subagent 天生适合当这个“陌生人”:每个 subagent 从全新、隔离的上下文启动,看不到你的对话历史,自然也不知道实现时的心路历程,只能就代码论代码。Claude 无人值守干得越久,这道独立检查就越重要。
一句话结论
结论
在把任务算作“完成”之前,跑一次对抗式 review:要么直接运行自带的
/code-review(在全新 subagent 里审当前 diff 找 bug),要么自写 prompt 让 subagent 拿着你的计划对照 diff 报差距。官方官方原理:reviewer 在新上下文里只看到 diff 和你给的标准,看不到产生这段代码的推理过程,所以能就事论事地评判结果。
做法步骤
- 查正确性用
/code-review。在工作会话里直接运行。官方它默认审“当前分支领先 upstream 的提交 + 未提交改动”,也可指定目标:文件路径、PR 号、分支名或main...my-feature这样的 ref 区间。review 以后台 subagent 运行、有自己的上下文窗口,不占你的对话;结果完成后回到会话里。可加--fix直接把发现应用到工作区,或--comment把发现发成 PR 行内评论。 - 调置信度。官方给
/code-review传 effort 档位:low/medium 只报最有把握的发现、误报少;high 到 max 撒网更宽、可能夹带不确定的发现。不传就用会话当前档位。 - 查“是否符合计划”要自写 prompt。官方
/code-review只管找 bug;想对照 SPEC/计划验收,官方给的公式是三要素:点名要审的工作、点名对照的计划、定义什么算一个 finding。因为 reviewer 是 subagent,差距会直接回到实现会话,Claude 能当场修复再复审,不用你在窗口间搬运。 - 更强隔离:开第二个会话。官方官方的 Writer/Reviewer 模式:会话 A 实现,会话 B(全新上下文)审查,把 B 的反馈贴回 A 修复。理由同样是“新上下文不会偏袒刚写出的代码”。本站观点subagent 版胜在闭环自动,双会话版胜在你能亲手把关 reviewer 看什么,重要改动值得用后者。
- 别被 reviewer 带节奏。官方官方明确警告:被要求找茬的 reviewer 几乎总会报点什么,哪怕工作本身没问题;每条都追会走向过度工程(多余抽象层、防御式代码、测不可能发生的用例)。要在 prompt 里限定“只报影响正确性或明确需求的差距”,其余当可选建议。
- 注意
--fix与回退的交互。官方后台 review 的--fix编辑发生在你会话的 checkpoint 之外,/rewind撤不掉,要用 git 回退——细节见改坏了怎么回退。另:GitHub 侧还有托管版 Code Review(research preview,Team/Enterprise 订阅),在 PR 上评论@claude review触发,多 agent 审整个 PR 并按严重级别发行内评论,和本地/code-review是两套东西。
可直接抄的 prompt
对照计划的对抗式 review(官方公式的中文版,按需替换对象):
用一个 subagent 对当前 diff 做对抗式 review,对照 @SPEC.md:
不要向它转述任何实现过程,让它只看 diff 和以下标准。检查:
1. SPEC.md 里的每条需求是否都已实现;
2. 列出的边界情况是否都有对应测试;
3. 是否改动了任务范围之外的东西。
只报告影响正确性或明确需求的差距(gaps),不要风格偏好。
结果回来后,把发现按“必须修 / 可选”分类,先给我看清单再动手修。纯找 bug 直接跑:
/code-review来源与最后核实日期
- 官方Best practices — Add an adversarial review step / Run multiple Claude sessions——fresh context 原理、review prompt 三要素、过度工程警告、Writer/Reviewer 模式,抓取于 2026-08-05。
- 官方Code Review——/code-review 的目标与 --fix/--comment 参数、effort 档位、后台 subagent 运行方式、GitHub 托管版,抓取于 2026-08-05。
- 官方Create custom subagents——subagent 全新隔离上下文、看不到对话历史、code-reviewer 示例,抓取于 2026-08-05。
- 最后核实:2026-08-05 · volatility:high(绑定 /code-review 参数与 subagent 行为,会定期复核)。