Garry Tan 的 AI 编程工厂：gstack 深度解剖

老荀
0 阅读10分钟

Garry Tan 的 AI 编程工厂：gstack 深度解剖

YC 掌门人 Garry Tan 开源了他的 Claude Code 工作流——14 个 Skill 组成的虚拟工程团队。60 天写了 60 万行生产代码，日均 1-2 万行。本文深度拆解 gstack 的架构设计、协作机制和最佳实践。

Gemini_Generated_Image_fydh8ofydh8ofydh.webp

一、gstack 是什么？

gstack 是 Garry Tan（Y Combinator 现任 CEO）开源的 Claude Code Skills 套件。它把 Claude Code 变成一支虚拟工程团队——CEO 重新思考产品、工程经理锁定架构、设计师捕捉 AI slop、评审员找生产 bug、QA 打开真实浏览器点击你的应用、发布工程师搞定 PR。

一句话总结：13 个角色，全是 Markdown，全部免费，MIT 协议。

Garry 本人用这套工具在 60 天内写了超过 60 万行生产代码，35% 是测试。日均 1-2 万行可用代码——同时他还在做 YC CEO 的全部工作。

二、核心架构：为什么它这么快？

2.1 持久化浏览器守护进程

gstack 的核心不是 Prompt，而是一个持久化的无头浏览器守护进程。

Claude Code CLI
    ↓ HTTP POST (Bearer Token 认证)
Bun.serve() 服务器（10 个路由）
    ↓ Playwright CDP 协议
Chromium 无头浏览器（持久标签页 / Cookie）
  • 首次启动：约 3 秒（冷启动浏览器）
  • 后续每条命令：约 100ms（HTTP POST + Playwright 动作）
  • 30 分钟空闲自动关闭，下次调用自动重启

这意味着 20 条浏览器命令的总开销不到 2 秒，而传统方案（每次冷启动 Playwright）需要 40 秒以上。

2.2 为什么选 Bun？

不是为了追新，而是工程需要：

特性解决的问题
bun build --compile编译为 58MB 单文件可执行程序，用户不需要装 Node.js
原生 SQLite直接读取浏览器加密 Cookie 数据库，无需 native addon
原生 TypeScript开发时零构建步骤，源文件就是执行文件
内置 HTTP 服务器Bun.serve() 够用，不需要 Express

2.3 无障碍树 Ref 系统

这是 gstack 最优雅的设计之一。

传统方案的问题：CSS 选择器在 Shadow DOM、CSP 策略、框架水合时频繁失败。

gstack 的方案：用 Playwright 的 accessibility tree 生成引用。

# 获取页面快照，看到 @e1, @e2, @e3... 引用
$B snapshot -i

# 直接用引用操作元素
$B fill @e3 "user@example.com"
$B click @e5

背后原理：

  1. 调用 page.accessibility.snapshot() 获取 ARIA 树
  2. 遍历树，给每个元素分配顺序编号（@e1, @e2...）
  3. 为每个元素构建 Locator：getByRole(role, {name}).nth(index)
  4. 操作前用 count() 检测元素是否过期（约 5ms 开销）

这套方案零 DOM 注入、跨框架通用、对 SPA 友好。

三、14 个 Skill 全景图

3.1 分层架构

gstack 的 14 个 Skill 覆盖了产品开发的完整生命周期，可以分为 4 层：

┌─────────────────────────────────────────────────────┐
│                    产品规划层                         │
│  /plan-ceo-review  /plan-eng-review                 │
│  /plan-design-review  /design-consultation          │
├─────────────────────────────────────────────────────┤
│                    质量保障层                         │
│  /review  /design-review  /qa  /qa-only             │
├─────────────────────────────────────────────────────┤
│                    发布运营层                         │
│  /ship  /document-release  /retro                   │
├─────────────────────────────────────────────────────┤
│                    基础设施层                         │
│  /browse  /setup-browser-cookies  /gstack-upgrade   │
└─────────────────────────────────────────────────────┘

3.2 各 Skill 详解

产品规划层

/plan-ceo-review — CEO 视角产品评审

不是简单的功能评审，而是"重新思考问题本身"。有 4 种模式：

  • SCOPE EXPANSION：梦想大一点，找 10 星产品
  • SELECTIVE EXPANSION：保持范围 + 精选扩展
  • HOLD SCOPE：在当前范围内最大化严谨度
  • SCOPE REDUCTION：砍到本质，MVP 思维

典型输出："Photo upload"不是真正的功能。用户真正需要的是帮卖家创建能卖出去的 listing。如果我们自动识别产品、拉取规格和对比数据、自动起草 listing 呢？那是 10 星。"上传照片"只有 3 星。

/plan-eng-review — 工程架构评审

锁定执行计划：架构图、数据流、边界情况、测试覆盖、性能考量。会画 ASCII 数据流图，输出 14 个测试用例矩阵、6 种故障模式、3 个安全顾虑。

/plan-design-review — 设计评审

对每个设计维度打 0-10 分，并解释"如何才能到 10 分"。维度包括：排版、色彩系统、布局网格、间距、组件层级、动效、无障碍、响应式。

/design-consultation — 设计系统创建

从零开始（或更新已有）设计系统。输出 DESIGN.md 作为项目的设计 source of truth，包含美学、排版、颜色、布局、间距、动效的完整定义。

质量保障层

/review — PR 结构审查

两轮审查：

轮次关注点
Pass 1（关键）SQL 安全、竞态条件、LLM 信任边界、枚举完整性
Pass 2（信息）条件副作用、魔法数字、死代码、测试缺口

亮点：枚举完整性检查会读取 diff 之外的代码。发现新增枚举值后，用 Grep 搜索所有使用处，检查新值是否都被处理了。

每个发现分为两类：

  • AUTO-FIX：机械性问题，直接修
  • ASK：需要判断的，问你

/design-review — 实时视觉审计

Designer 的 QA：找视觉不一致、间距问题、层级问题、AI slop 模式（渐变 hero、图标网格、统一圆角）。找到问题后在源码中修复，原子提交，截图 before/after 对比。

/qa — 系统测试 + Bug 修复

这是 gstack 最强大的 Skill。三层测试：

层级范围耗时
Quick首页 + 前 5 个导航目标30 秒
Standard系统性探索 + 5-10 个问题5-15 分钟
Exhaustive+ 外观问题15-30 分钟

Diff 感知模式（最强创新）：在 feature 分支上运行时，自动分析 git diff → 映射到受影响的路由 → 只测试变更的代码路径。比全量 QA 快 10 倍。

工作流：找到 bug → 读源码 → 修复 → 原子提交 → 重新测试验证。

/qa-only — 仅报告

和 /qa 相同的测试流程，但只出报告不修复。适合"我只想知道有什么问题"的场景。

发布运营层

/ship — 全自动发布流水线

一条命令完成：合并 base 分支 → 跑测试 → pre-landing review → 版本号 → CHANGELOG → 提交 → push → 创建 PR。

核心理念：你说 ship，它就 ship。

只在这些情况下停下来问你：

  • 合并冲突（无法自动解决）
  • 测试失败（代码坏了）
  • 版本决策（MINOR 还是 MAJOR）
  • review 中需要判断的问题

绝不会问你：要提交吗？CHANGELOG 内容对吗？要 push 吗？

Review Readiness Dashboard：

+====================================================+
|            REVIEW READINESS DASHBOARD               |
+====================================================+
| Review         | Runs | Status  | Required         |
|----------------|------|---------|------------------|
| Eng Review     |  1   | CLEAR   | YES              |
| CEO Review     |  0   | —       | no               |
| Design Review  |  1   | CLEAN   | no               |
+----------------------------------------------------+
| VERDICT: CLEARED — Eng Review passed               |
+====================================================+

只有 Eng Review 会阻断发布，CEO/Design Review 仅供参考。审查结果 7 天内有效，避免重复审查。

/document-release — 发布后文档同步

读取所有文档 → 对照 diff → 更新 README/ARCHITECTURE/CONTRIBUTING/CLAUDE.md → 润色 CHANGELOG → 清理 TODOS → 可选 bump VERSION。

/retro — 周维度开发统计

分析 commit 历史、工作模式、代码质量指标。支持团队分析：每人贡献、表扬、成长建议。持久化历史，支持趋势追踪。

基础设施层

/browse — 无头浏览器

35 个命令，覆盖导航、读取、交互、检查、视觉、标签管理。核心是 Ref 系统和持久化守护进程。

/setup-browser-cookies — Cookie 导入

从真实浏览器（Chrome、Arc、Brave、Edge）导入 Cookie。打开交互式选择器，你选择要导入哪些域名。安全模型：Keychain 授权 → 进程内解密 → 只读访问 → 值不显示。

/gstack-upgrade — 自更新

检测安装类型（全局 vs 仓库内），检查版本，智能提醒（24h/48h/7d 的 snooze 机制）。

四、最佳实践路径

4.1 日常开发流（推荐路径）

1. 有新功能想法
   → /plan-ceo-review          "这个功能的 10 星版本是什么？"
   → 选择方案，确认范围

2. 锁定技术方案
   → /plan-eng-review          "架构怎么设计？边界在哪？"
   → 确认架构，退出 Plan Mode

3. Claude 写代码
   → 实现功能（几分钟到几十分钟）

4. 提交前审查
   → /review                   "这个 PR 有什么结构问题？"
   → AUTO-FIX 自动修，ASK 的你确认

5. 发布
   → /ship                     一键搞定
   → /document-release         文档同步

时间对比：

环节传统团队gstack
产品评审2 小时会议5 分钟 /plan-ceo-review
架构设计1 天文档10 分钟 /plan-eng-review
Code Review等待 1-2 天3 分钟 /review
QA 测试1-2 天5-15 分钟 /qa
发布流程30 分钟手动2 分钟 /ship

4.2 Web 应用 QA 场景

# 场景 1：feature 分支自动测试（最常用）
/qa
→ 自动分析 git diff，只测变更路径

# 场景 2：测试 staging 环境
/qa https://staging.myapp.com
→ 系统性探索所有页面

# 场景 3：需要登录的应用
/setup-browser-cookies         → 导入 Cookie
/qa https://app.myapp.com      → 以登录状态测试

# 场景 4：只想要报告
/qa-only https://staging.myapp.com
→ 输出 bug 报告，不改代码

# 场景 5：回归测试
/qa --regression baseline.json
→ 对比上次结果，哪些修了？有新问题吗？

4.3 设计驱动开发

# 从零开始的项目
/design-consultation
→ 输出 DESIGN.md（完整设计系统）

# Plan Mode 中审查设计
/plan-design-review
→ 每个维度打分，说明如何到 10 分

# 实现后视觉审计
/design-review
→ 找视觉问题，修复，截图对比

4.4 大型重构场景

1. /plan-eng-review            确认重构方案
2. Claude 实现重构
3. /review                     结构审查（特别关注枚举完整性）
4. /qa                         确保没有回归
5. /ship                       发布
6. /document-release           同步文档
7. /retro                      看看这周效率如何

五、设计哲学：三个核心理念

5.1 "烧干湖水"完整性原则

gstack 最独特的哲学：AI 让完整实现的边际成本趋近于零，永远推荐完整方案。

任务类型人工耗时Claude Code压缩比
脚手架代码2 天15 分钟100x
写测试1 天15 分钟50x
功能实现1 周30 分钟30x
Bug 修复 + 回归4 小时15 分钟20x

反模式：

  • 错：选 B 吧，覆盖 90% 且代码更少 → （如果 A 只多 70 行，选 A）
  • 错：跳过边界情况省时间 → （边界情况只需几分钟）
  • 错：测试覆盖留到后续 PR → （测试是最便宜的"湖"）
  • 错：只报人工时间 "2 周" → （应该说 "人工 2 周 / CC 1 小时"）

5.2 Fix-First 审查哲学

每个发现都要行动，不只是"标记为已知"：

  • AUTO-FIX：机械性问题直接修（N+1 查询、死代码、明显 bug）
  • ASK：需要判断的问你

5.3 非交互式设计

尊重用户的决策。你说 review 就 review，说 ship 就 ship。不在每一步都问"确定吗？"。

只在真正需要人类判断时才停下来——合并冲突、测试失败、架构决策。

六、安全模型

gstack 在安全上非常谨慎：

层面措施
网络仅监听 localhost（127.0.0.1），不暴露到网络
认证每个请求需要 Bearer Token（启动时生成 UUID v4）
Cookie进程内 PBKDF2+AES-128-CBC 解密，永不写入磁盘明文
状态文件chmod 0o600，仅 owner 可读
浏览器数据库只读访问，复制到临时文件操作，永不修改真实数据库

七、和你有什么关系？

如果你是创始人/CEO

gstack 让你一个人拥有一支虚拟工程团队。从产品思考到代码发布，全链路覆盖。Garry 自己就是证明——YC CEO 的同时日均 1-2 万行代码。

如果你是第一次用 Claude Code

gstack 是最好的起点。结构化的角色和工作流，比面对空白 prompt 强太多。从 /plan-ceo-review 开始，5 分钟就知道这工具适不适合你。

如果你是 Tech Lead

gstack 给每个 PR 带来严格的 review、QA 和发布自动化。/review 的枚举完整性检查和 LLM 信任边界分析，可能比你团队现有的 code review 还细致。

八、快速上手

# 30 秒安装
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

# 你的前 10 分钟
/plan-ceo-review    # 对任何功能想法做产品评审
/review             # 对任何有改动的分支做代码审查
/qa https://你的staging地址    # QA 测试
/retro              # 看看你这周写了多少代码

MIT 协议，完全免费。Fork it. Improve it. Make it yours.

本文基于 gstack v1.0 源码分析。gstack 仍在快速迭代中，以 GitHub 仓库为准。

GitHub: github.com/garrytan/gs…

avatar
文章
阅读
粉丝