Claude Code 的 advisor 与 ultrareview：两个容易被忽略的机制

2026-08-18

「这一步别自己拍脑袋，找个更强的模型再看一眼」——这个诉求在 Claude Code 的官方文档里对应着两套完全不同的东西：advisor 工具和 ultrareview。区分它们的不是「谁更深」，而是两个更实际的问题：谁按下那个按钮，以及看完之后东西掉在哪里。 下面按官方文档写明的内容，把两条路径各走一遍。

advisor：你配置，模型自己决定什么时候叫

官方文档在 code.claude.com/docs/en/advisor 页首的 Note 里写明，advisor 工具是 experimental（实验性），且要求走 Anthropic API，并写明它在 Amazon Bedrock、Claude Platform on AWS、Google Cloud’s Agent Platform、Microsoft Foundry 上不可用；同一段还写明它的行为、定价与可用性都可能变化。

三种开启方式，以及它们的优先级

文档列出三种设置 advisor 模型的方式：

/advisor 命令：会话中途设置或更换，并保存为默认值
advisorModel 设置项：在 settings 文件里配一个持久默认值
--advisor 启动参数：只对本次会话生效

文档给出的写法分别是：

/advisor opus

{
  "advisorModel": "opus"
}

claude --advisor opus

有个细节值得单独拎出来：文档写明 --advisor 这个 flag 不出现在 claude --help 的列表里——翻帮助信息是翻不到它的。文档同时写明，该 flag 对当前会话的优先级高于 advisorModel 设置；如果本次会话的主模型不支持 advisor，或者请求的 advisor 模型被组织的 availableModels 白名单排除掉了，它会直接报错退出。

/advisor 不带参数运行时会打开一个可选模型的选择器；设置成功后文档写明会以 Advisor set to 加模型名确认，选择保存到用户设置的 advisorModel 里、跨会话保留。以上按钮名与提示文案均为官方文档写明的内容。

设置里的模型别名（fable、opus、sonnet）文档写明会解析到 Claude Code 内置的对应默认版本，而这个默认版本会随 Claude Code 的新版本推进——也就是说你写死一个别名，它指向的实际模型是会变的。你也可以传完整的模型 ID。

配对校验：配了不等于挂上了

这一层最容易踩空。文档写明 advisor 的能力必须不弱于主模型，Claude Code 在发请求前会做配对校验，结果有两种：

advisor 弱于主模型：advisor 不会挂到主模型的请求上，/advisor 的输出和一条通知会显示这个状态
主模型或 advisor 是 Claude Code 不认识的模型：同样不挂载

还有一条容易被忽略：文档写明 subagent 会继承已配置的 advisor，并针对它自己的模型再做一次同样的配对校验。所以会出现主模型这边没挂上、但某个 subagent 因为自己的模型满足配对而照常在用 advisor 的情况。

另外，文档把「feature-flag fetching」列进了 advisor 的三条 Requirements 之一：Claude Code 是通过从 Anthropic 拉取的 feature flag 来打开 advisor 的，在设置了会关掉 flag 拉取的变量（文档举的例子是 DISABLE_TELEMETRY）的会话里，advisor 保持关闭。它不是报错，而是不生效。

开启成功时的信号，文档写明是会话启动后出现一条 Advisor Tool (experimental) is on and may use more tokens · /advisor 的通知。

触发条件：没有开关能强制或限流

文档写得很直白：由 Claude 决定什么时候调用 advisor。倾向于在三类时刻——确定方案之前、某个错误反复出现时、宣布任务完成之前——但文档明确说这是「model-driven rather than rule-based」，是模型驱动而非规则驱动。

配套的一句更关键：没有任何设置项可以给 advisor 调用次数封顶或强制触发。想让它多问或少问，文档给的办法只有在提示词里说，比如 consult the advisor before you continue——把它当成一个普通工具在 prompt 里请求。

产出形态：一段进对话的指导，不是一份报告

advisor 每次调用都会拿到完整的对话，包括每一次工具调用和结果，返回的是 Claude 在继续之前会应用的指导意见。

官方文档写明，调用进行中转录里会显示一行 Advising 加 advisor 模型名；结果返回后这一行会确认 advisor 已经审阅过对话，按 Ctrl+O 展开可以读到 advisor 的完整指导。

它不是硬性命令。文档写明 Claude 一般会遵循 advisor 的指导，但在自己的证据与某条具体主张冲突时会调整——比如建议的步骤试了之后失败、文件内容与建议相矛盾，此时 Claude 会把冲突摆出来而不是无条件照做。

文档还写明中途开关 advisor 不会让主模型的 prompt cache 失效（与切换模型或 effort level 不同），advisor 返回的指导会作为转录的一部分在后续轮次里被缓存；但 advisor 自己对对话的读取不缓存，每次调用都重新处理完整转录，调用之间没有复用。

要关掉：/advisor off，或者在 /advisor 选择器里选 No advisor。要更彻底地禁用，文档写明设 CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1，此时 /advisor 命令不可用、已配置的 advisorModel 被忽略，而 --advisor flag 仍会被接受但不产生任何效果。

ultrareview：只有你能发起，结果是一份可解析的产出

ultrareview 的文档页首同样有状态标注：它是 research preview（研究预览），命令是 /code-review ultra，当你的账户可用时 /ultrareview 是它的别名，功能、定价与可用性可能变化。

触发条件：Claude 不会自己发起

文档写得毫不含糊：这个命令只有在你亲自输入 /code-review ultra 时才运行，Claude 不会自己发起 ultrareview。而同一套文档讲本地 /code-review 时写明，本地审查 Claude 可以自己启动，用自然语言让它审一下就行，也可以挂到 scheduled task 上；但文档同时写明scheduled task 从不启动云端审查，所以计划任务里的 /code-review 不要带 ultra 参数。

生效前提，以及一次静默降级

ultrareview 跑在 Claude Code on the web 的基础设施上，文档写明它要求用 claude.ai 账户认证；如果你只用 API key 登录，需要先 /login 用 claude.ai 认证。文档还写明它在 Amazon Bedrock、Google Cloud’s Agent Platform、Microsoft Foundry 上不可用，对启用了 Zero Data Retention 的组织也不可用。

最需要记住的是紧跟着的那一句：当 ultrareview 不可用时，/code-review ultra 会改为在你的会话里跑一次本地审查。它不报错，它降级。

文档内部还有一处差异值得注意：advisor 页列出的不可用平台里包含 Claude Platform on AWS，而 ultrareview 页列出的三个平台里没有这一项。两页口径不同，具体以官方文档最新内容为准。

目标怎么解析

不带参数时，文档写明 ultrareview 审查的是当前分支与默认分支之间的 diff，包含未提交和已暂存的改动。给一个分支名就是换基线：

/code-review ultra develop

基线分支不需要存在于你本地的克隆里，Claude Code 会从 origin 取；名字打错时错误信息里会给出最接近的分支名建议。给一个 PR 号就是审 PR：

/code-review ultra 1234

文档写明也接受 #1234、PR 1234 以及粘贴的 PR URL（URL 必须指向你当前目录对应的仓库）。

在 v2.1.218 或更高版本上，还可以直接用大白话描述你在做什么：

/code-review ultra check my auth changes

这时审查范围仍是当前分支，和不带参数一样；这句话被当作一条 note 保留，显示在启动对话框里，findings 回来时与它关联。解析规则是：只有多于一个词、且不是分支名或 PR 引用时才当 note；单个词一律按分支名或 PR 引用解析——所以拼错的分支名会走到「最接近分支名」的报错，而不是被当成 note 启动。文字里既有 PR 引用又有别的词时（文档举的例子是 check PR 123 again），命令两边都不走，会让你要么只给 PR 号、要么把引用去掉。

上传边界

有合规要求的团队要先弄清这一节。文档写明：分支审查时，Claude Code 会打包仓库状态并上传到远端 sandbox；而审查 PR 时，不从你的机器上传任何东西——远端 sandbox 直接从托管方克隆这个 pull request。PR 模式适用于 github.com 上的仓库，以及由 Owner 连接到 Claude Code 的 GitHub Enterprise Server 实例。

启动之前会有一个确认对话框，文档写明其中会展示审查范围、剩余的免费次数和预估成本；分支审查的范围里包含文件数与行数。确认之后审查转入后台，你可以继续用你的会话。

什么时候会被直接拒掉

文档在开跑任何审查工作之前会先检查 diff，列了三种情况：

diff 过大：分支审查有默认的改动文件数与改动行数上限，文档明说这些具体值可能变化，拒绝信息里会给出当时生效的值、你这次 diff 的大小，以及改动行数最多的那几个文件；PR 过大时也会拒，但只给文件数与行数、不给按文件的细分
没东西可审：与基线的 diff 为空时会直接说明，并建议你把本地改动 stage 或 commit，或者换一个基线
没有 merge base：分支与基线分支毫无共同历史时，会回落成审查仓库里所有被跟踪的文件；这个回落需要完整克隆，并且适用同样的体积限制。而在没有任何分支或其它 ref 的检出上（文档举的例子是 fetch 一个 URL 之后 checkout FETCH_HEAD 造成的 detached HEAD），会直接拒绝并建议你先建一个分支

仓库大到打不成包时，文档建议改走 PR 模式：推分支、开 draft PR，用 PR 号跑。

产出形态：通知、`/tasks`、stdout

交互式会话里，审查作为后台任务运行，你可以继续干别的、开别的命令，甚至把终端关掉。用 /tasks 可以看正在跑和已完成的审查、打开某次审查的详情、或者停掉一次进行中的审查。文档写明停掉之后云端会话会被归档，不返回任何部分结果。审查完成时，经过验证的 findings 会以通知形式出现在会话里，每条包含文件位置和问题解释，你可以直接让 Claude 去改。

非交互场景走的是另一个入口：claude ultrareview 子命令。文档写明它启动的是与 /code-review ultra 相同的审查，阻塞直到远端审查结束，并把 findings 打印到 stdout：

claude ultrareview
claude ultrareview 1234
claude ultrareview origin/main

输出通道是分开的：进度信息和实时会话 URL 走 stderr，stdout 保持可解析。可用的 flag 里，--json 打印原始的 bugs.json 载荷而不是格式化后的 findings；--timeout <minutes> 控制最多等多少分钟，文档写明默认 30——这是文档写明的默认值，随版本可能变动。退出码是三档：审查完成（无论有没有发现问题）为 0，启动失败、云端会话报错或超时为 1，被 Ctrl-C 打断为 130。文档还写明你打断子命令后远端审查仍在继续跑，顺着 stderr 上打印的会话 URL 可以在浏览器里接着看。

还有一条容易搞混的：claude -p '/code-review ultra'（需 v2.1.218 或更高版本）会启动云端审查并打印一个跟踪链接，但不等 findings 回来；要拿到结果就得用 claude ultrareview 子命令。文档也写明，当这次审查会走 usage credits 计费时，-p 这条路会在启动前停下，因为计费确认需要交互式会话。

至于把 findings 发回 PR：文档写明需要 v2.1.227 或更高版本、目标是 github.com 上的 pull request，发出去的是一条普通评论（以你自己的 GitHub 账户身份），不是 review、也不是 approval，结尾带一句 “Generated by Claude Code”。默认是 --no-post，也就是不发；交互式下要在启动对话框里选 Run and post the findings to the PR as me，加了 --post 只是预选、启动前仍然会问。交互式会话必须一直开着直到审查结束，会话先结束的话什么都不会发，之后恢复对话也不补发。发布这一步走的是 Claude Code on the web，因此在第三方承载平台上、或设置了 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 时不可用。

Windows 侧提醒一句：CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 是官方文档给出的变量名与取值，怎么设置属于 shell 的事——PowerShell 用 $env: 前缀，cmd 用 set，Linux/macOS 的 bash 用 export。这一句是操作系统层面的通用做法，不是官方文档的内容。

放在一起看：区别落在两个地方

	advisor	ultrareview
状态标注	experimental	research preview
谁发起	Claude 在决策点自行调用	只有你输入命令才跑
有没有开关控制频率	文档写明没有封顶或强制的设置	每次都是你显式发起
跑在哪	服务端 server tool	远端 sandbox（Claude Code on the web 基础设施）
拿到什么输入	完整对话，含每次工具调用与结果	分支 diff 或 PR
结果落在哪	转录里的一段指导，Claude 继续时应用	findings 通知 / stdout / 可选发到 PR
不可用时	静默不挂载（配对不过、flag 未拉到）	静默降级为本地审查

真正会咬到你的是最后一行：两个机制在不满足前提时都不报错。advisor 是「配了但没挂上」，ultrareview 是「输了 ultra 但跑的是本地」。所以验证方式不是「我配了」，而是去看那条 Advisor Tool (experimental) is on... 的通知在不在、这次审查是不是真的进了 /tasks 的后台任务列表。

另一处差别在于「第二意见落在哪」。advisor 的产出进入同一段对话，复盘只能靠 Ctrl+O 展开转录；ultrareview 的产出是一份独立的 findings，能进通知、能进 stdout、能用 --json 拿到 bugs.json 原始载荷，也就能被 CI 脚本消费——要做成流水线上的一道闸，只有后者有接口。两者的文档都写明行为与可用性可能变化，编排进日常流程之前先确认它在你的账户与承载平台上确实生效。

本文依据 Claude Code 官方文档（code.claude.com/docs）于 2026-08-17 的公开内容整理。该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。该产品迭代频繁，文中涉及的命令、配置项与默认值随版本变动，请以官方文档最新内容为准。本文不涉及价格、额度与限流的具体数值，相关信息请以官方定价与用量说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。