Pandasolo / ai / builder
all posts
AI技术 · ZH

Garry Tan 的 gstack 技能框架深度分析

May 8, 2026·9 min read·by PandaTalk

Garry Tan 的 gstack 技能框架深度分析

一、gstack 是什么

gstack 是 Y Combinator 现任 CEO Garry Tan 开源的一套 Claude Code 技能系统。它将 AI 编程助手重新定义为一个虚拟工程团队——21 个 slash 命令，每个命令对应一个专业角色（CEO、工程经理、设计师、QA 负责人、Staff Engineer、技术写作……），覆盖从创意到上线的完整开发冲刺流程。

Garry 声称用这套系统每天能产出 10,000-20,000 行可用代码，同时运行 10-15 个并行 sprint。

二、技能体系特点

1. 完整的 Sprint 流水线，而非零散工具

技能按开发阶段严格编排：

Think → Plan → Build → Review → Test → Ship → Reflect
  │        │                 │        │       │       │
  │   ┌────┴────┐            │        │       │       │
  v   v    v    v            v        v       v       v
办公  CEO  工程  设计       代码     QA测试   发布   周回顾
时间  评审  评审  评审      评审     (3级)    工程   (趋势
                                            流程   追踪)

每个环节的输出是下一环节的输入：/office-hours 输出设计文档 → /plan-ceo-review 读取并挑战 → /plan-eng-review 锁定架构并写测试计划 → /qa 使用测试计划 → /ship 检查 Review Readiness Dashboard。

这不是"给 AI 一堆工具"，而是**"用 AI 模拟一个完整团队的协作流程"**。

2. 每个技能都是一个"专家人格"

技能 角色隐喻 行为特征
/office-hours YC 合伙人 用 6 个尖锐问题逼你面对需求真相
/plan-ceo-review CEO/创始人 梦想要大，找"10 星体验"，四种范围模式
/plan-eng-review 工程经理 锁死架构，画 ASCII 图，逼问边界案例
/review Staff Engineer 两轮审查，先找致命问题（SQL 注入、竞态条件、LLM 信任边界），再看风格
/investigate 老练的 Debugger 铁律：没找到根因就不许修，三击假设规则
/qa QA 负责人 真实浏览器测试，发现 bug 后自动修复+原子提交+回归测试
/design-review 会写代码的设计师 80 项视觉审计清单，CSS 改动自动放行
/retro 工程经理 按人拆分贡献，追踪 shipping streak，表扬+成长点

每个角色都有明确的"性格"和"红线"。比如 /investigate 会自动冻结编辑范围（调用 /freeze），防止调试时误改其他模块；/qa 有 WTF-likelihood 自我调节机制，防止修复失控。

3. "Fix-first" 而非 "Report-only"

传统代码审查和 QA 工具只输出报告。gstack 的哲学是：发现问题就直接修。

  • /review：发现明显问题自动修复，模糊问题才提问
  • /qa：每个 bug 修复都是一个原子 commit（fix(qa): BUG-NNN），附带回归测试
  • /design-review：视觉问题修复后自动截取 before/after 对比图

只有 /qa-only 是纯报告模式，作为例外存在。

4. "Boil the Lake" 完整性原则

这是整个框架最核心的哲学：

当 AI 让边际成本趋近于零时，永远推荐完整实现——100% 测试覆盖、所有边界案例、完整错误路径。"湖"（可实现的完整性）必须烧开；"海洋"（跨季度的迁移）标记为超出范围。

这直接体现在：

  • 每个技能都要求完整交付，不允许"先这样凑合"
  • 工时估算同时显示人工和 AI 辅助时间（如"人工 2 周 / AI 约 1 小时"），压缩比 3x-100x

5. 分层安全体系

/careful      → 破坏性命令告警（rm -rf, DROP TABLE, force-push）
/freeze       → 限制编辑范围到指定目录
/guard        → careful + freeze 联合，最高安全级别
/investigate  → 自动触发 freeze，锁定调试范围

这不是事后补救，而是设计时就嵌入流程的安全意识。

6. 多 AI 交叉验证

/codex 调用 OpenAI 的 Codex CLI 做独立审查，然后与 Claude 的 /review 结果交叉对比。三种模式：

  • review：通过/不通过门控
  • challenge：对抗模式，专门找你代码的漏洞
  • consult：开放对话，保持会话连续性

用两个不同的 AI 互相校验，降低单一模型的盲区风险。

7. 真实浏览器能力

gstack 不是在模拟浏览器，而是运行了一个持久化的无头 Chromium 守护进程：

  • 首次启动 ~3 秒，之后每个命令 ~100ms
  • 通过 CDP（Chrome DevTools Protocol）通信
  • 支持截图、元素交互、表单测试、对话框处理
  • Cookie 导入支持从真实浏览器（Chrome/Arc/Brave/Edge）导入

三、从框架设计看 Garry Tan 的思维模式

1. 系统思维：不解决单点问题，解决整条链路

大多数人用 AI 编程是"遇到问题问一下"。Garry 的做法是重新设计整个软件开发流程。他没有优化"写代码"这个环节，而是把从创意到回顾的完整 sprint 流程全部 AI 化。

这是典型的 YC 思维——不要做一个更好的工具，要重新定义工作方式。

2. 约束驱动创新：用角色和规则替代自由度

一般人给 AI 的指令是"帮我写个功能"。Garry 给 AI 极其详细的约束：

  • /investigate 有"铁律"和"三击规则"
  • /qa 有 WTF-likelihood 自我调节
  • /review 有两轮审查协议和范围漂移检测
  • 每个技能都有明确的"什么时候该用，什么时候不该用"

他理解一个关键洞察：AI 在高度结构化的约束下表现远好于开放式指令。 给 AI"自由"反而让它犯错，给它"角色+规则+红线"才能让它可靠工作。

3. 创始人的产品直觉：10 星体验思维

/plan-ceo-review 的四种模式暴露了他的产品哲学：

  • SCOPE EXPANSION：梦想要大，找 10 星体验
  • SELECTIVE EXPANSION：保持范围+精选扩展
  • HOLD SCOPE：锁定范围，极致严谨
  • SCOPE REDUCTION：剥到本质

这正是 Airbnb 式的"11 星体验"思维（先设想极致体验，再往回收）。他不是在写代码，是在用产品思维设计开发流程本身。

4. YC 式的质疑文化

/office-hours 的 6 个"逼问"直接来自 YC 合伙人面试创始人的方法论：

  1. 需求真相：有人在绝望地等你的东西吗？
  2. 现状替代：不用你的产品，他们现在怎么办？
  3. 极致具体：最窄的楔子是什么？
  4. 观察驱动：你观察到了什么别人没看到的？
  5. 未来适配：3-5 年后这还重要吗？

他把自己多年做风投、当合伙人积累的创业直觉编码成了 prompt。

5. 工程管理者的视角：可观测性和趋势追踪

/retro 不是简单的"本周做了什么"，而是：

  • 按人拆分贡献
  • 追踪 shipping streak（连续发布记录）
  • 测试健康度趋势
  • commit 时间分布
  • session 检测和专注度评分
  • PR 大小分析
  • 表扬+成长机会

保存 JSON 快照用于跨周趋势对比。

这是一个管理过工程团队的人才会想到的——不是看某一次的表现，而是看趋势。

6. 实用主义的安全观

安全不是一个独立的"安全审查"环节，而是分层嵌入到每个操作中：

  • 日常开发：/careful 自动告警
  • 调试场景：/investigate 自动冻结范围
  • 生产环境：/guard 全面防护
  • Code review：/review 主动检查 SQL 注入、LLM 信任边界

他没有把安全当成"合规清单"，而是当成工程实践的一部分。

7. 对 AI 能力边界的深刻理解

几个设计细节暴露他对 AI 局限性的清醒认知：

  • 多 AI 交叉验证（/codex）：不信任单一模型
  • WTF-likelihood 自我调节：防止 AI 进入"修复循环"
  • 三击假设规则：假设错了三次就停下来，不要蛮干
  • 原子 commit：每个修复独立提交，方便回滚
  • ELI16 模式：3+ 次交互后自动简化提问，因为 AI 反复问同样的问题会让用户烦躁

他不是 AI 的盲目信徒，而是一个知道 AI 会在哪里出错、并提前设计了护栏的人。

四、总结

gstack 表面上是一套 Claude Code 技能，本质上是 Garry Tan 把自己作为 YC CEO + 连续创业者 + 工程管理者的经验编码成了一个可执行的开发方法论。

核心思维模式：

维度 传统做法 Garry 的做法
AI 定位 代码助手 虚拟工程团队
使用方式 按需提问 全流程 sprint
质量策略 人工 review 多角色多 AI 交叉验证
安全策略 事后审计 分层嵌入流程
完整性 够用就行 "Boil the Lake"——AI 时代完整实现的边际成本趋近于零
指令风格 开放式 角色+规则+红线
衡量方式 写了多少代码 趋势追踪+回顾反思

这套框架最深刻的洞察是：AI 编程的瓶颈不是 AI 的能力，而是人类组织 AI 工作的能力。 gstack 本质上是一套"AI 工程管理方法论"，用结构化的流程和角色约束，把 AI 从一个"聪明但不可靠的助手"变成了一个"有纪律的虚拟团队"。

━━━ fin ━━━

If you read this far — thank you.
Come tell me what you thought on X.