一个人顶一个团队

YC 掌门人 Garry Tan 的 810× 生产力背后，藏着什么秘密？

60 天，3 个生产级服务，一个人兼职完成

Garry Tan 是 Y Combinator 的 CEO，投资过 Coinbase、Instacart、Rippling。他发现自己 2026 年的代码产出是 2013 年的 810 倍（按逻辑代码行数标准化后）。他没有雇佣更多工程师 —— 他用了 gstack。

gstack 的核心思想：把 AI 不同的"专家视角"结构化成可复用的 Slash 命令。不是一个万能 AI 助手，而是一支有明确分工的虚拟团队。

⚡

为什么这对你重要

gstack 展示了一种新的工作模式：用结构化提示词把 AI 变成专业顾问，让你在没有工程团队的情况下，以团队的严谨度推进产品。理解它的架构，你就能复制这套方法。

810× 生产力是怎么来的？

Garry Tan 在 README 里公开了方法论。关键不是代码量，而是有效决策的密度：

📐

有结构的思考替代了散漫的讨论

/office-hours 强制用 6 个关键问题澄清产品方向，不让你在错误的事情上写代码。

🔍

每一行代码都经过专家视角审查

/review 从工程经理视角找生产级 Bug，/cso 用 OWASP+STRIDE 找安全漏洞，在问题进入生产前发现。

🚀

发布流程自动化，减少摩擦

/ship 自动检测、合并分支、更新 CHANGELOG、生成发布说明，把"能发布"的决策降低到分钟级。

🧪

真实浏览器验证而非假设

/qa 打开真实 Chromium 浏览器，像真实用户一样操作产品，截图存证 —— 不是模拟，是真实验证。

安装 gstack 只需 30 秒，这背后发生了什么？

安装命令


git clone \
  --single-branch \
  --depth 1 \
  https://github.com/garrytan/gstack.git \
  ~/.claude/skills/gstack

cd ~/.claude/skills/gstack
./setup

白话翻译

--single-branch 只克隆 main 分支，不下载全部历史，加快速度

--depth 1 只要最新快照，不要完整 git 历史，文件更小

安装到 ~/.claude/skills/ 这是 Claude Code 会自动发现技能包的标准路径

./setup 做两件事：编译 Bun 二进制（浏览器控制 CLI）+ 注册 skills 到 Claude

安装完成后，在任何项目里输入 /office-hours 就能立即使用全部 23 个技能

测验：你理解 gstack 的核心逻辑了吗？

gstack 最本质的创新是什么？

02

23 个专家角色

每个 Slash 命令背后，都有一个专属视角和职责

像管理真实团队一样组织 AI 工作

传统开发团队里，产品经理、工程师、设计师、测试员各有分工，不同角色在不同时机介入。gstack 把这套分工搬到了 AI 工具里：不同 Slash 命令激活不同角色视角，用正确的"专家"做正确的事。

这不只是提示词变化，而是认知框架的切换 —— 安全专家看代码与工程师看代码，关注点完全不同。

战略层 — 决定做什么

💼 /office-hours

🎯 /plan-ceo-review

📋 /autoplan

执行层 — 把事情做好

🔍 /review

🎨 /design-review

🔬 /investigate

守卫层 — 防止出问题

🛡️ /cso

🧪 /qa

🐦 /canary

点击任意命令查看详情

每个 Skill 长什么样？

每个 gstack Skill 都是一个 YAML front matter + Markdown 正文的文件，Claude Code 能直接解析它。

gstack/qa/SKILL.md（简化）


---
name: gstack
description: |
  QA testing with real browser
allowed-tools:
  - Bash
  - Read
triggers:
  - take a screenshot
  - QA test
---

## 执行步骤
1. 启动浏览器守护进程
2. 导航到目标 URL
3. 执行用户流程
4. 截图记录每一步

白话翻译

YAML 区域（--- 之间）是机器可读的元数据，Claude Code 用它来注册 Skill

allowed-tools 声明这个 Skill 有权使用哪些工具，防止权限蔓延

triggers 定义哪些关键词会自动触发这个 Skill，无需输入完整命令

--- 之后是 Markdown 正文，是给 AI 读的指令，像 SOP 手册一样详细

AI 执行时，像新员工读公司手册一样逐步执行 Markdown 里的步骤

你和 gstack 角色的一次典型对话

想象你用 /plan-ceo-review 审查一个功能想法：

0 / 6 messages

场景测验：选择正确的 Skill

你刚完成了一个用户认证模块，想检查有没有 SQL 注入或 XSS 漏洞。应该用哪个命令？

你有一个新的产品想法，还没开始写代码，想先验证这个方向是否值得做。应该先用哪个命令？

03

浏览器守护进程

gstack 最难的工程问题：为什么要一个常驻的 Chromium？

每次打开浏览器要 3 秒 —— 这是大问题

普通的 AI 浏览器工具每次执行命令都要启动一个新浏览器进程，等待加载，然后关闭。一次 QA 测试有 20 个步骤，就需要 20 次启动 —— 浪费 60-100 秒在等待上。

更糟的是：每次新进程，Cookie 和登录状态都消失了。你刚登录，下一个命令就要重新登录。

gstack 的解决方案是守护进程（Daemon）模式：启动一个 Chromium 进程，让它一直运行，每次命令直接连接已有进程。

⚡

性能差异

第一次启动：~3 秒。之后每次命令：100-200 毫秒。20 步 QA 测试：从 60 秒变成 4 秒。这就是守护进程模式的价值。

gstack 的三层浏览器架构

Claude Code 要截图、点按钮、填表单，需要通过三个层次完成这件事：

🤖

Claude Code

⌨️

Bun CLI

🖥️

Bun Server

🌐

Chromium

点击"下一步"追踪截图请求

Step 0 / 8

为什么用 Bun 而不是 Node.js？

gstack 的 ARCHITECTURE.md 里解释了选择 Bun 的技术原因：

📦

单文件二进制

bun build --compile 把整个项目编译成一个 ~58MB 可执行文件，无需 node_modules，无需 npx，无需 PATH 配置。

🗄️

内置 SQLite

读取 Chromium 的 Cookie 数据库用的是 SQLite，Bun 原生支持 new Database()，无需编译 native addon。

⚡

原生 TypeScript

Bun 直接运行 .ts 文件，无需编译步骤、无需 ts-node、无需 source map 调试。开发体验更流畅。

ARCHITECTURE.md 原文代码


# CLI 发现守护进程的方式
state_file = "~/.gstack/browser.json"
{
  "pid": 12345,
  "port": 9222,
  "started_at": "2026-05-01T10:00:00Z"
}

白话翻译

守护进程把自己的信息写入一个 JSON 文件（相当于"我在这里，这是我的地址"

pid 是进程 ID，用于检查进程是否还活着

port 是 HTTP 服务的端口，CLI 通过这个端口发命令

CLI 启动时先读这个文件，有文件就直连，没文件就新启动守护进程

30 分钟无操作，守护进程自动退出，下次使用自动重启 —— 省内存又不影响体验

测验：守护进程模式

gstack 使用守护进程模式最重要的优势（除了速度），是什么？

04

Skill 如何运作

从 Markdown 文件到 AI 行为 —— gstack 的运作机制

输入 /review 到 AI 开始审查代码，中间发生了什么？

gstack 的 Skill 系统有一个优雅的设计：所有的"专家知识"都编码在 Markdown 文件里，Claude Code 把它当作实时操作手册读取并执行，而不是"训练进 AI"。

这意味着：更新 Skill 只需编辑 Markdown，不需要重新训练模型；Skill 的行为完全透明可审查；你可以随时 fork 和定制。

1

触发检测

你输入 /review 或说"帮我看看这段代码"，Claude Code 的 Skill 路由器匹配到 triggers 列表里的关键词，加载对应 SKILL.md 文件。

2

Preamble 执行

每个 Skill 有一个 Preamble 区块，包含需要首先运行的 Bash 命令（比如检查更新、加载项目上下文、读取过往 Learnings）。

3

上下文加载

Skill 读取当前项目的 CLAUDE.md（项目规范）、git diff（变更内容）、learnings.jsonl（过往经验）构建完整上下文。

4

角色扮演执行

Claude Code 按照 SKILL.md 的指令，以对应角色视角执行任务。/review 的 AI 会"变成"一个挑剔的工程经理，找每一行代码的潜在问题。

gstack 如何"记住"项目经验？

gstack 有一个 Learnings 系统，把项目特定的知识存储到 ~/.gstack/projects/[slug]/learnings.jsonl：

learnings.jsonl 格式


{
  "id": "abc123",
  "ts": "2026-05-01T10:00:00Z",
  "skill": "review",
  "tags": ["auth", "security"],
  "content": "This project uses
    custom JWT lib, NOT
    jsonwebtoken package"
}

白话翻译

每条 Learning 是一个 JSON 对象，记录在对应 Skill 执行时学到的经验

ts 是时间戳，system 知道这条经验是多久前的

skill 标记这条经验来自哪个 Skill，review 积累的和 qa 积累的分开管理

tags 用于语义搜索，下次遇到 auth 相关代码时自动加载这条记忆

这条记忆告诉 AI：这个项目用自定义 JWT 库，别建议用 jsonwebtoken

🧠

为什么这比"训练 AI"更实用

训练 AI 需要数据、计算资源和时间。Learnings 系统用几行 JSON 就能让 AI "记住"项目特定知识，而且任何时候都能审查、编辑或删除这些记忆。完全透明，完全可控。

测验：gstack 机制理解

你想自定义 /review 命令，让它额外检查你的项目特有的代码规范。最合适的做法是？

05

从想法到上线

gstack 完整工作流：想法 → 规划 → 实现 → 审查 → 发布

一个功能从零到生产的 gstack 路径

gstack 的设计哲学：每个阶段都有专门的"守门人"角色，确保质量，同时不拖慢速度。

1

/office-hours 产品验证

→

2

/autoplan 技术规划

→

3

编写代码实现

→

4

/review + /cso 审查

→

5

/qa 功能验证

→

6

/ship 发布上线

🎯

这个流程的关键优势

传统团队这个流程需要多次会议和跨部门沟通，每个阶段等人 1-2 天。gstack 把每个角色变成即时可调用的命令，整个流程可以在一天内完成。速度提升不是因为省略了步骤，而是消除了等待。

/ship 命令：发布流程自动化

/ship 是 gstack 里最"解放生产力"的命令之一，它把通常需要 30 分钟手工操作的发布流程自动化。

检测读取 git diff，确认 PR 在正确分支，没有未解决的 Review 评论

合并以 squash 方式合并 PR，生成清晰的合并提交信息

CHANGELOG 根据提交记录自动生成 CHANGELOG.md 条目，按类别分组

版本号根据变更类型建议语义版本号（patch/minor/major），自动更新 package.json

发布说明生成面向用户的 Release Notes，用非技术语言描述新功能和修复

真实的 gstack 工作日

一位使用 gstack 的创始人，从早上到晚上的工作节奏：

0 / 9 messages

最终测验：综合应用

你用 /ship 发布了新版本，想监控上线后的错误率和性能指标，防止出现预期外的问题。应该用哪个命令？

🎓

课程完成！你学到了什么

gstack 的完整架构：23 个专家角色 Skill 体系、Bun 守护进程浏览器架构、Learnings 记忆系统、以及从想法到发布的完整工作流。这套方法论让一个人能以团队的严谨度推进产品。