OpenSpec vs Superpowers — Claude Code CLI 下的 SDD 框架选择指南

前言

2025-2026 年，AI 编码助手的能力突飞猛进，但一个老问题始终没解决：每个新会话都要重新解释项目结构、技术栈、规范，而且 AI 经常写出和期望不符的代码。

Spec-Driven Development（SDD） 应运而生——把规范作为真相源（source of truth），让人和 AI 在写代码前先对齐。其中最具代表性的两个框架是 OpenSpec（61.3k ⭐）和 Superpowers（256k ⭐）。

本文聚焦它们在 Claude Code CLI 中的实际使用，不聊概念，只讲怎么装、怎么用、怎么选。

---

框架对比速览

维度	OpenSpec	Superpowers
本质	Node.js CLI 工具	Claude Code 插件
安装方式	npm install -g @fission-ai/openspec	/plugin install superpowers@...
哲学	规范即真理	工作流即真理
触发模型	用户输入 /opsx:* 斜杠命令	技能自动匹配上下文触发
TDD	可选	强制内置
子 agent	无	一等公民
扩展方式	官方 schema / 自定义	自己写 SKILL.md
Stars	61.3k	256k

---

一、OpenSpec — 规范驱动开发

安装

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init

要求 Node.js 20.19.0+，Windows 可用。

两个 Profile

默认 core profile（装完即用）：

命令	用途
/opsx:propose <name>	创建变更 + 一次生成所有规划文档（最常用）
/opsx:explore	需求模糊时探索性对话
/opsx:apply	按 tasks.md 实施代码
/opsx:sync	delta spec 合并到主 spec
/opsx:archive	归档变更

日常流程：

/opsx:propose add-dark-mode
→ 自动生成 proposal.md / specs/ / design.md / tasks.md

/opsx:apply
→ 逐 task 实施

/opsx:archive
→ 归档至 archive/，自动同步 specs

Expanded workflow（需 openspec config profile 切换）：

额外增加 new、continue、ff、verify、bulk-archive、onboard 等命令，适合需要分步审核或首次入门的场景。

目录结构

openspec/
├── specs/               ← 真相源（系统当前行为）
│   ├── auth/spec.md
│   └── payments/spec.md
└── changes/             ← 进行中的变更
    ├── add-dark-mode/
    │   ├── proposal.md
    │   ├── specs/
    │   ├── design.md
    │   └── tasks.md
    └── archive/         ← 已完成变更

适合场景

• 团队协作，需要需求→代码可追溯
• 合规/审计项目
• 绿场或棕场项目增量开发
• 不需要严格的 TDD 强制

---

二、Superpowers — 工作流驱动开发

安装

/plugin install superpowers@claude-plugins-official

装完即生效，不需要记住任何命令。

7 阶段自动工作流

阶段	触发条件	Claude 的行为
Brainstorming	你提了模糊想法	苏格拉底式提问，理清需求
Git Worktrees	设计确认	创建隔离分支，验证基线测试
Writing Plans	设计通过	分解为 2-5 分钟任务
Subagent-Driven Dev	计划就绪	每任务一个子 agent，两级审查
TDD	写代码时	RED-GREEN-REFACTOR 强制
Code Review	任务完成	按严重度分级报告
Finish Branch	全部完成	提供 merge/PR/丢弃 选项

整个过程中你只需要正常说话：

你: 我想加一个支付小部件
Claude: （自动触发 Brainstorming）你偏向 Stripe 还是支付宝？...
你: Stripe，简单结账
Claude: （自动进入后续流程，几小时后可能已经写好了）

内置 14+ Skills

类别	Skills
规划	brainstorming, writing-plans, executing-plans
测试	test-driven-development
调试	systematic-debugging, verification-before-completion
协作	dispatching-parallel-agents, requesting-code-review, receiving-code-review
Git	using-git-worktrees, finishing-a-development-branch
元技能	writing-skills, using-superpowers

适合场景

• 个人项目或小团队
• 严格 TDD 信徒
• 需要长时间自主运行的场景
• 不希望记忆任何命令的开发者

---

三、两者组合（最强方案）

核心理念

OpenSpec     → 规划层（WHAT）—— 产出规范、方案、任务清单
                  ↓ 手递手
Superpowers  → 执行层（HOW）—— 用 TDD + 子 agent + 审查 执行 task 清单

完整操作步骤

Step 0：前置条件

确保项目已初始化：

# OpenSpec 安装
npm install -g @fission-ai/openspec@latest
cd your-project
openspec init    # 选择 Claude Code，使用默认 core profile

# Superpowers 安装（在 Claude Code 内）
/plugin install superpowers@claude-plugins-official

Step 1：OpenSpec 规划 → 产出规范

在 Claude Code 中输入：

/opsx:propose add-payment-widget

Claude 会做什么：

✅ Created openspec/changes/add-payment-widget/
   ✓ proposal.md         — 为什么做、变更范围、不做会怎样
   ✓ specs/payment/spec.md — 功能需求、边界条件、场景
   ✓ design.md            — 技术选型、架构图、数据结构
   ✓ tasks.md             — 实施清单

此时可以审查每个文件，用 /opsx:update 修改，满意了再继续。

Step 2：Superpowers 执行 → 代码落地

关键：不要用 /opsx:apply，不要用 OpenSpec 的执行模式。

直接对 Claude 说一句话（必须包含关键词"执行"）：

执行 openspec/changes/add-payment-widget/tasks.md，
按 Superpowers 工作流来，用 TDD，不要重新规划。

Claude 会依次自动触发：

① Brainstorming（自动跳过已有的规范，只确认任务理解）
② Git Worktree → 创建独立分支，跑测试确保基线为绿
③ Writing Plans → 将 tasks 进一步分解（如有必要）
④ Subagent-Driven Dev → 每个 task 一个子 agent：
     Task 1: [TDD] RED → 写测试 → 看它挂 → GREEN → 通过 → REFACTOR
     Task 2: [TDD] RED → 写测试 → 看它挂 → GREEN → 通过 → REFACTOR
     ...
⑤ Code Review → 检查实现是否符合 spec，给出 CRITICAL/WARNING/SUGGESTION
⑥ Finish Branch → 验证测试，给出合并选项

你只需要在 Brainstorming 阶段偶尔回答几个确认性问题，其余时间 Claude 自主工作。

Step 3：OpenSpec 归档 → 更新真理源

审查 Superpowers 完成的代码，没问题后：

/opsx:archive add-payment-widget

Claude：

✓ 检查：所有 tasks 已完成
✓ 同步：delta spec 合并至 openspec/specs/
✓ 归档：已移至 openspec/changes/archive/YYYY-MM-DD-add-payment-widget/
Ready for next feature.

---

四、实际案例：搭建代码审查规范体系

背景

项目需要建立一套代码审查规范：定义审查角色、流程、清单、标准。用 OpenSpec 承载规范文件，后续每次审查时引用。

操作步骤

Step 1：创建 code-review 变更

/opsx:propose code-review

Claude 自动生成 4 个文件。修改 proposal.md，明确你的目标：

# proposal.md

## 为什么做
团队缺乏统一的代码审查标准，导致每次审查质量参差不齐。

## 变更范围
- ✅ 审查角色定义（谁审查谁、职责）
- ✅ 审查触发条件（什么时候触发审查）
- ✅ 审查 SLA（响应时间、通过条件）
- ✅ 通用审查清单（安全、性能、风格）
- ✅ 各模块专项审查清单
- ✅ 意见分级标准（CRITICAL / WARNING / SUGGESTION）
- ❌ 不考虑自动化审查工具集成

Step 2：细化 spec 文件

审查 specs/review-process/spec.md：

# review-process/spec.md

## Requirement 1: 审查角色
- 审查者（Reviewer）：有模块上下文的人，负责审查
- 被审查者（Author）：提交变更的人，负责响应意见
- 审批者（Approver）：有合并权限的人，负责最终决定

## Scenario 1.1: 普通功能 PR
Given: 普通功能变更提交 PR
When: 该 PR 涉及核心模块
Then: 必须由至少 1 名审查者 + 1 名审批者确认
And: 审查 SLA 为 4 个工作小时
And: 所有 CRITICAL 级别意见必须解决后才能合并

## Requirement 2: 意见分级
- CRITICAL：必须解决，阻塞合并
- WARNING：建议解决，不阻塞但需记录
- SUGGESTION：可选的改进建议

审查 specs/review-checklists/spec.md：

# review-checklists/spec.md

## Requirement 1: 通用审查项
- 安全：是否存在 SQL 注入、XSS、权限绕过风险
- 性能：是否有 N+1 查询、无索引查询
- 可读性：命名是否清晰、函数是否过大
- 测试：关键路径是否有测试覆盖

## Requirement 2: 专项审查项
- Java 模块：异常处理是否规范、事务边界是否正确
- 前端模块：有无内存泄漏、样式是否与设计稿一致

## Scenario 2.1: 安全相关审查
Given: 涉及用户输入的代码变更
When: 审查者检查代码
Then: 必须检查输入校验、输出编码、权限验证

design.md

# design.md

## 技术方案
- 规范文件格式：Markdown，存放在 openspec/specs/ 下

## 文件结构
openspec/specs/
├── review-process/spec.md      # 流程规范
└── review-checklists/spec.md   # 审查清单

## 实施路径
1. 编写 review-process/spec.md
2. 编写 review-checklists/spec.md
3. 验证：每个 spec 至少包含 1 个 requirement + 1 个 scenario

Step 4：验证 → 归档

/opsx:archive code-review

Step 5：后续实际审查

/opsx:propose review-user-auth-module

在 spec 中引用已有规范：

引用：../../../specs/review-process/spec.md
引用：../../../specs/review-checklists/spec.md

## 专用审查项
- [ ] Token 有效期及刷新逻辑是否符合安全标准
- [ ] 密码加密方式是否符合项目规范
- [ ] 登录失败次数限制是否实现

执行：

# 方式一：直接按 tasks.md 审查
/opsx:apply

# 方式二（推荐）：触发 Superpowers review skill
执行这个 change，按 requesting-code-review skill 流程来，
每项给出 CRITICAL/WARNING/SUGGESTION 评级

归档：

/opsx:archive review-user-auth-module

---

五、小结

	OpenSpec	Superpowers
心智负担	需记忆几个斜杠命令	无需记忆任何命令
规范可追溯	✅ 文件进 git	❌ 无独立规范文件
TDD 强制	❌ 可选	✅ 内置强制
子 agent	❌ 不支持	✅ 一等支持
适合团队	✅	⚠️ Solo 体验更好
学习曲线	低（5 分钟上手）	中（需适应自动工作流）

最终建议： Superpowers 适合个人日常开发，OpenSpec 适合需要规范追溯的团队协作，两者结合是大项目的最佳实践。