AI 生成代码验收清单：用证据核实结果

能跑通一次演示，只是一条观察。验收要回答的是：这个具体版本，是否在约定条件下完成了用户任务，结论是否有可复查的证据？

本清单适用于获授权环境中的小型应用功能、API 改动或缺陷修复。从用户正常入口开始，检查到最终可持久保留的结果。清单可以手动使用；相关 Skill 用来组织工作，并非填写模板的前提。

适合与不适合的范围

适合审查范围明确、基线和需求可识别、能够访问相关运行环境的改动。检查深度由行为风险决定，不由修改文件数决定。

它不替代渗透测试、无障碍合规评估、受监管系统认证或生产压测方案。支付、身份、敏感数据、破坏性迁移和安全关键系统需要额外的专业审查。打勾不构成法律或安全保证。

1. 固定验收对象

记录基线、候选提交或构建产物、环境、浏览器或运行时、角色、获准的数据来源及副作用范围。存在未提交修改时，还需保存差异快照或哈希。先附上需求来源并分配 REQ/AC 编号，再看测试结果。

每项需求都写成独立于代码实现的可观察结果。“执行了 Save 处理函数”不够；“有权限的用户重新打开记录后仍看到新值”才是结果。关键规则缺失时标为 BLOCKED，不从生成代码反推正确需求。

使用 PASS、FAIL、BLOCKED、NOT RUN 或 N/A。N/A 必须说明为何确实不适用，不能用来掩盖工具缺失。没有证据不能判 PASS。例外应记录决策人、范围和后续事项，不可悄悄改成通过。

2. 执行适用检查

• [ ] 需求: 将每项 REQ/AC 对应到实现入口、用例和结果。检查差异中完全缺失的承诺，记录已同意的排除项，并确认没有擅自增加业务规则或权限。

• [ ] 核心功能与持久化: 从对应角色的正常入口完成任务。写入后刷新或重新打开，在允许的访问范围内读回权威状态，并关联同一对象和请求。成功提示不能单独证明保存成功。

• [ ] 边界与状态: 按实际规则检查缺省、空值、非法值及上下界两侧，确认计数单位。按风险覆盖合法和非法状态转换、重复点击、旧页面及并发更新。

• [ ] 错误与恢复: 仅在获准的隔离环境测试超时、拒绝、部分失败和中断。确认用户能理解错误并恢复操作；重试不重复产生副作用，迟到响应不能覆盖更新的操作。

• [ ] 安全基础: 检查实际动作及对象的服务端授权，包括归属不同的第二个测试账号。拒绝请求不得改动数据；按攻击面检查输入校验、输出编码及构建文件或日志中的凭据泄露。只做授权检查，不攻击无关系统。

• [ ] 可访问性与交互: 用键盘完成受影响流程，检查焦点、名称和标签、错误及弹窗关闭。检查缩放、窄屏、可读对比度和有意义的替代文本；按产品需要增加辅助技术检查。这些基础检查不等于合规评估。

• [ ] 性能: 先约定操作、数据规模、设备和网络条件、测量方法与阈值。测完整用户操作，不只测 API 耗时；同条件比较基线并保留样本及资源观测。无阈值时报告测量结果并等待决策，不自设及格线。

• [ ] 回归与审查: 运行受影响的现有检查及仓库要求的 lint、类型、构建和测试。覆盖共享调用方及相邻合法和非法路径，审查最终差异是否遗漏需求或削弱断言。修复要保留修复前失败、修复后通过的信号。

• [ ] 证据与交付: 每个结论都关联被测版本、实际步骤或命令、预期、实测及原始证据。明确标注 Mock、固定样本、合成数据及静态审查；确认最终差异没有使证据过期。本地验证、部署和目标运行环境验收分开报告。

3. 保存可复查的小型证据记录

每例记录：CASE 编号 → REQ/AC → 角色和数据来源 → 精确步骤 → 预期 → 实际 → 状态 → 通过或失败证据 → 环境及版本 → 缺口与负责人。

截图只能证明可见状态，不能证明持久化；200 响应不能证明目标对象正确变更；Mock 测试通过不能证明真实依赖可用。证据必须匹配结论，隐去秘密，只分享给获准查看的人。

可使用配套 Markdown 模板，或复制下方记录格式。模板包含九个起始检查项及可复制的用例记录；每行是覆盖提示，不代表整个类别已通过。

• CASE / REQ / AC: ____
• 角色 / 初始状态 / 数据来源与替代数据许可: ____
• 可复现的精确步骤或命令: ____
• 预期结果与规则来源: ____
• 实际结果: ____
• 状态（PASS / FAIL / BLOCKED / NOT RUN / N/A）: ____
• 通过证据：产物或脱敏日志、时间、版本: ____
• 失败证据：准确差异及产物、时间、版本: ____
• 持久化 / 外部最终状态读回: ____
• N/A 理由或剩余缺口 / 负责人 / 下一步: ____
• 修复前结果 / 修复后结果 / 受影响回归: ____
• 最终差异审查证据: ____

4. 合成演示：保存显示名称

以下仅为合成教学演示。输入和观察结果均为说明记录方式而虚构，未在用户生产项目或任何真实验收会话中执行。

假设已明确约定：去除首尾空白后，显示名称允许 1–40 个 Unicode 码点，用户只能修改自己的名称。这只是示例规则，不是通用推荐限制。

CASE-NAME-01 / AC-NAME-01：从正常菜单打开个人资料，保存“River”，重新打开。预期：名称仍为“River”，获准的读回结果属于同一账号。假设观察：成功提示出现，但重新打开显示旧名称。演示状态：FAIL。真实执行时应采集修改前后画面、脱敏请求及同账号同版本的权威读回证据；本文并未提供这些运行证据。

CASE-NAME-02：尝试去空白后为空，以及 1、40、41 个码点的输入。按假设规则，空值和 41 应拒绝，1 和 40 应接受。这些仅为计划用例，状态 NOT RUN；使用前先核实样本实际计数，码点、字节和用户感知字符并不相同。

CASE-NAME-03：在授权测试环境用账号 A 尝试修改账号 B。预期拒绝且 B 不变。CASE-NAME-04：中断保存，按约定恢复规则重试并检查最终状态。未使用授权测试账号和故障条件执行前，两项均保留 NOT RUN。

5. 决定哪些部分真正就绪

分别报告仓库规范、需求覆盖和运行时验收。约定范围内仍有 FAIL、BLOCKED 或 NOT RUN 的验收项，就不能宣称整体完成。“本次差异未发现可证明的缺陷”只是限定范围的审查结果，不是无缺陷保证。

失败后保留证据，区分产品、测试、环境、数据或需求问题。不要削弱断言、删除用例或反复重跑碰运气。仅在授权范围内修复，再跑原始用例及受影响路径，审查最新差异。

用准确交付状态：已实现、本地已验证、已部署、真实路径已验收。本地验收不授权部署；部署也不能单独证明用户任务可完成。

选择相关工作流程

• talking-us: 成功规则不明确或产品决策待定：澄清需求，不修改产品。
• write-design-doc: 需求已确认，但 API、数据或状态契约不清：整理可直接实施的设计。
• test-case: 由需求推导用例。design 用于规划，validation 用于已授权的现有检查；模式名不授予修复或替代数据权限。
• bug-fixing: 已有可复现失败：追踪首先破坏规则的地方，获准后修复并验证相关路径。
• code-review-multiagent: 对照需求和调用方审查最终差异。默认深入 Solo；独立智能体按风险和宿主能力启用。
• develop-closed-loop: 将已授权且规格明确的改动推进至实现、测试、修复、回归、审查和交付证据。所需配套流程须另行安装。

已知局限与参考资料

本文是基于六个工作流程包整理的原创实用指南，不是它们跨模型行为的测试报告。Skill 不提供账号、浏览器、数据、部署访问或权限；单个下载不等于完整合集。部分界面设计分支依赖未打包的外部 frontend-design-lab。

模板用于记录证据，不能自行发现缺陷。抽样需要说明等价依据及未覆盖分支；合成示例不能替代要求的真实业务数据。访问缺失时，保留待验收状态，继续不依赖该条件的安全检查。

安全基础可参考 OWASP 关于逐请求权限校验及在正确可信边界执行授权的建议：OWASP Authorization Cheat Sheet。基础可访问性检查及其局限见 W3C WAI Easy Checks。这些参考不意味着本清单构成完整审计。

下载 Markdown 模板