AI 开发规范工具对比分析文档

整理时间: 2026-03-20 数据来源: GitHub、Medium、Reddit、掘金、vocus.cc、yuv.ai 等公开资料

一、行业背景

1.1 为什么需要规范驱动开发？

2024-2026 年，AI 编程工具爆发式增长，92% 的开发者在工作流中使用 AI 工具。但也带来了核心问题：

"Vibe Coding" 困境：需求散落在聊天记录中，缺乏持久化和系统化
AI 失忆：上下文窗口满了后，AI 出现"失忆"症状
代码质量失控：AI 优化速度胜过质量，产出的代码像"意大利面条"
不可预测：模糊的提示词导致不可预测的结果

"25% 的 Y Combinator Winter 2025 队列中有 95% 的代码是 AI 生成的" "行业领袖预测到 2027 年开发者将不再看代码" "规范正在成为编程的基本单位" —— Martin Fowler

1.2 规范驱动开发（SDD）的三种模式

模式	描述	代表工具
Spec-First	规范先于代码，但用完即弃	Spec-Kit、Kiro、BMad
Spec-Anchored	规范持续存在和演进	OpenSpec、Spec Kitty
Spec-as-Source	只编辑规范，代码自动生成	Tessl

二、工具详细对比

2.1 基本信息

维度	Superpowers	Spec-Kit	GSD	OpenSpec	BMad Method	Kiro	Tessl
Stars	99.6K ⭐	69.1K	36.4K	32.5K	—	—	—
维护者	obra (社区)	GitHub 官方	TÂCHES	Fission-AI	社区	AWS	商业
协议	MIT	Open Source	MIT	MIT	Open Source	Proprietary	Proprietary
创建时间	2025-10	2025 初	2025-12	2025	—	—	—
核心创新	TDD + 子代理	宪法驱动	上下文工程/波次管理	变更管理	21 Agent	IDE 集成	规范即源码

2.2 功能对比

功能	Superpowers	GSD	OpenSpec	Spec-Kit	BMad	Kiro
设置时间	几分钟	几分钟	5 分钟	30 分钟	数小时/天	15-20 分钟
复杂度	中	中	低	中	高	中
TDD 强制	✅ 严格	❌	❌	❌	部分	❌
Git Worktree	✅	❌	❌	❌	❌	❌
增量修改支持	中	中	✅ 最佳	弱	弱	弱
子代理/Agent	6 技能	11 Agent	❌	❌	21 Agent	✅
上下文管理	普通	✅ 波次管理	普通	普通	普通	普通
上下文恢复	部分	✅ HANDOFF.json	❌	❌	❌	❌
仪表盘	❌	❌	✅	❌	❌	✅
多工具支持	20+	7+	20+	工具无关	—	仅 Claude
输出量	按需	结构化文件	~250 行	~800 行	非常详细	中等
Token 消耗	较高	高（5-10x）	低	中	高	中

2.3 场景评分（基于 spec-compare 研究项目）

场景	OpenSpec	Spec-Kit	BMad	Spec Kitty
从零开始新项目	★★★	★★★★★	★★★★	★★★
改造现有项目	★★★★★	★★	★★★	★★★★
小改动/bug 修复	★★★★★	★★	★	★★★★
大型功能开发	★★★★	★★★★★	★★★★★	★★★
团队协作	★★★★	★★★★★	★★★★★	★★★
个人项目	★★★★★	★★	★	★★★★
并行开发	★★	★★	★★	★★★★★

2.4 批评与局限

SDD 的共性问题：

瀑布回归：SDD 是否重新引入了瀑布流的官僚主义？
AI 不遵守规范：AI agent 经常忽略规范
可扩展性疑问：不清楚 SDD 何时增加价值、何时是额外开销
历史教训：与失败的模型驱动开发（MDD）有相似之处

各工具的具体批评：

Spec-Kit：阶段门控太严格，增量修改笨拙
Kiro/BMad：小改动用大锤子
Tessl：封闭 Beta，不确定性高
OpenSpec：缺乏 git worktree 支持
Superpowers：TDD 严格到可能影响效率
GSD：Token 消耗是普通模式的 5-10 倍；简单任务杀鸡用牛刀

三、组合推荐方案

3.1 个人开发者（推荐）

方案 A：Superpowers + OpenSpec ⭐（最均衡）

想法 → brainstorm(Superpowers) → propose(OpenSpec)
     → plan(Superpowers) → apply(TDD + Superpowers)
     → review → archive(OpenSpec)

Superpowers 管工程流程（TDD、计划、子代理）
OpenSpec 管需求规范（变更跟踪、文档沉淀）
互补不冲突，轻量高效

方案 B：GSD（自主开发型）

/gsd:discuss → /gsd:plan → /gsd:execute → /gsd:verify

适合"设置好需求后让 AI 跑几小时"的模式
波次管理解决上下文腐烂
缺点：Token 消耗较高

3.2 大型团队

Spec-Kit + Superpowers

Spec-Kit 定义项目"宪法"和团队规范
Superpowers 管个人开发流程
规范通过 Git 共享和 review

3.3 并行开发多功能

Spec Kitty + OpenSpec

Spec Kitty 是唯一内置 git worktree 的工具
OpenSpec 管需求变更
适合同时开发多个 feature

四、工具选择决策树

你是什么规模？
├── 个人/小团队
│   ├── 想让 AI 自主干几小时？→ GSD
│   ├── 改造现有项目？→ OpenSpec
│   ├── 需要严格 TDD？→ Superpowers
│   ├── 两者都要？→ Superpowers + OpenSpec ⭐
│   └── 关注上下文质量？→ GSD（波次管理）
├── 中大型团队
│   ├── GitHub 重度用户？→ Spec-Kit
│   ├── 需要并行开发？→ Spec Kitty
│   └── 企业级复杂流程？→ BMad Method
└── 想尝试最前沿
    ├── 喜欢 IDE 一体化？→ Kiro
    └── 只想写规范？→ Tessl（Beta）

五、参考资源汇总

文章与博客

研究项目

spec-compare: 6 款 SDD 工具深度对比 — 包含 11 款工具的详细分析

官方仓库

Superpowers — 99.6K ⭐
Spec-Kit — 69.1K ⭐
GSD (Get Shit Done) — 36.4K ⭐
OpenSpec — 32.5K ⭐
Spec Kitty — 社区 fork，worktree 支持
Flokay (Claude plugin for OpenSpec) — 18 ⭐
GSD for Cursor — 60 ⭐
GSD for OpenCode — 529 ⭐

论坛

r/ClaudeCode — SDD 工具讨论活跃
Hacker News: GSD 讨论 (460分/251评论) — 社区真实反馈

六、趋势展望

规范成为编程基本单位：从"写代码"到"写规范"
Living Spec 平台：规范实时同步代码（如 Augment Code 的 Intent）
多 Agent 协作：从单 Agent 到专业 Agent 团队
Git Worktree 标配：并行开发将成为标准能力
2027 年开发者可能不再直接看代码 — 行业趋势

本文档基于 2026 年 3 月公开资料整理，工具更新频繁，建议定期查看官方仓库获取最新信息。

AI 开发规范工具对比分析文档 ​

一、行业背景 ​

1.1 为什么需要规范驱动开发？ ​

1.2 规范驱动开发（SDD）的三种模式 ​

二、工具详细对比 ​

2.1 基本信息 ​

2.2 功能对比 ​

2.3 场景评分（基于 spec-compare 研究项目） ​

2.4 批评与局限 ​

三、组合推荐方案 ​

3.1 个人开发者（推荐） ​

方案 A：Superpowers + OpenSpec ⭐（最均衡） ​

方案 B：GSD（自主开发型） ​

3.2 大型团队 ​

3.3 并行开发多功能 ​

四、工具选择决策树 ​

五、参考资源汇总 ​

文章与博客 ​

研究项目 ​

官方仓库 ​

论坛 ​

六、趋势展望 ​

AI 开发规范工具对比分析文档

一、行业背景

1.1 为什么需要规范驱动开发？

1.2 规范驱动开发（SDD）的三种模式

二、工具详细对比

2.1 基本信息

2.2 功能对比

2.3 场景评分（基于 spec-compare 研究项目）

2.4 批评与局限

三、组合推荐方案

3.1 个人开发者（推荐）

方案 A：Superpowers + OpenSpec ⭐（最均衡）

方案 B：GSD（自主开发型）

3.2 大型团队

3.3 并行开发多功能

四、工具选择决策树

五、参考资源汇总

文章与博客

研究项目

官方仓库

论坛

六、趋势展望