AI生成代码需证据支撑：无测试不合并

AI写代码越快，PR越不能只看代码本身。

接下来真正要审的，是它有没有证明自己改对了。

没有测试证据、失败记录和影响范围说明的 PR，即使 diff 看起来很干净，也别急着合并。

过去审 PR，重点是人写了什么：代码风格、边界条件、命名、架构是否合理。

AI 参与以后，问题变了。

智能体可以很快生成一大段看起来合理的修改，也可以顺手补测试、改文档、修 lint。表面上 PR 更完整了，但审查者的压力并没有下降。

因为你不知道它是真的理解了问题，还是只是把错误藏到了更深的地方。

尤其是 AI 编程工具开始自动读仓库、自动改多个文件、自动跑命令以后，单靠肉眼看 diff，会越来越吃力。

团队需要把审查对象从“这段代码写得像不像人”改成“这次修改有没有证据支持”。

很多自动代码审查还停在第一层：有没有明显 bug，有没有安全风险，有没有风格问题。

这些当然有用，但不够。

AI 生成的 PR 最容易出问题的地方，往往不是语法。

它可能改对了一个测试，却破坏了另一个入口；可能补了异常处理，却吞掉了错误；可能把边界条件写得很漂亮，但和业务口径不一致。

所以审查者真正需要看的，不只是“哪里可能错”，还包括：

这就是证据审查。

它不是再加一层流程，而是把原来藏在评论里的追问，变成 PR 必填项。

可以先让每个 AI 参与的 PR 补一张表。

不需要复杂，越具体越好。

这张表最有价值的一栏，是“未覆盖范围”。

因为 AI 很擅长给出一个完整感很强的答案，却不擅长主动告诉你：哪些地方它没验证。

审查者看到未覆盖范围，才知道自己该把注意力放在哪里。

证据审查还有一个坑：让生成代码的同一个智能体，自己声明“我已经验证通过”。

这只能作为初筛，不能作为最终证据。

更稳的做法是把角色拆开：

不要把“模型说通过了”当成通过。

真正可用的证据，应该来自可复现命令、测试截图、日志片段、失败前后对比，或者明确的人类确认。

团队不一定要立刻换工具。

可以先把合并标准改成三条：

如果这三条答不上来，就不要因为 PR 是 AI 写的、看起来很快，就放宽审查。

AI 编程进入团队以后，真正稀缺的不是代码生成速度，而是可信的合并判断。

下一步的代码审查，不是让 reviewer 更快地点通过。

而是让每个 AI 生成的 PR 都带着证据上桌。