第 8 章 / 共 10 章
工具横向对照
8.1 四种做法的坐标
把主流做法放到两个维度上：流程重量（有多少个必须走的阶段和产物）与追溯强度（需求和代码之间的对应关系有多严格）。
以下数据为 2026 年 9 月初的快照，命令名和版本会随工具演进变化，动手前请以当前官方文档为准。
8.2 Spec Kit：完整阶段链
GitHub 开源的工具包，当前版本 v1.0.0，约 13.4 万星标。它把整条链路做成了命令：
| 命令 | 作用 |
|---|---|
/speckit.constitution | 确立项目原则（长期约束，跨需求生效） |
/speckit.specify | 定义需求与用户故事 |
/speckit.clarify | 澄清模糊点 |
/speckit.plan | 生成技术实现计划 |
/speckit.tasks | 生成可执行任务列表 |
/speckit.implement | 执行任务 |
/speckit.analyze | 一致性检查 |
/speckit.checklist | 生成检查清单 |
/speckit.converge | 评估代码库与规格的偏离 |
它宣称支持 30 多种 AI 编码 agent，覆盖 CLI 和 IDE 两类。
适合：多人协作、需求来自外部（产品、客户）、需要留下评审痕迹的项目。 代价：阶段闸门较多，小改动走全套会明显拖慢。它的常见用法是只用其中几个命令，而不是每次都走完整条链。
特别值得单独用的是 /speckit.constitution。项目原则是跨需求的长期约束——技术栈边界、必须遵守的架构决定、不允许引入的依赖。这类内容写一次，之后每份规格都受益，性价比极高。如果你不用 Spec Kit，把它写进 CLAUDE.md 或 AGENTS.md 是等价的。
8.3 OpenSpec：变更提案流
约 6.7 万星标，自我定位是更轻、阶段闸门更少、允许自由迭代。核心是第7章讲过的三段流程与三个目录，另有 /opsx:explore 用于不做承诺的探索。
适合：需求持续演进、改动频繁、希望保留变更历史的项目。 代价：追溯是事后补的，不适合需要逐条审计的场景。
8.4 Kiro：IDE 内的三文件
AWS 的 agentic IDE，2025 年 7 月发布。工作方式是：由你的提示生成用户故事和 EARS 验收标准 → 分析代码库产出设计文档（数据流图、接口、数据库 schema、API 端点）→ 生成带依赖顺序、且每条回链到需求的任务列表，通常体现为 requirements.md、design.md、tasks.md 三份文件。它还提供事件触发的自动化钩子（文件保存、提交时自动跑文档更新或测试）。
适合：愿意换 IDE、需求偏结构化、重视规格与代码同步的团队。 代价：绑定特定 IDE 和生态，迁移成本最高。
8.5 纯 Markdown：先从一份 SPEC.md 开始
不装任何东西：一份 SPEC.md、一份 PLAN.md、一份任务清单，配合你现有 agent 的计划模式。
适合：个人项目、小团队、第一次尝试 SDD 的人。 代价：没有阶段强制，全靠自觉；追溯要手写。
8.6 选型建议
| 你的情况 | 建议起点 |
|---|---|
| 个人项目，第一次试 | 纯 Markdown，先跑通一个需求 |
| 小团队，需求经常变 | 纯 Markdown 或 OpenSpec 的三目录结构 |
| 多人协作，需要评审痕迹 | Spec Kit，先只用 constitution / specify / plan / tasks |
| 有合规或审计要求 | Spec Kit + 更强的追溯约定 |
| 愿意换 IDE 且重视同步 | Kiro |