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-eng-review 作为 Eng Manager 锁定架构、数据流、边界条件；/plan-design-review 作为 Senior Designer 进行设计评分 0-10，拒绝 AI Slop。
Build 阶段，/design-consultation 作为 Design Partner 构建设计系统，生成 mockup。
Review 阶段，/review 作为 Staff Engineer 发现通过 CI 但会在生产爆炸的 bug；/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 个核心原则
倾听痛点，而非功能请求
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 关系图谱；主动优先排序时间；寻找委托或自动化的机会。
启示：用户说的"功能"往往是他们能想到的最直接的解决方案。顶级产品人的价值是听懂痛点背后的真实需求。
挑战前提，而非接受假设
/office-hours 会生成一系列可证伪的前提让你验证：
日历是锚定数据源，但价值在于上层的智能层；助理不会被取代，而是被增强；最窄的切入点是真正可用的每日简报；CRM 集成是必须，而非可选。
每个前提你都可以同意、反对或调整。你接受的每个前提都会成为设计文档的承重墙。
启示：好产品不是"满足所有假设"，而是"明确哪些假设是承重的，哪些是可以挑战的"。
找到 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?'"
启示：顶级产品人不是"实现需求"，而是"发现需求背后隐藏的卓越产品"。
设计驱动，而非事后装饰
gstack 中设计相关的技能有 3 个：/plan-design-review 在计划阶段进行设计审查；/design-consultation 构建设计系统；/design-review 进行上线后视觉审计加修复。
/plan-design-review 的工作方式：对 7 个维度评分（信息架构、交互状态、用户旅程、AI Slop 风险等）；解释 10 分长什么样；直接修改计划以达到 10 分；每个设计选择只问一个问题，避免决策疲劳。
关键洞察：大多数计划描述了后端做什么，但从未指定用户实际看到什么。空状态？错误状态？加载状态？移动端布局？这些决定被推迟到"实现时再定"——然后工程师因为没人指定更好的方案而提交了"No items found."。
启示：设计不是在开发完成后"美化"，而是在计划阶段就定义清楚用户看到和感受到什么。
测试至上，而非事后补救
/ship 的一个关键行为：如果你的项目没有测试框架，它会从头帮你搭建。
每个 /ship 运行都会生成覆盖率审计报告。每个 /qa 发现的 bug 修复都会自动生成回归测试。
"100% test coverage is the goal — tests make vibe coding safe instead of yolo coding."
启示：测试不是"保证质量"，而是"让你能够安全地快速迭代"。
如何用 gstack 工作
安装（30 秒）
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup
标准工作流
重构问题用 /office-hours；CEO 视角审查用 /plan-ceo-review；工程师视角锁定用 /plan-eng-review；设计师视角评分用 /plan-design-review；代码审查用 /review；真实浏览器 QA 用 /qa https://staging.myapp.com；一键发布用 /ship。
并行工作：规模化的关键
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 星产品——对于每个功能请求，问："这个请求背后隐藏的卓越产品是什么？"
设计在计划阶段，而非实现阶段——空状态、错误状态、加载状态——在写代码前就定义清楚。
用图表强制假设暴露——序列图、状态图、数据流图。
测试框架优先于功能开发——没有测试的功能是技术债务。
自动化文档更新——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 平台。