Agent 代码评审【译】

原文链接： https://addyosmani.com/blog/agentic-code-review/

Coding Agent 如今的表现极其出色，而且迭代速度极快。

有趣的是，软件工程的难点从“如何编写代码”转移到了“是否信任这些代码”，所以代码 review 成了当下软件开发中最关键的技能。

如何进行 review 很大程度上取决于你的身份：一个没有用户的独立开发者，与一个维护着十年老系统的团队，他们要解决的问题是完全不同的。

我对 Agent 辅助工程前景的看法非常乐观。Agent 确实非常出色，并且每个月都在变得更好。我现在发布的新功能，搁在一年前，是绝对无法在相同时间内完成的。

这篇文章是对“工作进展变化”的梳理与探讨，因为这些工作重心确实发生了转移，而大多数团队还没有完全跟上这种节奏。

代码 review 在过去之所以如此有效，是得益于阅读与编写速度差异的巧合。资深工程师阅读代码的速度要比初级工程师编写代码的速度快，因此 review 的节奏也能跟得上开发进度。

整个团队在阅读彼此 diff 的过程中，自然而然地理解了系统的架构设计。这种机制在很大程度上并不是刻意规划的结果，它仅仅源于一个事实：编写代码是缓慢的，而阅读代码是快速的。

但这个前提现在已不复存在。

Agent 可以在我读完这段文字的时间内，生成一千行通常相当扎实且格式规范的代码；然而，自从人类开始靠盯着屏幕谋生以来，我们的阅读速度几乎没有发生任何改变。因此，瓶颈转移到了那一步唯一没有变快的环节：让人确信所有变更是正确的。

我不觉得这是一种损失或限制，相反，这正是目前软件开发中最值得投入和提升的关键点，也是我今年倾注了最多精力的领域。

我发现了一个令人欣喜的转折，也是本文余下篇幅的核心：那些用于生成海量额外代码的工具，恰恰也是我用来跟上代码生成速度的最佳帮手。

在我自己的项目（包括一些热门开源项目）中，我现在会使用 Claude Code 或 Codex 对一批待处理的 PR 进行初步筛查和分类，这实实在在地改变了我的时间安排。所以，这篇文章绝对不是一个反对 AI 的论调，稍后我会详细解释我是如何使用它的。

2026 年的数据究竟表明了什么

AI 带来的生产力提升是真实的，但单纯的代码产出量夸大了这种提升：代码量大约增加了四倍，但交付的实际价值只增加了约十分之一。

这两个数字之间的差距就是 review 工作，这也正是为什么 review 是如今的核心所在。

在过去的几年里，这还只是传言和争论。而现在，这一现象已经被许多没有共同利益关联、甚至在某些情况下存在商业竞争关系的机构进行了大规模的量化评估。

评估结果都指向同一个方向：AI 显著推高了代码产量，但同时降低了代码质量和可读性。

Faros AI 对 4000 个团队的 22,000 名开发人员进行了跟踪调查，记录了团队在从低 AI 采用率转向高 AI 采用率时的变化。这是 2026 年 3 月的数据，非常具有时效性。

优点是真实存在且值得明确指出的：开发人员合并的 PR 明显增多，完成了更多的工作，每个工程师的输出量也有所上升。

然而，报告的其它部分指出：

• 代码流失率（code churn）上升了 861%
• 故障与 PR 的比率上升了 242.7%
• 每个开发人员的缺陷率从 9% 飙升至 54%
• review 时间中位数上升了 441.5%，首次 review 等待时间和平均 review 时间均几乎翻倍
• 未经任何 review 直接合并的 PR 比例增加了 31.3%

最后一个数据是我觉得最难忽略的，因为这并不是开发者的主动选择。

没有任何人决定停止 review，只是因为他们无法跟上代码量，从而导致代码开始在未被阅读的情况下直接合并，并逐渐成为常态。

我一直在关注是，那些拥有成熟、自律工程实践的团队受到的影响与其它任何团队一样严重。精心优化的流程并不能保护他们，因为代码量的增长速度远远超出了任何现有流程的设计承受范围。

需要始终注意的一点是：CodeRabbit 和 Faros 都是该市场的服务销售商，因此他们的叙事视角并不是完全中立的。但这并不意味着数据有误，因为不同来源的数据所呈现的效应规模非常大且保持一致，但阅读此类厂商研究报告时仍需考虑这个背景。

CodeRabbit 在 2025 年 12 月研究了 470 个开源 PR（其中 320 个由 AI 协同编写，150 个完全由人类编写），发现 AI 引入的变更所包含的问题大约是人类的 1.7 倍：逻辑和正确性问题增加了约 75%，安全漏洞的出现概率是人类的 1.5 到 2 倍，可读性问题更是翻了三倍不止。他们的 AI 总监 David Loker 将其描述为“企业必须积极缓解的、可预测且可量化的弱点”。“可预测”是这里的关键词。这些都是已知的、可定位的缺陷，这其实是个好消息：这意味着无论是人工还是自动化的 review 流程，都可以直击这些痛点。

GitClear 也有一些很有意思的数据。在他们截至 2025 年的生产力数据中，每天使用 AI 的开发者产出的原始代码量是不使用 AI 者的约 4 倍，但如果与他们自己一年前的产出相比，实际的生产力提升仅为 12% 左右。你生成了大约 4 倍的代码，却只带来了约十分之一的交付价值，而人类仍然需要 review 完这全部 4 倍的代码。难能可贵的是，GitClear 的 Bill Harding 明确指出，即使是这 12% 的增长，也存在一定的选择性偏差，因为实力更强的开发者往往更集中在 AI 使用群体中。4 倍的代码量与十分之一的价值提升之间的差距，直接点出了 review 面临的困境。

GitHub 报告称，Copilot 评审现已运行了超过 6000 万次，在不到一年的时间里增长了 10 倍，并且该平台上超过五分之一的 review 都有 agent 参与。这已经不再是少数人的小众尝试，而是现代代码生成的常规生产方式。

四份数据来源，四种不同的调研方法，得出了同一个结论：我们将机器速度的产出倾倒进了一个为人类工作速度而设计的系统中。

质量瓶颈并没有消失，它只是转移到了验证环节，而代码 review 就是需要为此买单的地方。

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

一次代码变更需要进行多少 review，几乎完全取决于它的影响范围，而你读到的大多数建议，都是由身处完全不同影响范围的人写出来的。

上面那些令人警惕的数据，几乎全部来自企业遥测和被海量 PR 淹没的开源维护者。如果这正是你所处的环境，那这些问题是完全真实的。但如果你是单枪匹马在开发一款只有少数几个人会运行的产品，那么这些问题中的绝大部分对你根本不适用，你大可不必为此感到焦虑。

有三个因素决定了你所处的位置：

• 影响范围：代码崩掉时会发生什么？是毫无影响，还是会导致愤怒的用户、资金损失以及个人身份信息泄露。
• 代码的生命周期：它是一个下周就可能重写并扔掉的原型，还是一个需要维护数年的基础架构库。
• 需要理解它的人数：是只有你一个人在脑海中掌控全局，还是一个团队需要随着时间推移共同分担维护职责。

将同一个 diff 带入这三个因素中进行衡量，“好的 review”所代表的含义会截然不同。

如果你是独自在一个没有用户的新项目中工作，那么在团队中分发系统知识，对你来说就不存在。因为你就是团队本身。

此时合理的做法是极度依赖测试与自动化验证，只审查那些真正关键的部分，对其余部分采取较宽松的标准。当这段代码在一个月后可能都不复存在，且崩掉时也没有人会在凌晨 3 点被呼叫起来排查时，代码重复和频繁变更的代价其实非常低。

不过这里有一个坑：只有在测试是真实有效的情况下，这种做法才行得通。在没有安全标准的情况下跳过 review 并不会减轻工作量，反而是以更高的代价延迟了它的出现。而且在没有人把关和制衡时，代码标准会逐渐滑坡。

“没有用户”仅仅是推迟 review 的条件，但它绝不是跳过自动化验证的标准。

接着，项目开始有了用户，这是最危险的过渡期。代码审查捕获 bug 会变得非常重要，因为 bug 会影响到真实用户，同时，知识共享的能力也应随之启动，因为开发人员已经不再只有你一个人。

团队往往会把独立开发者时期的习惯保留得过久，直到某次重大故障复盘。

最极端是拥有老旧代码库和海量用户的大型组织。在这里，每一个令人警惕的变量都蕴含着强大的破坏力。一个没有人理解的变更就是理解债务，它指不定什么时候就会变成某位值班人员的线上故障。

此时的 review 需要同时兼顾多项职责，而 agent 爆发式的产出在无形中摧毁了这一切。Faros 报告中关于成熟团队的数据，正是针对这种场景。

核心观点并非“企业应该谨慎，独立开发者可以放松”，而是 review 的目的会随着你所处的阶段而变化，其规则也必须随之调整。

如果将一个大型企业中严格限制、多 agent 协作、强调佐证的流水线硬套在一个两人的原型项目上，除了徒增工作量之外毫无益处。而在一个支付系统上直接运行“测试通过就上线”，无异于在系统上搭建一个故障制造机。

如今 review 的真正价值是什么

Review 最初的设计初衷是为了检查作者的推理逻辑、捕获 bug 并与团队共享经验。

Agent 确实会进行推理，但这些推理过程在生成 diff 后通常会被丢弃，没有与代码关联保存。这就导致 reviewer 必须去重建那些从未被记录在 diff 中的设计逻辑。

好消息是：这只是一个工具层面的问题，如果能捕获这些推理过程，review 将会变得极其轻松。

**人类编写代码时，我们真实意图是自然流露出来的。**那些在作者脑海中权衡过、被采纳或放弃的替代方案，都是 review 时需要检查的推理逻辑。

现代 agent 确实会进行推理，且常常是以可见的形式进行。它们会生成思考链路、权衡不同的选项，并随时解释自己的思路。

然而问题在于，一旦 diff 生成，这些推理过程通常就会被立即丢弃。它们极少被捕获，更不用说关联到 PR 上了。而且，这通常只是 agent 对如何实现这一任务的推理，而不是人类对于“这从一开始是不是一个正确的需求”的评判。

因此，review 的重心已经从“检查摆在你面前的推理逻辑”转变为“重建未被记录下来的意图”，这显然更难也更慢。我们也就不难理解为什么 review 的耗时会延长 441% 了。

2026 年的一篇论文《AI Slop and the Software Commons》分析了 Reddit 和 Hacker News 上 15 个关于开发者讨论“AI 垃圾代码（AI slop）”的 1154 篇帖子。其中一位开发者的一句话引起了我的注意：review 一个 agent 提交的 PR 让他觉得自己成为了“有史以来第一个亲眼看到这段代码的人类”。

这恰恰指向了问题所在。在正常的评审中，作者理解变更的目的，所以你只需要检查他们的工作。但在 agent 提交的 PR 中，没有人去梳理其中的前因后果，审查者是第一个试图弄清这一切的人。

正如论文所指出的，传统的 review 机制“并不是为了还原丢失的开发意图而设计的”。

但值得庆幸的是，这些丢失的意图完全可以被找回：因为推理过程原本是存在的，只是我们主动丢弃了它。我们只需让 agent 说明它打算做什么、排除了哪些方案，并把这些信息作为决策日志记录在 PR 中，重建意图的巨大成本就会随之消失。

这本质上就是一个工具层面的问题，而工具层面的问题总是可以解决的。

但这并不意味着“让 AI 去 review AI”本身就是一个完整的解决方案。另一个具有不同知识的模型确实能捕获到很多真实的 bug，这也是你应该运行这样一个模型的原因。但它无法提供人类的商业直觉，判断这到底是不是一个从一开始就值得去做的变更。

这个决定权仍然牢牢掌握在人手里，而这恰恰也是软件工程中最有趣、最值得保留的部分。

工具确实好用，但需根据自身情况进行选择

目前的 AI review 工具确实很出色，它们有时发现的问题各不相同，因此正确的做法不是去挑选一个最好的，而是同时运行两个架构不同的工具。

现在专门的 AI review 工具已经相当成熟了，我认为即使不在所有的项目中运行专门的 review agent，也至少应该让你主要的 coding agent 跑一遍。

CodeRabbit 是部署最广泛的工具，在 2026 年 1 至 2 月的独立 Martian 基准测试中，其 F1 分数名列前茅，拥有约 49% 的精确度以及该领域内最好的采纳率。

Greptile 则是用捕获量换取采纳率：在某项基准测试中，它的 bug 捕获率约为 82%，而 CodeRabbit 则是 44%，代价是会有更多的误报。

Anthropic 的 Code Review 报告称，其工程师判定其检测结果中只有不到 1% 是错误的。而我最想展示的数据是：它将内部获得实质性 review 的 PR 比例从 16% 提高到了 54%。过去那些只被扫一眼就直接点同意的长变更，现在终于有一些系统来认真阅读了。

我今年看到的最有价值的评估结论并非来自任何厂商。而是一名工程师在三个半星期里并行运行了四个 reviewer（CodeRabbit, Sentry Seer, Greptile 和 Cursor BugBot），分析了 146 个真实的 PR 以及 679 个发现点：

在 617 个不同的标记点中，有 93.4% 的问题仅被这四个工具中的其中一个捕获。6% 的问题被其中两个捕获。被 3 个工具共同捕获的几乎为零。没有任何一个问题是被这四个工具同时发现的。

这四款工具从未在同一行代码上给出相同的标记。每个工具都有其擅长的特定问题类型：

• Greptile 在代码正确性和架构设计上的误报率几乎为零
• CodeRabbit 的覆盖网最广，且提供一键修复
• Seer 则在预测生产环境故障的严重性上表现最佳

这是在真实的代码仓库上证明了“对抗性 review”的价值。

同一模型的四个副本只是一个账单金额更大的单个 reviewer，而四个完全不同的 review 工具，则可以发现任何单个 review 机制（包括人类在内）都无法单独找到的一系列 bug。

在实践中：不要纠结于挑选那个唯一最好的工具，因为根本没有。在涉及重大利益的场景中，建议同时运行两个特性完全不同的工具（上述实验将负责日常正确性检查的 Greptile 与防范生产环境故障的 Seer 组合使用，几乎没有任何重复检测）。

如果你是独立开发，那么一个好用的 reviewer 加上测试就足够了。不管营销人员怎么吹捧，务必在自己的代码库上进行评估，因为所有的测试结论都特定于某一个代码仓库，你的系统也一样。

我们是否应该将更多的 review 工作交给 AI？

机器实际上已经审查了你大部分的代码，甚至超过了你亲自审查的比例。目前唯一需要权衡的决定是，你是否要主动推行这一流程，以及你将保留多少人工把关的比例，而这应该根据变更的影响范围来进行动态调整。

我经常听到一些在一年前听起来不可意议的问题，而且是由资深的工程师提出来的：我们是否应该让机器承担更多的 review 工作，甚至可以说大部分工作？我不再认为这是一个愚蠢的问题。

AI review 的确行很有效。Anthropic 的检测结果中只有不到 1% 被标记为错误，这些工具能发现人类直接忽略的 bug，而且在审阅当天第 30 个 PR 时依然不会疲倦，而此时恰恰是人类最不可靠的时候。

与此形成鲜明对比的是，人类显然跟不上节奏：零 review 直接合并的数量增加了 31%，review 的等待时间也呈三位数增长。

在某种现实层面上，机器审查的代码量已经比我们人类要多了。因此，一个坦诚的提问不应该是“我们是否应该让 AI review 更多”，而是“AI 已经在这么做了，我们是要有意识、有规划地推行，还是假装人类仍在阅读一切，放任其默认发生”。

循环工程使这一点更加明确。它的前提是，你不再是那个不断向 agent 发送 prompt 的人，而是建立一个能够自动运行去 prompt 它的系统。而这个系统的核心是一个“裁判”，即一个决定当前工作是否完成、是否可以继续往下推进的 agent。

Reviewer 就是下一个被刻意设计并排除在循环之外的角色。

我们花了一年的时间把代码“编写”自动化，现在这些自动化循环又在把“校验”也自动化，人类正在被不断推向更外层和更高的维度。“人类应该留在哪个环节”并不是一个学术研讨题，而是你每次搭建自动化循环时都需要做出的决策，无论你是否意识到了这点。

我目前的看法是，答案可能不再是让人类阅读每一行代码。那个时代已经结束了。但它也不是直接让这个闭环自行评审然后我们就甩手不管。

当一个 agent 编写代码，另一个去 review，第三个去进行裁判判定时，你实际上是把一些拥有高度关联盲区的模型关在了一个闭环中（特别是当它们来自同一个模型家族时），它们会在同样的地方自信地达成一致。一个没有任何人类参与、仅仅依靠系统自信给出的“看起来不错”其实是虚假的信心。

系统的确定性直接成了你的确定性，但没有任何人真正理解了这里面的逻辑。这个自动化闭环可能会在表现出极度自信的同时犯下极其离谱的错误，而此时没有任何人类可以来纠正。

因此，人类并没有离开，而是上升到了一个更高的层级。你不再去 review 每一个 diff，而是开始真正掌控那些无法转交给模型的关键环节。责任分配至关重要。

“人类参与循环（human in the loop）”正在变成“人类把控循环（human on the loop）”。去抽查和审计这个系统，而不是事必躬亲地去阅读每一个 PR，从而将你有限的注意力倾注到那些出不起错的致命环节。

这已经是我在自己的项目（包括那些热门开源项目）中的工作方式，因为这些项目一天里收到的 PR 远超于我一个晚上能仔细看完的量。

我会指派 Claude Code 或 Codex 扫一眼一批进来的 PR，并让它给出初步评估：对看起来可以安全合并的部分、需要更多修改的部分以及具有高风险的部分进行归类。我并不会直接根据这个结果自动合并，也不会偷懒地直接放行它所批准的 PR。它带给我的最大帮助是进行精力的合理分配。

对于它认为低风险的变更，我可以只花几分钟进行确认；而对于它标记为危险的变更，我会投入真正专注且充足的时间去审阅。核心在于，这并不是把我原有的 review 时间稍微缩短了一点，而是完全重塑了这部分时间的使用形态。在目前我所需要处理的高强度任务量下，这是保证 PR 队列不至于彻底崩溃的核心原因。

这种做法更极致的版本是 Kun Chen（前 Meta L8 工程师，现在作为一个独立开发者，每天发布约 40 个 PR，正如他向 @petergyang 所透露的那样，他现在已经基本上不再 review 代码了）。

但值得关注的是，他曾是 L8 工程师，极其擅长这件事的他如今也不打算继续做了。他并行运行了 20 到 30 个 agent，并将精力转移到了“制定计划”上：他在项目前期编写极其详尽的实现方案，然后让 agent 针对方案自主运行数个小时；他表示计划的质量直接决定了它们可以在无人值守下安全运行多久。

这正是前文所描述的那种模式。我们需要精确理清这里应该发生什么，因为这意味着他并没有停止了校验。开发意图并没有凭空消失，因为是他自己亲手将其在计划中写了下来，所以“第一个亲眼看到这段代码的人”这一难题实际上已经解决了一半：人类确实理解了这个项目的因果设计，只不过这个过程发生在了开发前，而不是开发后。

同时，他也没有完全在没有保护网的情况下工作，他建立了一个自动化的 review 校验门槛，用于在代码合并前进行检测，而且当 agent 遇到瓶颈停滞不前时，他仍然作为最后的关键节点参与调试。

人类在代码编写前负责那些昂贵的设计思考，而机器则在事后去负责逐行把关。这很可能就是未来协作的基本形态。

他独自一人开发，没有庞大的团队，脚底下也没有铺满地雷的、已有十年历史的陈旧系统，这成了他每天免除 review 发布 40 个 PR 这一逻辑成立的基础条件，这也是绝大多数开发者并不具备的。

如果把他的工作流原封不动地照搬到一个面向庞大用户群体的开发团队里，你很快就会在自己的监控看板上重演 Faros 报告里的惨痛教训。

我们再次回到个人定位问题。

对于没有用户的独立开发：在 2026 年让 AI review 几乎所有的代码是一个完全立得住脚的选择，你大可不定有任何负罪感。

而对于维护着服务大众的复杂系统：让机器去处理初筛、复筛和 90% 的繁琐细节，但在那些承重柱级别的关键逻辑路径上必须保留真实的人类把关，绝不要让闭环机制全权决定任何可能会伤害到用户的生产环节。

保留多少人工参与度就像是一个刻度盘，你应该根据影响范围去调节它，而不是根据所谓的道德感。

到底应该怎么做

停止对所有内容进行相同深度的 review。把宝贵的人类精力倾注在出错代价昂贵的关键地方，而让廉价的确定性工具门槛和 AI reviewer 来处理剩下的事情。

其核心思路是让 review 的投入与出错的代价相匹配，将廉价且确定性的卡点检查尽早置前，并将人类的精力留给唯有人类才能胜任的任务。

**根据风险高低进行分层，而不是根据作者是谁。**一次配置文件的变更只需要配合 linter 并简单扫一眼；而一次核心业务逻辑路径的重构，则需要进行全面防护。不要把宝贵的重度 review 浪费在样板代码上，也不要因为测试通过就对一大笔代码变更直接放行。分层把关的原理在任何地方都是一样的；不同之处仅在于某一次 diff 需要跨越多少层防线。

**快速判断昂贵任务。**对于那些被 agent 生成的 PR 所淹没的团队来说，最近最有价值的研究是 2026 年 1 月发表的《Early-Stage Prediction of Review Effort》，该研究分析了 33,707 个由 agent 编写的 PR。Agent 非常擅长那些小而明确的局部改动，其中大约 28% 几乎可以立即合并；但是一旦它们收到比较主观的反馈，它们就很容易选择“隐身”，从而中断本应是双向沟通的 review 流程。（2026 年的另一篇配套研究发现，因作者放弃修改而导致 agent PR 被拒绝的比例高达 38%。）研究人员构建了一个“熔断器”，在人类介入之前，通过文件类型和 patch 大小等低成本的早期信号来预测哪些 PR 需要极高的维护精力，其实际运行效果非常显著。在前期就对 agent 提交的 PR 进行筛选分类，快速放行那些琐碎简单的改动，切忌让人类把一小时的时间浪费在那些 agent 一被挑战就直接选择摆烂放弃的庞大代码变更上。

**提高 review 的准入门槛。**解决被海量 PR 淹没的方法不是把 repository 完全锁死，而是拒绝 review 任何在提交时没有附带佐证的变更。在启动 review 之前，应强制要求：说清楚这次变更是为了解决什么问题、一份没有多达 3,500 行且毫无注释的 diff、测试通过的输出结果，以及代码实际运行过的证明。唯有如此，你才不会成为第一个去阅读这段代码的人类。你需要将“重建开发意图”的工作推回给提交代码的一方（在这个阶段成本非常低），而不是由自己作为 reviewer 去被动吸收（在此时代价极高）。

**刻意保持 PR 足够小巧。**根据 Faros 的数据，Agent 生成的 PR 通常偏大，平均要大出 51%，而 reviewer 的参与度和意愿是决定 PR 能否合并的最关键指标之一。一个过于庞大以至于无法理清的 PR 要么会被直接拒绝，要么（更糟糕地）被敷衍批准。请配置你的 agent 生成小粒度的 commit。一份人类能轻松阅读的 diff 如今是一个硬性的设计约束，而不是一种无所谓的客套礼仪。

**相比于实现代码本身，更需要仔细审阅测试文件的变更。**这是最需要防范的 agent 失败模式。Agent 修改了原有行为，随后通过重写断言来迎合新的、甚至是错误的行为，从而强行“修好”了测试。除非你确信这些改动是完全正确的，否则 200 个被修改的测试所给出的绿色对勾将毫无意义。任何重写了大量测试代码的 diff 都应该被视为黄色警告，务必优先阅读这部分。在此时，变异测试就体现出了它的价值：覆盖率只能告诉你某行代码有没有运行过，而变异测试则能告诉你，当这行代码出现错误时，现有的测试是否能够敏锐地捕捉到。

**将 CI 视为永不动摇的底线。**警惕 GitHub 提醒 reviewer 关注的那些反模式：删除了测试用例、跳过了 lint 规则检查、降低了覆盖率门槛、引入了在其它地方已经存在的重复 helper 函数，以及直接将不受信任的输入传入 prompt。最后一点需要特别强调，因为由 agent 开发的功能已经成为 prompt 注入漏洞（prompt injection）的新源头：如果一次代码变更直接将用户可控的文本输入到 LLM 接口中，而没有考虑这些文本对模型可能产生的误导指令，这种安全漏洞在 diff 中是看不出来的，它只会潜藏在后续流入的数据中。此外，agent 还会通过削弱 CI 的强度来让自己蒙混过关，这并不是出于恶意，仅仅是其梯度下降机制在寻找通往绿灯的最省力路径而已。确定性的卡口是整个流水线中唯一无法被一段自信的段落说服的部分，因此务必保持严苛。

**必须由人类来为 merge 最终负责。**模型不会在凌晨被呼叫排障，也无法对上线故障承担任何现实后果，因此那个最终点击 merge 的人才是唯一的负责人。当 AI 评审用平和、笃定的口吻告诉你“看起来不错”时，它向你传递的是一种尚未被充分证实的虚假信心。请将每一次 AI 评审都视为一个传感器，而不是最终判决：它提供的是参考数据，而不是决策。

如果你是独立开发且没有用户，那么分级审查、测试变更规范以及 CI 基本就能覆盖你的大部分需求，其修饰和繁文缛节在用户到来前都属于过度设计。

如果你身处大型组织，那么上述所有规则都是最低底线，而最初的筛查分类与准入门槛的设定，直接决定了 review 机制是能够良好运转扩展，还是会无声无息地彻底崩溃。

如果你带领一个团队，这意味着什么

开发的瓶颈早已不再是编写代码的速度，而是能够获得信任的人类何时能确信 review 过的代码没有问题。因为“AI 让我们开发更快了”而裁撤那些提供信任保障的评审人员，无异于把当下节省出来的成本转化成未来的生产事故。

产品上线的硬性约束已经不是写代码有多快，而是被信任的开发人员确信变更没有问题的速度。任何将“代码生成”视为瓶颈、而将“review”视作免费无成本环节的方案，最终都会导致开发进度的无声停滞，即便效率报表上的数字可能很好看。

Faros 的报告开门见山地指出了这一点：随着产出的飙升，QA 和 review 的工作量也在同步上升，因此单纯因为“AI 提高了速度”而削减工程研发团队的人头是极其危险的，除非你已经首先解决了 review 的缺口。这部分被资深工程师所承担的隐成本（review 时间呈现三位数增长）最严重地压在了你最不能承受其陷入瓶颈的核心人员身上，而且在任何只统计 PR 合并数量的常规指标中，这一代价是完全隐形、无法被察觉的。

开源软件的维护者们最先、也最深切地遇到了这个问题。即使那些连绵不断、看似合理实则空洞的贡献完全出于善意，也需要消耗大量真实的筛选和分类时间。那些做得好的企业会将 review 能力视作一项真实的资源进行量化评估、悉心保护并有计划地支出，而不是将其视为被 AI 释放出来的闲置富余劳动力。

编写变得廉价，理解却依然昂贵

随着 agent 的普及，代码 review 并没有变得无足轻重，它反而成了整个研发流中的核心活动。写代码这个问题或将被彻底解决，并且成本以月为单位急剧下降；而能带来持久竞争优势的，是那个能够让你放心信任这些生成代码的验证保障系统。

不要指望能用非黑即白的简单做法解决所有问题。

如果你是独立开发且没有用户，关于客户流失的那些企业鬼故事只是你未来的潜在风险，而不是眼前的燃眉之急，所以极度依赖测试、只审查核心部分，并老老实实承认那些被你推迟的工作自始至终都是要补上的。

而如果你在为广大用户维护一个大型的系统，这里提到的每一个令人警惕的数字都与你息息相关，唯一可行的出路是搭建起分级审查、强力佐证、以及特意引入异构机制的 review 流程，并且由人类来为最终的合并做出最终负责。

我们让编写的成本大幅下降，而理解代码的成本却依然一如既往地昂贵。在未来几年里表现卓越的团队，绝不会是那些能够疯狂生成最多代码的团队，而会是那些能够建立起切实可信的 review 机制，并且永远不会把“测试通过了”与“人类真正理解了其背后的意图与原理”混为一谈的团队。

正如 @simonw 一直强调的那样，你的职责是交付那些你已经证明可行的代码。Agent 并没有改变这一点。它们只是把这部分“证明”的工作变成了研发重心的核心，而不是事后的补救，我认为这是一个非常重要的转变。

深刻理解一个系统并能自信地为它背书，是软件工程中最具持久生命力、也最有趣的一项技能。而如今，正是我们去深度磨砺并精通这项手艺的最好时代。