gstack：YC CEO 的虚拟工程团队——一个人怎么像一支团队一样交付
12.7 万 star、作者是 YC 总裁 Garry Tan。23 个角色化工具把 Claude Code 变成 CEO、设计、工程、QA、发布、安全组成的完整团队，配合 10-15 并行 sprint，一个人也能开一家软件公司。
前面几篇写了各种"给编码代理装技能"的项目——Superpowers(纪律派)、ECC(体系派)、mattpocock/skills(品味派)、一份 65 行的 CLAUDE.md(极简派)。 今天这篇换个完全不同的视角——一个 YC CEO 是怎么用 AI 单枪匹马开一家软件公司的:gstack，作者是Garry Tan——Y Combinator 的总裁兼 CEO。
它自称是"把 Claude Code 变成一个虚拟工程团队"——一个会重新思考产品的 CEO、 一个锁定架构的工程经理、一个抓 AI 垃圾设计的设计师、一个发现生产 bug 的审查者、 一个打开真实浏览器的 QA 主管、一个跑 OWASP + STRIDE 审计的安全官、 一个负责发布 PR 的发布工程师。23 个角色化工具，12.7 万 star。
一、它是什么:把一个人的 Claude Code 变成一支团队
gstack 的出发点是 Karpathy 的一句话:
"我大概从 12 月起就没真正敲过一行代码了……这真是一个巨大的变化。"
Garry Tan 听到后想弄清楚:一个人怎么像一支 20 人的团队一样交付? 答案就在 gstack——它的核心不是"更聪明的代码生成"，而是把开发流程本身结构化成一个虚拟团队。
每个 slash 命令都对应一个"专职角色"，按一场 sprint 的顺序排列:
Think → Plan → Build → Review → Test → Ship → Reflect
而且每个技能都喂给下一个:/office-hours 写出的设计文档，/plan-ceo-review 会读;/plan-eng-review 写的测试计划，/qa 会接手;/review 抓的 bug，/ship 会验证是否修好。 不是一堆孤立命令，而是一条接力链。
二、虚拟团队长什么样:9 个核心角色
23 个角色工具里，最核心的 9 个是这样分工的:
| 命令 | 角色 | 干什么 |
|---|---|---|
/office-hours | YC Office Hours | 写代码前先拷问你的产品构想——6 个强制问题，挑战你的框架，生成实现方案。设计文档喂给下游所有技能 |
/plan-ceo-review | CEO / 创始人 | 重新思考问题，找出藏在需求里的"10 星产品"。四种模式:扩张 / 选择性扩张 / 保持范围 / 收缩 |
/plan-eng-review | 工程经理 | 锁定架构、数据流、边界情况、测试。把隐藏假设逼到台面上 |
/plan-design-review | 资深设计师 | 给每个设计维度打分 0-10，解释"10 分长什么样"，再把计划改到那个标准。AI 垃圾设计检测 |
/review | Staff 工程师 | 找那些过了 CI 但在生产环境爆掉的 bug。自动修明显的，标记完整性缺口 |
/qa | QA 主管 | 打开真实浏览器测试你的应用，发现 bug、自动修复、重新验证，为每个修复生成回归测试 |
/cso | 首席安全官 | OWASP Top 10 + STRIDE 威胁建模。零噪音:17 条误报排除、8/10+ 置信门槛 |
/ship | 发布工程师 | 同步 main、跑测试、审查覆盖率、推送、开 PR。没有测试框架会自动搭建 |
/retro | 工程经理 | 团队感知的每周回顾:按人统计、发布 streak、测试健康趋势 |
README 用一个完整示例展示了它的工作流——你想做"每日简报 app"，/office-hours 听完你的痛点后反驳你的框架:
"你说的是'每日简报 app'，但你描述的其实是一个个人 AI 幕僚长。"——然后提取出 5 个你没意识到的能力，挑战 4 个前提，生成 3 个实现方案。
八个命令走完:office-hours → ceo-review → eng-review → 实现 → review → qa → ship。 这是 gstack 的宣言——"那不是 copilot，那是一支团队"。
三、为什么:一个人的"软件工厂"
gstack 最有冲击力的不是工具，而是作者公布的数据。Garry Tan 声称:
- 过去 60 天:3 个生产服务 + 40+ 个功能上线，还是兼职，同时全职管理 YC;
- 2026 全年（截至 4 月 18 日）:已产出 2013 整年的 240 倍;
- 按逻辑代码行算:2026 年生产率是 2013 年的 约 810 倍;
- 同一张 GitHub 贡献图:2013 年(建 Bookface)772 次，2026 年 1,237 次且仍在增长。
他自己也回应了"AI 膨胀行数"的质疑——用逻辑代码行(而非原始 LOC)归一化， 并附了完整方法论文档(docs/ON_THE_LOC_CONTROVERSY.md)和可复现脚本。 要点很清晰:关键不是谁敲的代码，而是交付了什么。
支撑这套产出的，是 "并行 sprint" 的思想:
gstack 用一个 sprint 很棒。十个同时跑，才真正有意思。……没有流程，十个代理就是十团乱麻;有了流程，每个代理都知道该做什么、何时停。
Garry 说他常规跑 10-15 个并行 sprint——一个跑 office-hours，一个做 review， 一个实现功能，一个在 staging 上跑 qa，六个在别的分支上。你像 CEO 管团队一样管它们:只检查那些重要的决策，让其余的自行运转。
四、它和前几篇的关系:三条思路的交汇
写到这里，gstack 其实把前面几篇的思想都串起来了:
- 它借鉴了 Karpathy 的准则——README 明确说:office-hours 在写代码前逼出假设， 对应"先想再做";review 抓过度复杂，对应"简单优先";ship 把任务变成可验证目标， 对应"目标驱动执行"。它自认为是 Karpathy 那套规则的工作流执行层;
- 它用了 Superpowers 式的角色化审查——但把审查者变成了完整的"虚拟团队";
- 它比 ECC 更"全栈"——不只是技能和记忆，还带真实浏览器、安全审计、iOS 真机测试、发布管道。
但它的气质完全不同——前面几篇是"工程师给代理立规矩"， gstack 是"CEO 给代理建公司"。它更像一个完整的产品开发运营系统， 而不是一个编码方法论。
五、怎么用:30 秒开始
安装很快，要求 Claude Code + Git + Bun:
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup然后按 README 推荐的顺序体验:
/office-hours— 描述你想做什么;/plan-ceo-review— 对任何功能点子做 CEO 审查;/review— 对有任何改动的分支做审查;/qa— 在 staging URL 上跑 QA。
"走到这一步就停。你会知道它是不是你的菜。"
它支持 10 种 AI 代理(Claude、Codex、OpenCode、Cursor、Hermes 等)， 以及 OpenClaw(可以把它当作后台的分发层)。团队模式下，仓库里的成员会自动获得这套技能。
六、诚实的提醒
- 偏重——要完整体验 QA/浏览器/部署，需要 Bun、Playwright、真实 URL 甚至浏览器 cookies。 不是那种装完就能跑轻活的项目;
- 专注 Web 产品——它的设计流程、QA、发布管道都围绕 Web 应用。 做库、做 CLI、做后端服务，很多角色用不上;
- 部分特性需要真环境——iOS 真机测试要 iPhone、部署要真实平台。 "开箱即用"的体验主要在 Claude + Web 场景;
- README 带招聘广告——文末有"我们在招人，来 YC 工作"的横幅。 理解一下,这本质上也是 Garry Tan 展示 YC 号召力的一部分;
- 是流程不是魔法——它强制了"先想再写"，但如果你只想快速改个 bug， 完整的角色化流程可能显得笨重。README 自己说:走到 qa 就知道适不适合你。
我的收获
- "角色化"是给代理结构化工作的另一种思路——Superpowers 用"纪律"， ECC 用"体系"，gstack 用"给每个角色一个名字"。把流程拟人化，反而更容易让代理各司其职。
- 并行是真正的杠杆——单人生产力的终极形态不是"一个更聪明的代理"， 而是"多个代理 + 流程管理"。10-15 个并行 sprint，本质是把一个人变成一支团队。
- Karpathy 的准则成了行业共识——从一份 65 行 CLAUDE.md，到 gstack 自称的 "工作流执行层"，四条准则正在成为编码代理的"宪法"。
- 一个人 + AI 可以是一家公司——Garry Tan 的 810× 可能夸张， 但方向是真的:当交付瓶颈从"写代码"变成"做决策"，管理就成了核心技能。
想深入了解，推荐GitHub 仓库、ETHOS.md(作者的建设哲学)， 以及他 @garrytan 的分享。 如果你想体验"一个人像一支团队"，从 /office-hours 开始——它可能是你今年最值得试的一条命令。