一：一页结论
- Superpowers 更像 AI 编程助手上的工程工作流与技能系统，重点是把澄清需求、写计划、执行任务、TDD、review、验证这些动作流程化。
- OpenSpec 更像轻量 spec-driven framework，重点是把变更意图、设计方案、任务拆解和 spec delta 沉淀进代码仓。
- Spec Kit 更像规范驱动开发工具箱 ，从 constitution、spec、clarify、plan、tasks 到 implement，方法论最完整。
我的判断是：三者并不是完全同类产品。
二：三者核心对比
| 对比维度 | Superpowers | OpenSpec | Spec Kit |
|---|---|---|---|
| 核心定位 | AI 编程助手的工程工作流与技能系统 | 轻量 spec-driven framework | 规范驱动开发 toolkit |
| 主要解决的问题 | AI 如何更稳地完成开发任务 | 这次改动为什么做、改什么、影响哪些需求 | 如何把规范驱动开发做成一套完整流程 |
| 更偏哪一层 | 执行层 | 规划与变更管理层 | 方法论与流程框架层 |
| 主要产物 | skills、commands、hooks、workflow | specs、changes、proposal、design、tasks、spec delta | constitution、spec、plan、tasks、analyze、implement |
| 官方强调点 | TDD、review、subagent、workflow discipline | brownfield-first、specs live in code、lightweight | constitution、clarify、plan、analyze、implement |
| 安装 / 接入方式 | 支持 Claude Code、Cursor、Codex、OpenCode、Gemini CLI；其中 Claude Code、Cursor 接入更顺，Codex、OpenCode 有 manual setup 路径 | 面向多工具，强调 universal、open source、no API keys、no MCP | 通过 spec-driven development 流程与模板落地 |
| 更适合什么团队问题 | AI 代码质量不稳、任务执行容易跑偏、缺少工程约束 | 需求意图容易丢失、多人协作时缺少中间层资产 | 想建立统一的规范驱动开发制度 |
| 对前端团队的直接价值 | 强化 TDD、review、验证，减少遗漏 UI/交互细节 | 让需求、设计与代码变更之间更可追踪 | 把团队原则、规格、计划、任务体系化 |
| 适合的项目类型 | 日常迭代、中等到复杂需求、希望提升 AI 执行质量的项目 | 存量项目、复杂业务流、设计系统升级、跨页面改造 | 新项目、组织级流程建设、统一方法论落地 |
| 主要优势 | 更接近执行现场，能直接改善开发动作 | 轻量、适合 brownfield、多工具共享 spec 资产 | 方法论完整，适合制度化推广 |
| 主要限制 | 不同平台接入成熟度不同；spec 沉淀不是核心卖点 | 更偏规划表达，不是执行纪律工具 | 流程更重，接入成本更高 |
| 我的建议 | 如果目标是先提升 AI 写码质量，优先试点 | 如果目标是沉淀跨工具共享的规格资产，优先试点 | 如果目标是建立组织级规范流程，优先试点 |
三：Superpowers 到底是什么
按照官方仓库定义，Superpowers 是一套构建在 composable skills 之上的完整软件开发工作流。它不是单纯的 prompt 集合，而是把一系列工程动作做成默认流程。
官方 workflow 重点包括：
- brainstorming
- writing plans
- subagent-driven development / executing plans
- test-driven development
- requesting code review
- finishing branch
所以它更像执行层和工程纪律层，而不是把规格文档长期沉淀为仓库资产的系统。
一个需要明确的点：Superpowers 并不只偏 Claude Code，根据 obra/superpowers 官方仓库在 2026-03-19 的安装说明，Superpowers 当前支持的环境包括：
- Claude Code
- Cursor
- Codex
- OpenCode
- Gemini CLI
更准确的表述应该是：
Claude Code和Cursor有更顺滑的插件市场安装路径Codex和OpenCode也支持，但官方说明里属于 manual setup 路径
因此，Superpowers 不是只支持 Claude Code 的方案 ，而是一个覆盖多代理/多 CLI 环境的工作流系统，只是不同平台的接入成熟度和安装方式不同。
四：从前端团队视角看价值
| 视角 | Superpowers | OpenSpec | Spec Kit |
|---|---|---|---|
| 前端最受益的点 | 把澄清、计划、执行、测试、review 流程化 | 把需求意图和设计约束沉淀进仓库 | 把规范驱动开发制度化 |
| 特别适合的前端场景 | 复杂交互、状态较多的页面、需要补测试的需求 | 跨页面流程改造、组件库升级、存量项目治理 | 新项目启动、团队流程统一 |
| 能减少的典型问题 | 漏空态、漏报错态、测试缺失、实现跑偏 | "为什么这么改"说不清、评审只剩代码 diff | 团队标准不统一、流程因人而异 |
| 代价 | 需要团队接受更强的工程纪律 | 需要维护 spec 资产 | 需要接受更完整、更重的流程 |
4.1 关键判断：它们更可能是互补，不一定是替代
基于官方资料，我更倾向于把它们理解为两个层面：
- Spec 层：OpenSpec / Spec Kit
- Execution 层 ：Superpowers
也就是说，更成熟的做法可能是： - 用 OpenSpec 或 Spec Kit 定义需求、约束、任务和验收标准
- 用 Superpowers 提升执行质量、测试纪律、review 节点和并行开发能力
4.2 给前端研发团队的建议
| 团队情况 | 更建议优先看什么 | 原因 |
|---|---|---|
| 团队主要使用 Claude Code | Superpowers | 最容易直接改善日常开发动作和 AI 执行质量 |
| 团队主要使用 Cursor 或 Codex | Superpowers | 也支持，但要提前评估 manual setup 或平台接入差异的维护成本 |
| 团队是混合 agent 环境 | OpenSpec | 更适合作为跨工具共享的 spec 层 |
| 团队目标是建立统一开发制度 | Spec Kit | 更接近组织级方法论和标准流程 |
五：最终判断
| 如果目标是...... | 更建议优先看 |
|---|---|
| 让 AI 更像一个靠谱工程师 | Superpowers |
| 让需求意图长期沉淀在仓库里 | OpenSpec |
| 建立规范驱动开发的方法论体系 | Spec Kit |
对多数成熟前端团队而言，更现实的顺序通常是：
- 先解决执行质量问题
- 再解决规格沉淀问题
- 最后再考虑是否上升为组织级方法论
六：参考资料
- Superpowers 官方仓库：https://github.com/obra/superpowers
- Superpowers Marketplace：https://github.com/obra/superpowers-marketplace
- OpenSpec 官方网站：https://openspec.dev/
- OpenSpec 官方仓库：https://github.com/Fission-AI/OpenSpec
- Spec Kit 官方文档：https://github.github.com/spec-kit/
- Spec Kit Quick Start：https://github.github.com/spec-kit/quickstart.html
- Spec Kit 官方仓库：https://github.com/github/spec-kit