Claude Code 一个 100 行的改动，Review 跑了 35 分钟

一个 100 行的改动，Review 跑了 35 分钟

内置 /code-review 的“永远 max”之谜

2026-10-29 · 工程笔记 · 约 8 分钟阅读

这次我让 Claude Code 审一个很小的 Flutter UI 改动：生产代码六十多行，连测试一起一百多行。底部进度面板加了几个收起手势，顶部加了个拖拽把手，顺手把折叠按钮的热区从 32pt 调到 36pt。代码量不大，测试也补了，我估摸着十分钟能收工。

调用时我特意写了 medium——这种小改动，中等力度扫一遍就够了。

结果这一轮 review 跑了 35 分钟。

我第一反应是模型慢，或者测试跑得久。直到我打开了 subagents 目录。

结论先行

• 在当前版本（Claude Code 2.1.311）里，内置 /code-review 的级别参数没有生效：传 low、medium、high、--effort high，实际加载的都是 max profile。
• 唯一真正生效的是 --max-findings，但它只限输出条数，不减 agent 数量。
• 这一次 review 起了 12 个 agent：1 个主控 + 11 个并行审查角度。
• 这不是“默认 max”，而是“级别被忽略”。两件事的差别在于：前者你可以通过显式传参覆盖，后者不能。

35 分钟去哪了

一次 Skill 调用，结果只回来一个 JSON 数组。表面上看不出中间发生了什么。

我去翻了这次会话的 subagents 目录：

ls ~/.claude/projects/<project>/<session>/subagents/

12 个文件。每个 .meta.json 里记着 agent 的职责和父子关系：

{
  "agentType": "general-purpose",
  "description": "Angle A line-by-line scan",
  "parentAgentId": "a0a071f779daa3d3d",
  "spawnDepth": 2
}

把 description 摊开，大概是这些角度：

角度	在查什么
Angle A	逐行扫描 diff
Angle B	被删除的行为
Angle C	跨文件追踪
Angle D	语言/框架陷阱
Angle E	包装层正确性
Gap sweep	补漏复审（fresh reviewer）
Simplification	简化
Reuse	复用
Efficiency	效率
Altitude	抽象层级
Conventions	CLAUDE.md 约定

每个角度最多交 8 条候选，然后是一轮验证和一次补漏，最后按严重程度截断。对一百行的 diff 来说，这套流程像用消防水龙头浇一盆花。

一个没有生效的参数

我传的是 medium。但主控 agent 的根 prompt（初始指令）第一行是：

max effort → 5+5 angles × 8 candidates → 1-vote verify → sweep → ≤15 findings

You are reviewing for recall at maximum effort...

我把整个 prompt 搜了一遍，连 medium 这个词都没出现。

这不像“参数没传进去”那么简单——--max-findings 是生效的。更像级别 token 在某一层被吃掉了，最后落到了 max 的默认档。具体是 Skill 的解析、内置 skill 的 prompt 组装，还是别的环节，我没法从本地 transcript 里确定；但对使用者来说结论是一样的：这个旋钮现在不工作。

翻历史记录

我把本机几个项目的历史 review 都翻了一遍。只统计能同时看到“调用参数”和“根 prompt”的记录：

传给 skill 的参数	实际 profile	输出上限
low	max	≤15
low --max-findings 10	max	≤10
high --fix	max	≤15
--effort high	max	≤15
medium	max	≤15
不传	max	≤15

没有一条 low/medium/high 的 profile 记录。唯一另一个变体是 Agent tool unavailable → single-pass inline——Agent 工具不可用时的降级版，仍然是 ≤15 条。

所以这次不是偶发。之前那些 review 很可能也是 max，只是没有小 diff 做对照，绝对耗时看起来不刺眼。

为什么之前没发现

1. 大 diff 本来就慢。 一小时的 review 和三十分钟的 review，在没有基线时很难判断哪个不正常。
2. --max-findings 是真的。 它能改变输出条数，这会让人误以为级别也在正常工作。
3. fan-out 是黑盒。 一次 Skill 调用只返回一个结果，中间的 11 个 agent 不会出现在你的终端里。
4. 没人会去读 subagent 的 prompt。 除非你怀疑它。

这次之所以露馅，是因为 diff 小到不合理：几十行生产代码配 11 个 reviewer，怎么算都不对。

这不只是“慢”

• 成本控制失效。 你按风险分级，工具却只有一档。low 和 max 花一样的钱。
• 静默降级比报错更糟。 如果 level 没识别，至少应该告诉我“已忽略 medium，使用 max”。现在的行为是悄悄换挡。
• 多 agent review 需要可观测性。 起了多少 agent、每个阶段多久、花了多少 token，应该能在结果里看到，而不是让人去翻 JSONL。

不过话说回来，这次 review 本身是有价值的。它抓到了一个我确实会漏掉的问题：展开态头部包了一整行 GestureDetector，点到禁用的眼睛按钮时，按钮没有 tap recognizer，事件穿透到外层，把面板收起来了。还指出我有个测试点的是默认已选中的分段，就算点击根本没落到控件上，测试也会绿。

所以问题不是“该不该 review”，而是“花了 max 的钱，却以为自己买的是 medium”。

我现在怎么做

既然内置 skill 的级别不可靠，就把分级放到外面：

档位	做法	适用
Low	inline 自审，或起 1 个 agent 单遍扫 diff	小 UI、样式、纯测试改动
Medium	1 个 reviewer + 针对性验证	有行为变化、已有测试覆盖
High/Max	内置 /code-review，按 11–12 个 agent 的预算排期	BLE、协议、网络、状态机、数据迁移

如果还是想用内置 skill，至少把 --max-findings 用上；它能控制输出条数，但不会减少 agent。

想自查的话：

# 看根 prompt 加载的是哪一档
grep -a -m1 -o '`[a-z]* effort → [^`]*`' \
  ~/.claude/projects/*/*/subagents/agent-*.jsonl

# 数一次 review 起了多少 agent
ls ~/.claude/projects/<project>/<session>/subagents/*.meta.json | wc -l

一个小提醒：终端里 claude --version 和 VSCode 扩展实际运行的 binary 可能不是同一个版本。我这次 claude --version 显示 2.1.287，但会话进程用的是扩展自带的 2.1.311。排查前先确认你看的是哪个。

最后

这次排查让我改了一个习惯：当AI Coding发生了一些不同寻常的事情时，一定要停下来回溯一下，这次问题排查让我对 claude code 自带的 /code-review 有了更深入的了解。

毕竟，最贵的不是 35 分钟，而是你以为自己只花了 10 分钟。