GStack 十万星：YC 总裁的开源 AI 编码工作流，为什么开发者集体疯狂
2026 年 3 月 12 日，Y Combinator 总裁 Garry Tan 把一个名为 gstack 的仓库推到了 GitHub。48 小时内，它收获了 1 万颗星。几周后，这个数字逼近 10 万。
这种增长速度不是偶然的。它发生在一个工具解决了开发者们长期暗自挣扎、却从未看到过干净解法的问题时。
问题很简单：Claude Code（以及所有 AI 编码代理）单独使用时非常强大，但完全没有流程。 没有结构来支撑规划、审查、测试或交付。每个开发者在每个项目上，都得从零开始重建那个脚手架——一次又一次。
GStack 就是那个脚手架。它被编码成了 23 个带观点的 slash-command 技能。
📎 仓库地址：github.com/garrytan/gstack（MIT 许可，免费）
GStack 到底是什么
GStack 不是一个框架、一个库，也不是一个新的 AI 模型。它是一个 SKILL.md 文件的集合——结构化的指令集，Claude Code 从 .claude/skills/gstack/ 自动加载，并当作角色定义来对待。
每个技能模拟软件开发团队中的一名成员：
GStack 虚拟团队结构：
─────────────────────────────────────────────────
/office-hours ──► 产品思维，在写一行代码前推翻弱想法
/plan-ceo-review ──► 扮演苛刻的 CEO（以 Brian Chesky 为蓝本）
阻止你构建无聊的功能
/plan-eng-review ──► 在编码前画序列图和状态机。锁定架构
/review ──► 代码审查：N+1 查询、脏读、安全问题（XSS 等）
/qa ──► 通过 Bun + Playwright 打开真实浏览器。
登录 staging、点击、截图，60 秒内给出健康分
/ship ──► 发布工程师。提交、开 PR、处理 changelog
/retro ──► 工程回顾。统计代码行、提交数、发了什么、坏了什么这套角色覆盖了完整的开发生命周期：思考 → 规划 → 构建 → 审查 → 测试 → 交付 → 复盘。
30 秒安装
GStack 的安装出奇简单：
git clone --single-branch --depth 1 \
https://github.com/garrytan/gstack.git \
~/.claude/skills/gstack \
&& cd ~/.claude/skills/gstack && ./setup之后，在任何项目里打开 Claude Code，这些技能就以 slash 命令的形式可用。不影响系统 PATH，没有后台常驻进程——一切都活在 .claude/ 目录里。
QA 工具是技术亮点
GStack 的大部分功能可以通过好的 prompt 近似实现。但 /qa 技能不一样。
它构建在 Bun + Playwright 之上——一个持久的浏览器守护进程。它会登录你的 staging 环境，导航应用，截图，并生成一份健康报告。命令之间不重新加载页面，不因为重复描述浏览器看到了什么而浪费上下文。
对比一下标准方案和 GStack 方案：
标准 Claude Chrome MCP：
──────────────────────────────
Claude ──► MCP 调用 ──► Chrome（每次新上下文）
│
状态在调用间丢失。
上下文窗口快速填满。
GStack /qa（Bun + Playwright 守护进程）：
──────────────────────────────────────
Claude ──► /qa 技能 ──► 持久的浏览器守护进程
│
同一会话，同一标签页。
截图作为上下文传递。
上下文开销减少 20 倍。
健康分 ~60 秒内得出。每次调用都启动一个新浏览器上下文，和持久的守护进程——这个架构差异不大，但性能差异显著。这就是为什么 /qa 技能在一分钟内就能给出完整的应用健康分，而原生的 Chrome MCP 会话往往会膨胀。
生产数据：60 天 60 万行
Tan 在 README 里公开了自己的吞吐量数据，引发了不小的争议。
他报告的数据是：使用 GStack 的 60 天内，写了 60 万行生产代码，日均 1 万到 2 万可用行——同时还在全职运营 Y Combinator。他 2026 年至今的 GitHub 贡献量，已经是他 2013 年整年输出的 240 倍。
不出所料，”那不过是 AI 在写代码”的批评接踵而至。他的回应很直接：关键不在于谁敲的键盘，而于交付了什么。 按通胀调整后，输出质量更高、速度更快。
不管你接不接受这些数字，仓库结构本身就在讲述同样的故事：GStack 本身很大程度上是与 Claude Opus 共同创作的——提交历史清楚地显示了这一点。这就是内嵌在代码库中的概念验证：一个用自身工作流构建的工具。
快速采用真正意味着什么
10 万颗星，对于一个工作流工具来说，意义重大——它不是库，没有人把 GStack 作为依赖加进项目。开发者们是在改变自己的工作方式。
这背后的模式越来越清晰：靠 AI 编码代理走得最远的开发者，用的不是更好的模型或更多的算力——他们用的是更好的流程。 他们已经把自己的开发理念——规划标准、审查标准、测试期望——编码成了指令集，每次都能一致地执行。
GStack 就是一位开发者完整的开发哲学，编码成了 23 个技能。那个星数意味着，很多其他开发者要么认同这种哲学，要么一直在寻找一个可以拿来”借鉴”的版本。
它指向的转变：
旧模式：
开发者写代码
开发者（可选）审查代码
开发者发布
GStack 模式：
/office-hours 验证想法
/plan-ceo-review 压力测试范围
/plan-eng-review 锁定架构
开发者写代码（或代理写）
/review 捕获生产问题
/qa 在真实浏览器中验证
/ship 打开 PR
/retro 度量发生了什么八个检查点。一位开发者。无论多晚、多累，流程始终一致。
它不会做什么
GStack 是观点鲜明的、工作流繁重的。它最适合独立开发者或小团队——一个人扮演多个角色的场景。在更大的团队中，有专职的 QA、设计和工程管理，大部分技能就变得冗余了——你已经有真人填补那些角色。
它还需要前期的投入：CLAUDE.md 设置、项目上下文、熟悉 sprint 结构。用 GStack 做的第一个项目比不用更慢。 复利效应发生在之后。
仓库信息
- 地址：github.com/garrytan/gstack
- 许可：MIT
- 费用：免费
- 兼容：Claude Code、Codex CLI、Cursor 及其他七个 AI 编码运行时
- 状态：数周内 10 万星
开发者们已经用行动说话了。
本文基于 gstack README、Augment Code 分析（2026 年 4 月）及 2026 年 3–6 月的社区报道。
版权所有，本作品采用知识共享署名-非商业性使用 3.0 未本地化版本许可协议进行许可。转载请注明出处：https://www.wangjun.dev//2026/06/gstack-garry-tan-100k-stars/