YC CEO 公开了：我是怎么用 AI 一个人干翻一整个工程团队的

YC CEO 公开了：我是怎么用 AI 一个人干翻一整个工程团队的

上周看到一条推文，Andrej Karpathy 说：”I don’t think I’ve typed like a line of code probably since December.”

然后我去翻了 Y Combinator CEO Garry Tan 的 GitHub——过去 60 天，60 万行生产代码（35% 是测试），每天 1 万到 2 万行可用代码。与此同时，他还在全职做 YC CEO。

这不是标题党。他说得很清楚：差距在于工具。

一个人的工程队：gstack 是什么

gstack 是 Garry Tan 上个月在 GitHub 开源的 Claude Code 技能套件。GitHub stars 一周破 27000，现在已经超过 37000。

本质上，它把 Claude Code 从一个”你说什么它写什么”的工具，变成了一支完整的虚拟工程团队——每个角色各司其职，互相配合。

这套框架的核心是一个工作流 pipeline，每个环节读取上一个环节的产出：

/office-hours → /plan-ceo-review → /plan-eng-review → /review → /qa → /ship

每一环的输出，自动成为下一环的输入。没有重复，没有断层。

最被低估的环节：/office-hours

很多人装完 gstack 直接跳到写代码那步。但整个套件里最有意思的，是那个被严重低估的入口——/office-hours。

这是 Garry Tan 从 YC 合伙人那里提炼出来的强制性质问流程。任何想法进来，先回答六个问题：

• 需求现实：谁现在极度需要这个？
• 现状：没有你他们怎么做这件事？
• 极度具体：最具体的客户是什么样的？
• 最窄楔子：什么是最小可验证的需求证明？
• 观察：你看到了什么别人没看到的？
• 时机：为什么现在是正确的时间？

这个 Skill 的厉害之处不在于问题本身，而在于它的执行逻辑：只写设计文档，不写代码。它是整个 pipeline 的硬性关卡——跳过它，Claude 直接开始写代码？不允许。

有用户在 X 上描述了真实体验：/office-hours 没有停在六个问题上，它挑战了整个问题框架，识别出了错误的问题，然后生成了三个实现方案（带工作量估算），并写出了完整的设计文档。这才是这个 Skill 应该有的样子。

15 个角色，覆盖完整工程生命周期

除了 /office-hours，gstack 包含 15 个专业角色：

还有一个安全机制：/freeze 和 /guard 命令。跑并行冲刺时，防止多个 Claude 实例同时修改同一个文件。冻结核心配置文件，该冲刺就不会碰那些文件。

行业观察：为什么这个值得跟踪

gstack 之所以值得专门写一篇，是因为它代表了一个重要的范式转变。

过去一年，Claude Code、Cursor、Windsurf 这些工具解决的问题是”怎么让 AI 写代码更快”。gstack 解决的是另一个维度的问题：怎么让 AI 在正确的方向上写代码，并且有一整套机制保证质量。

这不是一个写代码的工具，是一个工程管理系统——，只不过所有角色都由 AI 来扮演。

Garry Tan 的核心观点值得所有 AI 开发者记住：

“YC 孵化了 4000 多家创业公司，我见过太多团队在错误的版本上 build得很快。只有先想清楚做什么，做什么才是对的。”

gstack 把这个逻辑编码成了可执行的工作流。对于 AI 行业观察者来说，这是一个值得持续跟踪的项目——它正在重新定义一个人类开发者的极限在哪里。

GitHub：https://github.com/garrytan/gstack

GitHub: https://github.com/garrytan/gstack