Claude Code 平台集成

Claude Code 平台集成

代码审查

4 分钟阅读

Code Review

设置自动化的 PR 审查,利用多 agent 分析你的完整代码库,捕获逻辑错误、安全漏洞和回归问题

Code Review 处于研究预览阶段,适用于 Team 和 Enterprise 订阅。不适用于启用了 Zero Data Retention 的组织。

Code Review 分析你的 GitHub Pull Request,并在发现问题代码的行上以内联评论形式发布发现。一组专门的 agent 会在完整代码库的上下文中检查代码变更,寻找逻辑错误、安全漏洞、边界情况损坏和细微的回归问题。

发现按严重程度标记,不会批准或阻止你的 PR,因此现有审查工作流保持完整。你可以通过向仓库添加 CLAUDE.md 或 REVIEW.md 文件来调整 Claude 标记的内容。

要在自己的 CI 基础设施中运行 Claude,请参阅 GitHub Actions 或 GitLab CI/CD。对于自托管 GitHub 实例上的仓库,请参阅 GitHub Enterprise Server。

本页涵盖:

要在终端中本地审查 diff 而无需安装 GitHub App,请在任何 Claude Code 会话中运行 /code-review 命令。请参阅 本地审查 diff。

审查如何工作

一旦 Owner 启用 Code Review 后,审查会在 PR 打开时、每次推送时或手动请求时触发,具体取决于仓库配置的行为。在 PR 上评论 @claude review 可以在任何模式下 启动审查。

审查运行时,多个 agent 会在 Anthropic 基础设施上并行分析 diff 和周边代码。每个 agent 寻找不同类型的问题,然后验证步骤会根据实际代码行为检查候选问题以过滤误报。结果会去重、按严重程度排序,并以内联评论形式发布在发现问题的具体代码行上,审查正文中包含摘要。如果未发现问题,Code Review 会更新 GitHub check run 以显示未检测到问题。Claude 也可能在 PR 上发布一条简短的确认评论。

审查成本随 PR 大小和复杂度而扩展,平均在 20 分钟内完成。Owner 可以通过 分析仪表板 监控审查活动和支出。

严重程度级别

每个发现都标有严重程度级别:

标记严重程度含义
🔴Important合并前应修复的 bug
🟡Nit小问题,值得修复但不会阻塞
🟣Pre-existing代码库中已存在但非此 PR 引入的 bug

发现包含可展开的扩展推理部分,你可以展开以了解 Claude 为何标记该问题以及它如何验证问题。

评价和回复发现

来自 Claude 的每条审查评论都附带 👍 和 👎,因此两个按钮都会出现在 GitHub UI 中供一键评价。如果发现有帮助,请点击 👍;如果错误或嘈杂,请点击 👎。Anthropic 在 PR 合并后收集反应计数,并用它们来调整审查员。反应不会触发重新审查或更改 PR 上的任何内容。

回复内联评论不会提示 Claude 响应或更新 PR。要根据发现采取行动,请修复代码并推送。如果 PR 订阅了推送触发审查,下次运行会在问题修复时解决该线程。要在不推送的情况下请求新的审查,请评论 @claude review once 作为 顶级 PR 评论。

Check run 输出

除了内联审查评论外,每次审查还会填充 Claude Code Review check run,它出现在你的 CI 检查旁边。展开其 Details 链接可在一个地方查看所有发现的摘要,按严重程度排序:

严重程度文件:行问题
🔴 Importantsrc/auth/session.ts:142令牌刷新与注销竞争,导致过时会话保持活动
🟡 Nitsrc/auth/session.ts:88parseExpiry 在输入格式错误时静默返回 0

每个发现也会以注释形式出现在 Files changed 标签页中,直接标记在相关的 diff 行上。Important 发现以红色标记渲染,Nit 以黄色警告渲染,已有 bug 以灰色通知渲染。注释和严重程度表独立于内联审查评论写入 check run,因此即使 GitHub 拒绝在已移动的行上添加内联评论,它们仍然可用。

Check run 始终以 neutral 结论完成,因此它永远不会通过分支保护规则阻塞合并。如果你想根据 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

Owner 为组织一次性启用 Code Review,并选择要包含的仓库。

1

打开 Claude Code 管理设置

前往 claude.ai/admin-settings/claude-code 并找到 Code Review 部分。你需要在 Claude 组织中拥有 Owner 或 Primary Owner 角色,并在 GitHub 组织中拥有安装 GitHub Apps 的权限。

2

开始设置

点击 Setup。这会启动 GitHub App 安装流程。

3

安装 Claude GitHub App

按照提示将 Claude GitHub App 安装到你的 GitHub 组织。该应用请求以下仓库权限:

  • Contents:读写
  • Issues:读写
  • Pull requests:读写

Code Review 使用内容的读取权限和 Pull requests 的写入权限。更广泛的权限集也支持以后启用 GitHub Actions。

4

选择仓库

选择要为 Code Review 启用的仓库。如果你看不到某个仓库,请确保在安装过程中授予了 Claude GitHub App 访问它的权限。你可以稍后添加更多仓库。

5

设置每个仓库的审查触发器

设置完成后,Code Review 部分会以表格形式显示你的仓库。对于每个仓库,使用 Review Behavior 下拉菜单选择审查何时运行:

  • Once after PR creation:PR 打开或标记为 ready for review 时运行一次审查
  • After every push:每次推送到 PR 分支时运行审查,在 PR 演进过程中捕获新问题,并在修复标记问题时自动解决线程
  • Manual:仅当有人在 PR 上 评论 @claude review 或 @claude review once 时启动审查;@claude review 还会订阅该 PR 在后续推送时进行审查

每次推送时审查运行最多的审查,成本最高。手动模式适用于高流量仓库,你希望选择特定 PR 进行审查,或仅当你的 PR 准备好后才开始审查。

仓库表格还显示基于近期活动的每个仓库的平均审查成本。使用行操作菜单可以按仓库开启或关闭 Code Review,或完全移除仓库。

要验证设置,请打开一个测试 PR。如果你选择了自动触发器,名为 Claude Code Review 的 check run 会在几分钟内出现。如果你选择了 Manual,请在 PR 上评论 @claude review 以启动第一次审查。如果没有出现 check run,请确认仓库已列在你的管理设置中,且 Claude GitHub App 有权访问它。

手动触发审查

两条评论命令可以按需启动审查。无论仓库配置的触发器如何,两者都有效,因此你可以在 Manual 模式下选择特定 PR 进行审查,或在其他模式下立即获得重新审查。

命令功能
@claude review启动审查并订阅该 PR 在后续推送时触发审查
@claude review once启动单次审查,不订阅该 PR 在未来推送时审查

当你想要对 PR 当前状态获得反馈,但不想让每次后续推送都产生审查时,请使用 @claude review once。这对于频繁推送的长期运行 PR 很有用,或者当你想要一次性第二意见而不更改 PR 的审查行为时。

对于任一命令触发审查:

  • 将其作为顶级 PR 评论发布,而非 diff 行上的内联评论
  • 将命令放在评论开头,如果使用单次形式,once 需在同一行
  • 你必须拥有仓库的 owner、member 或 collaborator 访问权限
  • PR 必须处于 open 状态

与自动触发器不同,手动触发器在 draft PR 上运行,因为显式请求表明你无论 draft 状态如何都希望立即审查。

如果该 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.md 工作原理的更多信息,请参阅 memory 文档。

对于你不希望应用于一般 Claude Code 会话的审查特定指导,请改用 REVIEW.md。

REVIEW.md

REVIEW.md 是位于仓库根目录的文件,用于覆盖 Code Review 在你仓库上的行为。其内容作为最高优先级指令块注入审查管道中每个 agent 的系统提示中,优先于默认审查指导。

因为它是原样粘贴的,REVIEW.md 是 plain instructions:@ import 语法 不会展开,引用的文件不会读入提示。将你希望强制执行的规则直接放在文件中。

你可以调整的内容

REVIEW.md 是 freeform markdown,因此你可以表达为审查指令的任何内容都在范围内。以下模式在实践中影响最大。

Severity:为你的仓库重新定义 🔴 Important 的含义。默认校准针对生产代码;文档仓库、配置仓库或原型可能希望更窄的定义。明确说明哪些发现类别是 Important,哪些最多是 Nit。你也可以向另一个方向升级,例如将任何 CLAUDE.md 违规视为 Important 而非默认的 nit。

Nit 数量:限制单次审查发布的 🟡 Nit 评论数量。散文和配置文件可以永远打磨。一个上限如 "最多报告五个 nit,在摘要中提及其余的数量" 可使审查保持可操作性。

跳过规则:列出 Claude 不应发布发现的路径、分支模式和发现类别。常见候选包括生成代码、lockfiles、vendored 依赖项和机器编写分支,以及 CI 已强制执行的任何内容如 linting 或拼写检查。对于值得审查但不需要全面审查的路径,设置更高的门槛而非完全跳过:在 scripts/ 中,仅当几乎确定且严重时报告。

仓库特定检查:添加你希望在每个 PR 上标记的规则,如 "新 API 路由必须有集成测试"。因为 REVIEW.md 作为最高优先级注入,这些比长 CLAUDE.md 中的相同规则更可靠。

验证门槛:要求在发布某类发现之前提供证据。例如,"行为声明需要源中的 file:line 引用,而非从命名推断" 可以减少误报,否则误报会花费作者一轮往返。

重新审查收敛:告诉 Claude 当 PR 已被审查时如何表现。一条如 "第一次审查后,抑制新的 nit 并仅发布 Important 发现" 的规则可以防止单行修复在风格上达到第七轮。

摘要形状:要求审查正文以单行统计开头,如 2 factual, 4 style,并在没有事实问题时以 "no factual issues" 开头。作者希望在细节之前了解工作的整体形状。

示例

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

# 审查指令

## 此处 Important 的含义

仅为会破坏行为、泄漏数据或阻止回滚的发现保留 Important:
不正确的逻辑、未限定范围的数据库查询、日志或错误消息中的 PII,
以及不向后兼容的迁移。风格、命名和重构建议最多是 Nit。

## 限制 nit 数量

每次审查最多报告五个 Nit。如果你发现更多,在摘要中说 "plus N
similar items" 而非以内联形式发布。如果你发现的所有内容都是 Nit,
以 "No blocking issues." 开头摘要。

## 不报告的内容

- CI 已强制执行的任何内容:lint、格式化、类型错误
- `src/gen/` 下的生成文件和任何 `*.lock` 文件
- 故意违反生产规则的仅测试代码

## 始终检查

- 新 API 路由有集成测试
- 日志行不包含电子邮件地址、用户 ID 或请求体
- 数据库查询限定为调用者的租户

保持聚焦

长度有成本:长的 REVIEW.md 会稀释最重要的规则。将其保留为改变审查行为的指令,并将一般项目上下文留在 CLAUDE.md 中。

查看使用

前往 claude.ai/analytics/code-review 查看整个组织的 Code Review 活动。仪表板显示:

部分显示内容
PRs reviewed选定时间范围内每日审查的 Pull Request 数量
Cost weeklyCode Review 的每周支出
Feedback开发者修复问题后自动解决的审查评论数量
Repository breakdown每个仓库的审查 PR 数量和解决的评论数量

管理设置中的仓库表格还显示每个仓库的平均审查成本。仪表板成本数字是用于监控活动的估算;如需发票准确的支出,请参阅你的 Anthropic 账单。

定价

Code Review 基于 token 使用量计费。每次审查平均成本为 $15-25,随 PR 大小、代码库复杂度和需要验证的问题数量而扩展。Code Review 使用通过 使用积分 单独计费,不计入你套餐的包含使用量。

你选择的审查触发器会影响总成本:

  • Once after PR creation:每个 PR 运行一次
  • After every push:每次推送运行,成本乘以推送次数
  • Manual:直到有人在 PR 上评论 @claude review 才运行审查

在任何模式下,评论 @claude review 都会 让 PR 订阅推送触发审查,因此该评论后每次推送都会产生额外成本。要运行单次审查而不订阅未来推送,请改用 @claude review once。

成本会出现在你的 Anthropic 账单上,无论你的组织是否使用 Amazon Bedrock 或 Google Cloud 的 Agent Platform 进行其他 Claude Code 功能。要为 Code Review 设置月度支出上限,请前往 claude.ai/admin-settings/usage 并为 Claude Code Review 服务配置限制。

通过 分析 中的每周成本图表或管理设置中的每个仓库平均成本列来监控支出。

故障排查

审查运行是尽力而为的。失败的运行永远不会阻塞你的 PR,但也不会自动重试。本节介绍如何从失败的运行中恢复,以及当 check run 报告你找不到的问题时该查看哪里。

重新触发失败或超时的审查

当审查基础设施遇到内部错误或超过时间限制时,check run 会以 Code review encountered an error 或 Code review timed out 的标题完成。结论仍然是 neutral,因此不会阻塞你的合并,但不会发布发现。

要再次运行审查,请在 PR 上评论 @claude review once。这会启动新的审查,而不订阅该 PR 在未来推送时审查。如果 PR 已订阅推送触发审查,推送新提交也会启动新审查。

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 check 旁边的 Details。严重程度表列出每个发现及其文件、行和摘要,无论内联评论是否被接受。
  • Files changed 注释:打开 PR 的 Files changed 标签页。发现以直接附加到 diff 行的注释形式渲染,与审查评论分开。
  • Review body:如果你在审查运行时推送到 PR,某些发现可能引用当前 diff 中不再存在的行。这些出现在审查正文文本的 Additional findings 标题下,而非内联评论。

本地审查 diff

/code-review 命令 可在不安装 GitHub App 的情况下在终端中审查 diff。在任何 Claude Code 会话中运行它:它报告正确性 bug 和 复用、简化和效率清理。默认情况下,本地审查覆盖你的分支领先上游的提交加上工作树中任何未提交的更改。传递 --comment 以将发现发布为内联 PR 评论,或传递 --fix 以在审查后将发现应用到你的工作树。

较低的 effort 级别 返回更少、置信度更高的发现,而 high 到 max 提供更广泛的覆盖,可能包含不确定的发现。没有 effort 参数时,审查使用会话当前的 effort。要审查默认 diff 以外的内容,请传递目标:文件路径、PR 编号、分支名称或 ref 范围如 main...my-feature。ref 范围形式审查从 my-feature 合并到 main 的 Pull Request 会包含的已提交 diff,无论分支的上游如何配置。

/code-review ultra --fix 在云端运行更深入的 ultrareview,然后在发现返回到你的会话时将其应用到你的工作树。Ultrareview 使用自己的范围:你的当前分支与仓库默认分支对比,加上工作树中任何未提交和已暂存的更改。

该命令在 v2.1.147 之前名为 /simplify,当时它默认应用修复。从 v2.1.154 开始,/simplify 运行单独的仅清理审查,应用修复而不寻找 bug。如果你为查找 bug 而脚本化了 /simplify,请切换到 /code-review --fix,后者保持不变。

Code Review 旨在与 Claude Code 的其他部分协同工作。如果你想在打开 PR 之前本地运行审查,需要自托管设置,或想深入了解 CLAUDE.md 如何塑造 Claude 在工具中的行为,这些页面是不错的下一步:

  • Commands:在本地 Claude Code 会话中运行 /code-review 以在推送前检查 diff
  • GitHub Actions:在你自己的 GitHub Actions 工作流中运行 Claude,实现代码审查之外的自定义自动化
  • GitLab CI/CD:用于 GitLab 流水线的自托管 Claude 集成
  • Memory:CLAUDE.md 文件在 Claude Code 中的工作原理
  • Analytics:追踪 Claude Code 除代码审查外的使用