验证鸿沟：我们自动化了代码生成，却忘了扩大审查规模

James Coombs 是一名设计工程师，负责编写 AI 代理在 Pull Request 上运行的代码审查技能。他提取了 49 个代码仓库连续四周的合并 PR 数据，检查审查是否跟上了生成的节奏。仪表盘显示跟上了。去掉机器人再看——并没有。

在一个工程组织内的 49 个代码仓库中，2026 年 8 月 24 日至 9 月 20 日的四周内合并了 1,239 个 Pull Request，其中 90.7% 标记为 AI 辅助（在提交时标记）。其中一半——50.6%——没有任何人账户的审查就合并了。不是轻量审查。根本没有。而这还是保守数字，因为几位工程师把代理撰写的审查贴在自己账户名下，所以来自人员账户的审查并不一定是人写的审查。组织的审查指标看起来更健康：中位 PR 收到两条评论，只有 30.6% 完全没有任何评论。两种说法都对，因为指标把机器人算作审查者。在那个时间窗口的最后一周，机器人留下了 898 条审查中的 635 条。我们用同样的方式扩大了代码产出速度，又用同样的方式扩大了审查规模，而人类审查根本没有扩展。

鸿沟，以及那个看似正确却错误的故事

我最初在七月跑了这些数字，当时是一周和 331 个 PR。那时候中位 PR 收到零条评论，55.6% 完全没有评论，43.2% 除了作者之外没有任何人审查。现在变成两条、30.6% 和 25.7%。看起来像是审查在追赶上来。并不是。只看来自人员账户的审查，没有任何审查的 PR 占比从七月的 47.7% 上升到过去四周的 50.6%，仅最近一周就达到 61.6%。仪表盘的收益全是机器人审查。

一个诱人的说法是 AI 写了烂代码，人类放行通过了。我无法验证这一点，而且值得精确说明原因，而不是随手抓一个数字。收集器统计标题以 "revert" 开头的 PR。这是回滚 PR 的计数，不是衡量谁的代码后来被回滚的指标，四周内仅有一个。七月的速度数据我也解读过：AI 辅助的 PR 停留中位时间 2.4 小时，而纯人类 PR 是 0.6 小时。现在变成 3.4 小时对比 3.8 小时，单周数据两者都有高低，而且 1,239 个 PR 中只有 115 个是纯人类 PR，所以我放弃了这个论点。

在任何人都拿这些数据制定政策之前，先说明一个注意事项：这是一个组织在四周内的数据，所以把它当作一个趋势而不是常数来理解。小仓库偏差很大，而这个数据集里小仓库很多。49 个仓库中有 20 个在四周内只合并了三个或更少的 PR，49 个中有 27 个中位评论数为零，而按 PR 权重的中位评论数是两条。所以不要依赖每个仓库的计数。内联评论也是按 PR 而不是按作者记录的，因此没有任何人类评论的占比只能给出一个范围：37.8% 到 66.2% 之间。两个异议都站得住脚的那个数字是审查覆盖率：1,239 个 PR 中有 627 个没有任何人账户的审查，而代理以人员账户名义发布的审查意味着真实数字更高。

零评论批准不一定是坏审查。有时候变更很小，审查者放行是正确的。更严格的衡量标准——没有任何书面评论的批准——占每个 PR 的 5.3%。对照收集到批准的 49.2%，大约九分之一是沉默批准的，比七月的四分之一有所下降。限制到来自人员账户的批准者，是 17.7%，接近六分之一。我没有说机器人审查没有价值。关键是一个机器人审查代理的 PR 是系统自己在检查自己，而把这个计为审查的指标无法区分差异。当至少一半的合并没有任何人工审查者时，审查悄然变成了一个签名，而且越来越像是机器的签名。

为什么显而易见的修复方案不起作用

一旦看到这个，反射性的做法是强制要求严格性。要求实质性评论。添加审查清单。硬加一个没人调过的必需检查。把"验证行为，不只是代码"写进贡献指南或代理的指令文件。

我测量过这类指令的结果。在早些时候对写入 AI 代理配置的行为规则进行的消融研究中，合规率是 0%。一条遵守起来有代价、且没有任何机制强制执行的规则，被遵守的概率和一条不存在的规则完全一样。人类和审查清单也是同样的逻辑。给两行变更增加五分钟的清单，就是那个人们学会跳过的清单。

所以这里是我想要反驳的观点：验证鸿沟是一个严格性问题。不是的。严格性很容易规定，也很容易忽略。鸿沟是一个采用问题。

为什么这是一个采用问题

你可以设计一个能捕获一切的审查流程。如果它花费的比中位变更人们愿意付出的更多，他们就会绕过去，而且一个经常被跳过的检查提供的保证比一个更轻但实际运行的检查还要少——只要更轻的那个仍然守住了一个真正的底线。跌破那条底线就会出现更糟糕的失败：一个检查运行了，通过了，在缺陷仍然上线的同时制造了信心。所以设计问题不是检查能有多严格，而是能有多严格的同时人们仍然会在想要放行的那个 PR 上运行它。

组织的数据展示了鸿沟。构建工具教会我的是原因：用来弥合鸿沟的检查被跳过了，不是因为它们错了。这只是一个组织的一项技能，是起点而不是证明。有四件事造成了差异。

按风险调整门槛。 每个变更根据两个因素获得一个风险等级：它有多可能破坏东西，以及如果破坏了会有多糟糕。一个复制小改动只需要一件证据；支付路径的变更需要完整的合约。关键是谁来设定等级：如果作者自己给自己的风险打分，轻的门槛就会成为每个人都声称的门槛，所以等级必须来自他们无法悄悄推翻的东西——差异启发式或路径规则。做错了，你就只是把作弊从跳过检查移到了错误分级。

永远不要要求无法提供的证据。 这是大多数清单犯的错。每个必需项都必须说明你实际上如何产生它。一个没有获取路径的要求，一个对没有视觉输出的变更要求截图，是无法满足的，而一个无法满足的条目比没有条目更糟糕，因为它教会人们整个系统都是噪音。一个达不到的门槛不只是在它自己的那一行失败。它让旁边的可达标的条目也失去了可信度。

** artifact 优于声明。** 停止接受散文作为证明。"已手动测试"是一个承诺，而不是第二个人可以检查的东西。截图、grep 结果、测试输出、日志行：这些才是证据。在这项技能中，纯粹的声明最多把一个要求降级为部分满足，因为这句话恰恰是 artifact 要替代的东西。当至少一半的 PR 从未到达能够要求提供 artifact 的人类审查者时，这一点更重要。

拒绝清洗自己的输出。 这是反直觉的那条。当技能同时收集证据并对其评分时，它自己收集的证据无法将一个要求提升到部分满足以上，而且它被标记为自报告。一个验证了自己工作并报告"已验证"的代理，什么也没告诉你。而那个标记必须喂入一个 gate 来对其采取行动，而不是留在记录里等待人类审查者——在至少一半的这些合并中，人类审查者根本不存在。同样的逻辑往上走一级：一个组织的机器人审查其代理的代码，而其指标称那为审查，就在组织规模上清洗了自己的输出。当一个系统开始检查自己时，它自身置信度的上限必须被强制执行而不是仅作建议，否则它已经把一个声明变成了事实。

这些都不是干净落地的。第一版要求每个变更都提供完整的证据合约。它很彻底，在小 PR 上被忽视得最严重——恰恰是小 PR 这种高容量场景需要一个轻量检查：我建了支付变更的门槛，却把它对准了 typo 修复。第二个错误是要求没有获取路径的证据，然后看着审查者认定工具是噪音而停止阅读它的全部内容——包括那些有信号的部分。这个教训让人不舒服：一个被忽视的门槛比没有门槛更糟糕，因为它还烧掉了下一个你设的门槛的可信度。

这把你带到了哪里

验证鸿沟不会通过把"更仔细地审查"写进政策而关闭，也不会通过添加审查机器人并看着评论数上升而关闭。生成已经自动化了。审查必须重新设计才能在容量中存活：按风险调整门槛、给每个必需项一个真实的获取路径、优先使用 artifact 而非断言、让任何自我检查的系统声明这一点。

你不需要我的数据才能开始，真正的测试是当另一个团队采用这个方法时跳过率是否下降。首先，把你的审查指标拆分为人类和机器人，并把以人员账户发布的代理审查算作代理的，因为在那之前，仪表盘会告诉你鸿沟在收窄而实际上它在扩大。然后找到你的团队在小变更上悄悄跳过的那个检查，问自己：它被跳过是因为它没有价值，还是因为它校准错误了。如果是校准错误，修复不是更多的纪律。而是为低风险场景设置更轻的门槛，这样检查才能存活下来去捕获高风险的那个。这周去找那个检查。