正文
AI 写代码更快以后，团队收到的 PR 也可能更多。Claude Code Review 可以在 GitHub PR 上提出审查意见，但管理员仍要决定让它读取哪些仓库、审查哪些变化，以及人工负责人如何处理结果。
Anthropic 在 2026 年 10 月 15 日宣布，Code Review 退出研究预览，向 Claude Team 和 Enterprise 组织开放。管理员需要启用功能、安装 GitHub App 并选择仓库；官方提供 Quick、Standard 和 Deep 审查深度，Standard 是默认项。官方发布说明
从哪些仓库和 PR 开始
优先选维护者熟悉、测试稳定且能代表日常工作量的仓库。试点既要包含小型修复，也要包含边界条件较多的功能变更；仅用文档修改衡量效果，无法说明它能否发现逻辑问题。
| PR 类型 | 试点重点 |
|---|---|
| 小修复和常规功能 | 意见是否指出实际问题，是否能在审查期限内返回。 |
| 多文件重构 | 是否识别跨文件行为变化和遗漏的调用方。 |
| 数据、鉴权和部署变更 | 人工负责人继续逐项审查；特别检查迁移、回滚和权限。 |
这是试点评估建议，不意味着任何档位可覆盖所有风险。先核对仓库代码能否发送给服务、GitHub App 的权限、组织策略和合同，再启用真实仓库。
审查深度、价格和数据边界要分开确认
官方在发布时称多数审查比预览期更快，并提供三档深度；实际耗时会随 PR 和服务条件变化。上线前应在当前管理界面和设置文档核实适用套餐、计费、预算、代码访问范围和数据保留条件。不要把旧预览期的平均费用写成现行固定价格。
AI 审查意见也不能自动等同于合并许可。检查现有 branch protection、必需状态检查和 CODEOWNERS；确认新提交后哪些检查或人工批准需要重新执行。站内关于 Copilot 自动批准的规则针对 Copilot，不能未经验证地套用到 Claude。
用一批真实 PR 衡量是否值得开启
让人工审查者按原流程独立审查一批 PR，同时记录 Claude 的结果；对重要改动准备已知缺陷或历史回归用例。逐项统计：
- 有效发现：能重现、与本次改动有关并值得修复的意见。
- 误报和噪声：无法复现、与上下文不符或重复已有检查的意见。
- 漏报：人工或测试确认的问题中，自动审查没有指出的部分。
- 等待和成本：从提交到意见返回的时间、每次审查用量，以及人工核实时间。
公开代码审查研究展示了如何用带已知缺陷的任务衡量 Agent，但它不能证明 Claude Code Review 在你的仓库中的表现。试点结果应保留任务类型、样本数量和未覆盖风险，而不是只统计评论条数。
当团队能说清“哪些仓库启用、发现由谁处理、合并门槛是什么、预算如何控制”，并且试点显示有效问题多于核实噪声，才有依据扩大使用范围。