gstack：把 Claude Code 變成虛擬工程團隊的 23 個角色化斜線指令

技术背景与问题定义

2026 年 3 月，Andrej Karpathy 在播客中说，自己从去年 12 月起几乎没有亲手敲过代码。这句话被 gstack 的 README 放在最前面。它点出了一个新问题：当模型已经能写大部分代码，瓶颈就从"会不会写"转到"怎么组织"。

大多数人第一次使用 Claude Code，面对的是一个空白提示框。同一个模型，有人只让它补几行函数，有人让它完成一个完整功能。差距往往不在模型，而在提问的结构。没有结构，就没有稳定的产出，也谈不上团队协作中常见的评审、测试和发布纪律。

gstack 针对的正是这个缺口。它由 Y Combinator 总裁兼 CEO Garry Tan 发布，仓库为 garrytan/gstack，采用 MIT 许可证，目前约有 13.5 万个 GitHub 星标。作者的自我定位很直接：这是他每天使用的"开源软件工厂"。他的目标读者有三类：仍想亲手交付的技术型创始人、第一次使用 Claude Code 的人，以及希望在每个 PR 上做严格评审和发布自动化的技术负责人。

核心架构与原理解析

gstack 的核心思路是把一个通用模型拆成多个有明确职责的角色。README 列出的角色包括：重新思考产品的 CEO、锁定架构的工程经理、识别"AI 味"设计的设计师、查找生产缺陷的评审员、会打开真实浏览器的 QA 负责人、执行 OWASP 与 STRIDE 审计的安全官，以及负责提交 PR 的发布工程师。README 的总数是 23 个专家角色加 8 个"电力工具"。 从形态上看，它没有后端服务，也没有新的运行时。README 明确说明：全部是斜杠命令，全部是 Markdown，免费，MIT 许可证。也就是说，每个角色本质上是一份写好的提示词文件，由 Claude Code 在调用 `/命令` 时加载。这个设计有三点后果。 第一，门槛极低。安装只是把文件放到 Claude Code 能读取的位置，README 称这大约需要 30 秒。第二，可审计。所有行为都写在文本里，你可以逐行阅读、修改、分叉。第三，也是最重要的限制：它没有强制力。角色只是提示词，模型是否真的遵守，取决于模型本身。这里没有类型系统，没有编译器，也没有任何机制能证明"安全官"真的做了完整审计。

快速上手流程也体现了这种分工：先用 `/office-hours` 描述要做的东西，再用 `/plan-ceo-review` 审查想法，用 `/review` 审查分支改动，用 `/qa` 在预发布地址或隔离的本地 API、CLI、任务或 webhook 上测试。流程顺序模拟了真实团队：需求澄清、方案评审、代码评审、测试、发布。

关键功能与实战评估

从本次会话可见的技能清单看，gstack 的命令覆盖了软件生命周期的多个环节：头脑风暴（office-hours）、战略与架构与设计评审（plan-ceo-review、plan-eng-review、plan-design-review）、设计系统（design-consultation）、排错（investigate）、测试（qa、qa-only）、代码评审（review）、视觉审查（design-review）、发布（ship、land-and-deploy）、文档更新（document-release）、复盘（retro），以及安全护栏（careful、freeze、guard）。另有一个约 100 毫秒一条命令的无头浏览器，用于 QA 和页面截图。

其中最值得注意的是 QA 角色。多数 AI 编码流程停在"代码写完"，而 gstack 要求打开真实浏览器验证页面状态。这把"我认为能用"换成了"我看到它能用"，是对幻觉风险的实际对冲。另一个亮点是 careful、freeze、guard 这类护栏：它们在执行 `rm -rf`、强制推送等危险命令前提醒，或把可编辑范围限制在一个目录里。

必须直说的是，README 里最醒目的数字全部来自作者自己。他称自己 2026 年的逻辑代码变化速率约为 2013 年的 810 倍（每天 11,417 对 14 个逻辑行），年初至 4 月 18 日的产出已相当于 2013 全年的 240 倍，统计范围是 40 个公开与私有仓库。作者也承认原始行数会被 AI 放大，并为此提供了归一化方法文档。但这些数字没有经过独立复现，私有仓库也无法外部核查。更关键的是，"产出更多代码"并不等于"交付更多价值"，更不能直接归因于 gstack 本身。我们没有对 gstack 做配对对照实验，因此不能声称它带来了任何具体倍数的提升。

行业影响与未来演进

gstack 的意义不在某项算法突破，而在它代表的做法：把团队流程编码成可分享的提示词包。这和过去把代码规范写成 lint 配置、把部署写成 CI 脚本是同一类思路，只是对象换成了智能体。13.5 万星标说明市场对"现成的智能体工作流"需求很大。

它也暴露了几个风险。其一，角色提示词容易同质化，不同项目的约束差异很大，直接照搬可能产生形式主义的"评审"。其二，没有强制验证，评审类命令的结论仍需要人来核对。其三，对单一厂商工具的依赖：这套命令围绕 Claude Code 构建，迁移到其他智能体需要重写。

未来的演进方向很可能是两条。一条是把角色提示词与真实的确定性检查连接起来，例如让"安全官"调用扫描器并输出可复核的日志，而不是只写一份文字报告。另一条是出现可量化的评测，用逐样本配对数据比较"有角色流程"与"无角色流程"的缺陷率和返工率。在这些证据出现之前，对 gstack 较稳妥的看法是：它是一套设计良好、成本很低、值得试用的工作流模板，但它的生产力承诺仍属于作者的自我报告，而不是已验证的结论。