架构师修行录

AI编程工作流怎么选?三大主流工具实测对比

鹿Sir上线,见字如面。

用AI写代码,你是不是也遇到过这些糟心事:

  • 同一个需求,AI每次给的代码风格都不一样,得反复解释项目规范
  • 团队里几个人同时用AI,同样的需求出来的实现千差万别
  • 想让它按测试驱动开发来,结果它总是跳过测试直接写代码

这些问题说到底就一个原因:AI代理缺少统一的工作流约束。

现在市面上有三款热门工具能解决这个问题:GitHub官方的Spec-Kit、轻量级的OpenSpec、以及社区最火的Superpowers。它们都打着"规范驱动"的旗号,但底层逻辑完全不同——选错了真的会适得其反。

我花了一周时间,把三款工具的官方文档和实现机制都研究了一遍,差异终于理清楚了。

一、三款工具的背景和定位

Spec-Kit:让规范能直接跑起来

GitHub官方出品,核心团队包括Den Delimarsky和John Lam等。

官方给它的定位很直接:

“

规范驱动开发颠覆了传统软件开发模式。规范不再是只供参考的文档,而是可以直接执行的——能生成可用代码,而不只是指导开发。

说白了,Spec-Kit的理念是:规范不只是看看而已,它能直接产出代码。

整个工作流分成七个阶段:项目治理(constitution) → 需求定义(specify) → 需求澄清(clarify) → 技术规划(plan) → 任务分解(tasks) → 一致性检查(analyze) → 代码实现(implement)。

每个阶段都有明确的输入输出,像工厂流水线一样一环扣一环。

OpenSpec:给规范加一层轻量管理

Fission-AI团队开发,核心理念用四个词概括:灵活、迭代、简单、为遗留项目设计。

官方定义:

“

一个轻量级的规范驱动框架,适用于编程代理和命令行工具——通用、开源,不需要API Key也不需要MCP。

关键点:轻量、通用、零配置门槛。

OpenSpec不追求"规范生成代码",而是做一层轻量的规范管理——通过/opsx:propose(创建提案) → /opsx:apply(执行) → /opsx:archive(归档)的流程,让规范成为活的文档。

Superpowers:用技能组合约束AI行为

Jesse Vincent(obra)出品,社区规模最大——115K Star。

官方定义:

“

一套完整的软件开发工作流,基于一组可组合的"技能"构建。

核心词:技能组合。Superpowers不是规范驱动,而是通过一组可组合的技能来约束代理行为。

内置技能包括:测试驱动开发(强制TDD)、系统化调试、苏格拉底式设计细化、子代理并发执行等。

二、技术架构对比

底层实现

Spec-Kit的架构

基于Python,用uv做包管理。核心是模板引擎 + 扩展系统——规范通过模板渲染成代码,扩展系统允许自定义工作流。

OpenSpec的架构

基于TypeScript,核心是变更驱动的工作流。每个功能变更是独立目录,包含提案、设计、任务和规范增量。

Superpowers的架构

基于Shell/JavaScript,核心是技能触发系统——不是手动调用命令,而是通过Hook自动激活相关技能。

数据流差异

维度
Spec-Kit
OpenSpec
Superpowers
规范存储
中心化配置文件
分布式目录结构
无独立规范层
变更追踪
Git分支隔离
changes/目录
Git Worktrees
状态管理
阶段门控
提案状态
技能激活状态

三、核心特性对比

维度
Spec-Kit
OpenSpec
Superpowers
核心范式
规范可执行化
轻量规范层
技能组合
主要语言
Python
TypeScript
Shell/JavaScript
Star数
82.5K
34.5K
115K
安装方式
uv tool install
npm install -g
插件市场/手动配置
AI代理支持
11+
20+
5+
是否需要API Key
取决于代理
不需要
取决于代理
是否需要MCP
取决于代理
不需要
取决于代理
TDD强制
不强制
不强制
强制
遗留项目支持
支持
优先设计
支持
学习曲线
中等
平缓
平缓

几个关键差异:

工具支持范围:OpenSpec支持最广(20+工具),包括Claude Code、Cursor、Codex、Windsurf、Gemini CLI等。Spec-Kit支持11+,Superpowers主要优化Claude Code。

TDD强制:只有Superpowers强制RED-GREEN-REFACTOR循环。对测试要求严格的团队,这是重要考量。

遗留项目支持:OpenSpec明确主打"为遗留项目设计"的旗号——优先考虑现有代码库的渐进式改造。

四、工作流范式对比

三款工具最大的差异在于工作流范式——这是选型的核心依据。

Spec-Kit:阶段门控式

constitution → specify → clarify → plan → tasks → analyze → implement
     ↓            ↓         ↓        ↓       ↓        ↓         ↓
   [门控]      [门控]    [门控]   [门控]  [门控]   [门控]    [门控]

每个阶段都是一道"门"——必须完成当前阶段才能进入下一阶段。好处是流程严格、质量可控;坏处是灵活性低,适合大型项目。

Spec-Kit的哲学是:结构胜过混乱。

OpenSpec:流畅迭代式

/opsx:propose → /opsx:apply → /opsx:archive
      ↓              ↓             ↓
   [提案]         [执行]        [归档]

没有严格的阶段门,可以随时调整提案。变更驱动——每个功能是独立的变更目录,完成后归档。

OpenSpec的哲学是:迭代胜过瀑布。

Superpowers:技能触发式

brainstorming → writing-plans → executing-plans → TDD → code-review
      ↓              ↓               ↓            ↓        ↓
   [自动触发]     [自动触发]       [自动触发]   [自动触发] [自动触发]

不是手动调用命令,而是通过上下文自动触发相关技能。比如写代码前自动激活TDD技能,写完代码自动激活code-review技能。

Superpowers的哲学是:流程胜过猜测。

你适合哪种范式?

你的情况
推荐范式
原因
大型项目、多人协作
阶段门控(Spec-Kit)
质量可控、流程可追溯
快速迭代、频繁调整
流畅迭代(OpenSpec)
灵活性高、学习成本低
质量优先、强制TDD
技能触发(Superpowers)
自动强制质量门

五、实战示例

Spec-Kit实战

安装:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

初始化项目:

specify init my-project

定义规范:

# 用户登录功能

## 用户故事
作为用户,我想登录以访问我的账户。

## 验收标准
- 用户可以输入邮箱和密码
- 系统验证凭据
- 凭据无效时显示错误信息
- 登录成功跳转到仪表盘

## 技术约束
- 使用JWT管理会话
- 密码必须用bcrypt哈希

执行规范生成代码:

/speckit.implement

OpenSpec实战

安装:

npm install -g @fission-ai/openspec@latest

创建变更提案:

/opsx:propose 给仪表盘添加暗黑模式支持

OpenSpec会在openspec/changes/add-dark-mode/目录下生成提案、设计、任务列表和规范增量。

执行实现:

/opsx:apply add-dark-mode

完成后归档:

/opsx:archive add-dark-mode

Superpowers实战

安装(以Claude Code为例):

/plugin install superpowers@claude-plugins-official

使用——不需要手动调用命令,技能会自动触发:

你只需要说:我想给登录功能加一个"记住我"选项

Superpowers会自动:
1. 激活brainstorming技能,细化需求
2. 激活writing-plans技能,生成实现计划
3. 激活test-driven-development技能,先写测试
4. 实现功能
5. 激活verification-before-completion技能,验证修复
6. 激活requesting-code-review技能,自我审查

六、选型建议

企业级项目

推荐:Spec-Kit

  • GitHub官方维护,长期支持有保障
  • 阶段门控确保质量可控
  • 丰富的扩展生态支持定制化
  • 企业级团队功能成熟

适合:大型团队、严格流程要求、需要可追溯性的项目。

快速迭代场景

推荐:OpenSpec

  • 轻量级,学习曲线平缓
  • 流畅迭代,无需严格门控
  • 支持20+工具,切换成本低
  • 无需配置API Key和MCP

适合:创业团队、个人项目、需要频繁调整方案。

质量优先场景

推荐:Superpowers

  • 强制TDD,质量有保障
  • 自动技能触发,减少人为疏漏
  • 子代理并发执行,效率高
  • 社区规模最大(115K Star)

适合:对代码质量有严格要求、重视测试覆盖率的团队。

遗留系统改造

推荐:OpenSpec

  • 明确主打"为遗留项目设计"
  • 变更驱动,适合渐进式改造
  • 规范持久化在代码库中,不影响现有结构
  • 灵活迭代,不需要一次性迁移

适合:现有代码库的渐进式现代化。

跨工具开发

推荐:OpenSpec

  • 支持20+ AI编程工具
  • 切换工具无需重新配置
  • 规范是通用格式

适合:需要在不同AI工具间切换的开发者。

需要规范生成代码

推荐:Spec-Kit

  • 规范可执行化是核心定位
  • 模板引擎支持代码生成
  • 扩展系统支持自定义生成逻辑

适合:希望通过规范自动生成代码的场景。

七、各自的局限

没有完美工具,选型本质是做权衡。

Spec-Kit的局限:

  • 相对重量级,需要Python 3.11+和uv,环境配置有一定门槛
  • 阶段门较严格,不适合需要频繁调整方向的项目
  • 学习曲线较陡,七个阶段需要时间理解

OpenSpec的局限:

  • 规范不直接生成代码,只能指导,不能执行
  • 企业功能开发中,团队协作功能尚不完善
  • 社区规模较小(34.5K Star),生态相对薄弱

Superpowers的局限:

  • 非规范驱动,没有独立规范层,规范是副产品
  • 依赖代理平台,安装方式因平台而异
  • 缺少正式文档站点,主要靠GitHub README和社区

总结

三款工具的核心差异可以概括为一句话:

  • Spec-Kit:规范能执行,直接生成代码
  • OpenSpec:规范轻量管理,灵活迭代
  • Superpowers:技能自动触发,强制质量

选型建议:

场景
推荐工具
大型企业项目
Spec-Kit
快速迭代/个人项目
OpenSpec
质量优先/强制TDD
Superpowers
遗留代码库改造
OpenSpec
跨工具开发
OpenSpec
需要规范生成代码
Spec-Kit

最后说一句:工具是手段不是目的。如果你的项目规模小、团队人数少,简单的Git提交规范 + Code Review可能就够了——别为了用工具而用工具。

你正在用哪款AI编程工作流工具?欢迎在评论区分享你的使用体验。

EOF

Image
关于「鹿Sir」

分享架构技术/IT资讯/牛马日常

电商·SaaS·AI架构师/DDD极客·SKILL极客

→关注公众号,撩小码鹿「已接入AI」

→加我备注“进群”,进技术大佬群学习