AREX Feed Article
Anthropic Claude Code 团队详解六层代码评审流程，宣布 Code Review 向全部 Team 与 Enterprise 客户开放
Anthropic 的 Claude Code 团队于 10 月 15 日在 claude.dev 发表长文《》，公开这支团队在 AI 大量参与编码后如何做代码评审，以及这套流程如何演进。10 月 26 日，团队成员 Addy Osmani 在 X 上分享了，文末注明系对原文的改写。截至 10 月 27 日，该帖已获得 9,500 余次点赞、超过 149 万次浏览；原文于 10 月 16 日出现在 上，相关讨论获得 487 分。
这支团队此前称，Claude Code 约 90% 的代码由 Claude 编写，新文正面回答随之而来的疑问：「还有人读代码吗」「代码出错了怎么办」。团队强调评审并未取消，而是把大部分阅读工作自动化，人工注意力留给高风险判断。文中给出的自述数据是：今年 6 月至 9 月，合入 Claude Code 代码库的 PR（pull request，代码合并请求）数量翻了一倍以上，需回滚的 PR 占比下降超过 40%。文章同时宣布，Code Review for Claude Code 已向全部 Team 与 Enterprise 客户开放。以上数字均为团队自述口径，未经独立核实。
评审挪到写代码时：目标是「至多一人在环」
变更数量随代理写代码快速上升。文中援引的数据显示，Anthropic 的 monorepo（统一管理的单一代码仓库）每日合入变更从今年 5 月约 2,500 个增至 9 月的 30,000 个以上；Claude Code 不在该 monorepo 中，但同样承受压力。团队写道，在这种速度下，逐行人工评审「越来越难，甚至不可能」。
文章把代码评审的两个目的定为：在上线前发现并修正 bug，以及在团队中建立对代码库的共同理解。团队认为「有没有人读过这段代码」是衡量风险的不精确指标，真正该问的是：这次变更可能出什么问题，哪种检查（自动的或人工的）才是抓住它的正确手段。评审的时机因此改变：它不再是代码写完、PR 开出后等待的关卡，而更像他们所说的「写作时持续进行的拼写检查」，多数变更在被人工查看之前，已被 Claude 评审并修正过至少一次。
目标也随之量化：Claude Code 的各仓库（CLI、桌面与 Web 应用、移动应用）中，多数 PR 应在至多一人在环（可以是作者本人）的情况下合入，且回滚率与事故率不上升。团队跟踪每 PR 人工审批数的中位数与 95 分位、人工评论数、PR 等待人工的时长；回滚率与事故率是护栏，文中说，这两项若上升，说明人工时间没有被省下，只是被挪走了。
开 PR 之前：先让 Claude 拿出可运行的结果
流程共六层检查，外加一套快速回滚机制。第一层在 PR 创建之前：团队要求 Claude 做可运行的事，比如跑测试、跑构建、把截图与设计稿比对，并展示结果而不是声称任务完成；随后由一个以全新上下文工作的子代理复审 diff（代码改动差异）。开 PR 前，许多成员还会运行几个内部技能：寻找 bug、精简 diff、端到端验证，以及按设计规范检查 UI 变更。
Claude Code 创建者 Boris Cherny 在文中称，给 Claude 配备验证流程可能是获得高质量结果最关键的一步，估计能把输出质量提高 2～3 倍，验证的具体形式因领域而异：「可能简单到跑一条 bash 命令，或跑一个测试套件，或在浏览器或手机模拟器里测试应用。」今年 1 月，他也曾。
当自动评审者反复标记同一问题时，团队从源头修：改技能、加 lint（代码风格检查）规则，或更新两类说明文件。CLAUDE.md 向 Claude 提供项目背景（技术栈、约定、目标与非目标），每次评审都会加载；REVIEW.md 由代码所有者编写，告诉评审者自己负责的代码里什么最重要。文章说明，好的 REVIEW.md 很短：定义这个项目什么算失败、限制吹毛求疵、列出可忽略的路径、要求给出文件名加行号的证据，并要求总结里写明发现数量，没有问题时明确说没有。
每个 PR 先过 AI 评审：多代理找 bug，投票剔除误报
每个 PR 在人工评审前先由 Claude 评审。diff 对照整个代码库和作者声明的意图来分析：变更是否真的解决了问题、是否融入更大的系统、是否破坏其他部分；评审 bug 修复时还会追查根因。
发现先经其他代理过滤：多个代理并行找 bug；另一组代理对每条发现投票，票数足够才算数；只涉及风格、诊断或清理的发现直接剔除，这些过滤器先在团队自己的 PR 上做过 A/B 测试再上线。剩下的发现以内联评论呈现，按严重程度排序，标记为 Important（重要）、Nit（小问题）或 Pre-existing（先前已存在），最后一类用于标明问题并非该 PR 引入，避免作者被不公平追责。所有发现必须处理：修复，或给出理由关闭讨论。文中称，很多时候代理会在夜里把问题修掉，作者回到 PR 时，它已经又过了一轮评审。
这套评审能力也是团队的公开产品 Code Review for Claude Code：本地另有轻量版 /code-review 命令；管理员可按仓库配置 Quick、Standard 或 Deep 模式，Deep 适用于漏掉一个 bug 的代价高于评审耗时的场景。团队自述，自研究预览版发布以来，内部 PR 获得实质性评审意见的比例从 16% 升至 54%；超过 1,000 行的 PR 大多能查出问题，较小的 PR 大多返回干净结果。
可阻断的安全审查与按风险分级的人工审批
安全评审独立运行且能阻断合并：只要代码评审或安全评审还有未处理的发现，PR 就不得合入。作者要么修复，要么附简短理由关闭讨论，这是处理误报的方式；后续 commit 解决问题时，发现会自动关闭。同样的机制可用开源的 security review GitHub Action 或 /security-review 命令复现。
标准自动检查包括 lint、类型检查、全平台测试与构建。文中说，一个典型的 CLI PR 在任何人查看之前可能已跑过几十项检查；PR 模板要求写明如何测试、如何回滚，Claude 可以代答，但作者要对内容把关。
人工审批按变更风险分级。claude.dev 原文给出对应表：文档、文案、仅限内部的功能、藏在 feature flag（功能开关）后的增量变更属低风险，自动评审与安全检查全绿后无需人工审批；一般产品变更，以及缓存、自动更新器、系统提示词等敏感区域的变更需一人审批；最高风险的代码和少数路径需要两人。
分级由变更本身而非作者决定：一个分类器读取变更并定级，另一个分类器判断某次变更是否需要额外人工。所有者标记为敏感的路径与任何 CI（持续集成）workflow 文件始终需要额外审批；只有仓库信任名单上的作者（通常是拥有该仓库的团队）享受放宽流程，其他人需要第二人审批。代理的审批不计入人工审批；若 PR 由代理撰写，操作代理的人始终算作必需评审人之一。一次审批只对一个 commit 有效，出现不可信的新 commit，比如代理推送了代码，或有人手工解决合并冲突，PR 就必须重新审批。
合入之后：merge queue、功能开关与快速回滚
合入由 merge queue（合并队列）把关：所有检查在应用了该变更的最新 main 上重跑，避免两个各自通过的 PR 合在一起弄坏 main。新功能通常先藏在 feature flag 后向 Anthropic 员工开放，团队自述他们重度使用自家产品，常常先于用户发现回归；公开发布时先推 latest 渠道，stable 渠道随后。
最后一层是快速发现与回滚。flag 可以在不部署的情况下关闭；Claude Code 团队实行每周 on-call（值班）轮换，每次事故复盘都会追问哪一层本该拦住这个问题。发现坏合入仍要靠作者、on-call 以及回滚与事故看板。团队承认还没有根据这些数字自动收紧审批的熔断机制，claude.dev 原文补充说，团队工程师希望在更多代码走向零人工合入之前先有这种机制。文中还引用一位团队成员的说法：放慢速度、减少产出确实能提高准确率，但主要原因是总工作量变少了，团队更愿意提高发现和修正问题的速度。
用事故当评测集：评审系统每天被打分
团队把事故当成了评审系统的评测基准。他们收集了曾引发事故的 PR、对应的 fix-forward（向前修复而非回滚）与回滚记录，由熟悉代码的工程师逐条确认 bug 的位置与真实性，形成评测集；评审系统每天对整个集合评测，每次事故补充新案例，系统的每次改动都要重新跑完全部案例。噪音用人的反应来衡量：每条评审意见按对方如何处理分类，修复、驳回、说明属有意为之、认为无关紧要；团队还在已知干净的 PR 上运行评审系统，统计它多久报告一次可能诱使他人做出有害修改的问题。文中写明的优先级是：先抓真 bug，其次减少评审轮数。
收敛是文章点出的另一个问题。代理作者与代理评审者可能互相空转：CLI 项目曾有一个 PR 在一夜之间循环了五十多轮评审与修复，最后靠人工叫停。对反复被标记的代码做 git blame（Git 的逐行修改溯源）后，团队发现约 59% 从评审系统第一轮起就已存在，评审者很少发现新 bug，只是每轮多翻出几条旧的。此后团队限制评审轮数：三轮后要求作者重新审视方案，数轮之后只复审 diff，指出 bug 的类别以便一次修完所有同类问题，不再重复报告已提出的发现。claude.dev 原文给出的前后对比：一轮评审即通过的比例从 65% 升至 78%，需要五轮以上的 PR 从 8.9% 降至 1.5%，平均评审轮数从 2.08 降至 1.32。
留给人的是五类决定：要不要做这件事（方向、品味与范围）、高风险代码（计费、自动更新器、CI workflow）、架构、核实证据（测试输出、命令结果、截图与评审发现），以及为每一次上线的变更负责，文中说，无论代码是谁敲的，都有人来担责。
至于评审的第二个目的，即传递对代码库的理解，团队坦言没有正式机制，也没人在脑子里保留 Claude Code 的完整心智模型。谁想了解某一块代码，就让 Claude 为那一小片生成讲解，几分钟就能拿到与当前代码同步的说明；有人还会让 Claude 把这一块做成一个可视化的小 artifact（讲解产物）。团队默认在公开的 Slack 频道工作，彼此能看到对方在构建什么。
文章还附上供其他团队复用的清单，称这套做法的大部分组件已经可用：在 CLAUDE.md 里列出可运行的检查、本地运行 /code-review 与 /security-review、设置 merge queue、按风险渐进放宽审批，并用事故与回滚记录积累评测集。至于边界本身，文中写道：Code Review 产品只发布发现，最终批准仍由人作出；但在自家仓库，所有者已开始决定哪些低风险变更在自动检查通过后直接合入，「这条边界还会继续演化」。