384 lines
11 KiB
Plaintext
Executable File
384 lines
11 KiB
Plaintext
Executable File
---
|
||
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* |