Anthropic Claude Code 审查取代常规人工阅读，AI 编写 90% 的代码

据 Anthropic 称，Claude 如今编写了该产品约 90% 的代码，这让 Anthropic Claude Code 审查进入了陌生领域。2026 年 6 月至 9 月期间，合并的拉取请求数量增长超过一倍；但据报道，需要回滚的占比下降了逾 40%。

这种组合才是真正的重点。面对机器编写代码的激增，Anthropic 并未让人类检查更多代码行，而是将大部分常规阅读交给其他 Claude 智能体，并将人工批准留给风险更高的变更。

这并非传统审查的简单提速。它改变了审查的含义、执行者，以及问责从何处开始。Anthropic 如今将人类注意力视为稀缺资源，应当跟随风险分配，而不是覆盖每一行代码。

这一方法也伴随着重要限制。头条数据来自 Anthropic 自行统计，尚未公布原始数据，也未经独立审计。其流程依赖广泛自动化、内部基础设施、分阶段发布，以及对自家模型异常深入的使用权限。

最终的较量并非 Claude 与人类程序员之间的对抗，而是自动化覆盖与普遍人工检查之间的竞争。Anthropic 正押注于：分层检查、定向批准和低成本可逆性，比以机器速度逐行阅读更能控制风险。

Anthropic Claude Code 审查发生了什么变化

Anthropic 将代码审查从单一人工关卡，转变为由自动检查、智能体审查者、定向批准和快速回滚组成的持续系统。

该公司在 10 月 15 日一篇关于 Claude Code review 的工程博客中介绍了这一系统。作者 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 将问题归结为产出规模：当智能体生成变更的速度超过人类阅读速度时，传统队列便会成为交付瓶颈。

Anthropic 表示，每个拉取请求都会先获得 Claude 审查，之后才由人工查看。审查者会结合更广泛的代码仓库及拉取请求声明的意图，阅读拟议变更。对于漏洞修复，它会尝试找出根本原因，而不只是检查表面补丁。

随后，多名智能体会并行查找潜在缺陷。另一组智能体会对每项发现投票，只有足够多的审查者达成一致时，系统才会发布问题。Anthropic 表示，它测试了能够过滤仅涉及样式、诊断或可选清理的评论的机制。

其余发现会获得严重性标签。开发者或智能体必须修复每项发现，或说明理由后关闭对应讨论串。只要问题尚未解决，独立的自动安全审查也可以阻止合并。

这些审查与传统防护措施并行。拉取请求仍须通过 lint、类型检查、构建，以及在受支持平台上的测试。合并队列会针对当前主分支重新运行检查，从而减少原本各自有效的变更发生不良交互所导致的失败。

审查在拉取请求出现之前就已开始。Claude 会运行测试、构建或视觉检查，并展示相关证据。拥有全新上下文的子智能体随后会检查 diff，从而降低编写智能体只是重复原有假设的可能性。

Anthropic 早先的 coding practices 建议将编写与验证上下文分离。新的工作流将这一建议转化为整个团队的操作系统。

人工批准取决于变更所分类的风险。低风险工作可在自动化和安全检查通过后合并，例如文档、文案变更、内部功能，以及隐藏在功能开关后的新增内容。

常规产品工作通常需要一人批准。缓存、系统提示词和更新机制等敏感领域同样会获得人工关注。最高风险的变更需要两人批准，而某些受保护路径始终会触发人工审查。

分类器评估的是变更本身，而非由人还是智能体编写。若原始分级看起来过于宽松，第二个分类器仍可要求人工参与。智能体的批准永远不能填补预留给人工的批准名额。

这一区别至关重要。Anthropic 并未取消人工问责，也未声称 AI 审查能够让软件毫无错误。它将常规缺陷检测与涉及架构、产品方向、敏感系统和可接受风险的决策区分开来。

指示 Claude 的人仍须对结果负责。每次批准仅适用于特定提交，因此后续变更可能使其失效。在 Anthropic 的模式中，委派改变了谁来编写和阅读代码，却不会改变谁对结果负责。

数据表明仅靠人工审查难以为继

Anthropic 公布的指标表明，代码产出可能已经超越了任何建立在全面人工阅读基础上的审查流程。

该公司表示，Claude Code 仓库中合并的拉取请求数量在 2026 年 6 月至 9 月期间增长超过一倍。同期，需要回滚的占比下降了逾 40%。

这些数据描述的是趋势，而非完整表现。Anthropic 未披露拉取请求的绝对数量、初始回滚率、最终回滚率或统计波动情况。40% 的相对下降既可能始于较高基线，也可能始于较低基线。

90% 这一数字也需谨慎表述。Anthropic 称，Claude 编写了 Claude Code 约 90% 的代码。这并不意味着模型独立决定产品优先级、定义每项需求，或承担部署责任。

工程师仍负责指导任务、判断证据、权衡设计取舍，并决定某项工作是否应当存在。机器作者身份衡量的是代码生成，而软件工程远不止于生成代码行。

即使有这些限定，Anthropic 仍面临真实的扩展难题。据报道，其独立 monorepo 从 5 月每天约 2,500 项合并变更，增长至 9 月每天超过 30,000 项。该公司构建了名为 Scion 的内部源代码控制系统来应对这一工作负载。

Claude Code 使用独立仓库，因此 30,000 项变更的数据并不直接衡量该产品团队。尽管如此，Anthropic 对其 source-control redesign 的介绍显示了其开发基础设施面临的更广泛压力。

Scion 和 Claude Code 的故事指向同一个瓶颈。一旦编程智能体能够持续创建、测试和修改变更，编写代码便不再控制吞吐量。审查队列、构建、权限、集成系统和发布控制将成为限制因素。

传统代码审查假定，来自人类的变更数量可被管理。另一人阅读每个 diff、要求修改并批准最终版本。当产出增长快于审查者能力时，这一模式便开始失效。

增加审查者并不能完全解决这种错配。经验丰富的工程师十分稀缺，而持续审查会打断设计工作、调试和产品决策。即使增加审查人员，组织仍可能在不断扩大的变更流中失去共同注意力。

因此，Anthropic 衡量的不只是产出的评论数量。它还跟踪每个拉取请求的人工批准数量、人工评论、等待时间、回滚和事故。其明确目标是在不将人工审查时间转移到生产恢复工作的前提下，减少人工审查时间。

该公司还报告称，其商用 AI 审查者将获得实质性评论的内部拉取请求占比从 16% 提高至 54%。据报道，大多数超过 1,000 行的变更会产生发现，而大多数较小变更则会获得干净结果。

这一结果本身并不能证明准确性。更多评论既可能意味着更好的检测，也可能意味着更多噪声，或两者兼有。Anthropic 表示，它通过观察开发者是否修复发现、拒绝发现，或认定所报告的行为本属预期，来评估评论质量。

更大的信号在于组织层面。Anthropic 不再将人类阅读每一行变更代码视为审查的决定性证明。它衡量的是组合系统是否能发现问题、有效引导注意力并限制生产环境损害。

这一变化给部署编程智能体的每个工程组织带来压力。如果智能体产出增长而审查政策保持不变，队列就会扩大，预期的生产力收益也会消失。团队必须限制生成，或重新设计验证方式。

自动化覆盖正在挑战普遍人工检查

核心较量在于广泛的机器覆盖，与“每项重要变更都值得人工直接阅读”这一信念之间。

普遍人工检查提供了一种直观承诺：合格工程师理解代码、看到变更，并在发布前承担责任。这一做法能够传播知识，同时发现自动化测试遗漏的假设。

然而，当审查变得仓促时，这种承诺便会减弱。面对庞大队列的人可能只是扫描而非推理，批准看似熟悉的代码，或把重点放在样式而非行为上。人工签名并不保证真正理解。

Anthropic 的替代方案采用多层专业化机制：一个智能体编写变更，另一个在全新上下文中审查，多个智能体寻找漏洞，独立智能体评估每项发现。安全审查、持续集成、合并检查、分阶段发布和回滚覆盖不同的失败模式。

这类似于纵深防御。由于后续层可以发现前序层遗漏的问题，任何单独一层都不需要具备完美的召回能力。风险分类则将稀缺的人类判断力导向潜在影响更大的变更。

这种机制也让 Anthropic 获得更广泛的审查覆盖。机器可以检查每一个拉取请求，无需等待同事的日程安排。它们可以检查代码仓库上下文、应用已记录的规范，并在数千项变更中重复同样的检查。

存放在 CLAUDE.md 中的指令描述项目、其约定和边界。独立的 REVIEW.md 则告诉审查者，特定代码仓库中的失败是什么样子。代码所有者可以识别敏感路径，并排除无关路径。

当审查者反复标记某个错误时，团队可以将经验前移。它可以添加 lint 规则、改进指令文件、修改技能，或创建新的自动检查。审查反馈随后便成为可复用的基础设施。

过去的失败会成为评估案例。Anthropic 表示，它收集了与事故、回滚和后续修复相关的拉取请求。工程师验证了底层漏洞，审查者如今每天都会针对这套案例运行。

这显著背离了由两个人进行的审查会面模式。该系统尝试将经验保存在可执行检查中，而非依赖个人记忆。每次事故都可以扩大组织未来的检测覆盖范围。

然而，人工审查仍处理无法被简化为局部正确性的问题。工程师决定某项功能是否应当存在、某种抽象是否会树立有害先例，以及证据是否足以支持部署。

他们还会检查敏感领域，包括计费、更新机制、持续集成和发布工作流。即使代码在局部看似正确，这些改动也可能带来广泛影响。

因此，这一流程并不认为机器在所有维度上都是更好的审查者。它将机器可以重复完成的阅读工作交给机器，同时将涉及目标、架构、不确定性和责任的决策交给人。

这种分工也改变了工程技能的要求。工程师需要明确意图、识别约束、设计验证方式、解读证据，并意识到何时代理优化了错误目标。阅读代码仍然有用，但它不再是理解系统的唯一途径。

Anthropic 的 Scion 团队提供了一个相关案例。工程师报告称，Claude 有时会采用低效或过度防御性的设计，这些设计符合局部模式。人类必须否决这些方向，因为他们理解系统层面的权衡。

“human in the loop”这一说法可能掩盖了这种角色。一位仅仅批准机器输出的人，保障作用有限；能够界定边界、选择证据并知道何时停止自动化的人，才能提供真正有效的控制。

对其他组织而言，教训不是移除审查者，而是区分机械检查与判断。当人们仍对高后果决策和不明确的证据保有决策权时，自动化覆盖才真正有价值。

Claude Code 审查如何避免无休止的代理循环

Anthropic 发现，除非审查流程被明确设计为能够收敛，否则 AI 作者和 AI 审查者可能制造无限量的工作。

更多审查并不必然更好。Anthropic 描述了一个 Claude Code 拉取请求：它在一夜之间经历了超过 50 轮审查与修复。最终，作者停止了这一循环。

审查者并非在每一轮都发现新的关键缺陷。Anthropic 利用版本历史检查重复出现的问题，发现约 59% 的问题涉及首次审查时就已存在的代码。

该代理不断定位额外的旧问题，而不是只评估新的修正。每条评论都会触发另一次修复、提交和审查。系统一直在运行，却没有高效地向可接受的最终状态推进。

这一失败说明了 AI 代码审查的一项独特风险。人类可以在几秒内忽略一条低价值建议；而编写代码的代理往往会执行它，产生新的差异，从而给审查代理提供更多材料。

Anthropic 随后加入了收敛控制。经过三轮后，审查者会要求作者重新考虑方案。后续轮次将聚焦于新的差异，而不是反复搜索整个变更。

审查者还会一次性报告整类相关缺陷。这样，作者可以修复所有实例，而不必在连续多轮中收到类似评论。此前已发布的问题不应再次出现。

Anthropic 表示，这些改动改善了其内部审查周期。据称，经过一轮审查与修复后即可通过的拉取请求占比，从 65% 升至 78%。

据称，需要五轮或更多轮次的拉取请求占比从 8.9% 降至 1.5%。通过前的平均审查次数从 2.08 降至 1.32。这些指标仍由公司自行报告，但它们针对的是许多代理工作流忽视的运营问题。

收敛之所以重要，是因为自动化劳动力并非没有薪酬就没有成本。每增加一轮，都会消耗模型容量、延误改动、产生更多代码，并增加后续检查必须审阅的材料。

当审查者对假设性威胁反应过度时，同样的问题也会出现。Anthropic 表示，对抗性审查可能变得目光短浅，鼓励过度验证或复杂化。一个被优化为发现潜在失败的系统，可能会制造新的维护成本。

基于风险的审查深度提供了一种控制方式。Anthropic 已正式推出的 Code Review 服务支持针对常规和关键仓库的不同审查级别。该公司称，大多数审查现在可在六到十分钟内完成。

然而，更快的审查者并不能解决根本的治理问题。团队仍需决定哪些发现重要、哪些路径值得更深入检查，以及多少轮次才是可接受的。

审查指令也可能成为隐藏的政策层。如果 CLAUDE.md、REVIEW.md 或分类提示中包含薄弱假设，代理就可能在整个仓库中一致地应用这些假设。

只有规则正确时，一致性才有帮助。团队需要为指导审查者的指令建立所有权、版本控制、评估案例和审查机制。否则，自动化可能会在人工察觉之前更快地扩大错误政策的影响。

这正是共享工程上下文变得重要的地方。采用代理的组织需要持久记录架构决策、事故经验和被否决的方案。一个可搜索的工程知识库可以帮助将这些上下文保留到单个审查线程之外。

Anthropic 的流程之所以有效，是因为它将审查者视为一个需要度量的系统。它追踪准确性、噪声、轮次、事故和开发者反馈。若安装 AI 审查者却没有这些反馈回路，复制的只是可见工具，而非运营模式。

Anthropic 的结果尚未证明什么

最强的主张仍属自行报告，Anthropic 尚未证明其结果能够迁移到基础设施、预算或故障容忍度不同的团队。

第一个不确定性涉及度量。Anthropic 报告称，合并的拉取请求数量增加了两倍以上，回滚占比下降了超过 40%。它并未发布底层数据集、绝对比率或事故严重程度分布。

回滚占比下降可能令人鼓舞，却仍可能掩盖重要结果。团队可能选择向前修复而非回滚、关闭功能开关，或容忍从未被贴上该标签的回归。回滚有用，但并不完整。

事故率提供了另一道护栏，但公开文章没有提供详细的事故时间序列。若没有严重程度和暴露范围数据，外部人士无法判断该流程究竟降低了风险，还是改变了处理失败的方式。

90% 的作者归属比例也存在类似模糊性。它没有说明这一度量统计的是生成行数、被接受行数、提交数还是其他单位。它同样没有披露，在最终代码形成前有多少人工提示、编辑和迭代。

Anthropic 的环境对这种方法格外有利。该公司控制模型，可以在并行审查者上投入大量算力，并围绕代理生成的工作负载开发内部基础设施。

其员工还会在公开发布前亲自使用 Claude Code。新功能可以依次经过内部部署、最新渠道，然后进入稳定渠道。功能开关让团队无需完整部署即可禁用某项行为。

运营医疗、金融、工业或安全关键系统的团队，可能面临不同要求。快速回滚无法消除所有后果。有缺陷的数据迁移、授权变更或外部操作，都可能造成不可逆的损害。

Anthropic 承认，不良合并的发现仍依赖作者、值班工程师、遥测和仪表板。它尚未具备这样的自动断路器：当回滚或事故增加时，自动提高审批要求。

这一缺口很重要，因为风险分类可能会过时。被标记为低风险的改动可能与隐藏依赖发生交互。一系列单独看来安全的改动，也可能形成危险的组合状态。

安全性带来了另一项担忧。Anthropic 使用自动化安全审查，但其自身的风险材料说明了为何人类监督仍然必要。其破坏评估将模型监控描述为一种持续演进的控制措施，而非完整保障。

社区反应提出了关于成本和理解的更广泛问题。一些开发者认为，Anthropic 能够维持在其他地方可能不具经济性的审查模式。另一些人担心，更少的人阅读差异会削弱对代码库的集体认知。

Anthropic 公开表示，Claude Code 团队中没有人维持对产品的完整心智模型。相反，当工程师需要时，会让 Claude 解释相关子系统。

这种方法可以保持解释的时效性，但也会形成依赖。如果生成的解释遗漏了某个交互，工程师就可能基于不完整的地图做出决策。同一模型家族也可能重复其所审查代码中固有的假设。

跨模型审查可以提供额外多样性，但并不会自动提高准确性。不同系统可能共享训练模式，也可能因无关原因而失败。重要的属性是独立证据，而不仅仅是不同的模型名称。

这些问题都不会否定 Anthropic 报告的结果。它们限制的是这些结果能够证明什么。该公司展示的是一套详细的内部流程以及令人鼓舞的方向性指标，而不是对人类代码审查的普遍替代方案。

三个信号将检验这一模式是否成立

下一项检验是：随着零人工合并扩大、审查产品进入其他公司，以及竞争对手采用不同控制措施，Anthropic 能否保持质量。

第一个信号是 Anthropic 自身的审批政策。其当前流程允许选定的低风险改动在自动检查通过后，无需单独的人类审查者即可合并。

关注这一边界是否会扩展到更多产品代码中。如果 Anthropic 加入其工程师希望具备的断路器，自动升级机制将使更广泛的部署更具可信度。事故上升或重新采用更严格审批都会削弱这一论点。

第二个信号来自使用自动化审查的外部组织的证据。Anthropic 已向 Team 和 Enterprise 客户发布 Code Review，这在陌生仓库和不同工程文化中创造了更广泛的测试。

有用的指标不会是评论数量或已审查拉取请求数量。团队应报告被采纳的发现、遗漏缺陷、误报、审查延迟、人工投入和生产事故。

Anthropic 之外的可比结果将加强这样一种主张：分层 AI 审查可以扩展。高噪声、不断增加的模型使用量，或未变化的事故率，则会表明 Anthropic 的成功依赖于其内部环境。

第三个信号是竞争反应。OpenAI、GitHub、Google、Cursor 及其他编码代理提供商，都面临生成代码与审查者能力之间的同样失衡。

它们的选择将揭示基于风险的审查是否会成为一种共同模式。竞争系统可能偏向跨模型审查、更强的沙箱机制、形式化验证、仓库特定评估，或更持久的人类审批。

开发者不应将这场讨论简化为 AI 能否发现漏洞。实际问题是，一个完整的审查系统能否分配注意力、保留责任，并在每一层都遗漏问题时安全恢复。

对于工程领导者而言，眼下的行动是度量。在改变审批政策前，建立审查时间、遗漏缺陷、误报、回滚率和事故严重程度的基线。没有这一基线，更快的合并看似是改进，实际却可能只是将成本转移到其他地方。

团队还应将可逆变更与不可逆变更区分开来。文档、标注过的界面调整以及内部工具，不应与身份验证、计费、迁移或发布基础设施采用同样的流程。

Anthropic 对 Claude Code 的审查方式，为许多团队很快将面临的问题提供了一个具体答案。它将审查视为分层控制系统，而不是某个人已逐行阅读所有代码的证明。

该公司披露的数据表明，这一答案值得测试，而非盲目照搬。如果你的智能体明天将代码产出翻倍，哪些证据能让审查人员在今天安全地不再逐一阅读所有内容？