Anthropic 把 Claude Code Review 从研究预览推进到正式可用，面向 Claude Team 和 Enterprise 组织开放。它不是另一个聊天窗口，而是一套围绕 GitHub Pull Request 运行的审查服务：多个 Agent 并行阅读变更及相关代码，验证候选问题，去重并按严重程度排序，最后把结果写回 PR 的行内评论、摘要和检查项。
对已经使用编码 Agent 的团队，这个更新的价值不在于“又多了一个会写代码的模型”，而在于把审查从人工排队环节变成可配置的自动流程。不过它仍然是辅助审查，不会批准或阻止 PR，也不能替代测试、人工判断和合并决策。
正式版带来了什么
从研究预览进入 Team 和 Enterprise
Code Review 现在面向 Claude Team 和 Enterprise 组织正式开放。管理员需要在 Claude Code 设置中启用服务，安装 Claude GitHub App，并选择要接入的仓库。配置完成后，新 PR 可以按仓库设置自动触发审查，开发者不需要为每个 PR 单独写配置。
可用范围有几个明确边界：代码仓库需要托管在 GitHub，包括符合条件的 GitHub Enterprise 环境；组织还需要满足 Anthropic 的计划和管理权限要求。官方文档同时列出若干暂不支持的组织配置，例如启用了 Zero Data Retention、HIPAA 配置或客户自管加密密钥的组织。不要把“Team 和 Enterprise 可用”理解成所有 Claude 账户或所有代码托管平台都能直接使用。
正式版的核心变化是更快的审查、更少的噪声，以及可按仓库选择的审查深度。
三档审查深度
管理员可以为组织设置默认等级，也可以为单个仓库设置不同等级：
- Quick：较轻量的检查，速度最快，成本最低，适合变更相对常规的仓库。
- Standard：深度、速度和成本之间的平衡，官方默认等级。
- Deep：最彻底的检查，耗时和成本也最高，适合关键服务或风险更高的变更。
这不是三个不同模型，而是审查过程的投入程度不同。官方文档明确说明，等级越高，审查越充分，但也会增加使用成本。团队可以让普通业务仓库使用 Quick，把支付、权限或基础设施仓库切到 Deep，而不是对所有 PR 采用同一套昂贵配置。
厂商披露：多数审查约快 3 倍
Anthropic 表示，正式版多数审查相比研究预览期约快 3 倍，耗时从约 20 分钟降到 6–10 分钟；同时希望找到更多真正会影响生产的问题，并用更简洁的描述说明问题、触发条件和修复方式。
这里的口径需要保留条件。6–10 分钟是厂商对大多数审查的描述，不是 SLA；实际时间会受 PR 规模、周边代码复杂度、审查等级和需要验证的候选问题数量影响。团队在上线前，仍应使用自己的典型 PR 做小范围试运行。
它如何检查一个 Pull Request
Code Review 的工作流可以拆成四步。
第一步是 Find。多个 Agent 并行阅读 diff 和相关上下文，重点寻找可能导致生产故障的问题，包括逻辑错误、安全漏洞和边界条件。默认关注正确性，不把格式偏好或缺少测试自动当成主要问题。
第二步是 Verify。系统会回到代码中验证候选发现，过滤误报。第三步是 Rank，把剩余发现去重并按严重程度排序。第四步是 Post，把结果发布到 PR：问题会以行内评论出现，同时提供审查摘要和一个名为 Claude Code Review 的 check run。
服务本身不会构建或运行你的代码，访问仓库时是只读的。它不会批准 PR，也不会阻止 PR 合并。更重要的是，官方文档明确提醒：没有发现问题，不等于代码没有漏洞或安全风险。团队仍需要保留 CI、测试、人工审查和发布前验证。
如何接入团队流程
管理员侧的接入路径比较清晰：
- 在 Claude 组织的 Claude Code 管理设置中打开 Code Review。
- 连接 GitHub，并安装 Claude GitHub App。
- 选择需要接入的组织或仓库。
- 为组织设置默认审查等级，必要时为重点仓库单独调整。
- 设置审查触发方式：创建 PR 后运行一次、每次 push 后运行，或只接受
@claude review手动触发。
仓库还可以通过根目录或子目录中的 REVIEW.md 调整审查规则，例如提高某类问题的关注度、排除生成文件、限制 nit 评论数量。项目已有的 CLAUDE.md 也会作为项目上下文被读取。需要注意的是，审查读取的是受保护基线分支上的规则，不应把只存在于 PR 自身变更中的规则当成可信配置。
对开发者来说，自动模式下，打开或更新符合条件的 PR 就可能触发审查；手动模式则可以在 PR 评论中请求一次审查。对于草稿 PR 和来自 fork 的 PR，自动审查有额外限制，团队应先按文档确认触发条件。
成本怎么计算
Code Review 没有固定的单次价格，而是通过 usage credits 按用量计费，费用记在组织，不记在发起 PR 的个人名下。单次成本取决于审查等级、变更规模、周边代码复杂度和需要验证的候选问题数量；总成本还取决于一个 PR 会触发多少次审查。
“每次 push 都审查”可能比“创建 PR 后只审查一次”产生更多费用。官方建议先选少量代表性仓库做试点，设置月度支出上限，再根据管理后台中的平均成本和实际 PR 数量估算全面推广的预算。组织还可以在使用设置中限制 Code Review 服务的月度支出，并在分析面板查看 PR 数量、成本、已解决反馈和仓库拆分数据。
适合谁，不适合什么
它最适合已经有 GitHub PR 流程、希望在人工审查前先筛出明显缺陷的 Team 和 Enterprise 团队。尤其是 Agent 生成代码比例上升后，审查吞吐量跟不上提交速度的团队，可以用 Quick 覆盖普通仓库，再把 Deep 留给高风险代码。
它不适合被当成“自动安全认证”或“无人值守合并器”。服务不运行构建和测试，可能漏掉问题；没有 finding 也不能证明安全。对于强监管、需要完整审计证据的系统，仍需把 Code Review 结果放进更完整的测试、安全扫描和人工审批链路中。
总结
Claude Code Review 的正式开放，补上了编码 Agent 工作流中的审查环节：它把多个 Agent 的并行检查、验证、去重和分级结果直接放回 GitHub PR，并通过 Quick、Standard、Deep 三档配置，让团队可以在质量、速度和成本之间做取舍。
真正值得评估的不是演示中能找到多少个 Bug，而是它在你的 PR 规模、代码库和触发频率下，能否减少人工审查前的噪声，同时保持可接受的误报率和预算。建议从少量仓库、Standard 或 Manual 模式开始，用真实 PR 记录耗时、有效发现和每月成本，再决定是否扩大范围。
HiFox
