OpenSpec + Superpowers 融合开发：AI 工程化双剑合璧

今天用 Claude Code 开发客户管理的导入导出功能，先试了 OpenSpec，再试了 Superpowers，发现它们根本不是一回事------一个管「想清楚」，一个管「做正确」，合在一起才是完整的工程化闭环。

两个工具，两个层级

很多人把 OpenSpec 和 Superpowers 当成同类工具来比较，其实它们解决的是不同层级的问题。

OpenSpec 是需求契约层。 它的核心理念是 Align before Code------先对齐规格，再写代码。它解决的问题是：做什么、边界在哪、怎么验收。你给它一个功能描述，它帮你生成需求提案、技术设计、规格说明、任务清单这一整套文档。

Superpowers 是施工纪律层。 它的核心理念是 Discipline before Code------纪律先行，编码在后。它解决的问题是：怎么做对、怎么保质、怎么不跑偏。它把 TDD、代码审查、子代理隔离这些工程实践固化成 AI 可执行的工作流。

一句话说清楚：OpenSpec 管「想清楚」，Superpowers 管「做正确」。

对比维度	OpenSpec	Superpowers
核心定位	SDD 规格驱动开发框架	AI 编程工程化工作流框架
核心理念	Align before Code	Discipline before Code
解决层级	定义层：做什么、边界在哪	执行层：怎么做对、怎么保质
开发范式	SDD 规格驱动开发	TDD 测试驱动开发 + 子代理隔离
核心能力	规格文档管理、变更集隔离、基线合并	TDD 强制流程、双阶段代码审查、子代理隔离
核心产出	规格说明书、设计文档、变更记录	单元测试用例、代码审查报告、任务计划

它们不是竞争关系，而是对应 SDD 和 TDD 两大工程范式的互补。

各自的标准流程

OpenSpec：5 步 SDD 闭环

全程通过 /opsx: 斜杠命令驱动，核心是「规格先行，全链路可追溯」。

Explore（需求探索） /opsx:explore --- AI 扫描代码提出问题，人工决策，产出对话级需求共识
Propose（生成提案） /opsx:propose --- AI 自动生成全套规范文档（proposal、design、specs、tasks），人工审批
Apply（执行编码） /opsx:apply --- AI 按任务清单逐项编码，自动标记完成进度
Verify（质量验证） /opsx:verify --- 归档前强制校验，检查功能完整性和代码与规格的一致性
Archive（归档沉淀） /opsx:archive --- 变更集归档，增量规范合并到项目主基线

Superpowers：6 步工程化闭环

全程通过 /superpowers: 斜杠命令驱动，核心是「纪律强制，全流程质量内建」。

Brainstorm（需求澄清） /superpowers:brainstorm --- AI 主动追问业务边界、异常场景、验收标准
Write Plan（任务拆解） /superpowers:write-plan --- 拆分为颗粒度适中、有依赖关系的可执行子任务
Execute Plan（子代理执行） /superpowers:execute-plan --- 每个子任务启动独立 AI 会话，上下文完全隔离
TDD（测试驱动） 子代理执行时强制触发 --- 严格遵循红-绿-重构循环
Code Review（双阶段审查） 子任务完成后自动触发 --- 先审规格合规，再审代码质量
Wrap-up（收尾归档） /superpowers:wrap-up --- 汇总交付物、更新进度台账

独立使用时的局限性

两者单独用都有短板：

OpenSpec 的局限：无强制质量校验、无内置 TDD，代码质量完全依赖人工把控
Superpowers 的局限：无统一规格基线沉淀，需求变更时缺乏可追溯的规范文档

这就是为什么要融合使用。

融合 6 步流程

核心逻辑：OpenSpec 定「蓝图」管基线，Superpowers 守「施工规范」保质量。两者结合形成从需求定义到工程交付的全链路闭环。

复制代码

┌─────────────────────────────────────────────────────────────────┐
│                    融合开发 6 步流程                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. 定规格    2. 补细节    3. 拆路径    4. 做开发    5. 双校验    │
│  OpenSpec    Superpowers  Superpowers  子代理TDD    规格+质量    │
│  propose     brainstorm   write-plan   execute-plan  双审查      │
│                                                                 │
│                                            6. 双归档            │
│                                            wrap-up + archive    │
└─────────────────────────────────────────────────────────────────┘

第 1 步：定规格 --- OpenSpec 锁定需求契约

执行 /opsx:propose 功能名称，AI 自动生成规格说明书、设计文档、验收标准。人工评审确认后，这些文档就是后续所有工作的「硬约束」。

价值：从源头锁定「做什么」，形成可追溯的需求基线，避免后续执行方向跑偏。

第 2 步：补细节 --- Superpowers 深度澄清

执行 /superpowers:brainstorm，基于 OpenSpec 的规格文档，AI 补充业务边界、异常场景、技术实现细节。把静态规格转化为可执行的工程目标。

价值：补齐规格到实现之间的工程细节，缩小理解偏差。

第 3 步：拆路径 --- Superpowers 拆解实施计划

执行 /superpowers:write-plan，对照规格文档，拆分为分层、分模块的可执行子任务，明确交付标准与依赖关系。

价值：把宏观规格拆解为可执行、可验证的原子任务。

第 4 步：做开发 --- 子代理 TDD 落地执行

执行 /superpowers:execute-plan（推荐子代理模式）。每个子任务在独立会话中执行，严格按 TDD 流程开发：先写测试（RED）→ 写最简实现（GREEN）→ 测试通过 → 代码重构（REFACTOR）。

价值：上下文隔离防污染，测试先行保障代码质量，并行执行提升效率。

第 5 步：双校验 --- 规格 + 质量双重审查

子任务完成后自动触发双阶段审查：

合规审查：对照 OpenSpec 规格文档，校验功能完整性、接口一致性、权限匹配
质量审查：校验代码规范、异常处理、安全漏洞、性能隐患

价值：既保证「做对了需求」，又保证「做好了代码」。

第 6 步：双归档 --- 资产沉淀与基线更新

先执行 Superpowers 收尾 /superpowers:wrap-up，汇总执行过程、测试报告、审查记录。再执行 OpenSpec 归档 /opsx:archive 功能名称 --update-specs，将增量规格合并到项目主基线。

价值：既沉淀执行过程的工程资产，又更新项目长期规范基线。

实战：客户管理导入导出

用一个真实案例走一遍融合流程。

背景：基于若依（RuoYi-Vue）框架，给客户管理模块新增 Excel 导入导出功能。最终产出 16 个文件、837 行新增代码、25 个测试用例。

OpenSpec 打头阵

执行 /opsx:explore 客户管理的导入导出功能，AI 自动扫描用户模块的导入导出实现（Controller、Service、前端组件、ExcelUtil），和客户模块的当前状态做对比，识别出 7 个缺失功能点，提出 5 个设计决策问题让我确认：导出是否带筛选、导入是否支持更新、ownerId 怎么处理等。

接着 /opsx:propose，3 分钟生成四件套：proposal.md（需求提案）、design.md（技术设计）、两个 spec.md（导出规格 + 导入规格）、tasks.md（22 个任务清单）。

这一步的价值在于：所有决策都有文档记录，后续 Superpowers 的子代理不用猜我想要什么。

Superpowers 接力执行

拿到 OpenSpec 的规格文档后，用 /superpowers:brainstorm 补充业务边界细节，再用 /superpowers:write-plan 拆解为更细粒度的子任务。

然后 /superpowers:execute-plan 启动子代理并行开发。每个子代理在独立会话中工作，遵循 TDD 流程：先写测试，再写实现。

实际执行的子任务

任务	描述	耗时
测试先行	编写 4 组失败的测试用例	~3 min
数据库菜单	新增权限菜单 SQL	~1 min
实体注解	@Excel 注解调整	~2 min
Service 层	importCustomer 实现	~3 min
Controller 层	3 个端点（导出/导入/模板下载）	~3 min
前端	按钮 + 导入组件	~3 min

踩了几个坑

开发过程中遇到 4 个问题，都不是大坑但都花了时间排查：

Vue 2 组件必须手动注册 ：import 了组件但没写 components: { }，点击按钮无反应且无报错
Maven 模块间编译依赖 ：改了 system 模块的接口，没先 mvn install 就编译 admin 模块
MockMvc 测试中 Excel 内容 ：Mock 文件内容是 "test" 不是有效 Excel，应该用 assertThrows 验证异常
JAR 文件被占用 ：后端进程还在跑就执行 mvn package

这些坑在双校验阶段被发现并修复，而不是等到部署后才暴露。

时间统计

阶段	耗时	占比
Explore 需求探索	~5 min	19%
Propose 生成提案	~3 min	12%
Apply 执行编码	~15 min	58%
Verify 质量验证	~2 min	8%
Archive 归档沉淀	~1 min	4%
总计	~26 min	100%

26 分钟，从需求到归档，全程有文档、有测试、有审查。

融合后的核心价值

全程可追溯

需求有规格、执行有过程、交付有测试、质量有审查。任何一个环节出了问题，都能回溯到对应的文档和决策记录。

质量双保障

规格对齐防方向跑偏------OpenSpec 的 spec.md 定义了「做什么」，Superpowers 的双阶段审查会对照 spec 校验。TDD + 代码审查防代码质量------先写测试再写实现，审查覆盖逻辑正确性和安全漏洞。

资产可复用

OpenSpec 归档后，规格文档合并到项目主基线。下次做类似功能（比如供应商导入导出），可以直接引用客户导入导出的 spec 作为参考，不用从零开始。

灵活可裁剪

不是每个功能都需要走完整 6 步。小改一个字段可以跳过 Propose 直接 Apply，核心模块才走全流程。流程是工具，不是枷锁。

适用节奏建议

根据功能规模选择不同的流程深度：

功能规模	文件数	推荐流程
小功能	1-3 个文件	Explore → Apply → Commit
中功能	4-10 个文件	Explore → Propose → Apply → Verify → Commit
大功能	10+ 个文件	完整融合 6 步流程

小功能走全套流程反而拖慢节奏，大功能跳过规格文档则容易返工。根据实际情况灵活裁剪，才是工程化的真正含义。

写在最后

OpenSpec 和 Superpowers 不是竞争关系，而是 AI 编程工程化的上下两层。OpenSpec 解决「做什么、做成什么样」的需求定义问题，Superpowers 解决「怎么做、怎么做好」的执行质量问题。

两者结合，就是 SDD + TDD 的完整工程化闭环：先用规格锁定需求，再用纪律保障执行，最后用归档沉淀资产。

用一句话总结：OpenSpec 定蓝图，Superpowers 守规范，合在一起才是真正的 AI 工程化开发。

OpenSpec + Superpowers 融合开发：AI 工程化双剑合璧