Vibe Coding 让人着迷——随口描述，代码即出。但当你真正交付时，“凭感觉"是蜜糖也是砒霜。
SDD 用规范替代感觉：先对齐设计，再动手实现——让 AI 从"猜你心思"变成"按图施工”。

---

一个熟悉的场景

你打开Codex或Claude Code，输入：

“帮我做一个用户登录系统。”

AI噼里啪啦开始写代码。5分钟后，你发现：

• 它用了JWT，但你想用Session
• 它没做密码加密，安全漏洞
• 登录成功后跳转的页面不是你想要的
• 接口设计和你的现有项目风格格格不入

于是你开始一轮又一轮的“改一下这个”、“改成那个”——死亡提示词循环开始了。

这是传统提示词驱动开发的典型困境：你用一个模糊的自然语言描述去驱动一个“过分热情”的AI，它会在缺乏共识的情况下直接开干，产出的代码往往偏离你的真实意图。

---

规范驱动开发是什么？

Spec-Driven Development（SDD） 的核心理念只有五个字：

先对齐，再动手。

在写任何一行代码之前，人和AI先在规范（Spec）上达成一致。这个规范不是传统的上百页PRD文档，而是轻量级的、以AI可消费的格式组织的“约定”——它描述系统应该做什么，以及怎样才算做对了。

SDD的核心流程可以抽象为：

理解意图 → 输出设计（Spec） → 人工确认 → 制定计划 → 分步实现 → 验证归档

以下两个开源项目是目前SDD领域最具代表性的实践——它们分别从不同角度回答了“如何让AI按照规范干活”。

---

Superpowers：用技能链约束AI的行为

Superpowers 是一套为AI编程助手设计的技能体系与方法论。它不是让你改变提问方式，而是改变AI的“思维方式”——当AI检测到你要构建什么东西时，它会强制执行一系列技能流程，而不是直接跳到写代码。

Superpowers的核心工作流

1. 头脑风暴（brainstorming）
      ↓ 设计文档（spec）
2. 编写计划（writing-plans）  
      ↓ 详细实现计划（plan）
3. 子代理开发（subagent-driven-development）  
      ↓ 每个任务 = 独立子代理 + 两阶段审查
4. 测试驱动开发（test-driven-development）
      ↓ RED-GREEN-REFACTOR
5. 完成分支（finishing-a-development-branch）
      ↓ 合并/PR/清理

头脑风暴：AI的第一反应不是写代码

这是Superpowers最核心的设计哲学转变。当你说“帮我做一个功能”时，AI不会直接写代码，它会：

1. 探索项目上下文 —— 检查现有文件、文档、最近提交
2. 逐个提问 —— 一次只问一个问题，理解你的目的、约束、成功标准
3. 提出2-3种方案 —— 带权衡分析和推荐
4. 分段呈现设计 —— 每段设计都等你确认后才继续
5. 输出设计文档 —— 保存为 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

Superpowers文档中有一个硬性规则：

在呈现设计并获得用户批准之前，禁止调用任何实现技能、编写任何代码、搭建任何项目。

哪怕是做一个todo list、一个单文件工具、一行配置修改——全部都要走这个流程。Superpowers的作者认为：简单的项目恰恰是未经审视的假设造成最多返工的地方。

编写计划：把设计变成“菜鸟也能执行”的任务清单

设计通过后，AI会生成一份粒度极细的实现计划。每个任务被拆解到2-5分钟的级别：

- [ ] 编写失败的测试
- [ ] 运行测试确认失败
- [ ] 实现最小代码让测试通过
- [ ] 运行测试确认通过
- [ ] 提交

每个任务包含：精确文件路径、完整代码片段、准确的验证命令和预期输出。没有“TODO”、没有“适当添加错误处理”——这些在Superpowers里被视为计划失败。

子代理驱动开发：AI自主工作数小时

这是Superpowers最激进的特性。计划就绪后，AI会：

• 为每个任务派发一个全新的子代理（干净上下文）
• 每个子代理完成后进行两阶段审查：规范合规性 + 代码质量
• 发现Critical/Important问题→修复→重新审查，直到通过
• 不间断执行所有任务，不中途询问“要继续吗？”

“你的编程助手自主工作几个小时而不偏离你们一起制定的计划，并不罕见。”

---

OpenSpec：用文件系统做AI的“合同”

OpenSpec 采取了不同的路径：它不是约束AI的行为，而是引入了一套规范文件系统——让AI和人在同一个文件结构上对话。

OpenSpec的核心理念

fluid not rigid      —— 不是瀑布，随时可以回头改
iterative not waterfall —— 边做边学，持续完善
easy not complex     —— 几秒初始化，几乎零学习成本
brownfield-first     —— 为存量项目而生，不只是新建项目

核心数据结构

openspec/
├── specs/              ← 真相来源：系统现在如何工作
│   ├── auth/spec.md
│   ├── payments/spec.md
│   └── ui/spec.md
└── changes/            ← 变更提案：你想改什么
    └── add-dark-mode/
        ├── proposal.md   ← 为什么改
        ├── specs/        ← 改什么（delta specs）
        ├── design.md     ← 怎么改
        └── tasks.md      ← 实施步骤

Delta Specs：只写变化，不写全部

这是OpenSpec的巧思。在传统规范系统中，一个需求变更可能需要重写整个规范文档。OpenSpec只写变化的部分：

## ADDED Requirements
- 系统 SHALL 在30分钟无操作后自动登出用户

## MODIFIED Requirements  
- 登录接口 SHALL 同时返回 access_token 和 refresh_token
  （原: 只返回 session_id）

## REMOVED Requirements
- 系统 SHALL 在首页显示登录次数统计

这让OpenSpec特别适合已有的、大型代码库的增量开发。

工作流：四个斜杠命令完成一个变更周期

/opsx:explore           → (可选) 先想清楚再动手
/opsx:propose add-dark-mode  → AI起草 proposal + specs + design + tasks
        (你审阅并调整计划)
/opsx:apply             → AI实施，逐个勾选任务
/opsx:archive           → delta specs合并进主specs，变更归档

“Enablers, not gates”（推动者，不是关卡）

OpenSpec强调，artifact之间的依赖关系是赋能的，不是锁死的：

proposal → specs → design → tasks 这个顺序告诉你什么变得可能了，不是逼你按什么顺序来。实现过程中发现设计有问题？直接改 design.md 继续。发现范围应该缩小？更新 proposal。没有东西被锁定。

---

SDD vs. 传统提示词开发：关键差异

维度	传统提示词开发	规范驱动开发（SDD）
启动方式	一句提示词直接生成代码	先头脑风暴，对齐意图后再动手
需求管理	散落在聊天历史中，难以追溯	以设计文档（spec）形式保存在仓库中
代码质量	依赖AI的“自觉”，经常偷工减料	强制TDD，RED-GREEN-REFACTOR
任务粒度	AI自行决定，容易跳过边缘情况	2-5分钟一个任务，每步都可验证
审查机制	无，靠人眼逐行检查	子代理自动审查：规范合规+代码质量
变更追溯	散落在git commit和聊天记录中	归档的change文件夹 = 完整的设计→实现考古记录
适合场景	快速原型、一次性脚本	团队协作、长期维护、大型项目
上手成本	几乎为零	需要安装配置，但Superpowers自动触发技能
自主性	AI容易跑偏	AI在规范框架内高度自主

---

为什么SDD更适合AI编程时代

传统提示词开发模仿的是人类即时对话的模式——你说一句，我做一下。但AI不是人，它需要更多的结构和约束才能高质量工作。原因有三：

1. AI的“过分热情”需要刹车

当前的AI编程助手倾向于“尽快交付可以运行的东西”——这本身不是坏事，但没有规范约束时，它会为了“看起来完成”而跳过设计思考。SDD通过硬性的设计评审关卡，给AI的冲动踩了刹车。

2. 规范是团队协作的多语言翻译器

在团队中，产品经理用自然语言描述需求，工程师用代码实现，AI用模型理解。规范文件成了三者之间可追溯、可版本控制、可审查的共同语言。六个月后回看一个change文件夹，你能完整理解“为什么这么做、做了什么、怎么做的”。

3. 规范让AI从“助手”变成“工程师”

没有规范时，AI是一个听从模糊指令的助手：“把这个改成那个”、“颜色改蓝一点”。有了规范后，AI变成了一个理解上下文、能自主推进、交付可审查工作的工程师——你在设计阶段把关，它在实现阶段自主。

---

两个项目的互补关系

Superpowers 和 OpenSpec 不是竞争关系，而是解决同一问题的不同层次：

• Superpowers 侧重行为约束——通过技能链改变AI的决策流程，适合想要“装上就用”的开发者
• OpenSpec 侧重结构约束——通过文件系统规范信息组织方式，适合需要团队协作和严格追溯的项目

两者可以配合使用：OpenSpec的文件结构 + Superpowers的技能驱动执行，构成完整的SDD体系。

---

开始你的第一次SDD

如果你想试试Superpowers：

# Codex CLI
/plugins
# 搜索 superpowers，安装

# Claude Code  
/plugin install superpowers@claude-plugins-official

然后直接说“帮我做一个功能”，观察AI的行为变化。

如果你想试试OpenSpec：

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init
# 然后在AI助手中使用
/opsx:explore    # 先探索
/opsx:propose    # 起草规范
/opsx:apply      # 实施
/opsx:archive    # 归档

---

写在最后

传统提示词开发让你和AI处在一种模糊的、不断讨价还价的关系中。规范驱动开发则建立了清晰的分工：你负责定义“对”是什么，AI负责把“对”做出来。

这个转变背后是一个更深层的认知：在AI可以写代码的时代，“写代码”本身不再稀缺。稀缺的是“知道该写什么代码”。 规范就是那个“知道”的显式表达。

这也许就是AI编程工具的下一个演进方向——不是更强的模型、更快的补全，而是更好的协作协议。

---

参考项目：

• Superpowers — by Jesse Vincent / Prime Radiant
• OpenSpec — by Fission-AI