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

> Claude Code 团队让 AI 审每个 PR，按风险定 0–2 人批准；托管 Code Review 不阻断合并，本地 /code-review 只认 CLAUDE.md。

- URL: https://blog.laozhang.ai/zh/posts/claude-code-team-code-review
- Published: 2026-10-23
- Updated: 2026-10-23
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Topic: Claude Code
- Tags: Claude Code, 代码审查, Code Review, Anthropic, AI 编程

---
Anthropic 在 2026 年 10 月 15 日发表的[《How the Claude Code team does code review》（claude.dev 工程博客）](https://claude.dev/blog/solving-code-review-at-anthropic/)讲的不是取消代码审查，而是把大部分"读代码"交给机器：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 自动检查、按风险分级的人工批准、合并队列加分阶段发布，最后是快速发现与回滚。原文的说法是每一层都会漏掉一些问题，能穿过全部几层的很少，剩下的交给回滚。下表左两列来自原文，右列是外部团队现在就能用上的对应工具。

![Claude Code 团队的 7 层代码审查：前 5 层在合并前、后 2 层在合并后，每层旁边列出外部团队可用的替代工具](https://blog.laozhang.ai/posts/zh/claude-code-team-code-review/img/review-layers.webp)

| 层 | Claude Code 团队查什么、谁拍板 | 你能用的替代 |
| --- | --- | --- |
| 1. 提 PR 前自证 | 让 Claude 跑测试、构建或和设计稿比截图，并贴出输出；再由一个新上下文的子代理审一遍 diff；不少工程师还会跑内部技能找 bug、精简 diff、端到端验证 | 本地 `/code-review`、`/security-review`，或自己写的审查子代理；`CLAUDE.md` 里列出能跑的检查命令 |
| 2. 每个 PR 的 AI 审查 | 对照整个仓库和 PR 的意图看改动是否解决问题、是否弄坏别处；修 bug 的 PR 要找根因；每条发现都要修复，或写明理由后关闭 | 托管的 Code Review（Team/Enterprise），或在自己 CI 里跑 Claude Code GitHub Action |
| 3. 能阻断的安全审查 | bug 审查或安全审查还有未关闭的发现时，PR 不能合并；误报靠写一句理由关闭 | 开源的 `claude-code-security-review` GitHub Action 或 `/security-review` 命令，加上 GitHub 的"合并前必须解决所有对话" |
| 4. CI 自动检查 | lint、类型检查、各平台测试、构建，一个普通 CLI 的 PR 可能先跑几十项；PR 模板写清怎么测的、怎么撤回，Claude 可以代填，但由提出改动的人签字 | 设为必需的 CI 检查，加上 PR 模板 |
| 5. 按风险的人工批准 | 分类器按改动定档，需要 0、1 或 2 人；敏感路径和 CI workflow 文件永远要人 | 书面的风险分级、CODEOWNERS、分支保护 |
| 6. 合并队列与分阶段发布 | 合并队列把改动合到最新 main 上重跑全部检查；新行为先放在开关后给 Anthropic 员工用；公开版本先进 latest 渠道，stable 随后 | 合并队列、功能开关、内部试用、灰度发布 |
| 7. 快速发现与回滚 | 开关不用重新部署就能关；每周轮值 on-call；事故复盘只问"哪一层本该拦住" | 一步回滚、值班、按层复盘 |

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

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

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

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

| 风险档 | 例子 | 需要几个人批准 |
| --- | --- | --- |
| 低 | 文档、文案、仅内部可见的功能、放在功能开关后面的新增代码 | 自动审查和安全检查都通过后，不需要人 |
| 中 | 普通产品改动，以及缓存、自动更新、系统提示词这类敏感区域 | 1 人 |
| 高 | 风险最高的代码，加上少数永远要两人批准的路径 | 2 人 |

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

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

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

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

| 数字 | 衡量的是什么 | 要注意 |
| --- | --- | --- |
| 约 90% | Claude 写的代码占 Claude Code 自身代码的比例 | 原文没说剩下约 10% 是哪些代码 |
| 合并 PR "翻倍以上" | 2026 年 6 月到 9 月，Claude Code 代码库合并的 PR 数量 | 没有公布绝对数量 |
| 回滚比例降 40% 以上 | 同期合并的 PR 中需要回滚的比例 | 比例不是次数：如果恰好是 PR 数翻倍、比例降 40%，回滚次数是原来的 2 × 0.6 = 1.2 倍 |
| 每天 3 万次以上 | 2026 年 9 月 Anthropic 单一大仓库每天落地的改动，5 月约 2,500 次 | Claude Code 在独立仓库里，这个数字不属于它 |
| 16% → 54% | 研究预览上线时，内部 PR 收到实质性审查意见的比例 | 预览于 2026 年 3 月 9 日上线，不是正式版之后的数据 |

只盯回滚率会不会走样，同一个讨论里也有人提出过。原文的设计是把回滚率和事故率当护栏，而不是目标：真正要压低的是人花的时间，用每个 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 文档](https://code.claude.com/docs/zh-CN/code-review)、[本地 /code-review 文档](https://code.claude.com/docs/en/code-review-local)和 [ultrareview 文档](https://code.claude.com/docs/en/ultrareview)。

| 工具 | 谁能用 | 读哪些规则文件 | 怎么计费 | 能不能挡住合并 |
| --- | --- | --- | --- | --- |
| 本地 `/code-review`（别名 `/review`） | 任何计划 | `CLAUDE.md`；不读 `REVIEW.md` | 和会话其他操作一样，计入套餐用量或 API 账单 | 不能，结果出现在会话里；加 `--comment` 可贴到 GitHub PR 或 GitLab MR |
| ultrareview（`/code-review ultra`） | 用 claude.ai 账号登录；Bedrock、Google Cloud Agent Platform、Microsoft Foundry、开了零数据保留或 HIPAA 配置的组织不能用 | 文档没有写 | Pro、Max 各有 3 次一次性免费，之后通常每次 $5–25 用量积分 | 不能；结果回到会话，可以选择贴到 PR |
| 托管 Code Review | Team、Enterprise 组织，仓库在 GitHub，由组织 Owner 开启 | `CLAUDE.md` 和 `REVIEW.md` | 按 token 从组织的用量积分里扣，没有固定单价 | 不能，检查结论永远是 neutral，GitHub 的必需检查把 neutral 当作通过 |
| 自己 CI 里的 Claude（GitHub Actions、GitLab CI/CD） | 有 Claude API key 或云厂商凭证的人 | 由你的 workflow 决定 | API 或云厂商计费 | 取决于你的 workflow：job 跑完发评论就算成功，挡不住；要让它在有发现时失败，再设为必需检查 |

本地 `/code-review` 默认审当前分支领先上游的提交加未提交的改动，也可以指定 PR 编号、分支区间、提交区间或路径，比如 `/code-review 1234`、`/code-review main...my-feature`。effort 从 `low` 到 `max`：`low` 只报最有把握的发现，误报少；往上覆盖面变宽。它作为后台子代理在独立上下文里运行，不占你的对话；加 `--fix` 会让 Claude 直接按发现修改工作区。另一个常被拿来比较的 `/simplify` 只做清理并直接改，找 bug 还是用 `/code-review`，先装哪些技能见 [Claude Code Skills 推荐：先用哪个、怎么安装与确认生效](https://blog.laozhang.ai/zh/posts/claude-code-best-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 文档](https://code.claude.com/docs/en/code-review-local)的说法一致："审查遵循你的 `CLAUDE.md`……不读 `REVIEW.md`"。

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

```js
// 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 设置了中文回复。

![两次本地 /code-review 对照：TODO 规则只写在 REVIEW.md 时没被报出，追加进 CLAUDE.md 后被标为 Important，其余三个问题两次都找到](https://blog.laozhang.ai/posts/zh/claude-code-team-code-review/img/review-md-test.webp)

这次测试的边界要说清楚。每种条件只跑了一次，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 审查文档](https://code.claude.com/docs/en/code-review-pull-requests)写明，一次审查从不批准也不阻断 PR，它在 PR 上留下的 "Claude Code Review" 检查结论是 neutral（或在某些推送后为 skipped），永远不会是失败；而按 [GitHub 关于受保护分支的文档](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)，必需状态检查的结果为 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 失败。官方文档给的读取命令如下（这一段没有在真实仓库上跑过）：

```bash
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 与斜杠命令：区别、选型和最小配置](https://blog.laozhang.ai/zh/posts/claude-code-hooks-slash-commands-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（有新提交时作废旧批准），并且不让任何机器人账号的批准顶替必需的人工批准。

   ```text
   # .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 费用文档](https://code.claude.com/docs/en/code-review-costs)，它按 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 账单怎么判断](https://blog.laozhang.ai/zh/posts/claude-extra-usage-cost)。

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

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

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

## 参考来源

本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-10-23。

- [《How the Claude Code team does code review》（claude.dev 工程博客）](https://claude.dev/blog/solving-code-review-at-anthropic/) (claude.dev)
- [Claude Code 的 Code Review 文档](https://code.claude.com/docs/zh-CN/code-review) (code.claude.com)
- [本地 /code-review 文档](https://code.claude.com/docs/en/code-review-local) (code.claude.com)
- [ultrareview 文档](https://code.claude.com/docs/en/ultrareview) (code.claude.com)
- [Code Review 的 PR 审查文档](https://code.claude.com/docs/en/code-review-pull-requests) (code.claude.com)
- [GitHub 关于受保护分支的文档](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) (docs.github.com)
- [Code Review 费用文档](https://code.claude.com/docs/en/code-review-costs) (code.claude.com)