SDD驱动AI开发：当Open Spec遇上Superpowers

“Too simple to need a design” is always wrong.
— Superpowers 工作流的第一条铁律

前言：Vibe Coding 的困境

2025年以来，”Vibe Coding”成了最火热的开发范式——对着AI说几句话，代码就出来了。Cursor、Copilot、Claude Code……工具越来越多，AI越来越聪明。

但你有没有发现一个诡异的现象：

AI写的代码越来越快，项目却越来越乱。

  • 第一天：哇，AI帮我5分钟写了个登录页面！
  • 第一周：嗯，重构一下这个组件……等等，它改了三个不相关的文件？
  • 第一个月：这个项目的代码到底是谁写的？——是你，也是AI，但现在谁也看不懂了。

问题出在哪？不是AI不够强，而是我们给AI的方式不对。

我们给AI的是模糊的自然语言指令，期待它产出精确的工程代码。这就像你对施工队说”帮我盖个好看的房子”，然后期待他们交出一份完美的建筑图纸。

SDD（Spec-Driven Development，规格驱动开发） 正是为了解决这个问题而生的。

什么是SDD？

SDD的核心思想只有一句话：

先写规格（Spec），再写代码（Code）。

这不是什么新概念。软件工程几十年来一直在讲”需求分析”、”概要设计”、”详细设计”。但在AI时代，Spec的意义发生了根本变化：

过去： Spec是给人看的文档，写完就扔，代码才是真相。
现在： Spec是给AI的指令，Spec就是真相，代码只是它的实现。

在AI辅助开发中，Spec不再是”可选的文档”，而是驱动整个开发流程的唯一输入。

SDD vs 传统开发 vs Vibe Coding

维度 传统开发 Vibe Coding SDD
输入 需求文档 + 架构设计 自然语言 Prompt 结构化 Spec
开发主体 人类程序员 AI（人类监督） AI（Spec 驱动）
质量保障 Code Review 基本没有 Spec Review + Code Review
可复现性 高（有代码） 低（Prompt模糊） 高（Spec可重放）
协作方式 人-人 人-AI Spec-AI
核心资产 代码 Prompt Spec

SDD本质上是一种人机协作的契约：人类负责思考和定义（写Spec），AI负责执行和实现（写代码）。

Open Spec：让Spec成为一等公民

“Open Spec”不是一个具体的产品或工具，而是一种开放的规格定义方法论。它的核心主张是：

1. Spec应该是机器可读的

传统的PRD（产品需求文档）是写给人看的Word文档，充满了模糊的表述：”用户体验要好”、”加载速度要快”、”界面要美观”。

Open Spec要求Spec是结构化的、无歧义的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 传统PRD
"用户可以注册账号"

# Open Spec
auth.register:
  input:
    email: string, required, format: email
    password: string, required, min_length: 8, must_contain: [upper, lower, digit]
  output:
    success: { user_id: uuid, token: jwt }
    failure: { error: enum[email_taken, invalid_format, weak_password] }
  behavior:
    - 发送验证邮件
    - 密码使用 bcrypt 哈希存储
    - 速率限制: 5次/分钟/IP

2. Spec应该是版本化的

Spec和代码一样，需要版本控制。当需求变更时，我们修改Spec，然后让AI重新生成受影响的代码。

3. Spec应该是可测试的

每一条Spec都应该能直接转化为测试用例。Spec说”密码最少8位”，那测试就应该验证7位密码被拒绝。

4. Spec应该是开放共享的

好的Spec模式可以被复用。认证模块的Spec、分页组件的Spec、RESTful API的Spec……这些模式可以被社区共享和改进。

Superpowers：SDD的工程化实现

Superpowers 是一个将SDD理念落地的工作流框架。它定义了一套严格的开发管线：

1
Idea → Brainstorm → Plan → Subagent-Driven Build (TDD) → Code Review → Finish Branch

让我们逐个拆解。

Phase 1: Brainstorming（头脑风暴）

铁律：不碰任何代码。

当你说”我要做一个XXX”时，Superpowers不会让AI立刻开始写代码。它会：

  1. 探索项目上下文 — 读代码、读文档、看最近的提交
  2. 逐个提问 — 一次只问一个问题，优先提供选择题
  3. 提出2-3个方案 — 每个方案有明确的优劣分析和推荐
  4. 逐段审批 — 设计分段呈现，每段都需要你确认
  5. 输出设计文档 — 保存到 docs/plans/YYYY-MM-DD-<topic>-design.md

💡 关键洞察： 这个阶段的价值不在于”设计文档”本身，而在于迫使你思考清楚。很多bug的根源不是代码写错了，而是需求想错了。

Phase 2: Writing Plans（编写计划）

设计通过后，进入计划阶段。Superpowers会：

  • 将设计拆解为细粒度的任务
  • 每个任务控制在 2-5分钟 的执行时间
  • 每个任务遵循 TDD 循环：写测试 → 看失败 → 实现 → 看通过 → 提交

这种粒度的设计是有原因的——它让每个任务都是可验证的。你不需要等到最后才知道哪里出了问题。

Phase 3: Subagent-Driven Development（子代理驱动开发）

这是Superpowers最酷的部分。每个任务不是由一个AI完成的，而是由三个子代理协作：

1
2
3
4
5
6
┌─────────────┐     ┌──────────────┐     ┌──────────────┐
│  Implementer │ ──→ │ Spec Reviewer │ ──→ │ Code Reviewer │
│  （实现者）   │     │ （规格审查者） │     │ （代码审查者） │
└─────────────┘     └──────────────┘     └──────────────┘
     ↓                      ↓                     ↓
   写代码              检查是否符合Spec        检查代码质量
  • Implementer： 根据任务描述和Spec编写代码，严格遵循TDD
  • Spec Reviewer： 确认代码完全符合Spec要求，不多不少
  • Code Reviewer： 检查代码质量、风格、潜在问题

三个角色互相制衡，就像现实中的团队协作一样。

Phase 4: Systematic Debugging（系统化调试）

出了bug？Superpowers不允许”试试这个修一下”式的碰运气。

铁律：不找到根因，不写任何修复代码。

调试流程：

  1. 根因调查 — 读错误信息、复现问题、检查最近变更、追踪数据流
  2. 模式分析 — 找到正常工作的例子，对比差异
  3. 假设-验证 — 一次只验证一个假设
  4. 修复-验证 — 从根因修复，确认不引入新问题

Phase 5: Finishing Branch（完成分支）

所有任务完成、所有测试通过后：

  • 确认所有测试通过
  • 选择：本地合并 / 推送PR / 保留分支 / 丢弃
  • 清理

实战：一个SDD驱动的开发示例

假设你要开发一个”用户待办事项”功能。

❌ Vibe Coding 方式

1
2
3
4
5
6
你：帮我写一个待办事项功能
AI：好的！[哗啦哗啦生成200行代码]
你：嗯……加个截止日期？
AI：好的！[改了5个文件]
你：等等，之前的排序逻辑好像坏了？
AI：让我看看……[又改了3个文件]

✅ SDD + Superpowers 方式

Step 1: Brainstorm

1
2
3
4
5
6
7
8
9
10
11
12
13
AI: 我来了解一下项目上下文……你的项目用的是什么技术栈？
你: React + TypeScript + Zustand
AI: 了解。关于待办事项，你希望支持哪些操作？
    A. 基础CRUD（增删改查）
    B. A + 标签/分类
    C. B + 截止日期 + 优先级
你: C
AI: 数据存储方案呢？
    A. 本地 localStorage
    B. 后端API
    C. 先本地，预留API接口
你: C
AI: 好的，我来输出设计文档……

Step 2: Spec → Plan

1
2
3
4
5
6
7
8
9
10
11
12
13
## Task 1: 数据模型 (2min)
- 定义 Todo 类型: { id, title, completed, priority, dueDate, tags }
- 写测试：创建 Todo 实例，验证所有字段

## Task 2: Store 实现 (3min)
- Zustand store: addTodo, toggleTodo, deleteTodo, updateTodo
- 写测试：每个 action 的行为验证

## Task 3: 列表组件 (3min)
- TodoList 组件渲染
- 写测试：空列表、有数据、完成状态筛选

...

Step 3: 子代理执行

1
2
3
4
5
6
[Implementer 子代理] 完成 Task 1: 数据模型 ✅
[Spec Reviewer 子代理] 验证：数据模型完全符合 Spec ✅
[Code Reviewer 子代理] 代码质量：类型定义清晰，无问题 ✅

[Implementer 子代理] 完成 Task 2: Store 实现 ✅
...

每一步都有记录，每一步都可验证，每一步都可回溯。

SDD的核心优势

1. Spec即文档

传统开发中，文档永远是过时的。SDD中，Spec就是开发的起点，它永远不会过时——因为代码是根据它生成的。

2. AI的确定性

AI的输出质量取决于输入质量。模糊的Prompt产出模糊的代码，精确的Spec产出精确的代码。SDD把”模糊”从方程中移除了。

3. 可审计性

每一个变更都可以追溯到Spec中的哪一条需求。出了问题，你不需要考古代码，只需要检查Spec。

4. 真正的TDD

很多人说”我们要做TDD”，但实际执行时总是”先写代码，再补测试”。SDD+Superpowers的流程从结构上保证了TDD的执行——因为Plan中每个任务的第一步就是”写测试”。

5. 人机协作的最佳分工

角色 职责
人类 思考、定义、决策、审批
AI 执行、实现、测试、审查

人类做人类擅长的事（创造性思考），AI做AI擅长的事（快速实现）。

SDD的边界与挑战

SDD不是银弹。它有明确的适用边界：

适合SDD的场景

  • ✅ 新功能开发
  • ✅ 有明确需求的项目
  • ✅ 需要多人/AI协作的场景
  • ✅ 对质量有要求的生产代码

不太适合的场景

  • ❌ 快速原型/一次性脚本
  • ❌ 探索性编程（还不知道自己要什么）
  • ❌ 单行修复（不需要完整流程）
  • ❌ 非代码任务

实践中的挑战

  1. 写好Spec是一种能力 — 需要练习，初期可能觉得”写Spec比写代码还慢”
  2. 不是所有需求都能精确定义 — 有些东西就是需要边做边调整
  3. 工具链还在成熟中 — SDD的工具生态还在早期

未来展望：Spec-First 的AI原生开发

我们正在见证软件开发范式的转变：

1
2
Code-First → Prompt-First → Spec-First
（代码优先）  （提示优先）    （规格优先）

Code-First时代（~2020）： 程序员写代码，文档是附属品。
Prompt-First时代（2023-2025）： 用自然语言驱动AI写代码，但Prompt是模糊的、临时的。
Spec-First时代（2025+）： Spec是精确的、持久的、可版本控制的，AI根据Spec生成和维护代码。

在这个范式下，**”会写Spec”将成为比”会写代码”更重要的技能**。

而Superpowers这样的工作流框架，为Spec-First开发提供了工程化的实践路径。它不只是一个”AI编程技巧”，而是一种新的软件工程方法论。

结语

SDD不是要取代Vibe Coding，而是为它加上了工程化的护栏。

如果你只是在写一个周末小项目，Vibe Coding完全够用。
但如果你在构建一个需要维护、需要协作、需要质量的项目——SDD值得你认真考虑。

先想清楚，再动手。先写Spec，再写代码。

这不是新道理，但在AI时代，它比以往任何时候都更重要。

参考资料