OpenSpec + Superpowers 实战：从需求对齐到代码交付的 SDD+TDD 双驱动工作流

最新推荐文章于 2026-07-28 10:23:10 发布

原创最新推荐文章于 2026-07-28 10:23:10 发布 · 527 阅读

1 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

编程新范式：AI智能体架构设计与实战

在这里插入图片描述

Vibe Coding 圈里最受关注的两件套组合：OpenSpec 负责"对齐需求"，Superpowers 负责"保证质量"。它们恰好补上了 AI 编程最头疼的两个短板——但组合使用的正确姿势，并不是简单地叠加两套工具。

一、从一次真实的需求漂移说起

假设这样一个场景：你在对话框里告诉 Claude Code——“给用户中心加一个导出功能，支持导出近 30 天的操作记录”。Claude 开始写代码，你去开会，回来一看，它把导出格式做成了 Excel，还顺手给每列加了筛选器，甚至引入了一个新的 xlsx 处理库。

功能是有了，但你要的只是一个 CSV 下载按钮。

三天后 PM 来问：当初为什么选 Excel 格式？你翻了半小时聊天记录，发现根本没有记录——那个决策在对话里一闪而过，AI 自己做的。

这个场景里有两个独立的问题，常常被混为一谈：

第一个问题是需求漂移。 AI 没有恶意，它只是在补全你没有说清楚的部分。你说"导出"，它根据训练数据推断"导出通常是 Excel"，然后就做了。真正的问题是：需求没有一个可以被双方确认的载体，只有聊天记录。

第二个问题是质量失控。 即便需求对齐了，AI 产出的代码也经常缺少边界处理——导出 10 万行时内存会怎样？用户浏览器关了下载会怎样？这些问题不是 AI 不懂，而是没有流程强制它在写代码之前先想清楚。

这两个问题的根源是同一件事：AI 编程缺少工程化的流程管控。 传统开发有 PRD 评审、技术设计评审、Code Review 来兜底，Vibe Coding 把这些全压缩进了聊天窗口，然后期望 AI 自己补全。

OpenSpec 和 Superpowers 各自解决其中一个问题。

二、两个工具，各管一段

OpenSpec：在写代码之前，先对齐要做什么

OpenSpec 是 Fission AI 推出的规格驱动开发框架，核心思路只有一句话：在 AI 开始写代码之前，先产出一份双方都同意的规格文档。

它的工作方式是给每个功能变更建立一个独立文件夹，里面包含四类文档：

文件	核心问题	传统开发的对应物
`proposal.md`	为什么做，做什么，不做什么	需求文档
`specs/`	行为规格，用 GIVEN/WHEN/THEN 描述场景	验收标准
`design.md`	技术实现方案	技术设计文档
`tasks.md`	实现任务拆解	Sprint Backlog

其中最关键的是 specs/ 里的 Delta Spec 机制。Delta Spec 描述的不是系统的全量状态，而是这次变更在哪里新增、修改、删除了什么行为。这使得 OpenSpec 对存量代码库（brownfield）特别友好——你不需要先把整个系统的规格写完才能开始用。

OpenSpec 有意设计为"流动而非刚性"的——它不要求你按顺序填完所有文档才能开始写代码，任何文件可以随时更新，理解加深了就修改 spec，这是它区别于传统重型规格框架的关键。

目前 OpenSpec 支持包括 Claude Code、Cursor、GitHub Copilot 在内的 20 余种 AI 编程工具，通过 slash command 工作，不绑定任何特定 IDE 或模型。

Superpowers：在写代码的过程中，保证怎么做

Superpowers 是 Jesse Vincent 开发的 AI 编程 Agent 技能体系。Jesse Vincent 是开源工单系统 Request Tracker 的作者，也曾担任 Perl 5 的发布负责人，联合创办了机械键盘公司 Keyboardio——他的背景决定了 Superpowers 的气质：流程纪律、自动化测试、文档化，这些是他认为不可谈判的工程底线。

Superpowers 的核心判断是：AI 编程质量差的根源不是能力不够，而是缺乏职业纪律。 Claude 知道应该先写测试，知道应该处理边界条件，但没有东西强制它这么做。Superpowers 要做的就是把这套纪律编码成可执行的技能文件。

它的工作方式是一套可组合的技能（Skills）体系，每个技能对应一个开发阶段，在对应场景下自动触发：

技能	触发时机	实质作用
`brainstorming`	检测到新需求	反向提问澄清边界，产出技术 Design Doc
`writing-plans`	设计确认后	将设计拆解为 2-5 分钟粒度的任务
`subagent-driven-development`	Plan 确认后	子代理逐任务执行，强制 TDD
`test-driven-development`	每个实现任务内	红灯→绿灯→重构，不跳步
`requesting-code-review`	每个任务完成后	对照 Plan 审查，Critical 问题阻塞继续
`finishing-a-development-branch`	全部完成后	验证、PR 决策、清理工作区

技能不是建议，它们是强制执行的。Jesse Vincent 在设计时明确说明，目标是让 Agent "像一个充满热情但缺乏判断力的初级工程师"也能按流程执行——这描述的其实是任何 AI Agent 的现状。

三、为什么两件套比单用更有价值

单独使用 OpenSpec 或 Superpowers，各自有明确的短板。

单用 OpenSpec，需求规格有了，但 /opsx:apply 阶段直接调用模型基础编码能力，没有强制的测试覆盖和阶段性 Code Review。规格写得再好，代码质量还是随机的。

单用 Superpowers，brainstorming 产出的 Design Doc 质量很高，但这些文档保存在本地，没有系统化的版本管理和归档。更重要的是，Superpowers 的状态管理是文本化的——任务完成后靠在文档里打勾来追踪进度，但 Agent 有时会忘记打勾，下次断点恢复时不得不重新扫描整个代码库来确认当前状态，这会消耗大量额外 Token。

组合使用后，两个工具的职责边界变得清晰：

OpenSpec  ←→  "做什么"的载体（Spec 生命周期、归档、版本追溯）
Superpowers ←→  "怎么做好"的执行器（技术设计、TDD 实现、Code Review）

它们的衔接点在于：OpenSpec 产出的 proposal.md 和 design.md 作为 Superpowers brainstorming 的输入，Superpowers 在技术深挖中发现的需求盲区反写回 OpenSpec 的 delta spec，形成闭环。

四、完整工作流：从需求到交付

整体流程概览

第一步：OpenSpec 产出 Spec

安装：

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init   # 自动检测已有 AI 工具配置，按需初始化

初始化后在 AI 终端发起提案：

/opsx:propose "为用户中心增加操作记录导出功能，支持导出近 30 天数据，CSV 格式"

生成结果：

openspec/changes/export-audit-log/
├── proposal.md          # 变更动机、范围边界（包括"不做什么"）
├── specs/
│   ├── export-format.md     # 导出格式规范（GIVEN/WHEN/THEN）
│   ├── data-range.md        # 数据范围规范
│   └── error-handling.md    # 异常处理规范
├── design.md            # 技术实现方案
└── tasks.md             # 实现任务列表

这一步的关键不是生成文档，而是 Review 环节。 重点检查两件事：proposal.md 里"不做什么"（out of scope）是否明确——这是防止需求漂移的核心；specs/ 里的 GIVEN/WHEN/THEN 场景是否覆盖了你能想到的边界情况。

第二步：Superpowers 技术深挖

Spec 确认后，让 Superpowers 做技术层面的深度设计：

读取 openspec/changes/export-audit-log/ 下所有文档，
使用 superpowers brainstorming，针对这个变更做技术设计。

这一步会发生两件重要的事：

其一，Superpowers 会反向提问。对于导出功能，它会问：100 万行数据时用流式导出还是分页导出？导出期间用户关闭浏览器怎么办？并发导出请求有没有限流？这些问题在写代码之前必须有答案。

其二，它会发现 OpenSpec 遗漏的场景并回写。实际场景中，一个看似简单的导出功能，brainstorming 后经常能发现 4-6 个规格盲区：

发现的盲区	根源
导出文件名规则（含时区）	spec 只说"CSV"，没说文件名
空数据时的导出行为	GIVEN 场景没有覆盖空状态
大数据量时的超时处理	性能边界没有写进 spec
权限不足时的错误提示文案	错误处理 spec 只写了状态码

这是两件套最重要的协作价值：OpenSpec 定义需求，Superpowers 在实现前帮你找出需求里的坑。

第三步：写实现计划并执行

使用 superpowers writing-plans，基于 Design Doc 创建实现计划。

Plan 生成后，Superpowers 创建 feature 分支，进入 subagent-driven-development 阶段。这个过程是自动的——每个子代理接收一个任务，强制先写测试，测试红灯通过后再写实现，实现通过后重构，最后提交。每个任务完成后触发 code review，Critical 问题会阻塞流程继续。

整个过程可能持续 30-60 分钟，期间不需要人工干预。

第四步：验证与归档

# 验证实现与 Spec 的一致性
openspec verify-change export-audit-log

# Superpowers 收尾（验证测试、做 PR 决策）
# 在 AI 终端触发 superpowers finishing-a-development-branch

# 归档变更
/opsx:archive export-audit-log

归档后，这次变更的完整上下文——为什么做、做什么、怎么做、做完验证——都保存在 openspec/changes/archive/ 里，三个月后还能追溯当初的设计决策。

五、真实场景：存量系统加功能（Brownfield）

前面的流程在新项目上直觉清晰，但更多人面对的是存量系统。这里用一个更贴近真实的场景展示两件套在 brownfield 场景下的价值。

场景： 一个运行了 2 年的 SaaS 产品，要给已有的用户权限模块增加"临时授权"功能——允许管理员给用户设置一个有效期，到期自动失效。

痛点在哪： 权限模块已有复杂的继承关系，临时授权需要插入现有的鉴权链路。如果只是扔给 AI 一句话，它大概率会在合适的地方插入一段代码，但不会意识到"临时授权到期时，已经建立的 session 怎么办"——因为这个问题在鉴权链路里藏得很深。

两件套的作用：

/opsx:propose 生成的 proposal.md 会强制描述与现有权限模块的边界关系——哪些现有行为是 MODIFIED，哪些是 ADDED，哪些明确不变。这一步让 AI 和你都必须面对"临时授权如何与现有 session 交互"这个问题，而不是绕开它。

Superpowers 的 brainstorming 则会系统性地追问：临时权限到期时，正在进行的操作如何处理？权限变更事件如何通知依赖方？如果授权创建者本身权限被撤销，已创建的临时授权怎么处理？

这些问题在 brownfield 场景下尤其重要，因为每一个都可能牵连到现有系统的某个角落。

关键结论： 两件套对存量系统的价值甚至高于新项目，因为存量系统里有更多"隐形的需求约束"需要被显式化。

六、自动化方案：用 Comet 串联全流程

手动切换 OpenSpec 和 Superpowers 需要记住一批命令，更重要的是，两个工具之间的文档同步和状态流转需要人工维护。Comet（@rpamis/comet）的价值正是在这里——它解决的不只是"记命令"的问题，而是解决了一个更深层的工程问题。

OpenSpec 和 Superpowers 各自的状态追踪都有弱点：OpenSpec 的 tasks.md 是静态 Markdown，Superpowers 的 Plan 文档靠 Agent 打勾来追踪进度——而 Agent 常常忘记打勾。这导致断点恢复时，Agent 不知道自己做到哪了，只能重新扫描代码库核验，浪费大量 Token。

Comet 用脚本化状态机替代了文本化进度追踪，每个阶段的状态由脚本写入 .comet.yaml，不依赖 Agent 自己记录，断点恢复只需一个命令：

/comet   # 自动检测当前 Spec 状态，从断点继续

Comet 五阶段流水线

Guard 脚本是 Comet 最关键的设计——Agent 说"做完了"不算数，脚本检测通过才算。这把"完成"的定义从对话里的文字变成了可验证的事实。

快捷路径

Comet 针对常见场景提供了精简流程：

/comet          → 完整五阶段（新功能、中等以上改动）
/comet-hotfix   → 跳过 Design，适合 Bug 修复
/comet-tweak    → 跳过 Design + 完整 Build 审查，适合配置调整

七、使用决策：什么时候上，上到哪一层

工具是否值得用，取决于它解决的问题的代价是否高于工具本身的学习成本。这里给出一个实用的判断框架：

需要上 OpenSpec 的信号：

需求在对话里说不清楚，AI 经常理解跑偏
项目有多人协作，需要共享需求上下文
变更涉及现有系统的核心链路（brownfield）
半个月后需要能追溯"当初为什么这么设计"

在 OpenSpec 基础上加 Superpowers 的信号：

功能涉及多个文件，代码质量难以靠对话口头约定
有边界条件处理要求（并发、容量、异常路径）
代码会进入生产环境，需要测试覆盖

在两者基础上加 Comet 的信号：

任务会跨越多个 Session（今天做不完）
手动维护两套工具的文档同步让你感到负担
团队多人使用同一套工作流

不需要全套的场景： 小改动（< 5 个文件）、文案调整、个人实验项目，直接用 /comet-tweak 或者裸 Claude Code 即可。工具应该在它能产生价值的地方出现，而不是无差别铺开。

八、三工具横向对比

维度	OpenSpec	Superpowers	Comet
解决的核心问题	需求漂移	代码质量失控	两者间的状态同步
核心理念	SDD：先对齐再动手	TDD：先测试再编码	脚本化状态机
安装方式	`npm install -g @fission-ai/openspec`	Claude Code Plugin 市场	`npm install -g @rpamis/comet`
是否开源	开源 MIT	开源 MIT	开源
学习成本	低（3 条核心命令）	中（需理解 Skill 触发机制）	低（1 条主命令）
适用范围	所有 AI 编程工具（20+）	主要针对 Claude Code	Claude Code 为主
最佳搭档	+Superpowers	+OpenSpec	=上述两者整合

九、一些值得注意的使用细节

关于 OpenSpec 的"流动性"设计。 它的设计哲学是"不设强制阶段门"——你可以在任意阶段更新任意文档，先写 design 再补 specs 也可以。但实际使用中，建议在 proposal.md 确认前不要让 AI 开始写代码，因为"为什么做"不清楚的时候，"怎么做"的讨论容易跑偏。

关于上下文管理。 发起 propose 前建议清空对话上下文（/clear）。每个 Change 应该是独立的对话 Session。在一个 Session 里处理多个变更是常见错误，会导致 AI 把不同需求的上下文混在一起。

关于模型选择。 brainstorming 阶段对推理能力要求较高，用推理能力较弱的模型可能导致设计不够深入。实现阶段则更注重代码能力，可以根据项目需要调整。

关于 Git 分支。 Superpowers 默认创建 feature 分支，但后续合并需要手动处理。不要在主分支上直接运行完整流程，否则出现问题时回滚代价较高。