SDD基于规范编程-OpenSpec及SuperPowers
<p>AI 编码助手越来越强，但"写代码"从来不是软件开发最难的部分——<strong>写对代码</strong>才是。</p><p>当我们把需求丢给 AI，它能秒出几百行代码，但这些代码真的是我们想要的吗？它符合设计意图吗？有没有超出范围？有没有遗漏场景？</p>
<p>如果没有一套<strong>规范驱动</strong>的工作流来约束 AI 的行为，"AI 写代码"很容易变成"AI 制造技术债"。</p>
<p>本文介绍两个解决这个问题的框架：<strong>OpenSpec</strong> 和 <strong>Superpowers</strong>。它们都属于 <strong>SDD（Spec-Driven Development，规范驱动开发）</strong> 的实践——先写规范，再写代码，用规范约束 AI 的每一步行为。</p>
<h2>什么是规范驱动开发（SDD）</h2>
<p>传统的 AI 辅助编码是这样的：</p>
用户描述需求 → AI 直接写代码 → 用户检查代码 → 发现不对 → 重来
<p>SDD 的思路完全不同：</p>
用户描述需求 → 生成规范文档（提案/设计/规格/任务） → AI 按规范实现 → 按规范验证
<p>核心理念只有一句话：<strong>先想清楚再动手，用文档约束行为，用验证确保正确。</strong></p>
<p>下面分别看两个框架是怎么落地这个理念的。</p>
<h2>OpenSpec — 规格驱动的变更管理</h2>
<p>OpenSpec 是 CodeMaker 内置的结构化开发工作流框架，核心思想是<strong>每次变更都有完整的设计文档可追溯</strong>。它不是一个独立工具，而是嵌入在 AI 编码助手中的一套工作流规范。</p>
<p><strong>2 核心概念：Artifact 链</strong></p>
<p>OpenSpec 的核心是一条 <strong>Artifact 依赖链</strong>，每个 artifact 都是前一个的细化：</p>
proposal.md → design.md → specs/*.md → tasks.md → 代码实现 → 归档
(为什么做) (怎么做) (做成什么样) (分几步做) (动手做) (存档)
<p>每个 artifact 的职责：</p>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th>Artifact</th><th>职责</th><th>核心内容</th></tr>
</thead>
<tbody>
<tr>
<td><strong>proposal.md</strong></td>
<td>变更提案</td>
<td>为什么做、目标/非目标、影响范围</td>
</tr>
<tr>
<td><strong>design.md</strong></td>
<td>设计决策</td>
<td>技术方案选择、替代方案对比、风险评估</td>
</tr>
<tr>
<td><strong>specs/*.md</strong></td>
<td>需求规格</td>
<td>Requirements + Scenarios（WHEN/THEN）</td>
</tr>
<tr>
<td><strong>tasks.md</strong></td>
<td>任务清单</td>
<td>可执行的 checkbox 任务列表</td>
</tr>
</tbody>
</table>
<p><strong>2 工作流程</strong></p>
<p>OpenSpec 提供了一组命令来驱动整个流程：</p>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th>命令</th><th>作用</th><th>说明</th></tr>
</thead>
<tbody>
<tr>
<td><code>/opsx:explore</code></td>
<td>探索模式</td>
<td>自由思考，不写代码，只讨论</td>
</tr>
<tr>
<td><code>/opsx:propose</code></td>
<td>提案</td>
<td>生成 proposal + 后续 artifacts</td>
</tr>
<tr>
<td><code>/opsx:ff</code></td>
<td>快速通道</td>
<td>一次性生成所有 artifacts</td>
</tr>
<tr>
<td>/opsx:apply</td>
<td>实现</td>
<td>逐 task 实现代码</td>
</tr>
<tr>
<td><code>/opsx:verify</code></td>
<td>验证</td>
<td>对照 artifacts 检查实现</td>
</tr>
<tr>
<td>/opsx:archive</td>
<td>归档</td>
<td>归档完成的变更</td>
</tr>
</tbody>
</table>
<p><strong>3 典型使用流程</strong></p>
<p>以"启动时检查并拉起后台服务"为例：</p>
<p><strong>第一步：快速生成所有 artifacts</strong></p>
/opsx:ff 启动时检查并拉起 UniCloudService 后台服务
<p>AI 会自动生成：</p>
<ul>
<li><code>proposal.md</code> — 阐述为什么需要这个变更</li>
<li><code>design.md</code> — 技术方案：复用 ServiceUtils、启动失败不阻塞</li>
<li><code>specs/unicloud-service-startup/spec.md</code> — 4 个场景（未注册/已运行/未运行/启动失败）</li>
<li><code>tasks.md</code> — 3 个可执行任务</li>
</ul>
<p><strong>第二步：开始实现</strong></p>
/opsx:apply
<p>AI 逐个 task 实现代码，每个 task 完成后自动对照 specs 验证。</p>
<p><strong>第三步：归档</strong></p>
/opsx:archive
<p>变更归档到 <code>openspec/changes/archive/2026-03-25-start-unicloud-service/</code>，形成可追溯的变更历史。</p>
<p><strong>4 Spec 管理体系</strong></p>
<p>OpenSpec 最独特的设计是<strong>主 spec + delta spec</strong> 体系：</p>
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/
<p>每次变更产生 delta spec，归档时同步到主 spec，形成<strong>项目级规格知识库</strong>。</p>
<h2>Superpowers — 多代理协作的完整开发工作流</h2>
<p>Superpowers 是由 Jesse Vincent 开发的开源项目，为 AI 编码代理提供一套完整的软件开发工作流。它支持 Claude Code、Cursor、Codex、Gemini CLI 等多个平台，核心特色是<strong>子代理驱动开发</strong>和<strong>强制 TDD</strong>。</p>
<p><strong>1 核心概念：Skills 组合</strong></p>
<p>Superpowers 由一组可组合的 <strong>Skills</strong> 构成，每个 skill 是一份 Markdown 格式的指令文件，定义了 AI 在特定阶段应该做什么。</p>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th>类别</th><th>Skills</th><th>职责</th></tr>
</thead>
<tbody>
<tr>
<td><strong>协作</strong></td>
<td>brainstorming</td>
<td>苏格拉底式对话，提问 → 方案对比 → 设计文档</td>
</tr>
<tr>
<td><strong>规划</strong></td>
<td>writing-plans</td>
<td>拆分为 2-5 分钟的 bite-sized tasks</td>
</tr>
<tr>
<td><strong>执行</strong></td>
<td>subagent-driven-development</td>
<td>每个 task 派遣独立子代理实现</td>
</tr>
<tr>
<td><strong>测试</strong></td>
<td>test-driven-development</td>
<td>强制 RED-GREEN-REFACTOR 循环</td>
</tr>
<tr>
<td><strong>审查</strong></td>
<td>requesting-code-review</td>
<td>两阶段审查：Spec 合规 → 代码质量</td>
</tr>
<tr>
<td><strong>Git</strong></td>
<td>using-git-worktrees</td>
<td>隔离工作空间 + 基线验证</td>
</tr>
<tr>
<td><strong>收尾</strong></td>
<td>finishing-a-development-branch</td>
<td>合并 / PR / 保留 / 丢弃</td>
</tr>
</tbody>
</table>
<p><strong>2 工作流程</strong></p>
<p>Superpowers 的完整流程如下：</p>
brainstorming 苏格拉底式对话，逐个提问，输出设计文档
↓
using-git-worktrees创建隔离工作空间，验证编译基线
↓
writing-plans 拆分为 bite-sized tasks（每步 2-5 分钟）
↓
subagent-driven-dev每个 task 派遣子代理：
├── Implementer 子代理（实现 + 自审查）
├── Spec Reviewer 子代理（合规审查）
└── Code Quality Reviewer 子代理（质量审查）
↓
finishing-branch 收尾：合并 / 创建 PR / 保留 / 丢弃
<p><strong>3 子代理驱动开发（核心特色）</strong></p>
<p>这是 Superpowers 最核心的设计。每个 task 的执行过程：</p>
Controller（编排者）
│
├─→ 派遣 Implementer 子代理
│ ├── 提问（如有疑问）
│ ├── 实现代码
│ ├── 写测试（TDD）
│ ├── 自审查
│ └── 报告状态：DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT
│
├─→ 派遣 Spec Reviewer 子代理
│ └── 对照 plan 逐条检查：做对了吗？
│ ├── ✅ 通过 → 继续
│ └── ❌ 问题 → Implementer 修复 → 重新审查
│
└─→ 派遣 Code Quality Reviewer 子代理
└── 审查代码质量：做好了吗？
├── ✅ 通过 → 标记完成
└── ❌ 问题 → Implementer 修复 → 重新审查
<p><strong>关键设计：每个子代理拥有独立的上下文。</strong>Controller 精确裁剪传递给子代理的信息，避免上下文污染。这是"多代理"比"单代理"质量更高的根本原因。</p>
<p><strong>4 强制 TDD</strong></p>
<p>Superpowers 在 Plan 阶段就把 TDD 写进每个 step：</p>
- [ ] Step 1: 写失败测试
- [ ] Step 2: 运行确认失败
- [ ] Step 3: 写最小实现代码
- [ ] Step 4: 运行确认通过
- [ ] Step 5: 提交
<p>如果 Implementer 子代理没有先写测试就开始写代码，Spec Reviewer 会直接拒绝。</p>
<p><strong>5 两阶段审查</strong></p>
<p>每个 task 完成后，强制经过两轮独立审查：</p>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th>阶段</th><th>审查者</th><th>关注点</th><th>输出</th></tr>
</thead>
<tbody>
<tr>
<td>第一阶段</td>
<td>Spec Reviewer</td>
<td>做对了吗？需求覆盖、场景遗漏、过度实现</td>
<td>✅ / ❌ + 具体问题</td>
</tr>
<tr>
<td>第二阶段</td>
<td>Code Quality Reviewer</td>
<td>做好了吗？代码质量、架构、安全、测试</td>
<td>Critical / Important / Minor 分级</td>
</tr>
</tbody>
</table>
<p><strong>阶段 2 必须在阶段 1 通过后才能开始。</strong>如果代码做的事情本身就不对，审查代码质量没有意义。</p>
<h2>OpenSpec与SuperPowers的对比</h2>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th>维度</th><th>OpenSpec</th><th>Superpowers</th></tr>
</thead>
<tbody>
<tr>
<td><strong>一句话定位</strong></td>
<td>规格驱动的变更管理框架</td>
<td>多代理协作的完整开发工作流</td>
</tr>
<tr>
<td><strong>核心理念</strong></td>
<td>先写 Spec 再实现，变更可追溯</td>
<td>先设计再编码，TDD + 子代理分工</td>
</tr>
<tr>
<td><strong>哲学</strong></td>
<td>Proposal → Design → <strong>Spec</strong> → Tasks</td>
<td>Brainstorm → Plan → <strong>TDD + Subagent</strong> → Review</td>
</tr>
<tr>
<td><strong>侧重点</strong></td>
<td>决策追溯 + 知识积累</td>
<td>执行质量 + 自动化审查</td>
</tr>
</tbody>
</table>
<p><strong>1 流程对比</strong></p>
OpenSpec: explore → proposal → design → specs → tasks → apply → verify → archive
Superpowers: brainstorming → git-worktree → writing-plans → subagent-dev → finishing-branch
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th>阶段</th><th>OpenSpec</th><th>Superpowers</th></tr>
</thead>
<tbody>
<tr>
<td><strong>探索/需求</strong></td>
<td>explore + proposal</td>
<td>brainstorming（苏格拉底式一问一答）</td>
</tr>
<tr>
<td><strong>设计</strong></td>
<td>design.md（Decisions 记录）</td>
<td>融合在 design doc 中</td>
</tr>
<tr>
<td><strong>规格</strong></td>
<td><strong>独立 specs/ 目录</strong>，有 delta/主 spec 同步</td>
<td>无独立 spec，融合在 design doc 中</td>
</tr>
<tr>
<td><strong>任务拆分</strong></td>
<td>tasks.md（功能粒度）</td>
<td>Plan（2-5 分钟/step，含完整代码）</td>
</tr>
<tr>
<td><strong>实现</strong></td>
<td>单代理逐 task 实现</td>
<td><strong>子代理隔离实现 + 两阶段审查</strong></td>
</tr>
<tr>
<td><strong>测试</strong></td>
<td>不强制 TDD</td>
<td><strong>强制 TDD（RED-GREEN-REFACTOR）</strong></td>
</tr>
<tr>
<td><strong>审查</strong></td>
<td>自审查 checklist</td>
<td><strong>独立子代理审查（上下文隔离）</strong></td>
</tr>
<tr>
<td><strong>Git</strong></td>
<td>不强制分支策略</td>
<td><strong>强制 git worktree 隔离</strong></td>
</tr>
<tr>
<td><strong>收尾</strong></td>
<td>archive（归档 artifacts）</td>
<td>finishing-branch（合并/PR/丢弃）</td>
</tr>
</tbody>
</table>
<p><strong>2 核心能力差异</strong></p>
<p>① 子代理 vs 单代理</p>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th> </th><th>Superpowers（子代理）</th><th>OpenSpec（单代理）</th></tr>
</thead>
<tbody>
<tr>
<td><strong>执行模式</strong></td>
<td>Controller + Implementer + Reviewer × 2</td>
<td>同一个 AI 全程负责</td>
</tr>
<tr>
<td><strong>上下文</strong></td>
<td>每个子代理独立上下文，精确裁剪</td>
<td>共享上下文，长对话可能漂移</td>
</tr>
<tr>
<td><strong>审查客观性</strong></td>
<td>高（审查者没有"我写的"心理包袱）</td>
<td>中（需要角色切换来模拟）</td>
</tr>
<tr>
<td><strong>平台依赖</strong></td>
<td>需要支持子代理派遣（Claude Code 等）</td>
<td>任何 AI 助手均可</td>
</tr>
</tbody>
</table>
<p>② Spec 管理</p>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th> </th><th>OpenSpec</th><th>Superpowers</th></tr>
</thead>
<tbody>
<tr>
<td><strong>独立 Spec 体系</strong></td>
<td>✅ 主 spec + delta spec + 同步</td>
<td>❌ 无独立 spec，融合在 design doc</td>
</tr>
<tr>
<td><strong>长期积累</strong></td>
<td>specs 按 capability 组织，可查询</td>
<td>plan/design 平铺在 docs 目录</td>
</tr>
<tr>
<td><strong>变更追溯</strong></td>
<td>archive 按日期归档，含完整 artifacts</td>
<td>依赖 Git 历史</td>
</tr>
</tbody>
</table>
<p>③ 测试策略</p>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th> </th><th>Superpowers</th><th>OpenSpec</th></tr>
</thead>
<tbody>
<tr>
<td><strong>TDD</strong></td>
<td>强制：写失败测试 → 运行 → 实现 → 运行 → 提交</td>
<td>不强制，以编译通过和行为验证为准</td>
</tr>
<tr>
<td><strong>Plan 中的测试</strong></td>
<td>每个 step 包含完整测试代码</td>
<td>tasks 中不含测试代码</td>
</tr>
</tbody>
</table>
<strong>3 适用场景</strong>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th>场景</th><th>推荐</th><th>原因</th></tr>
</thead>
<tbody>
<tr>
<td>全新项目 / 绿地开发</td>
<td><strong>Superpowers</strong></td>
<td>TDD + worktree + 子代理，端到端自动化</td>
</tr>
<tr>
<td>大型企业项目改动</td>
<td><strong>OpenSpec</strong></td>
<td>spec 追溯 + 变更归档，适合团队 review</td>
</tr>
<tr>
<td>需要长期维护 specs</td>
<td><strong>OpenSpec</strong></td>
<td>主 spec + delta spec + 同步 + 归档</td>
</tr>
<tr>
<td>有严格测试要求</td>
<td><strong>Superpowers</strong></td>
<td>内置 TDD 强制</td>
</tr>
<tr>
<td>不支持子代理的平台</td>
<td><strong>OpenSpec</strong></td>
<td>天然单代理模式</td>
</tr>
<tr>
<td>多代理协作环境</td>
<td><strong>Superpowers</strong></td>
<td>核心设计就是子代理驱动</td>
</tr>
</tbody>
</table>
<h2>总结</h2>
<table border="1" cellspacing="0" cellpadding="8">
<thead>
<tr><th>维度</th><th>OpenSpec</th><th>Superpowers</th></tr>
</thead>
<tbody>
<tr>
<td><strong>核心优势</strong></td>
<td>Spec 驱动 + 变更追溯 + 知识积累</td>
<td>子代理隔离 + TDD 强制 + 自动化审查</td>
</tr>
<tr>
<td><strong>核心劣势</strong></td>
<td>无 TDD 强制、无子代理、无 git 集成</td>
<td>平台依赖强、token 开销大、无 spec 管理</td>
</tr>
<tr>
<td><strong>一句话</strong></td>
<td>"让每次变更都有设计文档可追溯"</td>
<td>"让 AI 代理像有纪律的开发团队一样工作"</td>
</tr>
</tbody>
</table>
<p>两者解决的问题有重叠但侧重不同：Superpowers 侧重<strong>执行质量</strong>（通过子代理 + TDD + Review 保证代码正确），OpenSpec 侧重<strong>决策追溯</strong>（通过 artifact 链 + spec 管理保证设计可查）。</p>
<p>它们不是竞争关系，而是互补关系。最佳实践是：<strong>用 OpenSpec 做 spec 管理和变更追溯，从 Superpowers 中提取审查 SDD 强化Spec文件合规审查，约束 AI 可能的幻觉 - 唐宋元明清2188 - 博客园 和 worktree 能力增强执行质量</strong>。毕竟，规范编程的终极目标只有一个——<strong>让 AI 写的每一行代码，都有据可查、有规可循。</strong></p>
<p>以上就是关于 OpenSpec 和 Superpowers 两种 SDD 框架的介绍与对比。如果你正在使用 AI 辅助开发，不妨试试用规范来约束 AI 的行为——你会发现，<strong>花在设计上的时间，会在实现阶段成倍地省回来</strong>。</p>
出处：http://www.cnblogs.com/kybs0/
让学习成为习惯，假设明天就有重大机遇等着你，你准备好了么
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文连接，否则保留追究法律责任的权利。<br>来源：程序园用户自行投稿发布，如果侵权，请联系站长删除<br>免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]