代码评审

变化在哪里

评审正是瓶颈落下的地方。《当代码变便宜，瓶颈就会转移》已经摆出了遥测数据：拉取请求更多、更大，等待更久，未经任何评审就合并的比例也在上升。本章把这条队列当作既定事实，追问 AI 能对它做些什么。

答案有两种，截然不同。第一种把 AI 当作评论者：一个读遍每份 diff 并发布发现的机器人。这会增加工作量，因为每条评论都要有人读，然后修复或驳回。第二种把 AI 当作路由器的一部分：由系统决定哪些变更需要人看、这个人必须看什么、哪些变更可以靠抽样审计放行。这会减少工作量。第一种可能适得其反。在《案例研究》完整解读的那项工业研究中，机器人的评论有 73.8% 被解决，而拉取请求的平均关闭时间仍从 5 小时 52 分钟升至 8 小时 20 分钟（ICSE-SEIP 2025，T1）。

人这一侧也在变化，体现在两个方面。

自信不再是信号。在斯坦福的一项对照研究中，使用 AI 助手的参与者在一道加密任务上"显著更可能写出不安全的解法"，同时也更可能相信自己写出了安全的代码（Perry 等人）。

作者的笃定从来就不是用心程度的好指标，有了助手参与，它只会更差。评审必须建立在检查和证据之上，而不是作者听起来有多确定。

产能有限，涌入量可能超过它。curl 在 2026 年 1 月底终止了漏洞赏金计划。维护者 Daniel Stenberg 说，目的是"取消人们向我们提交垃圾和未经认真研究的报告的动机，不管是不是 AI 生成的"，并说"当前汹涌而来的提交给 curl 安全团队带来了很重的负担"（The Register）。那是安全收件箱，不是拉取请求队列，但机制相同：当产出的生成成本低于评审成本时，评审者就会被淹没。curl 没有试图评审得更快，而是切断了来水。

所以，这个阶段要回答的问题不是"要不要让机器人评审我们的拉取请求？"，而是：哪些变更仍然需要人，这个人看什么，又凭什么证据放行其余一切？

本阶段的阶梯

下面的标准与成熟度网格的评审一行一致。和本书其他地方一样，级别指的是人评审什么、何时评审，并与 AI 被允许做什么对照来读。在评审阶段，权限问题格外尖锐：有没有哪个 AI 握有批准权？

L1 位于作者一侧。Google 的系统针对人类评审者已经写下的意见，提出一条解决它的修改。AI 触及的是对评审的回应，而不是评审本身。

如今几乎所有产品都停在 L2，这是有意为之。机器人读 diff、发评论，由人来决定。比如 Anthropic 的 Code Review"不会批准 PR——那仍然是人来拍板的事"（Anthropic，厂商博客，截至 2026 年 3 月）。GitHub 的 Copilot 代码评审已覆盖"GitHub 上超过五分之一的代码评审"，GitHub 描述它时说的是它发出的反馈，而不是它放行的合并（GitHub，截至 2026 年 3 月）。既然每次合并都由人批准，这些工具无论评论多好都属于 L2。在 L2，真正有用的问题是：机器人是减少了人的工作量，还是增加了它。

L3 改变了评审者看的对象。人不再逐份阅读 diff，只看规则路由给自己的部分，其余变更则看一份结构化的证据摘要。Hassan 等人把这份摘要称为合并就绪包，属于"提交给人审批的结构化证据包，用于证明功能完整性"，以及核验是否充分、工程规范、决策理由和可审计性（Hassan 等人，概念性提议）。证据并不完整：Atlassian 人工评审意见的减少表明，人评审的对象可以改变，但不能表明这种改变是安全的。成熟度模型对 L3 的标准要求一项比较：在至少 90 天里，把 AI 路由的变更的逃逸缺陷率与人工基线相比。至今没有任何组织公开过这项比较（见 L3 的定义）。

还有一个反向信号。据《金融时报》报道、经 Fortune 于 2026 年 3 月转述，Amazon 零售部门在一连串事故之后，计划要求资深工程师为初级和中级工程师的 AI 辅助变更签字。Amazon 则表示，讨论中的事故只有一起与 AI 有关，没有一起涉及 AI 编写的代码，也不存在这种签字要求（T4，有争议）。无论哪一方说得对，当时讨论的应对措施都是更多的人工评审，而不是更少。

L4 有先例，但没有 LLM 证据。下文案例中的 Zalando 机器人，在没有人参与的情况下批准一个界定好的低风险类别。文章从未说明是否用到模型，而基于规则的批准器对 AI 而言属于 L0，所以这一格对 LLM 仍是空的。Zalando 是路由机制的先例，不是 AI 的证据。

成熟度模型的规则中有一条经验法则在这里直接适用：编码的级别最多比评审和测试中较低的那个高一级。这是本书的提议，不是定律。如果编码智能体已经在无人值守地提交拉取请求（编码 L3），而评审还停在 L1，就等着排队吧。先把评审提上去；《编码》讲的是同一取舍的另一面。

案例：Atlassian 的评审者与 Zalando 的路由器

本章的论点分两半：精确度和路由。两半各自最好的证据来自不同的公司。Atlassian 仔细测量了一个 AI 评论者；Zalando 公开了一个基于事故数据构建的路由器。

Atlassian：RovoDev Code Reviewer · T2 · 组织自测

级别：评审，L2。评审者对拉取请求发表评论；每次合并都由人批准。

Atlassian 的工程师在生产环境中评估了自家的 RovoDev Code Reviewer，并以 ICSE 2026 工业论文的形式发表（arXiv 2601.01129，2026 年 1 月）。摘要报告了来自"为期一年"的离线、在线和用户反馈评估的三个数字：评审者的评论中有 38.70%"在后续提交中引发了代码修改"；拉取请求周期时间缩短了 30.8%，而当前（v2）版摘要的表述更为谨慎，称之为"加速反馈周期的希望"；人工撰写的评审意见数量减少了 35.6%。

第一个数字是厂商通常拿来打头阵的那类，也是信息量最少的：一条"引发了代码修改"的评论，可能抓住了一个缺陷，也可能只是促成了一次没必要的改名。第二个数字是流动指标，方向与那项工业研究相反——那里的关闭时间变长了。两者在工具、地点和时期上都不同，从外部无法调和。放在一起看，它们说明 AI 评审者对流动的影响并不是固定的。

第三个数字最难解读。人工撰写意见减少 35.6%，从外部看正是 L3 的样子：人评审的对象变了。但它符合两种解释。一种是机器人抓住了例行问题，人把注意力转向了别处；另一种是人依赖机器人，看得不那么仔细了。只有逃逸缺陷对比能区分二者，而论文没有报告。

它没有说明什么。进入生产的缺陷是增是减；那 30.8% 在等待和实际评审之间如何分配；结果能否推广到别处。同行评审约束的是方法，不是独立性：Atlassian 测量的是自己的工具。

Zalando：基于风险的自动批准 · T3 · 工程博客

级别：评审，一种处于 L3/L4 边界的路由机制，未说明含有 AI 组件。

在《Zalando 的智能体工程：一份快照》（2026 年 8 月）中，Zalando 描述了一个机器人，它把每个拉取请求按上线风险分为"低、中、高"三类。"我们 33% 的 PR 属于低风险，由机器人自动批准"，之后作者即可合并，"在我们这里，这让 PR 前置时间缩短了 20–40%（与全部 PR 相比）"。

值得照搬的是它的设计。"审批机器人的规则集是基于对我们生产事故以及常见宕机诱因的分析构建的"，这些规则"高度针对我们的技术栈、部署清单、配置文件等"。分级依据的是后果而非大小："导致配置损坏的拼写错误被评为高风险"；"破坏向后兼容属于中风险，需要另一个人来判断"；"只改文档的变更属于低风险"。

机器人还改变了人的行为。Zalando 以轶事的形式报告，工程师开始拆分工作，让向后兼容的部分作为低风险变更快速发布："过去，我们看到这类变更被混在一起，拉长了上市时间，也增加了上线风险。"路由奖励的是小而可拆分的变更。

它没有说明什么。20–40% 是拿低风险 PR 与全部 PR 相比，而低风险 PR 本来就会更快，因此部分收益来自选择效应。Zalando 没有给出自动批准类别的逃逸缺陷率或事故率。文章也没有说明分类器是否使用 LLM，所以这是路由的证据，而不是 AI 批准的证据。

两个案例合起来，就是本章的设计：人仍要看的部分，交给一个精确的 AI 评审者；再用从事故中提炼的规则，把一部分变更移出人工队列。两家都没有公开能让这一组合够得上 L3 的安全性对比。

迁移步骤

按任务类型逐级攀升："评审：只改文档的变更为 L3；其余为 L2"就是一个合格的定级。

L0 → L1。

1. 允许作者一侧的辅助：针对评审意见的修复建议、对 diff 的解释。不以 AI 的名义在拉取请求里发布任何内容。
2. 趁机器人还没来，现在就记录基线：首次评审时间、实际评审时间、关闭时间，以及未经评审就合并的 PR 占比。之后每一步都要靠它来判断。

L1 → L2。

1. 部署一个只能评论、不能批准的评审机器人。在仓库设置里就不给它批准权，而不只是在它的指令里写明。
2. 先调精确度，再求覆盖面。Uber 的 uReview 用带有分类别阈值的置信度分数过滤评论，合并近似重复项，整类压制开发者不看重的类别（其中包括风格和可读性），并让第二个模型给第一个模型打分（Uber，T3）。GitHub 为 Copilot 代码评审表达了同样的原则："沉默胜过噪音"（GitHub，截至 2026 年 3 月；其自报数字见"指标"一节的厂商自报框）。
3. 在每条机器人评论上加一个"没用"按钮，并事先写下达到什么比例就关掉机器人（见 7.5 节）。
4. 为机器人评论加署名标识，以便与人工评论分开统计。
5. 60–90 天后，把关闭时间和等待时间与基线比较。如果关闭变慢了，先修好精确度，再往前走。

L2 → L3。这一步改变的是人评审的对象，光有更好的机器人是不够的。

1. 像 Zalando 那样，从你自己的事故历史中建立风险分级。问一问哪些变更引发过宕机，为这些变更类型写规则。不要从厂商的通用类别起步。
2. 定义低风险变更必须附带的证据包：跑了哪些检查、是否通过，AI 评审者的发现及每一条如何处理，变更的风险类别及理由。本书的模板附录收有一份合并就绪包模板。
3. 在合并系统中强制执行路由（分支保护、按路径指定必需审批人），而不是写在一份制度页面上。无论是编写代码的智能体还是做评审的 AI，都不得修改规则或分类器。这就是把判据原则用在评审上：路由规则就是核验器。
4. 对被路由走的类别保留人工审计抽样，并让该类别运行至少 90 天，把它的逃逸缺陷率与同类人工评审变更相比较。到那时才能称之为 L3。

L3 → L4，只限一个任务类别。这一级没有公开的 LLM 证据，所以要把它当作必须论证的例外。该类别必须狭窄且可逆（只改文档的变更是显而易见的第一个候选）。它需要一份有记录的验证档案、配有停用开关的持续监控、定期审计抽样，以及一位签署了风险承担书的指定负责人。大多数团队应止步于 L3，许多团队应止步于 L2。

示例推演：评审工时花在哪里

下面的算术仅作示意，背后没有任何组织。它说明为什么评论者和路由器的上限不同。一个团队每周收到 200 个拉取请求，一次人工评审需要 30 分钟。

Illustrative arithmetic. 200 PRs/week, 30 min human review each.

Scenario                                    Per-PR minutes     Hours/week
A. No AI review                             30                   100.0
B. Noisy bot: 5 comments/PR,                30 + 5 = 35          116.7
   1 min each to read and dismiss
C. Precise bot: 2 comments/PR at 1 min,     30 - 5 + 2 = 27       90.0
   saves 5 min of human review
D. As C, plus routing: 33% low-risk         134 x 27 = 3,618 min
   auto-approved, 10% of those audited      6.6 x 30 =   198 min
   at 30 min                                total      3,816 min   63.6

B vs A: +16.7%.  C vs A: -10.0%.  D vs A: -36.4%.

B 行就是那项工业研究的模式：评论耗费的注意力多于它们节省的。C 行的收益受限于机器人能替代每次评审中的多少工作。D 行把整次评审移出队列，所以它的收益受限于你能证明为低风险的变更占比，而不是评论质量。33% 借自 Zalando，只作为输入；你的占比取决于你的事故历史。

护栏

职责分离。编写变更的智能体绝不能批准它，提出需求的人也不能。GitHub 的 Copilot 云端智能体默认就是这样：它只推送到自己的分支，它的"工作流在 Copilot 云端智能体的代码被评审之前不会被触发"，而且发起请求的人不能批准它的拉取请求（GitHub 文档，截至 2026 年 10 月）。本站关于智能体职责分离的文章介绍了这一模式，《安全、权限与爆炸半径》则给出了每一级完整的权限边界。

给评审者一个全新的上下文，并限定问它什么。Anthropic 的指南建议另开一个只看 diff 和评判标准的评审会话，并提醒："一个被要求找漏洞的评审者通常会报告一些，即使工作本身没问题……追逐每一条发现会导致过度设计"（Claude Code 最佳实践，厂商指南，截至 2026 年 10 月）。要让它找指定类别的缺陷，而不是"任何问题"；迎合提示词所暗示的答案，正是本站在谄媚一文中描述的失效。

独立性仍是悬而未决的问题。批评者认为，当同一厂商的模型既写代码又评审代码时，评审就不是独立的检查。InfoQ 引述的一位用户说，这"连最低安全标准都达不到"（二手来源，2026 年 4 月）。没有研究测量过模型或厂商的多样性是否能抓到更多缺陷。在有研究之前，不要把 AI 评审算作受监管变更所要求的那道独立的第二次检查。

设计评审留给人。Uber 说 uReview"只能访问代码"，看不到过去的 PR、功能开关配置、数据库模式或技术文档。看不到设计的机器人无法评审设计，所以凡是涉及架构、数据模型或兼容性的变更，一律路由给人。《需求、规格与设计》讨论这些决策归谁所有。

一个事先约定的关闭开关。早在 LLM 出现之前，Google 就公开过一条针对自动化评审反馈的数值规则。它的 Tricorder 平台统计开发者对每个分析器的发现点击"请修复"与"没用"的情况："如果某个分析器的比例超过 10%，Tricorder 团队就会停用该分析器，直到作者改进它"，而且它"已经（多次）停用过分析器"。平台公开的标准是，开发者"应当感觉到该检查至少有 90% 的时候指出的是真问题"（Sadowski 等人，CACM 2018）。

本书的提议是，对 AI 评审者采用同一机制：每条评论配一个反馈按钮，跟踪一个比例，上线前定死阈值，一旦超过就关掉机器人（尽可能按类别关），修好再开。Tricorder 的 10% 针对的是静态分析器；把它当作起点。本书关于衡量成效以及何时回退的那一章以此为模板，为每个阶段设计回退触发条件。

限制批量。Zalando 报告，一些"认为大 PR 是个问题的团队，已经在内部约定把 PR 大小限制在一个固定规模"。大小对 AI 评审者和人一样重要：Anthropic 报告，它的评审者在大 PR 上发现的问题远多于小 PR（厂商自报，截至 2026 年 3 月；数字见"指标"一节的厂商自报框）。diff 越大，需要分拣的发现越多。限制大小对两种评审者都有好处。

指标

每个厂商都会报告一个听起来像"好评论占比"的数字，而没有两个衡量的是同一件事。下面这些术语把它们区分开来。

评审指标词汇表

• 有用（useful）：有人把这条评论评为有帮助。属于自愿评分，只统计那些愿意点一下的人。
• 已处理（addressed）：代码在同一变更集中以回应该评论的方式发生了修改，由规则或模型判定。
• 引发修改（led to change）：后续提交改动了评论所指的代码。它不能说明修改是对的或必要的。
• 已解决（AI 判定）（resolved）：由模型在合并时判断被标记的问题已修复。
• 可操作（actionable）：这是一次评审的属性，不是一条评论的属性：该次评审至少发出了一条评论。
• 被标为错误（marked incorrect）：有人明确把某条发现标记为错误。它只是误报的下限，因为大多数错误评论只是被无视了。

这些指标没有一个衡量的是：是否抓到了一个否则会被发布出去的缺陷。那才是你想要的数字，而没有人公开它。只有其中一项有人工基线：Uber 的审计发现，人工撰写的评论有 51% 在同一变更集中被处理，而 uReview 超过 65%，两者测量方法不同（见《案例研究》）。

应当跟踪什么

评价你的评审者，要看它对队列和对最终发布的东西产生了什么影响，并让每一个流动指标都配上一个稳定性指标。

• 等待时间和实际评审时间分开统计，智能体 PR 与 AI 辅助 PR 也分开统计。瓶颈一章解释了为什么单一的"评审时间"会掩盖队列。
• 关闭时间与上线机器人之前的基线对比。在那项工业研究中，走错方向的正是这个指标。
• 按评论类别统计的"没用"比例，并与你的停用阈值对照。
• 逃逸缺陷和回退：AI 评审和被路由的变更，与同类人工评审变更相比。这是通往 L3 的关口。
• 被路由到快速通道的占比，以及其中审计抽样的发现。
• 未经任何评审就合并的 PR，不论该由人还是由机器评审。如果这个数字上升，队列是靠跳过评审、而不是靠路由缓解的。

反模式

把评论数量当作价值。每个 PR 的评论更多，或"已解决"比例更高，都只是活动量。那项工业研究里有 73.8% 的评论被解决，关闭却变慢了。如果你的仪表盘以评论数打头，它衡量的是成本。

追逐每一条发现。被要求找漏洞的评审者总会找到一些。把每条 AI 评论都当作必须处理，就把精确度问题变成了过度设计。

在不变的队列上加一个机器人。如果每个 PR 仍要等同样的人工批准，再添一个 AI 评论者只会让约束留在原地，甚至加重它（见示例推演的 B 行）。如果机器人没有改变人评审的对象，它就没有碰到瓶颈。

把"AI 评审过"当作"评审过"。AI 的评论不是批准，产品自己也这么说。一个流程如果让机器人的放行代替人工批准，却没有成文的路由规则、审计抽样和逃逸缺陷对比，那就是做出了一次未申报的 L4 授权。按照权限规则，无论制度怎么写，你实际所处的就是这个级别。

同一个智能体既写又批。如果编写代码的智能体能批准自己的拉取请求，或能修改评审者的指令或路由规则，那就没有评审可言。

把人工评审当作无底洞。评审产能是有限的，触到上限的团队往往选择跳过评审，而不是为它做规划。Faros 的遥测显示，完全未经评审的合并在增加（T3，厂商；见瓶颈一章）。curl 触到了上限，于是切断了来水。在扩大生成规模之前先规划评审产能；做不到，就像 Google 的迁移团队那样给生成限流。

用厂商自己的数字给评审厂商排名。"70% 已解决"、"71% 可操作"和"38.7% 引发修改"是三种不同的测量。应当在你自己的拉取请求上比较工具。本站的代码评审智能体实践指南和评审机器人对比介绍了工具，关于智能体产出的评审队列的文章介绍了队列本身。《测试与验证》讨论被路由的变更必须通过哪些检查。