主题
SDD & SPEC 规范驱动开发 · 学习路线
一句话：SDD（Specification-Driven Development）不是另一种写代码的姿势，而是把「做什么、什么算做完」提前写成可验收的契约，让 AI 从「猜你要什么」变成「按你写的做」；代码是实现产物，规范才是源头。
本目录共 7 篇。路线按「先理解为什么，再选工具，最后进生产」组织。
这个知识库解决什么问题
AI 编码工具越来越多，但工具本身不决定代码质量，输入质量才决定。一句话需求会让模型用自己的默认值填空：方案、边界、异常处理都靠猜。结果不是「AI 不会写」，而是「写完才发现不是你要的」。
这套内容建立一套跨工具的 SDD 方法：规范怎么写、工具怎么选、在现有 AI 工具里怎么接、生产里怎么防止规范腐烂。工具会换，方法可以迁移。
学习路径
L1：建立心智模型（1–2 天）
目标：理解 Vibe Coding 的适用边界，以及 SDD 解决的具体问题。
| 序号 | 文章 | 核心问题 |
|---|---|---|
| 1 | 01-从Vibe-Coding到SDD | 为什么一句话需求不够？SDD 换来了什么、代价是什么？ |
| 2 | 02-SPEC规范编写实战指南 | 一份能约束 AI 的 SPEC 长什么样？验收标准怎么写？ |
完成标志：能说清 SDD 的收益和代价；能写出一份包含目标、范围、约束、可执行验收的 SPEC。
L2：工具与工作流（2–3 天）
目标：理解主流 SDD 工具的差异，知道在现有 AI 工具里怎么接，不把自定义配置误当成内置能力。
| 序号 | 文章 | 核心问题 |
|---|---|---|
| 3 | 03-Superpowers深度使用指南 | 流程 Skill 怎么组织？哪些是官方能力，哪些是社区实践？ |
| 4 | 04-SDD工具链横向对比 | Kiro / Spec Kit / OpenSpec / Superpowers 各在哪一层？怎么选？ |
| 5 | 05-SDD在各AI工具中的落地实践 | Claude Code / Cursor / Copilot / Windsurf / Aider / Cline 分别怎么接？ |
完成标志：能在一个现有工具里跑通「先规范、后实现」的最小流程；能区分工具内置、可配置扩展和团队约定。
L3：深入与生产（2–3 天）
目标：理解 OpenSpec 与 Spec Kit 的机制差异，掌握让规范长期存活的做法。
| 序号 | 文章 | 核心问题 |
|---|---|---|
| 6 | 06-OpenSpec与Spec-Kit深入解析 | 增量规范怎么工作？Spec Kit 的命令链怎么走？ |
| 7 | 07-SDD生产踩坑与最佳实践 | 规范为什么会腐烂？六个坑怎么处置？ |
完成标志：能为团队设计一套最小可运行的 SDD 流程，并说明它的维护成本和退出条件。
文件组织
text
27_SDD与SPEC规范驱动开发/
├── 00-SDD-SPEC学习路线.md ← 你在这里
├── 01-从Vibe-Coding到SDD.md ← L1
├── 02-SPEC规范编写实战指南.md ← L1
├── 03-Superpowers深度使用指南.md ← L2
├── 04-SDD工具链横向对比.md ← L2
├── 05-SDD在各AI工具中的落地实践.md ← L2
├── 06-OpenSpec与Spec-Kit深入解析.md ← L3
└── 07-SDD生产踩坑与最佳实践.md ← L3建议节奏
text
Week 1:
Day 1-2: L1（心智模型 + 写一份 SPEC）
Day 3-5: L2（选一个工具，跑最小流程）
Week 2:
Day 1-3: L3（机制深入 + 生产检查）
Day 4: 给自己当前项目补一份 SPEC
Day 5: 复盘：哪些验收标准真的执行了，哪些只是文档建议按顺序读。不理解「为什么需要规范」就去看工具对比，容易变成比功能清单；不写一份自己的 SPEC 就看生产踩坑，容易把别人的处置当成模板照抄。
初稿 2026-07 | 最后修订 2026-10 | 篇数订正为 7（原 08 已并入 02/07）