Review 详细指南

本页默认用 Claude Code /spec:review 说明；如果你使用 Codex，请改为 $spec-review。

Review 是 Spec-First 主工作流中的质量关口，用来把“已经完成的实现”转成 结构化发现、分级风险与后续动作。

输入与输出

输入：代码变更，可选 plan: 参数
输出：结构化 review report

如果你在 Review 时附带计划文档，当前实现会额外做需求对照，帮助判断“做出来的是否还是计划中的内容”。

启动方式

Claude Code：

bash

/spec:review
/spec:review mode:report-only
/spec:review mode:autofix
/spec:review plan:docs/plans/2026-04-20-001-feat-example-plan.md

Codex：

bash

$spec-review
$spec-review mode:report-only
$spec-review mode:autofix
$spec-review plan:docs/plans/2026-04-20-001-feat-example-plan.md

当前应该如何理解 Review 的 agent 体系

官网旧文档曾把 Review 写成“26 个评审代理并行”，这已经不是当前最稳妥的官方表述。

基于当前 README，Review 的对外表述应改成：

使用一套结构化 reviewer persona 体系
当前 README 强调 17 个 reviewer personas + 2 个 CE agents
实际调度会按变更范围、风险域和文件类型选择 agent 子集

也就是说：

不是每次都把全部 57 个 agent 一起跑
也不应继续把旧的 26 代理数字当成当前统一口径

典型执行流程

计算变更范围
识别意图与可选的 plan: 对照
选择评审人组合
并行执行评审
合并、去重、分级
输出结构化报告

这一流程的重点不是“多开几个 agent”，而是让发现有统一结构和后续处理路径。

常见模式

`mode:report-only`

严格只读
不修改文件
适合先拿风险画像

`mode:autofix`

尝试自动处理明确可修复的问题
不代表“高风险改动也适合无脑自动修”
对关键链路仍建议人工审阅结果

为什么建议带上 `plan:`

如果你已经有计划文档，带上它能让 Review 不只是“看代码像不像有问题”，还可以进一步判断：

是否偏离计划边界
是否遗漏计划中的验证项
是否新增了不在计划中的变更面

结果应该如何消费

Review 结束后，最实用的消费方式通常是：

先处理高严重度问题
再看是否要进入 mode:autofix
修复后重新 Review
通过后再进入 Compound

不该再承诺的旧口径

“Review 就是 26 个代理一起审”
“所有代理固定不变、固定并行”
“只需要看代码风格建议”

当前实现更强调：

结构化 findings
需求对照
风险分级
后续动作路由

Review 详细指南 ​

输入与输出 ​

启动方式 ​

当前应该如何理解 Review 的 agent 体系 ​

典型执行流程 ​

常见模式 ​

mode:report-only ​

mode:autofix ​

为什么建议带上 plan: ​

结果应该如何消费 ​

不该再承诺的旧口径 ​

下一步 ​