YC 总裁 Garry Tan 开源的 gstack 神在哪？把 Claude Code 变成 20 人的硅谷顶尖创业团队！
大家好，我是不会喷火的小火龙。
过去几个月，我用 Claude Code 和 Cursor 搓过不少独立项目。在这个过程中，我最常体会到的一种感受就是容易精力分散。
一个人用 AI 搞开发，往往需要同时兼顾很多环节：
刚开始要想产品定义，琢磨这个功能到底有没有人用；接着得转到系统架构，权衡技术选型和模块边界；随后又要在终端里盯着 AI 吐出的改动；最后还得在浏览器里一遍遍手动点击排查。
面对一个空白的 AI 对话窗口，AI 确实很配合。但它缺乏全局主见，你提什么需求它就写什么代码。它不会主动提醒需求是否过于臃肿，不会提前指出架构设计里的潜在冲突，通常也不会在浏览器里把页面跑一遍检查有没有报错。
时间一长，代码越堆越多，架构逐渐走样，到后期维护成本直线上升。
最近，硅谷创业孵化器 Y Combinator（YC）现任总裁兼 CEO Garry Tan 在 GitHub 上开源了一个项目：gstack。
Garry Tan 本人技术背景深厚。他把自己多年积累下来的初创团队工程协同流程与角色分工，整理成了一套专门配合 Claude Code 使用的开源技能包。
如下图所示，单人身兼数职与坐镇控制台调度虚拟团队相比，在开发效率和流程把控上有很大不同。
这篇文章主要梳理 gstack 的具体设计：各角色如何分工、真机浏览器测试的实现方式，以及如何在本地环境配置上手。
一、为什么自由对话往往难以持续产出复杂工程
给 AI 一长串提示词，很难让它同时兼顾产品逻辑与架构规范。
Garry Tan 在 gstack 中提出了一个关键观点：软件开发在不同阶段，需要不同的工作重心和思维习惯。
- 需求规划阶段：需要做减法，弄清楚功能的核心价值，砍掉冗余的枝节；
- 架构设计阶段：需要明确模块边界和依赖关系，避免边写代码边随意改动既定技术方案；
- 编码实现阶段：需要专注于把特定函数和业务逻辑按规范写出来；
- 测试验收阶段：需要主动寻找边界条件，模拟极端情况和交互盲区。
如果把所有诉求塞进同一个对话窗口，AI 很容易给出折中的方案，既不深入推敲需求，也容易在编码中忽略架构约束。
gstack 的做法是建立一套分阶段、按角色切换上下文的工程流水线（Role-based Workflow）。
二、gstack 虚拟团队的角色划分
在 gstack 的设计中，虚拟团队被划分为四个主要的协作梯队，如下图所示：
1. 需求审查：CEO 角色
调用命令：/plan-ceo-review
独立开发时容易陷入功能堆砌的误区。想做个小工具，不知不觉就列出一长串待办事项，结果核心逻辑迟迟难以闭环。
执行 /plan-ceo-review 后，AI 会切换为注重产品 ROI 的视角，重点审视三点：
- 核心功能是否真正解决了目标用户的痛点；
- 哪些辅助功能可以推迟到后续版本，先保留核心闭环；
- 用户首次使用时的核心路径是否足够顺畅。
在这个环节，CEO 角色主要负责给初始方案做精简，收敛出紧凑的最小可用版本。
2. 架构把关：工程经理（EM）
调用命令：/plan-eng-review
方案通过后进入技术评审。不少项目写到中后期难以维护，通常是因为缺乏统一约束，AI 在编码中随意引入依赖或跨层调用。
工程经理角色在编码前会要求明确技术架构，并确立规范：
- 避免在业务逻辑中随意增加未约定的依赖包；
- 规范前端视图层与数据访问层的依赖流向；
- 评估改动对已有接口和数据格式的兼容性。
3. 设计审查与安全审计
调用命令：/review-design 与 /review-security
设计师角色负责检查组件命名规范、样式复用以及操作链路的顺畅度。安全官角色则在合入前检查敏感参数、未授权访问和注入风险。
4. 前端测试：无头浏览器守护进程
调用命令：/browse 与 /test-browser
这是 gstack 相对独特的一个设计。
许多辅助编码工具对前端界面无法直接感知。生成的代码排版和语法可能完全正确，但在实际浏览器中可能因为定位覆盖或脚本执行时机问题导致无法点击。
Garry Tan 在 gstack 中基于 Bun 与 Playwright 实现了轻量级的浏览器守护进程。
在触发测试流程时，后台会自动启动无头 Chromium 实例：
- 直接访问本地开发服务（如
localhost:3000）； - 跨命令保留登录 Cookie 与本地存储状态；
- 模拟用户在页面上的输入、点击等交互操作；
- 抓取控制台报错与网络响应，并支持截屏传递给模型做进一步判断。
模型能直接基于真实的页面渲染结果进行调试和回归验证。
三、gstack 的 7 阶段敏捷冲刺流水线
在角色分工的基础上，gstack 将需求从规划到上线梳理为 7 个递进的阶段，如下图所示：
这套流程形成了清晰的研发闭环：
- Thinking（发散思考）：借助
/office-hours梳理核心痛点与定位； - Planning（规划评审）：通过
/plan-ceo-review砍掉次要需求，再经/plan-eng-review确定架构选型； - Building（编码构建）：在确定的规范范围内执行业务开发；
- Review（多维审查）：由对应角色检查界面细节与代码安全性；
- Testing（真实测试）：拉起浏览器运行端到端测试；
- Shipping（打包交付）：通过
/ship整理分支并提交发布； - Reflecting（总结复盘）：将开发中遇到的新规范沉淀回项目文档。
四、本地安装与常用指令
在本地部署和使用 gstack，步骤相对直接。
1. 环境准备与安装
确保系统已安装 Node.js（或 Bun）、Git，并且配置好了 Claude Code。
打开终端，运行安装命令：
▼bash复制代码# 将 gstack 仓库克隆到 Claude Code 的全局技能目录 git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack # 执行初始化脚本，安装 Bun 与 Playwright 依赖 cd ~/.claude/skills/gstack && ./setup
安装脚本会自动配置 Playwright 所需的浏览器组件并初始化运行环境。
2. 常用指令速查
配置完成后，启动 Claude Code 即可使用对应的技能。常用指令如下表所示：
| 斜杠指令 | 对应角色 | 主要场景 |
|---|---|---|
/office-hours | 创业顾问 | 梳理初始构想与受众定位时使用 |
/plan-ceo-review | 首席执行官 | 开工前对需求文档进行严苛挑刺与精简 |
/plan-eng-review | 工程经理 | 确定技术选型、分层规范与依赖范围 |
/browse <url> | 测试主管 | 启动浏览器访问指定页面并观察实际渲染 |
/test-browser | 自动化测试员 | 运行端到端测试并抓取控制台报错与截图 |
/review-design | 设计师 | 检查界面规范、布局一致性与交互细节 |
/review-security | 安全合规员 | 提交代码前排查密钥泄漏与未受控接口风险 |
/ship | 发布工程师 | 整理分支、生成规范提交日志并推送到远端 |
3. 实操示例
以搭建一个简单的开发者书签管理工具为例：
- 第一步：使用
/office-hours输入初始想法，AI 会从定位角度询问主要面向哪类用户、解决什么具体问题。经过两三轮梳理，我们将重点收敛为支持代码片段高亮展示的收藏工具。 - 第二步：执行
/plan-ceo-review初始计划列了 8 个功能，CEO 角色建议在首发版本中先去掉多用户协同和社交动态，集中跑通本地代码片段同步与高亮渲染。 - 第三步：完成开发后运行
/test-browser本地服务运行在http://localhost:3000。触发测试命令后，后台自动调起 Playwright 实例填写表单并保存，排查并修复了一处弹窗层叠顺序导致的点击失效问题。 - 第四步：执行
/ship所有检查通过后，工具自动生成语义化的提交说明并推送至远程仓库。
写在最后
面对能力越来越强的模型，如何把控工程节奏同样重要。
Garry Tan 开源 gstack，核心思路在于将成熟团队的分工规范与自动化验收流程，引入到个人开发实践中。
有了明确的阶段分工和自动化工具兜底，开发者在独立推进项目时能更专注于核心逻辑，减少流程散乱带来的额外消耗。
我是小火龙，一个持续在 GitHub 等开源社区挖掘真正好用、能打的高价值项目，同时记录自己用 AI 搓工具、做产品、踩坑填坑全过程的独立开发者。如果今天这篇对你有启发，欢迎关注公众号「小火龙AI 手记」，我们下篇见。
