Gstack 深度解析：YC CEO 开源的 AI 工程团队

在上篇文章中，我深度解析了 superpowers 这套 skill，没看过的同学可以点此看下。这两天我又关注到有个叫 gstack 的 skill 也非常火爆，也是一个用于 AI Coding 的 skill，我在深度学习后，发现也是一套非常值得推荐的 skill，接下来我们就先来看下 gstack 是什么？它是如何设计的？文末我也会尝试回答下，同为 AI Coding 的 skill，它和 superpowers 这套 skill 有啥异同！

Gstack 是 Y Combinator（简称 YC）总裁兼 CEO Garry Tan 开源的一套 AI 工程工作流，它将 Claude Code 从一个通用的 AI 助手变成了一整支虚拟工程团队：CEO、产品经理、工程经理、资深设计师、安全专家、QA 工程师、发布工程师……应有尽有。可能有些同学不了解 YC，我这里简单介绍一下：YC 是美国知名的创业孵化公司，曾孵化过许多知名企业，比如 Reddit、Dropbox……YC 也曾进军中国市场，当时陆奇负责中国业务，但可能因为水土不服，一年后便退出了中国市场。不过，这并不影响 YC 在创投领域取得的成就。你也应该感受到这个项目的来头有多大了，虚的说完我们来具体看下这套 skill 是如何设计的。

概览

这套 skill 的设计思路很有意思，它不是基于流程来设计的，而是基于角色来设计的。就像一个真实的创业公司，你需要不同的人来负责不同的事情——产品经理想清楚做什么，工程经理想清楚怎么做，设计师保证美观，QA 保证质量，安全官保证不出事，最后发布工程师负责上线。

Gstack 就是把这个团队角色拆成了一个个 skill，让 AI 分别扮演这些角色。更重要的是，这些角色不是孤立的，而是像真实团队一样有协作流程：从创意到产品，从计划到实现，从测试到发布，最后还有回顾复盘。

我把这个流程画了张图，大家可以直观感受一下：

这套 skill 的设计思路已经很清晰了，它是基于角色设计，把一个完整的工程团队"序列化"成了一套可以按顺序调用的技能。每个角色都有自己的职责和专业视角，当你按顺序调用这些技能时，就相当于一个完整的团队在为你工作。

核心 skill 介绍

由于篇幅所限，我没法把所有 skill 都详细介绍一遍。这里依然挑选部分来讲，挑选标准是：看名字不太容易理解用途的，以及比较关键的 skill。至于一些偏开发的 skill，见名知意，我就不再展开；感兴趣的同学可以自行查阅官方 GitHub 文件。

/office-hours：YC 产品门诊

这是整个流程的起点，也是我觉得最有意思的一个 skill。你可以把它理解为 Garry Tan 亲自坐诊的"YC 产品门诊"——它不会顺着你说，反而会质疑你的前提，挑战你的假设。

为什么这个 skill 很重要？

做产品最容易犯的错误就是"解决方案找问题"——你先想到一个功能，然后去给它找用武之地。YC 见过太多创业公司死在这上面了，这个 skill 就是在帮你避免这个坑。

它是怎么工作的？

1. 重构框架：倾听你的痛点，而不是你的功能需求。经常会帮你重新发现产品真正的价值。
   • 比如你说"我要做一个日历每日简报应用"
   • 它可能会告诉你——不，你真正想要的是一个个人首席 AI 幕僚
   • 它会帮你管理日程、准备会议、优先级排序
2. 前提挑战：提出可证伪的前提让你验证，每个接受的前提都会成为产品设计的支柱。
   • 不会听你说"我想做个 APP"
   • 而是会追问"具体谁在什么场景下遇到了什么问题？"
   • 每个问题都要你用具体例子回答，而不是空泛的假设
3. 实现方案：生成 2-3 种具体的实现方案，并给出诚实的工作量估算。
   • 人工团队时间 vs Claude Code + gstack 时间（压缩比通常在 20x-100x）
   • 推荐最窄切入点，让你最快上线从真实使用中学习

两种模式：

• 创业模式：面向创始人，六个"强迫性问题"，逼着你想清楚真正的痛点是什么
• 建造者模式：面向黑客松、Side Project、开源，帮助你找到最酷的版本和最快的分享路径

说白了，这一步就是把"我有个想法"变成"这是一个值得做的产品"。最后生成一份设计文档保存在 ~/.gstack/projects/，这份文档会直接输入给后续的 /plan-ceo-review 和 /plan-eng-review。

/plan-ceo-review：CEO 战略复盘

有了设计文档之后，就该 CEO 出场了。这个 skill 扮演的是 Garry Tan 本人的角色——站在创始人视角，重新思考问题。

为什么需要 CEO 视角？

普通的 AI 助手会字面执行你的需求：你说"加个照片上传功能"，它就给你加个文件选择器。但真正的 CEO 会问一个更重要的问题：这个产品到底是做什么的？

这个 skill 也可以称之为 Brian Chesky 模式——重点不是实现显而易见的需求，而是从用户角度重新思考问题，找到那个不可避免、令人愉悦、甚至有点神奇的版本。

举个真实的例子：

你说："我要给 Craigslist 风格的列表应用增加卖家照片上传功能"。 普通助手：好的，这就加文件选择器。 /plan-ceo-review：等等，照片上传真的是这个功能吗？真正的需求是不是帮卖家创造一个能卖出去的列表？那我们能不能：

• 自动识别商品是什么？
• 自动搜索网页拉出规格参数和分类价格对比？
• 自动生成标题描述？
• 自动建议哪张照片最适合当首图？
• 告诉你哪些照片看起来不行（太暗、太乱、低信任）？
• 让整个体验感觉高级而不是 2007 年的死气表单？

看到了吧？这就是 CEO 视角和普通执行者的区别。它不会只满足于字面需求，而是会问：这个请求背后隐藏的 10 星级产品是什么？

四种模式：

1. SCOPE EXPANSION（扩围）：大胆梦想，逐个呈现扩展方案让你选择
2. SELECTIVE EXPANSION（选择性扩围）：保持核心范围作为基线，看看还有什么可能
3. HOLD SCOPE（保持范围）：在现有范围内精益求精，不随便加东西
4. SCOPE REDUCTION（缩围）：stripped to essentials，只保留最核心的

这个 skill 最有意思的地方是，它不会只说"好"或"不好"，而是会像真正的 CEO 那样问你："这真的是用户需要的吗？我们能不能做得更大？或者，我们是不是想得太大了？"每种模式都有清晰的 trade-off，让你做最终决策。

/browse：真实无头浏览器

这是 gstack 的"秘密武器"之一——一个真实的 Chromium 浏览器，可以真正打开网页、点击按钮、填写表单、截图。

为什么这个很重要？

以前 AI 说"我测试过了"，你可能心里打鼓——它真的打开浏览器看了吗？还是在"幻想"测试结果？很多 AI 工具的"测试"都是基于 DOM 结构的模拟，或者更糟——直接编结果。

有了 /browse，你就能确信：是的，它真的测了。

技术原理：

它是一个编译后的二进制，和持久化 Chromium 守护进程通信，基于 Playwright。第一次调用启动浏览器（~3 秒），之后每次调用 ~100-200ms。浏览器在命令之间保持运行，所以 cookie、标签页、localStorage 都会保留。

关键功能：

• 真实渲染：不是模拟，是真的 Chromium 渲染页面
• 完整交互：点击、输入、滚动、上传、选择、悬停
• 断言验证：is visible/enabled/checked/editable
• 读取信息：text、html、links、console、network
• 可视化：screenshot、responsive、diff、PDF
• 快照引用：带 @e 引用的可访问性树，让你不用猜 CSS 选择器
• 多标签页支持：可以同时打开多个页面
• 命令链式调用：一条命令接一条，像真实用户操作
• 从真实浏览器导入 Cookie：通过 /setup-browser-cookies 直接导入
• 用户交接：碰到验证码/MFA 可以打开可见浏览器让用户解决，之后再恢复

举个实际例子：

你想测试登录流程，以前 AI 可能会说"我点击了登录按钮，然后跳转到了 dashboard"。但有了 /browse，它会真的这么做：

# 1. 转到登录页
$B goto <https://app.example.com/login>

# 2. 查看可交互内容
$B snapshot -i
→ [@e1] Email input
→ [@e2] Password input
→ [@e3] Login button

# 3. 使用引用填充表单
$B fill @e1 "test@example.com"
$B fill @e2 "password123"
$B click @e3

# 4. 验证成功
$B snapshot -D              # diff 显示点击后发生了什么变化
$B is visible ".dashboard"  # 断言仪表板已出现
$B screenshot /tmp/after-login.png

甚至碰到验证码也不怕：

Claude：我在登录页碰到验证码了。打开可见 Chrome 你解决一下，弄好告诉我。

> browse handoff "Stuck on CAPTCHA at login page"

你：done

Claude：> browse resume
[浏览器在交接后保留所有状态，resume 之后 AI 能获得你离开位置的新鲜快照]

说白了，这就是给 AI 一双真实的眼睛，让它能看到网页、交互测试、截图证据。以前 AI 说"我测过了"，你可能半信半疑；现在有了 /browse，你可以完全信任——因为它真的看了。

/cso：首席安全官安全审计

安全这东西，平时感觉不到，出事就是大事。这个 skill 扮演的是首席安全官的角色，给你做全面的安全审计。

为什么需要这个？

很多开发者（包括我自己）对安全都是"事后诸葛亮"——平时不注意，被黑了才后悔。但安全问题一旦发生，损失往往是巨大的：数据泄露、声誉受损、法律责任……

/cso 就是在你合并代码前，帮你把这些问题找出来。

审计内容：

• 注入漏洞：SQL 注入、NoSQL 注入、命令注入
• broken 认证：会话管理、密码存储、MFA
• 敏感数据暴露：PII、密钥、日志中的敏感信息
• XML 外部实体：XXE 攻击
• 破损访问控制：权限提升、水平越权、垂直越权
• 安全错误配置：默认密码、公开的调试信息、CORS 配置
• XSS：反射型、存储型、DOM 型
• 不安全反序列化：RCE 风险
• 已知漏洞组件：npm audit、依赖供应链
• 日志记录不足：审计日志、监控、告警

除此之外，它还会检查：

• CI/CD 管道安全：GitHub Actions、GitLab CI
• LLM/AI 安全：提示注入、prompt 泄露
• 技能供应链：扫描安装的 skill 是否有安全问题
• 密钥考古：检查 git 历史中是否有不小心提交的密钥

关键特点：

• 零噪音：17 个误报排除规则，8/10+ 置信度门槛——不会给你扔一堆没用的警告
• 每个发现都包含具体的利用场景：不是只说"这里有个 SQL 注入"，而是会说"怎么利用"、"影响范围有多大"
• 不是只扔给你一堆问题：而是会告诉你怎么修，甚至自动修复一些简单问题

两种模式：

• Daily（默认）：8/10 置信度门槛，零噪音——适合日常使用
• Comprehensive（--comprehensive）：2/10 置信度门槛，月度深度扫描——适合安全审计

说白了，这就是你的虚拟首席安全官，在你合并代码前帮你把安全关把好。安全这东西，还是预防为主，别等出事了才后悔。

/ship：一键发布 PR

代码写好了，测试通过了，接下来就是发布。这个 skill 扮演的是发布工程师的角色，帮你一键搞定。

为什么需要这个？

发布这事儿说起来简单，但实际上有一堆琐碎的步骤：同步主分支、解决冲突、运行测试、更新版本、写 changelog、提交、push、创建 PR……每一步都可能出错，而且烦得要死。

作为一个喜欢偷懒的人，我当然不想每次都手动做这些。/ship 就是把这堆琐事自动化，让你一个命令搞定。

自动完成：

1. 同步主分支：git fetch origin main && git merge origin/main
2. 运行测试：自动检测你的测试框架，运行正确的命令
3. 审计覆盖率：从你的 diff 构建代码路径映射，搜索对应测试，生成 ASCII 覆盖率图，缺口自动生成测试
4. 提交代码：bisectable chunks（可二分查找的提交块），每个提交一个独立功能
5. 推送到远程：git push -u origin feature-branch
6. 创建 PR：自动生成 PR 描述，包含 changelog、覆盖率变化、评审状态

测试引导： 如果你没有测试框架，它还会帮你 bootstrap 一个：

• 检测运行时（Node.js、Python、Ruby……）
• 找最佳框架（Vitest、pytest、RSpec……）
• 安装依赖
• 写 3-5 个真实测试
• 设置 GitHub Actions CI
• 创建 TESTING.md

评审关口： 创建 PR 前会检查评审就绪看板，如果缺工程评审会问，但不阻止你。每个分支保存决策，不会重复问。

举个例子，你刚写完代码，想发布：

你：/ship

/ship：
  Step 1: Pre-flight — on feature branch, 12 uncommitted changes included
  Step 2: Merge base branch — git fetch origin main && git merge origin/main
  Step 3: Run tests — bun test ✓ (42/42 pass)
  Step 3.4: Test Coverage Audit — Tests: 42 → 47 (+5 new)
  Step 3.5: Pre-Landing Review — No issues found
  Step 4: Version bump — v0.11.17.0 → v0.11.18.0
  Step 5: CHANGELOG — auto-generated from git log
  Step 5.5: TODOS.md — 2 items marked complete
  Step 6: Commit — bisectable chunks (5 commits)
  Step 7: Push — git push -u origin feature-branch
  Step 8: Create PR — <https://github.com/garrytan/gstack/pull/123>
  Step 8.5: Auto-invoke /document-release — docs synced

🎉 PR created: <https://github.com/garrytan/gstack/pull/123>

说白了，就是把"我写完了"变成"这就上线了"。以前发布可能需要 10 分钟，现在一个命令 30 秒搞定。作为一个喜欢偷懒的人，这当然深得我心。

/retro：每周工程回顾

一个好的团队会不断反思，这个 skill 就是帮你做这件事的。它会分析你的提交历史、工作模式、代码质量指标。

为什么需要这个？

不知道你有没有这种感觉：一周忙忙碌碌，感觉干了很多事，但周末回想起来，又好像啥都没干成。这时候你就需要数据——不要感觉，要事实。

/retro 就是帮你做这件事的：用数据说话，看看这周到底发生了什么。

分析内容：

• 每周提交统计：总提交数、代码行数、测试比例、PR 数量
• 人均贡献 breakdown：识别不同人的贡献，给出针对性的表扬和成长建议
• 发布 streak（连续发布天数）：看看你能连续多久保持发布节奏
• 测试健康趋势：总测试文件、本期新增测试、回归测试提交、趋势变化
• 成长机会建议：基于数据给出具体的改进建议

团队感知： 它可以识别谁运行的命令，对你自己的工作给出最深处理，然后逐个分解每个贡献者，给出具体的表扬和成长机会。

它会计算各种指标：

• 提交数、代码行数
• 测试比例
• PR 大小
• 修复率
• 从提交时间戳检测编码会话
• 找到热点文件
• 追踪发布连胜
• 识别本周最大贡献

举个例子：

周末你想回顾这一周：

你：/retro

/retro：Week of Mar 1: 47 commits (3 contributors), 3.2k LOC, 38% tests, 12 PRs, peak: 10pm | Streak: 47d

  ## Your Week
  32 commits, +2.4k LOC, 41% tests. Peak hours: 9-11pm.
  Biggest ship: cookie import system (browser decryption + picker UI).
  What you did well: shipped a complete feature with encryption, UI, and
   18 unit tests in one focused push...
  Where to level up: test ratio dipped to 12% on Wednesday — consider
   writing tests before refactoring next time.

  ## Team Breakdown

  ### Alice
  12 commits focused on app/services/. Every PR under 200 LOC — disciplined.
  Praise: Shipped the entire auth middleware rewrite in 3 focused sessions
  Opportunity: test ratio at 12% — worth investing before payment gets more complex.

  ### Bob
  3 commits — fixed the N+1 query on dashboard. Small but high-impact.
  Praise: That N+1 fix reduced dashboard load from 2s to 200ms
  Opportunity: only 1 active day this week — check if blocked on anything.

  ## Top 3 Team Wins
  1. Cookie import system shipped
  2. Test coverage improved from 32% to 38%
  3. No production incidents

  ## 3 Things to Improve
  1. Wednesday had 5 fix commits in a row — consider reviewing earlier
  2. Some PRs were over 500 LOC — try to split more
  3. E2E tests only ran once this week

  ## 3 Habits for Next Week
  1. Run /review before creating PRs
  2. Split PRs over 300 LOC
  3. Run E2E tests at least twice

甚至可以跨项目全局回顾：

你：/retro global

/retro：Global Retro: 5 projects, 138 commits, 250k LOC across 5 repos
  48 AI sessions | Streak: 52d 🔥

  🚀 Your Week: xindoo — Week of Mar 1
  ╔═══════════════════════════════════════════════════
  ║
  ║  138 commits across 5 projects
  ║  +24.2k LOC added · 2.1k LOC deleted · 22.1k net
  ║  48 AI coding sessions (CC: 35, Codex: 10, Gemini: 3)
  ║  52-day shipping streak 🔥
  ║
  ║  PROJECTS
  ║  ───────────────────────────────────────────────────────
  ║  gstack                47 commits    +3.2k LOC    solo
  ║  myapp                 52 commits    +12.8k LOC   team
  ║  other-project         39 commits    +8.2k LOC    solo
  ║
  ║  SHIP OF THE WEEK
  ║  Cookie import system — 2,457 lines across 18 files
  ║
  ║  TOP WORK
  ║  • Built /retro global — cross-project retrospective
  ║  • Shipped cookie import in gstack
  ║  • Refactored auth middleware in myapp
  ║
  ║  Powered by gstack · github.com/garrytan/gstack
  ╚═══════════════════════════════════════════════════

说白了，这就是你的虚拟工程经理，每周给你出一份"团队周报"。不要感觉，要数据——用数据说话，看看这周到底发生了什么，有哪些成长机会。结果还会保存 JSON 快照到 .context/retros/，下次运行能显示趋势。

/careful：危险操作警告

网上已经曝出不少 AI 误删文件的事件了。如果不对 AI 加以约束，确实很容易出问题。这个 skill 的作用是在你准备进行高风险操作前，先把你拦下来提醒一句。

会警告的操作：

• rm -rf
• DROP TABLE
• git push --force
• git reset --hard
• kubectl delete

你可以选择确认继续，也可以选择停下。说白了，这就是给你的"三思而后行"按钮。

/freeze：目录编辑锁定

调试的时候最烦什么？改着改着这个文件，不小心把那个文件也改了。这个 skill 就是帮你锁定编辑范围的。

功能：

• 只允许编辑指定目录
• 目录之外的编辑会被硬拦截
• 不是警告，是真的不让改

调试的时候，把编辑范围锁定在出问题的模块，就不用担心"误伤"其他代码了。

/guard：完整安全防护

这是 /careful + /freeze 的组合版，一次性开启所有安全防护。

同时开启：

• 危险操作警告
• 目录编辑锁定

说白了，就是"最高安全模式"——适合碰生产环境或者调试关键系统的时候用。

/unfreeze：解锁编辑

用完 /freeze 或 /guard 之后，用这个来解锁编辑限制，恢复可以编辑所有目录的状态。

与 superpowers 对比

可以看到，Gstack 与 Superpowers 在设计思路上是完全不同的，前者基于角色设计，而后者基于研发流程设计。

我列了张表格，对比下两者的核心差异：

共同点

虽然设计思路不同，但两者有一些核心的共同点：

1. 都反对"AI 拿到需求就开干"：都强调先想清楚，再动手
2. 都重视验证：没有证据，不能声称完成
3. 都用流程约束 AI：不让 AI 凭"聪明"乱来，而是用流程保证质量
4. 都适合复杂项目：项目越复杂，价值越明显
5. 都需要人工介入：不是完全自动化，而是人机协作

总结

阅读 Gstack 所有 Skill 的过程中，我也总结出几个有意思的结论：

1. Garry Tan 真的在实战中用这套东西：README 里晒出了他的 GitHub 贡献图——2026 年 1237 次贡献，最近 60 天写了 60 万+ 行代码。这不是"理论上好用"，是"真的能打"。
2. 这是 YC 方法论的 AI 化：YC 怎么辅导创业公司，Gstack 就怎么辅导你。从 /office-hours 的"挑战前提"，到 /plan-ceo-review 的"找 10 星产品"，这就是 YC 门诊的 AI 版。
3. 真实浏览器是杀手锏：很多 AI 工具的"测试"都是模拟的，但 Gstack 的 /browse 是真的 Chromium。这就从"AI 说它测过了"变成"我确信它真的测过了"。
4. 角色化设计降低认知负担：你不用想"现在该用什么流程"，只要想"现在我需要什么角色"——需要产品思维就用 /office-hours，需要 CEO 视角就用 /plan-ceo-review，需要 QA 就用 /qa。

Gstack 和 superpower 其实不是竞品，更多的时候是相互补齐，Gstack 适合偏向于宏观实现——从创意到产品，从 0 到 1；而 Superpowers 适合实际开发落地——从需求到代码，从 1 到 N。说直白点，一个是老板，一个是底层牛马 [doge]。

不过话说回来，这两个工具其实反映了一个共同的趋势：AI 编程不是"让 AI 替你写代码"，而是"让 AI 帮你组建一个团队"。以前你一个人要干产品、开发、测试、发布的活，现在这些角色都有 AI 帮你扮演，你只需要做最终决策。

这也是为什么我觉得 AI 不会取代程序员，但会重新定义程序员的工作方式。未来的程序员，可能更像是一个"团队管理者"，而不是一个"搬砖工"。