SDD 实战教程：规范驱动开发之道

系统学习稿 —— 从"凭感觉写代码（Vibe Coding）"转向"先定义清楚再执行（Specification-Driven Development）"

本教程整合自《SDD实战：规范驱动开发之道》（黄佳/咖哥，人民邮电出版社 2026-6）+ OpenSpec/Superpowers 等一线的可落地实践与模板，供系统学习与上手。

目标读者：被 AI 编程"第一天快、第一周返工、第一个月自我怀疑"折磨过的工程师；想让 AI 产出有据可查、可审查、可维护的协作者。

为什么需要 SDD：Vibe Coding 的五个陷阱
SDD 是什么：三个范式迁移与两次创造
SDD 五大核心原则
SDD 六阶段工作流总览
规范文档的载体选择
实战模板：proposal / design / tasks
落地工具链：OpenSpec + Superpowers 六步实战
SDD × Agent 设计模式
团队落地路径
常见坑与应对
何时不要用 SDD（边界与误区）
学习路径建议
你可能已经在用 SDD 了（你的工作流地图）

1. 为什么需要 SDD：Vibe Coding 的五个陷阱

Warning：你正处在从"尝试"迈向"工程化"的转折点。

AI 编程的速度曲线，往往是——

第一天飙升 → 第一周返工 → 第一个月自我怀疑

一句话点破：核心问题不是 AI 能力不足，而是你的指令不够完整。

1.1 数据陷阱的五个致命问题

SDD 要解决的，是 Vibe Coding（凭感觉写代码） 的五个陷阱：

#	陷阱	描述	后果
1	需求蒸发	你跟 AI 说"加个灰度发布"，它自由发挥，新增了一个 `GrayService`，而项目里用了三年的 `GrayReleaseUtil` 它不知道	知识藏在人脑里，不在 README/注释/prompt 里，AI 写不对
2	上下文漂移	每一轮对话，AI 都在丢掉上一轮约束。"不要改公共组件"到第八轮已被当空气	产出的代码与最初需求只剩字面相似
3	不可审查	AI 一次性吐几百行代码，无思考过程/取舍说明/备选方案	reviewer 审"结果"但"过程"已丢失，无从切入
4	不可复现	今天能跑，明天报错；同一 prompt 产出 A / 产出 B	bug 出现时，还原不了现场（生成代码那次对话已不存在）
5	不可维护	三个月后新人接手，面对无规范来源的代码，无 ADR、无架构决策记录	只能推倒重来

五个陷阱合起来，不是 AI 的错，是方法轮缺了「规范」这一环。

记住这本书的注脚："从 Vibe Coding 到 SDD，不是从一种工具切换到另一种工具，而是从『先试试看』转向『先定义清楚再执行』。"

一句话记住：AI 写不对，很多时候不是它不行，是你没把话说清楚——规范就是那份"说清楚"的书面版。

2. SDD 是什么：三个范式迁移与两次创造

2.1 软件开发方法论的三个范式迁移

时代	模式	特点
1970	瀑布模型	有规范、无迭代
2001	敏捷开发	有迭代、轻规范
2025	SDD（规范驱动开发）	有迭代、有规范

而 2025 年的 Vibe Coding（无迭代、无规范） 只是一个过渡现象。

2.2 SDD 的底层哲学：以终为始，两次创造

源自 Stephen Covey《高效能人士的七个习惯》的 "以终为始（Begin with the End in Mind），所有事物都经过两次创造"：

第一次创造（心智的创造）：在脑子里把房子想清楚 —— 用规范文档。
第二次创造（物质的创造）：按图纸把房子盖起来 —— 用代码。

文档	角色	创造类型
`proposal.md`	需求规范：要做什么、为什么做、做到什么程度	心智创造（一）
`design.md`	架构规范：用什么方案、为什么选它、有什么权衡	心智创造（二）
`tasks.md`	任务规范：拆成几步、每步交付什么、怎么验收	心智创造（三）
`Code`	实际代码	物质创造

"三份规范构成第一次创造，代码是第二次创造。"

2.3 SDD 区别于旧方法论的根本升级

时代差异——在 AI 时代，规范不只是给人看的参考材料，更是给 Agent 执行的输入。

规范文档从「可选的说明」变成「必要的工程接口」。

SDD 不是反对 AI 编程，而是给 AI 编程配上一副工程化的骨架。

一句话记住：三次创造——先用脑子想清楚写进规范，再写代码。规范是图纸，代码是房子。

3. SDD 五大核心原则

无论用什么工具，SDD 的骨架都是这五条原则：

规范先行 —— 先写规范，再动代码。规范是第一次创造，代码是第二次创造。
规范即文档 —— 规范本身就是最权威的文档，不需要另外维护一套文档。
规范可执行 —— 规范能由 Agent 读取、解析并转化为行为（机器可读）。
规范可版本控制 —— 规范进 git，可追溯、可 diff、可回滚。
代码服务规范 —— 编码的实现要以规范为唯一目标，代码不偏离规范。

4. SDD 六阶段工作流总览

SDD 的工作流分为 6 个阶段：

需求定义 → 架构设计 → 接口契约 → 任务拆解 → 代码生成 → 验证交付 (proposal) (design) (api-spec) (tasks) (code) (verify)

阶段	产物	核心问题	角色
1. 需求定义	`proposal.md`	要做什么、为什么、做到什么程度	心智创造
2. 架构设计	`design.md`	用什么方案、为什么、有什么权衡（ADR）	心智创造
3. 接口契约	`api-spec.yaml` / `data-models.md`	定义了哪些 API、数据模型	心智创造
4. 任务拆解	`tasks.md`	拆成几步、每步交付什么、怎么验收	心智创造
5. 代码生成	Code	Agent 按规范生成实现	物质创造
6. 验证交付	测试 + 验收	是否满足规范、可交付	物质创造

好书的实战（第 4-7 章）用一个完整项目（如"智能日报生成器"）从需求到验证，手把手走完这 6 个阶段。

一句话记住：六阶段就是"想清楚 → 设计好 → 拆细 → 照着做 → 验收到"的一条流水线，前面四步是给 AI 的地图，后面两步是验收。

5. 规范文档的载体选择

不是所有规范都用一种格式。选择合适的载体，让"规范可执行"真正落地：

规范类型	载体	原因
需求、架构、任务拆解	Markdown（`.md`）	人类可读、Agent 可读、git 友好
API 接口契约	YAML（`.yaml`）	结构化、可被工具校验/生成代码
需要严格机器验证的数据模型	JSON Schema	可机器验证、可生成校验器

原则：能给机器读的，就不要只给人看。 这是 SDD 从"文档"升级为"工程接口"的关键。

6. 实战模板：proposal / design / tasks

这套模板可以直接复制进你的项目（结合 OpenSpec 或手写都行）。

6.1 模板总目录

openspec/ ├── schemas/tdd-driven-v2/ │ ├── schema.yaml # 定义规则（每个 artifact 的生成指令） │ └── templates/ │ ├── proposal.md # 变更提案 │ ├── spec.md # 行为规格 │ ├── design.md # 技术设计 │ ├── tasks.md # 原子化任务 │ └── plan.md # 执行计划 ├── config.yaml # 项目上下文（技术栈/测试命令等） ├── changes/ └── specs/

6.2 proposal.md（需求规范：要做什么、为什么）

```markdown

Proposal

Problem

Testable Behaviors

Acceptance Criteria

```

关键：用 WHEN/THEN 列出可测试行为，只描述"期望发生什么"，不要描述实现细节。

6.3 spec.md（行为规格：GIVEN/WHEN/THEN 场景）

```markdown

Spec

Scenarios

Scenario 1: [name]

GIVEN: [前置条件]
WHEN: [操作]
THEN: [期望结果]
```

6.4 design.md（技术设计：怎么实现 + 测试策略）

```markdown

Design

File Structure

Test Strategy

```

设计必须包含精确的文件路径和测试策略，它是 Agent 实现时的"地图"。

6.5 tasks.md（原子化任务：拆成单步可验收）

```markdown

Tasks

Atomic TDD Task List

[Feature name]

[ ] RED: 编写失败测试 —— [测试什么行为]
[ ] GREEN: 最小实现 —— [实现描述，引用对应的 RED 任务]
[ ] REFACTOR: 重构清理 —— [清理描述]（可选）
```

核心纪律：每个任务只能是且仅是一个 TDD 阶段（RED / GREEN / REFACTOR），严禁合并。这是原子化约束——它物理上限制了 AI 的操作空间，防止一步写完整个功能（导致 TDD 形同虚设）。

6.6 实际写的时候，最容易卡住的三个地方

模板是死的，写的时候才是见真章。这三个坑几乎人人都会踩：

坑一：proposal 的 WHEN/THEN，写着写着就变成"实现细节"了。

WHEN/THEN 的本意是只描述行为，不描述怎么做。比如：

```markdown

❌ 这样写就偏了（混进了实现）

WHEN addTodo() 被调用 THEN 往数据库 table 里 insert 一条记录

✅ 这样才是行为（只讲"会发生什么"）

WHEN 用户添加一条待办 THEN 待办列表里出现这条待办，且状态为"未完成"
```

判断标准很简单：删掉这句话，如果实现方式换了（换数据库、换存储、换接口）这句话仍然成立——那就是行为；如果换实现它就不成立了，说明你写的是实现细节。WHEN/THEN 只描述"对外的可观察结果"，永远不说"内部怎么实现"。

坑二：design.md 的文件路径不写全，AI 就会乱建文件。

design.md 是 Agent 实现时的"地图"。如果只写"一个 service 层、一个 API 层"，Agent 会自由发挥，文件名、目录、甚至测试文件的路径都不确定。必须写到精确：

```markdown

File Structure

src/todo/service.ts # 业务逻辑
src/todo/service.test.ts # 单测
src/api/todo.routes.ts # 路由
tests/integration/todo.int.test.ts # 集成测试
```

为什么特别强调测试文件也列出来？因为 SDD 的验证靠测试，测试文件是验收的入口。列全路径，Agent 才不会"顺手"把测试文件建在别处，让你验收时找不到。

坑三：tasks.md 的 RED/GREEN 合并了，TDD 就白写了。

这是最关键的一条。一个常见写法是：

```markdown

❌ 合并了（AI 会一口气写完整个功能）

[ ] RED+GREEN: 写失败的测试，然后实现它

✅ 严格分开

[ ] RED: 写失败的测试 —— 验证 addTodo 能加一条"未完成"的待办
[ ] GREEN: 最小实现 —— 让上面那个 RED 测试通过
```

为什么严禁合并？因为一旦合并，AI 就会"先写测试再写实现，一步到位"，RED 阶段的约束就形同虚设——它可能写完测试后直接写个能过的实现，根本没经历"先看到失败"的过程。RED 的意义在于让 AI 亲眼看到测试是失败的，才允许它开始写代码。 这一步是 SDD 的"刹车片"，不可省。

7. 落地工具链：OpenSpec + Superpowers 六步实战

这是被真实项目验证过的可直接操作的工作流（V3，Todo API 项目实测 12 个 task、13/13 测试通过、95.38% 覆盖率）。

7.1 为什么这两件工具互补

维度	OpenSpec	Superpowers
管理对象	知识资产（specs、design、tasks）	代理行为（TDD、审查、子代理）
核心优势	Spec 驱动 + 变更追溯 + 知识积累	子代理隔离 + TDD 强制 + 自动审查
核心短板	无 TDD 强制、无子代理、无 git 集成	平台依赖强、token 开销大、无 spec 管理

一句话：一个管「写什么」（OpenSpec），一个管「怎么做」（Superpowers），桥梁是 schema.yaml 里的 instruction 文本。

7.2 六步流程

Step1 初始化项目 → Step2 创建 TDD Schema → Step3 /opsx:propose → 人工审查(必做) → Step4 /opsx:apply → Step5 人工验收(必做) → Step6 /opsx:archive

Step 1：初始化项目

bash mkdir my-project && cd my-project git init && npm init -y npm install --save-dev jest ts-jest @types/jest typescript npm pkg set scripts.test="jest" openspec init --tools claude

openspec init 不会创建 schemas/ 和 config.yaml，这俩要手动建（下一步）。

Step 2：创建 TDD Schema（一次性配置，可复用）

bash mkdir -p openspec/schemas/tdd-driven-v2/templates

手工写 3 个文件：schema.yaml（规则+instruction）、config.yaml（项目上下文）、5 个模板（见 §6）。

schema.yaml 的核心是给每个 artifact 写 instruction 文本——这是给 Agent 的"生成指令"，决定了它输出规范的质量。示例（tasks 的 instruction）：

yaml - id: tasks generates: tasks.md template: tasks.md instruction: | 将工作拆分为原子化 TDD 任务。每个任务必须是且仅是一个 TDD 阶段（RED / GREEN / REFACTOR）。使用 checkbox 格式：RED: 编写失败测试 / GREEN: 最小实现 / REFACTOR: 重构清理（可选）。规则：1.禁止合并 RED+GREEN；2.每个 GREEN 必须引用对应 RED；3.严格交替；4.每任务 2-5 分钟可完成。 requires: [specs, design]

config.yaml 的 context 写得越详细，propose 阶段全自动率越高（核心函数签名、输入输出类型、已有工具函数列表）。

Step 3：/opsx:propose —— 生成规格

markdown /opsx:propose 给 Todo API 加上任务优先级功能

AI 自动生成 5 个 artifact（proposal/specs/design/tasks/plan）。

propose 后必须人工审查（ROI 最高的 5 分钟）：
- proposal.md：WHEN/THEN 行为列表完整？缺边界情况？
- design.md：文件路径 + 测试策略合理？
- tasks.md（最关键）：每个 - [ ] 是否只有一个 TDD 阶段？RED/GREEN 是否严格交替？若出现"RED+GREEN: 写测试并实现"这种合并任务，手动拆开再继续。

Step 4：/opsx:apply —— 执行实现

markdown /opsx:apply add-todo-priority

AI 自动：逐个 dispatch subagent 执行每个 TDD task → 每个完成后两阶段审查（Spec 合规 → 代码质量）→ 勾选 checkbox → 下一个。

⚠️ apply 是长时间运行（实测约 1 小时+）。中途不要中断（中断可能部分 task 已完成但 tasks.md 未更新）。建议先用 inline 模式跑简单需求，或用 subagent 模式跑工程化需求。

Step 5：人工验收（不可省，兜底）

bash npm test && npx jest --coverage

验收清单：测试全过？tasks.md 所有 checkbox 已勾选？覆盖率 ≥ proposal 的行为数？文件结构与 design.md 一致（或偏离可接受）？无 TODO/桩代码？

apply 阶段不做 git 提交 —— 验收后手动提交：
bash git add -A && git commit -m "feat: implement <change-name> via SDD TDD workflow"

Step 6：/opsx:archive —— 归档

markdown /opsx:archive add-todo-priority

把 changes/<change-name>/ 移到 changes/archive/YYYY-MM-DD-<change-name>/。归档后直接 /opsx:propose 即可开启下一个 change，Schema 自动复用。

7.3 跑这套流程，最容易翻车的三个地方

六步看着顺，实际跑起来有三次特别容易翻车——提前知道，能省大半天。

翻车点一：/opsx:apply 是长时间运行，中途千万别断。
apply 是逐个 dispatch subagent 执行每个 TDD 任务，一个真实需求下来往往要 1 小时以上（Todo API 那种 12 个 task 的量级，实测跑了一个多小时）。中途一旦中断，麻烦的不是丢进度，而是"部分 task 做完了、tasks.md 却没更新"——你回来看，工作区里有一半实现了，但勾选状态对不上，很难判断到底完成了多少。

对策：开始 apply 前先想清楚"这需求简单还是复杂"。简单的用 inline 模式（快、准、省 token），工程化的才用 subagent 模式（慢但每个子任务有隔离上下文）。别一上来就 subagent，也别在 apply 中途去动别的。

翻车点二：propose 之后的人工审查，是 ROI 最高的五分钟，千万别跳过。
AI 生成的 5 个 artifact 里，tasks.md 最容易出问题——经常出现"RED+GREEN 合并任务"，或者 RED/GREEN 顺序错乱。你不审查，AI 就照着这份有问题的 tasks.md 去执行了，TDD 又从根上垮了。

对策：propose 后花 5 分钟，只抓 tasks.md 看一件事——每个 - [ ] 是不是只有一个 TDD 阶段？RED 和 GREEN 是不是严格交替？ 看到合并的就手动拆开，再让 apply 继续。这五分钟是整套流程里回报最高的一次投入。

翻车点三：apply 不帮你做 git 提交，验收后得自己 commit。
apply 的过程是"执行任务 + 勾选 checkbox"，不会自动 git commit。如果你忘了这茬，验收完直接关掉会话，这半天的成果就没进版本控制——下次一 clean，全没了。

对策：记住这个顺序——验收通过 → 手动 git add -A && git commit → 再归档。SDD 的原则本来就是"规范进 git、代码也进 git"，这一步不能省。

8. SDD × Agent 设计模式

这是《SDD实战》最亮眼的一章（第 8 章），把 SDD 与 5 种 Agent 设计模式深度融合——每种模式对应一份规范模板。用 5 种模式组合构建 SDD 半自动化流水线（黄佳《Designing AI Agents》里的心法落地）：

Step1 人类编写规范（proposal+design+tasks） ← 规划与执行模式（Plan） Step2 路由器分析请求判断属于哪个模块 ← 条件路由模式 Step3 Manager Agent 读 tasks.md 拆解分配任务 ← 层级委托模式 Step4 Worker Agents 各自生成代码+自我审查 ← 规划执行 + 生成-评审模式 Step5 Hooks 自动护栏（输入检查+输出检查） ← 护栏三明治模式 Step6 全量回归测试（pytest tests/ -v） ← 质量门 Step7 人类审查+合入（最终决策始终在人） ← 收尾

人类参与 Step1+Step7，AI 自动化 Step2-Step6 —— 最终决策始终在人。

5 种模式速览：

模式	核心	用途
规划与执行（Planner-Worker）	一个规划，多个执行者	任务拆解与分配
生成-评审（Generator-Critic）	生成 + 评审循环	自我审查、质量把关
层级委托（Hierarchical Delegation）	管理层级分解	大任务分治
护栏三明治（Guardrail Sandwich）	前输入+后输出检查	防止不规范输入/输出
条件路由（Conditional Routing）	按条件分发到不同模块	复杂请求分流

8.1 一个贯穿案例：给"每日销售播报"走一遍 SDD + Agent 模式

光看模式太抽象，拿你一个最常见的场景——"给我做个每日销售播报"——把前面所有东西串一遍。你会看到 SDD 和 5 种 Agent 模式是怎么一层层叠上去的。

Step 0 · 人先写规范（这就是你已经在做的 PRD + 方案）
- proposal.md：要做一个能每天自动汇总销售数据、生成播报、推送到群的工具。WHEN/THEN 写清楚："WHEN 每天下午 6 点触发 THEN 生成昨日全店销售汇总并入群"。
- design.md：数据从哪抓（ERP 接口）、存哪（SQLite）、播报格式长啥样、推送走什么通道——每一条都写清文件路径和测试策略。
- tasks.md：拆成原子化 TDD 任务（RED: 写测试验证能拉到昨日数据 → GREEN: 实现拉数 → ...）。

Step 1-2 · 路由器 + 层级委托（AI 开始接手）
- 一个 Manager Agent 读 tasks.md，把任务分给不同的 Worker Agent：一个负责数据采集，一个负责播报渲染，一个负责推送。
- 这就是层级委托——每个人只管自己那摊，上下文不互相污染。

Step 3 · 生成-评审（自我把关）
- Worker 写完一段代码，另一个 Agent 角色来评审——检查命名、边界、可测试性。
- 这就是生成-评审：生成和评审是两个独立角色，同进程用不同 system prompt 扮演。

Step 4 · 护栏三明治（兜住意外）
- 前置护栏：数据采集前校验输入（比如"昨天没数据怎么办"）。
- 后置护栏：推送前校验输出（比如"播报格式里有敏感数字"）。
- 这就是护栏三明治——输入输出两端都挡一下，AI 不会把脏数据发出去。

Step 5 · 全量回归（质量门）
- pytest tests/ -v 全量跑一遍，之前通过的功能不许被这次的改动弄挂。

Step 6 · 人看一眼，合入
- 最终决策在人——你看一眼播报格式对不对、数字准不准，点头才合入。

你看，这个"每日销售播报"从头到尾，就是把人写的规范 + AI 的分工、自查、护栏合起来。 人负责定义和决策（Step 0 和 Step 6），AI 负责中间的执行和迭代（Step 1-5）。这不是遥控 AI，是给 AI 配好骨架，让它按你的标准干活。

9. 团队落地路径

SDD 不是一天推完的。分三阶段渐进落地：

阶段	对象	做法
个人	独立开发者	给个人项目建立可传承的工程档案，AI 不再是黑盒打工，而是有据可查的协作者
团队	小团队 Leader	落地规范模板 + 工具链选型，把团队从"谁写谁懂"的口口相传拉出来
组织	企业架构师	第 8 章 SDD × Agent 设计模式 × Harness Engineering，形成未来 AI 系统施工图

Brownfield（既有/老项目）最难也最关键（第 7 章）：不要推倒重来，而是渐进式引入——先从一个小模块开始试点 SDD。

10. 常见坑与应对

真实项目实测发现的坑（V2/V3 教训），帮你提前避开：

#	坑	应对
1	任务粒度不对（RED+GREEN 合并）	tasks.md 必须原子化，每个 task 只做一个 TDD 阶段
2	两套系统互不引用（OpenSpec 的 tasks 和 Superpowers 的 plan 各自为战）	用 schema.yaml 的 instruction 把两者绑起来
3	审查审的不是 OpenSpec specs（审的是自己的 plan）	审查必须对齐 OpenSpec 产出的 specs
4	部分 task 跳过审查	apply 后对照 session 日志确认每个 task 都有审查报告，跳过的手动补审
5	测试覆盖率不足	对照 proposal 的 WHEN/THEN 逐个检查缺的测试
6	AI 自行调整文件结构	判断偏离是否合理（合并文件且功能正确可接受）
7	apply 不做 git 提交	验收后手动 `git add -A && git commit`
8	执行时间与复杂度不成比例	简单需求用 inline 模式，关键 task 才启用审查
9	接口/类型定义不一致（跨文件各自定义 type）	重点检查跨文件是否引用同一 interface/type

11. 何时不要用 SDD（边界与误区）

一本成熟的工程书会诚实告诉你"什么时候不要用 SDD"：

✅ 适合：纯函数库、工具函数、REST API（CRUD）、CLI 工具、数据转换/处理逻辑
⚠️ 谨慎：前端 UI 组件（行为难以用 WHEN/THEN 表达）、依赖外部服务（DB/第三方 API/文件系统）、时间紧迫的原型开发

SDD 不是银弹，也不取代其它方法论。它能：
- 与敏捷共存（SDD 提供规范，敏捷提供迭代节奏）
- 与DevOps协作（规范进 git，CI/CD 自动跑验证）
- 与 TDD 融合（spec 驱动 + TDD 强制循环，是天然搭档）

不要盲用 SDD 的场景：需求不可明确描述、系统过于简单（不值得规范成本）、单人多变快速原型、依赖 AI 边探索边定义的探索性工作。

12. 学习路径建议

按这个顺序系统学，从理解到上手最快：

第 0 步 · 建立心智（2h）
- 读懂 Vibe Coding 的五个陷阱（§1），理解"规范是工程接口而非文档归档"（§2.3）
- 记住"两次创造"：先心智创造（规范）再物质创造（代码）

第 1 步 · 最小闭环（半天）
- 挑一个纯函数/工具函数的小项目（最简单的 SDD 场景）
- 手工写 proposal/design/tasks 三件套（§6），走一遍"先定义清楚再执行"

第 2 步 · 上工具（1-2 天）
- 装 OpenSpec + Superpowers，配 schema.yaml（§7 Step2）
- 拿一个 REST API / CRUD 项目完整跑一遍 propose→apply→验收→archive（§7）

第 3 步 · 融入 Agent 模式（进阶）
- 把 5 种 Agent 设计模式组合成半自动化工流水线（§8）
- 团队层面渐进落地（§9），老项目从一个小模块试点

第 4 步 · 沉淀为习惯
- 每次需求：先 proposal → design → tasks → 再写代码
- 规范进 git、可追溯、可版本控制（§3）

13. 你可能已经在用 SDD 了（你的工作流地图）

读到这儿，如果你心里想的是"这规范驱动的规矩，听起来挺唬人"——那我先帮你松口气：你大概率已经在用 SDD 了，只是没这么叫它。

拿咱们自己做的事来对一下就明白了：

SDD 的那一套	你已经在用的东西	对应关系
`proposal.md`（要做什么、为什么）	你的 PRD（写产品需求：三视角诊断 → 概念版 → 范围冻结 → 落地版）	就是需求规范，一模一样
`design.md`（用什么方案、有什么权衡）	让 AI 帮你出的技术方案 / 架构决策（含取舍说明、ADR）	就是设计规范
`tasks.md`（拆成几步、怎么验收）	dfc Kanban 拆的任务卡（从 PRD 的 P0 功能派生出任务 + 验收标准）	就是任务规范
六阶段里的"验证交付"	你的 test-driven-development（先写失败测试再写代码）	就是验收那个环节

你看，SDD 不是外星人，就是你已经在做的那套流程的"系统化命名"。 你现在是人驱动地做这三件事——你凭感觉判断"这个需求够清楚了吗"、"方案够细了吗"、"任务拆得够原子化吗"。

SDD 多出来的那一层，是把这三样东西从"给你自己看的备忘"升级成"给 AI 执行的工程接口"：

你的 PRD 现在是人读的（写得好不好，你自己回头看才知道）
SDD 的规范是机器读的（写成 WHEN/THEN、GIVEN/WHEN/THEN、精确文件路径、原子化 TDD 任务——AI 读一遍就能照着执行）

一句话记住：你不是从没有规范要"学"规范，你是把你已经写的那份 PRD，改写成 AI 也能照着做的版本——这一步，就是 SDD。

结语

"从 Vibe Coding 到 SDD，不是从一种工具切换到另一种工具，而是从『先试试看』转向『先定义清楚再执行』。"

AI 编程已进入工程深水区。写得快的人正在被写得清楚的人甩开。SDD 给你的，不是一套工具，而是把"一时想清楚就够了"的决策，刻进仓库里的能力——让今天的每一次 change，都成为下一次 change 的起点。

这，就是 AI 时代真正不可替代的核心竞争力。

参考来源（外部资料，非逐字转录）：
- 豆瓣书评《SDD实战》读书笔记 / 《AI编程深水区的五个致命陷阱》（2026-07）
- OpenSpec + Superpowers TDD 实战（术哥，腾讯云开发者社区 2026-05）
- sdd-openspec-agents-template（joosiimoo，生产级 SDD + AI Agent 模板）