当 AI 开始大量写代码，Code Review 应该审什么？

目录

• 目录
• 1. 审查瓶颈变了：人的注意力要用在哪里
• 2. 六层检查加回滚：审查贯穿变更生命周期
• 3. 按变更风险路由人工审批
• 4. AI Reviewer 自己也需要评估和停止条件
• 5. 审查评论怎样变成团队的可复用知识
• 6. 团队怎样渐进落地
• 附录：参考资料与校准说明
  • 校准说明
  • 名词与概念解释
  • 参考资料

一个只改文案的 PR，和一个修改自动更新器的 PR，是否都需要同样多的人逐行审查？当 AI 加快代码生成，这个问题变得越来越实际。

Anthropic 在一篇介绍 Claude Code 团队审查实践的文章里给了两个信号。其一，Anthropic 的 monorepo 每天落地的变更从 2026 年 5 月约 2,500 个增至 9 月超过 30,000 个。其二，在独立于 monorepo 的 Claude Code 代码库里，6 月至 9 月合并的 PR 数量增加了一倍以上，需要回滚的 PR 占比相对下降了超过 40%；这里说的是相对降幅，不是下降了 40 个百分点。这是不同代码库、不同指标的观察，不能合成一条增长曲线，更不能据此证明某项审查措施单独造成了质量改善。

这两组观察把同一个工程问题推到眼前：当变更量持续增长，要求人对每个 diff 保持同等强度的逐行阅读，很难继续作为默认流程。我的判断是，Code Review 需要被重新设计成一套风险路由、证据检查和反馈校准系统。这个名称是本文对案例的归纳，不是 Anthropic 对自身流程的命名。

1. 审查瓶颈变了：人的注意力要用在哪里

传统 Code Review 至少承担两项工作：在交付前发现问题，以及通过阅读同事的改动传播代码库知识。前一项关乎交付风险，后一项关乎团队是否理解自己的系统。Anthropic 的文章主要解决第一项，同时承认第二项还没有正式的新流程。

如果只把“有没有人读过代码”当成质量指标，就会误判审查的效果。一位工程师花半小时审完一个文案改动，和花同样时间理解自动更新器的边界，所消除的风险并不相同。反过来，减少人工审批数量也不一定节省了时间：漏掉的故障可能在上线后变成排障、回滚和事故复盘。

因此，Anthropic 关注的目标更具体：让多数 PR 在不增加回滚和事故的前提下，以至多一位人类参与者完成合并；这位参与者可以是发起变更的人。团队跟踪每个 PR 的人工审批次数中位数与 95 分位、人工评论数，以及等待人工处理的时长，再用回滚率和事故率作为护栏。这与我在《构建 AI 智能体应用（四）：验证与测量》里强调的思路一致：评价一个 Agent 系统，需要看任务结果和过程成本，也要看失败如何暴露与恢复。

真正的效率目标，是减少审查、排障和修复所需的总人工时间，同时守住交付质量。审批减少后，还要继续观察回滚和事故；它们是滞后指标，短期平稳并不足以证明新流程安全。审查也因此需要前移，贯穿一项变更的生命周期。

2. 六层检查加回滚：审查贯穿变更生命周期

Anthropic 把检查分散在一项变更的整个生命周期里。不同层负责发现不同问题，也各有盲区：

这些检查之外，还要有快速发现并回滚的能力。功能开关可以在不重新部署的情况下关闭新行为；值班和事故复盘追问哪一层本应发现问题。回滚无法代替合并前检查，但复杂软件也不可能在合并前穷尽所有风险。

这里有两个值得注意的工程细节。第一，提交 PR 前就要求 Agent 展示测试输出、构建结果或截图等可检查的证据，比让它口头说“已完成”更可靠。第二，PR 上的审查不只看 diff 是否整洁，还要对照变更意图和仓库上下文，判断它是否真的解决了问题、是否破坏了别处。原文提到，代码审查产品进入研究预览期后，内部 PR 获得实质审查评论的占比从 16% 升至 54%；这个数字说明评论覆盖发生了变化，不能直接写成缺陷发现率提高了相同比例。

六层检查的价值，在于各自针对不同的失败方式。团队需要说清每一层要看到什么证据、谁处理发现、失效后怎样回滚；否则，增加检查层数也只是重复阅读同一份 diff。

3. 按变更风险路由人工审批

机器检查能覆盖越来越多的常规错误，人仍要处理检查无法替代的决策。Anthropic 的风险分级给出了清楚的边界：

一个容易误判的例子是系统提示词：它看起来也是“改文案”，但原文把它列为中风险；受功能开关保护的增量变更则被列为低风险示例。我的解释是，前者可能改变产品行为，后者更容易限制影响和撤回。实际分级还要看这次改动的影响面、可逆性和检查证据，不能拿代码行数或文件类型直接代替风险判断。这些判断维度是本文对案例的归纳，具体分级仍应由团队按自己的系统校准。

分级表只是第一道判断。Anthropic 先用分类器为这次变更定级，再由第二个分类器判断，即使等级允许轻审批，这次改动是否仍需要另一人参与。更轻的路径只对仓库信任名单中的作者开放，名单外作者仍需另一人批准；代码所有者指定的敏感路径、CI 工作流文件等也始终需要人。Agent 的“批准”不能占用人类审批名额。如果新的提交超出了系统能确认的范围，之前针对旧 commit 的审批还要重新给出。指挥 Agent 提交改动的人可算作所需的人类参与者之一，也要对结果负责；审批人数减少，不等于责任被自动化接走。

更重要的是，人工注意力应尽量前移到机器难以回答的问题：这项功能是否值得做？范围是否合适？一段新架构会不会成为之后所有人照抄的先例？测试输出、截图和审查发现能证明什么，又遗漏了什么？原文甚至提到，Agent 让开始写代码的成本变低，有些 PR 更应该尽早改变方向或直接关闭。这个判断如果拖到一份完整 PR 的最后才提，成本已经高了。

从《ArcKit：当 AI Coding 走出代码内循环》讨论的视角看，代码实现和测试属于高频内循环，方向、架构与风险接受属于更慢的外循环。自动化提高了内循环速度，后者就更需要清晰的责任人与决策记录。

4. AI Reviewer 自己也需要评估和停止条件

引入 AI 审查之后，团队会得到更多发现，也会得到更多看似有道理的发现。Anthropic 的流程里，多个 Agent 并行找问题，另一组 Agent 核验和投票；只有足够多的评审认为问题成立，评论才会发布。仅涉及样式、诊断信息或清理的低价值意见会被过滤；发布的发现还会标为重要、细枝末节或既有问题，避免把旧问题都归咎于这次 PR。每条发现都要被修复，或说明为何关闭。

过滤很重要，但“多个 Agent 同意”仍然只是审查信号，不是事实证明。如果它们读到同样缺失的上下文，可能一起误判。这个提醒来自我对评估系统的工程判断，不能据此断言 Anthropic 的评审器已经出现某种特定偏差。判断一条评论是否有用，还需要可复现的证据、懂代码的人确认的历史事故样本，以及上线后的结果。

Anthropic 已经把造成事故的历史 PR、修复和回滚收进评估集，请熟悉相关代码的工程师确认缺陷位置，并让评审器每天在这批样本上运行。另一面则是测量噪音：人究竟修复了评论、认为它有误、认为行为本来如此，还是认为问题不重要；对已知干净的 PR，评审器会不会提出反而导致有害修改的建议。这比只统计“发了多少条评论”更接近审查质量。

噪音在 Agent 写代码时尤其昂贵。人可以快速忽略一条无关紧要的建议，Agent 可能会照做，再提交、再触发审查。原文记录过一个 PR 在一夜间经历了超过 50 轮审查与修复。团队检查反复被标记的代码后发现，约 59% 从第一轮审查时就已经存在。这不表示 59% 是误报；它说明后续轮次常在不断翻出旧问题，流程难以结束。

因此，他们加入三轮上限；超过上限时先退一步重新考虑方案。前几轮之后只复查新 diff，避免重复发布旧发现，并让作者修复一类问题的所有实例。Anthropic 写下的优化顺序是：先抓住真实缺陷，再减少审查轮数。轮数不是可以牺牲缺陷召回率来压低的独立指标，而是检查评审器能否收敛。自动化审查需要同时定义如何验证发现、何时停止，以及无法收敛时怎样改变策略。

5. 审查评论怎样变成团队的可复用知识

如果机器读了大部分 diff，人怎么继续理解系统？Anthropic 坦言，他们还没有一套正式流程来完整替代审查的知识传播作用。团队成员想理解某个模块时，会让 Claude 针对那一小块代码生成讲解，必要时做可视化；开放的协作频道也让同事看到彼此的工作。这些做法降低了获取局部上下文的成本，但它们仍有一个更长远的问题：为什么某条约束存在，谁来保证它下次还会被记住？

原文已经给出一个起点。重复出现的审查意见，会回到 Skill、lint 规则或项目指令；由代码所有者编写的 REVIEW.md 告诉评审器这个区域什么算失败、哪些路径应跳过，以及发现必须带文件和行号证据。这样做的关键，是让下一次审查能使用这些经验，而不是把所有评论都塞进一份越来越长的文档。

阿里技术关于 AI 知识库的实践把业务、架构、系统和基建知识分层，提醒我们：评审器需要的上下文不止代码规范，还包括跨系统依赖和业务约束。沿着这个思路，本文建议把复盘后的审查经验按执行方式分为三类：

1. 可确定判定的约束，例如禁止某层直接访问私有表，进入 lint、架构检查或测试。
2. 需要上下文理解的约束，例如配置改动会让请求路由到错误环境，进入简短的 REVIEW.md、项目说明或 Skill，并附真实失败案例。
3. 需要人权衡的决策，例如一次改动是否值得引入新的系统边界，进入设计记录和风险讨论，由责任人判断。

这三类是本文的建议，并非 Anthropic 已经实行的完整知识治理流程。一条评论进入长期规则前，还应写明触发场景、约束理由、验证方式和维护者。低价值、从代码一眼可知的细节，不必反复文档化；没有维护者的规则，最终可能让评审器读到过期上下文。真正值得保存的是下一次机器容易猜错、人也容易忘记、改错又很贵的约束。

6. 团队怎样渐进落地

Anthropic 的流程建立在高变更量、完整 CI、合并队列、灰度发布和持续值班之上。小团队没有必要把所有层一次性复制过来，但可以沿着同一条逻辑逐步建立能力。

第一步，建立基线和可运行证据。 给 Agent 明确测试、构建和检查命令；在 PR 模板中写清“如何测试、有哪些风险、怎样撤回”。要求提交者附输出，而不是只写“测试通过”。记录一个仓库的人工审批次数、等待时间、回滚与事故，才有后续比较的基线。

第二步，在一个仓库校准评审器。 先试用几周，要求评论指出具体文件、行号和失败机制；记录哪些评论被修复、哪些是误报或既有问题，以及每个 PR 经历几轮审查。把重复且有效的意见归入测试、lint 或简短的项目规则。对安全、CI、发布和核心业务路径保留人工审批，明确每次变更的责任人。

第三步，用结果决定能否放宽门禁。 收集真实事故、回滚和干净 PR 作为回归样本；更新提示、模型或工具时重新评估。先确认自动检查稳定、作者可信、变更可逆，再按风险等级观察审批时长、回滚和事故，而不是只看全仓库的平均值：如果高风险改动的占比变了，整体回滚率也可能跟着变。短期没有事故，仍不足以单独证明安全。确认低风险路径表现稳定后，再逐步考虑减轻人工审批。

随着变更量上升，加入合并队列、功能开关、分阶段发布和快速回滚；若回滚或事故上升，检查是哪一层漏掉了风险，再调整审批和检查强度。Anthropic 明确说过，他们目前尚未实现根据这些指标自动收紧审批的熔断器；这仍是他们希望补上的能力。

原文的轻审批依赖可信作者、完整的自动检查、敏感路径例外和可逆的发布机制。缺少回滚能力或业务风险很高的团队，应继续保留相应的人工门禁。Anthropic 的数据是特定团队在特定时期的自述；其他团队是否能得到类似结果，要用自己的基线和事故记录验证。

代码生成越快，审查越需要回答三个问题：哪些错误能由机器稳定发现？哪些风险必须由人判断和承担？漏过的错误怎样回到检查与发布流程？把答案落实到每次变更的证据、审批规则和事故复盘中，才能在提高变更频率时持续校准质量。

附录：参考资料与校准说明

校准说明

• 本文的 Anthropic 数据来自团队在 2026 年 10 月发表的实践复盘，不是跨团队随机实验。不同代码库的数据没有合并，也没有据此推断单项措施与回滚变化之间的因果关系。
• “风险路由、证据检查和反馈校准系统”以及审查经验的三类归档，是本文基于案例和个人知识库提出的分析框架，并非 Anthropic 的官方流程名称。
• 阿里技术的知识库实践用于说明评审器可能需要的业务与系统上下文；本文的三类审查经验归档方式是另行提出的建议。Anthropic 内部流程与指标以其原文为准。

名词与概念解释

• PR（Pull Request）：提交给代码库审核与合并的一组变更。
• Diff：一次变更前后代码的差异；只复查新 diff，能避免反复评论早已存在的代码。
• CI（持续集成）：自动运行 lint、类型检查、测试和构建等检查的流水线。
• REVIEW.md：由代码所有者维护的局部审查说明，告诉评审器什么算失败、哪些路径应跳过，以及发现需要什么证据。
• 缺陷召回率：在已知真实缺陷中，评审器成功找出的比例；单靠多发评论不能提高这个指标的可信度。
• 回滚率：已合并或发布的改动因问题需要撤回的比例；本文按来源的口径叙述，不将它等同于事故率。

参考资料

• Anthropic：How the Claude Code team does code review
• 《构建 AI 智能体应用（四）：验证与测量》
• 《ArcKit：当 AI Coding 走出代码内循环，开始接管架构治理外循环》
• 阿里技术：AI Coding 知识库实践（BestBlogs 收录）