编码智能体将工程中的难点从编写代码转移到了是否信任代码的决策上，这使得代码审查成为当下软件工程中最具杠杆效应的技能，因为过去的那个快乐意外已不复存在。2026年的数据趋于一致：Faros AI 对 22,000 名开发者的研究发现，代码变更率飙升 861%，每位开发者的缺陷率从 9% 上升到 54%，审查持续时间增加 441%，零审查合并增加了 31%；而 GitClear 的数据则显示，原始输出量增加了 4 倍，但交付价值只提升了约 12%，这一差距用一句话概括就是审查问题。

智能体代码审查

现在的编码智能体已经非常出色，并且还在快速进步。有趣的结果是，工程中的难点从编写代码转移到了是否信任代码的决策上，这使得代码审查成为当下软件工程中最具杠杆效应的技能。你的处理方式很大程度上取决于你的身份：一个没有用户、独自开发的开发者，与一个维护着十年老应用的团队，面对的是截然不同的问题。

我对智能体工程从未如此乐观过。这些智能体确实很优秀，每个月都在变得更好。在普通的一周里，我现在能交付一些一年前在相同时间内我根本不敢尝试的东西。这篇文章旨在勾勒出那些有价值的工作转移到了哪里——因为它们确实转移了——而大多数团队还没有完全跟上这个变化。

过去，代码审查之所以有效，是因为相对速度上的一个偶然巧合。资深工程师阅读代码的速度比初级工程师编写代码的速度快，因此审查无需刻意设计就能跟上节奏，而团队成员在阅读彼此差异的过程中，也自然而然地吸收了对系统整体架构的理解。这其中很多并非刻意为之。它源于一个简单的事实：编写代码是缓慢且昂贵的一环，而阅读代码则是廉价且快速的。

这个事实已不再成立。一个智能体在我阅读这段话的时间内，就能生成数千行通常质量不错、格式规范的代码，而人类的阅读速度自从我们开始盯着屏幕工作以来，几乎没有改变。因此，瓶颈向下游转移了，转移到了那个没有变快的环节：让人确信这个变更是正确的。我不认为这是一种损失。这正是当下软件工程中最值得做好的杠杆点，也是我今年投入最多精力的地方。

这里有一个有趣的转折，它将塑造本文的其余部分。那些生成大量额外代码的同一工具，也是我用来跟上这些代码的最强帮手。 在我自己的项目中，包括那些流行的开源项目，我现在会让 Claude Code 或 Codex 处理一批涌入的 Pull Request，让它们帮我分类排队。这确实改变了我的时间分配方式。所以，这并不是一个反 AI 的论点，我稍后会详细介绍我具体如何使用它。

这也不是一个数据堆砌，更不是又一轮关于“让模型来写代码是好事还是手艺的终结”的争论，因为这种框架毫无意义。唯一能经得起真实代码库检验的回答是：这完全取决于你的身份。一个用“氛围编程”搞着最多只有十几个人会用的副项目的开发者，与一个为了让一个十年老企业系统再撑一个季度而努力的团队，它们几乎没有值得提及的共同约束。市面上大部分建议，实际上都是这两种人中的一种在告诉另一种人该如何生活。

2026年的数据到底说明了什么

AI 带来的生产力提升是真实的，但原始产出夸大了这种提升：大约四倍的代码量，只换来了十分之一不到的交付价值增量。这两个数字之间的差距就是审查工作，而这正是为何审查现在成为杠杆所在。

过去几年，这还只是个例和争论。现在，它已经在规模化层面上得到了测量，由那些没有共同议程、甚至在多个案例中存在商业竞争的组织完成，而测量结果都指向同一个方向：AI 大幅提升了产出，但也同时拉低了质量和可审查性。

Faros AI 对 4,000 个团队中的 22,000 名开发者进行了监测，追踪了团队从低 AI 采用率过渡到高 AI 采用率时发生的变化。这是 2026 年 3 月的数据，几乎是最新的。积极的一面是真实且值得明确说明的：开发者合并了更多的 PR，完成了更多工作，每位工程师的吞吐量也提升了。然后是报告中的其他发现：

• 代码变更率上升了 861%
• 事件与 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 使用群体中。四倍代码量与十分之一价值之间的差距，用一句话概括就是审查问题。

GitHub 报告称，Copilot 审查现已运行超过 6000 万次，在不到一年的时间里增长了 10 倍，并且平台上超过五分之一的审查涉及智能体。这不再是一种小众做法。这就是当下代码被制造出来的方式。

四个数据集，四种方法，一个结论。我们将机器速度的输出注入到为人工速度构建的系统中。瓶颈并没有消失；它转移到了验证环节，而审查正是为此买单的地方。

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

一个变更需要多少审查，几乎完全取决于其影响范围，而你读到的大部分建议，都来自一个在非常不同的影响范围内操作的人。

上述几乎所有令人担忧的数据都来自企业遥测数据以及不堪重负的开源维护者。如果这是你的情况，那这些数据就完全真实。如果你是一个人，发布一个只有少数几个人会运行的东西，那么其中大部分对你来说根本不适用，你也不应该为此感到不安。

决定你处于什么位置的三个变量：

• 影响范围：出问题时会发生什么？没什么事，或者愤怒的用户、金钱损失以及 PII 泄露的风险。
• 代码存活时间：一个下周可能重写的、用完即弃的原型，还是一个需要维护多年的代码库。
• 需要理解它的人数：只有你一个人，把整个系统记在脑子里，还是一个需要长期共同维护的团队。

用这三个变量去评估同一个差异，你会发现“好的审查”意味着完全不同的东西。

如果你是一个在无用户的绿地项目上独自工作的开发者，那么审查的第二个工作——在团队中分发知识——对你来说并不存在。你就是团队。

合理的做法是：重度依赖测试和自动化，审查那些真正重要的部分，对其他的则从轻处理。当代码可能一个月后就不存在，并且出问题也不会有人在凌晨 3 点被叫醒时，重复和变更的成本要低得多。但有一个很多人痛苦的教训：这只在测试真实有效时才成立。在没有安全网的情况下跳过审查，并没有消除工作，而是以更高的代价推迟了它，而且当没有人可以提出反对意见时，标准就会下滑。没有用户，只是允许你推迟审查。它并不是允许你跳过验证。

然后项目有了用户。这是危险的中间地带，而且这种转变通常很难被及时察觉。审查捕捉错误的作用突然变得重要了，因为错误现在会伤害到人。同时，其知识共享的作用也开启了，因为现在不再是你一个人了。团队往往会把独行侠时期的习惯多延续几个月，然后就会出现一次事后复盘，Faros 的数字不再只是图表，而是变成了他们自己的仪表盘。

最远端是一个拥有大量用户和旧代码库的大型组织。在这里，每一个令人担忧的数据都会全力发挥作用。一个没人理解的变更，是一种理解债务，它会变成某人的待命事件。审查同时承担着多项工作，而智能体输出的数量悄然压垮了所有这些工作。Faros 关于成熟团队的发现，正是直指这里。

所以，重点不是“企业应该谨慎，独立开发者可以放松”。而是审查的目的会根据你的处境而改变，因此规则也必须随之改变。把企业那套锁定、多智能体、需要证据的流水线，强加到一个两个人的原型上，只会增加摩擦而没有好处。在一个支付系统上运行“测试通过，就上线”，就是构建了一个带有绿色勾的事件生成器。这个领域里的大部分糟糕建议，都是这个光谱上一个位置的人给另一个位置的人开的处方。

审查现在实际上是为了什么

审查本是为了检查作者的推理、捕捉错误，以及与团队共享知识。智能体确实会推理，但这种推理通常被丢弃，而不是附加到代码上，因此审查者必须重建一个从未出现在差异中的理由。好消息是：这是一个工具问题，而捕捉推理过程会使审查变得容易得多。

这是真正改变的部分，我认为它被低估了。

当人类编写代码时，意图是自然附带的。推理过程、权衡并放弃的替代方案，都在作者的脑海中，而审查就是你在检查那些推理。现代智能体确实会推理，通常是可见的，产生思考轨迹、权衡选项、边做边解释。但问题是，这种推理通常在差异生成的那一刻就被丢弃了。它很少被捕获，很少附加到 PR 上，而且无论如何，这只是智能体关于如何实现任务的推理，而不是人类关于“这到底是不是正确的任务”的判断。因此，审查从检查你面前的推理，转变为重建从未被写下来的意图，这更困难、更慢，而我们却一直对审查时间增加了 441% 感到惊讶。

2026 年的一篇论文《AI Slop 与软件公用》分析了 15 个 Reddit 和 Hacker News 讨论串中的 1,154 条帖子，开发者们在这些帖子里讨论“AI 垃圾内容”。一位开发者的评论引起了我的注意：审查一个智能体的 PR 让他们成为“第一个看到这段代码的人类”。

这直接指出了解决方案。在正常的审查中，作者已经理解了变更，你只是在检查他们的工作。而对于智能体 PR，还没有人重建了“为什么”。审查者是第一个尝试这样做的人。

正如那篇论文所说，审查“本不是为了恢复缺失的意图而构建的”。令人鼓舞的是，缺失的意图是可以恢复的：推理过程是存在的，我们只是丢弃了它。让智能体陈述它试图做什么、排除了什么，并作为决策日志附加到 PR 上，那么大部分重建成本就会消失。这是一个工具问题，而工具问题是可以解决的。

但这并不意味着“让 AI 审查 AI”本身就是一个完整的答案。一个具有不同先验知识的第二个模型确实能捕捉到真正的错误，而且能捕捉到很多，这就是为什么你应该运行它。但它无法提供的是，关于“这到底是不是应该构建的正确变更”的人类判断。这种判断仍然由人来做，而且这恰好是工作中最有趣的部分，是值得保留的部分。

工具很好，但未必是因为它们宣传的理由

当前的 AI 审查工具确实不错，而且它们偶尔不会标记同一行代码，所以正确的做法不是挑选最好的一个，而是运行两个构建方式不同的工具。

专门的 AI 审查工具现在很出色，我认为你应该至少运行你的主要编码智能体（如果不是专门的审查智能体），覆盖所有项目，包括副项目。

CodeRabbit 部署最广泛，在独立的 Martian 基准测试（2026 年 1 月至 2 月）中，在 F1 分数上名列前茅，精确率约 49%，召回率在该领域最高。Greptile 牺牲了精确率换取召回率：在一个基准测试中，错误捕获率约 82%，而 CodeRabbit 为 44%，代价是更多的误报。Anthropic 的 Code Review 报告称，其工程师将不到 1% 的发现标记为错误，而我会真正展示给经理看的数据是：它将内部 PR 获得实质性审查的比例从 16% 提高到了 54%。那些以前只会被扫一眼就通过的、占大多数的变更，现在得到了某种形式的认真阅读。

我今年看到的最有用的结果并非来自供应商。一位工程师在 146 个真实 PR 上并行运行了四个审查工具：CodeRabbit、Sentry Seer、Greptile 和 Cursor BugBot，在三周半的时间里产生了 679 个发现：

在 617 个不同的标记位置中，93.4% 仅被四个工具中的其中一个捕获。6% 被两个捕获。几乎没有一个被三个捕获。没有一个被全部四个捕获。

这四个工具从未同时标记过同一行代码。每个工具在不同类型的问题上表现出色：Greptile 在正确性和架构方面几乎零误报；CodeRabbit 覆盖最广，提供一键修复；Seer 在生产故障严重性方面表现最佳。这是在真实代码库上展示了对抗性审查的论点，而不是在纸上。异构性才是关键。四个相同模型的副本只是一个拥有更大账单的单一审查者，而四个真正不同的审查者能够发现任何一个单一成员（包括人类）都无法单独找到的一组错误。

在实践中：不要为寻找唯一的最佳工具而烦恼——没有这样的工具。在高风险的一端，运行两个具有明显不同特性的工具（上述实验中将 Greptile 用于日常正确性，Seer 用于生产故障严重性，几乎零重叠）。如果你是独立开发者，一个好的审查工具加上真正的测试就足够了。而且，无论营销怎么说，在你的代码上衡量效果，因为这些结果中的每一个都针对特定的代码库，你的代码库也会如此。

我们是否应该让 AI 审查更多的东西？

机器已经在审查你的代码的更多部分了。唯一剩下的真正决定是，你是否主动这样做，而你保留的人工审查量应该与你的影响范围成比例。

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

令人不安的部分在于，AI 审查确实有效。Anthropic 发现的情况中，只有不到 1% 被标记为错误；这些工具能捕捉到人类直接读过去的错误，而且它们不会在第 30 个 PR 上感到疲倦。