Claude Code 团队怎么做代码审查：7 层检查与 /code-review 实测

Anthropic 在 2026 年 10 月 15 日发表的《How the Claude Code team does code review》（claude.dev 工程博客）讲的不是取消代码审查，而是把大部分"读代码"交给机器：Claude 先跑测试证明改动能用，每个 PR 都过一遍 AI 审查和安全审查，CI 全部通过后，再按改动的风险决定需要 0、1 还是 2 个人批准；合并之后还有合并队列、功能开关、分阶段发布和快速回滚兜底。人保留的是"要不要做"、定架构，以及计费、自动更新、CI 这类高风险代码。

想照着搭，先做四件事。要让审查执行的项目规则写进 CLAUDE.md，因为本地 /code-review 只读它、不读 REVIEW.md，2026 年 10 月 23 日的实测结果也是这样；只给 GitHub 上托管 Code Review 用的审查规则才写进 REVIEW.md。PR 模板加"测试方式、风险、如何回滚"三栏。用 CODEOWNERS 和分支保护让认证、计费、CI 与发布流程、安装程序的改动必须有人批准，并给 AI 审查轮次设一个上限。

条件要分清：托管的 Code Review 只给 Team 和 Enterprise 计划，而且从不批准、也不阻断合并，Anthropic 内部"有未处理的发现就不能合并"是他们在自己仓库里另外配的。任何计划都能用本地 /code-review；用 claude.ai 账号登录的 Pro、Max 用户还可以跑云端的 ultrareview。

Claude Code 团队的 7 层代码审查：每层查什么，你用什么替代

一次 Claude Code 改动从作者电脑到 stable 渠道，要经过 7 层检查：提 PR 前的自证、每个 PR 的 AI 审查、能阻断合并的安全审查、CI 自动检查、按风险分级的人工批准、合并队列加分阶段发布，最后是快速发现与回滚。原文的说法是每一层都会漏掉一些问题，能穿过全部几层的很少，剩下的交给回滚。下表左两列来自原文，右列是外部团队现在就能用上的对应工具。

第 1 层被放在最前面，是因为 Claude Code 的作者 Boris Cherny 认为，让 Claude 有办法验证自己的工作大概是拿到好结果最重要的一件事，他估计能让最终结果好两到三倍；这是他本人的估计，不是测量值。同一个审查意见反复出现时，团队不会每次在 PR 里重复指出，而是回到源头改：改技能、加一条 lint 规则，或者更新 CLAUDE.md、REVIEW.md。CLAUDE.md 每次审查都会加载，所以大仓库里要写短，细节指向其他文档，它什么时候加载、放多长合适，见 Claude Code Memory 指南（2026）：CLAUDE.md、auto memory 与插件怎么分工。

第 2 层的 AI 审查是多个代理同时找 bug，另一组代理对每条发现投票，足够多的代理认同才发出来，只涉及风格、诊断信息或清理的发现直接丢弃。留下的发现按严重程度排序，作为行内评论贴在 PR 上，并打上三种标签之一：Important 是合并前应该修的 bug，Nit 是值得修但不阻塞的小问题，Pre-existing 是代码库里本来就有、不是这个 PR 引入的 bug，单独标出来是为了不让作者背锅。原文说，研究预览上线时，内部 PR 收到实质性审查意见的比例从 16% 升到 54%；超过 1,000 行的 PR 多数会被挑出问题，小 PR 多数审完没有发现。

哪些改动 0 人、1 人、2 人批准：由改动决定，不由作者决定

Claude Code 仓库把改动分成三档，需要几个人批准由改动本身决定，而不是看谁写的。一个分类器读改动、定风险档；另一个分类器再问一次"这次改动是否仍需要多一个人"，哪怕档位说不用。

表外还有四条规则，决定了"0 人批准"不是谁都能走的捷径。第一，只有仓库信任名单上的作者（大多是负责这块代码的团队）才能走低档，其他人一律需要第二个人批准；代码负责人标成敏感的路径和任何 CI workflow 文件，永远需要人。第二，AI 代理的批准永远不算人的批准，自动审查可以放行低风险改动，但填不了要求真人的名额。第三，代理写的 PR 里，指挥代理的那个人算一个必需的审查者，就像代码是他自己敲的。第四，一次批准只对应一个具体提交，之后如果出现系统无法担保的新提交，比如代理又推了一次、或者有人手动解决了合并冲突，就要重新批准。

Hacker News 的讨论里有人质疑：让模型写文档、却没人读就合并，太冒险。放在上面四条规则里看，"文档 0 人批准"只对信任名单上的作者、在 AI 审查和安全审查都通过之后才成立。你的团队不必从这一档起步；原文给外部团队的建议恰好相反：先严，有了回滚率和事故率的数据再逐步放宽。

90%、PR 翻倍、回滚降 40%：这些数字各衡量什么

原文的几个数字口径各不相同，最容易被误读的是两个："回滚降 40%"是需要回滚的 PR 所占比例下降，不是回滚次数下降；"每天 3 万次改动"是 Anthropic 单一大仓库（monorepo）的数字，不是 Claude Code 仓库的。所有数字都是 Anthropic 自报，没有公布基数，外部无法复算。

只盯回滚率会不会走样，同一个讨论里也有人提出过。原文的设计是把回滚率和事故率当护栏，而不是目标：真正要压低的是人花的时间，用每个 PR 的人工批准数（中位数和 95 分位）、人工评论数、PR 等人处理的时长来量；如果回滚和事故上升，说明省下的时间只是挪到了修 bug 上。原文也承认缺一块：还没有"回滚和事故数字一变就自动收紧批准"的熔断机制，工程师希望先有它，再让更多代码走 0 人批准。

按你的计划能照搬哪些：/code-review、ultrareview 与 Code Review 对照

任何计划都能照搬的是本地 /code-review，它读 CLAUDE.md，计入你的会话用量；用 claude.ai 账号登录还能跑云端的 ultrareview；只有 Team 和 Enterprise 能开托管的 Code Review，也只有它会读 REVIEW.md。下表的事实截至 2026 年 10 月 23 日，来自 Claude Code 的 Code Review 文档、本地 /code-review 文档和 ultrareview 文档。

本地 /code-review 默认审当前分支领先上游的提交加未提交的改动，也可以指定 PR 编号、分支区间、提交区间或路径，比如 /code-review 1234、/code-review main...my-feature。effort 从 low 到 max：low 只报最有把握的发现，误报少；往上覆盖面变宽。它作为后台子代理在独立上下文里运行，不占你的对话；加 --fix 会让 Claude 直接按发现修改工作区。另一个常被拿来比较的 /simplify 只做清理并直接改，找 bug 还是用 /code-review，先装哪些技能见 Claude Code Skills 推荐：先用哪个、怎么安装与确认生效。

托管 Code Review 在 2026 年 10 月 15 日结束研究预览、正式面向 Team 和 Enterprise 开放，官方公告说多数审查从预览期的约 20 分钟缩短到 6–10 分钟。Owner 在 Admin settings > Claude Code 里开启、安装 Claude GitHub App、选择仓库，再给每个仓库选 Quick、Standard（默认）或 Deep 三个审查级别。开发者用 Bedrock 等云厂商跑 Claude Code 的团队，也需要一个 Team 或 Enterprise 的 Claude 组织才能用它。

本地 /code-review 读不读 REVIEW.md：2026 年 10 月 23 日实测

不读。2026 年 10 月 23 日，在一台 macOS 电脑上用 Claude Code 2.1.309、以 Pro 账号登录，对一个演示仓库各跑了一次 claude -p "/code-review low" --output-format json：审查规则只写在 REVIEW.md 里时，这条规则没有被执行；把同一句话追加进 CLAUDE.md（REVIEW.md 原样保留）、其他不动再跑一次，它被标成了 Important。结果和本地 /code-review 文档的说法一致："审查遵循你的 CLAUDE.md……不读 REVIEW.md"。

演示仓库的 main 分支只有一个计算购物车小计的函数，CLAUDE.md 写了一条"金额一律用整数 cents 存储和计算，不用浮点数"，REVIEW.md 写了一条"改动行里出现 TODO 注释算 Important，我们不合并 TODO"。待审分支 add-discount 新增了下面这个函数，故意埋了 4 个问题：

// Apply a percentage discount to the first `limit` items only.
// TODO: support coupon codes
function discountedTotal(items, percent, limit) {
  let total = 0;
  for (let i = 0; i <= limit; i++) {
    const line = items[i].priceCents * items[i].qty;
    total += line * (1 - percent / 100);
  }
  for (let i = limit; i < items.length; i++) {
    total += items[i].priceCents * items[i].qty;
  }
  return total;
}

问题一是第一个循环用了 i <= limit，多打折一件，limit 大于等于商品数时还会读到 undefined 抛 TypeError；问题二是第二个循环从 limit 开始，下标为 limit 的商品被算了两次；问题三是用浮点数算金额，违反 CLAUDE.md；问题四是那行 TODO，只有 REVIEW.md 说它是 Important。第一次运行用了 17.2 秒，找到了前三个问题，第三条明确引用了 CLAUDE.md 的整数 cents 规则，但对 TODO 只字未提。第二次只是把 TODO 那条规则追加进 CLAUDE.md，用了 8.7 秒，前三个问题照样找到，并多出一条："本次改动加了一条 // TODO: support coupon codes，按项目规则，带 TODO 的改动不能合并，属于 Important。"输出是中文，是因为这台电脑的 Claude Code 设置了中文回复。

这次测试的边界要说清楚。每种条件只跑了一次，effort 是 low，只在一台机器上，模型输出每次会有差异，两次耗时不同不能说明什么。命令返回的成本字段分别是 $0.19 和 $0.09，这是 CLI 按 API 价格估算的会话成本，不是账单。托管 Code Review、ultrareview、/security-review 和下一节的合并门禁脚本都没有跑，相关内容来自 Anthropic 的官方文档。实际影响很直接：同一条规则如果既要本地审查执行、又要托管 Code Review 执行，写进 CLAUDE.md；只有专门针对 PR 审查的规则（严重程度怎么定、哪些路径跳过、Nit 最多几条）才放 REVIEW.md。

Code Review 会挡住坏 PR 吗：产品不挡，Anthropic 是自己配的

不会。Code Review 的 PR 审查文档写明，一次审查从不批准也不阻断 PR，它在 PR 上留下的 "Claude Code Review" 检查结论是 neutral（或在某些推送后为 skipped），永远不会是失败；而按 GitHub 关于受保护分支的文档，必需状态检查的结果为 successful、skipped 或 neutral 时都算通过，所以把它设成必需检查也挡不住合并；不回应任何发现直接合并也可以，除非你的仓库规则另有要求。Anthropic 原文里"有未关闭的 bug 或安全发现就不能合并"，是他们在自己仓库里配的规则，原文结尾也说 Code Review 产品只发发现、不做批准。

要在自己的仓库达到同样效果，有两种做法。简单的一种是在 GitHub 分支保护里打开 Require conversation resolution before merging（合并前必须解决所有对话）：Code Review 的发现以行内评论对话的形式贴出，不修复也不写理由关闭，就合并不了，这和 Anthropic"每条发现都要回应"的做法一致，只是 Nit 也会拦住。另一种是在自己的 CI 里读审查结果：检查详情的最后一行是一段 HTML 注释，形如 <!-- bughunter-severity: {"nit":1,"normal":2,"pre_existing":0} -->，其中 normal 就是 Important 的数量，大于 0 时让 job 失败。官方文档给的读取命令如下（这一段没有在真实仓库上跑过）：

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID --jq '
  (.output.text | split("\n") | last
    | scan("^<!-- bughunter-severity: (.*) -->$")[0] | fromjson)?
  // error("no severity line")'

用这种做法时注意文档里的两个例外：找不到这一行时代表"没有结论"，不是"零个问题"，审查失败、超时、被取消或被新审查取代时都没有这一行；标题以 Code review not repeated 开头时表示沿用了上次结果、仍有 Important 未关闭，也应该让 job 失败。

照着搭一套：从 CLAUDE.md 到分支保护的 6 个步骤

下面的步骤按 Anthropic 原文末尾给外部团队的清单排序，从任何计划都能做的本机检查开始，到需要 Team 或 Enterprise 的托管审查，再到 GitHub 上的批准规则和发布兜底。第 1、2 步任何计划都能做，第 3 步的 AI 审查可以用托管 Code Review，也可以用自己 CI 里的 Claude Code GitHub Action。

1. 写一个短的 CLAUDE.md，列出 Claude 能自己跑的检查（测试、构建、lint 命令）和审查必须执行的项目规则，例如"金额一律用整数 cents"。格式化和 lint 交给 hook 自动跑，不靠审查提醒，做法见 Claude Code Hooks、Skills 与斜杠命令：区别、选型和最小配置。

2. 提 PR 前在本机跑 /code-review 和 /security-review，或者让一个新上下文的子代理审一遍 diff，并要求它贴出测试输出，而不是只说"已完成"。

3. 给 PR 模板加三栏，并把 CI 设为必需检查。Claude 可以代填，但提出改动的人负责确认：

   markdown复制

   ## 测试方式
   <!-- 跑了哪些命令、结果是什么；界面改动附截图 -->
   
   ## 风险
   <!-- 低 / 中 / 高，以及理由：动了哪些敏感路径 -->
   
   ## 如何回滚
   <!-- 关哪个功能开关，或直接 revert 哪个提交 -->

4. 先在一个仓库开 AI 审查，调几周 REVIEW.md 再推广。REVIEW.md 写短：这个仓库里"出错"长什么样、Nit 最多几条、跳过哪些路径、要求给出文件和行号作为证据、总结第一句先报数量，没问题就直说没问题。审查里反复出现的同类意见搬进这个文件。注意它从 PR 的基础分支或默认分支读取，从不读 PR 自身的修改，所以改 REVIEW.md 要先单独合并；降低严重程度、排除路径、限制 Nit 数量这几类指令，只有根目录的 REVIEW.md 位于受保护的默认分支上时才生效。

   markdown复制

   # Review instructions
   
   ## 什么算 Important
   只有会改变行为、泄露数据或妨碍回滚的问题才算 Important；命名和重构建议最多算 Nit。
   
   ## 限制 Nit
   每次审查最多报 3 条 Nit。
   
   ## 不要报告
   - CI 已经检查的 lint、格式、类型错误
   - src/gen/ 下的生成文件和所有 *.lock 文件
   
   ## 证据
   关于行为的结论必须给出 file:line，不能凭函数名推测。总结第一句先写发现数量，没有要修的就直接写"没有需要修复的问题"。

5. 写下风险分级，用 CODEOWNERS 和分支保护落地。分级按改动定，不按作者定；先严，有数据再放宽，低档只留给信任的作者。认证、计费、CI 与发布 workflow、安装程序这些路径写进 CODEOWNERS，分支保护里打开 Require review from Code Owners 和 Dismiss stale pull request approvals when new commits are pushed（有新提交时作废旧批准），并且不让任何机器人账号的批准顶替必需的人工批准。

   复制

   # .github/CODEOWNERS：这些路径的改动必须由对应负责人批准
   /src/auth/            @your-org/security
   /src/billing/         @your-org/payments
   /.github/workflows/   @your-org/release
   /scripts/install/     @your-org/release

6. 合并之后靠快速撤回兜底。用合并队列、功能开关、先内部试用、分阶段发布和一步回滚；把出过的事故和回滚收集成评测集，审查者的提示词、工具或模型一变就重新打分；用人花的时间做主指标，回滚率和事故率做护栏。

"某些路径必须 2 人批准"和"由分类器自动定风险档"在 Anthropic 用的是内部分类器，公开产品里没有对应物；GitHub 的必需批准人数按分支设置，开始时可以先用团队约定加 CODEOWNERS 覆盖最敏感的路径。

AI 作者和 AI 审查者互相改个没完：4 条收敛规则

审查必须能收敛。Claude Code 团队有一个 CLI 的 PR 在一夜之间来回审查、修复了 50 多轮，直到作者手动叫停；用 git blame 一查，审查者反复标出的问题里约 59% 是它第一轮时就已经存在的旧代码，也就是说它很少发现新 bug，只是每轮多挑出几个老问题。作者是 AI 代理时噪音的代价更高：人看到一条 Nit 几秒钟就能忽略，代理会去修，于是又多一次提交、又多一轮审查。团队现在把"几轮才通过"和召回率一起跟踪，并改了重审规则：

• 轮次上限：三轮之后，审查者请作者退一步，重新考虑整个做法。
• 只审新增 diff：前几轮之后，重审只看新的改动。
• 按类标问题：标出整类 bug，让作者一次修完所有同类位置，而不是只改被点到的那一行。
• 不重复：已经发过的发现不再重复发。

这几条是 Anthropic 改的审查者行为，用自己的代理循环时可以把它们写进 CLAUDE.md 或代理的指令里。用托管 Code Review 时，对应的开关是仓库的 Review runs 设置：After every push（每次推送都审）是从管理页加入仓库时的默认值，审得最多；改成 Once after PR creation（PR 创建后审一次）或 Manual（评论 @claude review 才审），再按需手动触发，就能控制轮次。团队写下的优先级也值得照抄：先抓真 bug，其次才是减少审查轮次。

代码审查要花多少钱：本地按会话用量，托管和 ultrareview 走用量积分

本地 /code-review 和会话里的其他操作一样，计入套餐用量或 API 账单，没有额外费用；上面那两次 low 级别的测试，CLI 估算的会话成本分别是 $0.19 和 $0.09。那是一个很小的演示仓库，改动只有十几行，改动更大、effort 更高时花费会相应增加。

托管 Code Review 没有固定单价。按 Code Review 费用文档，它按 token 用量从用量积分里扣，和套餐自带的用量分开，记在组织账上而不是开 PR 的人头上；每次的花费随审查级别、改动大小、周边代码的复杂度和需要核实的候选问题数增长。估算方法是先小范围试点：设一个月度支出上限，开几个仓库并设成 Once after PR creation 或 Manual，跑一阵后在 Admin settings > Claude Code 的仓库表里读"平均成本"，乘以每月 PR 数；用 After every push 的话再乘以每个 PR 的平均推送次数。支出上限、组织上限或积分余额任何一个用完，审查会被跳过，PR 上会留言说明原因。研究预览期间流传的"每次 $15–25"出自第三方转述，正式版文档里已经没有固定单价。另外，符合条件的 Enterprise 组织可以在 2027 年 1 月 15 日前领取至少 $10,000 的 Code Review 积分，领取后 30 天过期，有附加条款。

ultrareview 的 3 次免费是每个 Pro、Max 账号一次性的，不会刷新；用完后必须先打开用量积分才能启动付费审查，启动前的确认框会显示本次的预估费用。用量积分怎么开、怎么扣，见 Claude 额外使用费用：用量积分、Max 和 Claude Code 账单怎么判断。

还有人读代码吗：Claude Code 团队留给人的 5 件事

有，但人读的不再是每一行 diff，而是机器判断不了的东西。原文列出的人类职责有五项：决定这个东西该不该做，也就是方向、品味和范围；审计费、自动更新、CI workflow 这类高风险代码；审会被别人照抄的架构；读证据，包括测试输出、跑过的命令和返回结果、截图、审查者的发现，"如果你说不出这些检查会漏掉什么，就请人做一次真正的审查，而不是快速批准"；以及为每个上线的改动负责，不管是谁敲的代码。

代码审查原本还有一个作用是让团队了解代码库，机器读了大部分代码之后，Claude Code 团队没有为此设正式流程。要改哪一块，就让 Claude 为那一小块写一份讲解，有人还会让 Claude 做一个可视化的小页面；加上团队默认在公开的 Slack 频道里工作，别人在做什么一直看得见。改方向的意见要在讨论串里尽早提，而不是等 PR 做完了再挂一个阻塞评论；谁合并、谁负责，出了问题通常由作者来修，但复盘看的是系统哪一层漏了，不是追责。