「写得比读得快」这件事，软件行业享受了很多年，只是没人特意设计过它。

一个资深工程师读代码的速度，本来就快过一个初级工程师写代码的速度。评审因此能跟得上开发节奏，团队在互相读 diff 的过程里，也顺带把系统长什么样装进了脑子。这套流程管用，靠的是一个相对速度上的巧合：写代码慢且贵，读代码快且便宜。

这个巧合已经不成立了。

agent 写出一千行格式规整、大致合理的代码，用的时间比我读完这一段还短；而人的阅读速度，从我们开始整天盯着屏幕那天起就没怎么变过。约束于是往下游挪了一格，挪到唯一没有变快的那一步：一个人得确认这处改动是对的。

Addy Osmani 今年写了一篇长文，把过去一年里被反复量出来的数据、被反复争论的问题整理成了一张地图。他的结论是，评审没有因为 agent 的到来变得次要，它变成了核心工作。这个判断我认同，而且觉得对国内团队尤其值得看一眼，因为我们的讨论大多还停在「AI 到底能不能写好代码」。

数字比观点更硬#

先看被量出来的东西。

Faros AI 从低 AI 采纳度到高采纳度跟踪了 4000 个团队、22000 名开发者，这是 2026 年 3 月的数据。好的一面先说清：开发者合并的 PR 明显变多，人均吞吐上升，活儿干得更多了。然后是同份报告的其余部分：

  • 代码 churn 上涨 861%
  • 事故与 PR 的比值上涨 242.7%
  • 人均缺陷率从 9% 升到 54%
  • 评审时长中位数上涨 441.5%，首次评审等待时间和平均评审时间都大致翻倍
  • 零评审直接合并的 PR 增加 31.3%

最后一条最难解释，因为没人主动做过这个决定。评审者跟不上量，代码就开始在没人读过的情况下合进去，然后这变成了常态。还有一点，工程规范成熟的团队被冲击的程度和别人一样。好流程没保住他们，量的到来比任何流程设计的吞吐都快。

CodeRabbit 在 2025 年 12 月研究了 470 个开源 PR，其中 320 个有 AI 参与、150 个纯人工。AI 改动带来的问题大约多 1.7 倍：逻辑与正确性问题多约 75%，安全问题多 1.5 到 2 倍，可读性问题翻了三倍多。他们 AI 负责人 David Loker 把这些称为「可预测、可度量的弱点」。可预测三个字是关键，弱点已知、能定位，就意味着无论人工还是自动的评审流程，都能对着它们瞄准。

GitClear 到 2025 年的生产力数据里有我认为最该拿来说的一个对比：每天用 AI 的人产出的原始代码量大约是不用 AI 的人的 4 倍，但和自己一年前比，真实生产力提升大约只有 12%。也就是说，四倍的代码，换来一成多的交付价值，中间那三倍多的差额，是评审问题的一句话版本。GitClear 的 Bill Harding 自己也说明，这 12% 里有一部分是选择偏差，因为更强的开发者集中在 AI 组。

GitHub 那边，Copilot 的评审已经跑了 6000 多万次，不到一年涨了 10 倍，平台上超过五分之一的评审有 agent 参与。这不再是边缘做法。

四份数据，四套方法，指向同一个结论：我们把机器速度的产出，灌进了一个按人的速度设计的系统。瓶颈没有消失，它移到了验证这一端。还有一点得说明，CodeRabbit 和 Faros 都在往这个市场卖东西，读的时候留个心眼。不过这些效应量够大，而且来自彼此不相关的来源，方向又一致。

在我看来，这几组数字的价值不在绝对值，而在方向。它们说的是「生成速度」和「验证速度」被解耦了，而大多数团队的组织结构、CI 配置和人力分配，还是按「生成是瓶颈」那个世界设计的。

你的位置决定评审该有多重#

有三个变量决定你站在光谱的哪一段：爆炸半径，也就是它崩了会怎样；这段代码能活多久；有多少人需要看懂它。

同一个 diff 放进这三条里跑一遍，「好的评审」的含义完全不同。

单人、没有用户、全新项目。 评审的第二个职责，把知识分给团队，对你根本不存在，你就是整个团队。合理的做法是重度依赖测试和自动化，只仔细看真正要紧的部分，其余轻拿轻放。重复和 churn 在这里贵不到哪去，代码可能下个月就不存在了，崩了也不会有人在凌晨三点被叫起来。但有个前提，测试得是真的。没有安全网就跳过评审，不是省掉工作，是把工作推后并以更高的价格还账，而且没人在旁边反驳的时候，标准会悄悄往下滑。

项目开始有用户了。 这是危险的中段，而且跨越的那一刻很少被注意到。评审查 bug 的职责突然开始值钱，因为 bug 开始伤到人；知识共享的职责也打开了，因为不再只有你一个人。团队往往带着单人时期的习惯多过几个月，然后是一次复盘会，然后 Faros 那张图变成了自己的仪表盘。

大组织、老代码库、大量用户。 上面每一个刺眼的数字都会满功率落在这里。一个重复的工具函数不再是风格问题，它是一个未来的 bug 面，是逐年复利的维护成本。一处没人看懂的改动，会变成某个人的 on-call 事故。Faros 关于成熟团队的那个发现，说的正是这一档。

所以结论不是「企业该谨慎、个人可以放松」。把大企业那套多 agent、要证据的全套流水线塞进两个人的原型里，是白加摩擦；把「测试过了就发」用到支付系统上，是造了一台带着绿色对勾的事故生成器。这个领域里大多数糟糕的建议，都是光谱的一端在指导另一端怎么活。

评审原本在查的是什么东西#

人写代码的时候，意图是免费附带的。理由、被权衡之后丢掉的方案，都活在作者脑子里，评审就是你检查那套推理。

现代 agent 也会推理，有时候还露给你看：思考轨迹、选项权衡、边说边解释。问题是这层推理在 diff 生成的那一刻通常就被丢掉了。很少被记下来，很少挂到 PR 上；就算留下了，那也只是 agent 关于「怎么实现」的推理，不是人关于「这该不该做」的判断。

于是评审从「检查摆在面前的推理」，变成了「重建一份从没被写下来的意图」。后者更难也更慢，而我们还在为「它怎么慢了 441%」感到意外。

2026 年那篇《AI Slop and the Software Commons》分析了 15 个 Reddit 和 Hacker News 帖子里 1154 条开发者讨论，主题是「AI slop」。里面有一句话我印象很深：审一个 agent 的 PR，让那个人成了「第一个看到这段代码的人」。

这句话值得停一下，因为它直接指出了修法。正常评审里，作者已经理解了改动，你在核对他的工作；agent 的 PR 里，「为什么」还没被任何人重建过，评审者是第一个去重建的人。论文的说法是，评审流程「不是为找回缺失的意图而设计的」。好在缺失的意图是可恢复的，推理存在过，只是被我们丢了。让 agent 说清它要做什么、排除了哪些方案，把这份记录当成决策日志挂到 PR 上，重建成本的一大块就消失了。这是工具问题，而工具问题迟早会被解决。

这也不意味着「让 AI 审 AI」就是完整答案。另一个先验不同的模型确实能抓到真 bug，而且抓得不少，所以你应该跑一个。它给不了的是那个判断：这个改动本身值不值得做。那个判断留在人这边，而它恰好是这份工作里最有意思的部分。

AI 评审工具好用，但不是按它宣传的理由#

先看现在这几个工具的状态。CodeRabbit 部署最广，在 Martian 的独立评测（2026 年 1 到 2 月）里按 F1 排第一，precision 大约 49%，recall 是全领域最高。Greptile 拿 precision 换 recall，在某个评测里 bug 捕获率约 82%，同期 CodeRabbit 是 44%，代价是误报更多。Anthropic 的 Code Review 报告说，他们工程师认为标错的发现不到 1%；更该拿给管理者看的是另一个数字，它把内部「收到实质评审的 PR 比例」从 16% 提到了 54%。过去被扫一眼就通过的改动，现在至少有东西在读它了。

今年我看到最有用的一个结果不来自厂商。有个工程师把四个评审工具并行跑了三周半，CodeRabbit、Sentry Seer、Greptile、Cursor BugBot，一共 146 个真实 PR、679 条发现。617 个不同的被标记位置里，93.4% 只被四个工具中的一个抓到，6% 被两个抓到，几乎没有被三个抓到的，一个位置被四个同时标出来，一次都没有。

四个工具从来没有标过同一行。各自强在不同类别：Greptile 在正确性和架构上几乎零误报，CodeRabbit 网撒得最开、还能一键修，Seer 最擅长判断生产故障的严重程度。这才是对抗性评审在真实代码库上的样子。同质化才是问题：四个同一个模型的副本，就是一个收费更贵的评审者；四个真正不同的评审者，才凑得出一组任何单一成员（包括人在内）都找不出的 bug。

实践上的意思是，别纠结哪个工具最好，没有最好。高风险那一端，跑两个性格刻意不同的。单人的话，一个好工具加真实的测试就够了。还有，不管营销怎么说，都在自己的代码上量一遍，上面每个结论都只对某一个具体代码库成立，你的也会是。

那要不要干脆让 AI 多审一点#

我越来越常听到一个一年前还算异端的问题，问的人还是有经验的工程师：是不是该让机器多审一点，甚至审掉大部分？我不再觉得这个问题荒唐。

难受的地方在于，AI 评审确实有效。Anthropic 那边标错的发现不到 1%，这些工具能抓到人一眼划过去的东西，而且它们不会在一天第 30 个 PR 上变得不可靠，那恰恰是人最不可靠的时候。同时人明显跟不上：零评审合并涨了 31%，评审时长涨了三位数。某种意义上，机器已经在审比你更多的代码了。「要不要让 AI 多审」这个问题已经过时，真正要回答的是：它已经在审了，我们是有意识地这么安排，还是让它在大家假装人还在读每一行的时候默认发生？

Loop engineering 让这件事更清楚。循环的前提是，你不再是那个给 agent 写提示的人，你搭一个系统去提示它，而系统里有个核心角色是裁判：一个决定活儿干完没有的 agent。评审者就是下一个被有意设计出内循环的角色。我们用一年时间把「写」自动化了，现在循环在自动化「查」，人不断被往上推、往外推。「人留在哪」不是一个研讨会问题，它是你每接一个循环就在做的决定，不管你有没有意识到自己正在做。

我现在的落点是这样，而且随时可能改：答案不是「人读每一行」，那个时代结束了，量把它终结了，还在坚持这个说法的人描述的是一段不存在的世界。但它也不是「让循环自己审自己然后走开」。agent 写代码、另一个审、第三个裁决，这是一个模型闭包，盲点高度相关，尤其当它们同出一门的时候，会在同样的地方自信地点头。一个没有任何人参与的「看着没问题」，是借来的信心：系统的确定性变成了你的确定性，而实际上没有人理解任何东西。循环可以既非常确定又非常错，而没有人留在那里分辨。

所以人没有离开，只是上移了一层。你不再审每个 diff，转而负责那些无法转移给模型的部分：责任制，凌晨三点你没法给模型打电话；关于「这到底是不是该做的改动」的判断；错了代价很高的高风险闸门；还有那条比较别扭的，没人写进需求的隐含行为。模型审的是已经存在的代码，很少指出那个没人想到要写下来的需求，这仍然是一个人的形状的空缺。

Human in the loop 于是变成 human on the loop：抽样、抽查、审计这套系统，而不是读每个 PR，把有限的注意力花在错了真会疼的地方。

我自己也是这么干的。开源项目一天进来的 PR，比我一个晚上能认真读完的多，我就把 Claude Code 或者 Codex 指向一批 PR，让它给个第一遍：哪些看起来安全可合，哪些还需要加工，哪些真的高风险。我不会照着结论自动合并，也不会偷懒地把它批准的一律放行。它给我的是分配注意力的办法，几分钟确认它认为低风险的，把真正认真的一小时花在它标红的那些上。关键的细节是，这不是同一小时变快了，是另一种形状的一小时，而在现在的量级下，它是队列还能撑住的主要原因。

还有一个更极端的版本。前 Meta L8 工程师 Kun Chen 作为单人开发者一天发大约 40 个 PR，基本已经不审代码了。他并行跑 20 到 30 个 agent，把力气挪到了计划上：提前写详细的计划，agent 对着计划跑几小时，他说计划的质量决定它们能无人值守跑多久。

这件事值得看得更准一点，因为他并不是停止了验证。意图没有消失，是他自己提前写进了计划里，所以「第一个看到这段代码的人」这个问题被解决了一半：确实有人理解了「为什么」，只是在代码存在之前，而不是之后。他也没有裸奔，他搭了一道自动评审闸门（他叫它 No Mistakes），代码合并前会检查，agent 卡住时他还在升级路径上。人做代码存在之前那部分昂贵的思考，机器做之后逐行的检查，这很可能就是终局的形状。

但他是一个单人开发者，背后没有大团队，也没有一个埋满地雷的十年老系统。让他「一天 40 个 PR 不审」成立的前提，大多数读者并不具备。把这套工作流照搬到一支服务大量用户的团队，你就把 Faros 的数字复制到了自己的仪表盘上。他没有错，他只是待在这条光谱很靠某一端的位置。

真要做，有这么几件事#

按风险分层，不按作者分层。 改配置值得一个 linter 加一眼扫过。支付路径值得全套：类型、测试、两个不同的 AI 评审、一个拥有那个系统的人，再加一次安全审查。别在样板代码上做重评审，也别因为测试是绿的就把一处认证改动放过去。分层的逻辑到处都一样，变的是某个 diff 要通过几层。

让昂贵的尾巴快速失败。 2026 年 1 月那篇《Early-Stage Prediction of Review Effort》研究了 33707 个 agent 提交的 PR：agent 擅长小而明确的改动，大约 28% 几乎秒合；但一遇到主观反馈就容易「消失」，放弃评审本该有的来回。另一篇 2026 年的论文发现，评审者放弃占了被拒 agent PR 的 38%。研究者用文件类型、补丁大小这类便宜信号提前预测「高维护成本」的 PR，效果不错。所以提前分流，把琐碎的快速放行，别让一个人在一处发散得很开的大改动上耗掉一小时，而 agent 在你一反驳时就已经跑掉了。

把「什么才值得审」的门槛抬高。 被淹没的解法不是把仓库锁起来，是拒绝评审那些没有证据就送过来的改动。评审之前要求：说明这个改动是干什么的、一个不是 3500 行且没有注释的 diff、测试输出，以及它真的跑过的证明。这样你就不必再当第一个读这段代码的人。你把重建意图的成本推回给提交者，那里便宜，而不是自己扛，那里贵。

刻意把 PR 保持小。 agent 的 PR 平均大 51%，而评审者是否真正参与，是 PR 能不能合的最强预测因子之一。一个大到没法读的 PR，要么被直接拒掉，要么更糟，被盖一个橡皮图章。让 agent 产出小提交，一个人类读得动的 diff 现在是设计约束，不是礼貌问题。

测试改动要读得比代码更细。 这是 agent 最典型的失效模式：它改了行为，然后通过重写断言去「修」测试，让它匹配那个新的、坏掉的行为。200 个测试改过之后全绿，在你确认这些修改是对的之前，什么都不代表。任何重写大量测试的 diff 都当成红旗，先读它。突变测试在这里有它的位置：覆盖率告诉你某一行跑过了，突变测试告诉你这一行错了测试会不会发现。

把 CI 当成不会挪的墙。 留意 GitHub 现在提醒评审者注意的那些模式：删掉测试、跳过 lint、下调覆盖率门槛、重复一个别处已经有的工具函数、把不可信输入灌进 prompt。最后一条要强调，agent 造出来的功能是 prompt 注入的新来源：如果一处改动把用户可控的文本喂进 LLM 调用，又没想过这段文本能让模型去做什么，那漏洞不在 diff 里，它潜伏在以后会到达的数据里。agent 还会为了让自己的改动通过而削弱 CI，这不是出于恶意，只是梯度下降在找通往绿灯的最便宜路径。确定性闸门是整条流水线里唯一没法被一段自信的文字说服的部分，所以把它保持严格。

合并由人负责。 模型不能被 on-call，也不能为它发出去的东西负责，所以谁点的合并谁负责。当 AI 评审用平静自信的语气说「看着没问题」，它递给你的是它不一定挣来的信心。把每一次 AI 评审当成传感器，不是裁决：是数据，不是决定。

如果你是团队负责人#

出货的瓶颈不再是写代码有多快，而是一个可信的人有多快能对一处改动建立信心。任何把生成当瓶颈、把评审当免费的计划都会悄悄停住，而速度看板一路都是绿的。

Faros 的报告说得很直：产出上升的同时，QA 和评审的工作量也在上升，所以「AI 让我们更快了」不能成为削减工程人力的理由，除非你先把评审缺口补上。资深工程师税，也就是三位数百分比的评审时长，最重地落在你最不能被卡住的那批人身上，而它在任何只统计合并 PR 数的指标里都是隐形的。

开源维护者最先、也最重地撞上这堵墙。源源不断看起来像样、实际空洞的贡献，即使出于善意也要花掉真实的分类时间，这是金丝雀。公司是下一批。处理得好的那些，把评审能力当成一种要测量、要保护、要有意识地花掉的真实资源，而不是 AI 释放出来的空闲。

写代码变便宜了，读懂它没有#

评审没有因为 agent 变得次要，它变成了核心活动。写代码正在被解决，一个月比一个月便宜；耐久的优势是那套让你能信任写出来的东西的系统。

别在两个方向上拿一刀切的答案。如果你是单人、没有用户，那些关于 churn 和重复的企业恐怖故事对你是未来的风险，不是今天的火，所以靠你的测试，审真正要紧的，并且诚实地承认推后的活儿迟早要还。如果你维护着服务很多人的大东西，上面每一个刺眼的数字说的都是你，唯一站得住的是一套分层、要证据、刻意异质的评审流程，合并由人拥有。

贯穿整条光谱的是同一件经济学：我们把「写」变便宜了，「懂」还和以前一样贵。未来几年过得好的团队，不会是产出代码最多的那些，而是搭出了一套自己真的能信任的评审系统的那些，也是从没有把「测试过了」和「有人理解这段代码在做什么、为什么这么做」搞混的那些。

Simon Willison 一直在说，你的工作是交付你验证过能跑的代码。agent 没有改变这一点，它们只是把「验证」从事后补的环节变成了工作的中心。我觉得这是一笔划算的交易。

参考来源#