规范驱动开发SDD完全解读一、什么是规范驱动开发SDD1.1 核心概念规范驱动开发Spec-Driven Development, SDD是2025年AI编程领域最热门的新方法论之一。简单来说它的核心理念是“先写规范再写代码” —— 让规范成为人类和AI的共同真理来源。想象一下以前我们开发软件时可能先在脑子里有个模糊的想法然后直接开始写代码。有了AI助手后很多人直接对AI说帮我做个登录功能结果AI生成的代码常常不符合预期需要反复修改。SDD说“别急先把你要什么写清楚”1.2 SDD的三个层次根据Martin Fowler网站上的这篇文章SDD实际上有三个不同的实现层次层次名称含义人是否碰代码Level 1Spec-First规范优先先写好规范然后用它来指导AI开发✅ 是Level 2Spec-Anchored规范锚定规范不仅用于开发还长期保留用于后续维护和演进✅ 是Level 3Spec-As-Source规范即源码规范是主要文件人只编辑规范代码完全由AI生成人永不碰代码❌ 否简单理解Level 1就像做菜前先看菜谱Level 2就像把菜谱保存下来下次还能用Level 3就像你只需要告诉AI我要吃红烧肉AI自己看菜谱、自己做二、三大SDD工具对比文章详细介绍了三个主流的SDD工具我们来一一了解2.1 KiroAWS出品定位最轻量级的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 EDIT1:1映射一个规范对应一个代码文件还在实验阶段适用场景探索未来AI编程的可能性三、SDD vs 传统开发方法要理解SDD我们需要了解它的前辈们3.1 发展脉络图┌─────────────────────────────────────────────────────────────────────┐ │ 软件开发方法演进 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 传统开发 ───────→ TDD ───────→ BDD ───────→ MDD ───────→ SDD │ │ (随意编码) (测试优先) (行为描述) (模型驱动) (规范驱动) │ │ │ │ 1990s 2000s 2003 2000s 2025 │ │ │ └─────────────────────────────────────────────────────────────────────┘3.2 TDD测试驱动开发核心理念先写测试再写代码# TDD 示例先写测试deftest_user_login():userUser(testemail.com,password123)resultlogin_service.login(user)assertTrue(result.isSuccess())# 断言登录成功# 然后写实现代码deflogin(user):# 实现登录逻辑pass特点开发人员驱动用编程语言写测试关注代码单元的正确性技术人员专属3.3 BDD行为驱动开发核心理念用自然语言描述系统行为# BDD 示例用 Gherkin 语法 场景: 用户成功登录 Given 用户在登录页面 And 用户输入了有效的用户名test1和密码Hello123 When 用户点击登录按钮 Then 用户成功跳转到首页 场景: 密码错误 Given 用户在登录页面 And 用户输入了错误的密码 When 用户点击登录按钮 Then 显示错误消息特点产品、开发、测试共同参与用自然语言写场景关注用户行为所有人都能看懂BDD vs TDD 对比维度TDDBDD关注点代码功能实现用户行为参与者开发人员产品、开发、测试可读性编程语言技术人员专属自然语言所有人能懂范围单个代码单元端到端场景抽象层次低高3.4 MDD模型驱动开发核心理念用模型UML等描述系统自动生成代码┌─────────────────────────────────────────────┐ │ MDD 流程 │ ├─────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 概念模型 │ ──→ │ 设计模型 │ │ │ │ (业务需求)│ │ (UML图) │ │ │ └──────────┘ └────┬─────┘ │ │ │ │ │ ↓ │ │ ┌──────────┐ │ │ │ 代码生成 │ │ │ │ (自动) │ │ │ └────┬─────┘ │ │ │ │ │ ↓ │ │ ┌──────────┐ │ │ │ 可运行代码 │ │ │ └──────────┘ │ │ │ └─────────────────────────────────────────────┘特点用UML等图形化模型模型是核心资产自动生成代码需要专门的建模工具历史上未能在业务应用中大获成功3.5 SDD规范驱动开发核心理念用自然语言规范描述需求AI生成代码┌─────────────────────────────────────────────┐ │ SDD 流程 │ ├─────────────────────────────────────────────┤ │ │ │ ┌──────────────────────────────────────┐ │ │ │ 自然语言规范Markdown │ │ │ │ - 用户故事 │ │ │ │ - 验收标准 │ │ │ │ - 技术设计 │ │ │ └──────────────────┬───────────────────┘ │ │ │ │ │ │ AI 理解并生成 │ │ ↓ │ │ ┌──────────────────────────────────────┐ │ │ │ AI 生成代码 │ │ │ │ - 实现代码 │ │ │ │ - 测试代码 │ │ │ │ - 文档 │ │ │ └──────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────┘SDD vs MDD维度MDDSDD规范形式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探索未来 → Tessl6.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 TesslKiro官网kiro.devGitHub Spec-Kitgithub.com/github/spec-kitTessl文档docs.tessl.io