Skip to content
FunCoding

Search

Search docs, agents, posts, Skills and MCP servers

Code Review 与 ultrareview

对 GitHub PR 自动评审的托管服务(Code Review)、在本地评审 diff 的 /code-review,以及在云端做深度多智能体评审的 ultrareview:设置、触发、定制(CLAUDE.md/REVIEW.md)、定价、排障与非交互用法。

Code Review(托管的 PR 评审)

Code Review 处于研究预览阶段,面向 Team 和 Enterprise 订阅;启用了零数据保留的组织不可用。在其他套餐上,你仍然可以用 /code-review 命令在本地评审 diff。下文的价格、触发行为等以官方为准。

Code Review 分析你的 GitHub 拉取请求,并把发现作为行内评论发在有问题的代码行上。一组专门的智能体在你完整代码库的上下文里检查代码改动,寻找逻辑错误、安全漏洞、被破坏的边界情况和细微的回归。发现按严重程度打标签,不会批准或阻止你的 PR,所以现有的评审流程保持不变。你可以在仓库里加 CLAUDE.md 或 REVIEW.md 文件来调整 Claude 标记什么。

想在自己的 CI 基础设施里运行 Claude 而不是用这个托管服务,用 GitHub Actions 或 GitLab CI/CD;自托管 GitHub 实例上的仓库见 GitHub Enterprise Server 页。

评审如何工作

当 Owner 为你的组织启用 Code Review 后,评审会根据仓库配置的行为,在 PR 打开时、每次推送时或被手动请求时触发。在任何模式下,评论 @claude review 都会在某个 PR 上启动评审。

评审运行时,多个智能体在 Anthropic 基础设施上并行分析 diff 及周围的代码。每个智能体寻找不同类别的问题,然后一个验证步骤对照实际代码行为检查候选项,过滤掉误报。结果被去重、按严重程度排序,作为行内评论发布在发现问题的具体行上,并在评审正文里给出摘要。没有发现问题时,Code Review 会更新 GitHub 检查运行,显示没有检测到问题;Claude 也可能在 PR 上发一条简短的确认评论。评审的成本随 PR 的大小和复杂度而变,平均 20 分钟完成。Owner 可以通过分析仪表板监控评审活动和花费。

严重程度

每个发现都被标上严重程度:

标记严重程度含义
🔴Important合并前应该修复的缺陷
🟡Nit小问题,值得修但不阻塞
🟣Pre-existing代码库里已存在、但不是这个 PR 引入的缺陷

发现里包含一个折叠的 Why this was flagged 部分,展开可以读到 Claude 为什么标记这个问题以及它如何验证问题。

对发现评分和回复

Claude 的每条评审评论到达时都已附带 👍 和 👎,所以两个按钮都出现在 GitHub 界面里,方便一键评分。发现有用就点 👍,错误或嘈杂就点 👎。Anthropic 在 PR 合并后收集反应数,用它们来调整评审器;反应不会触发重新评审,也不会改变 PR 上的任何东西。

回复行内评论不会促使 Claude 响应或更新 PR。要对某个发现采取行动,修复代码并推送;如果 PR 订阅了推送触发的评审,下一次运行会在问题修复后解决该线程。要在不推送的情况下请求新的评审,把 @claude review 作为 PR 的顶层评论发出。要在不改代码的情况下驳回某个发现,解决(resolve)它的线程;回复不会驳回它。

检查运行的输出

除了行内评审评论,每次评审还会填充与你的 CI 检查并列出现的 Claude Code Review 检查运行。展开它的 Details 链接,可以在一处看到每个发现的摘要,按严重程度排序:

严重程度文件:行问题
🔴 Importantsrc/auth/session.ts:142Token refresh races with logout, leaving stale sessions active
🟡 Nitsrc/auth/session.ts:88parseExpiry silently returns 0 on malformed input

每个发现也作为注解出现在 Files changed 标签页里,直接标在相关的 diff 行上:Important 发现用红色标记渲染,nit 用黄色警告,pre-existing 缺陷用灰色通知。注解和严重程度表独立于行内评审评论写入检查运行,所以即使 GitHub 拒绝了某行已移动的行内评论,它们仍然可用。

检查运行总是以 neutral 结论完成,所以它永远不会通过分支保护规则阻止合并。如果你想以 Code Review 的发现来把关合并,在自己的 CI 里读取检查运行输出里的严重程度明细:Details 文本的最后一行是机器可读的注释,你的工作流可以用 gh 和 jq 解析它。要找到检查运行 ID,用 gh api repos/OWNER/REPO/commits/<commit-sha>/check-runs --jq '.check_runs[] | {id, name}' 列出该提交的检查运行,取名为 Claude Code Review 那条的 id;把 OWNER、REPO 和 CHECK_RUN_ID 换成你的仓库所有者、仓库名和该 ID:

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 找到了至少一个合并前值得修复的缺陷。

Code Review 检查什么

默认情况下,Code Review 聚焦正确性:会破坏生产环境的缺陷,而不是格式偏好或缺失的测试覆盖。你可以通过给仓库添加指导文件来扩展它检查的内容。

设置 Code Review

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

  1. 打开 Claude Code 管理设置:进入 claude.ai/admin-settings/claude-code,找到 Code Review 部分。你需要在 Claude 组织里是 Owner 或 Primary Owner,并且有在 GitHub 组织里安装 GitHub App 的权限。

  2. 开始设置:点击 Setup,这会开始 GitHub App 安装流程。

  3. 安装 Claude GitHub App:按提示安装 Claude GitHub App:选择拥有你想评审的仓库的 GitHub 组织,选择应用能访问哪些仓库,并批准请求的权限。评审拉取请求时,Claude 通过应用的读取权限读取你的仓库内容,并通过它对拉取请求和检查的写入权限发布评论和检查运行。安装期间你授予的是与其他 Claude 功能(如 GitHub Actions)共享的较广权限集合,完整列表见 GitHub Actions 页的 GitHub App 权限。

  4. 选择仓库:选择为哪些仓库启用 Code Review。如果你没看到某个仓库,确认你在安装期间给了 Claude GitHub App 对它的访问权;之后还可以添加更多仓库。

  5. 按仓库设置评审触发器:设置完成后,Code Review 部分以表格显示你的仓库。对每个仓库,用 Review Behavior 下拉框选择评审何时运行:

    • Once after PR creation:PR 打开或标记为可评审时运行一次评审。
    • After every push:每次推送到 PR 分支时都运行评审,随 PR 演进捕获新问题,并在你修复被标记的问题时自动解决线程。
    • Manual:打开 PR 或向 PR 推送不会启动评审;评论 @claude review 请求一次,或评论 @claude review always 同时让 PR 订阅之后推送的评审。

    不论你选哪个选项,Claude 只有在有人对来自 fork 的拉取请求评论 @claude review 时才会评审它。每次推送都评审运行的评审最多、成本最高;Manual 模式适用于流量高的仓库,你想让特定 PR 选择加入评审,或只在你自己的 PR 准备好后才开始评审。

仓库表还会根据近期活动显示每个仓库每次评审的平均成本;用行操作菜单可以按仓库开关 Code Review,或彻底移除某个仓库。要验证设置,打开一个测试 PR:如果你选了自动触发器,几分钟内会出现名为 Claude Code Review 的检查运行;如果你选了 Manual,在 PR 上评论 @claude review 启动第一次评审。如果没有出现检查运行,确认仓库列在你的管理设置里,并且 Claude GitHub App 有访问它的权限。

手动触发评审

评论命令按需启动评审。它们不论仓库配置的触发器是什么都有效,所以你可以在 Manual 模式下用它们让特定 PR 选择加入评审,或在其他模式下立即得到重新评审。

命令作用
@claude review启动一次评审,不让 PR 订阅未来的推送
@claude review always启动评审,并让 PR 订阅此后推送触发的评审
@claude review once与 @claude review 相同:启动一次评审,不订阅

当你希望之后每次推送到 PR 都启动新的评审时(例如设为 Manual 模式的仓库里的高优先级 PR),用 @claude review always。因为单独的命令不会让 PR 订阅,你可以请求一次性的第二意见,而不改变之后的推送是否触发评审。

注意:2026 年 7 月的更新之前,@claude review 会让 PR 订阅推送触发的评审。如果你依赖过那个行为,改为评论 @claude review always;@claude review once 仍然有效,行为与单独的命令相同。

这些命令要触发评审,需要:

  • 作为顶层 PR 评论发出,而不是 diff 行上的行内评论
  • 把命令放在评论开头,once 或 always 与命令的其余部分在同一行
  • 你必须对该仓库有写入、维护或管理员权限
  • PR 必须是打开状态

如果仓库属于某个组织,而你在该组织里的成员身份是私有的(这是 GitHub 的默认设置),GitHub 不会向 Claude 把你识别为成员。Claude 可能仍会用 👀 回应你的评论,但除非你被直接作为协作者添加到仓库,否则不会启动评审,即使某个团队或组织的基础权限给了你写入权限。要修复这一点,把你的组织成员身份设为公开,或请仓库管理员把你作为协作者添加到仓库。

与自动触发器不同,手动触发会在草稿 PR 上运行,因为明确的请求表明不论草稿状态如何你都想现在评审。如果该 PR 上已经有评审在运行,请求会排队,直到进行中的评审完成;你可以通过 PR 上的检查运行监控进度。

评审来自 fork 的拉取请求

不论仓库的 Review Behavior 设置如何,Claude 都不会自动评审来自 fork 的拉取请求。要启动一次,在该拉取请求上评论 @claude review;评论命令的要求仍然适用,你需要的写入权限是针对基础仓库而不是 fork。要对 fork 拉取请求再做一次评审,发一条新的 @claude review 评论;@claude review always 也行,但不会让该拉取请求订阅之后推送的评审。除评论命令之外,没有任何东西会在 fork 拉取请求上启动评审:点击检查运行上的 Re-run 不会启动评审,推送新提交也不会,即使仓库设为 After every push。

定制评审

Code Review 从你的仓库读取两个文件来引导它标记什么,二者对评审的影响力度不同:

  • CLAUDE.md:Claude Code 用于所有任务(不只是评审)的共享项目指令。Code Review 把它当作项目上下文读取,并把新引入的违规标记为 nit。
  • REVIEW.md:仅用于评审的指令,交给查找和验证发现的智能体,并由排序和报告发现的智能体参考。用它说明你的团队想让标记什么、以什么严重程度,以及发现如何报告。

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。评审流水线里查找和验证发现的智能体,会把它的内容与 Code Review 的默认评审指导一起,作为你仓库的评审指令收到;排序和报告发现的智能体在确定严重程度和撰写评审之前会参考它。把你想强制执行的规则直接写进 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,并在没有事实性问题时以「no factual issues」打头。作者想先知道工作的概貌,再看细节。

示例

这个 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 活动。仪表板显示:

部分显示什么
PRs reviewed所选时间范围内每天评审的拉取请求数
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:打开或推送时不评审,所以成本只来自有人请求的评审。

在 Once after PR creation 或 Manual 模式下,评论 @claude review always 会让 PR 选择加入推送触发的评审,所以在那条评论之后每次推送都会产生额外成本;在 After every push 模式下,推送本来就触发评审,所以订阅不改变每次推送的成本。评论 @claude review 运行一次评审而不订阅未来的推送。Claude 只有在有人评论 @claude review 时才评审 fork 拉取请求,所以 fork 拉取请求在任何模式下都不会产生每次推送的成本。

不论你的组织是否为其他 Claude Code 功能使用 Amazon Bedrock 或 Google Cloud 的 Agent Platform,这些成本都出现在你的 Anthropic 账单上。要为 Code Review 设置每月支出上限,进入 claude.ai/admin-settings/usage,为 Claude Code Review 服务配置限额。通过分析里的每周成本图表或管理设置里每个仓库的平均成本列来监控花费。

排障

评审运行是尽力而为的,失败的运行永远不会阻塞你的 PR。Code Review 会自行重试一些被中断的评审。本节讲如何自己再次运行评审,以及在检查运行报告了你找不到的问题时去哪里看。

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

评审失败或超出时间限制时,检查运行以 Code review failed 或 Code review timed out 这样的标题完成;结论仍是 neutral,所以没有东西阻塞你的合并。除非检查运行的摘要说该提交的新评审已被自动排队,否则自己再运行评审。要再次运行,在 PR 上评论 @claude review:这会启动新的评审而不让 PR 订阅未来的推送。如果 PR 不是来自 fork,你也可以在 GitHub 的 Checks 标签页里点击 Claude Code Review 检查上的 Re-run;重新运行同样启动新的评审而不订阅 PR。

评审没有运行,PR 显示支出上限消息

当你组织的每月支出上限达到时,Code Review 在 PR 上发一条评论,说明评审被跳过。评审在下一个计费周期开始时自动恢复,或在管理员于 claude.ai/admin-settings/usage 提高上限时立即恢复。

找到没有显示为行内评论的问题

如果检查运行标题说发现了问题,但你在 diff 上没看到行内评审评论,到发现被呈现的这些其他位置查看:

  • 检查运行 Details:在 Checks 标签页里点击 Claude Code Review 检查旁边的 Details。严重程度表列出每个发现的文件、行和摘要,不论行内评论是否被接受。
  • Files changed 注解:打开 PR 上的 Files changed 标签页。发现作为直接附在 diff 行上的注解渲染,与评审评论分开。
  • 评审正文:如果你在评审运行期间向 PR 推送了提交,一些发现可能引用当前 diff 里已不存在的行。它们出现在评审正文文字里的 Additional findings 标题下,而不是作为行内评论。

在本地评审 diff

/code-review 命令在你的终端里评审 diff,无需安装 GitHub App。它报告正确性缺陷,以及复用、简化和效率方面的清理。/review 是 /code-review 的别名(v2.1.223 之前,它是一个单独的命令,对 GitHub 拉取请求运行单遍的只读评审)。

1. 运行 /code-review。 在你工作的会话里运行命令:

/code-review

它评审你分支上领先于上游的提交以及任何未提交的改动,所以需要分支上或工作树里有工作,才有东西可报告。要评审别的东西,传一个目标:文件路径、PR 号、分支名,或 main...my-feature 这样的引用范围。你也可以加标志:

  • --fix:评审后把发现应用到你的工作树。
  • --comment:把发现作为行内评论发到 GitHub 拉取请求上,或作为单条备注发到 GitLab 合并请求上。
  • --post:对 github.com 拉取请求的 ultra 云端评审,在启动对话框里预选把完成的发现发布到 PR(需要 Claude Code v2.1.227 或更高)。

为 GitLab 合并请求传 --comment 时,Claude Code 通过 GitLab 的 glab CLI 发布发现(需要 v2.1.257 或更高);没有安装 glab 时,Claude 改为在终端里打印发现。合并请求以其 URL 或 !123 引用传入;只有当检出的 origin 在 gitlab.com 时,Claude Code 才把单独的数字或分支名当作合并请求,在自托管 GitLab 实例上,传 URL 或 !123 形式。

2. 继续工作。 评审作为后台子智能体运行,有自己的上下文窗口,所以不会填满你的对话。评审完成时,发现送达你的对话。

3. 对发现采取行动。 让 Claude 修复评审发现的问题;如果你传了 --fix 或 --comment,评审已经应用或发布了它的发现。

在这两种运行里,即使宿主应用请求发现列表,Claude 也以回复中的文本报告发现:在终端会话里(/code-review 以 forked 子智能体运行评审),以及在带文本或 JSON 输出的 -p 运行里。在请求发现列表的宿主应用(如桌面应用)里,Claude 改为通过 ReportFindings 工具报告评审的发现:Claude Code 把报告渲染为发现列表,每个条目显示文件位置、一句话摘要,以及发现带有的类别标签(如 correctness)。宿主请求在每个 effort 级别都适用,需要 Claude Code v2.1.218 或更高。Claude 稍后在会话里修复报告的发现时,会再次报告它们,Claude Code 在更新后的发现列表里把每个发现标记为已修复、已跳过或无需更改。

评审读取和编辑什么

评审像任何 Claude Code 会话一样遵循你的 CLAUDE.md,但它不读取 REVIEW.md。后台评审在你会话的检查点之外应用它的 --fix 编辑,所以 /rewind 无法撤销它们,用 git 来还原;当评审在前台运行时,它在你自己的轮次里编辑你的工作树,所以 /rewind 像往常一样恢复它的编辑。

调整 effort 和参数

传一个 effort 级别,用覆盖面换取置信度。在 low 和 medium,评审只报告它最有把握的发现,所以你看到更少的误报;high 到 max 扩大覆盖面,可能包含评审不那么确定的发现。当你不输入级别时,评审复用你上次输入的 low 到 max 之间的级别(即使在较早的会话里),Claude Code 显示 Reusing high effort, the level you typed last time 这样的通知;输入一个级别(如 /code-review high)来改变之后运行复用的内容,在非交互的 -p 运行里传的级别不更新它;ultra 既不更新也不使用记住的级别;如果你从未输入过级别,评审使用会话当前的 effort。(v2.1.223 之前,不带级别的 /code-review 总是使用会话当前的 effort。)

在 effort 级别和标志之后,Claude Code 以两种方式之一读取该行的其余部分:

  • 不带 ultra:剩下的一切都是评审目标,即使它以另一个命令名开头:/code-review /fix-issue 123 以 /fix-issue 123 作为目标文本进行评审,而不是把 /fix-issue 作为第二个叠加的 skill 加载(v2.1.218 之前,叠在 /code-review 之后的命令会作为自己的 skill 展开)。
  • 带 ultra:Claude Code 把单个词读作基础分支或 PR 号,并把没有指明分支或 PR 的更长文本变成附在评审上的备注:/code-review ultra check my auth changes 评审你当前的分支,Claude 把发现与你的备注关联起来。

在前台运行

评审默认在后台运行(v2.1.218 之前,它在你的对话内部运行)。在这些情况下它改为在前台运行:

  • 一个较早的评审仍在进行时你再次运行 /code-review。
  • 你在非交互模式下运行它,带 -p 标志或通过 Agent SDK:Claude Code 等待评审并把发现包含在响应里,ultra 除外,它启动云端评审而不等待。
  • 你把 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS 设为 1,这也会关闭所有其他后台任务功能。

让 Claude 启动评审

Claude 可以自己启动 /code-review:你用自然语言让它评审你的改动,它就可以运行该 skill 而无需你输入命令;以 /code-review 为提示的定时任务也会运行评审。定时任务从不启动云端评审,所以调度 /code-review 时不要带 ultra 参数。要阻止 Claude 和定时任务启动评审、同时保留 /code-review 供你输入,在 ~/.claude/settings.json 这样的设置文件里添加 skillOverrides 条目:

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

(v2.1.246 之前,Claude 只在从 Anthropic 获取的功能标志打开它的地方才自己启动 /code-review;在不获取功能标志的会话里,/code-review 只在你输入时才运行,调度的 /code-review 只会作为纯文本到达 Claude。)

ultrareview(云端深度评审)

ultrareview 是研究预览功能,功能、定价和可用性可能根据反馈变化。命令是 /code-review ultra;当 ultrareview 对你的账号可用时,/ultrareview 是它的别名。

ultrareview 是一种作为云端会话在 Anthropic 基础设施上运行的深度代码评审。运行 /code-review ultra 时,Claude Code 在云端沙箱里启动一队评审智能体,在你的分支或拉取请求里找缺陷。与本地 /code-review 相比:

  • 更高的信号:每条报告的发现都被独立复现和验证,所以结果聚焦真实的缺陷而不是风格建议。
  • 更广的覆盖:更大的评审智能体队伍并行探索这次改动,找出本地评审可能漏掉的问题。
  • 不占本地资源:评审完全在云端沙箱里运行,你的终端在此期间可以做别的事。

ultrareview 需要 claude.ai 账号认证,因为它作为云端会话在 Anthropic 基础设施上运行;如果你只用 API key 登录,先运行 /login 用 claude.ai 认证。使用 Amazon Bedrock、Google Cloud 的 Agent Platform 或 Microsoft Foundry 时它不可用,启用了零数据保留的组织也不可用;不可用时,/code-review ultra 改为在你的会话里运行本地评审。

从 CLI 运行 ultrareview

在任意 git 仓库里启动评审:

/code-review ultra

不带参数时,ultrareview 评审你当前分支与默认分支之间的 diff,包括未提交和已暂存的改动;对名称像凭据或密钥的文件(如 .env 和 *.tfvars)的未提交改动,Claude Code 遵循把本地仓库上传到云端会话的规则。对分支评审,Claude Code 打包仓库状态并上传到云端沙箱;评审拉取请求时,Claude Code 不从你的机器上传任何东西。启动前,Claude Code 显示一个确认对话框,列出评审范围、你剩余的免费运行次数和预估成本(分支评审的范围包含文件和行数);你确认后,评审在后台继续,你可以继续使用会话。该命令只在你用 /code-review ultra 调用时运行,Claude 不会自己启动 ultrareview。

对不同的基础评审。 要与默认分支之外的基础比较,传分支名。这个例子把你当前分支与 develop 比较:

/code-review ultra develop

基础分支不需要存在于你的本地克隆里,Claude Code 从 origin 获取它;名称有拼写错误时,Claude Code 在错误里建议最接近的分支名。提交 id 或标签也可以作为基础,此时评审覆盖你分支上自该提交以来的改动。

评审拉取请求。 要评审 GitHub 拉取请求而不是本地分支,传 PR 号:

/code-review ultra 1234

该命令也接受 #1234、PR 1234 和粘贴的 PR URL;粘贴的 URL 必须指向你当前目录中的仓库。在 PR 模式下,云端沙箱直接从宿主克隆拉取请求,而不是打包你的本地工作树。PR 模式适用于 github.com 上的仓库,以及 Owner 已连接到 Claude Code 的 GitHub Enterprise Server 实例。对 github.com 上的仓库,沙箱用连接到你 Claude 账号的 GitHub 账号克隆,所以该账号必须能读取 PR 所在的仓库;运行 /web-setup 把你的 GitHub CLI 登录连接到你的 Claude 账号。

把发现发布到拉取请求。 在 Claude Code v2.1.227 或更高版本上,当你评审 github.com 上的拉取请求时,可以让 Claude 把完成的发现作为单条普通评论,从你自己的 GitHub 账号发布到 PR 上。该评论不是评审或批准,并以「Generated by Claude Code」说明结尾;评审分支或 GitHub Enterprise Server 拉取请求时,Claude Code 只在你的会话里显示发现。除非你在那次运行里选择,否则 Claude Code 从不发布,--no-post 是默认。发布是你对每次运行做的选择:

  • 交互式:在启动对话框里选 Run and post the findings to the PR as me。如果你在命令里加 --post(如 /code-review ultra 1234 --post),Claude Code 预选该选项,启动前仍会询问。
  • 非交互式:带 --post 运行 claude ultrareview 子命令。你通过带该标志运行子命令来同意发布,所以 Claude Code 不询问就发布。在 claude -p '/code-review ultra' 运行里,Claude Code 在发现到达之前就退出,所以它不发布任何东西,改用子命令。

Claude Code 不从你的机器发布:它把评审的会话 ID 发给 Anthropic API,由 API 通过你连接到 Claude 的 GitHub 账号把评审存储的发现作为评论发布。发布需要与评审本身相同的 claude.ai 登录,在第三方提供商上或设置了 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 时不可用。在交互会话里,Claude Code 在发现到达时开始发布,所以要保持会话开着直到评审完成;Claude Code 只在该会话里保留发布选择,会话在评审完成前结束的话,即使你之后恢复对话,Claude Code 也不发布任何东西。发布完成时,Claude 告诉你结果:Posted(给你评论的链接)、Already posted(该评审较早的发布已经把评论放到了 PR 上,Claude 链接到拉取请求而不是再次发布),或 Failed(Claude 告诉你原因,发现留在你的终端里,你可以手动发布)。

用平实的话传达请求。 在 Claude Code v2.1.218 或更高版本上,你也可以用平实的话描述你在做的事:

/code-review ultra check my auth changes

评审仍然覆盖你当前的分支,范围与不带参数运行相同。Claude 把你的文字作为备注保留,显示在启动对话框里,并在发现到达时把它们与备注关联起来。只有当文字超过一个词且不是分支名或 PR 引用时,Claude Code 才把它当作备注;它把单个词读作分支名或 PR 引用,所以拼错的分支名得到「对不同基础评审」里最接近分支的错误,而不是带着备注启动。如果你的文字把 PR 引用与其他词结合(如 check PR 123 again),Claude Code 两种都不启动,而是请你只用 PR 号重新运行来评审那个 PR,或不带引用来评审你当前的分支。如果你的仓库太大无法打包,Claude Code 会提示你改用 PR 模式:推送你的分支并开一个草稿 PR,然后运行 /code-review ultra <PR-number>。

diff 限制和回退

ultrareview 在任何评审工作运行之前检查 diff,并在无法按原样评审时告诉你:

  • diff 太大:分支评审默认最多包含 500 个变更文件和 8,000 行变更(具体值可能变化,拒绝信息会点名生效的值、你的 diff 的大小以及变更行最多的文件)。Claude Code 以同样方式拒绝过大的拉取请求,点名它的文件和行数,但没有逐文件的明细。
  • 没有可评审的内容:相对基础的 diff 为空时,ultrareview 拒绝并点名它比较的分支或提交以及你所处的情形(如在基础分支本身上且没有未提交的内容,或某个分支的提交都已是基础的一部分),并给出该情形的出路,如切换到有你工作的分支、暂存或提交本地编辑,或传入不同的基础。
  • 首次提交:仓库的第一个提交没有更早的内容可比较,所以 ultrareview 在你于启动对话框里确认后评审其中的每个文件;如果有未跟踪文件,它改为拒绝并告诉你 git add 你想评审的那些,适用同样的大小限制。首次提交只有在该确认之后才被整体评审,所以 claude ultrareview 子命令和 claude -p 会拒绝它并指引你到交互会话(需要 v2.1.277 或更高)。
  • 没有合并基点:当你的分支与基础分支没有共享历史,或仓库没有可比较的基础分支时,ultrareview 改为评审仓库里每个被跟踪的文件。这个回退要求完整克隆,适用同样的大小限制;它只在你于启动对话框里确认或自己运行 claude ultrareview 子命令时才启动,在 claude -p 和两者都没发生的任何其他地方,ultrareview 拒绝、说明评审会覆盖每个文件,并指引你到交互会话。在没有分支或其他引用的检出上(例如获取某个 URL 后检出 FETCH_HEAD 创建的分离 HEAD),Claude Code 拒绝评审并建议先创建一个分支。

定价与免费运行

ultrareview 是高级功能,按用量额度而不是你套餐的包含用量计费(以下为官方核实时的数字,以官方为准):

套餐包含的免费运行免费运行之后
Pro3 次免费运行按用量额度计费
Max3 次免费运行按用量额度计费
Team 和 Enterprise无按用量额度计费
  • 免费运行:Pro 和 Max 的三次运行是每个账号一次性的配额,不会刷新。
  • 每次评审的成本:用完免费运行之后,通常是 5 到 25 美元的用量额度,取决于改动的大小,与启动对话框在每次运行前显示的估算一致。
  • 何时计一次运行:云端会话启动之后。你提前停止或未能完成的评审仍会用掉一次免费运行;付费评审只为实际运行的部分计费。

因为免费运行之外 ultrareview 总是按用量额度计费,你的账号或组织必须先打开用量额度,才能启动付费评审。如果没有打开,Claude Code 会阻止启动;怎么打开取决于你的账单权限:如果你能管理账号的账单,Claude Code 链接到你可以打开用量额度的账单设置;在 Team 和 Enterprise 套餐上,没有账单权限的成员从 CLI 发一个请求,让管理员打开用量额度。你也可以运行 /usage-credits 检查或更改你的用量额度设置。Claude Code 每个对话要求你确认一次用量额度计费:当你开始新对话(例如用 /clear)时,Claude Code 在下一次付费评审时再次显示确认。

跟踪运行中的评审

评审通常需要 5 到 10 分钟。评审作为后台任务运行,所以你可以在会话里继续工作、启动其他命令,甚至完全关掉终端。如果你选择了把发现发布到拉取请求,要保持会话开着直到评审完成;会话先结束的话,Claude Code 不发布任何东西。

用 /tasks 查看运行中和已完成的评审、打开某个评审的详情视图,或停止进行中的评审;如果你停止评审,Claude Code 归档云端会话并且不返回部分发现。Claude 也可以告诉你评审被停止了,或它的会话没找到:评审的云端会话在评审完成前于 claude.ai 上被停止或归档,Claude 告诉你它被停止了;评审的云端会话被删除,或你自启动评审后登录了不同的 Claude 账号或组织,Claude 告诉你会话没找到;如果你切换了账号,评审可能仍在启动它的账号下完成,评审仍在运行的话,重新以该账号登录并用 claude --resume 恢复对话以重新附加它。

评审完成时,Claude Code 在会话里以通知显示已验证的发现。每个发现包含文件位置和问题的解释,让你可以直接让 Claude 修复它。

非交互运行 ultrareview

用 claude ultrareview 子命令从 CI 或脚本启动 ultrareview,无需交互会话。子命令启动与 /code-review ultra 相同的评审,阻塞直到远程评审完成,并把发现打印到 stdout。

claude ultrareview
claude ultrareview 1234
claude ultrareview origin/main

不带参数时,子命令评审你当前分支与默认分支之间的 diff,在没有合并基点时与 /code-review ultra 一样有整个仓库的回退;传 PR 号来评审拉取请求,或传基础分支来对它评审,基础分支的处理与交互式命令一致。你在运行子命令时就同意了整个仓库回退以及计费和条款提示,所以运行无需等待输入就开始;你自己运行它才算同意。当 Claude 替你运行该子命令(例如通过 Bash 工具)时,Claude Code 拒绝整个仓库的评审。

在 Claude Code v2.1.218 或更高版本上,你也可以在非交互会话里运行 /code-review ultra 来启动云端评审,例如 claude -p '/code-review ultra':Claude Code 启动评审并打印跟踪链接而不等待发现,这与阻塞到发现到达的 claude ultrareview 不同;评审会计用量额度时,Claude Code 在启动前停止并指引你用 claude ultrareview,因为计费确认需要交互会话(v2.1.218 之前,非交互会话里的 /code-review ultra 运行本地评审)。

进度消息和实时会话 URL 发到 stderr,使 stdout 保持可解析。用这些标志控制输出、超时以及是否发布发现:

标志说明
--json打印原始的 bugs.json 负载,而不是格式化的发现
--timeout <minutes>等待评审完成的最大分钟数,默认 45
--post把完成的发现作为单条普通评论,从你的 GitHub 账号发布到拉取请求上;适用于 github.com 拉取请求目标,其他目标上 Claude Code 忽略该标志并说明(需要 v2.1.227 或更高)
--no-post不发布发现;这是默认,同时传两个标志时 Claude Code 不发布(需要 v2.1.227 或更高)

运行 claude ultrareview 要求与 /code-review ultra 相同的认证和用量额度配置。子命令以三个退出码之一退出:0 评审完成(有无发现皆可);1 评审启动失败或在完成前被停止、云端会话出错或超时;130 你用 Ctrl-C 中断了子命令。如果你中断子命令,远程评审继续运行;跟随打印到 stderr 的会话 URL 在浏览器里观看。带 --post 时,子命令在打印发现之后立即开始发布,并把链接打印到 stderr:如果运行失败、被停止或超时,或你中断了它,子命令不发布任何东西;如果评审完成但评论没有发布,Claude Code 把原因打印到 stderr,发现留在 stdout 上,你可以手动发布。

对 GitHub 拉取请求的自动评审,Code Review 直接与你的仓库集成,把发现作为行内 PR 评论发布,无需 CLI 步骤。

ultrareview 与 /code-review 的对比

两种评审都检查代码,但你在工作流的不同阶段使用它们:

/code-review/code-review ultra
目标你的工作 diff、拉取请求、分支或路径你的工作 diff 或拉取请求
运行位置本地,在你的会话里云端沙箱里
深度随 effort 参数而变带独立验证的多智能体队伍
时长几秒到几分钟大约 5 到 10 分钟
成本计入正常用量免费运行,之后每次评审大约 5 到 25 美元的用量额度
最适合迭代时的快速反馈对大改动的合并前信心

工作时用 /code-review 获得快速反馈,或传 PR 号在批准之前评审队友的拉取请求;在合并大改动之前,想要能抓住本地评审可能漏掉的问题的更深一遍时,用 /code-review ultra。

相关资源

  • 命令:在本地 Claude Code 会话里运行 /code-review,在推送之前检查 diff。
  • GitHub Actions:在你自己的 GitHub Actions 工作流里运行 Claude,做代码评审之外的自定义自动化。
  • GitLab CI/CD:面向 GitLab 流水线的自托管 Claude 集成。
  • 记忆:CLAUDE.md 文件如何在 Claude Code 里工作。
  • 分析:跟踪代码评审之外的 Claude Code 用量。
  • 在云端使用 Claude Code:了解云端会话和云端沙箱如何工作。
  • 有效管理成本:跟踪用量并设置支出限额。