gstack：YC CEO 用来日产 2 万行代码的 Claude Code 软件工厂
Garry Tan 是 Y Combinator 的 CEO。在过去 60 天里，他写了超过 60 万行生产代码，35% 是测试，每天 1 到 2 万行可用代码。同时他还在全职做 YC CEO 的工作。
这不是靠加班，是靠工具。他把自己的整套 Claude Code 工具集开源了，叫 gstack，一周拿了 26900 个 Star。
gstack 是什么
一句话：把 Claude Code 变成一个你实际管理的虚拟工程团队。
- CEO 重新思考产品方向
- 工程经理锁定架构
- 设计师捕捉 AI 审美问题
- 偏执的审查者找生产 bug
- QA 打开真实浏览器点击测试
- 发布工程师提交 PR
15 个专业角色，6 个安全工具，全部是 Markdown 文件和 slash 命令，MIT 协议，免费。
安装只要 30 秒
需要 Claude Code、Git、Bun v1.0+：
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup前 10 分钟体验路径：/office-hours → /plan-ceo-review → /review → /qa。
完整 Skill 清单
| Skill | 角色 | 功能 |
|---|---|---|
/office-hours | YC Office Hours | 起点。六个强制问题重新定义问题，挑战前提，生成实现方案。设计文档喂给下游 Skills |
/plan-ceo-review | CEO / 创始人 | 重新思考问题。找到请求背后隐藏的 10 星产品。四种模式：扩张、选择性扩张、保持范围、缩减 |
/plan-eng-review | 工程经理 | 锁定架构、数据流、图表、边界情况、测试。强制隐藏假设浮出水面 |
/plan-design-review | 高级设计师 | 交互式计划模式设计审查。为每个维度打分 0-10，解释 10 分标准，修复计划 |
/design-consultation | 设计合作伙伴 | 从零构建完整设计系统。了解行业，提出创意风险，生成真实产品样机 |
/review | Staff 工程师 | 找到能通过 CI 但会在生产炸的 bug。自动修复明显问题。标记完整性缺口 |
/investigate | 调试器 | 系统化根因调试。铁律：没有调查就没有修复。追踪数据流，测试假设，3 次失败后停止 |
/design-review | 会写代码的设计师 | 实时站点视觉审计 + 修复循环。80 项审计，然后修复发现的问题。原子提交，前后对比截图 |
/qa | QA 主管 | 测试你的应用，找 bug，用原子提交修复，重新验证。为每个修复自动生成回归测试 |
/qa-only | QA 报告员 | 和 /qa 相同方法但只报告。当你想要纯 bug 报告而不改代码时用 |
/ship | 发布工程师 | 同步 main，跑测试，审计覆盖率，push，开 PR。如果你没测试框架就自动建一个。一个命令 |
/document-release | 技术作家 | 更新所有项目文档以匹配你刚发布的。自动捕获过时的 README |
/retro | 工程经理 | 团队感知周回顾。每人分解，发布连胜，测试健康趋势，成长机会 |
/browse | QA 工程师 | 给 agent 眼睛。真实 Chromium 浏览器，真实点击，真实截图。每条命令 ~100ms |
/setup-browser-cookies | 会话管理器 | 从真实浏览器（Chrome、Arc、Brave、Edge）导入 cookie 到无头会话。测试认证页面 |
| 多 AI | ||
/codex | 第二意见 | OpenAI Codex CLI 的独立审查。三种模式：代码审查（通过/失败门）、对抗性挑战、带会话连续性的开放咨询 |
| 安全 & 工具 | ||
/careful | 安全护栏 | 破坏性命令前警告（rm -rf、DROP TABLE、force-push、git reset —hard）。可以覆盖任何警告。常见构建清理已加白名单 |
/freeze | 编辑锁 | 将所有文件编辑限制到单一目录。阻止边界外的 Edit 和 Write。调试时的事故预防 |
/guard | 全安全 | 在一个命令中结合 /careful + /freeze。生产工作的最大安全性 |
/unfreeze | 解锁 | 移除 /freeze 边界，再次允许所有地方编辑 |
/gstack-upgrade | 自我更新器 | 升级 gstack 到最新版本。检测全局 vs vendored 安装，同步两者，显示更改内容 |
Skill 深度解析
/office-hours — 这是每个项目应该开始的地方
在你计划之前，在你审查之前，在你写代码之前 — 坐下来和一个 YC 风格的合伙人一起思考你实际在构建什么。不是你认为你在构建的。是你实际在构建的。
重新定义框架
真实项目案例：用户说”我想做一个日历简报 app”。合理的请求。然后它问痛点 — 具体例子，不是假设。他们描述了助手漏掉事情、横跨多个 Google 账户的日历项目信息过时、AI 糊弄的准备文档、花很长时间追踪错误位置的事件。
它回来说：“我要挑战这个框架，因为我认为你已经超越它了。你说’多 Google 日历管理的日历简报 app’。但你实际描述的是一个个人参谋长 AI。”
然后它提取了五个用户没意识到自己在描述的能力：
- 监控你的日历 — 横跨所有账户，检测过期信息、缺失位置、权限缺口
- 生成真实准备工作 — 不是后勤摘要，而是为董事会会议、播客、筹款准备的智力工作
- 管理你的 CRM — 你要见谁，关系是什么，他们想要什么，历史是什么
- 优先你的时间 — 标记准备需要提早开始的时间，主动阻挡时间，按重要性排序事件
- 用金钱换杠杆 — 主动寻找委派或自动化的方式
那次重新定义改变了整个项目。他们本来要构建一个日历 app。现在他们在构建价值 10 倍的东西 — 因为这个 Skill 听他们的痛点而不是他们的功能请求。
前提挑战
重新定义之后，它展示前提让你验证。不是”这听起来好吗？” — 是关于产品的可证伪声明：
- 日历是锚定数据源，但价值在顶层的智能层
- 助手不会被取代 — 他们获得超能力
- 最窄的楔子是一个真正有效的日历简报
- CRM 集成是必备，不是锦上添花
你同意、不同意或调整。你接受的每个前提在设计文档中都是承重的。
实现方案
然后它生成 2-3 个具体实现方案和诚实的工作量估算：
- 方案 A：日历简报优先 — 最窄楔子，明天发布，M 工作量（人类：~3 周 / CC：~2 天）
- 方案 B：CRM 优先 — 先构建关系图，L 工作量（人类：~6 周 / CC：~4 天）
- 方案 C：完整愿景 — 一次性全部，XL 工作量（人类：~3 个月 / CC：~1.5 周）
推荐 A 因为你从实际使用中学习。CRM 数据第二周自然来。
两种模式
创业模式 — 为创始人和内部创业者构建业务。你得到六个强制问题，提炼自 YC 合伙人如何评估产品：需求现实、现状、迫切具体性、最窄楔子、观察 & 惊喜、未来适应。这些问题故意让人不舒服。如果你说不出需要你产品的具体人，那是写代码前要学的最重要的事。
构建者模式 — 为 hackathon、副项目、开源、学习和娱乐。你得到一个热情的合作者帮你找到想法的最酷版本。什么会让人说”哇”？到可分享东西的最快路径是什么？问题是生成性的，不是审问性的。
设计文档
两种模式都以写到 ~/.gstack/projects/ 的设计文档结束 — 那个文档直接喂给 /plan-ceo-review 和 /plan-eng-review。完整生命周期现在是：office-hours → plan → implement → review → QA → ship → retro。
/plan-ceo-review — 创始人模式
这是我想要模型以品味、雄心、用户同理心和长期视野思考的地方。我不想让它字面理解请求。我想让它先问一个更重要的问题：
这个产品实际是为了什么？
我把这想成 Brian Chesky 模式。
重点不是实现明显的工单。重点是从用户视角重新思考问题，找到感觉不可避免、令人愉悦、甚至可能有点魔幻的版本。
示例
假设我在构建一个 Craigslist 风格的列表 app，我说：
“让卖家为他们的物品上传照片。”
弱助手会添加一个文件选择器保存图片。
那不是真实产品。
在 /plan-ceo-review 中，我想让模型问”照片上传”是否就是功能。也许真实功能是帮某人创建一个实际能卖的列表。
如果那是真实工作，整个计划改变。
现在模型应该问：
- 我们能从照片识别产品吗？
- 我们能推断 SKU 或型号吗？
- 我们能搜索网络自动起草标题和描述吗？
- 我们能拉取规格、类别、价格对比吗？
- 我们能建议哪张照片作为主图转化最好吗？
- 我们能检测上传的照片是否丑陋、黑暗、杂乱或低信任吗？
- 我们能让体验感觉高级而不是像 2007 年的死表单吗？
那就是 /plan-ceo-review 为我做的。
它不只是问”我如何添加这个功能？” 它问**“这个请求内隐藏的 10 星产品是什么？”**
四种模式
- 范围扩张 — 梦想大。agent 提出雄心版本。每个扩张作为你选择加入的独立决策呈现。热情推荐
- 选择性扩张 — 将你当前范围作为基线，但看看还有什么可能。agent 以中立推荐一个个浮出机会 — 你挑选值得做的
- 保持范围 — 对现有计划最大严格。不浮出扩张
- 范围缩减 — 找到最小可行版本。砍掉其他一切
愿景和决策持久化到 ~/.gstack/projects/ 所以它们在对话外存活。特殊愿景可以提升到你 repo 的 docs/designs/ 给团队看。
/plan-eng-review — 工程经理模式
一旦产品方向对了，我想要完全不同类型的智能。我不想要更多蔓延的构思。我不想要更多”如果…岂不是很酷”。我想让模型成为我最好的技术主管。
这个模式应该搞定：
- 架构
- 系统边界
- 数据流
- 状态转换
- 失败模式
- 边界情况
- 信任边界
- 测试覆盖
还有一个对我来说意外巨大的解锁：图表。
当你强制 LLM 画系统时它们变得更完整。序列图、状态图、组件图、数据流图、甚至测试矩阵。图表强制隐藏假设浮到表面。它们让模糊计划更难。
所以 /plan-eng-review 是我想让模型构建能承载产品愿景的技术脊柱的地方。
审查就绪仪表板
每个审查（CEO、Eng、Design）记录其结果。每次审查结束，你看到一个仪表板：
+====================================================================+
| 审查就绪仪表板 |
+====================================================================+
| 审查 | 运行 | 最后运行 | 状态 | 必需 |
|-----------------|------|---------------------|-----------|----------|
| Eng Review | 1 | 2026-03-16 15:00 | CLEAR | YES |
| CEO Review | 1 | 2026-03-16 14:30 | CLEAR | no |
| Design Review | 0 | — | — | no |
+--------------------------------------------------------------------+
| 结论: CLEARED — Eng Review 通过 |
+====================================================================+Eng Review 是唯一必需的门（用 gstack-config set skip_eng_review true 禁用）。CEO 和 Design 是信息性的 — 分别推荐给产品和 UI 更改。
计划到 QA 流程
当 /plan-eng-review 完成测试审查部分，它写一个测试计划工件到 ~/.gstack/projects/。当你后面运行 /qa，它自动拾取那个测试计划 — 你的工程审查直接喂入 QA 测试，没有手动复制粘贴。
/plan-design-review — 在写任何代码前审查设计
这是我的高级设计师审查你的计划 — 在你写任何一行代码之前。
大多数计划描述后端做什么但从不指定用户实际看到什么。空状态？错误状态？加载状态？移动布局？AI 糊弄风险？这些决策被推迟到”实现时再想” — 然后工程师发布”未找到物品”作为空状态因为没人指定更好的。
/plan-design-review 在计划阶段捕获所有这些，当修复便宜时。
它像 /plan-ceo-review 和 /plan-eng-review 一样工作 — 交互式，一次一个问题，用 STOP + AskUserQuestion 模式。它为每个设计维度打 0-10 分，解释 10 分看起来什么样，然后编辑计划到那里。评分驱动工作：低分 = 很多修复，高分 = 快速通过。
对计划的七轮：信息架构、交互状态覆盖、用户旅程、AI 糊弄风险、设计系统对齐、响应式/可访问性、未解决设计决策。对每一轮，它找缺口，要么直接修复（明显的），要么问你做设计选择（真正的权衡）。
/design-consultation — 从零构建设计系统
/plan-design-review 审计一个已经存在的站点。/design-consultation 是当你什么都没有时 — 没有设计系统、没有字体选择、没有色板。你从零开始，想要一个高级设计师坐下来和你一起构建整个视觉身份。
这是一个对话，不是表单。agent 问你的产品、你的用户、你的受众。它思考你的产品需要传达什么 — 信任、速度、工艺、温暖，任何合适的 — 并从那里倒推到具体选择。然后它提出一个完整、一致的设计系统：审美方向、排版（3+ 字体带特定角色）、带十六进制值的色板、间距比例、布局方法、动作策略。每个推荐带理由。每个选择强化其他选择。
但一致性是底线。每个开发工具仪表板看起来一样 — 干净无衬线、柔和灰色、蓝色强调。它们都一致。它们都可忘记。让产品从”好看”到人们实际认识的区别是故意的创意风险：标题用意外衬线、没人在你类别用的大胆强调、让你的数据感觉权威而不是通风的更紧间距。
那就是 /design-consultation 真正关于的。它不只是提出一个安全系统。它提出安全选择和风险 — 并告诉你哪个是哪个。“这些是让你在类别中识字的选择。这是我认为你应该打破惯例的地方，以及为什么。” 你选哪些风险承担。agent 检查整个系统两种方式都一致。
/review — 偏执的 staff 工程师模式
通过的测试不意味着分支安全。
/review 存在因为有一整类 bug 能存活 CI 并在生产打你脸。这个模式不是关于梦想更大。不是关于让计划更漂亮。是关于问：
还有什么能坏？
这是结构审计，不是风格吹毛求疵。我想让模型寻找这些东西：
- N+1 查询
- 过期读
- 竞态条件
- 坏信任边界
- 缺失索引
- 逃逸 bug
- 破损不变量
- 坏重试逻辑
- 通过却漏掉真实失败模式的测试
- 忘记的枚举处理器 — 添加新状态或类型常量，
/review追踪它通过代码库的每个 switch 语句和白名单，不只是你改的文件
修复优先
发现获得行动，不只是列出。明显机械修复（死代码、过时注释、N+1 查询）自动应用 — 你看到每个 [AUTO-FIXED] file:line Problem → 做了什么。真正模糊的问题（安全、竞态、设计决策）浮出给你决定。
完整性缺口
/review 现在标记捷径实现，其中完整版本花费不到 30 分钟 CC 时间。如果你选了 80% 解决方案且 100% 解决方案是湖不是海，审查会叫出来。
/qa — 真实浏览器 QA
当某个东西坏了你不知道为什么，/investigate 是你的系统调试器。它遵循铁律：没有根因调查就没有修复。
不是猜测和打补丁，它追踪数据流，匹配已知 bug 模式，一次测试一个假设。如果三次修复尝试失败，它停止并质疑架构而不是抖动。这防止”让我再试一次”螺旋浪费小时。
四种模式
- Diff 感知（功能分支自动）— 读
git diff main，识别你的更改影响哪些页面，具体测试它们 - 完整 — 整个 app 的系统探索。5-15 分钟。记录 5-10 个有据 issue
- 快速（
--quick）— 30 秒冒烟测试。首页 + 前 5 导航目标 - 回归（
--regression baseline.json）— 运行完整模式，然后对比先前基线
自动回归测试
当 /qa 修复一个 bug 并验证，它自动生成一个捕获确切坏场景的回归测试。测试包括完整归因追溯回 QA 报告。
/ship — 发布机器模式
一旦我决定了构建什么、搞定技术计划、运行了严肃审查，我不想更多谈话。我想执行。
/ship 是为最后一英里。是为就绪分支，不是决定构建什么。
这是模型应该停止像头脑风暴伙伴表现、开始像纪律发布工程师表现的地方：同步 main、运行正确测试、确保分支状态理智、更新 changelog 或版本如果 repo 期望、push、创建或更新 PR。
测试引导
如果你的项目没测试框架，/ship 建一个 — 检测你的运行时，研究最佳框架，安装它，为你的实际代码写 3-5 个真实测试，建立 CI/CD（GitHub Actions），创建 TESTING.md。100% 测试覆盖是目标 — 测试让 vibe 编码安全而不是 yolo 编码。
覆盖审计
每次 /ship 运行从你的 diff 构建代码路径图，搜索对应测试，产生带质量星的 ASCII 覆盖图。缺口获得自动生成测试。你的 PR body 显示覆盖：Tests: 42 → 47 (+5 new)。
审查门
/ship 在创建 PR 前检查审查就绪仪表板。如果 Eng Review 缺失，它问 — 但不会阻挡你。决策每分支保存所以你不会被重复问。
很多分支在有趣工作做完、只剩无聊发布工作时死掉。人类拖延那部分。AI 不应该。
/browse — 给 agent 眼睛
/browse 是闭环的 Skill。在它之前，agent 能思考和编码但还是半盲的。它必须猜测 UI 状态、auth 流、重定向、控制台错误、空状态、坏布局。现在它能直接去看。
这是一个编译的二进制，和持久 Chromium 守护进程通信 — 建立在微软的 Playwright 上。第一次调用启动浏览器（~3s）。之后每次调用：~100-200ms。浏览器在命令间保持运行，所以 cookie、标签、localStorage 延续。
浏览器移交
当无头浏览器卡住 — CAPTCHA、MFA、复杂 auth — 移交给用户：
Claude: 我卡在登录页的 CAPTCHA。打开一个可见 Chrome 让你解决。
> browse handoff "卡在登录页 CAPTCHA"
Chrome 在 https://app.example.com/login 打开，你所有 cookie 和标签完整。
解决 CAPTCHA 并告诉我你完成了。
你: done
Claude: > browse resume
拿到新快照。成功登录。继续 QA。浏览器跨移交保留所有状态（cookie、localStorage、标签）。resume 后，agent 拿到你离开处的新快照。如果 browse 工具连续失败 3 次，它自动建议用 handoff。
/codex — 第二意见
当 /review 从 Claude 视角捕获 bug，/codex 带来完全不同的 AI — OpenAI 的 Codex CLI — 审查同一 diff。不同训练，不同盲点，不同优势。重叠告诉你什么是确实真的。每个独特发现是单独任何一个都不会捕获 bug 的地方。
三种模式
审查 — 对当前 diff 运行 codex review。Codex 读每个改变文件，按严重程度分类发现（P1 关键、P2 高、P3 中），返回通过/失败判断。任何 P1 发现 = 失败。审查完全独立 — Codex 看不到 Claude 的审查。
挑战 — 对抗模式。Codex 主动尝试破坏你的代码。它寻找边界情况、竞态、安全漏洞、负载下会失败的假设。用最大推理努力（xhigh）。把它想成你逻辑的渗透测试。
咨询 — 带会话连续性的开放对话。问 Codex 关于代码库的任何事。后续问题重用同一会话，所以上下文延续。非常适合”我这样想对吗？“时刻。
跨模型分析
当 /review（Claude）和 /codex（OpenAI）都审查了同一分支，你得到跨模型比较：哪些发现重叠（高信心）、哪些对 Codex 独特（不同视角）、哪些对 Claude 独特。这是代码审查的”两个医生、同一病人”方法。
安全护栏
四个 Skill 为任何 Claude Code 会话添加安全栏。它们通过 Claude Code 的 PreToolUse 钩子工作 — 透明、会话作用域、无配置文件。
/careful — 当你在生产附近工作、运行破坏性命令或只是想要安全网时说”小心”或运行 /careful。每个 Bash 命令针对已知危险模式检查：rm -rf、DROP TABLE、git push --force、git reset --hard、kubectl delete 等。常见构建工件清理（rm -rf node_modules、dist、.next）已加白名单 — 常规操作没误报。
/freeze — 限制所有文件编辑到单一目录。当你调试账单 bug，你不想 Claude 意外”修复” src/auth/ 的无关代码。/freeze src/billing 阻止那个路径外的所有 Edit 和 Write 操作。/investigate 自动激活这个 — 它检测被调试模块并冻结编辑到那个目录。
/guard — 全安全模式 — 在一个命令结合 /careful + /freeze。破坏性命令警告加目录作用域编辑。触碰生产或调试实时系统时用。
/unfreeze — 移除 /freeze 边界，再次允许所有地方编辑。钩子为会话保持注册 — 它们只是允许一切。再次运行 /freeze 设新边界。
10-15 个并行 Sprint
gstack 单个 Sprint 就很强，但真正的变革是并行。配合 Conductor 可以同时运行 10-15 个 Claude Code 会话，每个在独立工作区。一个做 office-hours，一个做 review，一个实现功能，一个做 QA。你像 CEO 管理团队一样管理它们：只关注需要决策的节点，其余让它们自己跑。
Greptile 集成
Greptile 是 YC 公司，自动审查你的 PR。它捕获真实 bug — 竞态、安全问题、通过 CI 却在生产炸的东西。它确实不止一次救了我的命。我爱这些人。
工作原理
任何自动审查器的问题是分诊。Greptile 很好，但不是每条评论都是真问题。有些是误报。有些标记你三次提交前已修的东西。没有分诊层，评论堆积你开始忽略它们 — 这违背目的。
gstack 解决这个。/review 和 /ship 现在是 Greptile 感知的。它们读 Greptile 的评论，分类每个，采取行动：
- 有效 issue 添加到关键发现并在发布前修复
- 已修 issue 得到自动回复承认捕获
- 误报 被推回 — 你确认，解释为什么错的回复出去
结果是两层审查：Greptile 在 PR 上异步捕获，然后 /review 和 /ship 作为正常工作流一部分分诊那些发现。没东西掉缝里。
从历史学习
你确认的每个误报保存到 ~/.gstack/greptile-history.md。未来运行自动跳过你代码库的已知 FP 模式。/retro 追踪 Greptile 随时间打击率 — 所以你能看信噪比是否改善。
为什么 gstack 有效
回到之前分析的三个洞察：
第一，角色而非提示词。每个 Skill 是一个有明确职责边界的角色，比空白提示词更有结构。
第二，姿态而非知识。plan-ceo-review 不教 Claude 商业知识，它给 Claude 一个严厉的审查姿态和不可跳过的流程。这就是为什么一个工程 Skill 能审查商业计划。
第三，流程而非混沌。Think → Plan → Build → Review → Test → Ship，每个阶段有对应工具。没有流程，十个 Agent 就是十个混乱源。有了流程，每个 Agent 都知道自己该做什么。
和我们之前的文章的关联
这是 Agent Skills 系列的第四篇，也是最实战的一篇：
- Google 的五大设计模式 — 理论框架
- Anthropic 的 Skills 经验 — 官方方法论
- dontbesilent 的 plan-ceo-review 分析 — 单个 Skill 的深度解剖
- gstack 完整教程 — 一整套工具的实战指南
四篇合在一起，从理论到实践，覆盖了 Agent Skills 的全部知识。
参考
- gstack GitHub（MIT License）
- Garry Tan，Y Combinator CEO
- Conductor，并行 Sprint 工具
- 顶级 Skill 长什么样
- Anthropic 内部 Skills 经验
- Agent Skills 五大设计模式
评论