Claude Code 的 /code-review 五个 effort 档位全测：埋入 12 个 bug，各档查出多少、花了多少

Q: /code-review、Code Review 和 ultrareview 有什么区别？

/code-review 是在你自己的 Claude Code 会话中运行的命令，按你选择的 effort 档位工作，任何套餐都能用。Code Review 是面向 Team 和 Enterprise 组织的托管服务，通过 GitHub App 审查 GitHub 拉取请求，可选 Quick、Standard 或 Deep 档位，按用量额度收费，于 2026 年 10 月 15 日正式开放。ultrareview 用 /code-review ultra 启动，在云端沙箱里运行一组评审代理。Anthropic 文档称，每个发现都会被独立复现和验证，一次审查通常需要 15 到 25 分钟。

30 秒看懂结论

10 月 15 日，Anthropic 正式开放了面向 Team 和 Enterprise 套餐的托管 Code Review 服务，用来审查拉取请求。同一天，Anthropic 还发文介绍了 Claude Code 团队自己怎么审代码，这篇文章在 Hacker News 获得了 487 分。任何套餐的用户都可以通过 /code-review 做这类审查：它在你自己的会话里运行，按你输入的 effort 档位工作。

我们搭了一个小 Python 包，做了一份新增 222 行的改动，埋入 12 个 bug，另放了四处干扰项（看着可疑、其实正确的写法）。随后在 Claude Code 2.1.310 中，用 Opus 5.5 把 /code-review 的五个 effort 档位都跑了一遍。接着修好这 12 个 bug，再审一次同一份改动。

medium 及以上，每次都在回复里点到了全部 12 个 bug。low 跑了三次，每次只列四条，分别覆盖五个、四个和四个 bug。
档位决定问题清单的上限。评审子代理收到的指令规定，low 最多 4 条，medium 和 high 最多 10 条，xhigh 和 max 最多 15 条。medium 和 high 通常会把放不下的一两个 bug 写进清单外的说明，或合并到其他条目中。medium 加 --max-findings all 的那次花了 $0.15，列全了 12 个。
档位也影响找问题的方法、耗时和花费。按 Claude Code 报告的 API 标价折算，low 花 $0.06–$0.07、约 10 秒，medium 花 $0.13–$0.14、30 秒，high 花 $0.14–$0.17、37 秒，xhigh 花 $0.32–$0.36、97 秒。max 动用了 30 个代理，花了 24 分钟和 $18.73，列出的也是这 12 个 bug，花费约为 high 的 120 倍。
修好 bug 后，每档仍列了条目：low 1 条，medium 10 条，high 8 条，xhigh 15 条，max 15 条。按我们的逐条判定，每档有一到四个是未埋入的真实问题；xhigh 和 max 另各有一个 Python 3.9 兼容问题。其余大多是建议，还有两条里的示例值算错了。
干扰项要连同输入范围一起看。在函数签名允许的输入范围内，没有哪次运行把干扰项判成 bug。有两个档位指出，其中一处遇到类型注解已排除的输入会出错；还有四个档位建议改写另一处，以便整理代码。

结论：像我们这样的改动，用默认的 medium 加 --max-findings all 就很合适。这次 /code-review 约 30 秒列全了 12 个 bug，按 API 标价折算只要 15 美分。想让评审实际跑代码核实发现，可以用 xhigh。我们这次观察到它这样做了，但它的配方并不要求验证，不能保证每次都会执行。max 花了 24 分钟和 $18.73，列出的仍是这 12 个 bug。它适合留给高风险改动，作为一个慢而带验证的第二意见，常规改动不必把它当首选。

/code-review 是什么

/code-review 是 Claude Code 内置的技能，/review 是它的别名。它审查当前分支的改动，查找正确性 bug。审查由一个拥有独立上下文的子代理完成，发现会返回到你的会话里。用 -p 非交互模式运行时，命令会等待审查完成，再把发现写进回复。加 --fix 会落实修复，加 --comment 会把发现发布到拉取请求。

effort 档位写在第一个参数的位置。Anthropic 文档说，low 只报告最有把握的发现，以减少误报（原文：“so you see fewer false positives”）；从 medium 到 max 则逐步扩大覆盖范围。如果省略档位，就沿用你上次在交互式会话中输入的值。-p 运行中传入的档位不会被记住。如果从来没有输入过档位，就使用当前会话的 effort 设置；Opus 5.5 的默认值是 medium。

名字相近的审查产品有三种，运行位置、适用套餐和计费方式各不相同：

	`/code-review`	Code Review	`/code-review ultra`
运行位置	你自己的会话，以子代理运行	Anthropic 的基础设施，审查 GitHub 拉取请求	云端会话
适用套餐	任何套餐	Team 和 Enterprise	需要登录 claude.ai
审查深度	effort 档位，从 `low` 到 `max`	按仓库选择 Quick、Standard 或 Deep	只有一种设置；文档称会验证发现
计费	套餐用量或 API 费用	用量额度（Usage credits），与套餐用量分开	每个 Pro 或 Max 账户免费 3 次，之后消耗用量额度，通常每次 $5–$25
通常耗时	几秒到几分钟，实测见下文	Anthropic 称为 6–10 分钟	文档称为 15–25 分钟

直到 10 月 15 日，Code Review 文档还写着平均每次审查花费 $15–25（原文：“averages $15-25 in cost”）。Internet Archive（互联网档案馆）在当天 18:47 UTC 保存的版本里仍有这句话，10 月 16 日 00:38 UTC 的版本里已经删掉。现在的费用页说，它没有固定的单次审查价格（原文：“has no flat per-review price.”）。

我们怎么测的

这个 Python 包原本只有一个金额模块、一个商品类型和一个购物车，以及一个测试。待审查的改动增加了优惠、分页、运费估算、积分、销售报表和重试辅助函数，共涉及八个文件，新增 222 行。其中有八个新测试，但只覆盖简单情况。仓库里的九个测试在两个版本上都能通过。我们埋入的 12 个 bug 都是普通的正确性问题，人工评审也应该能查出来：

#	文件	埋入的 bug	会出什么错
1	`pagination.py`	用 `len(items) // page_size` 计算页数	只要已有至少一整页，最后不足一页的内容就打不开
2	`pagination.py`	切片终点写成 `start + page_size - 1`	每个整页都会少一项
3	`discounts.py`	用 `float` 计算百分比折扣	返回浮点数，而且 $1.35 减价 30% 后得到 $0.94，正确值应为 $0.95
4	`discounts.py`	`day < self.ends_on`	优惠券在有效期的最后一天就不能用了
5	`cart.py`	默认参数为 `tags=[]`，方法还会往里追加内容	重商品的标签会出现在后续商品上
6	`cart.py`	遍历列表时调用 `list.remove()`	连续两个商品缺货时，第二个会留在列表里
7	`reports.py`	对 `Decimal` 使用 `total // len(orders)`	平均订单金额丢掉了美分部分
8	`reports.py`	按 `MM/DD/YYYY` 字符串排序	2025 年 12 月被排到 2026 年 1 月后面
9	`shipping.py`	`weekday() > 5`	周六被算成工作日
10	`retry.py`	在 `range(retries)` 中判断 `attempt == retries`	最后一次失败后返回 `None`，没有抛出异常
11	`loyalty.py`	`if not is_member:`	非会员反而拿到双倍积分
12	`shipping.py`	`month=day.month + 1`	遇到 12 月的任何日期都会崩溃

四处干扰项按原样写都是正确的。按整数克数计算箱数时，-(-total_weight_g // BOX_CAPACITY_G) 能正确向上取整。积分用 int(amount)，文档字符串已经说明，按业务规则舍去美分。range(len(revenues) - 1) 循环把每天和后一天配成一对，也没有越界。重试循环只捕获 TransientError，符合它的文档字符串。

我们另写了十二个答案测试，放在评审看不到的仓库外。这些测试在有 bug 的改动上全部失败，修好 12 个 bug 后全部通过。修好 bug 的同一份改动新增了 226 行。这里必须区分：它只是没有了我们埋入的那 12 个 bug，后面的结果会说明，它仍然有其他问题。

主实验使用 Claude Code 2.1.310 和 Opus 5.5，后者是我们 Max 套餐的默认模型：

claude -p "/code-review medium main...HEAD" --output-format json \
  --setting-sources project,local \
  --allowedTools "Bash(git:*),Bash(python3:*),Read,Grep,Glob,Agent"

主实验共 19 次，每次都新建 git 工作区（worktree），并关闭自动记忆（CLAUDE_CODE_DISABLE_AUTO_MEMORY=1），避免前一次留下的笔记影响后一次。我们没有开放 Edit 和 Write 工具，允许评审读文件、运行 git 和 Python 3.14.7。Python 仍有写文件的能力，不过每次结束后，git 都没有显示文件变动。

有 bug 的改动上，low、medium、high 各跑三次，xhigh 跑两次，max 跑一次；medium 和 high 再各加 --max-findings all 跑一次。修好 bug 的同一份改动上，每档各跑一次。花费取自 Claude Code 报告的 total_cost_usd，按 API 标价折算，不是实际账单；耗时取自 duration_ms。

修好 bug 后的条目由我们逐条分类，规则如下：

真实问题：函数签名和文档字符串允许的输入会触发错误结果或崩溃，而且我们已经复现。
建议：包括设计、命名、代码整理和测试覆盖，也包括只有无效输入才会触发的情况。例如优惠券百分比超过 100，违反字段注释里的 “0-100”，或商品重量为负数，不符合商店业务规则。
Python 3.9 兼容问题：单独计数，只有项目需要支持 3.9 时才算问题。
示例值错误：条目给出了一个具体结果，实际运行代码却得不到这个值。

埋入 12 个 bug 的改动：各档表现

档位	运行次数	列入清单的条目数	清单覆盖的埋入 bug 数	回复里任何位置提到的埋入 bug 数	每次花费	每次耗时
low	3	4, 4, 4	5, 4, 4	5, 4, 12	$0.06–$0.07	9–12 秒
medium	3	10, 10, 10	10, 11, 11	12, 12, 12	$0.13–$0.14	26–32 秒
high	3	10, 10, 10	10, 11, 12	12, 12, 12	$0.14–$0.17	31–42 秒
xhigh	2	15, 15	12, 12	12, 12	$0.32–$0.36	91–103 秒
max	1	15	12	12	$18.73	1,421 秒（24 分钟）
medium, `--max-findings all`	1	15	12	12	$0.15	32 秒
high, `--max-findings all`	1	16	12	12	$0.16	40 秒

“回复里任何位置提到”也包括清单外的补充说明。有时一条会涵盖两个 bug。比如有一次 medium 把页数算错和切片少一项合在一条里，所以 10 条清单也能覆盖 11 个 bug。

清单上限来自评审子代理收到的指令。在 Claude Code 2.1.310 中，子代理的提示词为各档位列了不同配方；这些上限来自我们看到的指令，并非官方文档明文规定。三条配方的原文分别是：

low：low effort → 1 diff pass → no verify → ≤4 findings
xhigh：10 inline angles → dedup (no verify) → sweep → ≤15 findings
max：5+5 angles × 8 candidates → 1-vote verify → sweep → ≤15 findings

medium 收到的配方与 high 完全相同：同一行标为 high effort 的指令，从八个角度审查，最多列 10 条。medium 和 high 的每次运行都提到了全部 12 个 bug，也都用满了 10 个名额。六次里有五次明确说明，部分发现受 10 条上限限制而未列入清单（原文：“cut by the 10-item cap”），再在清单外补充这些 bug，通常是报表里的一个或两个。另一次把两个 bug 合进一条，一共这样合并了两条，于是 12 个全都放下了。low 的三次中，有一次在清单里列四条，再用一小段话提到其余八个，整份回复因而覆盖了全部 12 个；另两次只提到了清单里那些。

加上取消上限的参数，约多花一美分。我们用 --max-findings all 分别跑了一次 medium 和 high，两次都列全了 12 个 bug，花费分别是 $0.15 和 $0.16。不加参数时，两档分别为 $0.13–$0.14 和 $0.14–$0.17。两次清单合起来还多列了这些内容：优惠券百分比缺少范围校验、浮点数 bug 影响的另一处代码、购物车和运费计算使用了不同重量单位、代码整理建议，以及测试只覆盖简单情况的提示。

只有 xhigh 和 max 实际跑代码检查了发现。有 bug 的改动上，low、medium、high 都没有执行任何代码。xhigh 为正确性问题写了小段 Python 检查并运行，其中一次说明，排在后面的两条没有执行检查。max 的代理则用 Python 逐个复现了埋入的 bug。

有 bug 的改动上，还出现了一些额外条目。除了埋入的 12 个，有的运行还报了一个我们没埋的真实问题：购物车也会修改调用方传入的 tags 列表。其他条目包括需要 Python 3.10 才支持的 date | None 注解、测试覆盖提示和建议。max 把向上取整的干扰项也列了出来，针对的是 Decimal 输入。它把这条和另一条归为只有“当前调用方不会传入的输入”才会触发的问题（原文：“need inputs no current caller passes”）。取消上限的那次 high 还说，优惠券百分比为负数会通过 Cart.total 让总价上涨。这条说错了：Cart.total 取优惠券和满减中较大的优惠，只有直接调用 apply_percent 才会出现它描述的涨价。

修好 bug 的同一份改动

档位	列入清单的条目数	未埋入的真实问题	Python 3.9 兼容问题	建议	含错误示例值的条目数	花费	耗时
low	1	1	0	0	0	$0.06	7 秒
medium	10	2	0	8	1	$0.14	31 秒
high	8	2	0	6	1	$0.17	37 秒
xhigh	15	3	1	11	0	$0.47	152 秒
max	15	4	1	10	0	$22.64	2,307 秒

下面这些情况，我们都在修好 bug 的代码上逐一复现了：

with_retries(fn, retries=0) 一次也不调用 fn，直接返回 None。五个档位都报了这一条。
paginate([], 7) 返回“共 0 页中的第 7 页”，没有抛出 “page out of range” 异常。medium 及以上都报了这一条。
把 datetime 作为 today 传入，是 date 类型注解允许的；但使用优惠券时，Cart.total 会抛出 TypeError。xhigh 和 max 报了这一条。
date | None 注解需要 Python 3.10。我们这台 Mac 上，/usr/bin/python3 运行的是苹果开发者工具里的 Python 3.9.6，在这个版本下连购物车模块都无法导入。xhigh 和 max 报了这一条；只有项目需要支持 3.9 时，它才算问题。
如果订单的 placed_on 是 datetime，报表会按每个时间戳各生成一行；如果混用 date 和 datetime，daily_rows 会抛出 TypeError。只有 max 报了这一条。

归为建议的条目，对代码行为的描述是准确的：优惠券百分比超过 100 时不会被拒绝，负重量可能让运费变成零或负数，retries 数的是尝试次数，优惠券日期按服务器时区计算，以及两个循环可以合成一个。其中，参数名叫“重试”，实际却把第一次尝试也算了进去，属于命名建议。

两条示例值错误出现在 medium 和 high，都是同一个箱数问题：它们说 Decimal 类型的重量 12.5 会算出一个箱子，代码实际返回零。high 还把相应运费写成 $4.50，实际是 $0.00。

再看干扰项。xhigh 和 max 指出，向上取整公式遇到 Decimal 或 float 重量会算错箱数，但这些输入已被函数的 int 类型注解排除。medium、high、xhigh、max 都建议改写那个把相邻两天配对的循环，属于代码整理。评审自己认定的 bug 比我们更多：high 把八条里的四条称为正确性 bug，max 把保留的 20 条里的 17 条称为 bug。上表采用的是我们按前述规则逐条判定的结果。

评审指令可能有助于解释为什么清单这么长，但我们没有做去掉这些指令的对照。medium 和 high 的目标是至少列出 5 条（原文：“Target at least 5 findings”），xhigh 则至少 7 条；紧接着又要求不要为凑数而编造（原文：“do not invent to hit the floor”）。指令还要求找问题的代理把半信半疑的候选也传下去，理由是悄悄丢掉这些候选是漏报的主要原因（原文：“finders that silently drop half-believed candidates are the dominant cause of misses”）。这些都是子代理收到的指令。max 以下的配方没有单独的验证步骤，不过这次 xhigh 自行跑了检查。修好 bug 后，只有 low 的清单接近空白。

max 多做了什么

只有 max 动用了多个代理来完成审查。有 bug 的改动上，主代理先把任务分给九个找问题的代理，每个各有一个角度：逐行扫描、检查被删除的行为、跨文件追踪、Python 常见陷阱、封装逻辑正确性，以及代码复用、简化、效率和根因分析。它们交回 19 个不同的候选问题后，主代理为每个候选启动一个验证代理，最后再做补漏扫描。总共是 1 个协调代理、9 个找问题的代理、19 个验证代理和 1 个补漏代理，合计 30 个，全部使用 Opus 5.5。

有 bug 的改动	high（3 次）	xhigh（2 次）	max（1 次）
评审代理数	1	1	30
清单覆盖的埋入 bug 数	10–12	12	12
按 API 标价折算的花费	$0.14–$0.17	$0.32–$0.36	$18.73
耗时	31–42 秒	91–103 秒	1,421 秒
输出 token 数	3,051–4,072	8,926–10,279	554,058

max 最后列了 15 条：12 个埋入的 bug 都已对着代码复现；Python 3.10 才支持的注解问题只能靠推断；另两条需要当前调用方不会传入的输入才会触发（原文：“need inputs no current caller passes”），分别是 Decimal 重量下的向上取整干扰项，以及优惠券百分比缺少校验。

验证代理给出的结果是 15 个已确认、3 个可能成立、1 个被否掉（原文：“15 confirmed, 3 plausible, 1 refuted”）。被否掉的是时区那条，验证代理认为这属于正常的设计选择（原文：“a normal design choice”），还指出优惠券截止日期的 bug 妨碍了示例验证。其余通过筛选、又放不进 15 条清单的候选，被写进了补充说明。

修好 bug 的同一份改动上，max 跑了 21 个代理：1 个协调代理、9 个找问题的代理、9 个按代码区域分工的验证代理、1 个补漏代理，以及 1 个负责验证补漏新增两条的代理。这次共验证 30 个候选，否掉 10 个，保留 20 个，列出 15 个，耗时 38 分钟，花费 $22.64。清单里有四个未埋入的真实问题，另有一个 Python 3.9 兼容问题，比其他档位多。

这次 max 保留了时区那条，认为可能成立。此时优惠券的 bug 已经修好。两次的验证分工和时区判断确实不同，但跑的是不同代码，因此说明不了 max 验证的可重复性。

前期对照：不允许运行 Python

主实验之前，我们还在有 bug 的改动上，把 low、medium、high、xhigh、max 各跑过一次，只允许 git 和读文件。这五次的其他条件也不同：当时 PATH 上的 python3 是 3.9.6，其中四次共用一个 git 工作区，low 那次是冒烟测试，自动记忆也还开着。

medium 和 high 与主实验一样，都提到了全部 12 个 bug。xhigh 列全了 12 个，试图跑测试时被拒绝，花费 $0.43。max 跑了 34 分钟，花费 $21.59，列出的仍是这 12 个 bug，并明确说明没有执行任何代码。

实际该怎么用

常规改动，用默认档位并取消清单上限：/code-review medium --max-findings all。在我们的改动上，这样约 30 秒列全了 12 个 bug，按 API 标价折算花了 $0.15。交互式会话会记住你输入的上限，直到传入 --max-findings default；-p 运行不会记住。
low 适合快速看一遍，覆盖范围有限。它最多列四条，只报最有把握的发现。在我们的几次运行里，这覆盖了 12 个 bug 中的四到五个。
想让评审实际跑代码检查，可以用 xhigh。同时要允许它执行你的测试命令，我们这里是 python3。这次 xhigh 检查了大多数发现，没有检查全部；它的配方没有验证步骤，因此不能保证它每次都会跑检查。
max 留给漏掉 bug 的代价更高的改动。如果这个代价超过半个多小时的等待和约 $20 的用量花费，再考虑用 max。它在我们的改动上列出的 12 个 bug 与 medium 相同，额外做的是给每条补上复现或明确理由，并否掉一个候选。
读清楚失败场景，再判断条目是否成立。每条都有失败场景。在修好 bug 的改动上，靠这些场景就能较快分清真实的边界情况和建议，也能发现箱数示例算错了。
本地命令遵循项目指令文件。它读取 CLAUDE.md，忽略 REVIEW.md。REVIEW.md 用来配置 GitHub 上托管的 Code Review 服务；给本地命令的项目评审规则应写进 CLAUDE.md。

这些情况没测

真实拉取请求。我们只测了一份人工合成的 222 行 Python 改动，埋的也都是普通 bug。更大的改动、其他语言，以及需要了解整个系统才能看出的 bug，结果可能不同。第三方 Quickchat 用 Martian’s Code Review Bench 的 20 个难拉取请求测试了本地 /code-review：high 使用 Sonnet 5.5，max 的所有审查子代理都被强制使用 Sonnet 5.5。Quickchat 报告，两档分别匹配到 27 个严重 bug 中的 21 个和 23 个。max 每次有 $30 和 90 分钟的上限，完成的 19 次平均花费 $20.95、耗时 56 分钟，high 则为 $0.11 和 40 秒。有五次 max 只返回了收尾说明，没有返回问题清单，Quickchat 从会话记录里恢复最后一份发现报告来评分；超时的那次按零计算。
其他模型。我们的全部运行都使用 Opus 5.5。
更多次重复运行。有 bug 的改动上，low、medium、high 各三次，xhigh 两次，max 一次；修好 bug 的改动上，每档一次。运行次数太少，不足以区分随机波动和档位之间的真实差异。
交互式会话。我们用的是 -p 非交互模式，审查在前台运行；交互式会话里，审查会在后台运行。
托管的 Code Review 服务和 ultrareview。它们在云端运行，按用量额度收费。

来源

Anthropic：Code Review 正式开放，2026 年 10 月 15 日。面向 Team 和 Enterprise，提供 Quick、Standard、Deep 档位。官方称，大多数审查现在约快了 3 倍，从约 20 分钟降至 6–10 分钟（原文：“Most reviews now finish about 3x faster (~20 minutes down to 6-10 minutes)”）。
Anthropic：Claude Code 团队如何审查代码，Addy Osmani、Morgan Westlee Lunt、Qing Wang，2026 年 10 月 15 日。Hacker News 讨论在 2026 年 10 月 25 日查看时有 487 分、480 条评论。
Anthropic：用 /code-review 在本地审查。说明 effort 档位、--max-findings、-p 的行为，以及 CLAUDE.md 和 REVIEW.md。查阅于 2026 年 10 月 25 日。
Anthropic：Code Review 费用与用量，查阅于 2026 年 10 月 25 日，称没有固定的单次价格（原文：“no flat per-review price”）。另见 Code Review 文档及其 Internet Archive 存档。截至 2026 年 10 月 15 日 18:47 UTC 保存的版本，仍称平均每次审查花费 $15–25（原文：“Each review averages $15-25 in cost.”）。
Anthropic：用 ultrareview 查找 bug，其中的定价与免费次数说明（原文标题：“Pricing and free runs”）。查阅于 2026 年 10 月 25 日。
Anthropic：模型配置，其中的 effort 档位调整说明（原文标题：“Adjust effort level”）。Opus 5.5 默认用 medium；文档提醒，max 可能出现收益递减，也容易过度思考（原文：“may show diminishing returns and is prone to overthinking”）。查阅于 2026 年 10 月 25 日。
Quickchat：Claude Code 多代理代码审查：花费与发现，2026 年 10 月 21 日。
Hacker News：Ask HN：如何处理已经上线、自己却看不懂的 AI 生成代码？，2026 年 10 月 19 日。在 2026 年 10 月 25 日查看时有 619 分、759 条评论。

我们的实测于太平洋时间 2026 年 10 月 25 日在一台 macOS 机器上完成：Claude Code 2.1.310、Opus 5.5，通过 claude -p 运行 19 次主实验 /code-review，采用 JSON 输出，每次新建 git 工作区，另有前述 5 次前期运行。我们从会话记录中读取了评审指令、工具调用和代理活动，用 Python 3.14.7 跑了答案测试，并在修好 bug 的版本上手动执行验证，核对了每一个被我们计为真实问题的条目和每一个示例值。

FAQ

Claude Code 的 /code-review 能做什么？ 它审查当前分支的改动，寻找正确性 bug，并在会话里报告发现。根据模型和 effort 档位，它还会提出复用代码、简化实现和提高效率的建议。它作为子代理在你自己的会话中运行，任何套餐都能用，消耗套餐用量或计入 API 费用。/review 是它的别名。加上 --fix 会落实修复，加上 --comment 会把发现发布到拉取请求。它与另外两项产品不同：面向 Team 和 Enterprise 的 GitHub 托管服务 Code Review，以及在云端运行的 /code-review ultra。

/code-review 该用哪个 effort 档位？ 我们在一份新增 222 行的改动里埋入了 12 个 bug，medium 及以上每次都在回复里点到了全部 12 个。low 最多列四条，覆盖四到五个 bug。Opus 5.5 默认用 medium；按 API 标价折算，medium 花 $0.13–$0.14、约 30 秒，加 --max-findings all 的那次列全了 12 个。xhigh 的 15 条清单也列全了 12 个，并自行编写 Python 检查来核实大多数发现，花 $0.32–$0.36、约 97 秒。max 动用了 30 个代理，耗时 24 分钟，按 API 标价折算花了 $18.73，列出的仍是这 12 个。我们只测了一份改动，每档只跑了少量几次。

/code-review 为什么只列 10 条？ 在 Claude Code 2.1.310 中，评审子代理收到的指令给问题清单设了上限：low 最多 4 条，medium 和 high 最多 10 条，xhigh 和 max 最多 15 条。放不下的 bug 可能出现在清单外的补充说明里，也可能合并进其他条目。用 --max-findings all 或指定数字可以调整上限，需要 Claude Code 2.1.288 或更新版本。我们有一次用 medium 加 --max-findings all，花 $0.15 列全了埋入的 12 个 bug。

修好埋入的 bug 后，/code-review 还报了什么？ 修好全部 12 个埋入的 bug 后，每档仍列了条目：low 1 条、medium 10 条、high 8 条、xhigh 15 条、max 15 条。按我们的逐条判定，每档有一到四个未埋入的真实问题，我们都复现了。xhigh 和 max 还各报了一个 Python 3.9 兼容问题，只有项目需要支持 3.9 时才算问题。其余大多是建议，涉及代码注释或商店业务规则不允许的输入，以及设计、代码整理和测试覆盖。两条里的示例值算错了。评审指令要求 medium 和 high 至少给出 5 条，xhigh 至少 7 条，同时明确说不要为凑数而编造。

/code-review 要花多少钱？ 用 Opus 5.5 审查这份新增 222 行的改动，Claude Code 报告的花费按 API 标价折算为：low $0.06–$0.07，medium $0.13–$0.14，high $0.14–$0.17，xhigh $0.32–$0.36，max $18.73。这些是折算值，不是账单；Pro 或 Max 套餐在额度内运行时消耗套餐内用量，不额外收费。托管的 Code Review 服务另收用量额度，与套餐用量分开，现在已不再给出固定的单次价格。直到 2026 年 10 月 15 日，它的文档还写着平均每次 $15–$25。ultrareview 给每个 Pro 或 Max 账户三次免费机会，用完不再刷新，之后通常每次消耗 $5–$25 的用量额度。

/code-review、Code Review 和 ultrareview 有什么区别？ /code-review 是在你自己的 Claude Code 会话中运行的命令，按你选择的 effort 档位工作，任何套餐都能用。Code Review 是面向 Team 和 Enterprise 组织的托管服务，通过 GitHub App 审查 GitHub 拉取请求，可选 Quick、Standard 或 Deep 档位，按用量额度收费，于 2026 年 10 月 15 日正式开放。ultrareview 用 /code-review ultra 启动，在云端沙箱里运行一组评审代理。Anthropic 文档称，每个发现都会被独立复现和验证，一次审查通常需要 15 到 25 分钟。