真正的问题开始变成另一类：为什么同一个模型，一会儿像个产品经理，一会儿像个 junior 开发，一会儿 review 又不够狠，到了要发版时还要来回拉扯？

Garry Tan 开源的 gstack，本质上就是在解决这个问题。

它的核心思路并不复杂，但非常有效：不要把 Claude Code 当成一个永远处在“模糊通用模式”里的助手，而是把它拆成多个显式角色，在不同任务阶段切换不同的脑子。

这也是 gstack 最值得写的一点。

很多 AI 编程工具的默认问题，不是能力不够，而是模式混在一起。

规划时缺少产品野心；
做工程方案时还在发散；
代码 review 时不够偏执；
到了测试和发版，又退回成“你想让我做什么”的聊天框。

Gstack 的做法，就是把这些混在一起的能力拆开，变成一组可以直接调用的工作流技能。

比如 /plan-ceo-review，不是让模型继续照单执行需求，而是强迫它先站在创始人视角，重新审视你到底是不是在做对的东西。

这个角度非常重要。

很多需求从字面上看没问题，但从产品价值上看其实只是“局部最优”。例如你说“给二手交易产品加个图片上传”，普通助手会给你实现上传组件；而 founder 视角会追问：用户真正要的到底是上传图片，还是更快生成能卖出去的 listing？

一旦这样问，后面的路线就完全变了。它可能会往自动识别商品、抓取规格、生成标题描述、推荐封面图的方向走。

这不是单点提效，而是在重写需求本身。

接着 /plan-eng-review 进入的是另一种模式。

这里不再强调“想象力”，而是要把产品想法变成可建造系统：架构边界、数据流、异步任务、失败模式、测试矩阵、状态机、信任边界。这一层其实非常适合 Claude Code，因为 LLM 在结构化推演和补齐边界条件上天然强，只要你给它一个明确角色，它往往比泛泛对话稳定得多。

然后是 /review。

这也是 gstack 里我觉得最实用的一层。

很多人说自己已经有 code review 流程了，但实际体验是：模型 review 经常变成样式检查器，挑点变量名、注释风格、重复逻辑，真正会在生产里炸的问题却不一定抓得出来。

Gstack 明确把这个模式定义成“偏执的 staff engineer”：去找 race condition、N+1、坏的 trust boundary、重试逻辑漏洞、测试覆盖假象、上线后才爆炸的问题。

这种设定看似只是 prompt 变化，实际影响很大。因为它不是在问“这段代码写得怎么样”，而是在问“这段代码还有什么方式会害你半夜起来修”。

再往后，/ship 负责最后一公里。

这一步听起来最无聊，却恰恰是很多分支烂尾的地方。真正做项目的人都知道，最难拖动的常常不是核心开发，而是发版前那一堆机械但必要的动作：同步 main、跑测试、确认分支状态、推送、开 PR、补变更说明。

AI 在这里的价值不是聪明，而是稳定和不嫌烦。

而 gstack 最出彩的一点，是它没有停留在“代码阶段”，而是把浏览器和 QA 也一并拉进来。

/browse 让 Claude Code 真正“看见”你的应用。它可以打开页面、登录、点击、截图、检查 console、验证某条 flow 是否跑通。这个能力一旦接进去，Claude Code 就不再只是半盲地写代码，而开始接近一个能闭环执行的代理：规划、实现、运行、观察、验证、修复。

/qa 则是把这种能力系统化，不是临时点几下，而是做结构化测试、输出健康评分、问题分级、截图证据和回归追踪。

这对独立开发者特别有意义。

因为一个人做产品时，最容易缺的不是开发，而是“多角色切换”成本。你既要像创始人一样想方向，又要像技术负责人一样稳架构，还要像严格 reviewer 一样挑错，最后再像 QA 一样把所有路径走一遍。

传统团队靠分工解决这件事；而 gstack 试图用一组明确定义的 Claude Code 技能，把这种分工搬回单兵工作流里。

所以它并不是一个简单的“技能合集”，更像是一套 Claude Code 的操作系统。

你可以把它理解成：不是让同一个 AI 一直用同一种脑回路工作，而是根据任务阶段，告诉它现在该用哪种脑子。

Founder 脑负责方向，
Eng 脑负责落地，
Reviewer 脑负责找隐患，
Release 脑负责收尾，
QA 脑负责去真实世界里撞一遍。

这套思路其实很值得 OpenClaw、Claude Code、Codex 这类工具用户参考。

未来真正强的，不一定是哪个模型单点更聪明，而是谁先把“认知模式切换”做成稳定工作流。

因为现实里的复杂任务，从来不是一种脑子能一路做到底的。

从这个角度看，gstack 最有价值的地方，不是它提供了八个 slash command，而是它公开展示了一种更成熟的 AI 编程范式：

不要再把 agent 当成一个永远语气平平的全能助手，
而要开始把它组织成一个会切换角色、会按阶段工作的数字团队。

这才是它真正厉害的地方。