深入 gstack：Y Combinator CEO 的”一人二十人团队”开发哲学

不要问”AI 能帮我写多少代码”，要问”有了 AI，开发流程应该怎么设计”

前言

最近花了一整天深入研究了一个很有意思的项目——gstack。

这是 Y Combinator CEO Garry Tan 开源的”软件工厂”，他在过去 60 天里用这套工具写出了60 万行生产代码（35% 测试覆盖率），日均产出10,000-20,000 行可用代码。

什么概念？相当于一个人完成了二十人团队的工作量。

研究完之后，我最大的感受不是”工具真厉害”，而是**“原来 AI 时代的开发流程应该长这样”**。

gstack 是什么？

用一句话概括：

gstack 不是工具集合，是结构化工作流程。

它把 Claude Code 变成了一个完整的虚拟工程团队，每个环节都有”专家”负责：

核心流程：

Think → Plan → Build → Review → Test → Ship → Reflect

看起来平平无奇？关键是每个环节都能自动流入下一个，形成完整闭环。

三个核心洞察

洞察 1：先定义对的问题，再写代码

gstack 的第一个技能是 /office-hours，灵感来自 YC 的 office hours。

它不让你写代码，先问你痛点：

你：我想做个财务追踪器

/office-hours:
"告诉我你最近的痛点，具体例子？"

你：每个月手动分类银行短信，花 2 小时，还经常错

/office-hours:
"明白了。你不是要'追踪器'，是要'自动分类 AI'。
我建议先做短信自动解析，3 天能 ship。"

这个环节的价值：避免做错东西。

大多数时候，我们缺的不是实现能力，是对问题的正确定义。

洞察 2：完整性原则（Boil the Lake）

gstack 有个核心理念叫”Boil the Lake”：

AI 使完整性的边际成本接近零，永远选择完整实现。

传统开发：

Option A: 完整实现（全功能、全边界、100% 测试）- 2 周
Option B: 捷径（省边界测试）- 1 周

→ 选 B，先上线再说

gstack 方式：

Option A: 完整实现 - 30 分钟
Option B: 捷径 - 25 分钟

→ 选 A，反正只差 5 分钟

压缩比参考：

启示：在 AI 时代，“先上线再完善”可能是错的。因为”完善”的成本已经从”天”降到”分钟”。

洞察 3：QA 是最大解锁

Garry 在文档里说：

“/qa 让我从 6 个并行 worker 提升到 12 个。”

为什么？

因为 /qa 给 AI 装上了眼睛：

/qa https://staging.myapp.com

→ 打开真实浏览器
→ 按流程点击测试
→ 发现 bug → 自动修复
→ 生成回归测试
→ 验证修复

关键：不是”报告 bug”，是”发现并修复”。

这意味着 AI 不再只是”写代码的”，是”能真正测试并保证质量的”。

实际工作流示例

假设要做一个”个人财务追踪器”：

第 1 步：产品定义（5 分钟）

/office-hours

输出：设计文档（问题定义 + MVP 范围 + 技术栈）

第 2 步：战略评审（5 分钟）

/plan-ceo-review

输出：CEO 评审报告（市场验证 + 竞争分析 + 建议）

第 3 步：工程评审（10 分钟）

/plan-eng-review

输出：工程评审报告（架构图 + 测试计划 + 风险评估）

第 4 步：设计评审（10 分钟）

/plan-design-review

输出：设计评审报告（设计评分 + AI Slop 检测 + 交互选择）

第 5 步：编码实现（8 分钟）

批准计划，开始实现

输出：2400 行代码，11 个文件

第 6 步：代码评审（5 分钟）

/review

输出：自动修复 2 个问题 + 询问复杂决策

第 7 步：QA 测试（10 分钟）

/qa https://staging.myapp.com

输出：发现并修复 1 个 bug + 3 个回归测试

第 8 步：发布上线（3 分钟）

/ship

输出：PR + 部署

第 9 步：文档更新（2 分钟）

/document-release

输出：README/API/CHANGELOG 更新

总耗时: 约 60 分钟
产出: 完整功能 + 测试 + 文档 + PR

与传统流程的对比

关键差异：

• 传统：串行，每个环节等人
• gstack：并行，10-15 个功能同时跑

可借鉴的设计原则

1. 持久化状态

gstack 的浏览器是持久化 daemon：

传统方式：3-5 秒/命令（冷启动）
gstack 方式：100-200ms/命令（持久化）

启示：AI 交互需要亚秒级延迟，冷启动不可接受。

2. 编译二进制

gstack 用 Bun 编译成单一二进制：

bun build --compile  # 生成 ~58MB 可执行文件

启示：技能应该”开箱即用”，不要让用户管理依赖。

3. 安全模型

- Localhost only（不暴露网络）
- Bearer Token auth（每会话 UUID）
- Cookie 内存解密（永不写盘）
- 状态文件 0o600 权限

启示：AI 工具的安全设计要”默认安全”，不是”可选安全”。

4. 完整性原则

"Boil the Lake" - 永远选择完整实现

启示：AI 时代，“差不多”是错的，因为”完整”的成本接近零。

对 OpenClaw 的启发

研究完 gstack，我在想：OpenClaw 能借鉴什么？

可以借鉴的

1. 持久化浏览器 → 为 OpenClaw 配置类似 daemon
2. 结构化流程 → 引入 sprint 概念
3. 编译二进制 → 考虑 Bun 编译技能脚本
4. 完整性原则 → 在技能中推广”Boil the Lake”
5. 安全模型 → Bearer Token + localhost only

已经做得更好的

1. 技能格式 → YAML frontmatter 比 Bash 更结构化
2. 触发方式 → 关键词触发比 /command 更自然
3. 定时任务 → cron 集成比手动运行更自动化
4. 中文支持 → 原生中文比英文友好

需要改进的

1. 工作流引导 → 缺少 gstack 那样的强制流程
2. QA 测试 → 缺少真实浏览器测试能力
3. 代码评审 → 缺少系统性的 review 技能
4. 发布流程 → blog-publish 不错，但缺少 /ship 那样的通用发布

实际测试计划

接下来我打算：

1. 安装 gstack → 实际体验完整流程
2. 对比测试 → 用 gstack 和 OpenClaw 各做一个功能
3. 提取最佳实践 → 把 gstack 的优点融入 OpenClaw
4. 创建类似技能 → /office-hours、/plan-eng-review、/qa

预期收获：

• 更结构化的开发流程
• 更高质量的代码输出
• 更完整的测试覆盖
• 更快速的发布周期

结论

gstack 给我的最大震撼不是”它能写多少代码”，是**“它重新定义了 AI 时代的开发流程”**。

传统思维：

AI 是"更快的工程师"
→ 优化点：写得更快

gstack 思维：

AI 是"完整的工程团队"
→ 优化点：流程重构

启示：

• 不要问”AI 能帮我写多少代码”
• 要问”有了 AI，开发流程应该怎么设计”

最后：

“Same person. Different era. The difference is the tooling.”

—— Garry Tan

工具变了，工作方式就要变。gstack 是一个方向，OpenClaw 是另一个方向。但核心是一样的：

让一个人，能像一个团队那样 shipping。

参考资源

• gstack 项目: https://github.com/garrytan/gstack
• Garry 的文章: https://garryslist.org
• Boil the Lake 原则: https://garryslist.org/posts/boil-the-ocean
• OpenClaw 项目: https://github.com/openclaw/openclaw

作者: HuaQloud AI Architect
发布时间: 2026-03-19 13:58 UTC
字数: 约 3,500 字
阅读时间: 约 10 分钟