GitHub 2 万星！YC CEO 开源的 gstack 到底是什么？一个人如何日写万行代码

发表于 更新于 分类于 阅读次数： 本文字数： 4.8k 阅读时长 ≈ 4 分钟

cover

3 月 12 日，Y Combinator 的 CEO Garry Tan 在 X 上发了一条推文：

“我用 Claude Code 做了一套工作流，开源了，MIT 协议，拿去用。”

然后整个开发者社区炸了。

几天之内，GitHub 上冲到近 2 万星，2200+ fork。 Product Hunt 趋势榜冲到前列。一位 CTO 试用后直接在推文下评论：

“你的 gstack 太疯狂了。这就是 God Mode。你的工程审查发现了一个隐蔽的 XSS 漏洞，我觉得我的团队自己都没发现。我打赌从今天起，超过 90% 的新项目都会用 gstack。”

这条评论又被 Garry Tan 转发，继续引爆。

到底什么是 gstack？它凭什么这么火？

先说这个人：Garry Tan 是谁

理解 gstack，先要理解做它的人。

Garry Tan 不是一个普通的科技博主或开源爱好者。他是 Y Combinator 的现任 CEO——这个全球最顶级的创业孵化器，孵化了 Coinbase、Instacart、Rippling 等价值数百亿美元的公司。

在 YC 之前，他是 Palantir 最早的工程经理/PM/设计师之一（Palantir 的 Logo 就是他设计的）。他联合创立了 Posterous（后来卖给了 Twitter）。2013 年，他自己写代码做了 Bookface——YC 的内部社交网络。

这是一个设计师、产品经理、工程管理者三合一的人。他做了几十年产品。

而现在，他声称在过去 60 天里，他写了超过 60 万行生产代码——35% 是测试——每天产出 1 万到 2 万行可用代码。他上周的 7 天统计：140,751 行新增代码，362 次 commit，约 115,000 行净增代码。

注意：他同时还在全职做 YC CEO 的工作。

他用来做到这一切的工具，就是 gstack。

gstack 是什么：一座开源的”软件工厂”

一句话概括：gstack 把 Claude Code 变成了一支你可以管理的虚拟工程团队。

它不是一个代码库。它是一组 Claude Code Skills——存放在 Markdown 文件里的结构化指令，让 AI 扮演不同的角色，按照一个完整的研发流程工作。

gstack 目前包含 15 个专家角色 + 6 个工具，全部作为斜杠命令（slash commands）使用：

核心流程：Think → Plan → Build → Review → Test → Ship → Reflect

命令 角色 做什么
/office-hours YC 导师 用 6 个追问重新定义你的产品，在写代码之前。挑战你的前提假设
/plan-ceo-review CEO/创始人 重新审视问题。找到需求里隐藏的”10 星产品”
/plan-eng-review 工程经理 锁定架构、数据流、ASCII 图表、边界情况和测试计划
/plan-design-review 高级设计师 每个设计维度打分 0-10，解释什么是 10 分的样子，然后修改到位
/design-consultation 设计伙伴 从零构建完整的设计系统，生成真实的产品 mockup
/review Staff Engineer 找到那些能通过 CI 但会在生产环境爆炸的 Bug。自动修复明显问题
/investigate 调试专家 系统化的根因调试。铁律：没有调查不许修复
/qa QA 负责人 打开真实浏览器，点击你的应用，找到 Bug，修复它，生成回归测试
/ship 发布工程师 同步 main、跑测试、审计覆盖率、push、开 PR。一个命令搞定
/retro 工程经理 团队级周回顾。每人明细、发布节奏、测试健康趋势
/codex 第二意见 用 OpenAI Codex CLI 做独立代码审查。跨模型交叉分析

每个 Skill 都会把输出喂给下一个 Skill。/office-hours 写设计文档 → /plan-ceo-review 读设计文档 → /plan-eng-review 写测试计划 → /qa 读测试计划 → /review 抓 Bug → /ship 验证 Bug 已修复。

没有任何东西会漏掉。因为每一步都知道前一步做了什么。

看它实际运行：8 条命令，从想法到 PR

这是 gstack README 里的一个真实演示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
你：    我想做一个日历日报应用。
你：    /office-hours
Claude: [追问你的痛点——要具体的例子，不要假设]

你：    多个 Google 日历，事件信息过时，地点错误。
        准备工作太花时间，而且结果不够好……

Claude: 我要挑战你的定义。你说"日报应用"。但你实际描述的
        是一个个人参谋长 AI。
        [提取你自己都没意识到的 5 个需求]
        [挑战 4 个前提假设——你同意、反对或调整]
        [生成 3 种实现方案和工作量估算]
        建议：明天先发布最小切入点，从真实使用中学习。
        完整愿景是 3 个月的项目——先做一个真正能用的日报。
        [写出设计文档 → 自动喂给下游 Skills]

你：    /plan-ceo-review
        [读设计文档，挑战范围，跑 10 个维度的审查]

你：    /plan-eng-review
        [数据流 ASCII 图，状态机，错误路径]
        [测试矩阵，故障模式，安全问题]

你：    批准计划。退出计划模式。
        [跨 11 个文件写了 2,400 行代码。约 8 分钟。]

你：    /review
        [自动修复] 2 个问题。[需确认] 竞态条件 → 你批准修复。

你：    /qa https://staging.myapp.com
        [打开真实浏览器，点击各个流程，发现并修复一个 Bug]

你：    /ship
        测试：42 → 51（+9 新增）。PR: github.com/you/app/pull/42

你说”日报应用”，AI 说”你在做一个参谋长 AI”——因为它听的是你的痛点，不是你的功能描述。然后挑战你的假设，生成方案，推荐最小切入点，写设计文档，这份文档又流向每一个下游环节。

8 条命令。这不是一个 Copilot。这是一支团队。

为什么 gstack 这么火

原因 1：它解决了一个真实痛点

大部分人用 Claude Code 的方式是：打开终端，输入一句话，看 AI 写代码。

问题在于——一个没有上下文、没有角色、没有流程约束的 AI，产出质量极不稳定。 有时候惊艳，有时候灾难。

gstack 的核心创新是角色分离。CEO 不审查基础设施 Bug。设计审查不参与后端修改。发布工程师不讨论架构。每个角色有明确的职责和边界，就像一个真正的高效工程团队。

TurboDocx 的分析说得好：”这用的是同一个心智模型——Director/Manager/Engineer 模式。gstack 把关注点分离编码进了 AI 的行为。”

原因 2：/qa 是一个巨大的突破

gstack 最核心的技术不是 Markdown Skills。是浏览器子系统。

大多数 AI 编程工具没有”眼睛”——它们不能打开你的应用看看实际效果。gstack 通过一个持久化的 Headless Chromium 守护进程解决了这个问题。不是每次操作都启动新浏览器，而是维持一个长时间运行的浏览器实例，通过本地 HTTP 通信。

这意味着 /qa 可以：登录你的应用、点击各个页面、截屏、发现 Bug、修复 Bug、生成回归测试、验证修复——全部自动。

Garry Tan 自己说：”/qa 是一个巨大的解锁。它让我从 6 个并行 worker 扩展到了 12 个。Claude Code 说’我看到了这个问题’然后真的修复了它——这改变了我的工作方式。”

原因 3：作者的身份和数据太有说服力

这不是一个周末项目的分享。这是 YC CEO 用自己的实际工作验证过的生产级工具。

60 天，60 万行代码，每天 1-2 万行，同时还在做 CEO。2026 年的 GitHub 贡献图和 2013 年他做 Bookface 时的对比，同一个人，完全不同的产出量级。

差距不在能力。在工具。

原因 4：零成本、零依赖、30 秒安装

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

纯 Markdown 文件。不碰你的 PATH。不在后台运行。MIT 协议，完全免费。

安装完就有 15 个专家角色可用。5 分钟内就能跑出第一个有用的结果。

争议：gstack 也有很多批评

火的东西总有争议。gstack 也不例外。

批评 1：”这不就是一堆 prompt 吗？”

从技术角度看，gstack 的核心确实是 Markdown 文件里的结构化 prompt。有人觉得这”不够技术”。但 Garry Tan 的反驳是：gstack 的价值不在于代码量，在于工作流设计。 它把一个完整的研发流程——从产品思考到发布——编码成了 AI 可以执行的步骤。

批评 2：”每天 2 万行代码”的数字注水。

一些开发者质疑：2 万行代码里有多少是 boilerplate？有多少是测试？质量如何？这是合理的疑问。Garry Tan 说 35% 是测试，但没有公开代码库让外界独立验证。

批评 3：过度依赖 Claude Code。

gstack 原生是为 Claude Code 设计的。虽然现在支持 Codex CLI 和 Gemini CLI，但核心体验仍然依赖 Anthropic 的生态。

TechCrunch 的报道用了一个很平衡的标题：《为什么 Garry Tan 的 Claude Code 设置既获得了大量的爱，也获得了大量的恨》。

CryptoRank 的分析总结得很到位：”对 gstack 的爱和恨，归根结底来自同一个源头——人们深刻认识到，软件的构建方式正在永远改变。”

怎么开始用：你的前 10 分钟

如果你已经装了 Claude Code，试试这个流程：

  1. 安装 gstack（30 秒）：

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

  2. **跑 /office-hours**：描述你正在做的东西。看它怎么重新定义你的问题。

  3. **跑 /plan-ceo-review**：在任何功能想法上试一试。

  4. **跑 /review**：在任何有改动的分支上试。

  5. 到此为止。 你会知道它适不适合你。

如果你用 Codex CLI 或 Gemini CLI：

1
2
git clone https://github.com/garrytan/gstack.git ~/gstack
cd ~/gstack && ./setup --host auto

它会自动检测你装了什么 Agent，安装到对应目录。

写在最后

gstack 的核心理念用一句话概括：不要把 AI 当工具用，把它当团队管。

一个工具给你一把锤子。一个团队给你一条流水线。

gstack 给你的是后者：产品经理挑战你的需求，工程经理锁定架构，设计师审查体验，Staff Engineer 找到生产 Bug，QA 打开浏览器点击验证，发布工程师打包上线。

同一个 AI。不同的角色。不同的约束。不同的产出。

这和你自己写一个巨长的 prompt 有什么区别？区别在于 流程。每一步的输出是下一步的输入。没有信息丢失。没有环节遗漏。就像一个真正的研发团队——CEO 不碰代码，QA 不做架构决策。

Dev.to 上有人总结得很好：”不管你喜不喜欢 gstack，它是软件开发方向的一个信号。未来不是关于 AI 能不能写代码——它显然能。而是关于我们怎么组织 AI 把代码写好。 Garry Tan 的答案是：把它当团队管，而不是当工具用。2 万颗 GitHub 星说明很多人同意。”

你试过 gstack 吗？感觉如何？你有没有自己的 Claude Code Skills 或工作流？你觉得”把 AI 当团队管”这个思路靠谱吗？如果你还没试过，最想先跑哪个命令——/office-hours、/review、还是 /qa？评论区聊聊你的想法。