AI 开发规范工具组合使用手册

版本: v2.0 | 2026-03-20 基于: 15+ 篇文章深度阅读 + 3 组专项研究 + GitHub Issues + 社区讨论

一、为什么要组合使用？

单个工具各有盲区，组合后才能全覆盖：

盲区	Superpowers	OpenSpec	GSD
需求追溯	❌	✅ Git 归档	❌
工程纪律	✅ TDD 强制	❌	❌
上下文腐烂	❌	❌	✅ 波次管理
自主开发	✅ 子代理	❌ 需人工驱动	✅ 波次并行
增量修改	中	✅ 最佳	中
可中断恢复	部分	❌	✅ HANDOFF.json

组合后 = 需求对齐 + 工程纪律 + 上下文管理，全覆盖。

二、推荐组合方案

方案 A：Superpowers + OpenSpec ⭐（最推荐）

"最高效的开发者应该是'双语'的——用 Superpowers 做快速原型，用 OpenSpec 做结构化开发。" —— CSDN 文章（被 GitHub Issue #780 引用）

适合：个人开发者、追求代码质量 + 需求对齐

分工：

OpenSpec = 需求管理层（改什么、为什么改）
Superpowers = 工程纪律层（怎么写才对）

方案 B：GSD + OpenSpec（速度优先）

适合：想让 AI 自主跑几小时、追求交付速度

分工：

OpenSpec = 规格管理层（统一真相文档、delta 变更）
GSD = 执行编排层（波次并行、状态恢复）

方案 C：三者全上（全能型）

适合：大型长期项目、Token 预算充足

分工：

OpenSpec = 需求管理层
Superpowers = 工程纪律层
GSD = 上下文管理层

方案 D：BMAD + Vibe Kanban（企业级）

适合：大型团队、需要可视化管理

分工：

BMAD = 21 Agent 全栈方法论
Vibe Kanban = 看板可视化并行开发

三、方案 A 详解：Superpowers + OpenSpec

3.1 安装配置

bash

# 1. 安装 OpenSpec（需要 Node.js 20.19+）
npm install -g @fission-ai/openspec@latest

# 2. 安装 Superpowers（通过 Claude Code marketplace）
# 在 Claude Code 中：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# 3. 在项目中初始化
cd your-project
openspec init
# Superpowers skills 自动加载到 .claude/skills/

共存确认（GitHub Issue #780，👍17）：

OpenSpec skills 在 .claude/skills/openspec/
Superpowers skills 在 .claude/skills/superpowers/
两者使用相同的 SKILL.md 格式，直接并存，无需特殊配置
命令命名空间隔离：OpenSpec 用 /opsx:*，Superpowers 用 $skill-name 自动触发

.claude/skills/
├── superpowers/
│   ├── brainstorming/SKILL.md          # 需求探索
│   ├── writing-plans/SKILL.md          # 计划编写
│   ├── test-driven-development/SKILL.md # TDD 强制
│   ├── systematic-debugging/SKILL.md   # 系统化调试
│   ├── subagent-driven-development/SKILL.md # 子代理开发
│   └── finishing-a-development-branch/SKILL.md # 收尾
└── openspec/
    ├── propose/SKILL.md   # 提出新变更
    ├── apply/SKILL.md     # 实现
    ├── verify/SKILL.md    # 验证
    └── archive/SKILL.md   # 归档

3.2 完整工作流

  你的想法
     │
     ▼
  ┌──────────────────────────────────────────┐
  │  Phase 1: 需求探索                        │
  │  Superpowers: $brainstorming 自动激活      │
  │  → 苏格拉底式对话，探索需求                  │
  │  → 讨论替代方案和边界情况                    │
  │  → 输出设计规格文档                         │
  └──────────────┬───────────────────────────┘
                 │ 人类确认方向
                 ▼
  ┌──────────────────────────────────────────┐
  │  Phase 2: 规范化                          │
  │  OpenSpec: /opsx:propose add-oauth2       │
  │  → 创建 .sillyspec/changes/add-oauth2/      │
  │    ├── proposal.md    # 为什么做、改什么    │
  │    ├── specs/         # 需求和场景         │
  │    ├── design.md      # 技术方案           │
  │    └── tasks.md       # 实现清单           │
  └──────────────┬───────────────────────────┘
                 │ 人类审阅 proposal + design
                 ▼
  ┌──────────────────────────────────────────┐
  │  Phase 3: 计划细化                        │
  │  Superpowers: $writing-plans 自动激活      │
  │  → 2-5 分钟粒度的任务                      │
  │  → 精确文件路径 + 验证步骤                  │
  │  → 保存到 docs/superpowers/plans/          │
  └──────────────┬───────────────────────────┘
                 │ 人类确认计划
                 ▼
  ┌──────────────────────────────────────────┐
  │  Phase 4: 隔离 + 执行                     │
  │  Superpowers: $using-git-worktrees        │
  │  → 创建隔离开发分支                        │
  │                                          │
  │  Superpowers: $test-driven-development    │
  │  → 🔴 RED: 写测试，看它失败                │
  │  → 🟢 GREEN: 写最少代码让它通过            │
  │  → 🔵 REFACTOR: 清理代码                  │
  │                                          │
  │  Superpowers: $subagent-driven-development│
  │  → 独立子代理逐个执行任务                   │
  │  → 两阶段审查（规范合规 → 代码质量）         │
  │  → 可自主工作数小时不跑偏                   │
  └──────────────┬───────────────────────────┘
                 ▼
  ┌──────────────────────────────────────────┐
  │  Phase 5: 验证 + 归档                     │
  │  Superpowers: $verification-before-completion│
  │  → 运行完整测试套件（fresh run）            │
  │                                          │
  │  OpenSpec: /opsx:verify                   │
  │  → 验证实现是否符合规范                     │
  │                                          │
  │  OpenSpec: /opsx:archive                  │
  │  → 归档到 .sillyspec/changes/archive/        │
  │  → 规范沉淀，三个月后仍可追溯               │
  └──────────────┬───────────────────────────┘
                 ▼
  Superpowers: $finishing-a-development-branch
  → merge / PR / keep / discard
                 │
                 ▼
           下一个需求 🔄

3.3 实战示例：修复"随机被登出"bug

Superpowers 部分（系统化调试）：

$systematic-debugging 自动激活

Phase 1: 根因追踪
  → 分析 session 管理代码
  → 检查 token 过期逻辑
  → 发现：Token 刷新竞态条件

Phase 2: TDD 修复
  → 写失败测试验证竞态条件
  → 实现修复（添加互斥锁）
  → 验证测试通过

Phase 3: 验证
  → 运行完整测试套件
  → 模拟并发请求
  → 确认：问题已解决

OpenSpec 部分（追踪与沉淀）：

/opsx:propose fix-session-token-race
/opsx:apply
/opsx:verify
/opsx:archive  → 团队成员可以追溯此修复

3.4 v5.0 新特性要点

Spec Review 循环：规划完成后启动对抗性审查子代理，找出计划中的 TBD 和遗漏
模型降级：有了详细计划后，实现阶段可用 Claude Haiku（便宜），Opus 只用于规划和审查
审查校准：审查子代理从 5 轮缩减到 3 轮，聚焦"会导致实现问题的缺陷"，不再纠结格式

3.5 Codex CLI 用户

如果使用 Codex CLI 而非 Claude Code：

bash

npx superpowers-codex install
# 确保 config.toml 启用 multi_agent

Claude Code	Codex CLI
Task (subagent)	spawn_agent(role="X")
Skill("superpowers:X")	$X 前缀
CLAUDE.md	AGENTS.md

3.6 大模型选择建议

阶段	推荐模型	原因
brainstorm + propose/design	Opus 4.5 / GPT 5.2	需要高推理能力
writing-plans	Opus 4.5	需要好的架构判断
TDD execute	Haiku（便宜）	有详细计划，便宜模型够用
verify + archive	Sonnet 4	中等推理，控制成本

四、方案 B 详解：GSD + OpenSpec

4.1 安装配置

bash

# 1. 安装 GSD
npx gsd@latest init
# 会在 .claude/commands/gsd/ 生成约 50 个命令文件

# 2. 安装 OpenSpec
npm install -g @fission-ai/openspec@latest
openspec init

关键配置：

GSD 状态持久化：.sillyspec/ 目录
OpenSpec 规格管理：.sillyspec/changes/ 目录
两者通过 Git 共存，互不干扰

4.2 完整工作流

  ┌──────────────────────────────────────────┐
  │  Phase 1: 项目启动（GSD 驱动）            │
  │  /gsd:new-project "构建用户管理系统"        │
  │  → 4 个 agent 并行研究                     │
  │  → Roadmapper 生成路线图                   │
  │  → 写入 .sillyspec/ 目录                   │
  └──────────────┬───────────────────────────┘
                 ▼
  ┌──────────────────────────────────────────┐
  │  Phase 2: 规格精炼（OpenSpec 驱动）        │
  │  /opsx:propose feature-name               │
  │  → 将 GSD 需求转化为结构化 spec             │
  │  → ADDED/MODIFIED/REMOVED delta 格式       │
  └──────────────┬───────────────────────────┘
                 ▼
  ┌──────────────────────────────────────────┐
  │  Phase 3: 任务规划 + 执行（GSD 驱动）       │
  │  /gsd:plan-phase                          │
  │  → XML 原子计划（精确文件路径 + 验证步骤）    │
  │                                          │
  │  /gsd:execute-phase                       │
  │  → 波次并行执行（独立 200K 上下文）          │
  │  → 每个任务原子级 git commit               │
  │  → 自动偏差处理                           │
  └──────────────┬───────────────────────────┘
                 ▼
  ┌──────────────────────────────────────────┐
  │  Phase 4: 验证 + 归档（两者配合）           │
  │  /gsd:verify-work → 人工验证               │
  │  /opsx:verify → 规范对照                   │
  │  /opsx:archive → 规格沉淀                  │
  │  /gsd:complete-milestone                  │
  └──────────────┬───────────────────────────┘
                 ▼
  /gsd:handoff → HANDOFF.json（随时中断恢复）
           下一个需求 🔄

4.3 核心优势

上下文腐烂零容忍：每个任务在全新 200K 上下文中执行
波次并行：独立任务同时跑，依赖任务排队
可中断恢复：HANDOFF.json 保存完整会话状态
目标反向规划：不问"怎么做"，问"什么必须为真"

4.4 注意事项

⚠️ 格式不兼容：GSD 的 .sillyspec/ 和 OpenSpec 的 .sillyspec/changes/ 格式不同。

建议用 Claude agent 做一次性格式转换
或约定 GSD 的 spec 输出直接使用 OpenSpec 结构

⚠️ 分工明确：GSD 管执行状态，OpenSpec 管规格状态，不要让两个工具同时修改同一个 artifact。

4.5 适合场景

✅ 中大型项目、需要自主开发、可中断恢复 ❌ 小型一次性项目（用其中一个就够了）、不使用 Claude Code 的环境

五、方案 C 详解：三者全上

5.1 三层架构

  ┌──────────────────────────────────────────┐
  │            OpenSpec（需求管理层）           │
  │     "改什么、为什么改" — 规范即契约          │
  └──────────────┬───────────────────────────┘
                 │ 规范确定后
                 ▼
  ┌──────────────────────────────────────────┐
  │          Superpowers（工程纪律层）          │
  │     "怎么写才对" — TDD + 审查 + 子代理      │
  └──────────────┬───────────────────────────┘
                 │ 计划确定后
                 ▼
  ┌──────────────────────────────────────────┐
  │            GSD（上下文管理层）              │
  │     "怎么跑不崩" — 波次并行 + 状态恢复      │
  └──────────────────────────────────────────┘

5.2 工作流

bash

# 1. 需求定义
/gsd:new-project "构建 SaaS 平台"
  → GSD 密集发现，生成项目路线图
openspec init
  → OpenSpec 初始化变更结构

# 2. 逐 feature 开发
/opsx:propose "用户认证系统"
  → OpenSpec 生成规范

# Superpowers 自动激活 brainstorming + writing-plans
  → 详细实现计划 + TDD 策略

# 3. 执行（GSD 波次管理）
/gsd:plan-phase
  → 基于 OpenSpec tasks.md 生成 XML 原子计划

/gsd:execute-phase
  → 波次并行，每个任务全新上下文
  → Superpowers TDD 技能约束子代理纪律

# 4. 验证归档
/opsx:verify → /opsx:archive

# 5. 中断恢复
/gsd:handoff → /gsd:continue

5.3 Token 消耗与成本

方案	相对消耗	说明
只用 OpenSpec	1x	轻量
只用 Superpowers	3-5x	子代理消耗
只用 GSD	5-10x	波次并行消耗
Superpowers + OpenSpec	4-6x
GSD + OpenSpec	6-11x
三者全上	8-15x	⚠️ 仅大型长期项目

降低成本技巧：

按需加载 spec：只加载当前 feature 的规范
分层上下文：系统层 < 2K tokens，项目层按需，任务层始终加载
模型降级：规划用 Opus，执行用 Haiku
用 @ 引用文件而非内联内容

5.4 推荐渐进式采用

Week 1: 只用 Superpowers（5 分钟上手）
Week 2: 加入 OpenSpec（1 小时上手）
Week 3: 确认需要更多上下文管理后，加入 GSD

不要一次上三个，从两个开始，按需扩展。

六、方案 D：企业级组合

BMAD + Vibe Kanban + Spec Kit

来自 LinkedIn 实战分享（Rashid Smith）：

  ┌──────────────────────────────────────────┐
  │         BMAD（规划层）                     │
  │  21 个专业 Agent，完整开发生命周期           │
  │  → 快速生成大量上下文                      │
  │  → 裁剪到"防止漂移"的最小集                │
  └──────────────┬───────────────────────────┘
                 │
                 ▼
  ┌──────────────────────────────────────────┐
  │       Spec Kit / OpenSpec（规格层）        │
  │  结构化规范文档                           │
  └──────────────┬───────────────────────────┘
                 │
                 ▼
  ┌──────────────────────────────────────────┐
  │       Vibe Kanban（执行层）                │
  │  看板管理多个 coding agent 并行执行         │
  │  → 可视化进度                             │
  │  → 集成到 VS Code                         │
  └──────────────────────────────────────────┘

关键经验：

"价值不是'用这些工具'，而是它们如何作为更紧密、可重复的循环协同工作。"

七、什么时候简化流程？

场景	完整流程	简化方案
新功能开发	✅ 全走	—
重大重构	✅ 全走	—
改个按钮颜色	—	只走 OpenSpec propose + apply
修 typo	—	直接改
bug 修复	—	只走 Superpowers systematic-debugging + TDD
性能优化	—	OpenSpec propose + Superpowers plan + TDD
一次性小脚本	—	什么都不用，直接写

八、常见问题

Q1: OpenSpec 和 Superpowers 会冲突吗？

不会。 GitHub Issue #780 已确认：两者 skills 都在 .claude/skills/ 下，格式相同，直接并存。触发机制不同（Superpowers 基于任务描述自动激活，OpenSpec 需要显式输入斜杠命令），不会打架。

Q2: GSD 和 OpenSpec 有官方集成吗？

没有。 目前没有官方集成方案，是社区推导的理论组合。核心挑战是格式转换（.sillyspec/ vs .sillyspec/changes/）和状态管理分工。建议用 Claude agent 做一次性转换。

Q3: 三者全上值得吗？

看项目规模。 个人小项目用 Superpowers + OpenSpec 就够了（4-6x Token 消耗）。只有大型长期项目、需要上下文持久化和波次并行时，才值得加入 GSD（总消耗 8-15x）。

Q4: 规范会过时怎么办？

来自 Reddit 真实讨论：

OpenSpec 的 delta 格式（ADDED/MODIFIED/REMOVED）天然支持规范演进
定期用 /opsx:verify 对照验证
规范是"活的文档"，不是写完就锁定的

Q5: SDD 是不是在重蹈 MDD（模型驱动开发）的覆辙？

Martin Fowler 和社区都在讨论这个问题。共识是：

MDD 失败因为代码生成技术不够好
现在的 AI 编码能力已经质变，SDD 的时机不同
关键是不要让规范变成瀑布流的官僚主义——保持流动、迭代

九、一键初始化脚本

bash

#!/bin/bash
# setup-sdd-combo.sh — SDD 组合环境初始化

echo "🔧 安装 OpenSpec..."
npm install -g @fission-ai/openspec@latest

echo "✅ 基础安装完成！"
echo ""
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo " 选择你的组合方案："
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo ""
echo "  方案 A: Superpowers + OpenSpec（推荐个人）"
echo "  方案 B: GSD + OpenSpec（速度优先）"
echo "  方案 C: 三者全上（大型项目）"
echo ""
echo " 使用方法："
echo "  cd your-project"
echo "  openspec init"
echo "  # 然后在 Claude Code 中："
echo "  /plugin marketplace add obra/superpowers-marketplace"
echo "  /plugin install superpowers@superpowers-marketplace"
echo ""
echo " 工作流："
echo "  1. 描述需求 → Superpowers brainstorm"
echo "  2. /opsx:propose → OpenSpec 生成规范"
echo "  3. 审阅确认 → Superpowers plan"
echo "  4. go → Superpowers TDD + 子代理开发"
echo "  5. /opsx:verify → /opsx:archive"

十、参考资源

核心仓库

Superpowers — 99.6K ⭐
OpenSpec — 32.5K ⭐
GSD — 36.4K ⭐
BMad Method — 企业级框架
Vibe Kanban — 并行 Agent 看板

组合相关

OpenSpec #780: 作为 Superpowers 技能包分发 — 官方共存确认
vk-workflow-kit — OpenSpec + Superpowers + Vibe Kanban 组合工具
superpowers-codex — Codex CLI 移植版
OpenSpec Change Manager Skill — MCP Market

深度文章

GSD vs Spec Kit vs OpenSpec vs Taskmaster AI — 四工具深度对比
AI 编程三剑客深度对比与实战指南 — 掘金
6 Best SDD Tools 2026 — Augment Code
SDD frameworks vs AI Plan Mode — Reddit 讨论
Has anyone tried SDD? — Reddit 真实反馈
Superpowers v5.0 发布博客 — 创始人亲自讲解
GSD Complete Beginner's Guide — 入门最佳
Solving Context Rot: GSD vs BMAD vs Taskmaster — 上下文腐烂对比

本文档基于 2026 年 3 月公开资料、GitHub Issues、社区讨论整理。工具更新频繁，建议定期查看官方仓库。

AI 开发规范工具组合使用手册 ​

一、为什么要组合使用？ ​

二、推荐组合方案 ​

方案 A：Superpowers + OpenSpec ⭐（最推荐） ​

方案 B：GSD + OpenSpec（速度优先） ​

方案 C：三者全上（全能型） ​

方案 D：BMAD + Vibe Kanban（企业级） ​

三、方案 A 详解：Superpowers + OpenSpec ​

3.1 安装配置 ​

3.2 完整工作流 ​

3.3 实战示例：修复"随机被登出"bug ​

3.4 v5.0 新特性要点 ​

3.5 Codex CLI 用户 ​

3.6 大模型选择建议 ​

四、方案 B 详解：GSD + OpenSpec ​

4.1 安装配置 ​

4.2 完整工作流 ​

4.3 核心优势 ​

4.4 注意事项 ​

4.5 适合场景 ​

五、方案 C 详解：三者全上 ​

5.1 三层架构 ​

5.2 工作流 ​

5.3 Token 消耗与成本 ​

5.4 推荐渐进式采用 ​

六、方案 D：企业级组合 ​

BMAD + Vibe Kanban + Spec Kit ​

七、什么时候简化流程？ ​

八、常见问题 ​

Q1: OpenSpec 和 Superpowers 会冲突吗？ ​

Q2: GSD 和 OpenSpec 有官方集成吗？ ​

Q3: 三者全上值得吗？ ​

Q4: 规范会过时怎么办？ ​

Q5: SDD 是不是在重蹈 MDD（模型驱动开发）的覆辙？ ​

九、一键初始化脚本 ​

十、参考资源 ​

核心仓库 ​

组合相关 ​

深度文章 ​

AI 开发规范工具组合使用手册

一、为什么要组合使用？

二、推荐组合方案

方案 A：Superpowers + OpenSpec ⭐（最推荐）

方案 B：GSD + OpenSpec（速度优先）

方案 C：三者全上（全能型）

方案 D：BMAD + Vibe Kanban（企业级）

三、方案 A 详解：Superpowers + OpenSpec

3.1 安装配置

3.2 完整工作流

3.3 实战示例：修复"随机被登出"bug

3.4 v5.0 新特性要点

3.5 Codex CLI 用户

3.6 大模型选择建议

四、方案 B 详解：GSD + OpenSpec

4.1 安装配置

4.2 完整工作流

4.3 核心优势

4.4 注意事项

4.5 适合场景

五、方案 C 详解：三者全上

5.1 三层架构

5.2 工作流

5.3 Token 消耗与成本

5.4 推荐渐进式采用

六、方案 D：企业级组合

BMAD + Vibe Kanban + Spec Kit

七、什么时候简化流程？

八、常见问题

Q1: OpenSpec 和 Superpowers 会冲突吗？

Q2: GSD 和 OpenSpec 有官方集成吗？

Q3: 三者全上值得吗？

Q4: 规范会过时怎么办？

Q5: SDD 是不是在重蹈 MDD（模型驱动开发）的覆辙？

九、一键初始化脚本

十、参考资源

核心仓库

组合相关

深度文章