规范驱动开发（SDD）完全解读
一、什么是规范驱动开发（SDD）？
1.1 核心概念
规范驱动开发（Spec-Driven Development, SDD） 是2025年AI编程领域最热门的新方法论之一。简单来说，它的核心理念是：
"先写规范，再写代码" ------ 让规范成为人类和AI的共同真理来源。
想象一下，以前我们开发软件时，可能先在脑子里有个模糊的想法，然后直接开始写代码。有了AI助手后，很多人直接对AI说"帮我做个登录功能"，结果AI生成的代码常常不符合预期，需要反复修改。
SDD说："别急，先把你要什么写清楚！"
1.2 SDD的三个层次
根据Martin Fowler网站上的这篇文章，SDD实际上有三个不同的实现层次：
| 层次 | 名称 | 含义 | 人是否碰代码 |
|---|---|---|---|
| Level 1 | Spec-First（规范优先） | 先写好规范，然后用它来指导AI开发 | ✅ 是 |
| Level 2 | Spec-Anchored（规范锚定） | 规范不仅用于开发，还长期保留，用于后续维护和演进 | ✅ 是 |
| Level 3 | Spec-As-Source（规范即源码） | 规范是主要文件，人只编辑规范，代码完全由AI生成，人永不碰代码 | ❌ 否 |
简单理解：
- Level 1 就像做菜前先看菜谱
- Level 2 就像把菜谱保存下来，下次还能用
- Level 3 就像你只需要告诉AI"我要吃红烧肉"，AI自己看菜谱、自己做
二、三大SDD工具对比
文章详细介绍了三个主流的SDD工具，我们来一一了解：
2.1 Kiro（AWS出品）
定位： 最轻量级的SDD工具
工作流程： 需求 → 设计 → 任务
┌─────────────────────────────────────────────────────────────┐
│ Kiro 工作流程 │
├─────────────────────────────────────────────────────────────┤
│ Step 1: requirements.md（需求文档） │
│ ├─ 用户故事（As a... I want... So that...） │
│ └─ 验收标准（Given... When... Then...） │
│ ↓ │
│ Step 2: design.md（设计文档） │
│ ├─ 技术架构 │
│ ├─ 数据模型 │
│ └─ 接口定义 │
│ ↓ │
│ Step 3: tasks.md（任务文档） │
│ └─ 具体的开发任务清单 │
└─────────────────────────────────────────────────────────────┘特点：
- 基于VS Code，使用Claude Sonnet 4.5
- 适合单个任务或用户故事
- 三个Markdown文档清晰明了
- 有"Steering（方向盘）"概念（记忆库）：product.md、structure.md、tech.md
适用场景： 小到中型功能开发
2.2 GitHub Spec-Kit
定位： 最可定制的SDD工具
工作流程： 宪法 → 规范 → 计划 → 任务（循环）
┌─────────────────────────────────────────────────────────────┐
│ Spec-Kit 工作流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ │
│ │ Constitution │（宪法 - 最高原则） │
│ │ 不变的核心规则 │ │
│ └──────┬───────┘ │
│ ↓ │
│ ╔═══════════════════════════════════════╗ │
│ ║ 循环：Specify → Plan → Tasks ║ │
│ ╚═══════════════════════════════════════╝ │
│ ↓ │
│ ┌──────────────┐ │
│ │ Specify │（规范阶段） │
│ │ 详细需求规范 │ │
│ └──────┬───────┘ │
│ ↓ │
│ ┌──────────────┐ │
│ │ Plan │（计划阶段） │
│ │ 技术实现方案 │ │
│ └──────┬───────┘ │
│ ↓ │
│ ┌──────────────┐ │
│ │ Tasks │（任务阶段） │
│ │ 具体开发任务 │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘特点：
- 命令行工具（CLI），兼容多种AI助手
- 大量使用清单（Checklist）跟踪进度
- "宪法"概念：包含不可变的高层原则
- 每个规范创建一个分支
- 非常详细但也很繁琐
适用场景： 大型项目、需要严格规范的企业环境
2.3 Tessl Framework
定位： 最激进的SDD工具（仍在内测）
核心思想： 规范即源码
┌─────────────────────────────────────────────────────────────┐
│ Tessl 工作流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 人类只编辑这个 ↓ │
│ ┌─────────────────┐ │
│ │ .tessl 规范文件 │ │
│ │ （自然语言描述） │ │
│ └────────┬────────┘ │
│ │ │
│ │ AI 生成 │
│ ↓ │
│ ┌─────────────────┐ │
│ │ 代码文件.js │ │
│ │ // GENERATED │ │
│ │ // DO NOT EDIT │ ← 人类不碰这个！ │
│ └─────────────────┘ │
│ │
│ 当需求变更时： │
│ 修改 .tessl 文件 → AI 重新生成代码 │
│ │
└─────────────────────────────────────────────────────────────┘特点：
- CLI + MCP服务器
- 唯一明确追求Spec-Anchored和Spec-As-Source的工具
- 代码文件顶部标注"GENERATED FROM SPEC - DO NOT EDIT"
- 1:1映射：一个规范对应一个代码文件
- 还在实验阶段
适用场景： 探索未来AI编程的可能性
三、SDD vs 传统开发方法
要理解SDD，我们需要了解它的"前辈们"：
3.1 发展脉络图
┌─────────────────────────────────────────────────────────────────────┐
│ 软件开发方法演进 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 传统开发 ───────→ TDD ───────→ BDD ───────→ MDD ───────→ SDD │
│ (随意编码) (测试优先) (行为描述) (模型驱动) (规范驱动) │
│ │
│ 1990s 2000s 2003 2000s 2025 │
│ │
└─────────────────────────────────────────────────────────────────────┘3.2 TDD（测试驱动开发）
核心理念： 先写测试，再写代码
python
# TDD 示例：先写测试
def test_user_login():
user = User("test@email.com", "password123")
result = login_service.login(user)
assertTrue(result.isSuccess()) # 断言登录成功
# 然后写实现代码
def login(user):
# 实现登录逻辑
pass特点：
- 开发人员驱动
- 用编程语言写测试
- 关注代码单元的正确性
- 技术人员专属
3.3 BDD（行为驱动开发）
核心理念： 用自然语言描述系统行为
gherkin
# BDD 示例：用 Gherkin 语法
场景: 用户成功登录
Given 用户在登录页面
And 用户输入了有效的用户名"test1"和密码"Hello123"
When 用户点击登录按钮
Then 用户成功跳转到首页
场景: 密码错误
Given 用户在登录页面
And 用户输入了错误的密码
When 用户点击登录按钮
Then 显示错误消息特点：
- 产品、开发、测试共同参与
- 用自然语言写场景
- 关注用户行为
- 所有人都能看懂
BDD vs TDD 对比：
| 维度 | TDD | BDD |
|---|---|---|
| 关注点 | 代码功能实现 | 用户行为 |
| 参与者 | 开发人员 | 产品、开发、测试 |
| 可读性 | 编程语言，技术人员专属 | 自然语言，所有人能懂 |
| 范围 | 单个代码单元 | 端到端场景 |
| 抽象层次 | 低 | 高 |
3.4 MDD（模型驱动开发）
核心理念： 用模型（UML等）描述系统，自动生成代码
┌─────────────────────────────────────────────┐
│ MDD 流程 │
├─────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 概念模型 │ ──→ │ 设计模型 │ │
│ │ (业务需求)│ │ (UML图) │ │
│ └──────────┘ └────┬─────┘ │
│ │ │
│ ↓ │
│ ┌──────────┐ │
│ │ 代码生成 │ │
│ │ (自动) │ │
│ └────┬─────┘ │
│ │ │
│ ↓ │
│ ┌──────────┐ │
│ │ 可运行代码 │ │
│ └──────────┘ │
│ │
└─────────────────────────────────────────────┘特点：
- 用UML等图形化模型
- 模型是核心资产
- 自动生成代码
- 需要专门的建模工具
- 历史上未能在业务应用中大获成功
3.5 SDD（规范驱动开发）
核心理念： 用自然语言规范描述需求，AI生成代码
┌─────────────────────────────────────────────┐
│ SDD 流程 │
├─────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────┐ │
│ │ 自然语言规范（Markdown） │ │
│ │ - 用户故事 │ │
│ │ - 验收标准 │ │
│ │ - 技术设计 │ │
│ └──────────────────┬───────────────────┘ │
│ │ │
│ │ AI 理解并生成 │
│ ↓ │
│ ┌──────────────────────────────────────┐ │
│ │ AI 生成代码 │ │
│ │ - 实现代码 │ │
│ │ - 测试代码 │ │
│ │ - 文档 │ │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────┘SDD vs MDD：
| 维度 | MDD | SDD |
|---|---|---|
| 规范形式 | UML图、结构化DSL | 自然语言Markdown |
| 灵活性 | 低（受限于模型语言） | 高（自然语言） |
| 确定性 | 高（预定义规则） | 低（LLM非确定性） |
| 工具支持 | 专门的建模工具 | 任何文本编辑器 |
| 代码生成 | 固定模板 | AI智能生成 |
四、SDD的优势与挑战
4.1 优势
┌─────────────────────────────────────────────────────────────┐
│ SDD 的优势 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✅ 提高代码质量 │
│ 约束AI输出，减少幻觉和错误 │
│ 研究显示可减少40-60%的bug │
│ │
│ ✅ 减少返工 │
│ 需求清晰，减少"这不是我要的"的情况 │
│ │
│ ✅ 更好的协作 │
│ 规范成为团队共享的真理来源 │
│ 产品、开发、测试在同一页面 │
│ │
│ ✅ 知识沉淀 │
│ 规范成为可维护的文档 │
│ 新成员快速理解系统 │
│ │
│ ✅ 可追溯性 │
│ 从需求到代码的完整链路 │
│ 变更影响分析更容易 │
│ │
└─────────────────────────────────────────────────────────────┘4.2 挑战与问题
文章作者也提出了许多值得思考的问题：
┌─────────────────────────────────────────────────────────────┐
│ SDD 的挑战 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ⚠️ 过度设计的风险 │
│ 小bug也要写4个用户故事、16个验收标准？ │
│ 用大炮打蚊子 │
│ │
│ ⚠️ 审查负担 │
│ 要审查大量Markdown文件，比审查代码还累 │
│ 内容重复、冗长 │
│ │
│ ⚠️ AI不听话 │
│ 即使有详细规范，AI还是可能忽略或误解 │
│ 上下文窗口大了≠AI能正确利用所有信息 │
│ │
│ ⚠️ 虚假的控制感 │
│ 很多文件和清单 ≠ 真正的控制 │
│ 小步迭代才是王道 │
│ │
│ ⚠️ 功能规范 vs 技术规范 │
│ 很难清晰分离"要什么"和"怎么做" │
│ 现实中经常混淆 │
│ │
│ ⚠️ 遗留系统整合 │
│ 现有代码库如何引入SDD？ │
│ 学习曲线陡峭 │
│ │
└─────────────────────────────────────────────────────────────┘五、实际应用场景
5.1 什么时候适合用SDD？
| 场景 | 适合度 | 说明 |
|---|---|---|
| 新项目启动 | ⭐⭐⭐⭐⭐ | 从0开始，规范先行 |
| 大型功能开发 | ⭐⭐⭐⭐ | 需要多方协作，规范能统一认识 |
| 复杂业务逻辑 | ⭐⭐⭐⭐ | AI需要清晰理解业务 |
| 小bug修复 | ⭐⭐ | 可能过度设计 |
| 遗留系统维护 | ⭐⭐ | 整合困难 |
| 快速原型 | ⭐⭐ | 与"快速"理念冲突 |
5.2 不同规模问题的处理方式
┌─────────────────────────────────────────────────────────────────┐
│ 根据问题规模选择合适的方法 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 小任务（1-2小时） │
│ ├─ 直接AI对话 / "Vibe Coding" │
│ └─ 快速、灵活、不需要太多规范 │
│ │
│ 中型功能（1-3天） │
│ ├─ Kiro 的简化流程 │
│ └─ 需求 → 设计 → 任务，三步走 │
│ │
│ 大型项目（1周+） │
│ ├─ Spec-Kit 完整流程 │
│ └─ 宪法 → 规范 → 计划 → 任务 │
│ │
│ 探索性/实验性 │
│ ├─ Tessl Framework │
│ └─ 规范即源码，完全AI驱动 │
│ │
└─────────────────────────────────────────────────────────────────┘六、给开发者的建议
6.1 如何开始尝试SDD？
-
从小处开始
- 不要一上来就用在最复杂的项目上
- 先在一个小功能上试试Kiro的三步流程
-
先写规范，再写代码
- 即使是小功能，也尝试先写几行需求描述
- 你会发现思考变得更清晰
-
保持迭代
- 不要一次性写完美的规范
- 小步快跑，持续 refinement
-
选择合适工具
- 轻量级 → Kiro
- 企业级 → Spec-Kit
- 探索未来 → Tessl
6.2 关键原则
┌─────────────────────────────────────────────────────────────┐
│ SDD 黄金法则 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 规范是为了沟通，不是为了形式 │
│ 如果没人看，再漂亮的规范也没用 │
│ │
│ 2. 适合的就是最好的 │
│ 小任务简单处理，大项目严格规范 │
│ │
│ 3. AI是助手，不是替代品 │
│ 你的角色不是指挥，而是验证和精炼 │
│ │
│ 4. 保持怀疑 │
│ AI可能忽略规范，也可能过度执行 │
│ │
│ 5. 迭代优于完美 │
│ 小步迭代比一次性大设计更可靠 │
│ │
└─────────────────────────────────────────────────────────────┘七、总结
7.1 核心要点
-
SDD不是银弹 ------ 它是一种工具，适合某些场景，不适合所有场景
-
三个层次 ------ Spec-First、Spec-Anchored、Spec-As-Source，根据需求选择
-
三个工具 ------ Kiro（轻量）、Spec-Kit（企业级）、Tessl（激进实验）
-
历史传承 ------ SDD继承了TDD、BDD、MDD的思想，用AI时代的自然语言规范替代了传统的测试和模型
-
谨慎乐观 ------ 作者提醒我们注意过度设计、审查负担、AI不听话等问题
7.2 一句话总结
SDD = 用清晰的自然语言规范指导AI编程，让"要什么"和"怎么做"分离，提高代码质量和团队协作效率。
7.3 未来展望
SDD还处于早期阶段，工具和方法都在快速演进。无论你是否现在采用SDD，了解它的理念都会帮助你更好地与AI协作编程。
正如文章作者所说：
"很多文件和模板和清单，并不能保证AI会遵循所有指令。小步迭代的方法论仍然是我们保持控制的最佳方式。"
参考资源
- 原文：Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
- Kiro官网：kiro.dev
- GitHub Spec-Kit：github.com/github/spec-kit
- Tessl文档：docs.tessl.io