AI 写的 PR 测试全绿：你的合并标准是什么

这种场景如今我几乎每天都会遇到。一个 Agent 交回一个 Pull Request，测试全绿、diff 看起来合理，而我一行的代码都没写。现在我得决定要不要合并它——而且我发现我其实并没有一条始终如一的规则。我想知道你有吗。

选项似乎分布在一个光谱上。

一端是像对待陌生人写的代码一样逐行阅读，因为确实是个陌生人。慢，安全，而且quietly把 Agent 本应给你买来的速度又悄悄还回去了。

中间是信任测试，然后抽查有风险的部分。我大部分时间就处于这个区间，而它的根基是一个让人不太舒服的假设：我的测试套件足够好，好到能捕获我没有去读的那些东西。在那些测试确实扎实的仓库里，这套做法是可行的。在测试单薄的仓库里，我其实就是在信任一个绿色的勾，然后管这叫「审查」。

另一端是快速浏览，没明显问题就合并，因为量太大做不到更多，而且 Agent 通常是对的。快，但失败模式是一种微妙的 bug——微妙到刚好能通过快速浏览，这恰恰是这些模型最擅长制造的 bug 类型。

我目前的落脚点是：读一个 Agent 的 diff 大致就像读一个新人写的代码一样仔细，测试我只信任我真正信任的那部分。这意味着真正的工作转移了：决定我能否快速合并的真正因素，是在这个 Agent 运行之前我的测试本来有多好。验证并没有因为生成变便宜而跟着变便宜。

但这是一个人的规则，而且我会根据仓库的风险程度来回摇摆。

所以具体来说，两个问题：

你合并一段不是你写的代码的实际门槛是什么？逐行阅读、信任套件、抽查，还是别的什么？

那个门槛有没有烧过你——一个绿色的 PR 后来证明是错的，而你只是后来才发现？它改变了你现在审查代码的方式吗？

我要的是具体的故事，不是原则，因为我猜我们大多数人都在即兴发挥，同时假装自己有一套政策。