Code Review 正式版上线：AI 评审从个人试用变成了组织级配置

2026 年 10 月 15 日，Anthropic 把 Claude Code 的 Code Review 从研究预览推向了正式版（GA），面向 Claude Team 与 Enterprise 组织开放。最容易被引用的数字是：大多数评审从预览期的约 20 分钟缩短到 6 至 10 分钟，管理员可以为每个仓库选择 Quick、Standard 或 Deep 三档评审深度。但数字是这次发布里最不值得细看的部分。真正变化的是 AI 代码评审在一个团队里的身份：它不再是某个开发者个人试用的预览功能，而变成了管理员统一开启、统一做预算、统一担责的组织级配置。

这个身份变化值得停下来想一想，因为它改变了评价这款工具的问题。在预览期，正确的问题是“它能不能找到真 bug”。到了正式版，正确的问题变成了另外一组：哪些仓库配哪一档深度、按你的 PR 数量一次评审要花多少钱、评审结论与团队意见不一致时听谁的、它执行的规则由谁来定。本文依据 Anthropic 10 月 15 日的官方公告与 Code Review 产品文档回答这些问题，并且会明确标注哪些数字是 Anthropic 自己的说法、尚未经过独立验证。

这项服务到底做什么

Code Review 是一项托管服务，不是装在编辑器里的插件。管理员在 Claude Code 设置里开启它，安装 Claude 的 GitHub App，再选择覆盖的仓库；此后评审会在新 PR 上自动运行，开发者个人不需要再做任何配置。一次评审分四个阶段走：多个 agent 并行检查改动与周边代码找问题；验证步骤把候选结论与代码逐一核对、过滤掉假阳性；剩下的结论去重后按严重程度排序；结果以行内评论的形式落到 PR 上，同时附上一份摘要和一个名为 Claude Code Review 的检查运行（check run）。

这个 check run 有两个性质，初看不起眼，实际很重要。第一，它永远不会以失败告终，评审也永远不会批准或阻止合并。合并决定完全留在团队手里。这是一个刻意的设计：这项服务定位为“第二位读者”，而不是一道门禁。第二，如果评审没有发现问题，它会明确说出来。一次干净的评审是一句可以读到的结论，而不是需要你去猜测的沉默。这两条保护的是同一件事：团队继续掌握合并的判断权，同时对每一次改动都获得一次系统性的复核。

它审什么，又刻意不审什么

默认情况下，Code Review 只关注正确性：那些会让生产出问题的 bug，而不是格式偏好或测试覆盖率缺失。这个默认值本身就是一个判断，理解它才能理解你的团队会觉得这款工具“好用”还是“吵闹”。一个每条 PR 都纠格式的评审员，会训练开发者直接忽略它；一个只在可能影响生产的问题上才开口的评审员，才挣得到被认真阅读的资格。团队可以用 REVIEW.md 与 CLAUDE.md 指导文件调整评审范围，但默认值已经体现了 Anthropic 的押注：自动化评审挣信任的地方，在于它开口的地方。

评审可以在 PR 打开时运行一次、每次推送后都运行、或者仅按需运行；拥有写权限的任何人都可以通过评论“@claude review”手动触发一次。草稿 PR 与 fork 仓库会被排除在自动评审之外。这两项排除是务实的，不是理念上的：草稿按定义就是未完成品，而给 fork 自动评审等于把一条免费的评审流水线交给外部贡献者的代码。如果你的工作流主要用草稿 PR 作为评审面，那就需要显式触发评审，而不是等它自动出现。

REVIEW.md 那条值得单独写一段的规则

Code Review 读取的 REVIEW.md 来自 PR 的目标分支（base branch）或仓库的默认分支，永远不会读取 PR 自身改动里的版本。这条规则是整个发布里后果最深远的设计，值得把道理说透：如果评审员读的是待审分支里的规则，那么任何一个 PR 都可以在提交代码的同时附上一份更宽松的 REVIEW.md，把用来衡量自己的标准先放宽。强制规则来自受保护的目标分支，就等于要求新规则必须先经过与代码一样的合并与评审流程才能生效。能被被检查对象自己改掉的规则只是建议；改不掉的规则才是政策。如果你从本文只带走一个行动，那就应该是这一条：写好你的 REVIEW.md，保护好它所在的分支，像审代码一样审对它的每一次修改。

档位、计费与赠金

管理员可以为每个仓库选择 Quick、Standard（默认）或 Deep。日常代码库走快速通道，最关键的代码库走深度评审；评审越深入，费用越高，因为评审按 token 用量计费，不包含在套餐价格里。预览期的公开资料与报道把单次评审的典型费用放在约 15 至 25 美元，随 PR 规模与复杂度浮动；请把这个数字理解为预览期的报道数字，而不是正式版的价格表，因为 Anthropic 并没有公布正式版的单次评审价格。你的团队唯一可靠的成本数字，是试点一周后自己的平均值。所以合理的上线方式是：先在几个有代表性的仓库开 Standard、设好支出上限，跑一周后再按仓库定档位。

符合条件的 Claude Enterprise 组织可以领取至少 1 万美元的 Code Review 赠金，领取窗口在 2027 年 1 月 15 日 23:59 UTC 关闭，赠金自领取起 30 天后过期。这里的细节很要紧：领取只能做一次、不能撤销也不能重复，而且 30 天是从领取那一刻开始算的，不管评审有没有跑起来。所以要先把 Code Review 在仓库上配置好再领取，否则一部分窗口会被配置工作白白耗掉。赠金不覆盖自托管 GitHub Action、GitHub Enterprise Server 上的 Code Review、以及 /code-review 这类命令；试用版、经销商账单组织、零数据保留组织等几类组织也被排除在外。领取之前先读赠金条款；一份在配置过程中过期的赠金，比没有赠金更糟。

谁用不了，以及它不做什么

这项服务要求 Team 或 Enterprise 套餐，仓库必须托管在 GitHub 上，包括 GitHub Enterprise Server 与支持数据驻留的 GitHub Enterprise Cloud。开启了零数据保留（Zero Data Retention）或 HIPAA 配置的组织无法使用，它也不在 Anthropic 的商业伙伴协议（BAA）覆盖范围内，尚未支持客户自管加密密钥的组织。即使开发者是通过 Amazon Bedrock、Google Cloud Agent Platform 或 Microsoft Foundry 使用 Claude Code，也仍然需要一个 Claude 组织。评审在托管环境里以只读权限运行：只读改动与周边代码，不构建、不运行代码，也不在自托管环境里运行。

产品文档里还有一句每个团队在开启前都应该内化的话：Code Review 用的是 AI，可能会漏掉 bug、安全漏洞或其他问题；一次没有发现问题的评审，不代表代码没有错误、不安全。这句话不是套话。一次针对鉴权或支付代码的干净 AI 评审，不应该改变人类阅读这段改动的仔细程度。这项服务是一位有预算的第二位读者，不是一份正确性证明；把干净评审当成安全证书的团队，迟早会在文档已经警告过的那类 bug 上吃亏。

与 Anthropic 自家工程长文的区别

本站读者可能还记得同一天 Anthropic Claude Code 团队发布的另一篇文章，讲他们自己怎么做代码评审：Claude 写了 Claude Code 约 90% 的代码，6 月到 9 月间合并的 PR 翻了一倍多，而回滚比例下降了 40% 以上。那是一篇内部工程故事：七层评审流程，服务于一个团队、一个产品、一种工作流，数字由建造它的人自己统计。这篇文章讲的是另一回事：对外提供的产品本身，它的可用范围、档位、计费与限制。内部数字很有意思，但它不是关于 Code Review 在你的仓库上会怎么表现的证据，而且目前也没有针对这些数字的外部审计。用你自己仓库上的试点结果来评判这款产品，而不是用另一个团队的内部指标。

所以实际建议可以收得很具体。如果你是 Team 或 Enterprise 套餐、代码在 GitHub 上，那就先在少数几个仓库以 Standard 试点，写一份说清团队真正关心什么的 REVIEW.md，设好支出上限，一周后看平均成本与假阳性率。如果结论安静、具体、可执行，再按仓库逐步扩大；如果结论很吵，先调 REVIEW.md 再调档位——大多数吵闹的评审员，吵闹的原因是标准从来没有被写下来，而不是模型错了。正式版本身并不会让 AI 评审自动变得可信；它让评审变得可配置、可计费、可追责，而正是这三点，让一个团队能够自己决定要不要信任它。

试点第一周：按天排，比一次全开更稳

如果你打算在团队里试点 Code Review，不要第一天就全量开启。更稳的节奏是按周排：第一天，在一个中等规模、改动频率正常的仓库开 Standard，触发方式设为“PR 打开时一次”，先看结论的质量而不是数量；第二到第三天，把触发方式扩展到每次推送，观察同一 PR 在多轮推送下的结论变化——好的评审应该在后续推送里减少重复结论，而不是每推一次就把同一批问题重新说一遍；第四天，读一周的平均成本与结论采纳率，决定哪些仓库值得开 Deep、哪些仓库保持 Quick 就够了；第五天，再把 REVIEW.md 的第一版写进目标分支，让下一周的评审有明确的标准可依。

试点期间要记录的数字只有三个：单次评审的平均耗时、单次评审的平均成本、结论被采纳或被明确驳回的比例。耗时决定开发者会不会等它，成本决定财务上能不能铺开，采纳率决定它是不是真的在帮忙。三个数字里采纳率最重要：如果结论大多被驳回，问题通常不在档位，而在 REVIEW.md 没有写清团队的标准；如果结论大多被采纳但成本过高，问题在档位与触发方式，先降档、再收触发频率，不要反过来。

REVIEW.md 写什么、不写什么

一份能用的 REVIEW.md 不是越长越好。应该写进去的是三类内容：第一，项目里反复出问题的模式，比如“涉及金额计算的改动必须附带边界值测试”“所有对外接口改动必须同步更新文档”；第二，明确不评审的东西，比如“不要纠格式，格式由 lint 负责”“不要因为缺少测试覆盖率就单独提结论”；第三，严重程度的标尺，比如“数据丢失、资金错误、鉴权绕过属于必须修，性能小幅回退属于建议修”。不应该写进去的，是会频繁变化的细节与个人偏好：具体函数的命名风格、某次评审里提过的个别问题、还没有达成共识的争议点。规则写得越像个人偏好，被驳回的概率就越高。

还有一条容易被忽略的纪律：REVIEW.md 的修改本身要走评审流程。因为 REVIEW.md 读的是目标分支版本，对它的修改必须先合并才能生效，这既是保护机制，也意味着一次仓促的规则修改会在下一个合并周期才生效。改规则之前，先在团队里达成共识，再提交修改；不要在某个 PR 评审不顺利的当天，临时加一条针对那个 PR 的规则——那条规则会在之后所有的 PR 上生效，而它的代价要由整个团队承担。

评审结论的分流：立即修、排期修、驳回

评审结论落到 PR 上之后，团队需要一套默认的分流规则，否则每条结论都会变成一次讨论。实用的分流是三档：第一档是“合并前必须修”，包括数据正确性、鉴权、资金、数据丢失类问题，这类结论由作者在合并前处理；第二档是“可以排期修”，包括可读性、边界情况、非关键路径的性能问题，这类结论转成后续任务，不阻塞当前合并，但要有明确的负责人与期限；第三档是“驳回并说明理由”，包括误报、与项目约定冲突、以及评审员不了解业务上下文导致的错误结论，驳回时要写一句理由——这句理由既是给评审员的反馈，也是给未来 REVIEW.md 修订的素材。

分流规则本身也应该写进 REVIEW.md 或者团队的评审手册里，而不是靠每次口头商量。口头商量的问题是：同一个人、同一种结论，在不同 PR 里会得到不同的处理，而这种不一致会让开发者逐渐不信任评审结论。规则写下来之后，评审结论的处理就变成执行问题，而不是讨论问题，团队的评审时间才能真正省下来。

与人工评审的分工：机器看广度，人看判断

最后要划清一条分工线：机器评审擅长的是广度——每一行都看、每一次都不漏、每一种常见模式都记得；人类评审擅长的是判断——这个改动符不符合业务意图、这个取舍在当前阶段合不合理、这段代码的长期维护成本值不值得。把判断类的工作推给机器，或者把广度类的工作全留给人，都是分工错误。合理的状态是：机器先把广度扫一遍，人类在机器结论的基础上做判断，并且只在机器结论涉及业务意图时才花时间争论。

这条分工线还有一个实际好处：它保护了人工评审的时间。很多团队的人工评审之所以流于形式，是因为评审者把时间花在了找格式问题、找拼写错误、找显而易见的空指针上——这些正是机器最擅长的事。把广度交给机器之后，人类评审者的时间才能集中到真正需要人的地方：这个功能该不该做、这个接口设计三年后会不会后悔、这个改动有没有考虑回滚。正式版的意义，最终就落在这里：它不是让机器代替人评审，而是让人有时间做只有人能做的评审。

给小团队的特别提醒：Team 套餐够不够

很多小团队看到“Team 与 Enterprise”会先问一句：我们这个规模，Team 套餐的 Code Review 够不够用？从官方公告给出的信息看，够不够用的判断标准不是团队人数，而是仓库数量与 PR 频率：Team 套餐同样享有 Quick、Standard、Deep 三档与自动评审，区别主要在赠金（赠金只面向符合条件的 Enterprise 组织）与某些合规配置上。如果你的团队规模小、PR 量不大，Team 套餐加 Standard 档、再加支出上限，就是一套完整的试点配置；不需要为了 Code Review 单独升级到 Enterprise，除非你已经有合规或采购上的其他理由。先按现有套餐试点，成本数字跑出来之后，再谈套餐问题。