Review 指南

代码评审：/spec:code-review · $spec-code-review · 契约见 spec-code-review

文档/计划评审：/spec:doc-review · $spec-doc-review · 契约见 spec-doc-review

当前 spec-first 将 review 拆成代码评审和文档/计划评审两个入口。不要再把 review 理解为单一通用 workflow。

入口选择

场景	Claude Code	Codex
评审代码 diff、实现质量、测试、安全、性能	/spec:code-review	$spec-code-review
评审需求、计划、任务包、文档一致性和可执行性	/spec:doc-review	$spec-doc-review
移动 App 运行时验证前的 PRD / Figma / source 静态一致性审查	/spec:app-consistency-audit	$spec-app-consistency-audit

执行逻辑图

用户选择 review 入口
  |
  +-- 代码 diff
  |     |
  |     v
  |   spec-code-review
  |     |
  |     v
  |   收集 diff、计划、测试结果、graph/standards 证据
  |     |
  |     v
  |   correctness / testing / security / maintainability 等视角出 findings
  |
  +-- 文档、需求、计划、任务包
  |     |
  |     v
  |   spec-doc-review
  |     |
  |     v
  |   检查目标、边界、traceability、可执行性和过期事实
  |
  +-- 移动 App 静态一致性
        |
        v
      spec-app-consistency-audit
        |
        v
      比对 PRD / Figma / source / route / architecture / analytics / i18n
  |
  v
输出 findings、verdict、剩余风险
  |
  +-- 有阻断问题 -> 回到 work / plan 修正
  +-- 经验可复用 -> 进入 compound

Code review 适合什么

使用 code review 时，应提供当前请求、相关计划或任务包、diff、目标文件和测试结果。它关注：

• intent vs implementation 是否一致
• 是否引入 correctness、security、reliability、performance 问题
• 测试是否覆盖关键行为和边界
• 是否违反项目约定或 host/runtime 边界

Doc review 适合什么

使用 doc review 时，应提供需求文档、计划、任务包或设计文档。它关注：

• 目标和范围是否自洽
• requirement traceability 是否完整
• 执行单元是否可验证、可排序、可交接
• 是否混入未核验事实、过期入口或不稳定承诺

Review 的输入纪律

• 明确评审对象：代码、计划、需求、任务包或文档。
• 附上当前事实来源：文件路径、命令输出、测试结果或上游版本。
• 不把 Claude Code 与 Codex 入口混写；按实际宿主使用 /spec:* 或 $spec-*。
• 对 dirty/unreleased 上游状态要降级为限制说明，不要写成稳定公开事实。

与 compound 的关系

Review 给出 findings 和 verdict；compound 负责把已经验证、未来可复用的经验沉淀下来。不要把每条 review comment 都变成永久知识，只沉淀真实、可复用、不会快速过期的经验。

App audit 的位置

App 一致性审查是专项 review input，不是普通 code review 的替代品。它适合在移动 App 改动进入模拟器、真机、打包或 QA 前运行，用本地 PRD、Figma context、source、route、architecture、analytics 和 i18n evidence 提前暴露跨来源不一致。最终合并判断仍要结合真实测试和运行时验证。