原文地址【带图片】：gstack 深度解析：让 Claude Code 化身虚拟工程团队的角色驱动工作流

一、gstack 是什么

gstack 是一套开源（MIT 协议）的 Claude Code 自定义斜杠命令集合，由 Garry Tan 创建并维护。它在 GitHub 上已获得超过 80,000 颗星，被社区广泛认为是 2026 年 AI 编程工具链中最具影响力的项目之一。

它的核心理念可以用一句话概括：

把 AI 从一个「写代码的助手」，升级成一个「完整的虚拟工程团队」。

这个团队里有什么角色？CEO、工程经理、设计师、QA 负责人、安全官、发布经理——gstack 的每一个 / 命令都对应一个特定角色，该角色有明确的职责边界和行为约束。

Garry Tan 本人用这套系统在 60 天内交付了超过 60 万行生产级代码（其中 35% 是测试代码），同时还在全职运营 Y Combinator。他在 2026 年的 GitHub 贡献数达到 1,237 次，超过了 2013 年时的纪录。

gstack 不引入任何新框架——它不依赖 LangGraph、CrewAI 或其他 Agent 编排库。每个 skill 就是一段结构化的 Markdown 提示词，通过 Claude Code 的 skills 机制加载。这种极简设计意味着：零运行时开销、安装只需 30 秒、可以直接阅读和修改提示词源码。

---

二、核心理念：角色驱动 vs 流程驱动

要理解 gstack，首先要理解它的设计哲学。

2.1 每个角色只做一件事，且禁止跨界

gstack 最核心的设计原则是严格的角色边界：

• /review — 只能找 bug，禁止修 bug。修 bug 是开发者的工作，reviewer 修了就无法客观判断
• /ship — 只负责发布流程（测试→版本号→changelog→commit→PR），禁止讨论产品方向
• /office-hours — 只做产品层面的质疑和追问，不涉及技术实现

这种约束刻意模拟了真实团队中的专业分工。一个设计师不会替后端工程师做架构决策，一个 QA 不会因为「这个功能看起来不错」就跳过测试。角色边界是质量保证的第一道防线。

2.2 「Boil the Lake」原则

gstack 的设计文档中提到了一个有趣的比喻——Boil the Lake（把湖煮沸）：

做好你能做的事，跳过你做不好的事。不要为了完成一个任务而去发明一个还不存在的能力。

翻译成实践就是：如果某个 skill 在当前项目状态下无法高质量完成工作，它应该诚实地告知用户，而不是硬上。比如 /qa 在没有浏览器配置的情况下会直接说「我无法测试」，而不是随便跑几个命令敷衍。

2.3 与 Superpowers 的哲学差异

如果你读过本站的 Superpowers 文章，这里有一个直观的对比：

	Superpowers	gstack
核心理念	流程驱动——强制执行 TDD 铁律	角色驱动——模拟多视角判断
谁来判断	流程规则判断（红→绿→重构）	角色视角判断（CEO 怎么看？设计师怎么看？）
自动化程度	高——自动触发 7 阶段工作流	中——手动按需调用角色
最适合	工程师追求代码质量和执行纪律	Founder 需要产品思维和多视角验证

一句话总结：Superpowers 确保你「把代码写对」，gstack 确保你「写的是对的代码」。

---

三、安装与配置

3.1 前提条件

• Claude Code 已安装并认证
• Git
• Bun v1.0+（Windows 下可用 Node.js 替代）

3.2 安装步骤

git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

安装完成后，所有 skill 存放在 ~/.claude/skills/gstack/ 目录下。不会修改 PATH，不会启动后台进程。

如果需要团队共享，可以将 skill 安装到项目级别：

cp -Rf ~/.claude/skills/gstack .claude/skills/gstack
rm -rf .claude/skills/gstack/.git
cd .claude/skills/gstack && ./setup

3.3 配置路由规则

安装后需要在 CLAUDE.md 中添加路由规则，告诉 Claude 什么时候使用哪个 skill。一个推荐的配置模式：

# CLAUDE.md 路由规则

## gstack 角色路由
- 当需要产品决策、范围判断时，使用 /office-hours 或 /plan-ceo-review
- 当需要架构审查时，使用 /plan-eng-review
- 当代码准备合并前，使用 /review 进行代码审查
- 当需要端到端测试时，使用 /qa
- 当准备发布时，使用 /ship

---

四、完整角色阵容拆解

截至 2026 年 4 月，gstack 包含 23 个角色化 skill。下面按开发阶段分组逐一介绍。

4.1 思考阶段：把方向想清楚

/office-hours — 模拟 YC 合伙人办公时间。用 6 个强制问题重构你的产品定位：你要解决什么问题？谁是你的用户？现有方案为什么不够好？这个 skill 不会写一行代码，但可能帮你省下几周的无效开发。

/plan-ceo-review — CEO 视角的范围挑战。核心工作是审视你的计划，问「这个功能真的值得做吗？」和「有没有更简单的方式达到同样目的？」。它会主动砍需求——这在 AI 编程中反而是稀缺能力。

/plan-eng-review — 工程经理视角的架构审查。锁定数据流、API 边界、错误处理策略和扩展点。输出是一份架构决策记录，后续的 /review 和 /qa 都会对照这份记录来验证。

/plan-design-review — 设计审查。对每个设计维度打分（0-10 分），专门识别「AI 设计 slop」——那种千篇一律的 AI 生成 UI 风格。如果你用 AI 做前端，这个 skill 能大幅提升最终产品的视觉辨识度。

/autoplan — 一键运行 CEO + Eng + DevEx 三重审查，适合快速验证想法。

4.2 构建阶段：写对的代码

/design-html — 从设计稿到生产级 HTML/CSS。不是简单生成组件，而是产出可直接部署的页面。

/design-shotgun — 生成多个设计变体供选择，适合探索不同视觉方向。

/investigate — 根因分析专用。当你遇到 bug 但不知道原因时，这个 skill 会系统性地排查，而不是直接给一个「试试这个」的补丁。

/codex — 调用 OpenAI Codex CLI 做跨模型第二意见。把同一个问题同时丢给 Claude 和 OpenAI，对比分析结果。这是目前唯一一个引入外部模型的 skill。

4.3 审查阶段：多双眼睛把关

/review — Staff Engineer 级别的代码审查。检查维度包括安全性、性能、架构一致性和可维护性。关键约束：只找问题，不修问题。如果 reviewer 自己改代码，就失去了独立审查的意义。

/cso — 首席安全官。运行 OWASP Top 10 + STRIDE 威胁建模的完整安全审计。对于处理用户数据或涉及支付的项目，这个 skill 在每次发布前都值得跑一遍。

4.4 测试阶段：真实环境验证

/qa — QA Lead 级别的端到端测试。这是 gstack 最独特的能力之一：它启动一个真实的 Chromium 浏览器（通过 Playwright），模拟用户操作进行测试，发现问题后直接修复。

/qa-only — 只生成 bug 报告，不做任何代码修改。适合需要人工审查的测试场景。

/browse — 打开浏览器直接查看页面效果。不是截图，是真实的浏览器渲染——这对于验证 CSS、动画和交互逻辑至关重要。

/setup-browser-cookies — 导入浏览器 cookies，让测试浏览器保持登录状态，方便测试需要认证的页面。

4.5 发布阶段：安全上线

/ship — 完整的发布流程编排：运行测试 → 代码审查 → 版本号管理 → 生成 changelog → 提交 → 推送 → 创建 PR。一条命令完成从代码到 PR 的全过程。

/land-and-deploy — 合并 PR、等待 CI 通过、触发部署、验证生产环境。将发布的后半程也自动化了。

/canary — 发布后的生产监控。检测错误率、性能回归和异常日志。

/setup-deploy — 自动配置部署目标。支持 Fly.io、Render、Vercel 和 Netlify。

/document-release — 发布后自动更新文档。

4.6 复盘阶段：持续改进

/retro — 周报生成器。统计本周的提交数、代码行数、测试覆盖率趋势、各 skill 的使用频率。不只是数字汇总，还会给出改进建议。Garry Tan 本人用这个 skill 发现自己一周内新增了 14 万行代码、362 次提交。

4.7 安全护栏

/careful — 在执行破坏性操作（如 rm -rf、git reset --hard）之前发出警告并等待确认。

/freeze — 锁定 AI 的编辑范围到指定目录，防止意外修改其他模块。

/guard — 同时激活 careful 和 freeze 两种保护。适合在关键模块旁边做高风险操作时使用。

/unfreeze — 解除目录锁定。

---

五、典型工作流：从 Idea 到上线

下面演示一条完整的 gstack 工作流，展示各个角色如何接力完成一个功能开发。

第一步：产品验证（/office-hours）

用户 > /office-hours 我想做一个文章阅读时间估算功能

gstack（YC 合伙人模式）>
我先问你 6 个问题：
1. 谁需要这个功能？是作者还是读者？
2. 没有这个功能，用户现在怎么判断文章长度？
3. 你观察到了什么具体的行为数据让你觉得需要这个功能？
...

第二步：范围挑战（/plan-ceo-review）

用户 > /plan-ceo-review

gstack（CEO 模式）>
看了你的方案，我建议砍掉「阅读进度保存」子功能——它会让 scope 翻倍，
但对核心体验的提升有限。先把「静态估算」做好，观察数据再决定是否扩展。

第三步：架构审查（/plan-eng-review）

用户 > /plan-eng-review

gstack（工程经理模式）>
架构上需要确认三个边界条件：
1. 中英文阅读速度差异怎么处理？（中文 300-400 字/分钟，英文 200-250 词/分钟）
2. 代码块的阅读时间权重是多少？
3. 计算结果要不要缓存？文章内容不会频繁变化。

第四步：设计审查（/plan-design-review）

用户 > /plan-design-review

gstack（设计审查模式）>
评分如下：
- 信息层级：7/10，阅读时间的位置不够突出
- 视觉一致性：8/10
- 移动端适配：6/10，小屏幕上时间显示建议用图标+数字简写

第五步：代码审查（/review）

开发完成后，在合并前运行：

用户 > /review

gstack（Staff Engineer 模式）>
发现 3 个问题：
1. [安全] 用户输入的文章内容未做 XSS 过滤
2. [性能] reading_time 计算在每次请求时都重新执行，建议加缓存
3. [边界] 空文章或纯图片文章返回 0 分钟，应考虑显示 "< 1 分钟"
禁止我修复这些问题——请你自己改完后重新 /review。

第六步：浏览器测试（/qa）

用户 > /qa

gstack（QA Lead 模式）>
[启动 Chromium...]
1. 打开文章详情页 ✓
2. 验证阅读时间显示 "25 分钟" ✓
3. 切换到移动端视口 ✓
4. 发现：移动端阅读时间文本溢出 → [自动修复 overflow: ellipsis]
5. 回归测试通过 ✓

第七步：发布（/ship）

用户 > /ship

gstack（发布经理模式）>
1. 运行测试套件... 全部通过 ✓
2. 代码审查... 3 个问题已修复 ✓
3. 测试覆盖率... 87% ✓
4. 版本号 bump: 1.2.0 → 1.2.1
5. 生成 changelog
6. git commit + push
7. 创建 PR: https://github.com/...

第八步：复盘（/retro）

周末运行，回顾一周的工程数据并给出改进建议。

---

六、关键特色能力详解

6.1 持久化 Chromium 浏览器

gstack 在后台维护一个 Chromium 守护进程，启动后保持运行状态：

• 亚秒级响应：不需要每次测试都冷启动浏览器，cookie 和登录状态持久保留
• 真实渲染：不是 headless 截图，是完整的浏览器环境
• 自动化操作：Playwright 驱动，可以点击、填写表单、验证 DOM 状态

这是 gstack 与 Superpowers 最显著的差异之一——Superpowers 没有内置浏览器测试能力。

6.2 多 Agent 并行编排（Conductor 模式）

gstack 可以同时启动多个 Claude Code 会话，每个运行在不同的 git worktree 中独立工作。这种「指挥家」模式适合以下场景：

• 并行执行多个独立任务（前后端同时开发）
• 同一个问题从不同角色视角并行审查
• 多个设计变体同时生成和比较

6.3 安全审计

/cso skill 不是简单的代码扫描——它运行完整的 OWASP Top 10 检查和 STRIDE 威胁建模。对于 SaaS 产品来说，每次重大发布前过一遍 /cso 可以捕获大部分常见安全漏洞。

6.4 跨模型审查

/codex skill 是 gstack 中唯一引入外部模型的角色。它的工作方式是将同一个问题同时发送给 Claude Code 和 OpenAI Codex CLI，然后对比两边的分析结果。这种「第二意见」机制对于关键架构决策尤其有价值。

6.5 跨平台兼容

gstack 的 skill 基于 SKILL.md 标准格式，因此不仅能在 Claude Code 中使用，还可以在 Cursor、Codex CLI、Gemini CLI 等支持该标准的平台上加载。

---

七、gstack vs Superpowers：选型指南

本站已有 Superpowers 的详细介绍（见延伸阅读），这里聚焦两者的对比和选择逻辑。

7.1 核心差异

对比维度	Superpowers	gstack
创建者	Jesse Vincent (obra)	Garry Tan (YC CEO)
设计哲学	流程驱动——强制执行 7 阶段开发流程	角色驱动——23 个虚拟角色多视角判断
核心约束	TDD 铁律（Red-Green-Refactor）	角色边界（每个角色只做一件事）
自动触发	是——自动进入 Brainstorm→Plan→TDD→Review 流程	否——手动按需调用角色
浏览器测试	需额外工具	原生内置 Chromium + Playwright
产品思维	弱——聚焦工程执行	强——CEO/设计师/合伙人视角
Token 消耗	中	中高（多角色审查叠加）
学习成本	低——自动流程，无需记忆命令	中高——需理解 23 个角色和适用场景
最适合	后端 / 基础设施 / 重测试覆盖的项目	Web 应用 / SaaS / Solo Founder

7.2 选择建议

选 Superpowers 的场景：

• 你是一个追求代码质量的工程师，想确保每一次改动都有测试覆盖
• 项目是后端服务、SDK、基础设施，TDD 的收益很大
• 你希望 AI「自动」走完规范流程，而不是手动指挥

选 gstack 的场景：

• 你是独立开发者或 Solo Founder，需要在产品方向上有人挑战你
• 项目是 Web 应用或 SaaS，前端交互复杂，需要真实浏览器测试
• 你重视「做对的事」多于「把事做对」

7.3 最佳实践：组合使用

两个框架不是互斥的。社区的主流实践是三层叠加：

决策层（gstack）  →  执行层（Superpowers）  →  验证层（gstack）
「想对」               「做稳」                   「测全」

具体操作流程：

1. 用 gstack 做前期决策：/office-hours → /plan-ceo-review → /plan-eng-review → /plan-design-review，确保方向正确
2. 用 Superpowers 做中期执行：Brainstorm → Plan → TDD → Subagent → Review → Finalize，确保代码质量
3. 回到 gstack 做后期验证：/qa（真实浏览器测试）→ /cso（安全审计）→ /ship（发布）→ /retro（复盘）

这种组合不是简单的「两个都用」，而是利用了各自的最强项——gstack 的产品判断力 + Superpowers 的工程质量保障。

---

八、常见问题与踩坑指南

8.1 Token 消耗问题

gstack 的每个 skill 都是一个完整的角色提示词，单次调用可能消耗 10K+ token。如果在一个对话中连续运行 /office-hours + /plan-ceo-review + /plan-eng-review + /plan-design-review，上下文消耗可能超过 100K token。

建议：

• 每个阶段结束后开启新对话，避免上下文污染
• 对于小改动（修 typo、改样式），不需要走完整的角色链
• 使用 /autoplan 替代三个独立审查，减少对话框次

8.2 「流程感」过重

23 个角色全部启用会产生明显的流程厚重感——修一个按钮颜色可能要经过设计审查→代码审查→QA→发布四道关卡。

建议：不是每个改动都需要完整的角色链。根据改动的影响范围划分级别：

• 小改动（typo、样式微调）：直接开发 + /ship
• 中改动（新增组件、修改 API）：/plan-eng-review + /review + /ship
• 大改动（新功能、架构变更）：完整链

8.3 构建阶段空白

gstack 在「构建」阶段没有对应的 skill——这是有意为之。Garry Tan 认为 Claude Code 本身的代码生成能力已经足够强，不需要额外角色包装。但这意味着从 /plan-eng-review 到 /review 之间的开发工作完全靠你自己和 Claude Code 的默认能力。

建议：在构建阶段配合 Superpowers 的 TDD 流程填补这个空白。

8.4 Windows 兼容性

Chromium 守护进程在 Windows 下的配置比 macOS/Linux 稍复杂。如果 /qa 在 Windows 上无法启动浏览器，检查：

# 确认 Playwright 浏览器已安装
npx playwright install chromium

# 确认浏览器路径在 skill 配置中正确指定

---

九、总结

核心要点回顾

要点	说明
gstack 是什么	Garry Tan 创建的 23 个角色化 Claude Code skill 集合
核心理念	角色驱动——每个角色只做一件事，不跨界
最大优势	多视角判断力（产品、设计、安全、QA）
最大劣势	构建阶段无对应 skill，需配合其他工具
与 Superpowers 的关系	互补——gstack 定方向，Superpowers 保执行
适合人群	Solo Founder、独立开发者、Web 应用开发者

一句话总结

gstack 不会让你的 AI 写代码更快——但它会让你的 AI 写「对的」代码。

---

参考资料

• gstack GitHub Repository — Garry Tan 的 gstack 官方仓库
• gstack vs Superpowers vs AEGIS — 3 Philosophies of AI Agent Systems — 三种 AI Agent 系统哲学对比
• Superpowers, GSD, and GSTACK: Picking the Right Framework for Your Coding Agent — Pulumi 对三大 Claude Code 编排框架的横评
• A Claude Code Skills Stack: How to Combine Superpowers, gstack, and GSD Without the Chaos — 社区整理的三层组合方案
• What Is gstack? This will Change How you Code Forever — Apidog 对 gstack 的介绍
• Garry Tan’s Claude Code Workflow for 10K LOC/Week Development — SitePoint 的 gstack 教程

---

延伸阅读

• Superpowers：让 AI 编程助手从「能写代码」到「工程级交付」的技能框架 — 本站 Superpowers 深度解析
• MCP、Skills 与 Plugins：Claude Code 扩展机制全解析 — 理解 gstack 的技术基础：Skills 机制
• Workflow 与 Agent 的区别：从原理到实践的完整指南 — 理解流程驱动与角色驱动背后的 Agent 设计哲学