在计算机编码和软件开发领域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 追问澄清后沉淀为结构化 SpecPlan方案架构、技术栈、实现方式AI 读 Spec 输出Tasks拆解原子化任务清单AI 按 Plan 拆分Implement实现代码 自动生成的测试AI 严格按 Spec/Plan/Tasks 生成需求变更时只改 Spec再由 AI 基于新 Spec 重新生成代码和测试全程可追溯。为什么在计算机编码语境下谈 SDDSDD 的走热与大模型编码能力的爆发直接相关。在 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。