Garry Tan 的 gstack：一人抵二十人团队的 AI 工程工作流

Garry Tan 的 gstack：一人抵二十人团队的 AI 工程工作流

今天早上刷 GitHub Trending 看到 gstack 这个项目，第一反应是：又一个 AI 编程工具？但当我看到创始人是 Y Combinator 现任 CEO Garry Tan，而且 README 开头引用了 Karpathy 那句"自从去年 12 月以来我可能连一行代码都没敲过"时，我决定认真看看。

这个项目到底解决了什么问题

做后端这么多年，我见过太多"AI 辅助编程"工具了。大部分要么是简单的代码补全，要么是给个聊天框让你问问题。gstack 不一样——它不是帮你写代码，而是模拟一整个工程团队的工作流。

Garry Tan 在 README 里给了一个直观的数据：2026 年他的代码产出效率是 2013 年的 810 倍（按逻辑代码行数计算）。这不是说 AI 写的代码多，而是说一个人能完成的工作量发生了质变。核心问题在于：传统开发流程中，从产品构思到上线需要多个角色协作——产品经理定义需求、架构师设计方案、工程师实现、测试 QA、安全审查、发布管理。gstack 把这些角色全部 AI 化，变成 23 个专门的 slash 命令。

架构设计：为什么是 23 个工具而不是一个大模型

仔细看了 README 里的技能列表，发现一个很有意思的设计哲学：每个工具都有明确的边界和职责。这和现在很多"一个模型搞定一切"的思路截然不同。

## 产品阶段
/office-hours      # YC 风格的产品质询，6 个强制问题重构需求
/plan-ceo-review   # CEO 视角审视，4 种范围模式（扩展/收缩/保持/削减）
/plan-design-review # 设计师评审，每个维度 0-10 分评分

## 开发阶段  
/plan-eng-review   # 工程经理锁定架构，数据流图、状态机、边界情况
/review            # 高级工程师代码审查，自动修复明显问题
/cso               # 首席安全官，OWASP Top 10 + STRIDE 威胁建模

## 测试部署
/qa                # QA 负责人，真实浏览器测试，发现并修复 bug
/ship              # 发布工程师，同步分支、运行测试、提 PR
/land-and-deploy   # 合并 PR、等待 CI、验证生产环境

这种设计的好处在于：当你让一个通用模型"帮我做个功能"，它往往会跳过需求分析直接写代码。gstack 强制你按流程走——先 /office-hours 明确痛点，再 /plan-ceo-review 确认范围，然后才进入开发。这其实是在用工具链强制执行工程纪律。

技术栈分析：TypeScript + Claude Code 生态

从技术选型来看，gstack 基于几个关键组件：

1. Claude Code：核心执行引擎，所有技能都是通过 slash 命令触发 Claude Code 会话
2. TypeScript/Bun：工具链本身用 TS 编写，Bun 作为运行时（性能更好）
3. Playwright：浏览器自动化，用于 /qa、/browse 等需要真实 UI 测试的场景
4. 多 Agent 支持：除了 Claude Code，还支持 Cursor、OpenCode、Factory Droid 等 10 种 AI 编程助手

## 30 秒安装命令
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack \
  && cd ~/.claude/skills/gstack && ./setup

安装逻辑很简单：克隆仓库到 ~/.claude/skills/gstack，然后执行 setup 脚本。setup 会做几件事：

• 在 ~/.claude/skills/ 下为每个技能创建符号链接
• 修改 CLAUDE.md 添加 gstack 配置段
• 检测已安装的 AI 助手并自动配置对应路径

团队模式下还会在项目中添加 .claude/ 目录和 required 或 optional 标记，确保团队成员自动同步最新版本。

几个让我眼前一亮的功能

1. 设计 - 开发闭环：/design-shotgun → /design-html

这个工作流解决了 AI 生成的 UI 总是"看起来不错但不能用"的问题。/design-shotgun 会生成 4-6 个设计变体，在浏览器中并排展示，你可以实时反馈"留白多一点"、"标题加粗"，它会迭代生成。选定后 /design-html 用 Pretext 引擎生成真正响应式的 HTML/CSS——文字会重排、高度自适应、布局是动态的，而不是固定像素的 demo。

2. 真实浏览器测试：/qa

这是我觉得最有价值的功能。它不是模拟点击，而是启动真实的 Chromium 浏览器，打开你的 staging 环境，按照测试流程走一遍，发现 bug 后直接修复并生成回归测试。Garry 说这个功能让他能从 6 个并行 Sprint 提升到 12 个——因为 agent 真的有"眼睛"了。

## QA 完整流程
/qa https://staging.myapp.com
## 输出：打开浏览器 → 点击关键流程 → 发现 Race Condition → 提交修复 → 重新验证 → 生成回归测试

3. 跨模型审查：/codex

你可以让 Claude 做完 /review 后，再用 OpenAI 的 Codex CLI 跑 /codex 做独立审查。两个不同模型的审查结果会合并展示，重叠的找出来，各自独特的也标出来。这相当于请了两个不同背景的高级工程师给你做 Code Review。

4. 安全护栏：/careful + /freeze

说"be careful"会激活 /careful，在执行 rm -rf、DROP TABLE、force-push 等危险命令前强制确认。/freeze 则把编辑限制在单一目录内，调试时防止 AI"顺手修复"了不相关的代码。/guard 把两者合一。

适用场景和局限

适合的场景：

• 技术创始人/CTO 想亲自参与产品开发但时间有限
• 小团队（1-5 人）希望用 AI 放大产能
• 需要标准化工程流程的初创公司
• Claude Code 或类似工具的重度用户

局限性：

• 强依赖 Claude Code 生态，如果你用其他 IDE 集成可能体验打折
• 23 个技能需要学习成本，不是"开箱即用"的那种
• 需要真实浏览器测试的功能依赖 Playwright，Windows 用户需要额外配置 Node.js
• 对于超大型项目（数百人团队），这种"一人即团队"的模式可能不适用

我的看法

作为一名写 Java 后端的开发者，我一开始对这种"全栈 AI 工作流"是持怀疑态度的。但仔细看下来，gstack 最有价值的不是它有多少个技能，而是它把工程流程产品化了。传统公司里，一个功能从想法到上线需要多少会议、多少文档、多少轮 review？gstack 把这些流程压缩成一系列命令，每个命令背后是一套经过验证的方法论。

当然，它不是银弹。AI 生成的代码还是需要人做最终判断，安全审查也不能完全替代专业安全团队。但对于想快速验证想法的创业者、或者想用 AI 提升效率的小团队，这套工具确实提供了一个可参考的范式。

用 README 里的一句话结束："The point isn't who typed it, it's what shipped."（重点是谁敲的代码，而是交付了什么）——这可能就是 AI 时代工程师需要转变的思维。