想象一下你的日常：你让 Codex 写了一段代码，然后让另一个 AI 帮你审查。它报了几个问题，你让 Codex 去改，改完再送审。第二轮、第三轮、第四轮，你盯着这个循环，脑子里冒出一个问题：这到底什么时候是个头？多审几轮，代码真的在变好吗？

大多数团队根本回答不了这个问题。他们只知道「AI 帮我写、AI 帮我审」，却从没想过审查这件事本身也可以被量化。John Watson 在 2026 年 8 月的一篇文章里，给出了一个罕见的答案。他帮一家叫 Gymwasp 的公司搭了一套「软件工厂」流水线，让 AI 从规划一路干到发布，全程没有一个人类去读代码。六个月之后，他从 372 个 issue、1801 轮对抗性审查、将近 1.2 万条审查结论里，挖出了六个反直觉的发现。

七个审查员，各管一摊#

这套工厂的名字叫 The Mandible。它的审查环节同时跑七个独立的审查 agent，每个 agent 跑在自己的模型实例上，互相看不到对方发现了什么。七个「赛道」分别是：测试覆盖率、整洁代码、前端、领域驱动设计、安全、无障碍、可观测性。每个审查员给出三种结论之一：pass（通过）、warn（警告，不阻塞合并）、fail（失败，阻塞发布），一轮的最终结论取七者中最差的那个。

这里藏着一个容易被忽略的细节：每个审查员都拿到一份「赛道外排除清单」，明确告诉它哪些事不该它管。作者说，没有这份清单，你会看到同一个问题被七个审查员重复报七遍。

发现一：六成五一轮就过#

数据里最反直觉的一点是，合并就绪来得比想象中快得多。65% 的 issue 在第一轮审查之后就没有任何 fail 赛道了，94.5% 三轮内达标，98.9% 四轮内达标。换句话说，绝大部分价值在第一轮就已经落地。真正拖到第四轮之后的，往往是那些复杂的 PR，它们在 LLM 的非确定性面前，想拿一个「全绿」几乎不可能。

这里要分清两个概念：「合并就绪」（没有 fail）和「全绿」（七条赛道全部 pass）。前者才是决定代码能不能上线的指标，后者更多是心理安慰。

发现二：第四轮之后，多审反而更糟#

如果额外的轮次真的在帮忙，「本轮通过的概率」这条曲线应该持续攀升。但数据显示它既不升也不平，而是先减半、再原地踏步。第一、二轮的转化率大约是 25%，从第三轮开始，审查进入了「震荡」而不是「收敛」。

更麻烦的是，有 218 个 fail 出现在之前一直干净的赛道上。原因不难理解：每一次修复都会碰到相邻的代码，从而在新地方触发新的问题。作者说得很直接：第四轮是一个「肘点」，过了这个点，多花一轮审查引入的不确定性，和它想消除的不确定性一样多。

发现三、四：29% 从没拿过全绿，天真的平均值会低估成本 44%#

如果只看那些「全绿」的 issue，平均每单要 3.31 轮。但把「带着 warn 上线」的也算进去，诚实的数字是 5.99 轮，差了将近一倍。有 29% 的 issue 从头到尾没拿到过全绿，它们是带着 warn 被发布出去的。

这其实是这家公司的风险容忍度：审查在前三轮已经抓住了结构性问题，剩下的都交给 warn 记下来。作者的观点很明确，在 LLM 审查的非确定性面前，追求 100% 全绿是对算力的浪费。

发现五：审查成本不随规模上涨#

七月，这家公司的发布量翻了三倍。如果审查环节靠的是人力，成本会跟着暴涨。但数据里，每单的审查轮次中位数稳稳停在 4 轮，发布量与轮次的相关性 Pearson r = 0.08，几乎为零。

这就是确定性自动化的意义所在：流水线在吞吐量上升时依然能保持形状。这也是为什么我说，把审查交给 AI，真正的收益不是「更快」，而是「可预测」。

发现六：代码比计划更容易写错#

1801 轮审查里，1463 轮花在代码上，只有 338 轮花在计划上，比例大约是 81% 对 19%。也就是说，AI 更可能在实现阶段把代码写错，而不是在规划阶段把方案定错。计划关卡在代码诞生之前，就把架构层面的错误拦了下来。

这提醒我们一件事：别急着让 AI 写代码。先让它把计划写清楚、把范围划明白，能省下后面一大半的返工。

隐藏杀手：基础设施抖动#

最后还有一个容易被忽略的数字。3.7% 的审查结论因为 agent 崩溃而丢失，8.1% 的轮次里至少有一条赛道没有被评估，111 次迭代在写出结论之前就死掉了。

作者把这种「基础设施抖动」称为「静默的信任杀手」。他说了一句很有意思的话：传统 CI 里 flaky 测试多了，你会忍不住把测试注释掉；AI 审查里，如果整洁代码审查员经常崩，你会忍不住把它整个移除。同样的本能，同样的错误。正确的做法是修 brief（审查员的指令），而不是干掉这条赛道。

怎么办：像调 CI 一样调审查#

作者把整件事概括为一句话：这是把 CI/CD 优化这门老手艺，对准了一个新靶子。心智模型可以迁移，因为形状可以迁移：一条可测量的确定性流水线，每个阶段都能被埋点、分析、改进。

具体的做法是三步。先埋点，记录轮次、结论、每个赛道的分布。再诚实测量，用生存分析而不是天真的平均，那些「被截断」的观测不是噪音，是数据。最后找到肘点，问自己哪一轮之后额外的努力不再有回报、哪条赛道卡得最多、返工都发生在哪，然后重调 brief、收紧排除清单、校准 warn 和 fail 的边界，再测一遍。

总结#

这篇文章最打动我的，不是那六个发现本身，而是一个视角的转变：当 AI 开始写代码、审代码之后，「代码审查」从一种人的直觉判断，变成了一条可以被测量、被优化、会漂移的流水线。对用 Codex 的我们来说，这同样适用。别再凭感觉觉得「多审几轮更安心」，去测量你的审查循环到底是在收敛，还是在空转。

参考来源：