夜雨聆风
AI 写代码越快，PR 越不能只看代码本身。
接下来真正要审的，是它有没有证明自己改对了。
没有测试证据、失败记录和影响范围说明的 PR，即使 diff 看起来很干净，也别急着合并。
代码审查正在变成证据审查
过去审 PR，重点是人写了什么：代码风格、边界条件、命名、架构是否合理。
AI 参与以后，问题变了。
智能体可以很快生成一大段看起来合理的修改，也可以顺手补测试、改文档、修 lint。表面上 PR 更完整了，但审查者的压力并没有下降。
因为你不知道它是真的理解了问题，还是只是把错误藏到了更深的地方。
尤其是 AI 编程工具开始自动读仓库、自动改多个文件、自动跑命令以后，单靠肉眼看 diff，会越来越吃力。
团队需要把审查对象从“这段代码写得像不像人”改成“这次修改有没有证据支持”。
只看语法错已经不够了
很多自动代码审查还停在第一层：有没有明显 bug，有没有安全风险，有没有风格问题。
这些当然有用，但不够。
AI 生成的 PR 最容易出问题的地方，往往不是语法。
它可能改对了一个测试，却破坏了另一个入口；可能补了异常处理，却吞掉了错误；可能把边界条件写得很漂亮，但和业务口径不一致。
所以审查者真正需要看的，不只是“哪里可能错”，还包括：
这就是证据审查。
它不是再加一层流程，而是把原来藏在评论里的追问，变成 PR 必填项。
一张测试证据链表
可以先让每个 AI 参与的 PR 补一张表。
不需要复杂，越具体越好。
这张表最有价值的一栏，是“未覆盖范围”。
因为 AI 很擅长给出一个完整感很强的答案，却不擅长主动告诉你：哪些地方它没验证。
审查者看到未覆盖范围，才知道自己该把注意力放在哪里。
不要让 AI 自己给自己打满分
证据审查还有一个坑：让生成代码的同一个智能体，自己声明“我已经验证通过”。
这只能作为初筛，不能作为最终证据。
更稳的做法是把角色拆开：
不要把“模型说通过了”当成通过。
真正可用的证据，应该来自可复现命令、测试截图、日志片段、失败前后对比，或者明确的人类确认。
先改合并标准
团队不一定要立刻换工具。
可以先把合并标准改成三条：
如果这三条答不上来，就不要因为 PR 是 AI 写的、看起来很快，就放宽审查。
AI 编程进入团队以后，真正稀缺的不是代码生成速度，而是可信的合并判断。
下一步的代码审查，不是让 reviewer 更快地点通过。
而是让每个 AI 生成的 PR 都带着证据上桌。
