当 Andrej Karpathy 在播客里说出那句话时，Garry Tan 追问的却是另一件事：一个人怎么才能像一个 20 人团队那样持续交付？gstack 就是他的答案。

Garry Tan 现在是 Y Combinator 的 President & CEO，早年在 Palantir 做过工程、产品和设计，也联合创办过 Posterous，还做过 YC 内部社交网络 Bookface。在 gstack 的 README 里，他把自己最近一段时间的产出写得很重：

• 过去 60 天，600,000 行生产代码
• 其中约 35% 是测试
• 每天 10,000–20,000 行
• 同时还在全职运营 YC

这套说法当然带有很强的个人方法论宣传色彩，重点还是 Garry 给出的工作方式。README 里还举了另一个例子：Peter Steinberger 几乎独自用 AI agents 构建了 OpenClaw。按 GitHub API 在 2026-04-13 的查询，openclaw/openclaw 当时已经有 356,016 stars。

下面只抓一个核心问题：gstack 到底靠什么，把 Claude Code 从“能写代码的助手”推成“像一个虚拟工程团队”的工作流？

gstack 是什么

Garry 对它的定义非常直接：gstack 要把 Claude Code 变成一个虚拟工程团队。这句话对应的就是整个仓库的组织方式。

它把不同阶段的职责拆成一组 slash commands：

• 有人负责重新定义问题
• 有人负责锁架构和测试边界
• 有人负责设计审查
• 有人负责代码 review
• 有人负责打开真实浏览器做 QA
• 有人负责安全审计
• 也有人负责把 PR 发出去、等部署、再看生产健康

按照当前 README，这套仓库由 23 个 specialist roles 和 8 个 power tools 组成，全部以 Markdown 技能形式分发，开源协议是 MIT。

GitHub 数据

按 2026-04-13 查询到的 garrytan/gstack 仓库数据：

• Stars：70,992
• Forks：9,987
• 开源协议：MIT
• 主语言：TypeScript
• 创建时间：2026-03-11

这些数据本身也说明了一件事：gstack 在极短时间里就形成了话题和扩散。

Sprint 流程：思考 → 计划 → 构建 → 审查 → 测试 → 发布 → 复盘

理解 gstack，先看这句话：gstack is a process, not a collection of tools. 它把整个软件交付链条按 sprint 的顺序收成：Think → Plan → Build → Review → Test → Ship → Reflect，也就是：思考需求 → 形成计划 → 开始构建 → 做代码审查 → 进入真实测试 → 完成发布 → 最后复盘。

关键还在于前一个技能会把产物交给下一个技能。例如：

• /office-hours 写出的 design doc 会被 /plan-ceo-review 继续读
• /plan-eng-review 产出的测试计划会被 /qa 继续使用
• /review 找出的风险，会在 /ship 阶段继续被验证

gstack 和“装一堆提示词模板”之间的区别也在这里——它把软件团队里容易断掉的交接面，写成了明确流程。

gstack 主流程图

23 个专家角色，先看分工

23 个角色可以按几类分工来理解。

1. 规划角色

这一层负责把模糊需求压成可执行计划。

• /office-hours 用 6 个强制问题追问你的真实痛点、目标用户和隐藏前提，然后生成 design doc。
• /plan-ceo-review 站在 CEO / founder 视角重新审需求，支持 Expansion、Selective Expansion、Hold Scope、Reduction 四种模式。
• /plan-eng-review 从工程经理视角锁定架构、数据流、边界情况、测试矩阵和失败路径。
• /plan-design-review 审设计本身，核心目标是揪出 AI slop 和模板化输出。
• /autoplan 把 CEO → 设计 → 工程审查连成一条自动流水线。

2. 设计角色

这一层负责从“想法”走到“可交付界面”。

• /design-consultation 从零整理设计系统、风格方向和产品视觉语言。
• /design-shotgun 一次生成多版视觉方案，放进浏览器里做对比，再根据反馈继续迭代。
• /design-html 把选中的设计稿直接变成可交付 HTML/CSS。
• /design-review 审完直接修，保留前后对比。

3. 构建与审查角色

这一层负责在“代码已经能跑”之后，把高风险问题揪出来。

• /review 找的是那种 CI 绿了但线上会炸的 bug，比如 SQL safety、LLM trust boundary、条件分支副作用。
• /investigate 用系统化根因调试方法处理复杂问题，强调“没有调查，就没有修复”。
• /devex-review 把开发者体验当成可测试对象，实际去走 onboarding、getting started 和文档路径。

4. QA 与安全角色

这一层把“写完”推进到“敢上线”。

• /qa 打开真实浏览器、点击流程、发现 bug、修 bug、重新验证，还会为修复补回归测试。
• /qa-only 保留相同 QA 方法，但只出报告，不改代码。
• /cso 用 OWASP Top 10 和 STRIDE 做安全审计，强调低误报和高置信度。

5. 发布与辅助角色

这一层把交付继续往上线推进。

• /ship 同步主分支、跑测试、看覆盖率、推送、开 PR。
• /land-and-deploy 从“PR 已批准”一路做到“生产已验证”。
• /canary 发布后继续盯性能、控制台报错和页面失败。
• /benchmark 对比前后 Core Web Vitals 和资源体积。
• /document-release 自动更新 README 和其他文档，防止代码发了、文档没跟上。
• /retro 做按团队节奏组织的周期复盘。
• /learn 管跨会话记忆，累积项目模式、坑点和偏好。

6. Power tools

power tools 的作用是给这套流程加护栏和额外能力。

• /codex 用 OpenAI Codex CLI 做第二意见审查。
• /careful 在破坏性命令前弹安全警告。
• /freeze 把修改范围锁定在一个目录。
• /guard — /careful + /freeze 组合。
• /unfreeze 解开编辑边界。
• /open-gstack-browser 启动 GStack Browser。
• /setup-deploy 为 /land-and-deploy 做部署配置。
• /gstack-upgrade 升级 gstack 到最新版本。

这套角色和工具叠在一起，最后得到的是一套团队分工模型。

gstack 的命令分层

几个关键能力

1. /qa：把真实浏览器拉进工作流

这是 gstack 里很显眼的一项能力。/qa 直接去：打开真实 Chromium，实际点页面，发现真实交互 bug，修复以后再跑一遍，顺手补回归测试。当 Agent 能直接看到坏掉的页面、点到错误的交互、修完再验证，它的工作边界就从代码编辑器扩到真实产品了。

2. /design-shotgun + /design-html：把视觉迭代接到工程输出

传统 AI 原型流程的问题是：你用文字描述愿景，然后赌模型理解对了。gstack 这里的流程接近真实设计评审：先生成 4-6 个变体，在浏览器中并排比较，选方向、给反馈、继续迭代，选定后再交给 /design-html，输出接近可发布状态的 HTML/CSS。这套链路把“想法到界面”接成了一条完整流程，直接连到工程输出。

3. 智能审查路由

README 对这一点的解释是按分工来路由审查：CEO 不必看基础设施 bug，设计审查不必覆盖纯后端改动，不同变更需要不同审查组合。gstack 不默认每次都全角色齐上，它会试图判断当前改动更适合哪类审查。

4. 把测试覆盖率和回归测试写进流程

gstack 对测试的态度很硬：/ship 会审覆盖率，如果项目还没测试框架，会尝试引导你补起来；/qa 发现并修复 bug 后会顺手补回归测试。这让“vibe coding”从纯速度导向，开始往“可回归、可持续交付”收。

5. /codex：跨模型第二意见

当 /review 用 Claude 看过一遍 diff，/codex 再用 OpenAI Codex CLI 独立看一遍时，你得到的是一份交叉审查结果：哪些问题两个模型都看到了，哪些是 Claude 才看到的，哪些是 Codex 才指出来的。这和真实团队里的交叉审查相似。

6. /pair-agent：多 Agent 协调

/pair-agent 解决的是另一个问题：如果你同时跑多个不同供应商的 Agent，怎么让它们共享同一个浏览器环境，在同一套上下文里协作？它的做法是让多个 Agent 通过同一个 GStack Browser 协调工作，各自拥有隔离标签页。这类设计适合多 Agent 协作。

实际使用示例：8 条命令跑完一条闭环

下面这条链路，基本就是 gstack 想推广的工作方式。

1. 你说：我想做一个日历每日简报应用
2. 运行 /office-hours
3. 系统先追问你的真实痛点和替代方案
4. 它把“daily briefing app”重新解释成“personal chief of staff AI”
5. 运行 /plan-ceo-review
6. 再运行 /plan-eng-review
7. 计划批准后开始实现
8. 跑 /review
9. 跑 /qa https://staging...
10. 最后跑 /ship

在 README 的示例里，这条链能走到：先有设计文档，再有 CEO 审查，再有工程审查，再进入实现，再做代码 review，再做真实浏览器 QA，最后产出 PR。README 想强调的是这条链路覆盖了从需求到 PR 的完整分工。

gstack 的最短试用路径

安装：30 秒起步

按当前 README，最简单的安装要求是：Claude Code、Git、Bun v1.0+，Windows 额外需要 Node.js。

Claude Code 安装命令

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack
./setup

其他 AI 编程 Agent

gstack 当前明确支持 8 类 AI coding agents。README 里列出的典型宿主包括：

• Claude Code — 全局安装到 ~/.claude/skills/gstack
• OpenAI Codex CLI — 用 ./setup --host codex
• OpenCode — 用 ./setup --host opencode
• Cursor — 用 ./setup --host cursor
• Factory Droid — 用 ./setup --host factory
• Slate — 用 ./setup --host slate
• Kiro — 用 ./setup --host kiro
• OpenClaw — 通过 ACP 与 Claude Code 侧接入

想先判断它适不适合自己，README 给出的最短试用路径很简单：安装 → 跑 /office-hours → 跑 /plan-ceo-review → 在有代码改动的分支上跑 /review → 手上有 staging URL 时跑 /qa。

并行 Sprint：为什么它适合多 Agent

gstack 还有一个特点：它不只适合单线程。README 里直接把这个场景写成：一个会话跑 /office-hours，一个会话跑 /review，一个会话做实现，一个会话在 staging 跑 /qa，其他会话在别的分支继续推进。Garry 自己把这种模式描述成 10-15 个并行 sprint。

这种并行能成立，原因在于 sprint 结构先被固定了。没有流程时，10 个 Agent 是 10 个混乱源。有了 Think → Plan → Build → Review → Test → Ship 这条顺序后，每个 Agent 才知道自己现在该做什么、该在什么时候停。

隐私与遥测

这部分也值得单独提一下。按当前 README，gstack 的 telemetry 是：默认关闭，首次运行才会询问是否开启；开启后发送的只包括技能名、耗时、成功/失败、gstack 版本、操作系统；不发送代码、文件路径、仓库名、分支名、提示词和用户内容。随时可以用下面这条命令关闭：gstack-config set telemetry off。

总结

gstack 的关键在于它试图把一个软件团队的节奏写进 Agent 工作流。它把下面这些原本容易散掉的东西重新拢到一起：产品定义、范围控制、工程审查、设计迭代、浏览器 QA、安全审计、发布与文档更新。

如果你只是想让 Agent 帮你快一点写一个函数，gstack 会显得很重。但如果你关心的是：一个人怎么借助 Agent，把从想法到上线的整条链条收成团队级交付流程，它给出了一套完整的答案。gstack 开源的是一整套 AI 时代的软件工厂组织方式。

Sources

• garrytan/gstack GitHub README
• garrytan/gstack GitHub API
• openclaw/openclaw GitHub API
• Fortune / No Priors 中 Andrej Karpathy 的引述（经 gstack README 引用）