Superpowers、gstack、Waza、Ruflo：AI 编码工作流框架对比与选型
1. 引言
Claude Code、Codex CLI、Cursor 等工具让自然语言驱动开发成为日常，但一个新问题浮现：AI 代理经常跳过关键步骤——不澄清需求就写代码，不测试就提交，不评审就合并。
一批开源项目尝试用结构化工作流解决这个问题。它们把需求澄清、架构设计、TDD、代码评审、安全审计等工程实践封装为"技能"（skills），让 AI 代理像有经验的工程师一样按流程工作。
四个代表性项目：
- Superpowers：方法论即代码，自动触发工作流
- gstack：虚拟工程团队，覆盖完整 Sprint
- Waza：轻量工匠习惯，八个核心技能
- Ruflo：企业级多代理 Swarm 编排
2. 项目速览
| 维度 | Superpowers | gstack | Waza | Ruflo |
|---|---|---|---|---|
| 仓库 | obra/superpowers | garrytan/gstack | tw93/waza | ruvnet/ruflo |
| 作者 | Jesse Vincent (@obra) | Garry Tan (YC CEO) | tw93 | Reuven Cohen (ruvnet) |
| 定位 | 软件开发方法论 | 虚拟工程团队 | 工程师习惯工具包 | 企业多代理编排 |
| 技能数量 | ~12 核心技能 | 23+ 角色 + 8 工具 | 8 技能 | 100+ 代理 + 20 插件 |
| 触发方式 | 自动触发（基于上下文） | 手动斜杠命令 | 手动斜杠命令 | 自动路由 + 手动命令 |
| 代码量 | 纯 Markdown 技能 | TypeScript + Markdown | 纯 Markdown（零代码） | TypeScript + Rust(WASM) |
| 支持平台 | Claude, Codex, Cursor, Copilot, Gemini, OpenCode | Claude, Codex, Cursor, OpenCode, Factory, Slate, Kiro, Hermes, OpenClaw | Claude Code, Codex | Claude Code (MCP 原生) |
| 核心哲学 | Systematic over ad-hoc | Think → Plan → Build → Review → Test → Ship → Reflect | 克制，少即是多 | Swarm 智能，自学习优化 |
| 许可证 | MIT | MIT | MIT | MIT |
Superpowers 和 Waza 偏向方法论与习惯，gstack 和 Ruflo 偏向团队角色与系统编排。这个分野决定了不同场景下的选型。
3. 深度解析
3.1 Superpowers：方法论即代码
Superpowers 由 Jesse Vincent（Prime Radiant 创始人）构建，其核心假设是：AI 代理最大的风险不是写不出代码，而是跳过思考过程。因此，Superpowers 设计了一套自动触发的技能链，从开发者说出"我想做 X"的那一刻起，代理就被强制进入结构化工作流。
核心工作流：
- Brainstorming（头脑风暴）：代理不立即写代码，而是通过苏格拉底式提问澄清需求。"你真正想解决什么问题？""有哪些约束条件？""有没有更简单的方案？"
- Writing Plans（撰写计划）：将设计拆分为 2-5 分钟可完成的微任务，每个任务包含精确文件路径、预期变更和验证步骤。
- Subagent-driven Development（子代理开发）：为每个任务派遣全新的子代理，执行后经过两阶段评审（规范符合性 + 代码质量）。
- Test-driven Development（测试驱动开发）：强制 RED-GREEN-REFACTOR 循环。先写失败测试，再写最小通过代码，最后重构。代理会删除在测试之前写的任何代码。
- Requesting Code Review（代码评审）：任务间自动触发评审，按严重程度报告问题，关键问题阻断进度。
- Finishing a Branch（完成分支）：验证测试、呈现选项（合并 / 提 PR / 保留 / 丢弃）、清理 Git worktree。
Superpowers 的贡献指南中对 AI 代理的警告极其严厉——"本仓库 PR 拒绝率 94%。提交低质量 PR 不是帮助人类伙伴，而是让他们丢脸。"这种对质量的极致追求，贯穿整个设计。
适用场景：
- 需要严格工程纪律的团队，尤其是信奉 TDD 和系统方法论的开发者
- 复杂功能开发，需要多轮迭代和严格评审
- 跨平台团队（Superpowers 支持 6+ 种 AI 编码助手）
不适合：
- 快速原型或脚本编写（强制工作流会显得笨重）
- 完全不接受测试驱动开发的团队
3.2 gstack：一个人的工程团队
如果说 Superpowers 是"方法论的强制执行者"，gstack 就是"创业团队的完整模拟器"。Garry Tan（Y Combinator CEO）开源了他在管理 YC 的同时仍能高频 shipping 的工具链。按他自己的统计，60 天内以兼职时间交付了 3 个生产服务、40+ 功能，逻辑代码变更速度是 2013 年的 810 倍（注：该数据为作者自述，方法论见 gstack 仓库中的 docs/ON_THE_LOC_CONTROVERSY.md）。
核心工作流——Sprint 七步：
| 阶段 | 技能 | 模拟角色 |
|---|---|---|
| Think | /office-hours | YC 合伙人 |
| Plan | /plan-ceo-review, /plan-eng-review, /plan-design-review | CEO / 工程师 / 设计师 |
| Build | 自然语言指令 | 开发者 |
| Review | /review, /codex | 资深工程师 + OpenAI Codex 交叉评审 |
| Test | /qa | QA 负责人（真实浏览器测试） |
| Ship | /ship, /land-and-deploy | 发布工程师 |
| Reflect | /retro | 工程经理 |
杀手级功能：
- 真实浏览器 QA（
/qa）：启动基于 Playwright 的 Chromium，实际点击页面流程、发现 bug、生成回归测试、提交修复。代理从"盲写代码"变成了"有眼睛的测试员"。据 Garry Tan 自述，这项功能将他的并行工作流从 6 个提升到 12 个。 - 设计探索管线（
/design-shotgun→/design-html）：生成 4-6 个 AI 设计变体，在浏览器中并排比较，收集反馈后迭代。"品味记忆"会学习你偏好的风格。然后将选定设计转为生产级 HTML/CSS（使用 Pretext 计算布局，30KB 零依赖）。 - 跨模型第二意见（
/codex）：让 OpenAI Codex CLI 独立评审同一份代码 diff，生成交叉模型分析报告——哪些发现重叠，哪些是某模型独有。 - 安全护栏（
/careful,/freeze,/guard）：破坏性命令前警告、锁定编辑范围、两者同时激活。 - 团队模式（
./setup --team）：共享仓库自动同步配置，消除版本漂移。
gstack 不是技能集合，而是流程编排。每个技能的输出自动成为下一个技能的输入。/office-hours 写出的设计文档，被 /plan-ceo-review 读取；/plan-eng-review 的测试计划，被 /qa 继承。
适用场景：
- 独立开发者 / 创始人：模拟完整团队，弥补人力不足
- 小团队（2-5 人）：标准化开发流程，减少沟通成本
- 需要设计+前端+QA 全栈覆盖的项目：gstack 是唯一提供完整设计到测试管线的框架
不适合：
- 已有成熟流程和专门团队的大型企业（可能与现有流程冲突）
- 纯后端 / CLI 工具项目（设计相关技能浪费）
3.3 Waza：克制的工匠习惯
Waza（日语"技"，意为练至本能的技巧）由 tw93 创建，是四个项目中最轻量的。它的 README 第一句话就表明了立场："Engineering habits you already know, turned into skills Claude can run."
核心设计哲学：
"AI 让你更快，但不一定让你想得更清楚、ship 得更谨慎、理解得更深入。"
Waza 明确将自己定位为 Superpowers 和 gstack 的轻量替代：
"Tools like Superpowers and gstack are impressive, but they are heavy. Too many skills, too much configuration, too steep a learning curve for engineers who just want to get things done."
八个技能：
| 技能 | 触发时机 | 作用 |
|---|---|---|
/think | 开始新功能前 | 挑战需求、压力测试设计、验证架构 |
/design | 前端界面开发 | 产出有明确美学方向的设计，非通用默认 |
/check | 任务完成后、合并前 | 评审 diff、自动修复安全问题、标记破坏性命令 |
/hunt | 遇到 bug | 系统化调试，确认根因后再修复 |
/write | 撰写或编辑文章 | 重写中英文文本，去除 AI 公式化表达 |
/learn | 进入陌生领域 | 六阶段研究：收集 → 消化 → 大纲 → 填充 → 精炼 → 自评 |
/read | 阅读 URL 或 PDF | 获取干净 Markdown，支持 GitHub/微信/飞书/PDF 路由 |
/health | 审计 Claude Code 配置 | 检查 CLAUDE.md、规则、技能、MCP、行为 |
关键差异——手动触发 vs 自动触发：
Waza 的技能不会自动链式触发。每个技能完成自己的任务后停止，等待用户决定下一步。这种"手动变速箱"设计是有意为之：
"Every rule the author writes becomes a ceiling. The model can only do what the instructions say and can't go further. Waza goes the other direction. Each skill sets a clear goal and the constraints that matter, then steps back."
Extras：
- Statusline：终端状态栏显示上下文窗口使用率和 API 配额
- English Coaching：被动语法纠正规则，在会话中标记英文错误并教授规则
适用场景：
- 个人开发者：想要更好的工程习惯，但不想被重框架束缚
- 已有成熟流程的团队：只需在关键节点（设计前、合并前、调试时）插入检查点
- 中英文混合工作环境：
/write和/read对中文开发者极实用
不适合：
- 需要全自动 Sprint 管理的团队
- 需要多代理并行协作的复杂项目
3.4 Ruflo：企业级多代理编排
Ruflo（原名 Claude Flow）由 Reuven Cohen 创建，是四个项目中最重、最企业级的方案。如果说 gstack 模拟的是"一个虚拟团队"，Ruflo 模拟的是"一个虚拟公司"。
架构概览：
User → Claude Code / CLI
|
v
Orchestration Layer (MCP Server, Router, 27 Hooks)
|
v
Swarm Coordination (Queen, Topology, Consensus)
|
v
100+ Specialized Agents (coder, tester, reviewer, architect...)
|
v
Memory & Learning (AgentDB, HNSW, SONA, ReasoningBank)
|
v
LLM Providers (Claude, GPT, Gemini, Cohere, Ollama)
核心能力：
- Swarm 协调：支持层级（Queen-led）、网状（Mesh）、环形（Ring）、星形（Star）拓扑，集成 Raft、拜占庭容错（BFT）、Gossip、CRDT 共识协议。
- 自学习（SONA）：使用 Q-Learning 路由器和专家混合模型（MoE），持续优化任务分配。路由准确率达 89%。
- 向量记忆（AgentDB）：HNSW 索引的向量数据库，据项目文档称搜索速度比传统方案快 150-12,500 倍。支持弹性权重整合（EWC），防止灾难性遗忘。
- 背景工作者：12 个自动触发的工作线程（审计、优化、测试缺口检测等）。
- 插件市场：20 个原生 Claude Code 插件 + 20 个 npm 插件，可按需安装。
- 多提供商：Claude、GPT、Gemini、Cohere、Ollama，智能故障转移。
Ruflo 的入口设计相对轻量——安装后，用户不需要学习 314 个 MCP 工具或 26 个 CLI 命令，只需正常使用 Claude Code，hooks 系统会在后台自动路由任务、学习成功模式、协调代理。
适用场景：
- 企业级复杂系统：需要多代理协作的大型代码库
- 安全敏感环境：AIDefence、CVE 修复、路径遍历防护
- 需要跨模型冗余：多 LLM 提供商故障转移
- 长期项目：需要代理记忆和学习能力持续积累
不适合：
- 个人 side project（过重）
- 团队规模小于 5 人（无法发挥 Swarm 优势）
- 预算受限（多代理 + 多提供商成本高）
4. 横向对比
4.1 复杂度与控制力
| 项目 | 复杂度 | 控制力 | 学习曲线 |
|---|---|---|---|
| Waza | 低 | 高（用户完全控制每一步） | 30 分钟 |
| Superpowers | 中 | 中（工作流自动触发，但可覆盖） | 2 小时 |
| gstack | 高 | 中（流程编排严密，但技能众多） | 1-2 天 |
| Ruflo | 极高 | 低（系统自动协调，用户干预少） | 1 周+ |
Waza 是"手动变速箱"，给用户最大控制权，适合喜欢微操的工程师。Ruflo 是"自动驾驶"，系统接管大部分决策，适合愿意让渡控制换取规模的企业。Superpowers 和 gstack 位于中间，前者偏向"强制纪律"，后者偏向"角色分工"。
4.2 自动化程度
| 项目 | 触发方式 | 技能间协作 | 用户干预频率 |
|---|---|---|---|
| Waza | 手动 | 无（独立技能） | 每个步骤 |
| Superpowers | 上下文自动触发 | 链式自动推进 | 关键决策点 |
| gstack | 手动斜杠命令 | 输出自动成为下游输入 | 每个阶段 |
| Ruflo | Hooks 自动路由 + 手动 | Swarm 自动协调 | 异常处理 |
自动化程度与用户控制权成反比。Waza 的完全手动设计不是缺陷，而是针对"AI 规则成为天花板"问题的刻意回应。
4.3 团队规模适配
| 团队规模 | 推荐项目 | 理由 |
|---|---|---|
| 1 人（独立开发者） | Waza 或 gstack | Waza 轻量不碍事；gstack 弥补团队缺失 |
| 2-5 人（初创团队） | Superpowers 或 gstack | 标准化流程，减少磨合成本 |
| 5-20 人（成长团队） | gstack（团队模式） | ./setup --team 自动同步配置 |
| 20+ 人（企业团队） | Ruflo | Swarm 协调、安全加固、多提供商冗余 |
4.4 平台兼容性
| 项目 | Claude Code | Codex | Cursor | OpenCode | Copilot | Gemini | 其他 |
|---|---|---|---|---|---|---|---|
| Superpowers | ✅ 官方插件 | ✅ | ✅ 插件 | ✅ | ✅ | ✅ | OpenCode |
| gstack | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | Factory, Slate, Kiro, Hermes, OpenClaw |
| Waza | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | — |
| Ruflo | ✅ MCP 原生 | ❌ | ❌ | ❌ | ❌ | ❌ | — |
Superpowers 的跨平台支持最全面；gstack 次之，但增加了 OpenClaw 等新兴代理；Waza 和 Ruflo 主要绑定 Claude Code 生态。
5. 工作场景应用指南
场景一：快速原型与 Side Project
特征：1-2 周交付，快速验证想法，代码质量要求中等 推荐：Waza 使用方式：
- 开始功能前运行
/think澄清需求（5 分钟） - 前端开发时运行
/design获得有方向的设计 - 完成功能后
/check评审 diff - 遇到 bug 用
/hunt系统化调试
为什么不选其他：Superpowers 的强制 TDD 会拖慢原型速度；gstack 的完整 Sprint 流程对短期项目过度设计；Ruflo 的企业级架构完全没必要。
场景二：初创公司 MVP 迭代
特征：2-5 人团队，高频迭代，需要设计+前端+后端+测试 推荐：gstack 使用方式：
- 新功能：
/office-hours→/autoplan→ 实现 →/review→/qa→/ship - 设计迭代：
/design-shotgun探索视觉方案 →/design-html生产化 - 安全合规：定期
/cso运行 OWASP + STRIDE 审计 - 团队协作：启用 Team Mode，确保所有人使用相同配置
gstack 的设计到测试管线对初创公司最完整。很多初创公司没有专职设计师和 QA，/design-consultation 和 /qa 填补了这些角色空缺。
场景三：中型团队产品功能开发
特征：5-15 人，已有代码库，需要保持代码质量和一致性 推荐：Superpowers 使用方式：
- 安装后无需额外操作，工作流自动触发
- 代理会自动 Brainstorm → Plan → TDD Implement → Review
- 复杂任务使用
subagent-driven-development并行处理 - 利用
using-git-worktrees保持主分支干净
Superpowers 的"零摩擦"设计最适合已有流程的团队。不需要学习 23 个斜杠命令，代理在后台自动执行方法论。TDD 强制对技术债务累积的代码库尤其有价值。
场景四：企业级复杂系统维护
特征：20+ 人，多团队协作，安全合规要求高，系统复杂 推荐：Ruflo 使用方式：
- 安装
ruflo-core+ruflo-swarm+ruflo-security-audit - 配置多提供商故障转移（Claude 为主，GPT/Gemini 备用）
- 启用背景工作线程：自动审计、测试缺口检测、文档漂移检测
- 复杂重构任务使用 Swarm 协调，分配 coder/reviewer/architect 角色
Ruflo 的共识协议和安全加固对企业环境至关重要。当多个代理同时修改共享代码库时，Raft/BFT 共识防止冲突。AIDefence 和 CVE 扫描满足合规要求。
场景五：个人技能提升与习惯养成
特征：开发者希望提升工程习惯，不特定于某个项目 推荐：Waza 使用方式：
- 全局安装
npx skills add tw93/Waza - 遇到任何新领域先用
/learn建立研究框架 - 写技术博客时用
/write润色中英文 - 定期
/health检查 Claude Code 配置健康度
Waza 的"习惯"定位使其超越特定项目，成为开发者的通用工具包。English Coaching 对中文开发者尤其有价值。
6. 选择与实施建议
渐进式实施路径
不要试图一次性引入最重的框架。建议按以下路径渐进：
第一步（本周）：安装 Waza
- 零配置，8 个技能立即可用
- 在 1-2 个任务中试用
/think和/check - 建立"技能辅助开发"的肌肉记忆
第二步（下个月）：如果团队需要更严格的流程，引入 Superpowers
- 安装后观察自动触发的工作流
- 重点体验 TDD 强制和子代理开发
- 评估是否适配团队的工程文化
第三步（季度）：如果是初创团队且需要填补角色空缺，升级到 gstack
- 从
/office-hours和/review开始 - 逐步引入
/qa和/ship - 启用 Team Mode 统一团队配置
第四步（年度）：如果企业规模扩大且需要多代理编排，评估 Ruflo
- 从核心插件开始，按需扩展
- 建立 Swarm 治理规范
- 培训团队使用 hooks 自动路由
决策树
你是个人开发者还是团队？
├── 个人 → 需要设计/QA 覆盖？
│ ├── 是 → gstack
│ └── 否 → Waza
└── 团队 → 团队规模？
├── <5 人 → 需要完整 Sprint 流程？
│ ├── 是 → gstack
│ └── 否 → Superpowers
├── 5-20 人 → 已有成熟流程？
│ ├── 是 → Superpowers（无缝嵌入）
│ └── 否 → gstack（建立流程）
└── 20+ 人 → 需要多代理编排？
├── 是 → Ruflo
└── 否 → gstack（团队模式）
组合使用
这四个项目并非互斥。实际上，它们可以组合：
- Waza + Superpowers：用 Waza 的
/think做前期思考，用 Superpowers 的自动工作流做后续实现 - gstack + Waza：在 gstack 的 Sprint 流程中，用 Waza 的
/check替代/review做轻量评审 - Superpowers + Ruflo：Superpowers 负责单代理工作流，Ruflo 负责多代理 Swarm 协调
实际使用中，以 Waza 打底建立基本习惯，按团队需求叠加更重的框架，往往比一次性引入大框架更顺畅。
冲突与共存
虽然上面讨论了组合使用，但同时安装全部四个项目必然产生冲突。问题不是功能重叠，而是控制权的争夺。
直接冲突点：
| 冲突类型 | 具体表现 | 涉及项目 |
|---|---|---|
| 命令覆盖 | /learn：gstack 和 Waza 都有此命令，Claude Code 无法确定调用哪个 | gstack + Waza |
| CLAUDE.md 覆盖 | gstack 要求注入大段配置；Waza 的 /health 会审计并可能标记这些配置为"非标准"；Superpowers 通过插件隐式修改行为 | 三者互相影响 |
| 自动触发干扰 | 你想用 gstack 的 /office-hours 做产品诊断，Superpowers 检测到"新功能开发"上下文，自动启动 brainstorming，两个流程在同一个会话中重叠 | Superpowers + gstack |
| 工作流逻辑矛盾 | Superpowers 强制"先写测试再写代码"，代理会删除测试之前写的代码；gstack 的 /ship 有自己的测试覆盖审计标准，两者要求可能不同 | Superpowers + gstack |
| 后台 Hooks 竞争 | Ruflo 的 27 个 hooks 自动路由任务，如果检测到"代码评审"并自动派发代理，而此时 gstack 的 /review 也在运行，会出现重复评审 | Ruflo + gstack/Superpowers |
最危险的组合：Superpowers + gstack
两者都是完整的流程框架，但哲学互斥。Superpowers 是"方法论强制"，gstack 是"角色模拟"。同时安装时，代理会在一个会话中收到两套矛盾的指令：Superpowers 要求自动触发 TDD 循环，gstack 要求等待用户输入 /ship 才能发布。结果是不可预测的——代理可能在写测试和写代码之间反复横跳，或者在未评审的情况下尝试发布。
相对安全的组合：
- Waza + 任意框架：Waza 是手动触发、零代码，不修改 CLAUDE.md（除了
/health审计），冲突最小。可以作为基底叠加其他框架的特定技能。 - gstack（带前缀）+ Waza：运行
./setup --prefix，将所有命令转为/gstack-qa、/gstack-review，避免覆盖 Waza。 - Ruflo + Superpowers：Ruflo 主要工作在后台编排层，Superpowers 负责单代理工作流，两者分层明确。但需要关闭 Ruflo 的自动任务路由，改为手动触发 Swarm。
共存策略：
- 分项目隔离：Claude Code 的 CLAUDE.md 和技能配置是项目级的。在项目 A 使用 gstack，项目 B 使用 Superpowers，互不影响。
- 启用命名空间：如果必须在同一项目中使用 gstack 和其他框架，用
--prefix或--no-prefix管理命令名。 - 禁用自动触发：Superpowers 的自动技能触发可以通过配置关闭，改为手动调用。这是与 gstack 共存的前提。
- 只装子集：不需要安装整个框架。例如，可以只安装 Waza 的
/think和/check，以及 gstack 的/qa，跳过其他技能。
底线建议：不要在一个项目里同时启用 Superpowers 和 gstack。它们是两个互斥的完整流程，强行共存只会导致代理行为混乱。Waza 可以作为通用基底与任何框架搭配，Ruflo 作为企业后台层需要单独评估兼容性。
7. 结语
四个项目的差异本质上是控制权与自动化之间的权衡。
Waza 把控制权完全交给用户，每个技能都是独立的检查点，适合不信任自动化的保守派。Superpowers 在后台强制执行纪律，适合相信方法论但懒得手动触发的人。gstack 用角色分工模拟团队，适合缺少人力的初创公司。Ruflo 用 Swarm 协调接管大规模协作，适合愿意让渡控制权换取规模的企业。
它们没有绝对的优劣，只有与场景匹配与否。但底层逻辑是一致的：当 AI 能一秒写百行代码时，真正稀缺的不是打字速度，而是不跳过思考的能力。
