怎样检查 AI 写的代码：从 diff 到实际用户流程
Neaptide · 2026年9月20日 · 8 分钟阅读
从 diff、有效测试和用户流程三层检查 AI 生成代码，附审查提示词与完成报告模板。
本文目录
智能体说“测试通过”，只回答了一部分问题。还要知道运行了哪些测试、是否覆盖原始问题，以及有没有超出任务范围的改动。验收应从能与代码和应用行为逐一对照的条件开始。
检查 AI 代码分三个层次：文件改动、自动化检查和用户流程。 这是建议的工作方法，不是无错误保证；它帮助你发现还缺哪些证据。
开始前写下验收条件
对于咨询表单，只说“修好提交”不够。应描述可观察的行为：
服务器返回错误时，保留字段值并显示清晰提示。提交过程中不产生重复请求。成功后显示确认信息。
区分必须满足的条件和偏好。漂亮的重构不能替代原本需要修复的错误。
复杂任务可以先让智能体找出受影响部分和现有检查。明确验证方式也是 Anthropic 的建议之一。
第一层：阅读 diff
查看修改文件列表，理解每个文件为何需要改动。小型表单修复不应悄悄改变身份验证、依赖和部署配置。
检查：
- 原有访问规则与错误处理是否保留。
- 真实校验是否被替换成无条件成功。
- 原本能发现问题的测试是否消失。
- 是否加入密钥、多余日志或临时绕过措施。
使用 `git diff` 和 `git diff --stat`。如果智能体已经提交代码，要比较相应提交；普通的未提交改动 diff 此时可能为空。git diff 文档。
第二层：运行合适的检查
要求列出命令及每项结果。区分“已启动”“已结束”“已通过”。环境错误可能让进程结束，却无法证明修复有效或无效。
| 检查 | 回答什么问题 |
|---|---|
| 类型检查 | 是否满足被检查的类型约束 |
| 函数测试 | 给定输入是否得到预期结果 |
| 集成测试 | 相互协作的部分是否匹配 |
| 构建 | 当前配置能否完成构建 |
| 浏览器场景 | 用户可观察的流程是否正常 |
任何一项都不能代替其他所有检查。例如，构建成功不能证明邮件已送达。
修复可复现缺陷时，应确认相应测试在旧行为下失败、修复后通过。否则测试可能只检查新实现容易满足的条件，而遗漏原始错误。
第三层：走一遍用户流程
表单应检查空输入、无效值、服务器错误和成功提交。使用测试数据及测试接收端，避免产生真实客户请求，同时能观察结果。
浏览器自动化应检查可见行为，使用稳定的界面定位方式。Playwright 建议隔离测试，并使用与用户感知相关的定位器。Playwright 最佳实践。
截图能证明一个可见状态，不能证明整条处理链。还应检查处理函数是否收到正确字段、测试系统是否出现记录，以及重复点击是否产生重复项。
怎样让第二个智能体审阅
提供原始任务、diff 和现有检查结果，让它寻找违反条件的地方并说明复现方法。不要预先告诉它第一个智能体“已经全部正确修复”。
可用提示词：
对照任务条件审阅修改。每条意见注明文件、触发错误的条件和验证方法。不要列出与当前 diff 无关的通用建议。单独说明现有资料无法确认的部分。
第二个智能体只是额外的问题来源，正确性仍应依据代码与检查。意见有争议时，复现场景，而不是在模型之间投票。
完成报告应包含什么
保存一份简短、日后可核对的记录：
修改：修复了什么，涉及哪些文件。
已检查：命令、条件和结果。
场景：在应用中执行了哪些操作。
未检查：环境限制和未解决问题。
决定：接受、返工，或补充证据。不要用“总体能用”掩盖不确定性。如果测试服务不可用，就明确写出最终送达尚未确认，便于判断下一步。