Claude Code Review 正式上线，揭开六层 AI 监督流水线

2026 年 10 月 15 日，Anthropic 的Claude Code Review从研究预览转为正式上线时，公司在产品公告之外做了一件不寻常的事：它发表了一篇详尽的工程复盘，讲述构建这套系统过程中出过哪些问题。这篇由 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 发表在 Anthropic 工程博客上的文章，《Claude Code 团队如何做代码审查》，揭示了一个被彻底改造的开发流程：当被审查的系统本身也编写了大部分被审查的代码时，团队实际上不得不重新定义什么是软件质量保证。

数字让问题一目了然。截至 2026 年 9 月，合并进 Anthropic 主仓库的代码中，超过 90% 由 Claude 编写。每日合并量从 5 月的约 2500 次，攀升到 9 月的超过 3 万次——四个月里增长了 12 倍。仅在 6 月到 9 月之间，合并的拉取请求就翻了一番。在较小的代码库里本可以发现大多数重大缺陷的人类审查者，如今面对的是源源不断涌来的机器生成提交。在 AI 审查系统上线之前，只有 16% 的代码改动得到了实质性的反馈。其余的要么被草草浏览，要么根本没人审查。

10 月 15 日的正式版发布，让所有 Claude Team 和 Enterprise 客户都能使用 Code Review，同时为符合条件的组织提供至少 1 万美元审查额度的推广优惠。定价仍然按 token 计费，视复杂程度，每个拉取请求 15 到 25 美元——这种成本结构反映的是所涉工作的深度，而不是跑一遍 linter 的速度。

传统代码审查如何在 AI 规模下失灵

Anthropic 遇到的这种失效模式并非它所独有。在整个行业里，AI 编程工具大幅提升了每位工程师的代码产出——Anthropic 的工程师在 2026 年第二季度交付的代码，大约是2024 年同期的八倍。但在团队每天合并几十个拉取请求时还管用的审查基础设施，一旦这个数字达到数千，就会崩溃。

具体到 Anthropic，这种不对称之所以格外严重，是因为 Claude Code 写的不只是新功能，还有 Claude Code 自身的核心基础设施。到 9 月，Claude 自己的代码库中超过 90% 是由 Claude 编写的——Claude Code 的创造者Boris Cherny公开把这种情况描述为一个自我强化的反馈回路。当团队要求 Claude 在提交前验证自己的输出时，Cherny 发现质量比未经验证的提交提高了两到三倍。编写代码的同一个模型，也能对代码做出有意义的批评——前提是审查提示词的结构设计得当。

但当工程团队需要在每天数万次合并中管控回滚风险时，仅靠自我验证是不够的。最终形成的是一套分层架构，旨在在开发周期中最合适的环节，捕捉不同类别的问题，而人工审查则被保留为一道与风险相称的兜底，而不是每次都要过的关卡。

六层防御架构内部

Anthropic 在内部构建并部署——如今已正式开放——的这套系统，运行在六个不同的层级上，每一层处理不同的风险面。

第 1 层——提交 PR 之前的自我验证。在工程师打开拉取请求之前，Claude 会运行项目的构建、测试套件和 linter，然后启动一个全新的子智能体，在没有生成代码那个会话上下文的情况下阅读 diff。全新上下文的审查是这里的关键设计选择：一个花了几个小时开发某个功能的智能体，已经积累了一些假设，可能会让它为明显的错误找理由开脱。一个在代码编写时并不在场的审查者，会注意到作者眼睛跳过的东西。这一层能在许多错误进入共享审查流水线之前就把它们拦下。

第 2 层——每个拉取请求都进行并行 AI 审查。PR 一打开，Claude 就派出一组智能体并行查找缺陷，逐一验证每个发现以过滤误报，并按严重程度对留下来的发现排序。对于有争议的问题，智能体会先投票再呈现给人类，这能抑制多个审查者各自发现同一问题时，PR 讨论串里通常会被重复评论刷屏的情况。审查聚焦于逻辑错误、安全问题和正确性——风格问题会在人类审查者看到输出之前就被明确过滤掉。项目规范和审查重点，写在仓库里的CLAUDE.md和REVIEW.md文件中，让团队可以针对特定路径或组件调节审查深度，并指定哪些代码区域需要格外审视。

第 3 层——安全审查。每个 PR 都会运行一轮单独的、专注于安全的智能体审查，且必须在合并之前完成。这一层检查 SQL 注入模式、跨站脚本漏洞、认证与授权缺陷，以及不安全的数据处理，Anthropic 将这些检查描述为对现有安全实践的补充，而不是替代。它与第 2 层的关键区别在于，安全审查没有商量余地：不同于风格评论甚至逻辑警告，安全发现会在任何合并进行之前作为优先反馈呈现出来。在公开提供的 Claude Code Review 产品中，这一层给出的是建议性发现——真正的合并关卡仍是团队自己的 CI 流水线。在 Anthropic 内部，这些发现被接入 CI 工具，形成了实际上的硬性拦截，企业团队可以通过把REVIEW.md的输出连接到自己的分支保护规则来复制这种配置。

第 4 层——持续集成。标准的 lint、类型检查和跨平台测试套件。这些检查与常规 CI 流水线没有区别，代表的是在加入 AI 层之前就已存在的基线。

第 5 层——按风险分级的人工审批。在进入人工队列之前，一个分类器会把每个 PR 归入三个风险等级之一。低风险改动——文档、文案修改、隐藏在功能开关后面的内部功能、没有对外接口的新代码——不需要强制的人工签字。中风险改动，包括常规的产品修改，以及任何涉及缓存系统、自动更新器或系统提示词等敏感组件的改动，需要一名人类审查者。高风险改动，即涉及最敏感代码路径的改动，需要两名。分类器自动完成等级划分；工程师打开 PR 时就能看到所属等级。

第 6 层——合并队列、功能开关和分阶段发布。获批的 PR 进入合并队列，而不是直接落入主分支。新功能先发给 Anthropic 内部员工，再逐步扩大到更广泛的用户群体。功能开关让任何改动都能在发布后监控发现异常行为时被立即关闭——无需重新部署。团队把这描述为代码进入生产流量之前的最后一道受控关卡。

在全部六层之后，还有最后一道兜底：自动检测加上快速回滚，以及一条「谁合并，谁负责」的归属规范——即使改动先经过了多个自动化系统的审查，提交改动的工程师仍要对合并后的监控负责。

实践中的风险分级：人类监督集中在哪里

风险分级分类器是整条流水线中影响最深远的设计决策，因为它决定了实际上有多大比例的 PR 会送到人类审查者面前。

中风险等级里的敏感组件清单——明确点名了缓存系统、自动更新器和系统提示词——并非纸上谈兵。它反映的是 2026 年 4 月 23 日那次事故复盘所汲取的教训：正是这几个组件中的缺陷相互叠加，造成了一次严重的生产环境性能下降。接入该产品的团队，可以通过修改REVIEW.md来配置哪些路径被视为敏感，让风险等级反映自己代码库特有的危险区域，而不是 Anthropic 的默认设置。

这套分级结构还体现了一种关于规模的理念：当合并队列每天运行 3 万次改动时，对每次改动都进行两人完整审查，并不是一项安全政策——而是一个瓶颈。与风险相称的审查，才让这种速度的自动化开发与产品质量能够兼容。

50 轮 PR 问题：当 AI 审查陷入自我循环

博文中最有启发性的失败之一，是一个 CLI 拉取请求陷入了审查与修复的循环，在工程师叫停之前跑了 50 多轮。审查者不断发现问题。修复者不断处理问题。双方都没有自动跳出这个循环。

这个问题以两种方式叠加。第一，审查智能体没有区分当前改动引入的新缺陷，和周围代码中早已存在的问题。团队分析这个循环时发现，审查者标出的问题中有 59% 位于这个 PR 根本没有触碰的既有代码里。从一个狭义的角度看，智能体在正确地做自己的工作——找出真实的缺陷——但在一个更重要的方面做错了：它把遗留缺陷当成了作者在合并前必须修复的责任。这正是把 AI 审查用于 AI 生成代码库的核心难题：编写代码的智能体和审查代码的智能体，都没有「在你碰它之前它就已经坏了」这个概念。

第二，智能体在不同轮次中重复报告相同的发现。如果某一类缺陷在第一轮出现且没有被修复，它就会在第二轮、第三轮乃至之后的每一轮里再次出现——增加的是噪声而不是信号，让循环一直延长而无法收敛。

团队实施的修复同时针对这两种失效模式：审查轮次现在上限为三轮；后续轮次只重新检查 diff，而不是全部被修改的文件；审查者标出的是缺陷类别，而不是逐一列举每个具体实例；已经报告过的发现不会在后续轮次中重复。这些约束防止系统以牺牲收敛为代价去追求彻底性。

内部指标显示了什么

这些改动在整条流水线上带来了可衡量的改进。AI 审查系统在内部上线后，得到实质性反馈的代码改动比例从 16% 升至 54%——这一变化反映出，在自动化之前，有多少审查能力根本就是缺失的。当人类审查者要应付每天数千个 PR 时，大多数改动只能得到敷衍的一瞥；AI 层则为全部合并量提供了一致的审查深度，而不只是最高优先级的那些改动。

审查效率也明显提高。一轮审查即通过的 PR 比例从 65% 升至 78%。在分布的另一端，需要五轮及以上审查的 PR 从 8.9% 降至 1.5%。每个 PR 的平均审查轮数从 2.08 降至 1.32。整个代码库的回滚率下降了 40% 以上。

这些指标还隐含着一个博文没有完全说透的更微妙的含义：实质性评论增加的同时审查轮数减少，说明 AI 审查并不只是在自动化人类原有的行为。它在揭示人类审查者漏掉的问题，同时也在流程中更早地发现它们——在它们变成需要好几轮才能理清的纠缠状态之前。平均轮数从 2.08 降到 1.32，是这组数字中运营意义最大的一个：每多一轮审查，就意味着工程师要切换回一个他们心里已经结掉的 PR，而这种成本在每天数万次合并中叠加起来，是相当可观的。

4 月的事故复盘：当 AI 审查自己代码里的缺陷

博文中最有揭示性的部分，描述了一份2026 年 4 月 23 日的事故复盘：Claude Code 出现的一次性能下降，追溯到了在六周内相互叠加的三个独立缺陷。每个缺陷单独来看只会造成轻微损害。合在一起，它们让产品明显退化，而且在多个审查周期中都没被发现。

第一个问题是 3 月 4 日实施的一次推理强度下调，把模型的推理强度从高调到了中——这一参数变更影响了复杂任务中的输出质量。它在4 月 7 日被发现并回退。

第二个是 3 月 26 日引入的一个缓存缺陷。这个缺陷导致思考块——模型在复杂多步任务中使用的内部推理轨迹——在空闲超时触发后的每一轮都被清空，而不是按预期只清空一次。这意味着模型在任务进行中反复重置推理状态。实际效果是，任何需要在多次工具调用之间持续推理的复杂任务，都在悄无声息地退化：模型每一步都得从头重建上下文，而不是逐步积累。修复于 4 月 10 日随版本v2.1.101发布。

第三个是 4 月 16 日推送的一项系统提示词变更，它为了控制冗长的输出，把模型在两次工具调用之间的输出限制在 25 个词以内。这一约束实际上让模型无法在多步任务中给出有用的中间推理。它于 4 月 20 日被回退。

让这次事故复盘不同寻常——并与代码审查架构直接相关——的，是之后发生的事。当工程师把完整的仓库上下文交给更新的模型Opus 4.7，让它分析性能下降前后那段时间的代码库时，它找出了那个缓存缺陷。而当时的生产模型 Opus 4.6，在给定较窄的上下文窗口时并没有找到它。

这个对比主要并不是在证明新模型更聪明。它证明的是：要发现三个独立改动之间的微妙相互作用——每个改动单独来看都很小，彼此相隔数周引入——所需要的那种宽上下文推理，要求一个大而连贯、覆盖全部相关代码库的上下文窗口，而不只是单个 PR 的 diff。没有哪个处理普通 PR 的人类审查者，能察觉到六周前做的一次缓存行为改动，正与五周后加入的一条系统提示词约束相互叠加。这次复盘实际上验证了第 2 层背后的架构选择：拥有宽上下文的并行智能体，不是锦上添花的便利功能，而是让跨改动的相互作用得以被发现的前提。

正式上线对企业开发团队意味着什么

正式版把 Code Review 开放给所有 Claude Team 和 Enterprise 客户，除了在组织设置中启用该功能并安装 GitHub App 之外，不需要任何按仓库的配置。一旦启用，系统会在每个 PR 上自动运行——除了最初的管理员设置之外，没有按仓库选择加入的环节——这消除了团队只对自己认为重要的代码运行 AI 审查的选择性部署问题。

上线时 1 万美元的推广额度，按标准价格可以覆盖 400 到 666 次审查，足以让一个中等规模的工程团队在几周内建立起有意义的基线，再决定是否持续投入 token 开支。按每个 PR 15 到 25 美元计算，这套系统的定价定位是专业基础设施，而不是廉价的附加功能——在单次价格上可以与专业代码审计服务竞争，但在 PR 数量很大时，持续成本相当可观。

与 GitHub Copilot、CodeRabbit 和 Cursor 的竞争态势

对于已经在使用 GitHub Copilot 代码审查、CodeRabbit 或 Cursor 云端智能体审查功能的团队来说，有意义的比较不在于智能体数量或营销说法。真正的区分变量，在于工具如何处理周围代码中的既有缺陷——它是否把发现限定在 diff 之内，在多轮中发现同一问题时如何处理，以及它的安全层是与 CI 流水线集成，还是需要单独调用。

GitHub Copilot 代码审查包含在 Copilot Enterprise 订阅中，现有客户无需额外付费，并与 GitHub 的 PR 工作流原生集成。它没有公开类似的架构失效模式披露，因此无法直接比较。

CodeRabbit采用按席位定价（按年付费时，每位开发者每月 24 美元起），而不是按 PR 计费，这对 PR 数量大的团队可能更划算。它支持 GitHub、GitLab 和 Bitbucket——相比上线时只集成 GitHub 的 Claude Code Review，在平台覆盖上有优势。

Cursor 的云端智能体提供了一个更广的自主编程循环，在一个能感知会话的上下文中集代码生成、修改和审查于一体，对于运行完整智能体工作流、而非以 PR 为单位进行审查的团队来说可能更合适。代价是 Cursor 的模式以会话为中心，而非以 PR 为中心，与那些以一次独立审查事件为前提的合并流水线结合得不那么顺畅。

Anthropic 公开讲述了 50 轮循环问题及其详细修复，为评估者提供了真实的诊断信息：系统在哪里失败过，这些失败又是如何解决的——这种透明度是竞争工具中没有一家做到的。

Anthropic 仍在解决的更大问题

这篇博文最重大的坦白并不在于缺陷，而在于开发流程本身的形态。

在每天 3 万次合并、90% 的代码由 AI 生成、人工审查只集中在按风险分级的一部分改动上的情况下，「谁写的代码」与「谁对代码负责」之间的关系，已经变得真正复杂起来。「谁合并，谁负责」的规范，把责任分配给了触发合并的工程师。但在这样一条流水线里——Claude 写了代码，另一个 Claude 智能体审查了它，一个分类器分配了风险等级，一个人凭一份摘要在几秒钟内批准了它——从问责的角度看，「合并它」究竟意味着什么？

博文把这条流水线描述为对数量问题的解决方案。它提出的更难的问题是：为人类作者设计的审查流水线，是否是这种规模下 AI 生成代码库的正确基础；还是说，整个合并前审查模式只是一种过渡产物，终将被持续的合并后监控、自动回滚，以及软件工程尚未发展出来的责任框架所取代。Anthropic 自己的工具是在事后——缺陷引入六周之后——才找出 4 月事故中的那些缺陷，这说明团队仍在寻找这个答案。第 6 层的功能开关和回滚能力，在结构上是整条流水线中最稳健的安全机制，恰恰因为它在合并之后、而不是之前发挥作用。随着 AI 编程在 Anthropic——以及如今正在采用其审查基础设施的那些组织——不断成熟，这种平衡将如何变化，是最值得关注的技术里程碑。