Claude Code + OpenSpec + Superpowers 协同开发实践指南

原文链接：https://mp.weixin.qq.com/s/hkM8j7PefkEpj5zQV7Tt3Q 来源：职场向上生长力 发布时间：2026-06-01

摘要

OpenSpec + Superpowers 的协同开发模式解决了 SDD 的两个核心问题——"做什么"和"怎么做"。OpenSpec 管需求规范和可追溯性，Superpowers 管子代理驱动的执行纪律。两者上下游关系，不是替代关系。文章给出了完整的五阶段工作流 + 三个常见误区避坑。

核心分工

维度	OpenSpec	Superpowers
解决的问题	"做什么"——需求规范	"怎么做"——执行纪律
核心能力	结构化规范文档 + 可追溯变更管理	brainstorming → writing-plans → subagent TDD → 双阶段 review
输出	proposal.md / design.md / specs/ / tasks.md	执行计划 + 代码 + 测试 + 审查报告
角色	定义"正确的目标"	规划"到达目标的最优路径"

OpenSpec：解决"做什么"

Fission-AI 团队开源，核心口号："先对齐规格，再写代码。"

工作流：propose（提案）→ apply（实施）→ archive（归档）

解决四个问题：

1. 需求对齐：proposal.md / design.md / specs/ / tasks.md 四份结构化文档
2. 规范可追溯性：changes/ 目录独立管理变更
3. 架构决策固化：design.md 持久化技术方案和决策理由
4. 团队协作：统一规范格式减少跨团队沟通成本

Superpowers：解决"怎么做"

Claude Code 核心开发者维护的 20+ 可组合 Skill 开发纪律框架。

核心机制：SDD（Subagent-Driven Development）——每个任务三个角色：

• Implementer：写代码和测试
• Spec Compliance Reviewer：逐行对比代码和规格是否一致
• Code Quality Reviewer：规格通过后审查代码质量

用子代理专业分工替代"一人多职"导致的上下文切换和质量依赖个人能力。

关键设计：writing-plans 里每个 step 2-5 分钟粒度，强制 TDD 在子 agent 内部执行而非主对话层。

完整五阶段工作流

阶段 1：OpenSpec 需求对齐（propose）
    ↓
阶段 2：Superpowers 头脑风暴（brainstorming，苏格拉底式追问）
    ↓
阶段 3：Superpowers 编写计划（writing-plans，2-5 分钟粒度）
    ↓
阶段 4：Superpowers 子代理执行（subagent TDD + 双阶段 review）
    ↓
阶段 5：OpenSpec 归档（archive）

三个常见误区

误区一：绕过 Superpowers 直接写代码

觉得 brainstorming 太慢，跳过直接写。短期快几分钟，长期返工和 Bug 修复时间数倍于节省的时间。完整流程虽然单次耗时长，但一次性通过率明显提升。

误区二：混淆 OpenSpec 的 specs 和 Superpowers 的 plans

OpenSpec 的 specs/ 描述功能的静态行为（API 定义、数据模型、验收场景），Superpowers 的 plans 产出动态执行步骤（先做什么、再做什么、每步的验收标准）。两者是上下游关系，不是替代。

误区三：做全栈时设计靠文字描述

纯文本 design.md 很难准确传递 UI 意图，AI 对文字理解有偏差，返工成本甚至高于后端逻辑。正确做法：让 Claude Code 生成独立的 HTML 原型文件，作为"可执行的 UI 规范"纳入 OpenSpec 变更目录统一版本管理。

实践建议

• 子代理执行选型：无脑选 Subagent-Driven，除非只有 1-2 个简单 Task / 高度耦合 / 调试探索 / Token 预算非常有限
• 整个流程可打包成 Skill，后续每个需求都走完整周期
• 规范和纪律是有意为之的"减速"，但换来的是可追溯的"确定性"