代码审查成为 AI 时代最高杠杆技能

代码智能体代码审查

代码生成智能体现在表现异常出色，而且进步迅速。有趣的后果是，工程中最困难的部分已经从写代码转移到决定是否信任这些代码，这使得代码审查成为当今软件开发中最具杠杆效应的技能。你如何处理这个问题在很大程度上取决于你的身份：一个没有用户的独立开发者和维护十年老应用的团队面临的问题完全不同。

我对智能体工程的乐观态度达到了历史高位。这些智能体确实表现出色，每个月都在进步，现在我可以发布一些一年前我根本不敢尝试的东西。这篇文章是一份地图，指出有趣的工作已经去往了何处，因为它确实已经转移了，而大多数团队还没有完全跟上。

代码审查之所以有效，是因为一个幸运的相对速度巧合。一个资深工程师读代码的速度比初级工程师写代码的速度快，所以审查能跟上进度，而无需任何人特意设计它，团队因为相互阅读彼此的代码差异而作为副产品吸收了系统如何组合在一起的知识。大多数都不是故意的。这是由一个简单的事实推导出来的：写代码是缓慢、昂贵的部分，而读代码是便宜、快速的。

这个事实已经不再成立。一个智能体可以在我读完这段文字的时间内生成一千行通常坚实、格式良好的代码，而人类的阅读速度自从我们开始对着屏幕谋生以来基本没有变化。所以约束转移到了下游，转移到了唯一没有加快的步骤：一个人确信这个改动是正确的。我不认为这是一个损失。这是当今软件中杠杆效应最大的地方，也是我今年投入大部分注意力的地方。

这里有一个愉快的转折，塑造了本文的其余部分。生成所有这些额外代码的相同工具也是我跟上这些代码的最佳利器。在我自己的项目上，包括流行的开源项目，我现在会让 Claude Code 或 Codex 对一批传入的 PR 进行分类，这确实改变了我如何花费时间的方式。所以这不是反 AI 的论点，我稍后会回到我如何确切地使用它。

这也不是一份数据转储，也不是又一轮讨论让一个模型编写你的代码是否很棒或是工艺的终结，因为这种框架没有用。唯一能经得起真实代码库考验的答案是，这完全取决于你是谁。一个凭感觉编程一个侧项目（可能只有十几个人会运行）的开发者，和一个保持十年老企业系统再运行一个季度的团队，几乎没有任何值得命名的共同约束，而流通中的大多数建议实际上是这两个人中的一个在告诉另一个如何生活。

2026 年的数据实际显示了什么

AI 的生产力收益是真实的，但原始输出高估了它们：大约四倍的代码换来十分之一的交付价值增长。这两个数字之间的差距就是审查工作，这正是为什么审查现在是杠杆所在。

几年来这都是轶事和论证。现在它在规模上得到了测量，由没有共同议程的组织进行，在几种情况下涉及竞争性商业利益，而测量结果一直指向同一个方向：AI 将输出大幅推高，同时将质量和可审查性都推低。

Faros AI 为 22,000 名开发者（来自 4,000 个团队）进行了测试，并追踪了当团队从低 AI 采用率转向高采用率时发生的情况。这是 2026 年 3 月的数据，与这里的任何内容一样及时。上升面是真实的，值得明确陈述：开发者合并的 PR 数量和完成的工作都大幅增加，每个工程师的吞吐量也在上升。然后是报告的其余部分：

• 事故与 PR 的比率上升 242.7%

• 每个开发者的缺陷率从 9% 上升到 54%

• 审查中位数时间上升 441.5%，首次审查时间和平均审查时间都大约翻倍

• 合并未经审查的 PR 上升 31.3%

最后这个数字是我觉得最难驳回的，因为没人选择它。没有停止审查的决定。审查者根本跟不上数量，所以代码开始在未被阅读的情况下合并，这变成了正常现象。我一再回到的细节是，拥有成熟、纪律严明的工程实践的团队受到的打击同样严重。好流程没有保护他们，因为数量的到来速度快于任何流程被设计成可以吸收的。

一个需要始终持有的警告：CodeRabbit 和 Faros 都向这个市场销售，所以他们的框架不是不感兴趣的。这并不会使数字错误，效应大小很大且在不相关的来源之间是一致的，但厂商研究值得牢记这一点来阅读。

CodeRabbit 在 2025 年 12 月研究了 470 个开源 PR，其中 320 个是 AI 共同撰写的，150 个仅由人类撰写，发现 AI 变动携带的问题大约多 1.7 倍：逻辑和正确性问题上升约 75%，安全问题多 1.5 到 2 倍，可读性问题增加超过三倍。他们的 AI 主任 David Loker 将这些描述为"可预测的、可测量的弱点，组织必须主动缓解"。可预测是关键词。这些是已知的、可定位的弱点，这是好消息：这意味着审查流程，无论是人工还是自动化，都可以直接针对它们。

GitClear 有我会首先提出的单个数字。在他们 2025 年的生产力数据中，日常 AI 用户的原始输出大约是非用户的 4 倍，但根据他们自己一年前的输出测量，真正的生产力收益仅约 12%。你生成的代码大约是原来的四倍，换来的交付价值增加大约十分之一，而一个人仍然必须审查所有四倍的代码。为了 GitClear 的信用，Bill Harding 明确表示，即使是那 12% 中的一些也是选择偏差，因为更强的开发者集中在 AI 群体中。4 倍代码和十分之一价值之间的差距就是用一行话说出的审查问题。

GitHub 报告称 Copilot 审查现在已进行超过 6000 万次审查，在不到一年的时间内增长了 10 倍，平台上超过五分之一的审查涉及一个智能体。这不再是一个利基实践。这是代码的制作方式。

四个数据集、四种方法、一个结论。我们将机器速度的输出倒入了为人类速度工作而构建的系统。瓶颈没有消失；它转移到了验证，而审查就是支付这笔账单的地方。

每个人都在解决不同的问题

一个变动需要多少审查在很大程度上完全取决于它的影响半径，而你读到的大多数建议是由在非常不同的影响半径上运营的人写的。

上面几乎所有令人担忧的数据都来自企业遥测和被 open source 维护者淹没的情况。如果那是你的情况，它完全是真实的。如果你是一个人，发布的东西只有少数人会运行，大部分都根本不适用于你，你不应该被迫感到不安。

三个变量决定了你的位置：

影响半径：它在破裂时会发生什么。什么都不是，或者用户生气、金钱和 PII 处于危险中。

代码存活多久：你可能下周重写的一次性原型，或者你将维护多年的代码库。

有多少人需要理解它：只有你在你的头脑中掌握整个东西，或者一个团队必须随着时间推移共享所有权。

通过这三个变量运行相同的代码差异，"好审查"的意思确实截然不同。

如果你独自在一个没有用户的绿地项目上工作，审查的第二个工作（在团队中分配知识）对你不存在。你就是团队。合理的做法是依靠测试和自动化，审查真正重要的部分，接受其余部分的较轻接触。当代码可能在一个月内不存在且在凌晨 3 点破裂时没有人被寻呼时，重复和变动的成本要低得多。问题是，人们痛苦地学到这一点，那就是它仅在测试是真实的情况下才有效。在没有安全网的情况下跳过审查不会消除工作，它以更高的价格延迟它，而当没有人在那里推回时，标准会下滑。没有用户是推迟审查的许可。这不是跳过验证的许可。

然后项目获得用户。这是危险的中间地带，而过渡在当时很少被注意到。审查的 bug 捕捉角色突然变得重要，因为 bug 现在伤害人，它的知识共享角色启动，因为它不再只是你。团队保持他们的独奏时代习惯再长几个月，然后就有了事后分析，Faros 数字停止成为一个图表，而成为他们自己的仪表板。

在最远的一端是拥有老旧代码库和众多用户的大型组织。这里每一个令人警惕的数字都以完整的力度出现。一个重复的辅助函数不仅仅是风格问题，它是一个未来的 bug 源头和随着时间推移会不断增加的维护成本。一个没有人理解的变更是理解债务，最终会成为某个人值班时的突发事件。评审要同时完成多项工作，而 AI 智能体输出的数量悄悄地破坏了所有这些工作。关于成熟团队的 Faros 发现就是针对这里的。

所以关键点不是"企业应该谨慎，独立开发者可以放松"。而是审查的目的随着你的位置而改变，所以规则也必须随之改变。把企业那套锁死的、多智能体的、需要证据的流程强加在两人原型团队上，你只是增加了摩擦力而没有获得任何好处。在支付系统上运行"测试通过，发布"的策略，你就构建了一个事故生成器，只是在上面贴了一个绿色的勾号。这个领域大部分的坏建议都是某个位置上的规则被套用到了谱系上的另一个位置。

审查的真实目的

审查的初衷是检查作者的推理。AI 智能体确实会推理，但这种推理通常在生成 diff 时就被丢弃了，而不是附加到代码上，所以评审者必须重建一个从未进入 diff 的理由。好消息是：这是一个工具问题，捕捉推理过程可以让审查变得极其简单。

这是真正改变了的部分，我认为这一点被严重低估了。

当人类编写代码时，意图是自动获得的。推理、权衡过的和被舍弃的替代方案，都存在于作者的脑海中，审查就是你检查这些推理。现代 AI 智能体确实会推理，通常是可见的，产生思考轨迹、权衡选项并解释他们的做法。但问题在于，这种推理通常在产生 diff 的一刻就被丢弃了。它很少被捕捉，很少被附加到 PR 上，而且无论如何，它是 AI 智能体关于如何实现任务的推理，而不是人类对这首先是否是正确任务的判断。所以审查从检查摆在你面前的推理转变为重建从未被记录下来的意图，这更困难、更缓慢，而我们仍然对其耗时 441% 长度感到惊讶。

一篇 2026 年的论文《AI 垃圾信息与软件共有资产》分析了 15 个 Reddit 和 Hacker News 线程上的 1,154 篇帖子，其中开发者讨论了"AI 垃圾信息"。一位开发者的一句话一直留在我心里：审查 AI 智能体的 PR 让他们成为了"第一个看到这段代码的人类"。

这值得深思，它直接指向了解决方案。在常规审查中，作者已经理解了变更，你在检查他们的工作。对于 AI 智能体 PR，还没有人重建过为什么要做这个改变，而评审者是第一个尝试的人。正如论文所说的，审查"不是为了恢复缺失的意图而构建的"。令人欣慰的是，缺失的意图是可以恢复的：推理确实存在过，我们只是丢弃了它。让 AI 智能体说明它试图做什么以及它排除了什么，将其作为决策日志捕捉到 PR 上，重建成本的大部分就会消失。这是一个工具问题，而工具问题是可以解决的。

这些都不能让"让 AI 审查 AI"本身成为完整的答案。具有不同先验的第二个模型确实能捕捉真实的 bug，而且能捕捉很多，这就是为什么你应该运行一个。它不提供的是人类对于这是否是首先应该构建的正确变更的判断。这种判断仍然属于一个人，而它恰好是工作中最有趣的部分，值得保留的部分。

工具很好，但不总是因为它们宣传的原因

当前的 AI 审查工具确实很好，它们有时在相同的行上标记的内容不同，所以正确的做法不是选择最好的一个，而是运行两个以不同方式构建的。

专门的 AI 审查工具现在很好，我认为你应该在所有东西上运行至少一个，包括副项目。CodeRabbit 是部署最广泛的，在 2026 年 1 月至 2 月的独立 Martian 基准测试中排名靠前，F1 精度约为 49%，召回率在该领域最佳。Greptile 牺牲精度以换取召回：在一项基准测试中的 bug 捕捉率约为 82%，而 CodeRabbit 为 44%，代价是更多的假阳性。Anthropic 的代码审查报告不到 1% 的发现被他们的工程师标记为不正确，而我实际会向经理展示的数字是：它将他们内部接受实质性审查的 PR 比率从 16% 提高到 54%。那些曾经只是被扫一眼和批准的长尾变更现在得到了某个东西的仔细阅读。

我今年看到的最有用的结果不是来自供应商。一位工程师在 3 周半内在 146 个真实 PR 和 679 项发现上并行运行了四个审查工具：CodeRabbit、Sentry Seer、Greptile 和 Cursor BugBot：

在 617 个不同的标记位置中，93.4% 恰好被四个工具中的一个捕捉到。6% 被两个捕捉到。几乎没有被三个捕捉到。一个都没有被全部四个捕捉到。

这四个工具从未在同一行上标记过。每个都在不同的问题类别中表现出色：Greptile 在正确性和架构上接近零假阳性，CodeRabbit 有最广的网络和一键修复，Seer 在生产故障严重性上表现最好。这是对抗性审查论证在真实代码库上而不是在论文中的演示。异质性就是全部要点。四个相同模型的副本就是一个审查者有一张更大的发票，而四个真正不同的审查者会发现一组没有任何单个成员（包括人类）能单独找到的 bug。

在实践中：不要纠结于哪个工具最好，根本没有。在高风险的一端，运行两个具有明显不同特征的工具（上面的实验将 Greptile 用于日常正确性，Seer 用于生产故障严重性，几乎没有重叠）。如果你是独立开发者，一个好的审查工具加上真正的测试已经足够了。无论营销怎么说，在你自己的代码上衡量它，因为这些结果中的每一个都特定于特定的代码库，你的也将如此。

我们应该让 AI 审查更多吗？

机器已经在审查比你更多的代码了。唯一真正的决定是你是否有目的地这样做，你保留的人工数量应该与你的影响范围相适应。

我不断听到一个问题，一年前会被视为异端邪说，现在却来自经验丰富的工程师：机器应该进行更多的审查，也许大部分审查？我不再认为这是一个愚蠢的问题。

令人不适的部分是 AI 审查确实有效。Anthropic 不到 1% 的发现被标记为错误，这些工具捕捉到人类直接跳过的 bug，他们在一天中的第三十个 PR 上不会感到疲倦，这正是人类最不可靠的时候。同时，人类明显跟不上：零审查合并上升了 31%，审查时间上升了三位数。在某种真实意义上，机器已经在审查比我们更多的代码了。诚实的框架不是"我们应该让 AI 进行更多审查"而是"AI 已经在做了，我们是否会有意识地这样做，或者让它在默认情况下发生，同时假装人类仍然阅读一切"。

循环工程加强了这一点。循环的前提是你停止成为提示 AI 智能体的人，而是构建一个提示它的系统，这个系统的一个核心部分是一个判断者：一个决定工作是否完成后再继续的 AI 智能体。评审者是下一个被故意设计出内部循环的角色。我们花了一年时间自动化编写，循环现在自动化检查，人类不断被推向上层和外层。"人类在哪里停留"不是一个研讨会问题，它是你每次连接一个循环时决定的东西，无论你是否意识到你在做出决定。

我目前的立场是，我宽松地持有这个：答案不是"人类阅读每一行"。那已经结束了。体积结束了它，任何坚持否则的人都在描述一个不再存在的世界。但它也不是"让循环自己审查然后走开"。当一个 AI 智能体编写代码，另一个审查它，第三个判断它，你有一个模型的闭合循环，具有广泛相关的盲点，特别是当他们来自同一个家族、自信地在相同的地方同意的时候。一个没有任何人的自信"看起来不错"是借来的自信：系统的确定性变成了你的，没有人实际理解任何东西。循环可以非常确定和非常错误，没有人类留下来告诉区别。

所以人类并未离开，而是上升到更高的层级。你不再审查每一个 diff，而是开始拥有那些模型无法转移的部分。责任感，因为你无法在凌晨 3 点对一个模型进行寻呼。判断这是否是应该构建的正确变更，这有别于代码是否正确的判断。高影响范围的关键点，其中出错代价昂贵。还有尴尬的那一个：没人指定的行为，因为模型审查存在的代码，很少标记出没人想到要写下来的需求，这仍然是一个我不指望很快能填补的人类形状的缺口。循环中的人变成了循环上的人：抽样、抽查和审计系统，而不是阅读每个 PR，把你有限的注意力花在出错真正会造成伤害的地方。

这已经是我在自己的项目（包括现在一天内收到的 PR 比我一个晚上能仔细阅读还多的开源项目）中的工作方式。我让 Claude Code 或 Codex 来处理一批传入的 PR，要求进行首次通过：高层次地阅读什么看起来可以安全合并、什么需要更多工作，什么是真正的高风险。我不会基于结果自动合并，也不会懒惰地合并它批准的任何内容。它给我的是分配注意力的方法。我可以花几分钟确认它认为低风险的变更，把真正的、仔细的时间用在它标记为危险的变更上。重要的细节是，这不是我的旧审查时段变快了一点。这是一个不同形状的时段，在我现在处理的量级下，这是队列保持可管理状态的主要原因。

Codex 和 Claude Code 给我一个首次通过、按风险排序的一批 PR 阅读。分类才是帮助。合并决定仍然是我的。

同样这一步的更极端版本是 Kun Chen，一位前 Meta L8 级工程师，现在作为独立开发者每天大约发送 40 个 PR，已基本停止了代码审查。容易驳斥这一点，除了他是 L8，在这个他停止做的事情上异常擅长，这正是有趣之处。他并行运行 20 到 30 个智能体，把他的工作转向了计划：他预先写详细的计划，智能体针对这些计划运行数小时，他说计划质量决定了他们能运行多长时间而不需要人工干预。这是我上面用最纯粹的形式描述的举动。值得精确说明实际发生了什么，因为他并没有停止验证。意图并未消失，他在计划中自己写下来了，所以"第一个人类曾看过这个"的问题被半解决了：一个人确实理解了为什么，只是提前而不是之后。他也没有在没有安全网的情况下工作，他建立了一个自动审查门（他称之为 No Mistakes），在代码合并前检查，当智能体卡住时他也保持升级。人类在代码存在之前进行昂贵的思考，机器在之后进行逐行检查，这可能就是这将向哪里发展的样子。

但他是一个没有大型团队也没有充满陷阱的十年老系统的独立开发者。使 40 个 PR 每天不审查对他有理性的确切条件是大多数读者没有的条件。把他的工作流复制到一个为许多用户发货的团队上，你就在你自己的仪表板上重现了 Faros 的数字。他没错，他只是在频谱的一个特定端点很远的地方。

这又回到了频谱这个问题。独立且无用户：让 AI 审查几乎全部是 2026 年可防御的立场，你不应该对此感到内疚。为许多人维护大型事物：让机器处理首次通过、第二次通过和无聊的 90%，但在负载承载路径上保持真正的人，不要让循环在任何可能伤害人的东西上完全闭合。你保持多少人是一个旋钮，你按爆炸半径设置它，不是按内疚。

停止以相同深度审查所有内容。只在出错代价昂贵的地方花费稀缺的人类注意力，让廉价的确定性门和 AI 审查者处理其余的。

组织理念是将审查工作与出错成本相匹配，尽可能提前推动廉价的确定性工作，为只有人类才能做的事情保留人类注意力。

按风险分级，不按作者。配置变更应得到 linter 和一瞥。支付路径应得到完整堆栈：类型、测试、两个不同的 AI 审查者、拥有该系统的人，以及安全通过。不要在样板代码上花费繁重的审查，也不要因为测试是绿色就通过身份认证变更。分层方法无处不在；改变的是给定 diff 必须通过多少层。

快速失败昂贵的尾部。对于被智能体 PR 淹没的团队来说，最有用的最近发现是《审查工作的早期阶段预测》（2026 年 1 月），研究了 33,707 个智能体创作的 PR。智能体擅长小的、定义明确的变更，大约 28% 的变更几乎立即合并，但一旦收到主观反馈，它们就倾向于"消失"，放弃审查实际上是什么的来回往复。（一篇伴随的 2026 年论文发现评审者放弃占被拒绝的智能体 PR 的 38%。）研究人员建立了一个"断路器"，它从文件类型和补丁大小等廉价信号在人类查看前预测高维护 PR，而且效果很好。提前对智能体 PR 进行分类，快速跟踪平凡的，不要让一个人花一个小时在智能体一旦你推回就会放弃的分散变更上。

提高你甚至会审查什么内容的标准。被埋没的修复不是锁定仓库，而是拒绝审查没有证据的变更。在审查前要求：一份变更用途声明、一个不是 3,500 行且没有注释的 diff、测试输出，以及它实际运行的证明。这是你停止成为第一个阅读代码的人类的方法。你把意图重构工作推回给提交它的人，在那里成本低，而不是自己吸收，在那里成本高。

刻意保持 PR 小。智能体 PR 运行得很大，在 Faros 数据中平均大 51%，而审查者参与是最强的预测因素之一，即 PR 是否合并。一个大的不可审查的 PR 要么被彻底拒绝，要么更糟，被草率通过。指示你的智能体生成小的提交。一个人类可以实际阅读的 diff 现在是一个设计约束，而不是礼貌。

比代码更仔细地阅读测试变更。这是要监视的智能体失败模式。智能体改变行为，然后通过重写断言以匹配新的、破损的行为来"修复"测试。200 个编辑过的测试的绿色检查在你确认编辑是正确的之前意味着什么。将任何重写许多测试的 diff 视为标志并首先阅读那些。Mut