AI 并行生成如洪水：Review 反成最大瓶颈

Opus 5 的宣传点是模型现在会检查自己的成果。Anthropic 对 Opus 5 的指导说得很清楚：模型默认会进行验证，你以前写的那些 verify 和 double-check 指令现在只会导致过度验证。边写边检查自己的成果是一回事；审查最终生成的 diff 是另一回事。Opus 5 在前一件事上做得更好了，而这悄然让你免去了后一件：它刚刚生成的四百行改动，以一个没人真正看过的绿色对勾，落在了你的分支上。

如果你同时用多个 agent 运行 Claude Code，你会知道那是什么样子。Hacker News 上有一位开发者说得直白："一旦 AI 开始生成代码，它就像溃堤的洪水一样涌出。任何人类都不可能完全理解这一切。"另一位，和我运行着相同配置的人说："我也会发出大量并行 agent，而审查绝对是最大的瓶颈。"（Hacker News）

Opus 5 本应让这个过程更快。结果它只是把工作挪了位置。你写得少了，审得多了，而审查机器写出的东西比审查自己写的更难，因为所有上下文都不在你脑子里。Robert Laszczak 这个月说得透彻："审查 agent 写的代码比审查自己手写的代码要难得多。"你找来一个更快的写手，结果得到的是一份全职审查你无法完全装进脑子里的代码的工作。

绿色对勾不是审查

当队列堆积，审查就不再是审查了。Shmulik Cohen 给取代它的东西起了个名字：vibe merging，"开发者被 AI 生成代码的洪流淹没，只是走马观花地浏览 diff 或凭直觉点击 Approve。"他们指出的特征你肯定已经做过了："LGTM 速通，三分钟内批准一个 300+ 行的 diff。"绿色对勾完成了审查，你只是签了字。

这些都不新鲜。早在 agent 写代码之前，开发者就会走马观花地看 diff、随手 LGTM。但一个五十行的改动集你走马观花看过去，大部分还是能 catch 到；因为改动小，扫一眼很便宜。扫的习惯没变，改动集变了。两分钟写完四百行、三分钟批准，而同样的直觉式检查现在覆盖的范围只有以前的零头。AI 没有发明橡皮图章，它只是让盖在上面的东西成倍增加了。

这也不是什么私密感受。业界已经把它量化了。Faros AI 读取了两年的遥测数据，来自 22000 名开发者，发现代码审查中的中位时间上升了 441.5%，完全不经过审查就合并的 pull request 上升了 31.3%。LinearB 统计了 810 万个 pull request，发现 AI 辅助的 PR 规模是手写的 2.6 倍，且在被审查者接手之前等待时间超过五倍。代码来得更快了；阅读速度没有。而这之下的质量鸿沟是开发者能感受到的：在 Stack Overflow 2025 年的调查中，46% 现在不信任 AI 输出的准确性，而信任的只有 33%，其中只有 3% 高度信任，最大的挫败感——占 66%——是答案"几乎对，但不完全对"。这正是那种能在三分钟扫描中存活下来的 bug。

本能反应是拿一个模型对准模型

所以显而易见的做法是把阅读自动化。如果一个模型写了代码，就让一个模型来审查代码。Opus 5 会告诉你做这件事。问它如何让自己的错误不进主分支，它会乐于提出审查自己的 diff——猜来猜去给自己打分。这是首先要不信任的建议。每个代码托管平台现在都自带一个 AI 审阅者，在 diff 上留评论，对于机械层面它确实有帮助，就像 linter 那样有帮助：它"生成了 linter 会生成的同类型局部、机械反馈，所有那些可能拖累人工审查者、让他们无法处理全局事项的东西"。（Hacker News）

麻烦始于你让那个审查者成为四百行 AI diff 和主分支之间的守门人。现在你有一个模型在检查另一个模型，它的判断和写代码的那个 stochastic guess 是同一种东西，而这个问题不会因为你给它的代码越多而变得越简单、只会越难。在一个大改动上，每次都对的几率相乘下降：单个函数看起来还行的每行准确率，在一百个函数上就会崩溃。

更强的基座模型救不了你

它终究还是个 guess，而 guess 的数量在增长。论点跟 Opus 5 那个一样：《删除你的 CLAUDE.md?》，模型给自己的指令规则打分：一个 stochastic judge 运行多次，在你最依赖它的地方恰恰变得最不可靠。

真正守得住的东西

随模型扩展的不是更快的阅读器，而是不需要阅读的关卡。确定性检查直接拒绝操作：失败的测试、阻止的 lint 规则、拒绝写入变更永远不该触碰的路径的 hook、拒绝格式错误文件的 schema。它对 diff 不形成意见，所以不会因为 diff 变大而变得更不可靠，它在第一个文件和第一百个文件上返回相同的判断。Prompt 引导，hook 强制：引导是模型可以权衡也可以搁置的建议，关卡是它无法逾越的地板。我们对自己的 agent 运行这样的关卡，它们 catch 到了下午六点疲惫的审查者 catch 不到的东西。

Bryan Finster，多年来一直主张代码审查一直是弱点的家伙，得出了相同的结论："答案是把所有能自动化的东西都自动化，把人类判断留给真正需要它的东西。"

关卡做不到什么

值得把边界说准确，因为这很容易被过度宣传。判断这是否是正确的功能、架构在六个月内是否还能撑住、代码是否做了 ticket 实际要求的事：每一种都需要一个关于变更所处世界的模型——产品、使用它的人、整个事情的方向。关卡没有这些。它按规则检查 diff，从不对照现实，所以那个判断始终是人的。

而且对整个"审查是新瓶颈"框架的部分反驳是有道理的。一位开发者对这个恐慌的平实回应是："有人声称这是瓶颈吗？看起来是个稻草人。"他说得对，审查一直是约束。改变的是比例。当你写代码时，你的判断主要花在写上、少量花在审查上。现在写几乎是免费的，判断是全部工作，所以曾经藏在审查里的机械负载必须挪到模型无法巧言令色通过的地方。那个地方就是关卡。

读一次规则，关卡其余部分

你用 Opus 5 来写更多、决定更少。真正实现这一点的方法是停止把人工注意力花在检查能解决的部分——格式、冲突、禁止的调用、爆炸半径外的写入——而把它花在模型无法给你的唯一东西上：这值不值得做。指向第二个模型去审查第一个感觉像是进步，却悄悄一个 guess 一次地重建了问题。模型无法争辩的关卡是无聊的答案，但它在当天第一百个 pull request 时仍然站着。

我在 Reporails 工作，做指令文件、规则和驱动编码 agent 的 prompt 的确定性诊断和治理。它读你写下的引导面，告诉你，有量化的证据，哪些指令耦合到行为、哪些是模型可以忽略的文字。它不运行你的模型，也不投票；它只测量文件。