本文基于对五个框架的 GitHub 仓库、官方文档、独立评测、企业案例、社区讨论的系统性交叉验证。每一个结论都标注了来源类型。最后更新：2026-05-09。

---

1. 五分钟速览

框架	一句话	核心机制	版本	Stars	出品方
GSD	专治上下文腐烂的工作流协议	分阶段开新窗口执行 + 文件持久化	v1.41.0	61K+	TÂCHES（独立开发者）
gstack	25 种工程角色的虚拟团队	角色分工斜杠命令 + Sprint 流水线	无发布版本	91.7K+	Garry Tan（YC CEO）
Spec Kit	规范成为可执行蓝图	Constitution 驱动的 9 步门禁流程	v0.8.7	93K+	GitHub（官方）
Ruflo	企业级多智能体蜂群指挥系统	5 种集群拓扑 + 5 种共识/协调机制	v3.6.30	46.9K+	rUv / Cognitum.One
OpenSpec	轻量级 delta 规范驱动	增量差异（ADDED/MODIFIED/REMOVED）自动归档	v1.3.1	46.2K+	Fission-AI（YC W26）

数据来源：各框架 GitHub 仓库主页（2026-05-09 抓取）。

---

2. 多维度对比

2.1 生产就绪度

维度	GSD	gstack	Spec Kit	Ruflo	OpenSpec
版本号	v1.41.0	无发布版本	v0.8.7	v3.6.30	v1.3.1
发布次数	66	0	—	1,480	36
提交数	2,497	266	931	6,345	586
已知内存泄漏	无报告	无报告	无报告	有（GitHub Issues #1373）	无报告
测试失败	无报告	无报告	无报告	16 个测试失败	无报告
Windows 兼容	✅	⚠️ 需 Git Bash/WSL	✅	❌ 已知崩溃（#1164）	✅
ThoughtWorks 雷达	未收录	未收录	已收录（2026-04）	未收录	未收录
独立安全审计	无公开记录	无公开记录	无公开记录	有内部审计但无第三方	无公开记录

Ruflo 数据来源：GitHub Issues #1373、#1344、#1164；ic.work 独立分析（2026-05）。

2.2 企业治理能力

能力	GSD	gstack	Spec Kit	Ruflo	OpenSpec
需求→代码可追溯链	⚠️ 文件级	❌ 对话级	✅ 完整 artifact 链	❌	✅ delta 归档
强制质量门禁	✅ 4 类门禁	❌ 靠角色自觉	✅ 强制不跳步	❌	❌ 无强制
技术决策记录	⚠️ 散落	❌	✅ CONSTITUTION.md	❌	❌
编码规范强制执行	❌	❌	✅ Constitution 约束	❌	❌
审计轨迹	✅ Git 历史	✅ Git 历史	✅ 完整 artifact	⚠️ 代理日志	✅ archive 目录
跨模型支持	8+	9+	30+	多模型	25+

Spec Kit 治理数据来源：GitHub 官方文档 + ThoughtWorks 技术雷达评估（2026-04）。

2.3 真实世界验证

框架	已知企业/组织用户	独立公开案例	案例可信度
GSD	Amazon / Google / Shopify / Webflow 工程师	Hacker News 多篇使用报告 / XDA Developers 评测 / AugmentCode 评测	高
gstack	Garry Tan 本人	仅作者自述，无第三方独立验证	低（伴随 Hacker News 争议和 flag）
Spec Kit	ThoughtWorks 团队 / EPAM	ThoughtWorks 雷达收录 / EPAM 案例研究 / Microsoft Learn 培训模块	高
Ruflo	无公开企业案例	ic.work 独立分析：明确建议不用于核心工作流	无正面案例
OpenSpec	得物（大型电商平台）	得物技术团队深度实战文章（优惠券结算重构）	高

来源：各框架 README 声明 + Hacker News + 知乎/CSDN + ThoughtWorks Radar + ic.work 独立分析。

2.4 存量项目（Brownfield）适配

能力	GSD	gstack	Spec Kit	OpenSpec
零侵入初始化	❌ 需整理项目信息	✅ 仅加 skill 文件	⚠️ 需 init --here + 整理	✅ openspec init 后目录为空
对已有代码补 spec	不需要	不需要	需要（全量 spec 模型）	不需要（delta 只写改动）
不影响团队原有流程	⚠️ 需改用 GSD 命令	⚠️ 需改用 gstack 命令	❌ 需改为 9 步门禁	✅ 不改流程
卸载代价	删文件即可	删 skill 即可	删 .specify/ + specs/	rm -rf openspec/
规范渐进生长	❌	❌	❌ 每次全量重写	✅ 核心能力

关键推论：存量项目引入编排框架，OpenSpec 是唯一"零迁移成本"的选项。其他四个都需要先投入时间整理或适配。

2.5 学习曲线与团队门槛

框架	核心命令数	上手时间	团队其他人需要学吗	主要学习障碍
GSD	6 核心 + 80 辅助	1-2 天	用辅助命令时需要	六阶段工作流概念
gstack	25	3-5 天	需要用到的角色都要学	25 个命令的适用时机
Spec Kit	9	2-3 天	必须学（流程强制）	Constitution 写法 + 9 步门禁节奏
Ruflo	—	1-2 周	必须学	集群拓扑 + 共识协议 + 代理配置
OpenSpec	4 核心 + 6 扩展	半天	不需要	理解 delta 标记（ADDED/MODIFIED/REMOVED）

---

3. 核心问题一：能不能搭配装？

3.1 规范层 vs 执行层

编排框架按职责天然分成两层：

规范层（定义"做什么"）        执行层（管理"怎么做"）
┌──────────────┐              ┌──────────────┐
│  Spec Kit    │              │     GSD      │  ← 上下文隔离
│  OpenSpec    │              │    gstack    │  ← 角色分工
└──────────────┘              │    Ruflo     │  ← 多机集群
       │                      └──────────────┘
       │                            │
  同一层内是竞争关系           同一层内可以互补
  只能选一个                   可以按需叠加

3.2 每种组合的判定

组合	关系	判定	原因
Spec Kit + OpenSpec	竞争	🔴 不要	两套 spec 体系、两套目录、两套命令——团队困惑和决策疲劳
OpenSpec + GSD	互补	✅ 可取	规范层和执行层各司其职，目录不冲突，命令不重叠
Spec Kit + GSD	半重叠	🟡 不推荐	两者都有 plan/execute 阶段，谁的优先级高？
OpenSpec + gstack	勉强互补	🟡 慎用	gstack 25 个命令中仅 4-5 个对存量项目有用
GSD + gstack	勉强互补	🟡 慎用	角色分工 + 上下文隔离各有价值，但没有 gstack 版本号，升级风险叠加
OpenSpec + GSD + gstack	过度	🔴 不要	三套框架 = 三套升级节奏 + 上下文被框架吃掉 20K+ tokens
任何 + Ruflo	风险叠加	🔴 目前不要	Ruflo 自身 bug 未修完，叠加其他框架让排错变成噩梦

3.3 唯一推荐搭配

OpenSpec + GSD，理由如下：

目录互不侵犯：
├── openspec/         ← OpenSpec
├── PROJECT.md        ← GSD
├── REQUIREMENTS.md   ← GSD
├── ROADMAP.md        ← GSD
├── STATE.md          ← GSD
└── src/              ← 你的代码（两者都不碰）

工作流：
/opsx:propose  → 写 delta spec
/opsx:apply    → 实现
/gsd-plan-phase 1  → 拆执行阶段
/gsd-execute-phase 1 → 子代理并行执行
/gsd-verify-work 1   → 验证
/opsx:archive  → 归档

上下文开销估算：
• GSD 全量：~12K tokens
• OpenSpec：约 3-6K tokens（取决于命令数）
• 合计：15-18K tokens 系统开销

搭配的条件： 项目规模足够大，15-18K token 开销值得。小项目不划算。

3.4 特殊情况：项目里已有 Superpowers 技能包，再加编排框架冲突吗？

先说结论：不冲突。 Superpowers 是方法论技能包，五个编排框架是工作流管理——它们不在同一层，目录不打架，命令不重叠。

但这不是说"随便叠加都没事"。以下是逐一分析：

---

Superpowers 是什么？

属性	说明
定位	方法论技能包（教 AI 怎么做工程），不是编排框架
作者	Jesse Vincent（obra / Prime Radiant）
Stars	184K+
版本	v5.1.0
机制	14 个技能自动激活——不需要手动调命令，AI 在写代码时自动走 TDD、系统调试、代码审查
安装位置	.claude/skills/superpowers/
核心理念	“Write tests first, always”

数据来源：obra/superpowers GitHub 仓库（2026-05-09 抓取）。

---

Superpowers × 五个编排框架逐一判定：

叠加组合	判定	目录冲突？	命令冲突？	功能重叠？	详细说明
Superpowers + Spec Kit	🟡 可用	无（.claude/skills/ vs .specify/）	无（自动激活 vs /speckit.*）	⚠️ 轻度	Superpowers 的 brainstorming + writing-plans 和 Spec Kit 的 /speckit.specify + /speckit.plan 都强调"先规划再写代码"。不冲突但需明确分工：让 Spec Kit 产出规范文档（CONSTITUTION.md / SPECIFICATION.md），让 Superpowers 管 TDD 和代码审查
Superpowers + OpenSpec	✅ 最干净	无（.claude/skills/ vs openspec/）	无（自动激活 vs /opsx:*）	无	Superpowers 管"怎么写对"（TDD + review），OpenSpec 管"写什么"（delta spec）。零重叠，叠加后上下文开销最低
Superpowers + GSD	✅ 互补	无（.claude/skills/ vs 项目根目录文档）	无（自动激活 vs /gsd-*）	无	Superpowers 管工程方法论，GSD 管上下文隔离。不同维度，各管各的
Superpowers + gstack	🟡 有冗余	无（都在 .claude/skills/ 但不同子目录）	无（自动激活 vs /review 等）	⚠️ 中度	Superpowers 的 requesting-code-review 和 TDD 覆盖了 gstack 的 /review 和 /qa 功能。如果已装 Superpowers，gstack 的审查/测试角色是重复投资。只有 /cso（安全）、/ship（发布）、/browse（浏览器测试）这几个 Superpowers 不覆盖的角色有增量价值
Superpowers + Ruflo	🔴 不要	无关	无关	无关	不是因为冲突——是因为 Ruflo 自身的内存泄漏 + 16 测试失败 + Windows 崩溃不解决，跟谁叠加都不安全

---

叠加后的上下文开销：

只装 Superpowers               → ~3-5K tokens
Superpowers + OpenSpec          → ~7-10K tokens
Superpowers + Spec Kit          → ~10-14K tokens
Superpowers + GSD               → ~15-18K tokens
Superpowers + OpenSpec + GSD    → ~18-23K tokens

以上为估算值，实际开销取决于安装模式（GSD 有 --minimal 模式可降至 ~700 tokens）和激活的技能数量。

---

一句话：Superpowers 跟五个编排框架都不冲突，但它让 gstack 的 review/QA 角色变多余，跟 Spec Kit 有轻微的规划理念重叠需要主动分工。最干净的叠加对象是 OpenSpec 和 GSD。

---

4. 核心问题二：已有公司项目，加哪个不伤身？

4.1 侵入性排名

OpenSpec  <  gstack  <  GSD  <  Spec Kit  <  Ruflo
   │           │         │         │           │
 零侵入      轻量      中等      重度       危险

4.2 逐框架分析

OpenSpec：零侵入

执行 openspec init 后：
  项目多了 openspec/ 目录（空的）
  项目原有代码、流程、文件 → 完全不变
  团队其他人 → 不知道也无所谓
  不用了 → rm -rf openspec/

核心原因：Delta 模型不需要你给已有代码补 spec。
只给"这次要改的模块"写 delta，不改的模块一动不动。
规范库是随着每次改动自然长出来的。

企业案例：得物（大型电商）在生产环境中用此方式，
对已有优惠券结算系统做重构，只写变更 delta，不补全量 spec。

来源：得物技术团队公开文章（2026-03）+ OpenSpec 官方仓库。

gstack：轻量但收益有限

侵入程度：仅 .claude/ 下加 skill 文件，不碰项目代码
实际问题：25 个角色，存量项目真正有用的约 4-5 个：
  ✅ /review（代码审查）
  ✅ /cso（安全审计）
  ✅ /qa（测试）
  ✅ /ship（发布）
  ❌ /office-hours、/design-shotgun、/plan-*（你已有方案和设计）
  
致命缺陷：无版本号。如果某次更新和你的 Claude Code 版本不兼容，
你无法回滚到特定版本——因为没有 semver。

GSD：中等侵入，需整理已有信息

实际需要做的事：
  - 写 PROJECT.md（项目总览）
  - 整理 REQUIREMENTS.md（已有需求）
  - 规划 ROADMAP.md（后续路线）
  - 标记 STATE.md（当前进度）

适合：项目正在大规模迭代，跨天任务频繁
不适合：项目只是日常修修补补，初始化成本回不了本

Spec Kit：存量项目最高侵入

specify init --here 之后：
  - 需要写 CONSTITUTION.md（整个项目的技术原则）
  - 每个新功能要写全量 spec（不是 delta）
  - 已有 50 个接口怎么补 spec？这是个现实问题
  - 团队必须改用 9 步门禁流程

社区反馈：ThoughtWorks 报告指出存量项目使用 Spec Kit
存在 "brownfield friction"——重写全量 spec 是真实摩擦。
EPAM 案例确认了这一点。

适合：准备从零重写的项目，或者全新子项目。
不适合：已经在跑的项目想"试试看"。

Ruflo：目前不要往任何公司项目上加

已知问题（均有 GitHub Issues 编号）：
  - 内存泄漏：3 个 Map 无清理机制（#1373）
  - 16 个测试失败（Vitest 4.x 兼容性）
  - Windows 崩溃：ERR_UNSUPPORTED_ESM_URL_SCHEME（#1164）
  - 独立分析明确建议不用于核心工作流（ic.work, 2026-05）
  - 无公开企业案例

---

5. 分场景决策

5.1 你在哪个阶段？选哪个？

你的项目阶段
│
├─ 0→1（从零开始，商业项目）
│   │
│   ├─ 需要质量审计/合规/未来交接
│   │   └─ 首选：Spec Kit
│   │      • 唯一提供 Constitution → Spec → Plan → Tasks 全链治理
│   │      • ThoughtWorks 雷达已收录
│   │      • GitHub 官方出品，93K⭐，MIT 协议
│   │      • 风险提示：EPAM 案例证明 Constitution 可能被 AI 忽略
│   │        解法——写"为什么"而不是只写"不要做什么"
│   │
│   └─ 不需要严格审计，想要轻量快速
│       └─ 首选：OpenSpec
│          • 比 Spec Kit 轻得多
│          • YC 孵化，v1.3.1 已过 1.0 里程碑
│
├─ 1→10（已有项目，持续迭代）
│   │
│   ├─ 日常功能迭代
│   │   └─ 首选：OpenSpec
│   │      • Delta 模型：改哪写哪，不改不动
│   │      • 零侵入：openspec init 后目录为空
│   │      • 卸载零成本：rm -rf openspec/
│   │
│   ├─ 跨天/跨会话马拉松任务
│   │   └─ OpenSpec + GSD 组合
│   │      • OpenSpec 管规范，GSD 管上下文不腐烂
│   │      • 注意：15-18K tokens 上下文开销
│   │
│   └─ 修修补补为主
│       └─ 不加任何框架
│          • 你的痛点不是上下文腐烂也不是规范缺失
│          • 加框架只会增加负担
│
└─ 需要跨机器多代理集群
    └─ ⚠️ 目前五家都不够成熟
       • Ruflo 架构对但代码质量不支撑商业使用
       • 建议：继续用 OpenSpec+GSD，等 Ruflo 稳定到 v4.x 再评估

5.2 按团队类型选

团队类型	推荐	理由
个人开发者（side project）	OpenSpec 或不用	轻量，快速，不强制流程
个人开发者（要商业化的产品）	Spec Kit	从第一天就有完整治理，未来交接/融资/合规不慌
小团队（2-5 人，新项目）	Spec Kit	Constitution 统一团队编码标准，门禁避免跳步
小团队（2-5 人，有存量项目）	OpenSpec	零迁移成本，先跑起来
中型团队（5-20 人，有存量项目）	OpenSpec + GSD	日常用 OpenSpec 迭代，马拉松任务用 GSD 管理
大团队（20+人）	超出本文范围	需评估 CI/CD 集成、权限管理、合规要求

---

6. 风险清单：选之前必须知道的

框架	必须知道的风险	严重程度
GSD	完整自动化需 --dangerously-skip-permissions，企业安全策略可能不允许	中
GSD	完全自主模式下 AI 可能在你不知情时做架构决策	中
gstack	无发布版本号——升级不可预期，回滚无锚点	高
gstack	企业案例仅作者一人，Hacker News 争议大（被指"名人效应"）	高
Spec Kit	Constitution 可能被 AI 忽略（EPAM 案例确认）——必须写"为什么"	中
Spec Kit	存量项目全量 spec 重写摩擦大（ThoughtWorks 报告确认）	中
Spec Kit	指令膨胀（instruction bloat）导致上下文消耗增加	中
Ruflo	内存泄漏 + 16 个测试失败 + Windows 崩溃——不适合生产	致命
Ruflo	1,480 个发布 = break change 概率极高	高
OpenSpec	无强制门禁——不自律的团队可能跳步	低
OpenSpec	品牌认知度低于 Spec Kit（46K vs 93K stars）	低

---

7. 一页总结

┌─────────────────────────────────────────────────────────┐
│                    五大编排框架 决策速查                    │
├──────────┬──────────┬──────────┬──────────┬──────────────┤
│          │  Spec Kit│ OpenSpec │   GSD    │    gstack    │
├──────────┼──────────┼──────────┼──────────┼──────────────┤
│ 0→1 商业 │  ✅ 首选  │  可用    │  太重    │   慎用       │
│ 1→10 迭代│  有摩擦  │  ✅ 首选  │  ✅ 组合  │  收益有限    │
│ 存量项目  │  侵入高  │ ✅ 零侵入 │  需整理  │  学习成本高  │
│ 企业治理  │ ✅ 最完整 │  基础    │  基础    │   弱         │
│ 搭配装    │  别搭配  │ ✅ 可+GSD │ ✅ 可+OS │  别搭配     │
│ 生产就绪  │  ✅     │  ✅      │  ✅      │  ⚠️ 无版本号 │
├──────────┼──────────┼──────────┼──────────┼──────────────┤
│  Ruflo    │ 目前不推荐用于任何商业场景（截至 2026-05）     │
└──────────┴──────────┴──────────┴──────────┴──────────────┘

如果你只能记住一句：
  新项目要治理 → Spec Kit
  老项目要迭代 → OpenSpec
  跨天马拉松 → GSD
  目前别碰 → Ruflo
  gstack → 除非你确定知道为什么要用 Garry Tan 的个人工具

---

方法论声明： 本文每个结论基于以下来源的交叉验证——各框架 GitHub 仓库（README、Issues、Discussions）、官方文档、ThoughtWorks 技术雷达（2026-04）、EPAM 案例研究、得物技术团队公开文章、ic.work 独立分析、Hacker News 社区讨论、AugmentCode/XDA Developers 等独立评测。所有数据抓取于 2026-05-09。Stars 数和版本号是动态数据，以你阅读时的实际值为准。