AI 生成代码的审查清单，应该回答一个问题：有什么证据，足以让我们接受这次改动？代码能编译、Agent 总结写得漂亮、另一个模型说“没问题”，都不能直接替代验收证据。
GitHub 的 Copilot 介绍仍把审阅和批准的责任留给用户。下面是我们建议的验收方法，不代表自动审查工具能认证代码正确。文档核验日期为 2026 年 9 月 29 日。
先看行为，不先信总结
重新写清楚需求结果，再找到真正负责实现它的代码。接受 Agent 对 diff 的解释之前，先读实际改动。
假设这次新增了一个删除已保存项目的接口。“删除按钮能用”并不是完整要求。项目拥有者应能删除指定项目；其他用户不能删除；请求中断时，不能悄悄破坏无关记录。
先写这些预期，再看测试。否则，测试可能只是在验证实现里的错误，而不是用户真正需要的行为。
按风险决定检查深度
这是基础清单，不能替代高风险系统的专业安全审查。不确定就升级处理，不要把“没检查”写成“通过”。
检查测试是否真的能抓住错误
以上面的删除接口为例，至少考虑授权成功、未授权尝试、项目不存在几种情况，预期结果应来自产品真实规则。
条件允许时，证明相关回归测试在旧实现上失败、修复后通过。还要检查模拟的认证层是否恰好绕开了原本要测的权限边界。
同一个 Agent 写的测试，是有用的提案，不是独立真相。需要反复比较模型或工作流时，另建 Coding Agent 回归测试集。
交付一份验收记录
让 Agent 给出简短记录，包括：
- 改变了什么行为，由哪些文件负责；
- 真正跑过的检查、结果，以及没跑的检查；
- 剩余风险和假设；
- 本次审查的准确版本；
- 合并或部署前还需要谁确认。
多份改动组合后，要在组合结果上重跑相关检查。某个分支被审查过，不等于另一个最终 diff 已经被验证。团队交接指南可帮助把证据跟着工作一起交付。
把生成与批准分开
第二个 Agent 可以找反例，但仍需要有人判断证据是否覆盖风险。范围更小的改动更容易验收；未经要求的大重构会增加难度。
如果希望在同一个云端项目里组织实现和审查，可以看 Agent.Space 的工作方式。打开 Agent.Space启动一个范围明确的任务，再用同一套标准验收，不因代码由哪个 Agent 生成就降低要求。