gstack 深度解析：YC CEO 的 AI 团队工厂，23 个虚拟角色如何重构 Solo Developer 的生产力边界

开场判断

Garry Tan 有一句话在科技圈被反复引用：

“I don’t think I’ve typed like a line of code probably since December.” — Andrej Karpathy，2026 年 3 月

Karpathy 做到的，Garry Tan 想搞清楚「怎么做到的」。他的答案是 gstack：一套把 Claude Code 变成「虚拟工程团队」的智能体编排系统。23 个专职角色、8 个加固工具、3 种独立模式、并联执行 10-15 个 Sprint——一个人，跑出过去一个团队的速度。

这不是一套提示词集合，而是一套有体系、有边界、有安全设计的工作流操作系统。本文从四个维度系统拆解它的架构逻辑和工程哲学。

系统总览：三横两纵的模块架构

gstack 的架构不是平面的技能堆叠，而是一套「分层角色 + 并联执行」的控制系统。拆开来看，整个系统由三条横线和两条纵线构成：

三条横线（按执行层级）：

两条纵线（贯穿全局）：

• Browser 层：/open-gstack-browser + Sidebar Agent + $B CDP 逃生口，为整个系统提供真实浏览器能力
• 记忆层：GBrain（Supabase/PGLite）+ /learn + 跨机器状态同步，为智能体提供持久化记忆

这种「横切分层 + 纵穿基础设施」的架构，与 OpenClaw 的多 Session 并联模式有本质区别：gstack 所有角色都在同一个 Claude Code Session 内运行，通过 /review → /qa → /ship 的强流程约束保证每个阶段质量，而 OpenClaw 的各 Session 之间通过消息通道协调，更偏向分布式 actor 模型。

角色体系：23 个虚拟工程师是怎么分工的

gstack 的 23 个 Workflow Skill 不是随意命名的功能集合，而是一套模拟真实工程团队角色的职责体系。按职责可以分为五组：

第一组：规划层（Plan）

规划层的关键设计：Garry Tan 引用了 Andrej Karpathy 的四种 AI Coding 失败模式（错误假设、过度复杂、正交编辑、命令式优于声明式），为每个角色注入了对应防护。/office-hours 对应「错误假设」，/review 对应「正交编辑」和「过度复杂」，/ship 对应「命令式优于声明式」——这是一个被显式设计过的质量门禁体系。

第二组：设计与创意层（Design）

/design-shotgun → /design-html 流水线是 gstack 最独特的设计之一。大多数 AI Coding 工具在「设计稿」和「代码」之间存在巨大鸿沟：设计师用 Midjourney 生成图片，工程师手动还原。gstack 把这个过程自动化：用 GPT Image 生成多个 mockup 变体，人类在浏览器里直接看、直接选、直接迭代，选定后 /design-html 用 Pretext 框架生成真正可响应的生产级 HTML。

第三组：质量门禁层（Review & QA）

/investigate 的「铁律」设计值得注意：大多数 AI Coding Agent 在遇到 bug 时会立刻开始「猜着修」，这恰恰是 Karpathy 第四种失败模式（命令式优于声明式）的典型症状。/investigate 要求 Agent 先追踪数据流、验证假设，在 3 次修复失败后才停止——这是用流程约束对抗模型冲动性的显式设计。

第四组：发布与运维层（Ship & Deploy）

第五组：辅助与专项层

任务流转：一个功能从想法到上线如何穿过 23 个角色

架构要落地，必须看一个具体任务如何流过系统。以「在个人项目里增加一个支付功能」为例：

用户输入：「我想加 Stripe 支付」
         ↓
/office-hours（产品顾问）
  → 强制提问：支付失败如何退款？测试用哪个 Stripe 测试 key？
    输出一份澄清后的功能范围文档
         ↓
/autoplan（跨职能 PM）
  → 自动触发：/plan-ceo-review → /plan-design-review → /plan-eng-review
  → 各评审就位，只把「按钮颜色选择」留给人类拍板
         ↓
/spec（规范作者）
  → 五阶段生成规范：why → scope → technical（含强制代码阅读）
    → Codex quality gate（低于 7/10 封锁文件生成）
         ↓
Claude Code 实现代码
         ↓
/review（Staff Engineer）
  → 扫描「CI 能过但生产爆」的 bug 模式
  → 自动修复明显的，标记架构决策问题
         ↓
/qa（QA Lead）
  → 启动真实浏览器，打开本地服务
  → 跑支付流程，发现 Stripe webhooks 未配置
  → 原子提交修复 + 生成回归测试 + 验证
         ↓
/ship（Release Engineer）
  → 同步主干 → 检查测试覆盖率 → 推送并打开 PR
  → 自动触发 /document-release 文档同步
         ↓
/land-and-deploy（Release Engineer + SRE）
  → 合并 PR → 等 CI → 等部署 → 验证生产健康
         ↓
/canary（SRE）
  → 监控 5 分钟：控制台错误、性能指标、页面可用性
  → 无异常则任务结束，有回退则触发告警

这个流程里最有意思的设计是规划层和执行层之间的强制门禁：/autoplan 不会在评审未通过时强制放行，/spec 里的 Codex quality gate 会在代码质量低于 7/10 时拒绝生成文件。这是 gstack 用流程约束对抗 AI 模型「过度自信」的核心机制。

Browser 层：给 Agent 装上眼睛

gstack 的 Browser 层是整个系统里工程复杂度最高的部分，也是与其他 AI Coding 工具拉开差距的关键。

GStack Browser 的核心能力

/open-gstack-browser 启动的不是普通 headless Chrome，而是一个定制的 AI 控制浏览器，具备三个差异化能力：

1. Sidebar Agent（侧边栏智能体）

Chrome 侧边栏里跑一个独立的 Claude Sonnet 实例，负责快速动作（点击、导航、截图），而主 Session 的 Opus 处理分析和复杂决策。每次任务最多 5 分钟，超时自动停止，不会干扰主 Session。这解决了「我需要 Agent 快速操作浏览器但不想开一堆 Session」的根本矛盾。

2. Prompt 注入防御（Multi-Layer Defense）

当 Agent 通过浏览器访问外部网页时，恶意页面可能尝试通过 prompt injection 劫持侧边栏 Agent。gstack 实现了四层防御：

第一层：22MB 本地 ML 分类器
  → 扫描每个页面和工具输出，CPU 本地运行，无需 API 调用
  
第二层：Claude Haiku transcript 检查
  → 对完整对话 shape 投票，检测「注入型」对话模式
  
第三层：随机 Canary Token
  → 在 system prompt 里埋入随机标识符
  → 检测跨 text/tool args/URLs/file writes 的会话窃取尝试
  
第四层：Verdict Combiner（裁决合并器）
  → 必须两个分类器同时同意才阻止
  → 防止 Stack Overflow 这类教程页面被误杀
  
可选增强：721MB DeBERTa-v3 集成
  → 2-of-3 多数裁决模式
  → 通过环境变量 GSTACK_SECURITY_ENSEMBLE=deberta 开启

这个防御体系的工程价值在于：它是第一个在 AI Coding Agent 浏览器场景下同时考虑「误报率」和「漏报率」的解决方案。单一分类器对 Stack Overflow 风格页面的误报是已知问题，gstack 的 verdict combiner 机制直接针对这个工程矛盾设计。

3. $B handoff 机制

当 Agent 遇到 CAPTCHA、Auth Wall 或 MFA 时，$B handoff 在同一页面打开一个可见的 Chrome，用户手动解决后说「done」，Agent 用 $B resume 从断点继续。这个机制的本质是把「AI 无法完成的操作」自动降级到「人类介入 + AI 恢复」，而不是让整个工作流卡死。

$B domain-skill：浏览器记忆的复利机制

$B domain-skill save 允许 Agent 保存每个站点的特定知识（例如「LinkedIn 的 Apply 按钮在 iframe 里」），下次访问同一 hostname 时自动触发。存储路径与 /learn 的 per-project learnings 文件放在一起，跨项目可选择性提升。与 RAG 系统不同，这是程序性知识（procedure knowledge）而非事实性知识（factual knowledge），两者互补。

GBrain：智能体的长期记忆系统

gstack 包含一个独立模块 GBrain，为 AI Agent 提供持久化知识库，解决的是「Claude Code 每个 Session 都是空白」的，根本问题。

四种接入模式

信任 triad（per-repo 权限控制）

每个仓库对应三种信任级别，Agent 在该仓库工作时受对应约束：

read-write  → 可搜索 brain 并从此仓库写入新页面
read-only   → 可搜索但绝不写入（适合多客户顾问）
deny        → 完全禁用 gbrain

决策 sticky 跨 worktree 和分支，同一 remote 的所有克隆共享同一策略。

/sync-gbrain：代码变动与知识同步

每次 /sync-gbrain 执行时：

1. 注册 cwd 为 federated source
2. 执行 gbrain sync --strategy code（增量默认）
3. 在项目 CLAUDE.md 里写入 ## GBrain Search Guidance 块，引导 Agent 优先使用 gbrain search 而非 Grep
4. 如果 capability check 失败， Guidance 块自动移除——不会有「指向不存在工具」的过期提示

并联执行：Conductor 模式下的 10-15 倍提速

gstack 性能最震撼的数字来自 Garry Tan 本人的度量：

“On logical code change — not raw LOC, which AI inflates — my 2026 run rate is ~810× my 2013 pace (11,417 vs 14 logical lines/day).”

「逻辑代码变更量」而非「原始行数」是关键区分：gstack 用 /ship 的覆盖率审计确保每次提交的测试密度，使 810x 里面有相当部分是真实验证的质量，而非 AI 膨胀出来的噪音。

10-15 个 Sprint 并行的工程前提

gstack 的并行不是「开 15 个 Tab 同时问问题」，而是：

Conductor
  ├── Sprint 1: /office-hours 讨论新产品 idea
  ├── Sprint 2: /review 评审 PR #47
  ├── Sprint 3: 实现新功能（Claude Code 主 Session）
  ├── Sprint 4: /qa 在 staging 环境跑支付流程
  ├── Sprint 5-15: 其他分支的特性开发、bugfix、文档更新...

实现并行的工程前提：

1. 流程结构化：每个 Sprint 遵循「think → plan → build → review → test → ship」的固定流程，Agent 知道何时停止
2. 决策分级：只有「口味决策」（颜色、字体、定价）才提交给人类，日常执行完全自主
3. 状态隔离：每个 Sprint 在独立 worktree/workspace 运行，不互相干扰
4. 结果汇聚：/retro global 跨所有 Sprint 汇总数据，生成统一的团队健康报告

这套模式的前提是问题本身已经被 /office-hours 和 /autoplan 拆解清楚。没有结构化规划，10 个并行 Agent 就是 10 个并行混乱源。

横向对比：gstack 在 AI Coding 工具栈里处于什么位置

理解 gstack 的工程价值，需要把它放在当前 AI Coding 工具的坐标轴里：

gstack 最适合的场景：已经习惯 Claude Code、需要把「单点强化」扩展为「系统工程」、尤其在设计和质量门禁上有强需求的独立开发者或小型团队。

OpenClaw 更适合的场景：需要跨系统（不只是 Claude Code）统一编排多个 AI Agent 的复杂工作流，以及需要多模态（语音/视频/图像）综合处理的项目。

适用边界：什么时候应该用，什么时候不该用

应该用

• 独立开发者或 2-5 人团队，已经在用 Claude Code，希望在不改变 IDE 的前提下引入工程流程约束
• 需要设计到代码到测试到文档全链路自动化的项目
• 一个人同时跑多个 Sprint，需要状态管理和结果汇聚能力
• 对 Prompt 注入风险有强感知，需要浏览器安全隔离

不该用 / 暂时不该用

• 纯脚本或一次性数据处理任务，引入 gstack 的流程 overhead 不值得
• 对 Claude Code 还不熟悉的用户，先跑通基础用法再上 gstack
• 项目需要强结构化分工（真人的 PM、QA、设计师各司其职），gstack 模拟的是「单人多次角色切换」而非「多人实时协作」
• Windows 环境（需要 Git Bash 或 WSL，Node.js + Bun 双运行时依赖，官方支持仍在完善）

总结：Solo Developer 的工程边界正在被重新定义

gstack 真正在工程层面回答的问题，不在「AI 能不能写代码」，而在「一个人的工程输出如何系统化地达到团队质量门槛」。

810x 的生产力数字背后，有三条相互支撑的设计逻辑：

1. 角色分层：23 个专职角色各司其职，用流程替代意志力
2. 质量门禁：规划层和执行层之间的强制检查点，不让问题穿透到生产
3. 并行结构：问题拆解后并行执行，用 Sprint 管理而非用注意力管理

Garry Tan 在 README 里有句话：「The point isn’t who typed it, it’s what shipped.」这句话是 gstack 哲学的最佳注解：代码的来源不重要，重要的是它是否被验证、是否被测试、是否能交付。

对今天的独立开发者而言，gstack 提供的不止「更快的打字速度」，而是一套把工程纪律外化为工作流程的基础设施。当这套基础设施就位，一个人确实可以跑出过去一个团队的速度——不是因为 AI 替代了人，而是因为流程承接了那些本该由团队协作弥补的纪律性缺口。

相关链接：

• GitHub：https://github.com/garrytan/gstack
• GBrain：https://github.com/garrytan/gbrain