我先联网检索「02-SDD」到底指什么，确认其所属领域和定义。
我精读阿里云开发者社区原文与腾讯云实践文章，确认 SDD 的定义、工作流和与 Vibe Coding 的区别。
在这组技术系列文章里，"02-" 是章节编号（第二篇），"SDD" 是本篇要讲的核心概念，全称 Spec-Driven Development，规范驱动开发（也译规格驱动开发）。它是一种在 AI 编程时代流行起来的工程化开发方法：先把 "系统应该做什么、不能做什么、边界条件是什么" 写成结构化、可验证的规范（Spec），并把规范作为唯一真源（Single Source of Truth），代码则是从规范派生出来的产物 —— 先定义 WHAT（做什么），再让 AI 或团队决定 HOW（怎么做）。典型流程是 Specify（写需求规范）→ Plan/Design（技术设计）→ Task（任务拆解）→ Implement & Verify（实现与验证）。它主要解决纯 Vibe Coding 下需求跑偏、上下文丢失、架构漂移、代码不可审查等问题；但 SDD 并不适合所有场景，小改动、一次性脚本和探索期原型直接开发即可，规范投入产出比并不划算。
一、先分清：这里的 SDD 指什么
| 项目 | 说明 |
|---|---|
| 本篇 SDD | Spec-Driven Development，规范 / 规格驱动开发，面向 AI 辅助编程的工程方法 |
| "02-" 含义 | 系列文章第二篇的章节编号，不是技术术语本身 |
| 核心产物 | 分层规范文件（宪法 / 行为 / 方案 / 任务），而非某段代码或某个工具 |
| 适用背景 | AI 编程助手、AI Agent 大量生成代码后，需要把意图和约束固化下来 |
补充：SDD 在其他领域也可能是 SEPA Direct Debit（欧洲直接借记）、Software Design Description（软件设计文档）等缩写；本文按原标题上下文，只讲 AI 编程语境下的规范驱动开发，不与其他含义混用。
二、三句话读懂 SDD
- 规范是唯一真源，代码是规范的产物。 需要改系统时，先改规范，再由规范驱动代码变更；代码可以重写，规范不能丢。
- 规范必须先于代码存在，且以可验证的形式存在。 "可验证" 是关键，这也是 SDD 与 "事后补一份设计文档" 的本质区别。
- 规范是人与机器共读的。 给人看用于评审和交接，给 AI 看作为每次生成代码的输入约束；所以规范要结构化、短句、可编号、可追溯。
三、SDD 要解决什么问题
纯靠对话让 AI 写代码，项目上线一段时间后容易出现以下失败模式：
- 上下文丢失：清空对话或跨会话后，AI 忘记数据库结构、编码规范等约定。
- 需求漂移：多轮迭代后实现偏离最初意图，没人说得清从哪里开始偏的。
- 反复重来：小改动引发大范围返工，甚至从零重新生成。
- 架构漂移：AI 自行加入缓存层等 "看似合理" 的设计，几轮后假设嵌入数据模型，难以移除。
- 不可审查：几百行未经文档化的 AI 生成代码，评审者看不出设计意图。
- 多文件崩溃：改动涉及多个文件时，上下文窗口挤掉前面的约束条件。
根源往往不是模型不够聪明，而是从来没有一份写下来、版本化保存的规范。
四、典型 SDD 工作流
| 阶段 | 做什么 | 产出物 |
|---|---|---|
| Specify（写需求） | 写清做什么、为什么做：需求、用户故事、验收标准，先不谈实现 | 行为规范、验收标准 |
| Plan/Design（技术设计） | 把规范转成技术设计：架构、数据模型、接口、约束、迁移与回滚方案 | 技术方案文档 |
| Task（任务拆解） | 按顺序拆成可执行、可验证的任务清单 | 任务清单 |
| Implement & Verify（实现与验证） | AI 按任务清单实现，人审查聚焦的变更，而非整段代码转储 | 代码、测试、评审记录 |
评审重点随之前移：团队先评审 Spec 和 Plan，而不是等代码生成完再去读 "一坨 AI 输出"。
五、规范的四个层次
落地成败的关键，是不要把所有内容塞进一个文件。
| 层次 | 典型文件 | 回答的问题 | 长度上限 | 变更频率 | 批准人 |
|---|---|---|---|---|---|
| L0 宪法 | constitution.md | 团队做技术决定的底线是什么 | 1 页 | 半年 | 技术负责人 |
| L1 行为规范 | spec.md / requirements.md | 系统应表现出什么行为（做什么、不做什么） | 2-4 页 | 每个需求 | 产品 + 技术 |
| L2 技术方案 | plan.md / design.md | 用什么结构、技术、迁移和回滚方式实现 | 2-3 页 | 每个需求 | 技术负责人 |
| L3 任务清单 | tasks.md | 按什么顺序、由谁、以什么验证标准完成 | 1-2 页 | 每个需求 | 开发自管 |
纪律只有一条：上一层不写下一层的内容。行为规范里出现 "用 Redis 做原子扣减" 就是越界，那属于 L2 技术方案；技术方案一变，行为规范不该跟着作废。
六、让需求可验证：EARS 句式
EARS（Easy Approach to Requirements Syntax）是一套受限需求句式，用来逼作者把触发条件、状态和异常分支写清楚，让规范既能被人评审，也能被 AI 读取。
| 类型 | 句式 | 示例 |
|---|---|---|
| 通用 | 系统应…… | 系统应为每次库存变更记录一条不可修改的流水。 |
| 事件驱动 | 当〔触发〕时，系统应…… | 当用户点击 "领取" 且库存大于 0 时，系统应创建一张 "未使用" 状态的券并返回券码。 |
| 状态驱动 | 当处于〔状态〕时，系统应…… | 当券处于 "已锁定" 状态时，系统应拒绝除核销与解锁外的所有状态变更。 |
| 非期望 | 如果〔异常条件〕，则系统应…… | 如果用户已达每人限领上限，则系统应拒绝领取、返回错误码，且不扣减库存。 |
| 可选特性 | 当启用〔配置〕时，系统应…… | 当启用 "仅限新用户" 配置时，系统应仅允许注册 7 天内且无已支付订单的用户领取。 |
写作三条要求：一句一条（不用 "并且"" 同时 " 连接两个行为）、给编号（如 FR-001，编号永不复用）、禁形容词（快速、友好、合理、尽量等，换成数字或明确条件）。
七、与瀑布、敏捷、TDD/BDD 的区别
| 方法论 | 核心 / 权威产物 | 谁读 | 与代码的关系 | 主要失效点 |
|---|---|---|---|---|
| 瀑布 | 需求规格说明书（SRS） | 人 | 文档完成后基本脱离，代码另行演进 | 文档与代码脱钩，改代码不改文档 |
| 敏捷 / Scrum | 用户故事 + 验收标准 | 人 | 故事卡在迭代结束后废弃 | 粒度太粗，边界条件 "实现时再说" |
| TDD / BDD | 测试用例 / 业务语言行为描述 | 人 + 机器 | 测试即规范，只覆盖已想到的路径 | 要求先想清设计，不描述 "为什么" |
| SDD | 分层规范（行为 + 架构 + 边界 + 约束） | 人 + AI | 规范驱动生成，变更回写规范 | 规范腐败、流程过重 |
一句话概括：TDD 用测试锁住行为，SDD 用规范产生行为；测试回答 "它现在对不对"，规范回答 "它应该是什么、为什么"。
八、什么场景该用、什么场景不必用
| 改动特征 | 判断 | 处理方式 |
|---|---|---|
| 改文案、调样式、一行修复、改配置 | 不需要 SDD | 直接改，不写规范 |
| 单文件、单函数、逻辑清晰、可 1 小时回滚 | 不需要 SDD | 直接改，PR 描述写清意图 |
| 跨 2-3 个文件、有分支和边界条件 | 轻量规范 | 只写 L1 验收标准（5-10 条），方案用口头 + PR 描述 |
| 跨模块、涉及数据模型变更、有并发或状态机 | 完整 SDD | L0-L3 全走，含分析门禁 |
| 多人并行、需要交接、有合规或审计要求 | 完整 SDD + 归档 | 全流程 + 变更提案 + 归档留痕 |
| 探索期原型、一次性脚本、技术验证 | 不需要 SDD | 标注为一次性产物，禁止进主干 |
建议的强制线：涉及数据库结构变更、跨服务调用、资金或库存计算、权限判定的需求，一律走完整 SDD，这四类返工成本最高，规范投入产出比最好。
九、主流 SDD 工具参考
| 工具 | 形态 | 最擅长 | 主要短板 |
|---|---|---|---|
| GitHub Spec Kit | CLI + 斜杠命令，可接入多种 AI 助手 | 新项目、需要正式评审的产品需求 | 流程偏重，小改动承担不起 |
| Amazon Kiro | 独立 IDE（基于 Code OSS） | 单人深度开发、IDE 内闭环 | 绑定自家 IDE，团队统一成本高 |
| OpenSpec | CLI + 斜杠命令，强增量规范与归档 | 存量系统、频繁小步变更 | 对新项目引导较弱 |
| 纯 Markdown 自建 | 无工具，全靠约定 | 任何场景兜底 | 无自动化，依赖自觉 |
十、适用边界与常见误区
- 适合：10 人以上团队、有集成点的复杂系统、需要追溯的监管行业（金融、医疗等）、多人并行与跨仓库协作。
- 不适合：独立开发者、简单 CRUD、周末项目、需求频繁变动的小项目；此时写规范的时间可能超过直接写代码。
- 常见误区：把所有规范塞进一个文件；上层规范越界写技术实现；规范写完就不再回写维护；用形容词代替可验证条件。
- 业界有 "用 vibe 去探索，用 spec 去建造"（Use the vibes to explore. Use specifications to build.）的说法：探索阶段可以自由尝试，进入建造阶段再用规范约束。
整体来看，SDD 的本质是把 AI 时代最稀缺的能力 —— 准确表达意图、固化约束和可追溯变更 —— 从对话记录搬到版本化的规范文件里。它不是要替代编程能力，而是给 AI 生成代码套上一层工程纪律：先对齐规范，再生成代码，最后按规范验证，从而让团队协作、审查和长期维护变得可控。
【相关 FAQ】
问题 1：02-SDD 里的 SDD 到底是什么意思？
回答 1：在本篇上下文中，SDD 全称 Spec-Driven Development，中文叫规范驱动开发（也译规格驱动开发）；"02-" 只是系列文章的章节编号。SDD 把规范作为唯一真源，代码由规范派生，先写清做什么和约束条件，再让 AI 或团队完成实现。
问题 2：SDD 规范驱动开发的典型工作流分哪几个阶段？
回答 1：典型 SDD 工作流分为 Specify（写需求规范）、Plan/Design（技术设计）、Task（任务拆解）、Implement & Verify（实现与验证）四个阶段。规范先于代码存在，团队先评审规范和方案，再由 AI 按任务清单生成代码并验证。
问题 3：SDD 规范驱动开发和 TDD、BDD 有什么区别？
回答 1：区别在于权威产物不同：TDD 的权威产物是测试用例，主张先写测试；BDD 用业务语言描述行为；SDD 的权威产物是完整规范，包含行为、架构、边界情况和约束，先写规范再让 Agent 产出代码、测试和文档。一句话说，TDD 用测试锁住行为，SDD 用规范产生行为。
问题 4：SDD 规范驱动开发一般把规范分成哪几个层次？
回答 1：SDD 通常把规范分为四层：L0 宪法（技术决定底线）、L1 行为规范（系统应表现的行为）、L2 技术方案（结构、技术、迁移回滚）、L3 任务清单（顺序、负责人、验证标准）。纪律是上一层不写下一层的内容，避免技术方案一变行为规范就作废。
问题 5：哪些场景适合用 SDD，哪些场景不必用规范驱动开发？
回答 1：跨模块、涉及数据模型变更、并发或状态机、多人并行、有合规审计要求的项目适合走完整 SDD；涉及数据库结构变更、跨服务调用、资金库存计算、权限判定的需求建议强制走完整 SDD。改文案、调样式、一行修复、单文件小改动、一次性脚本和探索期原型则不必使用 SDD，直接开发即可。
【参考资料】
- [2026-11-13]（02-SDD 到底是什么）阿里云开发者社区
- [2026-07-28]（Vibe Coding 在企业中的落地实践）腾讯云开发者社区
- [2026-05-29]（Vibe Coding 从自然语言到工程化实践：面向竞赛团队的 AI 编程新范式介绍）上海图书馆（上海科学技术情报研究所）
- [2026-05-09]（5 人 7 天干完 20 人数周的活：Spec-Driven Development 如何重新定义 AI 编程）腾讯网
【免责声明】
本文内容基于公开技术文章与社区资料整理，仅用于 SDD（Spec-Driven Development，规范驱动开发）概念的科普与方法梳理，不构成具体项目的开发流程咨询或工具选型承诺。文中流程分层、EARS 句式、工具对比和案例数据来自不同团队与公开报道，适用效果因项目规模、团队成熟度和场景差异而不同；落地时请结合自身工程规范与实际情况评估。文中提及的第三方工具名称归各自所有者所有，如信息存在更新或版权问题，请联系更正。