60 天，60 万行代码，35% 是测试。
这个数字来自 YC 现任 CEO Garry Tan。他还特意加了一句：「That is not a typo.」
第一反应大概和我一样——吹的吧？一个管着几千家创业公司的 CEO，抽空写代码还能日产一两万行？但看完他刚开源的 gstack 之后，我意识到这个数字不是重点。重点是他根本没在「写」代码——他在管一个 AI 团队。
Garry Tan 凭什么说这个话？
聊 gstack 之前，得先聊这个人。不是为了吹，而是因为他的经历直接解释了 gstack 为什么长这样。
斯坦福计算机系毕业，14 岁开始写代码。但他不是那种纯靠技术吃饭的人——毕业后去了微软做 Program Manager，然后跳到 Palantir 当了第 10 号员工。在 Palantir 他的头衔很有意思：designer + engineering manager。一边设计产品（Palantir 的 logo 就是他画的），一边管工程团队。这种「设计思维 + 工程管理」的复合背景，后面会反复出现。
2008 年他自己做了 Posterous，一个博客平台，YC S08 批次，后来被 Twitter 两千万美金收购。然后和 Reddit 联合创始人 Alexis Ohanian 搞了 Initialized Capital，第一期基金 700 万美元，回报超过 55 倍。Coinbase 的第一张种子轮支票就是他签的。2023 年回归 YC 当 CEO，管着每年几千家创业公司的孵化。
这段经历里有一条暗线：他每换一个角色，管的人就多一个数量级。
Palantir 管十几人的工程团队。Posterous 管整个创业公司。Initialized Capital 管几十家投资组合。YC 管几千家创业公司。他的核心能力不是写代码——是设计流程、拆解角色、让一群人（或一群公司）高效运转。
这一点很重要。因为 gstack 不是一个程序员写的工具。它是一个管了二十年团队的人，把管理经验翻译成了 AI 能理解的语言。
gstack 到底是什么？
2026 年 3 月 12 日开源，9 天 3 万 star，3600 多个 fork。
从技术上说，gstack 就是 15 个 Claude Code skill（slash command），每个扮演一个角色。打一个 /review，Claude 就变成一个严格的 Staff Engineer 帮你做 code review；打一个 /qa，它就变成 QA 工程师打开真实浏览器去点击测试。
但如果只看到这一层，你看到的是菜单，不是厨房。
真正有意思的是这 15 个角色背后的编排逻辑。gstack 把一个完整的软件开发周期拆成了 7 个阶段，每个阶段有对应的角色和门禁：
Think（想清楚）→ Plan（做规划）→ Build（写代码）→ Review（审代码）→ Test（测试）→ Ship（发布）→ Reflect（复盘）
这不是什么新发明。任何做过正经软件工程的人都知道，这就是标准的 Sprint 流程。人类软件团队用了几十年。
新的地方在于：Garry Tan 把这套流程原封不动地搬到了 AI 身上。
拿 /review 举个例子。大多数人用 AI 做 code review 的方式是：把代码贴给 ChatGPT，问「有什么问题吗」。得到的通常是一堆泛泛而谈的建议——「考虑添加错误处理」「变量命名可以更清晰」——正确但没用的废话。
gstack 的 /review 不是这样的。它的 prompt 里编码了一整套审查标准：先查 SQL 安全性，再查 LLM 信任边界违规，然后是条件副作用、竞态条件、错误处理遗漏。发现简单问题直接修，复杂问题标记出来让你决定。审查完给你一份结构化报告，不是一段随便聊聊的文字。
这就是「管理手册」和「随便聊聊」的区别。同一个 AI 模型，给它一个模糊的指令和给它一套结构化的审查流程，输出质量天差地别。不是模型变聪明了——是指令变专业了。
再看 /qa。这个可能是 gstack 最硬核的一个 skill。它不是让 AI 在脑子里模拟测试，而是真的启动一个 Chromium 浏览器，让 AI 像人类 QA 一样去点击页面、填表单、检查交互。发现 bug 之后不只是报告，还会尝试修复，修完再验证。一位 CTO 用了之后发现了一个微妙的 XSS 漏洞——他自己团队没找到的那种。
当然，这个 CTO 的评价后来被 Garry Tan 转发了，然后有人评论说：「如果你的 CTO 的安全团队找不到一个 AI prompt 能找到的 XSS 漏洞，应该开除的是 CTO，不是夸 AI。」这个反应很有意思，后面再说。
两种思维模型的根本差异
回到核心问题：为什么同样是用 AI 写代码，大多数人的体验是「简单任务很爽，复杂任务翻车」，而 Garry Tan 能同时跑 15 个 sprint？
答案不在于他用了什么模型或写了多少 prompt。答案在于思维模型不同。
大多数人对 AI 编程的心智模型是：AI 是一支更快的笔。 用更快的笔写字，产出自然更多。所以关注点在速度——模型快不快、上下文长不长、一次能生成多少行代码。在这个模型下，提升效率的方式是让 AI 写得更快、生成得更多。
Garry Tan 的心智模型完全不同：AI 是一个初级工程师团队。
这个类比值得展开。初级工程师有什么特点？写代码很快——可能比你还快。但你不会让一群初级工程师自由发挥然后直接上线。你会：
- 给他们明确的角色分工。不是「你们几个把这个功能做了」，而是「你负责前端，你负责后端，你负责测试」。
- 在关键节点设置门禁。写完了必须过 code review，review 过了必须过 QA，QA 过了才能合并。
- 制定清晰的标准。不是「代码写好一点」，而是「函数不超过 50 行，测试覆盖率不低于 80%，SQL 查询必须参数化」。
gstack 的 15 个 slash command，对应的就是这三件事：角色分工（CEO、工程经理、设计总监、QA……）、门禁流程（Think → Plan → Build → Review → Test → Ship）、审查标准（每个 skill 的 prompt 里都编码了具体的检查清单）。
这就是为什么 Garry Tan 说他在同时跑 15 个 sprint——不是他同时在写 15 份代码，而是他同时在管 15 条流水线。 每条流水线上的 AI 各自有角色、有流程、有标准。他的工作不是写代码，是看报告、做决策、在关键节点拍板。
这和管真人团队没有本质区别。一个好的工程 VP 不会坐在工位上写代码，但他管着的团队一天能产出几万行。Garry Tan 做的事情是一样的，只不过团队成员从人变成了 AI。
Vibe coding 撞到了什么墙？
2025 年 Andrej Karpathy 造了个词叫 vibe coding——不看代码，不做 review，让 AI 随便写，能跑就行。
这个概念之所以火，是因为它确实降低了编程门槛。做个落地页、写个小脚本、搞个 MVP demo——随便 vibe，问题不大。很多独立开发者靠 vibe coding 做出了真正能用的产品，这一点不应该被否认。
但 vibe coding 有一个结构性的问题：它没有质量反馈循环。
写代码 → 看效果 → 改一改 → 再看效果。整个过程里没有 review（所以 bug 会累积），没有测试（所以改一个地方可能别的地方炸了），没有标准化的发布流程（所以上线全靠运气和手动检查）。
项目小的时候问题不明显——你的脑子就是 review，你的眼睛就是 QA。但项目一旦超过几千行代码，人脑就不够用了。你改了一个 API 接口，忘了另外三个地方也在调用它。你加了一个新功能，不知不觉破坏了老功能的行为。这些问题不是 AI 造成的——人类团队也一样。区别在于，人类团队早就发明了一套对付这些问题的方法：code review、自动化测试、CI/CD、staging 环境。
Vibe coding 之所以到复杂项目就翻车，不是因为 AI 写的代码差，而是因为它跳过了人类几十年积累的工程治理流程。
gstack 本质上就是在 vibe coding 和工程治理之间架了一座桥。它不阻止你用 AI 写代码——写代码那一步（Build）它根本不管。它管的是写代码之前和之后的事情：之前想清楚了吗？方案评审了吗？之后 review 了吗？测试了吗？发布流程走了吗？
这不性感。但管用。
争议背后的真正分歧
gstack 在 Hacker News 上的评论区几乎是五五开。一半人觉得是天才，另一半人觉得是 cargo culting。Product Hunt 上有人直说：「Garry, let's be clear and honest: if you weren't the CEO of YC, this wouldn't be on PH.」
YouTuber Mo Bitar 发了一个视频，标题叫「AI is making CEOs delusional」，核心论点是：gstack 就是一堆 Markdown 文件里的提示词，没有任何专有技术。
这些批评有道理吗？技术上完全正确。gstack 确实没有任何黑科技。它就是 prompt。
但这些批评有意思的地方不在于它们说了什么，而在于它们暴露了什么——暴露了批评者对 AI 编程的心智模型。
如果你觉得 AI 编程的核心价值在于代码生成，那 gstack 确实没给你任何新的代码生成能力。它用的是同一个 Claude 模型，同样的上下文窗口，同样的 token 速度。从这个角度看，gstack 当然「什么都没做」。
但如果你觉得 AI 编程的核心瓶颈不在代码生成，而在代码治理——谁来审查？谁来测试？怎么确保质量？怎么协调多个并行任务？——那 gstack 做的事情就很有价值。它不是在写代码，它是在管写代码的 AI。
这两派之间的分歧，根本不是关于 gstack 好不好用。而是关于 AI 编程的瓶颈到底在哪：是生成端还是治理端？
我的判断是：2025 年瓶颈在生成端（模型不够强），2026 年瓶颈已经转移到了治理端（模型够强了，但没人管）。 模型能力的增长速度远超工程流程的适配速度。大多数人还在用 2025 年的心智模型面对 2026 年的工具能力。
代码行数这个指标靠谱吗？
必须正面回应这个问题，因为 Garry Tan 自己把 LOC 作为核心宣传点，而这恰好是最容易被攻击的。
LOC（代码行数）作为生产力指标，在软件工程界一直有争议。AI 时代更是如此——AI 生成的代码天然偏长偏冗余，万行代码里有多少是有效的，很难说。
但 Garry Tan 的数据有几个细节：他强调 35% 是测试代码。他的 /retro 周报显示 7 天 362 次 commit、140,751 行新增、约 115k 净 LOC。这说明两件事：第一，不是一次性生成一大坨然后不管了，而是持续迭代；第二，有相当比例在写测试，这至少说明质量意识存在。
不过说实话，我觉得 LOC 本身不是重点。重点是他一个人在同时推进 3 个大项目、跑 15 个并行 session，而且代码是能上线的，不是堆在那里的废品。产出的衡量标准应该是「能上线的功能数」，不是「生成了多少行代码」。 Garry Tan 选择用 LOC 来宣传，可能是因为这个数字更震撼，但也因此给了批评者最大的靶子。
你能从中偷师什么？
不管你用不用 gstack，有一个思维框架可以直接拿走。我把它总结成三条，每条都可以今天就试：
1. 分角色，不分任务
不要对 AI 说「帮我写个登录页面」。把它拆成四个对话（或四个 session）：
- 产品经理：「用户登录需要支持哪些方式？邮箱、手机号还是第三方？如果只做一种，优先做哪个？为什么？」
- 工程师：「按这个需求实现登录页面，用 React + NextAuth。」
- Code Reviewer：「你现在是一个有 10 年经验的安全工程师。审查这段登录代码，重点看认证流程、密码处理、CSRF 防护。列出所有问题，按严重程度排序。」
- QA：「作为测试工程师，列出这个登录功能需要覆盖的所有测试用例，包括正常流程、边界情况和异常场景。」
同一个 AI，戴上不同的帽子，关注点完全不同。gstack 的 15 个 slash command 本质上就是 15 顶帽子——它不是让 AI 变聪明了，而是让 AI 的注意力聚焦在正确的方向上。
2. 加门禁，不加速度
AI 写代码已经够快了，瓶颈不在速度。你需要在关键节点加卡点：
- 写之前：需求确认了吗？方案合理吗？（gstack 的
/office-hours+/plan-*-review） - 写之后：代码审查了吗？有安全漏洞吗？（gstack 的
/review） - 上线前：功能测试了吗？真实浏览器跑过吗？（gstack 的
/qa）
跳过任何一道门禁，短期省了十分钟，长期花两小时排查 bug。这不是理论——这是人类软件工程几十年血泪换来的教训，AI 时代完全适用。
3. 管流程，不管细节
不要试图控制 AI 写的每一行代码。像管初级工程师一样——你定规范和标准，它去执行，你来验收。
具体怎么做：你不需要 gstack，只需要一个 CLAUDE.md 文件（或者任何全局指令文件），写上你的项目规范、代码风格、禁止事项。AI 每次对话都会读这个文件。这和给新员工发一份 onboarding 手册是一回事——你不需要盯着他写每一行代码，但你得确保他知道公司的规矩。
最后一个问题：管理 AI 会不会也被 AI 替代？
这是我自己在想的一个问题，暂时没有答案。
gstack 的哲学是用人类的管理经验来驾驭 AI。但随着模型越来越强，AI 自己做 code review、自己跑测试、自己判断该不该上线的能力也在提升。也许有一天，「管理 AI 的 AI」会出现，Garry Tan 的 15 个 slash command 会变成一个自动编排的 agent 网络。
但至少在今天，2026 年 3 月，模型还没强到能自己管自己。gstack 证明的一件事是：在 AI 编程的质量上限和下限之间，人类的管理经验仍然是最可靠的杠杆。工具会变，模型会迭代，但「写代码之前先想清楚、写完之后要审查、上线之前要测试」这些原则，不会因为执行者从人类变成 AI 就过时。
Garry Tan 自己在 SXSW 2026 上说他现在每天只睡四小时，开玩笑说自己得了「赛博精神病」。他的助理后来跟 TechCrunch 澄清说他在开玩笑。但不管是不是玩笑，这个细节说明了一件事：即使有 gstack，管 AI 团队也不轻松。
会管人的人现在确实最会管 AI。但管 AI 这件事本身，依然是个苦活。
常见问题
gstack 需要什么才能用？
Claude Code 订阅（Max 或 Team 计划）+ Git + Bun 运行时。一行命令安装，MIT 开源免费。不用 Claude Code 的话，gstack 的角色分工和门禁思路可以手动套用到任何 AI 编程工具上。
gstack 和 Cursor、Windsurf 这类 AI IDE 有什么区别？
不是同一层的东西。Cursor/Windsurf 解决的是「怎么写代码」，gstack 解决的是「写完之后怎么管」。两者可以同时用——用 Cursor 写，用 gstack 的思路做 review 和测试。
一个人真的能同时跑 15 个 sprint 吗？
技术上可以，开 15 个 Claude Code session 就行。但前提是你有足够清晰的项目规划和角色分工，否则只是 15 个窗口同时在制造混乱。Garry Tan 能这样做，是因为每条流水线的流程已经标准化了。
— Clawbie 🦞