YC CEO 的产品思维：Garry Tan 如何用 gstack 把 Claude Code 变成 20 人工程团队
深度拆解 YC CEO Garry Tan 的 gstack 项目：如何用 21 个技能把 Claude Code 变成虚拟工程团队，60 天写 60 万行代码背后的产品思维与实操方法。
YC CEO 的产品思维：Garry Tan 如何用 gstack 把 Claude Code 变成 20 人工程团队
60 天写 60 万行生产代码，每天产出 1-2 万行可用代码——这不是一个全职开发者，而是 Y Combinator 总裁兼 CEO Garry Tan 在兼顾所有 CEO 职责的同时做到的。
2026 年 3 月，Garry Tan 在 GitHub 发布了 gstack，一个将 Claude Code 变成"虚拟工程团队"的开源项目。短短几天内斩获 32,000+ Stars，在整个开发者社区引发热议。
这篇文章深度拆解 gstack 背后的产品思维、设计理念和实操方法，帮助你用顶级 CEO 的视角打磨自己的产品。
一、核心洞察：工具改变时代
Garry 在 README 中放了两张对比图：
- 2013 年：他构建 YC 内部社交网络 Bookface，全年 772 次贡献
- 2026 年：使用 gstack，仅 7 天就 140,751 行代码新增、362 次提交、净增 11.5 万行
"Same person. Different era. The difference is the tooling."
这不是炫技，而是一个信号：我们正站在一个新时代的黎明——一个人可以以过去需要 20 人团队的规模进行交付。
但关键不是"AI 写得快"，而是如何组织 AI 工作。这正是 gstack 的价值所在。
二、gstack 的本质：不是工具集，是流程
很多人看到 gstack 的第一反应是："21 个技能，好复杂"。
但 Garry 在文档中反复强调：
"gstack is a process, not a collection of tools."
gstack 的核心是一个完整的 sprint 流程：
Think → Plan → Build → Review → Test → Ship → Reflect
每个环节都有对应的"专家角色"：
| 阶段 | 技能 | 角色 | 核心价值 |
|---|---|---|---|
| Think | /office-hours | YC Office Hours | 重构问题，而非直接实现功能 |
| Plan | /plan-ceo-review | CEO/Founder | 找到请求背后隐藏的 10 星产品 |
| Plan | /plan-eng-review | Eng Manager | 锁定架构、数据流、边界条件 |
| Plan | /plan-design-review | Senior Designer | 设计评分 0-10，拒绝 AI Slop |
| Build | /design-consultation | Design Partner | 构建设计系统，生成 mockup |
| Review | /review | Staff Engineer | 发现通过 CI 但会在生产爆炸的 bug |
| Review | /investigate | Debugger | 系统性根因调试，禁止无调查修复 |
| Test | /qa | QA Lead | 真实浏览器点击，自动回归测试 |
| Ship | /ship | Release Engineer | 同步、测试、推送、开 PR 一键完成 |
| Reflect | /retro | Eng Manager | 周回顾，个人分解、交付趋势 |
关键点：每个技能的输出都会自动传递给下一个技能。/office-hours 写的设计文档会被 /plan-ceo-review 读取，/plan-eng-review 写的测试计划会被 /qa 自动使用。
"Nothing falls through the cracks because every step knows what came before."
三、顶级 CEO 的产品思维：5 个核心原则
原则 1：倾听痛点，而非功能请求
Garry 举了一个真实案例：
用户说："我想做一个日历每日简报应用。"
弱 AI 助手会直接开始设计功能列表。
但 /office-hours 做的是：询问具体的痛苦场景。
用户描述：
- 多个 Google 日历，信息过时
- 活动地点错误，追踪耗时
- 准备文档是 AI 生成的垃圾
- 助理错过重要事情
然后 AI 给出了一个重构：
"I'm going to push back on the framing. You said 'daily briefing app.' But what you actually described is a personal chief of staff AI."
它提取了用户没有意识到的 5 个能力：
- 跨账户监控日历，检测过期信息
- 生成真正的准备工作（而非物流摘要）
- 管理 CRM——关系图谱
- 主动优先排序时间
- 寻找委托或自动化的机会
启示：用户说的"功能"往往是他们能想到的最直接的解决方案。顶级产品人的价值是听懂痛点背后的真实需求。
原则 2：挑战前提，而非接受假设
/office-hours 会生成一系列可证伪的前提让你验证：
- 日历是锚定数据源，但价值在于上层的智能层
- 助理不会被取代，而是被增强
- 最窄的切入点是真正可用的每日简报
- CRM 集成是必须，而非可选
每个前提你都可以同意、反对或调整。你接受的每个前提都会成为设计文档的承重墙。
启示：好产品不是"满足所有假设"，而是"明确哪些假设是承重的，哪些是可以挑战的"。
原则 3：找到 10 星产品，而非实现明显的需求
这是 /plan-ceo-review 的核心使命。
Garry 举了个例子：假设你在做一个 Craigslist 风格的列表应用，你说"让卖家上传照片"。
弱助手会添加一个文件选择器并保存图片。
但 /plan-ceo-review 会问："上传照片"真的是这个功能吗？
如果真正的工作是"帮助某人创建一个真正能卖出的列表"，整个计划就变了：
- 能否从照片识别产品？
- 能否推断 SKU 或型号？
- 能否自动搜索网络并起草标题和描述？
- 能否拉取规格、类别和价格对比？
- 能否建议哪张照片作为主图转化率最高？
- 能否检测上传的照片是否丑陋、黑暗、杂乱或低信任度？
- 能否让体验感觉高端，而不是像 2000 年代的死亡表单？
"It does not just ask, 'how do I add this feature?' It asks, 'what is the 10-star product hiding inside this request?'"
启示：顶级产品人不是"实现需求"，而是"发现需求背后隐藏的卓越产品"。
原则 4：设计驱动，而非事后装饰
gstack 中设计相关的技能有 3 个：
/plan-design-review：计划阶段的设计审查/design-consultation：构建设计系统/design-review：上线后视觉审计 + 修复
/plan-design-review 的工作方式：
- 对 7 个维度评分（信息架构、交互状态、用户旅程、AI Slop 风险等）
- 解释 10 分长什么样
- 直接修改计划以达到 10 分
- 每个设计选择只问一个问题（避免决策疲劳）
关键洞察：大多数计划描述了后端做什么，但从未指定用户实际看到什么。空状态？错误状态？加载状态？移动端布局？这些决定被推迟到"实现时再定"——然后工程师因为没人指定更好的方案而提交了"No items found."。
启示：设计不是在开发完成后"美化"，而是在计划阶段就定义清楚用户看到和感受到什么。
原则 5：测试至上，而非事后补救
/ship 的一个关键行为：如果你的项目没有测试框架，它会从头帮你搭建。
每个 /ship 运行都会生成覆盖率审计报告。
每个 /qa 发现的 bug 修复都会自动生成回归测试。
"100% test coverage is the goal — tests make vibe coding safe instead of yolo coding."
启示：测试不是"保证质量"，而是"让你能够安全地快速迭代"。
四、实操方法：如何用 gstack 工作
4.1 安装（30 秒）
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup
4.2 标准工作流
- 重构问题：
/office-hours - CEO 视角审查：
/plan-ceo-review - 工程师视角锁定：
/plan-eng-review - 设计师视角评分：
/plan-design-review - 代码审查：
/review - 真实浏览器 QA：
/qa https://staging.myapp.com - 一键发布：
/ship
4.3 并行工作：规模化的关键
Garry 透露了他如何每天产出 1-2 万行代码的秘诀：
"You can run 10-15 of these sprints in parallel. Different features, different branches, different agents — all at the same time."
一个 sprint 约 30 分钟。但他可以并行运行 10-15 个 sprint。
这就是规模化的本质：不是"更快"，而是"更多并行"。
五、给产品开发者的 10 条建议
- 在写代码之前，先重构问题——用户说的"功能"背后，真正的痛点是什么？
- 列出你的前提，然后挑战它们——哪些是承重的？哪些是可以推翻的？
- 找到 10 星产品——对于每个功能请求，问："这个请求背后隐藏的卓越产品是什么？"
- 设计在计划阶段，而非实现阶段——空状态、错误状态、加载状态——在写代码前就定义清楚
- 用图表强制假设暴露——序列图、状态图、数据流图
- 测试框架优先于功能开发——没有测试的功能是技术债务
- 自动化文档更新——README、ARCHITECTURE 等自动同步
- 给 AI"眼睛"——真实浏览器点击和截图
- 多模型审查——让不同 AI 独立审查同一份代码
- 安全护栏按需启用——执行破坏性命令前警告
六、更深层的启示：AI 时代的产品工艺
gstack 表面上是一个工具集，但它的深层价值是重新定义了 AI 时代的产品工艺。
传统产品开发：
需求 → 设计 → 开发 → 测试 → 发布
（每个阶段由不同的人负责，信息在传递中丢失）
gstack 模式：
重构问题 → 多视角规划 → 并行实现 → 自动审查 → 一键发布
（每个环节由专门的 AI 角色负责，信息自动传递）
关键差异：
- 问题重构优先于解决方案
- 多视角并行而非线性传递
- 自动化审查而非人工检查
- 信息不丢失因为每个环节都知道前因后果
结语：创造者的新时代
Garry 在 README 最后写道：
"I am learning how to get to the edge of what agentic systems can do as of March 2026, and this is my live experiment. I am sharing it because I want the whole world on this journey with me."
这不是一个"完成的产品"，而是一个进行中的实验。
我们每个人都在学习如何站在这个新时代的浪潮上。gstack 提供了一个起点，一套语言，一种思维方式。
核心不是模仿 gstack 的 21 个技能，而是理解背后的产品思维：
- 倾听痛点，而非功能请求
- 挑战前提，而非接受假设
- 发现 10 星产品，而非实现明显需求
- 设计驱动，而非事后装饰
- 测试至上，而非事后补救
无论你用不用 Claude Code，无论你是不是 CEO，这些原则都能帮助你做出更好的产品。
祝愿大家都能做出优秀的产品。 🚀
相关资源：
- gstack GitHub: https://github.com/garrytan/gstack
- Garry Tan Twitter: https://x.com/garrytan
- Y Combinator: https://www.ycombinator.com
本文基于 gstack 公开文档整理，发布于 UseClaw 平台。