怎样检查 AI 写的代码：从 diff 到实际用户流程
Neaptide · 2026年9月20日 · 9 分钟阅读 · 更新于: 2026年10月3日
从 diff、有效测试和用户流程三层检查 AI 生成代码，附审查提示词与完成报告模板。
本文目录
智能体修好了表单提交，测试也通过了，可服务器一报错，用户填的内容还是全没了。审查只做到 diff 和一排成功退出的命令，就会漏掉这种问题。验收代码要把三类证据连起来：改了什么，哪项检查能发现缺陷，用户实际经历了什么。
检查 AI 代码分三个层次：文件改动、自动化检查和用户流程。这套方法不保证没有错误，它的用处是让你看清还缺哪些证据。
开始前写下验收条件
对一个咨询表单来说，只说“修好提交”太笼统。要写出可以观察到的行为：
服务器返回错误时，保留字段值并显示清晰提示。提交过程中不产生重复请求。成功后显示确认信息。
必须满足的条件和个人偏好要分开写。不然，一次漂亮的重构很容易顶替掉原本要修的那个错误。
任务复杂时，先让智能体找出受影响的部分和已有的检查。给智能体一个明确的验证手段，也是 Anthropic 的建议之一。
智能体的解释只说明它的意图，证明不了实际行为。Diff 显示具体改动。测试验证某一个条件。把流程完整走一遍，才把界面和结果连起来。每种证据都有边界，一张成功提示的截图证明不了邮件已经送达。
第一层：阅读 diff
打开修改文件列表，逐个问一句：这个文件为什么要动。一次小小的表单修复，不该顺手改掉身份验证、依赖或部署配置。
检查：
- 原有访问规则与错误处理是否保留。
- 真实校验是否被替换成无条件成功。
- 原本能发现问题的测试是否消失。
- 是否加入密钥、多余日志或临时绕过措施。
用 git diff 和 git diff --stat 查看。如果智能体已经提交了代码，就要比较相应的提交，因为这时普通的未提交改动 diff 可能是空的。git diff 文档。
读 diff 前先执行 git status --short，因为新文件可能根本不在 diff 里。git diff 比较工作区与暂存区，git diff --cached 比较暂存区与 HEAD。想一次看全所有已跟踪但未提交的修改，用 git diff HEAD。已经生成的提交，要和任务开始前的基点比较。
第二层：运行合适的检查
让智能体列出确切的命令和每一项的结果。“已启动”“已结束”“已通过”是三回事。环境出错也会让进程结束，但这既不说明修复有效，也不说明无效。
| 检查 | 回答什么问题 |
|---|---|
| 类型检查 | 是否满足被检查的类型约束 |
| 函数测试 | 给定输入是否得到预期结果 |
| 集成测试 | 相互协作的部分是否匹配 |
| 构建 | 当前配置能否完成构建 |
| 浏览器场景 | 用户可观察的流程是否正常 |
表里任何一行都代替不了其他几行。比如，构建成功证明不了邮件已经送达。
缺陷可以复现时，要确认相应测试在旧行为下失败、修复后通过。做不到这一点，测试查的可能只是新实现容易满足的条件，原来的错误照样漏过去。
第三层：走一遍用户流程
表单要检查空输入、无效值、服务器错误和成功提交。用测试数据和测试接收端来做，既能看到结果，又不会产生真实的客户请求。
做浏览器自动化测试时，检查的是可见行为，定位要靠稳定的界面特征。Playwright 建议让测试彼此隔离，并使用贴近用户所见内容的定位器。Playwright 最佳实践。
截图能证明一个可见状态，证明不了整条处理链。还要检查三件事：处理函数有没有收到正确的字段，测试系统里有没有出现记录，重复点击有没有产生重复项。
一个实用的回归场景是：填写表单，触发可控的服务器错误，确认字段值保留，再次提交。请求进行中重复点击，不应创建第二条申请。在浏览器测试里模拟响应，验证的只是错误处理。邮件是否真的送达，要用测试收件人另行验证。
怎样让第二个智能体审阅
提供原始任务、diff 和现有检查结果，让它找出违反条件的地方，并说明怎样复现。别事先告诉它第一个智能体“已经全部正确修复”。
可用提示词：
对照任务条件审阅修改。每条意见注明文件、触发错误的条件和验证方法。不要列出与当前 diff 无关的通用建议。单独说明现有资料无法确认的部分。
第二个智能体给你的是更多的问题，仅此而已。代码对不对，仍然要看代码本身和检查结果。意见有争议时，就去复现那个场景。让模型之间投票，什么也证明不了。
完成报告应包含什么
留一份简短的记录，日后可以回头核对：
修改：修复了什么，涉及哪些文件。
已检查：命令、条件和结果。
场景：在应用中执行了哪些操作。
未检查：环境限制和未解决问题。
决定：接受、返工，或补充证据。当你能把需求、diff 和观察到的结果对应起来时，再接受修改。保留实际运行过的命令和场景，并写明尚未验证的部分。如果缺陷可以复现，就把准确步骤和预期行为交给智能体，这比一句“再检查一下”管用。
来源与核对
技术来源和计算已于 2026 年 10 月 3 日核对。场景与图示为 Neaptide 教学示例，我们没有做产品性能对比测试。