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

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

一、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，而是一个持久化的无头浏览器守护进程。

scss 复制代码

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 生成引用。

bash 复制代码

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

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

背后原理：

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

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

三、14 个 Skill 全景图

3.1 分层架构

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

bash 复制代码

┌─────────────────────────────────────────────────────┐
│                    产品规划层                         │
│  /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：

diff 复制代码

+====================================================+
|            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 日常开发流（推荐路径）

bash 复制代码

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 场景

bash 复制代码

# 场景 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 设计驱动开发

bash 复制代码

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

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

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

4.4 大型重构场景

markdown 复制代码

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 还细致。

八、快速上手

bash 复制代码

# 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...