Spec-Driven Development (SDD)
SDD 是什么？
一种将规格说明（Specification）而非代码视为核心产物的开发方法论。 规格成为可直接生成实现的"可执行文档"，代码只是"最后一公里"的产物。
作为 AI 辅助编码工作流，SDD 遵循结构化功能规格 → 分解模块 → 生成任务的多步过程。 规格形态多样：单一文档、文档组或系列结构化工件。
主流实践包括：
- Amazon Kiro：三阶段工作流（需求 → 设计 → 任务）
- GitHub Spec Kit：三步流程 + 编排能力 + 可配置提示 + "宪法"原则
- Tessl Framework：规格取代代码成为主要维护工件（2025 年内测）
见：Understanding Spec-Driven Development
Thoughtworks 的观察？
Thoughtworks 技术雷达认为 SDD 领域值得关注，但当前工具存在明显局限：
- 工作流繁琐且主观设计倾向强
- 生成冗长规格文件，难以审阅
- PRD/用户故事的目标读者不清晰
- 规模扩展性存疑——为 AI 逐条手工制定规则难以长期维持
OpenSpec
定位？
轻量级开源 SDD 框架，由 Fission-AI 开发。强调灵活而非僵化、迭代而非瀑布。
核心命令？
| 命令 | 作用 |
|---|---|
/opsx:new | 创建变更 |
/opsx:ff | Fast-forward 自动生成规划文档 |
/opsx:apply | 执行实现 |
/opsx:archive | 归档已完成变更 |
特点？
- 5 分钟快速启动（vs Spec Kit 的 30 分钟）
- 无严格阶段门控，可随时修改任何产物
- Node.js 运行，无需 Python
- 执行更快，规格文件更简洁
Spec Kit (GitHub)
定位？
GitHub 官方推出的系统化 SDD 工具包，适合需要严格质量控制的团队。
核心命令？
| 命令 | 作用 |
|---|---|
/speckit.constitution | 创建项目基本原则 |
/speckit.specify | 定义功能规格 |
/speckit.plan | 技术实现计划 |
/speckit.tasks | 生成任务清单 |
/speckit.implement | 系统执行所有任务 |
/speckit.clarify | 结构化澄清需求 |
特点？
- 严格的阶段门控（规划前必须澄清）
- 丰富的模板系统
- Python CLI 工具
- 支持 17+ AI 工具（Claude Code、Cursor、Copilot 等）
GSD (Get Shit Done)
定位？
轻量级 meta-prompting + context engineering + SDD 系统，由 TÂCHES 创建。
核心解决的问题？
Context Rot — 随着 Claude 上下文窗口填满而产生的质量衰减。
核心命令？
| 命令 | 作用 |
|---|---|
/gsd:new-project | 初始化项目（问题 → 研究 → 需求 → 路线图） |
/gsd:discuss-phase | 捕获实现决策 |
/gsd:plan-phase | 研究 + 规划 + 验证 |
/gsd:execute-phase | 并行执行计划 |
/gsd:verify-work | 人工验收测试 |
/gsd:quick | 快速模式（跳过可选步骤） |
核心机制？
- XML 格式化提示：每个计划都是结构化 XML，优化 Claude 理解
- 多代理并行：研究、规划、执行各阶段并行子代理
- 原子 Git 提交：每个任务独立提交
- 上下文隔离：每个计划 200k tokens 纯净上下文
特点？
- 无企业仪式（无 sprint ceremonies、story points、Jira）
- 系统复杂但工作流程简单
- 支持 Claude Code、OpenCode、Gemini CLI
BMAD (Breakthrough Method for Agile AI-Driven Development)
定位？
AI 驱动的敏捷开发框架，模拟完整软件开发团队。
核心组成？
- 21 个专业 Agent：产品经理、架构师、开发工程师、UX 设计师、Scrum Master 等
- 50+ 引导式工作流：覆盖完整开发流程
特点？
- 最完整的"AI 团队"模拟
- 真正的敏捷方法论（sprints、ceremonies）
- human-in-the-loop，强调人与 AI 协作
- 适合大型、复杂项目
四者对比
| 维度 | OpenSpec | Spec Kit | GSD | BMAD |
|---|---|---|---|---|
| 定位 | 轻量 SDD 框架 | 系统 SDD 工具包 | 上下文工程系统 | AI 敏捷团队框架 |
| 复杂度 | 低 | 高 | 中 | 最高 |
| 启动成本 | 5 分钟 | 30 分钟 | 5 分钟 | 较高 |
| 团队模拟 | 无 | 无 | 无 | 21 个 Agent |
| 核心优势 | 灵活快速 | 严格质量控制 | 解决 context rot | 完整敏捷流程 |
| 最佳场景 | 个人/小团队 | 企业团队 | 复杂多阶段项目 | 大型敏捷项目 |
批判性反思
规格与代码的等价性原理
试图用自然语言规格替代代码是徒劳的——当规格精确到足以可靠生成实现时，它必然被扭曲成代码形式。这是 Dijkstra 所谓"窄接口"的必然要求。
OpenAI 的 Symphony 项目自称从规格生成，但其 SPEC.md 实则是"伪代码的 markdown 形式"：包含数据库 schema 的逐字段罗列、算法的伪代码描述、甚至直接嵌入代码块。 该规格文件已达 Elixir 实现代码量的 1/6，却仍未保证可靠生成。
数学史印证了这一点：希腊数学因停留在口头和图形而停滞，直到 Vieta、Descartes、Leibniz 等人设计的形式符号系统才突破瓶颈。"代码生成于规格"的愿景本质上是 Borges 小说中的"与帝国一样大的地图"—— 当规格详尽到与实现重合，它便失去了作为抽象工具的价值。
见：A sufficiently detailed spec is code：Gabriella Gonzalez 对 agentic coding 两个核心误区的深度剖析