SDD + TDD：AI 时代的开发范式

Vibe Coding 为什么不灵：

把想法丢给 AI，让它生成代码，看着差不多就收下------这种被称作 Vibe Coding 的写法，实际效果往往不如人意；问题不在模型不够聪明，而在开发过程缺了两个最基本的保障：

需求是否清晰：你说的是 "做一个好用的登录页"，还是 "未登录访问设置页要跳转登录，登录成功后回跳，凭证过期返回 401"？前者只能靠模型猜；
质量是否达标：代码能跑起来不代表没有 bug，由谁来判定 "达标"？

这两个问题恰好各有一个对应的成熟解法：需求不清，用 SDD 把需求变成明确的规格；质量没底，用 TDD 给质量做担保；两者都是软件开发范式，TDD（测试驱动开发）早在 2002 年就已提出，SDD（规格驱动开发）则是 2025 年随着 AI 编程兴起才进入大众视野

TDD：先写测试，再写实现

TDD（Test-Driven Development，测试驱动开发）的核心只有一句话：先写测试，再写实现，而不是事后补测试

为什么顺序不能反？因为事后补的测试天然偏向 "绿"：实现已经摆在那里，写测试的人------尤其是照着实现写测试的 AI------会不自觉把测试写成对现状的复述，跑起来当然全绿，但这样的测试反映不出真实 bug；先写测试、在实现存在之前看着它失败，才能证明测试真的在检验行为，而不是在给实现背书

TDD 的推进方式是一个循环，通常叫 "红 → 绿 → 重构"：

写测试用例 → 运行确认失败（红）→ 写最小实现 → 运行确认通过（绿）→ 重构 → 下一个行为

一轮循环的含义是：

写一个针对新行为的测试用例，运行并确认它失败------失败是好事，它证明测试有效、行为确实还没实现，这一步是 "红"；
写最小的实现让测试通过，这一步是 "绿"；
在测试全绿的保护下重构代码，然后带着下一个行为进入下一轮

本质上，TDD 是把 "质量达标" 从一句空话变成可机械验证的事实：每一分行为都有测试背书，是测试在驱动整个开发流程

SDD：先把需求变成规格

TDD 管住了质量，但它管不了另一个问题：如果需求本身是模糊的，测试按什么标准写？SDD（Specification-Driven Development，规格驱动开发）解决的就是这一层

它的核心是先把需求变成明确的规格，再按规格开发；这里的规格不是一句需求，而是一份把业务规则、边界约束、异常处理、模块之间的交互方式都写清楚的文档；流程是 "需求 → 规格 → 执行 → 测试 → 评审"：

需求文档（模糊的一句话）→ 生成初版规格 → 编码实现 → 对照规格补测试 → 评审验收

一句话需求进来，先扩展成初版规格；按规格实现功能；再对照规格补测试，验证实现是否符合规格；最后评审验收；如果评审发现规则有遗漏，或者需求发生了变化，就更新规格，并同步调整测试和代码------规格是整个流程的单一事实来源

SDD 与 TDD 的关键差别在推进顺序：TDD 必须测试先行，每个行为先有失败的测试，再有实现；SDD 允许先把功能写完，再补测试验证；一个把测试放在前面驱动开发，一个把规格放在前面约束开发；在 AI 编程里两者常常配合使用：规格约束 AI 生成什么，测试验证 AI 生成得对不对

Superpowers：把范式落成一条工作流

范式听起来都对，真正的问题是落地：在 AI 编程工具里，怎么按这套流程走下来？Superpowers 是 GitHub 上 30 万 Star 的开源项目，本质上是一套整合了 SDD、TDD 等开发范式和其他工作技能（skill）的开发工作流，每个环节封装成一个 skill，按流程串联：

整体架构：六个节点，两个回退点

整条链有 6 个节点，其中中间四个（②③④⑤）就是通用的 SDD + TDD 工作流------需求分析、写计划、执行、审查；一头一尾是 Superpowers 自己的入口和收尾

它不是一条直线，而是带循环的流程，回退点有两个：

⑤ 审查不通过，回炉重做：Critical / Important 级别的问题必须修------内联执行路线用 TDD 修一轮，写复现测试、看它红、改到绿、跑全量；子代理路线派 agent 修完，再派 agent 复审，每个任务最多 5 轮，第 5 轮还不过就熔断，转为逐条裁决，不再自动重试
⑥ 测试失败，停在原地：worktree 和分支都不回滚，你要么用 systematic-debugging 技能找根因，要么确认是计划本身错了，回到上游改计划

这两个回退点正是它与 SDD 精神同构的地方：评审发现问题不是 "记一笔继续走"，而是要回到上游同步调整------发现问题就修规格、修计划、修代码，直到三者重新一致

逐节点拆解：

① `using-superpowers`------入口闸门

只做路由；路由规则相当激进：任何回应之前------包括问澄清问题之前------只要有 1% 可能相关，就必须先调用对应技能；比如你说 "我们来做个什么东西"，它就把你导向 brainstorming

② `brainstorming`------需求分析

对应 SDD 的规格阶段：入参是需求文档 prod.md，出参是规格文档 spec.md；它通过开放式提问弄清真实需求，并按复杂度把任务分流成三档：

快速明确的任务：请求本身就是需求，直接做，不落文档；
小改动：在对话里说清楚，走常规流程；
需要书面设计的项目：先写一份 design 文档，再进入 writing-plans

只有第三档会走到写计划环节------不是所有事都值得写规格；规格文档统一产出到 docs/superpowers/specs/ 目录下

③ `writing-plans`------写计划

把规格变成具体的执行计划：入参 spec.md，出参 plan.md，计划文档产出到 docs/superpowers/plans/；写完计划后，它会把执行方式的选择权交给人

④ 执行计划------开发者选执行方式

这一步有两条路线，成本、速度、效果各有取舍：

内联执行（executing-plans）：当前会话自己一个任务一个任务地做；成本低、速度快，但效果差一些------只在最后做一次整体审查；这条路线强制加载 TDD
子代理执行（subagent-driven-development）：每个任务派一个全新的 agent 去做，做完再派另一个 agent 审查，然后进入下一个任务；成本高、速度慢，但效果好------每个任务都有独立审查，上下文不会互相污染；这条路线只在开发者要求时才使用 TDD

⑤ code review------代码审查

无论走哪条路线，最后都必须做一次全分支终审：派一个全新的 agent、用最强的模型，审查整个分支的 diff，按三级出结论：

Critical：会导致数据错误、安全问题、核心功能不可用，必须立即修；
Important：影响正确性或可维护性，但不致命，修完再继续；
Minor：命名、风格、小的优化建议，记账不阻塞

⑥ `finishing-a-development-branch`------交付

跑项目历史上的全部测试，测试失败就停；通过之后由人来选：本地合并、推 PR，还是保留分支；最后清理工作区

回到开篇的问题：

Vibe Coding 之所以不灵，是因为它同时放任了需求不清与质量无凭两个风险；SDD 用规格关住前者------业务规则、边界、异常、交互先写清楚，变了就回写规格；TDD 用先行测试把后者变成机械事实------红、绿、重构循环推进，每分行为都有测试背书；Superpowers 则把两者串成一条可执行的流水线：需求分析产出规格，规格变成计划，计划按内联或子代理方式执行，全程有分级审查和明确回退点，最后以全量测试收口；让 AI 写代码从碰运气变成可控流程，靠的不是更强的模型，而是这两层老老实实的工程约束