Code Review：GitHub PR 自动化多 Agent 代码审查完整指南 #

Claude Code Review 是 Anthropic 托管的 GitHub PR 审查服务，由多个专业化 Agent 并行分析代码变更，在具体代码行发布内联注释。适用于 Team 和 Enterprise 订阅。支持 PR 创建、每次 push 或手动触发（@claude review）。通过仓库根目录的 REVIEW.md 自定义审查规则和严重程度。按 token 计费，每次审查平均 $15-25，独立于订阅用量额度。如需在自有 CI 运行则参见 GitHub Actions 文档。

Code Review 处于研究预览阶段，面向 Team 和 Enterprise 订阅。启用了 零数据保留 的组织不可用。

Code Review 分析 GitHub Pull Request 并在发现问题的代码行上发布内联注释。一组专业化 Agent 在整个代码库上下文中检查变更，寻找逻辑错误、安全漏洞、边界情况和潜在回归问题。发现按严重程度标注，不会自动批准或阻止 PR，不影响现有 review 流程。

你可以在仓库中添加 CLAUDE.md 或 REVIEW.md 文件来调整 Claude 标记的内容。

如需在自有 CI 基础设施运行，见 GitHub Actions 或 GitLab CI/CD。自托管 GitHub 实例见 GitHub Enterprise Server。

Code Review 工作原理 #

管理员启用 Code Review 后，根据仓库配置的触发行为，PR 开启时、每次 push 时或手动请求时触发审查。在任意模式下，评论 @claude review 会启动 PR 审查。

审查运行时，多个 Agent 在 Anthropic 基础设施上并行分析 diff 和周围代码。每个 Agent 负责一类问题，然后验证步骤检查候选发现是否与代码实际行为一致，以过滤误报。结果去重并按严重程度排序后，以内联注释形式发布在发现问题的具体代码行上，并在审查正文中附带摘要。如果未发现问题，Code Review 更新 GitHub check run 显示未检测到问题。Claude 也可能在 PR 上发布简短的确认评论。

审查规模随 PR 大小和复杂度扩展，平均完成时间 20 分钟。管理员可通过分析仪表板监控审查活动和费用。

严重程度标注 #

每个发现包含可折叠的扩展推理区，点开可以查看 Claude 标记该问题及验证的原因。

评分与回复发现 #

Claude 的每条审查评论都附带了 👍 和 👎 按钮，可在 GitHub 界面中一键评分。认为有用点 👍，错误或噪声点 👎。Anthropic 在 PR 合并后会收集反应计数并用于调优审查器。反应不会触发重新审查或改变 PR 内容。

回复内联注释不会让 Claude 回复或更新 PR。要处理发现，请修复代码并 push。如果 PR 订阅了 push 触发审查，下次运行会在问题修复后自动解决对应线程。如需在不 push 的情况下请求新审查，在 PR 正文区评论 @claude review once。

Check Run 输出 #

除内联审查注释外，每次审查会填充 Claude Code Review check run，显示在 CI 检查旁边。展开其 Details 链接可在同一位置查看按严重程度排序的所有发现摘要：

每个发现在 Files changed 标签页中也有注释，直接标注在相关 diff 行上。Important 发现用红色标记，Nits 用黄色警告，预先存在的 bug 用灰色提示。注释和严重程度表独立于内联审查注释写入 check run，因此即使 GitHub 拒绝了移动行的内联注释，它们仍然可用。

check run 结论始终为中性，因此不会通过分支保护规则阻止合并。如果希望根据 Code Review 发现来门控合并，可以在自有 CI 中从 check run 输出读取严重程度分布。Details 文本的最后一行是可机器可读的注释，你的工作流可以用 gh 和 jq 解析：

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

返回每种严重程度的计数的 JSON 对象，例如 {"normal": 2, "nit": 1, "pre_existing": 0}。normal 键代表 Important 发现的数量；非零值表示 Claude 找到了至少一个合并前应修复的 bug。

Code Review 检查的内容 #

默认情况下，Code Review 关注正确性问题：会破坏生产的 bug，不是格式偏好或缺少测试覆盖。可以通过在仓库中添加指导文件来扩展检查范围。

怎么设置 Code Review #

管理员一次性为组织启用 Code Review，并选择要包含哪些仓库。

1. 前往 claude.ai/admin-settings/claude-code 找到 Code Review 区域。需要拥有 Claude 组织的管理员权限和 GitHub 组织安装 GitHub App 的权限。

2. 点击 Setup，开始 GitHub App 安装流程。

3. 按照提示将 Claude GitHub App 安装到 GitHub 组织。App 请求以下仓库权限：

   • Contents：读写
   • Issues：读写
   • Pull requests：读写

   Code Review 使用内容的读取权限和 PR 的写入权限。更宽的权限集也支持日后启用的 GitHub Actions。

4. 选择要启用 Code Review 的仓库。如果找不到某个仓库，请确保安装期间已授予 Claude GitHub App 对该仓库的访问权限。可以稍后添加更多仓库。

5. 设置完成后，Code Review 区域会以表格形式显示仓库。对于每个仓库，使用 Review Behavior 下拉菜单选择审查时机：

   • Once after PR creation（PR 创建后一次）：PR 开启或标记为 Ready for review 时运行一次
   • After every push（每次 push 后）：每次 push 到 PR 分支都运行，捕获 PR 演进过程中的新问题，并在修复标记的问题时自动解决线程
   • Manual（手动）：仅当有人评论 @claude review 或 @claude review once 时启动审查；@claude review 还会订阅该 PR 后续 push 的审查

每次 push 都审查会运行最多审查，成本也最高。手动模式适用于高流量仓库，只对特定 PR 进行审查，或只在 PR 就绪后才开始审查。

仓库表格还根据近期活动显示每个仓库的平均单次审查成本。使用行操作菜单可以启用或禁用每个仓库的 Code Review，或完全移除仓库。

验证设置：开一个测试 PR。如果选择了自动触发方式，几分钟内会出现名为 Claude Code Review 的 check run。如果选择了手动方式，在 PR 上评论 @claude review 来启动首次审查。如果没有出现 check run，请确认仓库已列在管理员设置中，且 Claude GitHub App 有该仓库的访问权限。

手动触发审查 #

两个评论命令可按需启动审查，无论仓库配置的触发方式如何：

当你只想要当前 PR 状态的反馈，但不想每次 push 都产生费用时，使用 @claude review once。这适用于长期开发且频繁 push 的 PR，或只想获得一次额外审查而不改变 PR 审查行为的情况。

要使命令触发审查，必须满足：

• 将命令作为顶级的 PR 评论发布，不是 diff 行的内联注释
• 将命令放在评论开头，如果使用一次性形式，once 放在同一行
• 你对仓库拥有 owner、member 或 collaborator 权限
• PR 必须处于 open 状态

与自动触发不同，手动触发对草稿 PR 有效，因为显式请求表示你希望立即获得审查，无论草稿状态如何。

如果同个 PR 已有审查正在运行，请求会排队直到进行中的审查完成。可以通过 PR 上的 check run 监控进度。

自定义审查规则 #

Code Review 从仓库中读取两个文件来指导标记内容。它们对审查的影响力不同：

• CLAUDE.md：所有 Claude Code 任务共享的项目指令，不仅限于审查。Code Review 将其作为项目上下文读取，并将新引入的违规标记为 nit 级别。
• REVIEW.md：审查专用指令，直接注入审查流水线中的每个 Agent，作为最高优先级。用它来改变标记内容、严重程度和报告方式。

CLAUDE.md #

Code Review 读取仓库的 CLAUDE.md 文件，将新引入的违规标记为 nit 级别的发现。这是双向的：如果 PR 修改代码使某条 CLAUDE.md 规则过时，Claude 也会标记需要更新文档。

Claude 读取目录层级中每个级别的 CLAUDE.md 文件，因此子目录中的规则只适用于该路径下的文件。更多关于 CLAUDE.md 的用法，见指令与记忆文档。

对于不希望应用于一般 Claude Code 会话的审查专用指导，使用 REVIEW.md。

REVIEW.md #

REVIEW.md 是仓库根目录下的一个文件，用于覆盖 Code Review 在仓库上的行为。其内容作为最高优先级的指令块注入审查流水线每个 Agent 的系统提示中，优先于默认审查指导。

因为它是逐字粘贴的，REVIEW.md 是纯文本指令：@ 导入语法不会扩展，引用的文件不会被读入提示。请将你想要执行的规则直接放入该文件。

可以调整的内容 #

REVIEW.md 是自由格式的 Markdown，因此任何可以表示为审查指令的内容都在范围内。以下模式在实践中效果最好。

严重程度：为你的仓库重新定义 🔴 Important 的含义。默认校准针对生产代码；文档仓库、配置仓库或原型项目可能需要更窄的定义。明确指出哪些类别的发现是 Important，哪些最多是 Nit。你也可以反向升级，例如将任何 CLAUDE.md 违规视为 Important 而不是默认的 nit。

Nit 数量上限：限制单次审查中 🟡 Nit 注释的数量。散文和配置文件的优化永无止境。像“最多报告五条 nit，其余在摘要中统计数量”这样的上限可以保持审查可操作。

跳过规则：列出 Claude 不应发布发现的路径、分支模式和发现类别。常见候选有生成的代码、锁文件、供应商依赖和机器自动生成的分支，以及你的 CI 已经强制执行的任何内容（如 lint、拼写检查）。对于只需部分审查的路径，可以设置较高的门槛而不是完全跳过：“在 scripts/ 目录下，只在接近确定且严重时报告。”

仓库特定检查：添加在每个 PR 上都需标记的规则，例如“新建 API 路由必须有集成测试。”因为 REVIEW.md 作为最高优先级注入，这些规则比在冗长的 CLAUDE.md 中更可靠。

验证门槛：要求某类发现发布前必须提供证据。例如，“行为声明需要在源码中有 file:line 引用，不是从命名推断”，可以减少误报，否则作者需要来回沟通。

复审收敛：告诉 Claude 当 PR 已被审查过后的行为。例如，“首次审查后，抑制新的 nit，仅发布 Important 发现”，可以防止一行修复因风格问题进入第七轮。

摘要格式：要求审查正文以一行计数开头，如 2 factual, 4 style，并在没发现问题时以“无事实性问题”开头。作者在细节之前希望看到工作的大致情况。

示例 #

以下 REVIEW.md 为后端服务校准严重程度、限制 nit、跳过生成文件，并添加仓库特定检查。

# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review. If you found more, say "plus N
similar items" in the summary instead of posting them inline. If
everything you found is a Nit, lead the summary with "No blocking
issues."

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant

保持聚焦 #

长度有成本：冗长的 REVIEW.md 会稀释最重要的规则。只包含会改变审查行为的指令，将一般项目上下文留在 CLAUDE.md 中。

查看使用量 #

前往 claude.ai/analytics/code-review 查看组织的 Code Review 活动。仪表板显示以下内容：

管理员设置中的仓库表格也会显示每个仓库的平均单次审查成本。仪表板成本数据是用于监控活动的估算值；需要按发票准确的费用，请参考 Anthropic 账单。

定价 #

Code Review 按 token 用量计费。每次审查平均 $15-25，随 PR 大小、代码库复杂度和需要验证的问题数量而扩展。Code Review 用量通过 Extra Usage 单独计费，不占用套餐内的包含用量。

选择的触发方式会影响总成本：

• Once after PR creation（PR 创建后一次）：每个 PR 运行一次
• After every push（每次 push 后）：每次 push 都运行，成本按 push 次数倍增
• Manual（手动）：直到有人评论 @claude review 才产生审查

在任何模式下，评论 @claude review 会使 PR 加入 push 触发审查，因此该评论后的每次 push 都会产生额外费用。要运行单次审查而不订阅后续 push，请改为评论 @claude review once。

无论你的组织对其他 Claude Code 功能使用 Amazon Bedrock 还是 Google Vertex AI，费用都会出现在 Anthropic 账单上。要为 Code Review 设置月度消费上限，前往 claude.ai/admin-settings/usage 并配置 Claude Code Review 服务的限额。

通过分析仪表板中的每周费用图表或管理员设置中的每个仓库平均成本列来监控消费。

故障排查 #

审查是尽力而为的。失败的审查永远不会阻塞 PR，但也不会自动重试。本部分介绍如何恢复失败的审查，以及在 check run 报告你无法找到的问题时应该在哪里查看。

审查失败或超时怎么解决 #

当审查基础设施遇到内部错误或超过时间限制时，check run 会以标题 Code review encountered an error（Code review 遇到错误）或 Code review timed out（Code review 超时）完成。结论仍为中性，因此不会阻塞合并，但不会发布任何发现。

要重新运行审查，在 PR 上评论 @claude review once。这启动一次全新的审查，不订阅后续 push。如果 PR 已订阅 push 触发的审查，推送一个新的提交也会启动新的审查。

GitHub Checks 标签页中的 Re-run 按钮不会重新触发 Code Review。请改用评论命令或新推送。

审查未运行且 PR 显示消费上限消息 #

当组织达到月度消费上限时，Code Review 会在 PR 上发布一条评论，说明审查已跳过。审查会在下一个计费周期开始时自动恢复，或在管理员在 claude.ai/admin-settings/usage 提高上限后立即恢复。

找不到内联注释显示的发现问题 #

如果 check run 标题显示发现了问题，但你在 diff 上看不到内联审查注释，请查看以下其他也会显示发现的位置：

• Check run Details：点击 Checks 标签中 Claude Code Review 旁边的 Details 链接。严重程度表列出了每个发现的文件、行和摘要，无论内联注释是否被接受。
• Files changed 注释：打开 PR 的 Files changed 标签页。发现会作为直接附加到 diff 行的注释显示，独立于审查注释。
• 审查正文：如果你在审查运行时推送了 PR，有些发现可能引用了当前 diff 中已不存在的行。这些行的发现会显示在审查正文中的 Additional findings 标题下，而不是以内联注释形式出现。

常见问题 #

Claude Code Review 怎么配置触发方式？ #

管理员在 claude.ai/admin-settings/claude-code 为每个仓库选择触发方式：PR 创建后一次、每次 push 后、或手动。设置完成后，仓库表格的 Review Behavior 下拉菜单即可调整。评论 @claude review 可以在任意模式下手动触发审查。

为什么 Code Review 审查没有运行？ #

可能原因：组织达到月度消费上限（PR 上会显示说明消息）、仓库未在管理员设置中启用、或 Claude GitHub App 没有该仓库的访问权限。如果 check run 显示错误或超时，评论 @claude review once 重新触发。

怎么用 REVIEW.md 调整审查规则？ #

在仓库根目录创建 REVIEW.md 文件，写入审查指令即可。例如设置 Important 的准确定义、限制 nit 数量、指定需要强制检查的规则（如“新 API 路由必须有集成测试”）。该文件作为最高优先级注入每个 Agent，优先于默认审查指导。