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

一、定义/必要性

1.1 问题

vibe coding写代码，效果往往不如人意，本质上就是会遇到两个核心问题：

• 需求是否清晰
• 质量是否达标

那我们具体就可以通过TDD/SDD去分别解决。

1.2 概念

两者都属于软件开发的范式，TDD 2002年就早已提出，SDD是25年因为AI进入大众视野。

TDD，测试驱动开发（Test-Driven Development）

核心是先写测试，再写实现，而不是事后补测试——因为事后补的测试天然偏向绿，不能反映真实bug。

流程是红 → 绿 → 重构，循环地推进：

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

本质上是通过测试做质量的担保，驱动整个开发流程。

SDD，规格驱动开发（Specification-Driven Development）

核心是先把需求变成明确的规格，再按规格开发。规格不是一句简单的需求，而是把业务规则、边界约束、异常处理、模块的交互都写清楚。

流程是需求 → 规格 → 执行 → 测试 → 评审：

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

注意它和 TDD 的差别在推进顺序：SDD 允许先把功能写完，再补测试验证；TDD 必须测试先行。

如果发现规则遗漏或需求变化，就更新规格，同步调整测试和代码。

---

二、Superpowers

Superpowers 是 GitHub 上 30 万 Star 的开源项目。

本质上是一套整合了SDD、TDD等优秀开发范式与其他工作技能（skill）的开发工作流。每个环节都是1个skill。

2.1 整体架构

整条链是 6 个节点，中间四个（②③④⑤）就是通用的 SDD + TDD 工作流，一头一尾是它自己的入口和收尾。

它也是循环的，回退点有两个：

• ⑤ 审查不通过 → 回炉重做。Critical / Important 必须修：内联路线用 TDD 修一轮（写复现测试 → 看它红 → 改到绿 → 跑全量）；子代理路线派 agent 修完再派 agent 复审，每个任务最多 5 轮，第 5 轮还不过就熔断，逐条裁决，不再自动重试。
• ⑥ 测试失败 → 停在原地。worktree 和分支都不回滚，你要么用 systematic-debugging 找根因，要么发现是计划错了回去改计划。

这就是它和 SDD 同构的地方：评审发现问题不是"记一笔继续走"，而是要回到上游同步调整。

2.2 逐节点拆解

① using-superpowers —— 入口闸门

只做路由。路由规则：任何回应之前，包括问澄清问题之前，只要有 1% 可能相关，就必须先调用对应技能。

比如当你说"我们来做个什么东西"，它就把你导向 brainstorming。

② brainstorming —— 需求分析

对应 SDD 的规格阶段，入参——需求文档 prod.md，出参——规格文档 spec.md。开放式提问问真实需求，按复杂度分流成三档：

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

只有需要书面设计的项目才会走到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 **三级出结论。Critical 立即修，Important 修完再继续，Minor 记账。

Critical → 会导致数据错误、安全问题、核心功能不可用 Important → 影响正确性或可维护性，但不致命 Minor → 命名、风格、小的优化建议

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

跑项目历史全量测试，测试失败就停。

通过后，由人来选：本地合并、推 PR、还是保留分支。最后清理工作区。