Superpowers、OpenSpec、Spec-Kit有什么区别？

前言

这三个项目在GitHub上都是现象级的存在：Superpowers狂揽238K Star，Spec-Kit斩获115K+ Star，OpenSpec也有46K+ Star。

加起来快40万Star，这是什么概念？

Spring Boot整个生态加起来都没这么多。

但问题来了：

它们到底有什么区别？

我该用哪个？

今天这篇文章就专门跟大家一起聊聊这个话题，希望对你会有所帮助。

一、先说说“Vibe Coding”的坑

在正式介绍这三个工具之前，我们先花2分钟聊聊一个现象。

有些小伙伴在工作中可能遇到过这样的情况：你让AI帮你实现一个功能，它二话不说就开始写代码了。你只是让它加一个登录接口，结果它顺手把整个认证模块都重写了。你问它“测试过了吗”，它说“应该没问题”。你让它解释为什么这么改，它开始讲一堆听起来很合理、但你总觉得哪里不对的理由。

这就是现在很多AI编程工具的真实写照。

它们不是不会写代码，而是太容易跳步骤了。

需求还没问清楚，就开始实现；设计还没确认，就开始改架构；测试还没跑完，就宣布完成。

问题的根源是什么？

AI代理缺乏结构化的工作流约束。

AI写代码的能力已经足够强了，但它没有“工程纪律”的概念。

它不知道写代码之前要先理解需求，不知道改代码之前要先写测试，不知道提交之前要先做Code Review。

三个工具应运而生，从不同角度解决这个问题：

1. Spec-Kit解决的是 “按什么规矩干” ——规范可执行化
2. OpenSpec解决的是 “改了什么” ——轻量规范管理
3. Superpowers解决的是 “怎么干” ——技能驱动工作流

二、Superpowers

给AI装上“工程纪律”。

2.1 它是什么？

Superpowers由开发者Jesse Vincent（GitHub: obra）打造，是一套AI编程代理技能框架与开发方法论。

一句话概括：它不是在让AI更聪明，而是让AI更守规矩——像给AI请了一个“项目经理”，强制它先思考、再计划、后编码、再审查。

截至目前，Superpowers在GitHub上已积累238K Star、21.1K Forks，Anthropic官方插件市场安装量超过68万次。

它支持Claude Code、Codex CLI、Gemini CLI、Cursor、GitHub Copilot CLI等多种AI编程工具。

2.2 核心机制：14个Skill

Superpowers的核心是14个可组合的Skill（技能），分为四大类：协作、测试、调试、元。

最重要的几个Skill：

① brainstorming（头脑风暴）⭐ 最常用

这是入口Skill。它的核心逻辑是：未获得用户明确批准前，绝不允许AI动手写一行代码。

AI会像苏格拉底一样，一次只问一个问题，逐步澄清需求；帮你把模糊的想法变成清晰的设计；提出2-3种方案，分析权衡；最终产出设计文档。

② subagent-driven-development（子代理驱动开发）⭐ 核心Skill

为每个计划任务派发独立子代理，互相隔离上下文，防止污染。每个任务完成后经过两阶段审查：

1. F1：规格合规审查——是否违反设计文档？
2. F2：代码质量审查——风格、性能、安全、边界条件？ 审查不通过则打回去重做。

③ test-driven-development（强制TDD）

强制遵循TDD的“红-绿-重构”循环：先写一个会失败的测试 → 用最少的代码让它通过 → 优化代码。

④ requesting-code-review（代码审查）

AI自动获取当前分支的git diff，逐文件进行审查，按严重程度报告问题。关键问题会阻止继续推进。

2.3 五阶段开发流程

Superpowers的核心，是给所有AI编码会话定死了一套五阶段的标准化开发流程：

任何代码产出，都必须走完这五步，一步都不能跳。

2.4 优缺点

优点：

1. 强制工程纪律，杜绝Vibe Coding
2. 14个Skill覆盖完整开发生命周期
3. 子代理隔离，防止上下文污染
4. 两阶段审查，确保质量
5. 跨平台兼容，不锁定具体AI工具 缺点：
6. 刚性Skill可能限制AI的“自由发挥”
7. 强制TDD可能增加初期开发时间
8. 学习曲线：需要熟悉14个Skill的用法

三、OpenSpec

给AI编码加上“规格说明书”。

3.1 它是什么？

OpenSpec是Fission AI团队创建的AI原生规范驱动开发框架。

一句话概括：它让AI编码工具按照一份结构化的规格文档来干活，而不是随心所欲地写代码。

OpenSpec的核心理念是四个词：fluid、iterative、easy、built for brownfield。

它不追求“规范生成代码”，而是做一层轻量的规范管理。

截至2026年6月，OpenSpec在GitHub上已有56K+ Star，支持Node.js 20.19.0+。

它不绑定特定AI工具，可无缝融入现有开发流程，尤其适配已有项目（1→n）的功能迭代。

3.2 核心机制：增量规格系统

OpenSpec最核心的创新是Delta-Based Specs（增量规格）机制。

传统的规格文档有个致命问题：每次需求变更，要么重写整个文档，要么在旁边手动批注。OpenSpec用增量方式表达变更：

1. ADDED Requirements —— 新行为追加到主规格
2. MODIFIED Requirements —— 替换现有需求块
3. REMOVED Requirements —— 删除需求块
4. RENAMED Requirements —— 用FROM:/TO:格式改标题 这个设计对棕地项目（已有代码库的项目） 特别友好。

你不需要一次性把所有需求写全，发现遗漏了就直接追加一个ADDED。

3.3 四个核心Skill

OpenSpec提供四个Skill，覆盖完整的开发周期：

3.4 完整工作流示例

以下通过一个天气查询CLI工具的例子，展示OpenSpec的完整流程：

第一步：提出变更

/opsx:propose "创建一个简单的天气查询命令行工具"

OpenSpec会生成四个文件：

proposal.md —— 回答Why/What/Impact：

Why

在终端快速查看天气，不需要打开浏览器或手机。

What Changes

• 新增 weather-cli 命令行工具
• 支持 weather <城市名> 和 weather --help

Impact

• 新增文件：weather.py
• 无外部依赖（仅用 Python 标准库）

specs/city-weather-query/spec.md —— 逐条描述功能需求：

Requirement: 城市天气查询

系统应接受城市名并返回当前天气。

Scenario: 有效城市名

• WHEN 运行 weather London
• THEN 显示伦敦的天气

Scenario: 无效城市名

• WHEN 运行 weather xyzxyzxyz
• THEN 显示友好错误信息

design.md —— 记录架构决策：

Context

零依赖的命令行天气查询工具。

Goals / Non-Goals

• Goals: 城市名查询、--help、错误处理、零依赖
• Non-Goals: 自动定位、GUI、持久化

Decisions

• 使用 wttr.in API（免费、无需API Key）
• 只用Python标准库

tasks.md —— 可执行的检查清单：

1. Core Implementation

• 1.1 实现天气查询函数
• 1.2 添加CLI参数解析
• 1.3 添加错误处理

2. Testing

• 2.1 测试有效城市名
• 2.2 测试错误处理

第二步：审阅——生成完成后，人工审阅这些文件。在这个阶段修改成本最低——改几行Markdown比改代码快得多。

第三步：执行变更——确认无误后，执行/opsx:apply，AI按照tasks.md逐步实现。

第四步：归档——完成后执行/opsx:archive，合并规范。

3.5 DAG工件依赖图

OpenSpec内部用了一个DAG（有向无环图）来管理工作流的依赖关系。

简单说，它会自动判断：先写proposal，再写spec，再写design，再写tasks——顺序不能乱，依赖不能跳。

3.6 优缺点

优点：

1. 轻量级：无需API Key和MCP
2. 增量规格：对已有项目特别友好
3. 规范可追溯：每次变更都有完整的proposal→spec→design→tasks→archive闭环
4. 不绑定特定AI工具：支持Cursor、GitHub Copilot、Claude Code等 缺点：
5. 执行层面较弱：可以把“要做什么”说清楚，但不太能把“具体怎么做”推进得足够细
6. 缺乏强制质量门禁：规范写好了，但AI执行时可能跳步骤
7. WHAT清楚，但HOW不够细

四、Spec-Kit

让规范“可执行”。

4.1 它是什么？

Spec-Kit是GitHub官方出品的规范驱动开发工具包。

官方定位非常明确：Spec-Driven Development flips the script on traditional software development. Specifications become executable, directly generating working implementations rather than just guiding them。

翻译过来：规范不只是“指导文档”，而是可执行的——能直接生成工作代码。

Spec-Kit发布于2025年8月，截至2026年6月已斩获115K+ Star、10.2k Fork，是2026年GitHub上增长最快的AI工具类项目之一。

支持Claude Code、GitHub Copilot、Cursor、Gemini CLI等25+种AI代理。

4.2 核心机制：七阶段流水线

Spec-Kit的核心是七个阶段的规范驱动开发流程，每个阶段都有明确的输入输出，像工厂流水线一样：

constitution.md（宪法） ：定义项目级别的治理原则——代码质量标准、测试规范、用户体验一致性要求、性能要求。

spec.md（规范） ：描述具体功能的需求——用户故事、功能需求，不涉及技术栈（关注what和why）。

plan.md（计划） ：技术实现方案——技术栈选择、架构设计、API契约。

tasks.md（任务） ：可执行的任务清单——从计划中提取的具体任务、实现步骤。

4.3 安装与使用

安装（需要Python 3.11+和uv包管理器）：

安装uv

curl -LsSf https://astral.sh/uv/install.sh | sh

安装Specify CLI

uv tool install specify-cli --from

使用：在AI代理中通过斜杠命令触发各阶段：

/speckit.constitution # 定义项目宪法

/speckit.specify # 描述功能规范

/speckit.plan # 制定技术计划

/speckit.tasks # 分解任务

/speckit.analyze # 一致性检查

/speckit.implement # 执行实现

4.4 优缺点

优点：

1. GitHub官方背书：可靠性高，长期维护有保障
2. 规范可执行：规范不只是文档，能直接生成工作代码
3. 七阶段流水线：流程清晰，每一步都有明确输入输出
4. 支持25+种AI代理：覆盖面广
5. 项目宪法机制：从顶层约束AI行为 缺点：
6. 学习曲线陡峭：七阶段流程需要时间掌握
7. 偏重“绿field项目”：对已有代码库的适配不如OpenSpec自然
8. Python技术栈：CLI基于Python/uv，对Java开发者有一定门槛

五、一张图看懂三者差异

这是最核心的部分——它们到底有什么区别？

用一句话总结：

1. Spec-Kit像一本详细的**《装修规范手册》** ——告诉你什么能做、什么不能做
2. OpenSpec像便利贴系统 ——快速记录变更，灵活调整
3. Superpowers像专业施工队的工作流程 ——每一步都有检查点，确保质量

六、多维度对比

七、到底该选哪个？

选Superpowers的场景

1. 你需要AI严格遵循工程纪律 —— 强制TDD、强制Code Review、强制子代理隔离
2. 你的任务复杂度高 —— 涉及多文件修改、需要子代理并行执行
3. 你希望AI从“代码生成器”升级为“资深工程师”
4. 你不希望被特定AI工具锁定 —— Superpowers跨Claude Code、Cursor、Codex等通用 我自己的经验是：Superpowers最适合那些“代码质量要求高、返工代价大”的项目。比如金融系统、核心业务模块、长期维护的项目。强制流程虽然前期慢一点，但后期几乎不需要返工。

选OpenSpec的场景

1. 你已有代码库，需要持续迭代 —— OpenSpec的增量规格机制对棕地项目特别友好
2. 你希望需求变更可追溯 —— 每次变更都有完整的proposal→spec→design→tasks→archive闭环
3. 你团队需要多人协作 —— 规范文档让所有人都清楚“这次改了什么”
4. 你希望轻量级、快速上手 —— 无需API Key和MCP OpenSpec最打动我的是增量规格的设计。在一个已经跑了三年的老项目上，你不可能花一个月把全部需求文档补全。OpenSpec允许你“边做边补”，每次只记录这次变更涉及的部分。这才是真实世界的工作方式。

选Spec-Kit的场景

1. 你从零开始一个新项目 —— 绿field项目，七阶段流水线从头走一遍
2. 你需要GitHub官方背书 —— 长期维护有保障
3. 你希望规范直接生成代码 —— 不只是指导文档，而是可执行的
4. 你的团队愿意投入时间学习标准化流程 Spec-Kit适合“从零到一”的项目。如果你的团队正打算启动一个新的大项目，而且愿意花时间把规范做扎实，Spec-Kit的七阶段流水线会让你少走很多弯路。但如果你面对的是一个已经跑了三年的老项目，Spec-Kit可能不如OpenSpec来得灵活。

最佳实践

不要把它们当成“三选一” 。

实际使用中，很多开发者发现这三个工具可以组合使用：

1. OpenSpec擅长管理WHAT —— 需求、提案、spec生命周期和归档
2. Superpowers擅长管理HOW —— 头脑风暴、深度设计、计划执行和代码Review
3. Spec-Kit擅长管理“按什么规矩” —— 项目宪法、全局约束 有开发者基于这个思路，创建了Comet —— 一个结合OpenSpec和Superpowers的Skill工具：

“OpenSpec很适合管理需求、proposal、spec生命周期和归档。Superpowers很适合做头脑风暴、深度设计、计划执行和代码review。但我在真实使用时发现：只用OpenSpec，容易出现WHAT清楚但HOW不够细的问题；只用Superpowers，容易出现HOW很强但WHAT没有完整生命周期闭环的问题。”

理想的工作流：用Spec-Kit定义项目宪法和全局约束 → 用OpenSpec管理每次变更的规格和归档 → 用Superpowers约束AI的执行纪律。

总结

回到最初的问题：Superpowers、OpenSpec、Spec-Kit，到底该怎么选？

我的建议是三步走：

第一步：认清你的项目阶段

1. 新项目从零开始 → Spec-Kit的七阶段流水线帮你打地基
2. 已有代码库持续迭代 → OpenSpec的增量规格机制更灵活
3. 两者都有 → 考虑组合使用 第二步：认清你的核心痛点
4. AI不守纪律、乱改代码 → Superpowers的14个Skill强制流程
5. 需求说不清、变更没记录 → OpenSpec的增量规格管理
6. 项目没规范、质量靠运气 → Spec-Kit的七阶段流水线 第三步：不要怕组合使用

这三个工具不是互斥的。Spec-Kit定“规矩”、OpenSpec管“变更”、Superpowers管“执行”——它们各管一摊，完全可以一起用。

一个参考的组合方案：

1. 用Spec-Kit的constitution定义项目宪法（一次性）
2. 每次新功能用OpenSpec的propose创建变更提案
3. 用Superpowers的brainstorming做需求澄清
4. 用Superpowers的subagent-driven-development执行开发
5. 用OpenSpec的archive归档变更 这样，你既有全局规范（Spec-Kit），又有变更追溯（OpenSpec），还有执行纪律（Superpowers）——三管齐下，AI编程才能真正从“碰运气”变成“按流程” 。

开源地址

1. Superpowers：https://github.com/obra/superpowers （238K Star）
2. OpenSpec：https://github.com/Fission-AI/OpenSpec （56K+ Star）
3. Spec-Kit：https://github.com/github/spec-kit （115K+ Star）