Claude Code Review正式GA：永不阻断PR，Anthropic内部却强制卡点

Anthropic 的代码审查产品 Code Review 在 10 月 15 日结束研究预览阶段，正式面向 Team 与 Enterprise 组织开放（GA）。但一个耐人寻味的反差是：在 Anthropic 自家的 Claude Code 仓库里，只要审查发现（finding）仍未关闭，PR 就不允许合并；而在对外售卖的版本中，审查永远不会让检查失败，也不会批准或阻塞你的 PR。这个差异并非疏漏，而是产品定位与内部实践之间的一次刻意切分。

产品层面的设计：审查只提供信息，不替你做决定

据官方公告，Code Review 现在对 Claude Team 和 Enterprise 组织可用。管理员可以为每个仓库选择 Quick、Standard（默认）或 Deep 三档审查深度；与预览阶段相比，大多数审查现在快了约 3 倍，耗时从约 20 分钟降到 6 到 10 分钟。

具体机制上，多个 agent 并行读取 diff 及其周边代码，再由一轮验证环节丢弃误报，之后才发布结果。PR 上会出现内联评论，以及一个名为 Claude Code Review 的检查运行（check run），每条发现被标记为 Important、Nit 或 Pre-existing。审查运行在 Anthropic 的基础设施上，只有只读权限，不会构建或执行你的代码。

产品文档说得非常直白：「审查永远不会批准或阻塞你的拉取请求，检查运行也永远不会以失败告终。」这与官方团队博客的表述一致——批准 PR 始终是「人的决定；产品发布的是发现，不是批准」。

换句话说，想让发现真正挡住合并，需要你在仓库侧自己配置规则。文档给出了两种做法，后文会展开。

check run 是 GitHub 的 Checks API 中的一种对象，用来向 PR 或 commit 报告自动化任务（如 CI、lint、安全扫描）的结果。每个 check run 有状态（queued、in_progress、completed）和结论（success、failure、neutral、cancelled 等），并可以附带详情文本和注释。分支保护规则可以要求某些 check run 必须完成且结论为 success 才能合并。本文中的 Claude Code Review 检查运行就是这样一个对象——它总是以非失败结论结束，因此不会天然阻塞合并；要实现阻断，需要外部脚本解析其详情文本，或借助其他 PR 状态（如未解决对话）来间接实现。

内部实践：风险分级 + 强制卡点，与商业产品完全不同

Anthropic 自家仓库的规则是：「只要 bug 审查或安全审查还有任何发现未关闭，PR 就不能合并。」这两个世界之间的差距，在官方自己的文字里就摆着。

支撑这套内部流程的，是一个风险分级分类器。它读取每个变更并判定风险档位：低风险（文档、文案、内部功能、flag 后的增量变更）在自动化审查与安全检查通过后可零人工批准合并；中风险（普通产品变更、缓存、自动更新器、系统提示词）需要一位人工批准；高风险代码需要两位。

团队博客还列出几条即使你不买产品也值得抄走的规则：「变更本身决定档位，而不是作者」「谁发起的变更谁负责」「一次批准只覆盖一个具体 commit」「某些路径必须有人参与，包括 owners 标记为敏感的路径和任何 CI 工作流文件」。

更值得关注的是团队对自身局限的坦白：他们「还没有在各项指标变化时收紧审批的熔断机制」，而工程师们希望在更多代码走向零人工合并之前把这些机制建起来。

owners 标记（OWNERS 文件） 是大型代码仓库中常见的权限约定，源自 Google 的内部实践，后被 Kubernetes 等开源项目广泛采用。仓库中特定目录或文件可以附带 OWNERS 文件，列出对该路径有评审权或批准权的个人或团队。当变更触及这些路径时，必须获得对应 owners 的批准才能合并。Anthropic 内部规则中「owners 标记为敏感的路径必须有人参与」即属此类机制。它的作用是把「谁有资格批准」从全局角色细化到路径级别，避免不熟悉该模块的人随意放行高风险变更。

关于效果数据，需要谨慎看待

团队博客给出的数字颇有说服力：Claude 编写了 Claude Code 自身约 90% 的代码；从 6 月到 9 月，Claude Code 代码库的已合并 PR 数量翻了一倍多，而需要回滚的比例下降了超过 40%。目标是让「Claude Code 仓库中的大多数 PR 最多只需一个人参与就能合并，且回滚或事故不增加」。

但这些数字有两个需要注意的地方：它们是 Anthropic 关于自家仓库的自报数据，没有给出基数；而且据 The Next Web 报道，Anthropic 对该产品性能的主张并未经过独立测试。对考虑落地的团队来说，这属于值得参考但不宜直接外推的证据。

如何让自己的仓库也强制卡点

产品默认不阻断合并，文档提供了两条路径把它变成硬性门禁。

方案一：要求所有对话已解决。 GitHub 分支保护规则可以要求 PR 上的所有评论在合并前被解决。由于发现以对内联线程形式发布，未关闭的线程会挡住合并。注意两点：回复本身不能关闭发现，需要推送修复让下一轮审查自行解决，或手动标记解决；此外这条规则覆盖所有线程，包括 nit 和人工评论，而且对 GitHub 无法作为内联评论接受的发现无效——这类发现只出现在 Files changed 标签页的注释和检查运行的详情表里。

方案二：只卡 Important 发现。 检查运行的详情文本末尾有一行机器可读的判定行，gh 可以解析。其中 normal 键统计 Important 发现的数量，包含此前审查中仍未关闭的。脚本会串起两次 gh api 调用，在存在未关闭 Important 发现时以非零退出码失败。

一个关键的实现细节：这个脚本必须作为合并前置步骤运行，此时 Claude Code Review 检查已经完成，而不是在 PR 打开或推送时触发。审查需要几分钟，过早触发的任务找不到已完成的运行，会让每个 PR 都失败。脚本还有意采用 fail-closed 策略——文档建议把缺失判定行「视为没有结论而不是零发现」，且「有些已完成的审查同样没有这一行」。因此偶尔干净的 PR 可能需要补一条 @claude review 评论才能通过门禁。作者也坦言，该脚本并未在真实的 Code Review 检查上实际跑过。

启用任何一种门禁之前，先保护默认分支。 REVIEW.md 可以降低严重级别，而方案二统计的正是严重级别，所以谁能编辑这个文件至关重要。Code Review 只从 PR 的 base 分支或默认分支读取 REVIEW.md，从不读取 PR 自身的变更，因此 PR 无法放宽自己的审查。降低级别、排除路径或限制 nit 数量的规则，只有在默认分支受保护时才会被根目录的 REVIEW.md 采纳。本地 /code-review 读取的是 CLAUDE.md，不是 REVIEW.md。

fail-closed 与 fail-open 是安全与可靠性设计中的一对原则。fail-closed 指当系统无法做出判断或发生异常时，默认采取拒绝/阻断的保守行为；fail-open 则默认放行。在本文的合并门禁脚本中，fail-closed 意味着如果解析不到判定行（可能因为审查尚未完成、运行被跳过或格式变化），脚本会视为「没有结论」并以非零退出码失败，从而挡住合并。这样做的好处是不会让未经审查的代码溜过去，代价是偶尔干净的 PR 也会被误挡，需要人工补触发审查。选择哪种策略取决于团队对漏放风险与摩擦成本的权衡。

成本结构：按 token 计费，默认配置容易放大开销

定价方面没有固定的单次审查价格。审查按 token 用量通过 usage credits 计费，与套餐包含的用量分开计算，费用计入组织账户。预览期间据 The Next Web 报道，每次审查成本在 15 到 25 美元之间。

需要警惕的是默认设置：新加入的仓库默认是「每次推送后」触发审查，成本会随推送次数倍增。文档建议先用少量仓库以「PR 创建后一次」或手动模式试运行，观察 Average cost 列，并设置月度支出上限。额度耗尽后审查会被跳过，PR 上会收到说明原因的评论。符合条件的 Enterprise 组织可在 2027 年 1 月 15 日前申请至少 1 万美元的 Code Review 额度，具体条款适用。

usage credits 是 Anthropic 对 API 及部分增值功能采用的按量计费单位，与订阅套餐自带的用量额度分开核算。Code Review 的每次审查都会消耗模型推理的输入与输出 token，因此费用随 diff 大小、审查深度（Quick/Standard/Deep）和触发频率变化，没有固定的单次价格。组织账户统一结算，管理员可以在控制台查看 Average cost 等指标并设置月度支出上限。额度耗尽后相关功能会被跳过而非报错，这要求团队提前规划预算，避免在关键合并窗口因额度不足而失去审查覆盖。

PR 之前的另一层：本地预检

Code Review 从 PR 存在开始工作，而 Anthropic 的第一层防线更早：Claude 在 PR 打开前就运行测试、构建和 linter，由一个子 agent 在全新上下文中审查 diff。团队博客提到，Claude Code 的创造者 Boris Cherny 估计这种验证能让最终结果提升两到三倍。

这部分正好是各类本地工具与 IDE 的用武之地。围绕 Claude Code 的开发者工具生态（如支持分支隔离、逐轮保存 agent 操作、在提交前带风险标记审查变更的 IDE）正是瞄准了这个「PR 之前」的空档。需要注意的是，这类工具不运行 Code Review，也不替代 CI，与 Anthropic 没有隶属关系。

零人工批准，你敢用吗

Anthropic 自家仓库已经允许 owners 决定哪些低风险变更（例如 flag 后的增量变更）可以仅凭自动化检查合并——而且是在工程师们希望的熔断机制尚未到位的情况下。

对使用该产品的团队来说，核心问题变成：你愿意让一个分类器为你的仓库决定风险档位吗？还是每个 PR 都仍然需要一个人？

从工程实践看，Anthropic 这个案例的真正价值不在于产品功能本身，而在于它展示了一条渐进路径：先用审查发现提升信息密度，再用仓库规则把它变成门禁，最后在数据充分后才考虑放开零人工合并。对大多数团队而言，在分支保护与 REVIEW.md 权限收紧之前，直接照搬「零人工」的做法风险过高——尤其是当自报数据和独立验证之间仍有距离的时候。

AI 审查器本质上是一个跑在生产环境里的 LLM 功能，Anthropic 也是按这个标准在运营它：过往事故会变成评估集每日回归，噪音水平用人对每条评论的实际处理行为来度量。如果你的团队准备把 AI 审查器放到 PR 上，这部分观测与评估工作，应该在账单到来之前就规划好。