---
created: 2026-04-27
type: source
tags: [gstack, superpowers, claude-code, workflow, ai-coding, agent, methodolgy]
---

# gstack + Superpowers 联合工作流完全研究

> 当 Garry Tan 的角色分工 遇上 Jesse Vincent 的工程纪律
>
> 研究时间：2026-04-27

---

## 📋 概览

**gstack** 和 **Superpowers** 是 Claude Code 生态中最流行的两个工作流框架，分别解决不同维度的问题：

| 框架 | 核心问题 | 作者 |
|------|---------|------|
| **gstack** | "谁来干？" — **角色分工** | Garry Tan（YC CEO） |
| **Superpowers** | "怎么干？" — **工程纪律** | Jesse Vincent |

两者结合 = **完整的高质量 AI 编程工作流**。

---

## 🧩 定位差异

### gstack：角色驱动（23 个专业角色）

```
你想建什么？  →  CEO 重新定义问题
              →  设计师出方案
              →  工程经理锁架构
              →  QA 测试
              →  安全官审计
              →  发布工程师上线
```

**关键**：每个角色有明确的 **slash 命令**，覆盖产品全生命周期。

### Superpowers：纪律驱动（14 个自动触发技能）

```
你有想法     →  brainstorming（苏格拉底式追问）
              →  writing-plans（拆解任务，每步 2-5 分钟）
              →  subagent-driven-development（子代理逐任务执行）
              →  test-driven-development（RED-GREEN-REFACTOR）
              →  requesting-code-review（代码审查）
              →  finishing-a-development-branch（合并/PR）
```

**关键**：技能 **自动触发**，不需要手动调用。

---

## 🔄 联合工作流

### 完整流程（Think → Ship）

```
┌─────────────────────────────────────────────────┐
│  阶段         │ gstack 角色      │ Superpowers 技能  │
├─────────────────────────────────────────────────┤
│ 1. 想法探索   │ /office-hours    │ brainstorming    │
│ 2. 战略审查   │ /plan-ceo-review │ brainstorming    │
│ 3. 设计       │ /design-review   │ brainstorming    │
│ 4. 工程规划   │ /plan-eng-review │ writing-plans    │
│ 5. 实施       │ /review          │ subagent-driven  │
│               │                  │ test-driven-dev  │
│ 6. 测试       │ /qa              │ systematic-debug │
│ 7. 审查       │ /review          │ code-review      │
│ 8. 发布       │ /ship            │ finishing-branch │
│ 9. 部署       │ /land-and-deploy │ finishing-branch │
│ 10. 监控      │ /canary          │ verification     │
│ 11. 回顾      │ /retro           │ (meta)           │
└─────────────────────────────────────────────────┘
```

### 为什么需要两者？

| 场景 | 只有 gstack | 只有 Superpowers | 两者结合 |
|------|-----------|-----------------|---------|
| 需求模糊 | ✅ CEO 重定义 | ✅ brainstorming | ✅✅ 最佳 |
| 任务拆解 | ⚠️ 较粗 | ✅ 每步 2-5 分钟 | ✅ gstack 方向 + SP 粒度 |
| 代码质量 | ✅ /review 找 bug | ✅ TDD + 两阶段审查 | ✅ 双重保障 |
| 测试覆盖 | ⚠️ /qa 黑盒 | ✅ TDD 强制红绿重构 | ✅ 单元 + 集成 |
| 子代理调度 | ⚠️ 无 | ✅ 逐任务 + 审查 | ✅ gstack 角色审查 SP 子代理产出 |
| 部署上线 | ✅ 完整流程 | ⚠️ 只到 finishing | ✅ gstack 补齐 |
| 安全审计 | ✅ /cso | ❌ 无 | ✅ gstack 独占 |
| 浏览器 QA | ✅ /qa 真实浏览器 | ❌ 无 | ✅ gstack 独占 |

---

## 🎯 核心 Superpowers 技能详解

### 1️⃣ brainstorming（想法探索）

**触发时机**：在写代码之前

**工作方式**：
- 苏格拉底式追问（不是直接给方案）
- 探讨多种实现路径
- 把设计文档分块展示，让你逐段确认
- 最终产出设计文档

**示例**：
```
你：我想做一个日历每日简报应用
Superpowers：[问 6 个强制问题]
            [挑战你的框架：你不是要"简报"，是"AI 参谋"]
            [产出 3 种实现方案 + 工作量估算]
```

### 2️⃣ writing-plans（写计划）

**核心原则**：
- 每个任务 2-5 分钟
- 精确到文件路径
- 包含完整代码和验证步骤
- DRY / YAGNI / TDD / 频繁提交

**计划格式**：
```
## Task N: [组件名]

Files:
- Create: src/path/file.py
- Modify: existing/path/file.py:123-145
- Test: tests/path/test.py

- [ ] Step 1: 写失败的测试（含代码）
- [ ] Step 2: 运行测试确认失败（含命令+预期输出）
- [ ] Step 3: 写最小实现（含代码）
- [ ] Step 4: 运行测试确认通过（含命令+预期输出）
- [ ] Step 5: 提交（含 git 命令）
```

**严禁**：
- ❌ "TBD" / "TODO" / "后续补充"
- ❌ "添加适当的错误处理"
- ❌ "类似 Task N"（必须重复完整代码）

### 3️⃣ subagent-driven-development（子代理驱动开发）

**核心流程**（每任务）：

```
1. 调度实现者子代理
   ↓
2. 实现者工作（实现+测试+提交+自审）
   ↓
3. 调度规格审查者子代理
   ↓  ✅ 规格匹配？ → 下一步
   ↓  ❌ 不匹配 → 实现者修复 → 重审
   ↓
4. 调度代码质量审查者子代理
   ↓  ✅ 质量通过？ → 标记完成
   ↓  ❌ 质量问题 → 实现者修复 → 重审
   ↓
5. 下一个任务...
```

**模型路由**（省钱策略）：
- 机械实现任务（1-2 文件）→ **便宜模型**
- 集成调试任务（多文件协调）→ **标准模型**
- 架构设计/审查 → **最强模型**

### 4️⃣ test-driven-development（测试驱动）

**RED-GREEN-REFACTOR 循环**：

```
RED   → 写一个失败的测试
        运行确认它确实失败了

GREEN → 写最少代码让它通过
        运行确认它通过了

REFACTOR → 重构代码，保持测试通过
           提交
```

**强制**：先写测试！不是写完代码再补测试。

### 5️⃣ systematic-debugging（系统化调试）

**4 阶段根因追踪**：
1. 复现问题
2. 追踪数据流
3. 测试假设
4. 修复 + 验证

**铁律**：没有调查就不能修 bug！最多尝试 3 次后停止。

### 6️⃣ requesting-code-review（代码审查）

**审查清单**：
- 规格覆盖度
- 边界情况
- 错误处理
- 测试覆盖
- 代码质量

### 7️⃣ finishing-a-development-branch（完成分支）

**流程**：
- 运行全部测试
- 展示选项（合并/PR/保留/丢弃）
- 清理 worktree

---

## 🏗️ gstack 角色详解（23 个）

### 战略规划

| 命令 | 角色 | 与 SP 协作点 |
|------|------|-------------|
| `/office-hours` | 产品顾问 | 衔接 `brainstorming` |
| `/plan-ceo-review` | CEO | 战略审查，4 种范围模式 |

### 设计

| 命令 | 角色 |
|------|------|
| `/plan-design-review` | 高级设计师（0-10 评分） |
| `/design-shotgun` | 生成 4-6 个方案变体 |
| `/design-html` | 设计稿 → 可投产 HTML |

### 工程

| 命令 | 角色 | 与 SP 协作点 |
|------|------|-------------|
| `/plan-eng-review` | 工程经理 | 衔接 `writing-plans` |
| `/review` | 资深工程师 | 衔接 `code-review` |
| `/investigate` | 调试员 | 衔接 `systematic-debugging` |

### 测试/质量

| 命令 | 角色 | 与 SP 协作点 |
|------|------|-------------|
| `/qa` | QA 负责人 | 衔接 `verification` |
| `/cso` | 安全官 | gstack 独占 |

### 发布/运维

| 命令 | 角色 | 与 SP 协作点 |
|------|------|-------------|
| `/ship` | 发布工程师 | 衔接 `finishing-branch` |
| `/land-and-deploy` | 发布工程师 | gstack 独占 |
| `/canary` | SRE | gstack 独占 |

---

## 🚀 联合使用示例

### 完整功能开发

```
你：我想加一个通知功能

你：/office-hours
       ← gstack: CEO 重新定义问题
       ← SP: brainstorming 追问

你：我想清楚了，就是要推送通知
       ← SP: brainstorming 产出设计文档

你：/plan-ceo-review
       ← gstack: CEO 战略审查

你：/plan-eng-review
       ← gstack: 工程经理锁架构
       ← SP: writing-plans 拆解任务

你：开始实施
       ← SP: subagent-driven-development
              每任务：实现 → 规格审查 → 质量审查

你：/review
       ← gstack: 资深工程师找生产 bug
       ← SP: code-review 审查清单

你：/qa https://staging.myapp.com
       ← gstack: 打开真实浏览器测试
       ← SP: systematic-debugging 修 bug

你：/ship
       ← gstack: 测试+PR
       ← SP: finishing-branch 收尾
```

---

## 🔗 claude-flow：一键集成

[**claude-flow**](https://github.com/hgahlot/claude-flow) 项目把 gstack + Superpowers 和其他工具打包在一起：

| 组件 | 功能 |
|------|------|
| **gstack** | 25 技能（QA/审查/发布/部署/监控） |
| **Superpowers** | 14 自动触发技能（TDD/调试/子代理） |
| **GSD** | 50 命令 + 17 Agent（规格驱动生命周期） |
| **UI/UX Pro Max** | 67 风格 + 96 配色 + 57 字体 |
| **Claude-Mem** | SQLite 跨会话记忆 |
| **ralph-wiggum** | 自主迭代循环 |
| **/flow** | 统一命令路由 |
| **/discover** | 每周发现新工具 |

**一键安装**：
```bash
cd /your/project
git clone https://github.com/hgahlot/claude-flow.git /tmp/claude-flow
bash /tmp/claude-flow/setup.sh
```

---

## 📊 对比总结

| 维度 | gstack | Superpowers | 联合效果 |
|------|--------|------------|---------|
| **关注点** | 角色分工 | 工程纪律 | 角色 + 纪律 |
| **触发方式** | 手动命令 | 自动触发 | 自动 + 手动 |
| **规划粒度** | 较粗 | 每步 2-5 分钟 | gstack 方向 + SP 粒度 |
| **测试** | 黑盒浏览器测试 | TDD 强制红绿重构 | 单元 + 集成 |
| **审查** | 单次 | 两阶段（规格+质量） | 双重保障 |
| **部署** | 完整 | 只到合并 | gstack 补齐 |
| **安全** | OWASP+STRIDE | 无 | gstack 独占 |
| **子代理** | 无 | 逐任务调度 | SP 执行 + gstack 审查 |

---

## 📌 最佳实践

### 什么时候用 gstack？

- 需要**角色审查**（CEO/设计师/安全官）
- 需要**真实浏览器 QA**（/qa）
- 需要**部署上线**（/ship, /land-and-deploy）
- 需要**安全审计**（/cso）
- 需要**生产监控**（/canary）

### 什么时候用 Superpowers？

- **TDD** 强制（先写测试）
- **任务拆解**（每步 2-5 分钟）
- **子代理调度**（逐任务 + 两阶段审查）
- **系统化调试**（4 阶段根因追踪）
- **代码审查**（自动化审查清单）

### 什么时候两者都用？

- **完整功能开发**：gstack 提供角色 + Superpowers 提供纪律
- **新项目启动**：gstack 的 /office-hours + Superpowers 的 brainstorming
- **复杂重构**：gstack 的 /review + Superpowers 的 TDD

---

## 🔧 安装建议

### 方案一：两者独立安装（推荐新手）

```bash
# 安装 gstack
git clone --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

# 安装 Superpowers（在 Claude Code 中）
/plugin install superpowers@claude-plugins-official
```

### 方案二：claude-flow 一键安装（推荐进阶）

```bash
git clone https://github.com/hgahlot/claude-flow.git /tmp/claude-flow
bash /tmp/claude-flow/setup.sh
```

---

*研究完成时间：2026-04-27 11:00*