1 人 = 20 人团队：解析 YC CEO Garry Tan 的 gstack 工程系统

王庚君
10 阅读11分钟

1 人 = 20 人团队：解析 YC CEO Garry Tan 的 gstack 工程系统

导读: "60 天 60 万行代码，35% 是测试"。Y Combinator 总裁 Garry Tan 开源了他的 AI 工程系统——gstack。这不是工具集，而是一套完整的虚拟工程团队。

📖 目录

  1. Garry Tan 是谁？
  2. [60 天 60 万行代码的真相](#60-天 60-万行代码的真相)
  3. gstack 是什么？
  4. 15 个专家角色详解
  5. Sprint 流程：Think→Plan→Build→Review→Test→Ship→Reflect
  6. 实战：30 分钟完成一个功能
  7. 并行开发：同时运行 10-15 个 sprint
  8. 安装与配置
  9. gstack vs 其他方案

Garry Tan 是谁？

Garry Tan 是 Y Combinator 的总裁兼 CEO，这可能是硅谷最有影响力的人之一：

身份说明
🎯 YC CEO投资过 Coinbase、Instacart、Rippling（估值千亿美元）
💻 工程师Palantir 早期员工，设计了 Palantir logo
🚀 创业者联合创办 Posterous（卖给 Twitter）
🎨 设计师产品设计师出身，Built Bookface（YC 内部社交网络）

2013 年，他用 772 个 GitHub contributions 构建了 Bookface。

2026 年，他用 1,237 个 contributions（还在增加）展示了什么是 AI 原生开发。

60 天 60 万行代码的真相

📊 数据说话

Garry 在 gstack README 中披露的数据：

过去 60 天：
- 600,000+ 行生产代码
- 35% 是测试代码
- 日均 10,000-20,000 行可用代码

过去 7 天（/retro 统计）：
- 140,751 行新增
- 362 个 commits
- ~115k 净 LOC

这不是全职编码的产出——他同时在做 YC CEO 的全部工作。

📈 GitHub Contributions 对比

2013 年（Bookface）: 772 contributions
2026 年（gstack）:   1,237 contributions（还在增加）

同一个人，不同时代。区别在于工具。

💡 核心洞察

"We are at the dawn of something real — one person shipping at a scale that used to require a team of twenty."

我们正处在一个新时代的黎明——一个人以过去需要 20 人团队的规模交付代码。

gstack 是什么？

🎯 定位

gstack 是 Garry Tan 的开源软件工程工厂。它不是工具集，而是把 Claude Code 变成一个你真正管理的虚拟工程团队。

👥 15 个专家 + 6 个权力工具

┌─────────────────────────────────────────────────────────────┐
│                      gstack 团队                            │
├─────────────────────────────────────────────────────────────┤
│  🎯 CEO          → 重新思考产品                              │
│  📐 Eng Manager  → 锁定架构                                  │
│  🎨 Designer     → 捕捉 AI slop                              │
│  🔍 Reviewer     → 发现生产 bug                              │
│  ✅ QA Lead      → 真实浏览器测试                            │
│  🚀 Release Eng  → 发布 PR                                   │
│  ... + 9 个专家 + 6 个权力工具                               │
└─────────────────────────────────────────────────────────────┘

全部作为 slash 命令，全部 Markdown 格式，全部免费，MIT 许可。

🎯 适用人群

人群价值
创始人/CEO技术背景仍想亲自开发，用 gstack 像 20 人团队一样构建
Claude Code 新手结构化角色而非空白提示，最佳入门方式
技术负责人为每个 PR 带来严格的审查、QA 和发布自动化

15 个专家角色详解

🎯 产品与规划类

/office-hours - YC Office Hours

角色: YC 导师 职责: 在你写第一行代码之前，重新定义问题

你说："我想做一个每日简报应用"

它听完后说：
"等等，你描述的其实是一个'个人首席参谋 AI'，
不是'每日简报应用'。

让我挑战你的 4 个前提...
让我生成 3 种实现方案...
让我写一份设计文档..."

设计文档自动流入下游技能。

核心能力:

  • 6 个强制性问题重构你的产品
  • 挑战你的前提假设
  • 生成多种实现方案
  • 输出设计文档供下游使用
/plan-ceo-review - CEO / 创始人评审

角色: 挑剔的 CEO 职责: 找到藏在需求里的 10 星级产品

4 种模式:

  • Expansion（扩展）
  • Selective Expansion（选择性扩展）
  • Hold Scope（保持范围）
  • Reduction（缩减）
/plan-eng-review - 工程经理评审

角色: 严谨的工程经理 职责: 锁定架构、数据流、边界条件

输出:

  • ASCII 数据流图
  • 状态机图
  • 错误路径分析
  • 测试矩阵
  • 失败模式分析
  • 安全关注点
/plan-design-review - 高级设计师评审

角色: 挑剔的设计师 职责: 每个设计维度 0-10 分评分

特点:

  • 解释什么是 10 分
  • 编辑计划以达到 10 分
  • AI Slop 检测
  • 每个设计选择一次用户询问
/design-consultation - 设计伙伴

角色: 设计合作伙伴 职责: 从零构建完整设计系统

能力:

  • 研究竞品
  • 提出安全选择和创意风险
  • 生成真实产品 mockup
  • 编写 DESIGN.md

🔍 质量与测试类

/review - 员工工程师审查

角色: 资深工程师 职责: 发现通过 CI 但在生产环境会爆炸的 bug

特点:

  • 自动修复明显问题
  • 标记完整性缺口
  • 跨模型分析（与/codex 配合）
/investigate - 调试专家

角色: 系统调试员 职责: 系统性根因分析

铁律: 没有调查就没有修复

流程:

  1. 追踪数据流
  2. 测试假设
  3. 3 次失败后停止
/design-review - 会写代码的设计师

角色: 设计师 + 工程师 职责: 审计并修复发现的问题

输出:

  • 原子化 commits
  • before/after 截图
/qa - QA 负责人

角色: QA 负责人 职责: 测试应用、发现 bug、修复、验证

核心能力:

  • 真实浏览器点击测试
  • 原子化 commit 修复
  • 为每个修复生成回归测试
  • 自动验证修复
/qa-only - QA 报告员

角色: 纯 QA 报告 职责: 与/qa 相同方法，但只报告不修复

🚀 发布与文档类

/ship - 发布工程师

角色: 发布工程师 职责: 一键发布

流程:

  1. 同步 main 分支
  2. 运行测试
  3. 审计覆盖率
  4. 推送
  5. 创建 PR

特点:

  • 如果没有测试框架，自动 bootstrap
  • 每次运行产生覆盖率审计
  • 自动调用 /document-release
/document-release - 技术作家

角色: 文档工程师 职责: 更新所有文档以匹配刚发布的内容

自动更新:

  • README
  • ARCHITECTURE
  • CONTRIBUTING
  • CLAUDE.md
  • TODOS

📊 反思与工具类

/retro - 工程经理复盘

角色: 工程经理 职责: 团队感知每周复盘

输出:

  • 每人 breakdown
  • 交付 streak
  • 测试健康趋势
  • 增长机会
/browse - QA 工程师

角色: 给 AI 一双眼睛 职责: 真实 Chromium 浏览器、真实点击、真实截图

性能: ~100ms 每命令

/setup-browser-cookies - 会话管理器

角色: 会话管理 职责: 从真实浏览器导入 cookies

支持: Chrome、Arc、Brave、Edge

🛡️ 安全与辅助类

/codex - 第二意见

角色: OpenAI Codex CLI 独立审查 职责: 跨模型分析

3 种模式:

  • review（pass/fail gate）
  • adversarial challenge（主动挑战）
  • open consultation（开放咨询）
/careful - 安全护栏

角色: 安全卫士 职责: 破坏性命令前警告

触发: 说 "be careful"

警告: rm -rf、DROP TABLE、force-push

/freeze - 编辑锁定

角色: 范围守卫 职责: 限制文件编辑到一个目录

用途: 调试时防止范围外修改

/guard - 全面安全

角色: /careful + /freeze 职责: 最大安全

/unfreeze - 解锁

角色: 解锁 职责: 移除/freeze 边界

/gstack-upgrade - 自更新

角色: 自更新工具 职责: 升级到最新版

Sprint 流程

🔄 完整流程

Think → Plan → Build → Review → Test → Ship → Reflect
  ↓       ↓        ↓        ↓        ↓       ↓        ↓
office  ceo     eng      review   qa     ship    retro
hours  review  review

📋 实际对话示例

你：我想做一个每日简报应用给团队用

你：/office-hours

Claude:
[询问痛点——具体例子，不是假设]
[挑战你的框架]
[生成 3 种实现方案]
[推荐最窄的楔子]
[写设计文档 → 自动流入下游]

你：/plan-ceo-review
[阅读设计文档，挑战范围，运行 10 节评审]

你：/plan-eng-review
[ASCII 数据流图、状态机、错误路径]
[测试矩阵、失败模式、安全关注点]

你：批准计划，退出计划模式
[写入 2,400 行代码，跨越 11 个文件，约 8 分钟]

你：/review
[AUTO-FIXED] 2 个问题
[ASK] 竞态条件 → 你批准修复

你：/qa https://staging.myapp.com
[打开真实浏览器，点击流程，发现并修复 bug]

你：/ship
Tests: 42 → 51 (+9 新增)
PR: github.com/you/app/pull/42

⏱️ 时间估算

阶段时间
/office-hours3-5 分钟
/plan-ceo-review2-3 分钟
/plan-eng-review3-5 分钟
Build5-10 分钟
/review2-3 分钟
/qa5-10 分钟
/ship2-3 分钟
总计约 30 分钟

并行开发

🎯 核心洞察

"One sprint, one person, one feature — that takes about 30 minutes with gstack. But here's what changes everything: you can run 10-15 of these sprints in parallel."

一个 sprint 30 分钟，但你可以同时运行 10-15 个。

🌳 Git Worktrees 方案

# 主分支
main/

# 并行功能分支（每个独立工作树）
feature-briefing-ui/
feature-calendar-integration/
feature-news-sources/
feature-email-digest/
feature-slack-bot/
...

📊 Garry 的并行策略

每天 10-15 个并行 sprint
每个 sprint 一个功能分支
每个分支一个 Claude Code 会话

早上启动所有会话
下午审查所有 PR
晚上合并

💡 实现方式

  1. Git Worktrees - 每个功能独立工作目录
  2. 多 Claude 会话 - tmux 或独立终端
  3. 智能审查路由 - gstack 自动判断需要什么审查
  4. Review Readiness Dashboard - 发布前状态一览

实战：30 分钟完成一个功能

🎯 场景：添加用户登录功能

Step 1: /office-hours (3 分钟)

你：我想给用户加登录功能

Claude: 等等，你真正需要的是什么？
- 只是邮箱 + 密码？
- 还是需要 OAuth（Google/GitHub）？
- 是否需要 MFA？
- 用户会话如何管理？

让我写一份认证设计文档...

Step 2: /plan-ceo-review (2 分钟)

[挑战范围]
[建议先用 Magic Link，后期再加密码]
[推荐 Auth0 或 Supabase Auth]

Step 3: /plan-eng-review (4 分钟)

[生成数据流图]
[定义 session schema]
[列出边界情况]
[生成测试计划]

Step 4: Build (8 分钟)

[自动写入 800 行代码]
- 用户模型
- 登录 API
- Session 管理
- 前端表单

Step 5: /review (3 分钟)

[发现密码未哈希]
[自动修复]
[发现 CSRF 保护缺失]
[请求批准修复]

Step 6: /qa (7 分钟)

[打开真实浏览器]
[测试登录流程]
[发现移动端布局问题]
[修复并验证]
[生成回归测试]

Step 7: /ship (3 分钟)

[同步 main]
[运行测试：35 → 42]
[推送]
[创建 PR: github.com/you/app/pull/15]
[更新文档]

总计：30 分钟

安装与配置

🚀 快速安装

方法 1: 全局安装（推荐）

git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

方法 2: 项目级安装

git clone https://github.com/garrytan/gstack.git ~/gstack
cd ~/gstack && ./setup --host auto

方法 3: Codex 用户

git clone https://github.com/garrytan/gstack.git ~/.codex/skills/gstack
cd ~/.codex/skills/gstack && ./setup --host codex

📝 配置 CLAUDE.md

添加 gstack 部分到你的 CLAUDE.md：

## gstack

使用 gstack 的 /browse 技能进行所有网页浏览，
不要使用 mcp__claude-in-chrome__* 工具。

可用技能:
/office-hours, /plan-ceo-review, /plan-eng-review,
/plan-design-review, /design-consultation, /review,
/ship, /browse, /qa, /qa-only, /design-review,
/setup-browser-cookies, /retro, /investigate,
/document-release, /codex, /careful, /freeze,
/guard, /unfreeze, /gstack-upgrade

✅ 验证安装

cd .claude/skills/gstack && ./setup

如果技能不工作，运行上面的命令重新构建。

gstack vs 其他方案

📊 对比表

特性gstackeverything-claude-codeBMADSuperpowers
定位虚拟工程团队性能优化系统SDLC 方法论工程超能力
核心15 个专家角色28 Agents + 116 SkillsPRD 驱动TDD 优先
流程Think→Ship→ReflectPlan→Execute→ReviewSpec→BuildTest→Code
特色CEO/Designer 评审12 语言生态22+ 平台Iron Laws
创始人Garry Tan (YC)Affaan MustafaBMAD 社区Jesse Vincent
Stars新但热门50K+41K+100K+

🎯 选择建议

场景推荐
创始人/CEO 亲自开发gstack ⭐⭐⭐⭐⭐
追求极致性能everything-claude-code ⭐⭐⭐⭐⭐
需要完整 SDLCBMAD ⭐⭐⭐⭐
TDD 实践Superpowers ⭐⭐⭐⭐⭐
新手入门gstack ⭐⭐⭐⭐

核心哲学

💡 Garry 的设计理念

1. 流程胜过工具

"gstack is a process, not a collection of tools."

2. 设计是核心

"Design is at the heart. /design-consultation doesn't just pick fonts."

3. QA 是突破

"/qa was a massive unlock. It let me go from 6 to 12 parallel workers."

4. 测试一切

"Test everything. 100% test coverage is the goal."

5. 文档自动更新

"/document-release is the engineer you never had."

🎯 为什么有效？

传统方式:
你 → 思考 → 写代码 → 测试 → 修复 → 发布
     ↓
   容易跳过步骤

gstack 方式:
你 → /office-hours → /plan → /build → /review → /qa → /ship
     ↓
   每个步骤强制执行

结语

gstack 不是另一个工具集。它是一个人如何像 20 人团队一样交付的系统。

Garry Tan 用 60 天 60 万行代码证明了这个系统的有效性。

现在，这个系统开源了。

Fork it. Improve it. Make it yours.

参考资料:

本文基于 gstack README 和官方文档编写，最后更新：2026-03-21

avatar
文章
阅读
粉丝