在计算机编码和软件开发领域，SDD 通常指 Specification-Driven Development（规格驱动开发，也称规范驱动开发）——一种以结构化规格（Spec）为"唯一真相源"、由 AI 或代码生成器将规格转换为实现、测试和验证的软件工程方法论。
核心思想
传统开发是"先写代码，文档跟不上"；SDD 把这个关系反过来：规格成为首要产物，代码只是规格在特定语言和框架下的可再生的具象表达。
Microsoft Learn 对 SDD 的定义很直白：在传统开发中代码是真相源，规格服务于代码；SDD 反转了这一关系，让规格成为主要工件（primary artifact），代码服务于规格。维护软件意味着演进规格，而不只是打补丁。
三个核心原则
- 规格即真相源（Single Source of Truth）：规格是中心真相源，代码只是它在特定语言和框架下的表达。
- 可执行规格：规格必须精确、完整、无歧义到足以生成可工作的系统，从而消除意图与实现之间的落差。
- 活文档：调试 = 修正生成错误代码的规格；重构 = 重组规格以提升清晰度。规格与实现始终保持同步。
Azure 的文档补充了一个关键视角：在 SDD 中，规格是一份机器可强制执行的契约，介于"解决方案构建者"“AI 编码助手”"治理团队"之间——需求变了，更新规格，受影响的代码通过 AI 辅助系统地重新生成，无需手动干预成千上万个代码仓库。
标准工作流
SDD 通常是一个四阶段的闭环（以 GitHub Spec Kit 为代表）：
| 阶段 | 产出 | 谁来做 |
|---|---|---|
| Specify定规格 | 用户故事、验收标准、需求与边界案例 | 人给意图，AI 追问澄清后沉淀为结构化 Spec |
| Plan方案 | 架构、技术栈、实现方式 | AI 读 Spec 输出 |
| Tasks拆解 | 原子化任务清单 | AI 按 Plan 拆分 |
| Implement实现 | 代码 + 自动生成的测试 | AI 严格按 Spec/Plan/Tasks 生成 |
需求变更时，只改 Spec，再由 AI 基于新 Spec 重新生成代码和测试，全程可追溯。
为什么在"计算机编码"语境下谈 SDD
SDD 的走热与大模型编码能力的爆发直接相关。在 Copilot、Cursor、Claude Code 等 AI 编码助手普及后，团队遇到几个痛点：
- 上下文漂移：聊着聊着 AI 开始"瞎编"
- 实现不一致：同一功能反复生成，风格和边界条件都不一样
- 不可追溯：代码改了一堆，没人说得清"当时为什么这么改"
SDD 本质上是用结构化的 Spec 给 AI 划跑道——AI 在跑道里可以充分发挥，但不会飞出去。这也是为什么 GitHub 要通过开源 Spec Kit 把 SDD 推成一套完整的、面向 AI 辅助编程的工程方法论。
💡 顺带一提：SDD 在其他语境下可能有别的展开（比如 Software Design Document 软件设计文档、Serial Data Driver 等），但在计算机编码 / AI 编程这个语境里，它稳定地指向Specification-Driven Development。
