基于规范编程SDD-OpenSpec及SuperPowers

AI 编码助手越来越强，但"写代码"从来不是软件开发最难的部分------写对代码才是。

当我们把需求丢给 AI，它能秒出几百行代码，但这些代码真的是我们想要的吗？它符合设计意图吗？有没有超出范围？有没有遗漏场景？

如果没有一套规范驱动的工作流来约束 AI 的行为，"AI 写代码"很容易变成"AI 制造技术债"。

本文介绍两个解决这个问题的框架：OpenSpec 和 Superpowers 。它们都属于 SDD（Spec-Driven Development，规范驱动开发） 的实践------先写规范，再写代码，用规范约束 AI 的每一步行为。

什么是规范驱动开发（SDD）

传统的 AI 辅助编码是这样的：

用户描述需求 → AI 直接写代码 → 用户检查代码 → 发现不对 → 重来

SDD 的思路完全不同：

用户描述需求 → 生成规范文档（提案/设计/规格/任务） → AI 按规范实现 → 按规范验证

核心理念只有一句话：先想清楚再动手，用文档约束行为，用验证确保正确。

下面分别看两个框架是怎么落地这个理念的。

OpenSpec --- 规格驱动的变更管理

OpenSpec 是 CodeMaker 内置的结构化开发工作流框架，核心思想是每次变更都有完整的设计文档可追溯。它不是一个独立工具，而是嵌入在 AI 编码助手中的一套工作流规范。

2 核心概念：Artifact 链

OpenSpec 的核心是一条 Artifact 依赖链，每个 artifact 都是前一个的细化：

proposal.md → design.md → specs/*.md → tasks.md → 代码实现 → 归档
   (为什么做)    (怎么做)     (做成什么样)   (分几步做)   (动手做)    (存档)

每个 artifact 的职责：

Artifact	职责	核心内容
proposal.md	变更提案	为什么做、目标/非目标、影响范围
design.md	设计决策	技术方案选择、替代方案对比、风险评估
specs/*.md	需求规格	Requirements + Scenarios（WHEN/THEN）
tasks.md	任务清单	可执行的 checkbox 任务列表

2 工作流程

OpenSpec 提供了一组命令来驱动整个流程：

命令	作用	说明
/opsx:explore	探索模式	自由思考，不写代码，只讨论
/opsx:propose	提案	生成 proposal + 后续 artifacts
/opsx:ff	快速通道	一次性生成所有 artifacts
/opsx:apply	实现	逐 task 实现代码
/opsx:verify	验证	对照 artifacts 检查实现
/opsx:archive	归档	归档完成的变更

3 典型使用流程

以"启动时检查并拉起后台服务"为例：

第一步：快速生成所有 artifacts

/opsx:ff 启动时检查并拉起 UniCloudService 后台服务

AI 会自动生成：

• proposal.md --- 阐述为什么需要这个变更
• design.md --- 技术方案：复用 ServiceUtils、启动失败不阻塞
• specs/unicloud-service-startup/spec.md --- 4 个场景（未注册/已运行/未运行/启动失败）
• tasks.md --- 3 个可执行任务

第二步：开始实现

/opsx:apply

AI 逐个 task 实现代码，每个 task 完成后自动对照 specs 验证。

第三步：归档

/opsx:archive

变更归档到 openspec/changes/archive/2026-03-25-start-unicloud-service/，形成可追溯的变更历史。

4 Spec 管理体系

OpenSpec 最独特的设计是主 spec + delta spec 体系：

openspec/
├── specs/                          # 主 specs（项目级知识库）
│   └── disk-mount/spec.md
│
└── changes/                        # 变更目录
    ├── start-unicloud-service/     # 活跃变更
    │   ├── proposal.md
    │   ├── design.md
    │   ├── specs/                  # delta specs（变更级）
    │   │   └── unicloud-service-startup/spec.md
    │   └── tasks.md
    │
    └── archive/                    # 已归档变更
        └── 2026-03-25-start-unicloud-service/

每次变更产生 delta spec，归档时同步到主 spec，形成项目级规格知识库。

Superpowers --- 多代理协作的完整开发工作流

Superpowers 是由 Jesse Vincent 开发的开源项目，为 AI 编码代理提供一套完整的软件开发工作流。它支持 Claude Code、Cursor、Codex、Gemini CLI 等多个平台，核心特色是子代理驱动开发 和强制 TDD。

1 核心概念：Skills 组合

Superpowers 由一组可组合的 Skills 构成，每个 skill 是一份 Markdown 格式的指令文件，定义了 AI 在特定阶段应该做什么。

类别	Skills	职责
协作	brainstorming	苏格拉底式对话，提问 → 方案对比 → 设计文档
规划	writing-plans	拆分为 2-5 分钟的 bite-sized tasks
执行	subagent-driven-development	每个 task 派遣独立子代理实现
测试	test-driven-development	强制 RED-GREEN-REFACTOR 循环
审查	requesting-code-review	两阶段审查：Spec 合规 → 代码质量
Git	using-git-worktrees	隔离工作空间 + 基线验证
收尾	finishing-a-development-branch	合并 / PR / 保留 / 丢弃

2 工作流程

Superpowers 的完整流程如下：

brainstorming        苏格拉底式对话，逐个提问，输出设计文档
     ↓
using-git-worktrees  创建隔离工作空间，验证编译基线
     ↓
writing-plans        拆分为 bite-sized tasks（每步 2-5 分钟）
     ↓
subagent-driven-dev  每个 task 派遣子代理：
                     ├── Implementer 子代理（实现 + 自审查）
                     ├── Spec Reviewer 子代理（合规审查）
                     └── Code Quality Reviewer 子代理（质量审查）
     ↓
finishing-branch     收尾：合并 / 创建 PR / 保留 / 丢弃

3 子代理驱动开发（核心特色）

这是 Superpowers 最核心的设计。每个 task 的执行过程：

Controller（编排者）
     │
     ├─→ 派遣 Implementer 子代理
     │      ├── 提问（如有疑问）
     │      ├── 实现代码
     │      ├── 写测试（TDD）
     │      ├── 自审查
     │      └── 报告状态：DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT
     │
     ├─→ 派遣 Spec Reviewer 子代理
     │      └── 对照 plan 逐条检查：做对了吗？
     │          ├── ✅ 通过 → 继续
     │          └── ❌ 问题 → Implementer 修复 → 重新审查
     │
     └─→ 派遣 Code Quality Reviewer 子代理
            └── 审查代码质量：做好了吗？
                ├── ✅ 通过 → 标记完成
                └── ❌ 问题 → Implementer 修复 → 重新审查

**关键设计：每个子代理拥有独立的上下文。**Controller 精确裁剪传递给子代理的信息，避免上下文污染。这是"多代理"比"单代理"质量更高的根本原因。

4 强制 TDD

Superpowers 在 Plan 阶段就把 TDD 写进每个 step：

- [ ] Step 1: 写失败测试
- [ ] Step 2: 运行确认失败
- [ ] Step 3: 写最小实现代码
- [ ] Step 4: 运行确认通过
- [ ] Step 5: 提交

如果 Implementer 子代理没有先写测试就开始写代码，Spec Reviewer 会直接拒绝。

5 两阶段审查

每个 task 完成后，强制经过两轮独立审查：

阶段	审查者	关注点	输出
第一阶段	Spec Reviewer	做对了吗？需求覆盖、场景遗漏、过度实现	✅ / ❌ + 具体问题
第二阶段	Code Quality Reviewer	做好了吗？代码质量、架构、安全、测试	Critical / Important / Minor 分级

**阶段 2 必须在阶段 1 通过后才能开始。**如果代码做的事情本身就不对，审查代码质量没有意义。

OpenSpec与SuperPowers的对比

维度	OpenSpec	Superpowers
一句话定位	规格驱动的变更管理框架	多代理协作的完整开发工作流
核心理念	先写 Spec 再实现，变更可追溯	先设计再编码，TDD + 子代理分工
哲学	Proposal → Design → Spec → Tasks	Brainstorm → Plan → TDD + Subagent → Review
侧重点	决策追溯 + 知识积累	执行质量 + 自动化审查

1 流程对比

OpenSpec:        explore → proposal → design → specs → tasks → apply → verify → archive
Superpowers:     brainstorming → git-worktree → writing-plans → subagent-dev → finishing-branch

阶段	OpenSpec	Superpowers
探索/需求	explore + proposal	brainstorming（苏格拉底式一问一答）
设计	design.md（Decisions 记录）	融合在 design doc 中
规格	独立 specs/ 目录，有 delta/主 spec 同步	无独立 spec，融合在 design doc 中
任务拆分	tasks.md（功能粒度）	Plan（2-5 分钟/step，含完整代码）
实现	单代理逐 task 实现	子代理隔离实现 + 两阶段审查
测试	不强制 TDD	强制 TDD（RED-GREEN-REFACTOR）
审查	自审查 checklist	独立子代理审查（上下文隔离）
Git	不强制分支策略	强制 git worktree 隔离
收尾	archive（归档 artifacts）	finishing-branch（合并/PR/丢弃）

2 核心能力差异

① 子代理 vs 单代理

	Superpowers（子代理）	OpenSpec（单代理）
执行模式	Controller + Implementer + Reviewer × 2	同一个 AI 全程负责
上下文	每个子代理独立上下文，精确裁剪	共享上下文，长对话可能漂移
审查客观性	高（审查者没有"我写的"心理包袱）	中（需要角色切换来模拟）
平台依赖	需要支持子代理派遣（Claude Code 等）	任何 AI 助手均可

② Spec 管理

	OpenSpec	Superpowers
独立 Spec 体系	✅ 主 spec + delta spec + 同步	❌ 无独立 spec，融合在 design doc
长期积累	specs 按 capability 组织，可查询	plan/design 平铺在 docs 目录
变更追溯	archive 按日期归档，含完整 artifacts	依赖 Git 历史

③ 测试策略

	Superpowers	OpenSpec
TDD	强制：写失败测试 → 运行 → 实现 → 运行 → 提交	不强制，以编译通过和行为验证为准
Plan 中的测试	每个 step 包含完整测试代码	tasks 中不含测试代码

3 适用场景

场景	推荐	原因
全新项目 / 绿地开发	Superpowers	TDD + worktree + 子代理，端到端自动化
大型企业项目改动	OpenSpec	spec 追溯 + 变更归档，适合团队 review
需要长期维护 specs	OpenSpec	主 spec + delta spec + 同步 + 归档
有严格测试要求	Superpowers	内置 TDD 强制
不支持子代理的平台	OpenSpec	天然单代理模式
多代理协作环境	Superpowers	核心设计就是子代理驱动

总结

维度	OpenSpec	Superpowers
核心优势	Spec 驱动 + 变更追溯 + 知识积累	子代理隔离 + TDD 强制 + 自动化审查
核心劣势	无 TDD 强制、无子代理、无 git 集成	平台依赖强、token 开销大、无 spec 管理
一句话	"让每次变更都有设计文档可追溯"	"让 AI 代理像有纪律的开发团队一样工作"

两者解决的问题有重叠但侧重不同：Superpowers 侧重执行质量 （通过子代理 + TDD + Review 保证代码正确），OpenSpec 侧重决策追溯（通过 artifact 链 + spec 管理保证设计可查）。

它们不是竞争关系，而是互补关系。最佳实践是：用 OpenSpec 做 spec 管理和变更追溯，从 Superpowers 中提取审查 SDD 强化Spec文件合规审查，约束 AI 可能的幻觉 - 唐宋元明清2188 - 博客园 和 worktree 能力增强执行质量 。毕竟，规范编程的终极目标只有一个------让 AI 写的每一行代码，都有据可查、有规可循。

以上就是关于 OpenSpec 和 Superpowers 两种 SDD 框架的介绍与对比。如果你正在使用 AI 辅助开发，不妨试试用规范来约束 AI 的行为------你会发现，花在设计上的时间，会在实现阶段成倍地省回来。