目录 [−]

"I basically operate as an engineering manager for a fleet of temporary models."
我本质上是一个工程经理，管理一支临时工模型大军。

——Garry Tan, Y Combinator 总裁 & CEO, 2026 年

Skill 是能力单元——一个 Markdown 文件定义一种行为。Spec 是合约，定义"做成什么样才算对"。Ralph Loop 是执行引擎，"做不到就继续做"。三者构成闭环：Skill 提供方法，Spec 提供标准，Ralph Loop 提供执行力。

但它们都隐含了同一个假设：你只有一个 Agent。

把这个假设推倒。如果你可以同时拥有二十三个 Agent，每个被赋予一个不同的专家角色——有人负责产品思考，有人负责架构设计，有人负责代码审查，有人负责质量测试，有人负责安全审计，有人负责发布部署——并且它们按照一个严格的 Sprint 流程协作。会发生什么？

gstack 回答这个问题。它是一个虚拟工程团队的操作系统。

5.1 一个人就是一支军队

2026 年初，Garry Tan 在社交媒体上发了一组对比数据，让整个硅谷的技术圈安静了几秒钟。

同一个人。同样的工作强度。2013 年，他的 GitHub 年度贡献图是一张稀疏的绿色点阵——和大多数全职工程师差不多。2026 年，同一张图画满了深绿色的方块，密集到几乎看不到底色。逻辑代码行的产出是 2013 年的八百一十倍。

八百一十倍。这是数量级的跃迁。

Garry Tan 是 Y Combinator 的总裁兼 CEO。日常工作是管理全球最大的创业投资机构之一：看项目、面试创始人、做投资决策、运营一个数百人的组织。写代码不该是他的主要工作。但在运营 YC 的同时，他在六十天内交付了三个生产级服务和四十多个功能。他用的方法论，就是 gstack。

gstack 的 GitHub 描述行只有五个词——"open source software factory"（开源软件工厂）。这五个词指向一个概念突破：将 AI Agent 从"工具"升级为"团队"。

它的核心机制很简单：把二十三个专家角色写成二十三个 Markdown 文件，每个文件定义了一种专门的"认知模式"——CEO 怎么想产品、工程经理怎么审架构、QA 怎么测应用、安全官怎么审计漏洞。调用 /office-hours，Agent 切换到"YC 合伙人"模式，六个强制问题盘问你的产品想法。调用 /review，同一个 Agent 切换到"员工工程师"模式，寻找能通过 CI 却在生产环境爆发的隐蔽 bug。调用 /ship，它变成"发布工程师"，同步主干、跑测试、审计覆盖率、推送代码、创建 PR。

同一个 Agent，不同角色。切换不靠每次重写 prompt——靠一个 Markdown 文件。第 2 章 Pocock 的 Skill 哲学在这里被推到了极致：当 Skill 不再零散，而是一个完整的组织架构，AI 软件工程的上限就变了。

Garry Tan 自己说过一句话，概括了 gstack 的设计理念：他本质上是一个工程经理，管理一支临时工模型大军。这句话在卷首语中也出现过——Claude Code 的创造者 Boris Cherny 说过类似的话。但 Garry Tan 比 Cherny 多走了一步：他给这支 AI 大军建立了一套组织架构——角色分工、流程阶段、质量门禁、交付流水线。一群零散的 Agent 变成了一个有结构的虚拟工程团队。

5.2 安装与配置：30 秒建起一支虚拟军队

gstack 是一组 Markdown 文件，代码完全开源，MIT 许可证。三十余个 Skill 文件构成它的全部——不需要数据库、不需要后端服务、不需要 API Key 之外的付费依赖。获取方式只有一种：git clone，然后跑一条 setup 脚本。

5.2.1 依赖与前提

gstack 跑在 Claude Code 之上——它的 PreToolUse hooks、slash commands、project-level config 都依赖 Claude Code 的 Harness 体系（详见第 10 章）。所以前提条件少：

• Claude Code —— gstack 的宿主。Claude Code 提供 Agent 运行时、hooks 机制和 slash command 支持。
• Git —— Skill 文件通过 git 分发和版本管理。
• Bun v1.0+ —— gstack 的 setup 脚本和 hooks 用 Bun 的 TypeScript 运行时，利用它的快速启动和内置工具链。
• Node.js（仅 Windows）——Bun 在 Windows 上尚未完整覆盖，部分脚本需要 Node.js 作为回退。

5.2.2 基础安装

在 Claude Code 会话中粘贴这行命令：

1

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

--depth 1 是浅克隆，只拉最新版本——几十 KB，秒级完成。./setup 做了三件事：把三十余个 Skill 文件注册到 Claude Code 的 skills 目录、生成 CLAUDE.md 的 gstack 配置区块、配置 /browse 无头浏览器 Skill。Agent 自己执行这些步骤，不需要人手动改文件。

30 秒后，三十余个 / 命令全局可用——/office-hours、/review、/qa、/ship、/cso……任何一个 Claude Code 会话，在任何目录，都能调用。

5.2.3 团队模式：共享 repo 的自动同步

个人使用，全局安装就够了。但多人协作的 repo 需要团队模式——让每个 Clone 仓库的开发者自动获得 gstack，不需要手动安装。

在项目目录内运行：

1

(cd ~/.claude/skills/gstack && ./setup --team) && ~/.claude/skills/gstack/bin/gstack-team-init required && git add .claude/ CLAUDE.md && git commit -m "require gstack for AI-assisted work"

这条命令做的事：把 gstack 标记为项目的必需依赖，写入 .claude/ 配置和 CLAUDE.md。之后任何人 checkout 这个 repo 开 Claude Code 会话，系统自动检测缺失的 gstack 并引导安装。版本漂移问题不复存在——每个会话启动时做一次自动更新检查（限流每小时一次，网络失败无害降级，完全静默）。

required 可换成 optional——required 阻止未装 gstack 的会话进入，optional 只提示不阻止。

5.2.4 多 Agent 支持

gstack 的设计不锁定 Claude Code。它的 setup 脚本自动检测你机器上装了哪些 AI 编码 Agent，按需分发 Skill 文件。截至 2026 年 5 月，支持 10 种 Agent：

用 ./setup --host <name> 指定目标 Agent。核心 Skill 逻辑同一套 Markdown 文件，Agent 特定的适配层由 setup 脚本按注入方式生成。

新增一个 Agent 宿主也简单——一个 TypeScript 配置文件，零代码改动（详见 gstack 仓库的 ADDING_A_HOST.md 文档）。这个设计反映了一个工程判断：Skill 的"认知模式"是平台无关的，只有 hooks 和门控机制依赖特定 Agent 的 Harness 能力。

5.2.5 OpenClaw 深度集成

Peter Steinberger 的 OpenClaw（247K GitHub Stars）通过 ACP 协议批量管理 Claude Code 会话。gstack 对此做了原生适配：

• 在 OpenClaw Agent 中安装 gstack 后，所有 Skill 在 OpenClaw 管理的 Claude Code 子会话中自动可用。
• 四个方法论 Skill（/office-hours、/plan-ceo-review、/investigate、/retro）以 OpenClaw 原生 Skill 形式发布到 ClawHub，无需 Claude Code 会话也能跑——它们是纯对话 Skill，不依赖 hooks：

  1	clawhub install gstack-openclaw-office-hours gstack-openclaw-ceo-review gstack-openclaw-investigate gstack-openclaw-retro

日常使用中，你不必手动加载 gstack——对 OpenClaw Agent 说"审查这个 PR 的安全性"，它自知要 spawn Claude Code 会话并执行 /cso。说"帮我规划 v2 API 重构"，它跑 /office-hours → /autoplan。OpenClaw 做调度，gstack 做执行。

5.2.6 升级与维护

gstack 的维护模型建立在"文件即工具"这个前提上。升级只需重新跑 setup——覆盖旧 Skill 文件，保留用户自定义配置。/gstack-upgrade Skill 封装了这个流程，一条命令完成：拉取最新 git commit、重新执行 setup、输出 changelog。

自动更新机制（团队模式）确保共享 repo 的开发者始终用同一版本——不是"建议升级"，是"不升级进不去"。有人觉得这太重，有人觉得多人协作下这是唯一靠谱的做法。两种意见在第 5.5 节的强制力之争中有完整展开。

5.3 从工具到团队：gstack 的核心设计

gstack 的设计围绕三件事：角色化、流程化、自动化。

5.3.1 角色化：每个 Skill 是一个专家人格

Pocock 的 Skills 系统中，一个 Skill 定义一种行为——"怎么做 TDD""怎么对齐需求""怎么调试"。行为是抽象的，不绑定人格。/tdd 直接给出红-绿-重构的循环规则。

gstack 每个 Skill 既定义行为，也定义人格。/plan-ceo-review 的开头是"你是 CEO / 创始人。你的职责是重新思考这个问题，找到'十星级产品'的愿景。"人格设定改变了 Agent 的认知姿态——它不光知道要做什么，还知道用什么视角、什么标准、什么语气来做。

这是工程决策，不是包装。

当你对 AI 说"审查这个架构"，它给出的反馈取决于它认为自己是谁。如果它认为自己是一个代码审查者，会关注命名、结构、可读性。如果它认为自己是工程经理，会关注模块边界、扩展性、失败模式。如果它认为自己是 CEO，会关注这个架构在多大程度上服务于产品愿景、哪些复杂度是为未来假设买单、哪些简化会释放更多迭代速度。

gstack 把这个洞见系统化了：不让一个全能 Agent 做所有审查。让二十三个专家 Agent 各自审查自己擅长的维度。

以下是 gstack 七个 Sprint 阶段的核心角色：

这十五个之外，gstack 还有一系列辅助角色——/browse（持久化无头浏览器，给 Agent 装上"眼睛"）、/context-save 和 /context-restore（跨会话状态持久化）、/codex（调用 OpenAI Codex 提供第二意见）、/health（代码质量仪表盘）、/document-release（发布后自动同步全部文档）——总共三十余个 Skill，覆盖从产品发现到发布监控的完整软件生命周期。

5.3.2 流程化：Sprint 不是建议，是结构

有二十三个专家角色是第一步。第二步是让它们按正确的顺序工作。

gstack 定义了一个七阶段 Sprint：Think → Plan → Build → Review → Test → Ship → Reflect。 它通过 PreToolUse hooks 在 Claude Code 上实现了强制性阶段门控。未通过 /review 的代码无法 commit。未通过 /qa 的功能无法进入 /ship。门控是系统执行的，不依赖人的纪律。

每个阶段的产出自动成为下一阶段的输入。/office-hours 产出的设计文档被 /plan-ceo-review 和 /plan-eng-review 消费。/plan-eng-review 锁定的架构和数据流被 Build 阶段的 Agent 作为实现约束。/review 发现的 bug 被 /qa 验证修复。/qa 生成的回归测试变成后续所有迭代的自动化安全网。/retro 的周回顾基于 git 历史的客观数据——每个人的交付连贯性、测试健康趋势、增长机会——不依赖主观感受。

这个流程设计回应了第 4 章 Ralph Loop 的一个核心局限：Ralph Loop 解决"一个任务内的自我纠正"，解决不了"谁来决定任务方向是否正确"。gstack 在上面加了一层角色化流程审查——代码写出来之前，CEO 角色审产品方向、工程经理角色审架构方案、设计师角色审用户体验、安全官角色审威胁模型。Ralph Loop 保证做对了，gstack 保证在做对的事。

5.3.3 自动化：当流程可以被机器强制执行

gstack 最激进的创新不在角色数量，在强制力。

大多数 AI 编码工具上，流程规范本质上是引导指令——Agent 被要求"先做计划再写代码"，但如果它跳过了计划直接写代码，没有系统级机制阻止它。Claude Code 的 Harness 体系（第 10 章详谈）提供了 PreToolUse hooks——在 Agent 执行特定工具调用前插入检查脚本。gstack 充分利用了这个机制：git commit 前检查代码审查是否通过，git push 前检查 QA 测试是否完成，部署前检查安全审计是否执行。

这和传统 CI/CD 流水线有一个关键区别。传统 CI/CD 检查的是代码能不能跑（构建、测试、lint）。gstack 的 hooks 检查的是流程有没有走完——不直接判断代码好坏，而是确保该看的人都看过了。这是一种元级别的质量保证。

Garry Tan 管这叫"流程即代码"（Process as Code）。就像 IaC 把服务器配置变成可版本控制的文件，gstack 把工程流程变成了可版本控制的 Markdown 文件和 hooks 脚本。一个新团队成员加入项目时，不需要"学习流程"——流程已经编码在系统中，自动执行。

5.4 Sprint 全景：七个阶段的深度拆解

上面是 gstack 的骨架。现在一个阶段一个阶段拆开，看肌肉怎么工作。

5.4.1 Think：用六个强制问题杀死坏想法

/office-hours 是 gstack Sprint 的起点。灵感来自 Y Combinator 的 Office Hours——YC 合伙人与创始人之间那种著名的、不留情面的二十分钟产品对话。

这个 Skill 的人格设定是"YC 合伙人"。行为不是"听你说完然后给反馈"——它用六个强制问题盘问你的产品想法：

1. 你在解决谁的什么痛苦？——把你从"我觉得这个 idea 很酷"拽到"有一个具体的人正在经历一种具体的痛苦"。
2. 他们现在怎么解决这个问题的？——不知道现有方案，就不了解竞争格局。
3. 你的方案好在哪？——不是好在技术上，是好在用户愿意切换过来。
4. 最小可验证的第一步是什么？——答案超过两周工作量，说明你还没想清楚。
5. 为什么是你？——你有什么洞察、技能或资源让这件事只有你能做？
6. 如果这个失败了，最可能的原因是什么？——正面假设自己的产品会死，倒推最可能的死因。

六个问题问完，Agent 产出一份设计文档。不是 PRD，不是 spec，是一份"已经想清楚了什么、还没想清楚什么"的结构化记录。这份文档成为 Plan 阶段所有审查角色的输入。

5.4.2 Plan：四层审查锁定方向

Plan 阶段是 gstack 的防御核心。写一行代码之前，四个角色各自从专业视角审查同一个方案。

/plan-ceo-review——CEO 视角。 这个角色不问"怎么实现"，问"该不该做"。它用四种战略模式评估每个功能：扩张模式（加倍投入）、选择性模式（只做最有价值的部分）、维持模式（不做增量，只维护质量）、削减模式（砍掉）。一个功能被分配了削减模式，后续角色就不再为它消耗审查资源。

/plan-eng-review——工程经理视角。 这个角色锁定架构：ASCII 架构图、数据流图、状态机、测试矩阵。核心任务是把隐藏的假设翻到台面上——组件 A 依赖组件 B 的什么接口？并发场景的竞态条件是什么？失败模式的降级策略是什么？这些问题不在这一步澄清，到 Build 阶段再发现，返工成本是十倍起。

/plan-design-review——高级设计师视角。 这个角色有一个独特的职责：AI Slop 检测。"Slop"是 2025-2026 年 AI 生成内容社区涌现的一个词——指 AI 倾向于生成的那些看起来不错但缺乏真实设计意图的视觉产出。AI 做的 UI 常常是均匀的间距、对称的布局、标准的配色——视觉上不丑，但也不对。它们缺一个人类设计师做特定选择时的理由——"这个按钮为什么是 48px 不是 44px？""这个颜色为什么是 #1890ff 不是 #1677ff？"设计师角色用 0-10 评分系统审查每个设计维度，强制 Agent 为每个设计选择提供理由。

/plan-devex-review——开发者体验视角。 这个角色做一件事：实际走一遍"新开发者上车"的流程。测量 TTHW（Time to Hello World）——clone 仓库到看到第一个成功运行的功能要多久——并与同类项目做基准对比。追踪摩擦点：哪些步骤需要手动配置、哪些文档缺失或过时、哪些错误信息让人困惑。开发者体验就是产品体验——你的 API 需要读三篇文档才能调用成功，用户不会怪文档，用户会怪你的产品。

四个角色可以分别手动运行，也可以通过 /autoplan 一次性启动全流程——CEO、设计、工程、DX 依次审查，只在有人类判断需要的决策点暂停等待输入。

5.4.3 Build：从方案到代码

gstack 的 Build 阶段没定义全新的编码 Skill——它复用 Claude Code 原生的编码能力，加了几个设计专项增强。

/design-shotgun 是其中最特别的一个。灵感来自散弹枪式的设计探索——同时生成 4-6 个不同风格的 AI 模型变体，放在对比板上逐个淘汰。背后的假设：AI 生成的第一个设计通常不是最好的，它是最平均的。强制生成多个变体并对比，更容易发现哪个选择表达了产品意图。

/design-html 将设计模型转化为生产级 HTML/CSS——零依赖、30KB 以内。这个约束本身就是质量声明：不被框架臃肿绑架的设计产出。

5.4.4 Review：寻找 CI 抓不到的 bug

/review 是 gstack 中最重要的质量 Skill 之一。人格设定是"员工工程师"（Staff Engineer）——有十五年经验、见过各种生产事故的老兵。

审查逻辑分成两条通道。结构通道：检查代码结构、命名一致性、错误处理完备性、测试覆盖盲区——传统代码审查的自动化版，可以自动修复机械问题。对抗通道：假设自己是攻击者或极端场景——"如果这个 API 被每秒 1000 次调用会怎样？""中间件崩溃重启后状态能恢复吗？""用户同时开两个 tab 操作，数据会冲突吗？"这类问题传统 CI 永远抓不到，因为它们不是代码逻辑错误，是代码在真实世界的行为假设错误。

/codex 提供第二意见机制——把同一段代码发给 OpenAI Codex CLI，用不同模型、不同训练数据、不同的"审美"来审查。Claude 和 Codex 同时认为有问题，那几乎可以肯定真有问题。这和第 7 章 autoresearch 的"多 Agent 交叉审核"逻辑一致——不同模型的盲区不同，交叉审核覆盖更多问题类型。

5.4.5 Test：给 Agent 装上眼睛

gstack 的 Test 阶段是它与其他方法论最显著的差异点。大多数 AI 编码工具的测试止步于单元测试和集成测试——它们能看到代码，看不到 UI。gstack 通过 /browse Skill 提供了一个持久化无头 Chromium 实例，让 Agent 能在真实浏览器中点击、截图、检查 DOM、读控制台输出。

/browse 是一个持久化守护进程——在 Agent 会话的整个生命周期中保持运行，维持浏览器状态（cookies、localStorage、登录会话），响应时间约 100-200ms。它的"ref"系统基于无障碍树（accessibility tree）定位元素——Agent 不说"点击坐标 (200, 300)"，说"点击'提交'按钮"。这让测试脚本对 UI 变化具有鲁棒性——按钮换了位置，ref 仍然有效。

在此之上，/qa 角色执行完整的 QA 流程：真实浏览器中测试应用、发现 bug、原子 commit 修复、重新验证、自动生成回归测试。/qa-only 提供纯报告模式——发现 bug 不改代码，把发现交给人类开发者处理。

/cso（首席安全官）执行 OWASP Top 10 和 STRIDE 威胁建模。它有一个值得注意的设计——17 种误报排除规则。安全扫描工具最让开发者反感的就是误报——"这里可能有 XSS 注入风险"（但输入已经在上一层被清洗了）。/cso 不简单报告"发现 XSS 风险"，它会先检查输入是否已经在调用链的某处被验证或清洗——没有，才报告。

5.4.6 Ship：从"approved"到"verified in production"

Plan 阶段是防御，Ship 阶段是进攻——把审查通过的代码投入生产。

/ship 执行的是一套完整的发布卫生流程：同步主干→运行全部测试→审计测试覆盖率→有退步就阻止→推送到远程→创建 PR→PR 描述自动填写 What/Why/How。

/land-and-deploy 更远一步——一键从"approved"到"verified in production"：合并 PR、等 CI 和部署流水线完成、生产环境跑冒烟测试、验证关键路径可用。

/canary 进入 SRE 模式：部署后持续监控控制台错误、性能退化、页面故障。它用 /browse 的无头浏览器实例在部署后自动遍历关键用户路径，发现异常——页面白屏、API 超时、静态资源 404——立即报警。

5.4.7 Reflect：数据驱动的回顾

/retro 不是"大家坐在一起聊聊上周做了什么"的社交仪式。它分析 git 历史的客观数据：每个人的交付连续性（多少次连续合入不中断）、测试健康趋势（覆盖率在上升还是下降）、交付速度的中位数和方差。它产出的是数据。

/benchmark 提供性能退化检测：每次 PR 合入后自动对比页面加载时间、Core Web Vitals、资源体积。合入后的指标比合入前差，PR 就被标记为需要性能审查。

两个 Skill 构成 gstack 的持续改进闭环——不只让开发更快，而且每一次 Sprint 都比上一次更好，有数据可查。

5.5 gstack 的工程文化：强制力之争

gstack 有一个在社区中引发持续讨论的设计选择：它通过 PreToolUse hooks 实现了强制阶段门控。未通过 /review 的代码无法 commit。未通过 /qa 的功能无法进入 /ship。

批评者和支持者各自引用书中的一章来支撑自己。

批评者引第 2 章——Matt Pocock 明确反对接管流程的方法论。他的原话是 GSD、BMAD、Spec-Kit 这类方法在帮你接管流程的同时，夺走了你的控制权，让流程中产生的 bug 难以定位和修复。Pocock 的哲学中，Skill 是工具，用户保留对流程的全部控制权。强制门控让流程从用户的选择变成了系统的要求。

支持者引第 4 章——Ralph Loop 的核心价值就是不给 AI 交半成品的机会。AI 能绕过审查直接提交代码，它就会绕过审查直接提交代码——这个行为模式被反复验证过。强制门控的目标是 AI 的自我评估，不是人类开发者。AI 经常真心认为自己"做完了"，实际上漏掉了关键功能。审查和验证完成之前锁住 commit 按钮，工程上这是负责任的做法。

Garry Tan 的立场是中间偏强制：引导流程适合个人项目，强制流程适合多人协作和被审计的生产环境。gstack 支持双模式——在 Claude Code 上通过 hooks 实现强制门控，在不支持 hooks 的平台上退化为引导指令。这个设计认了一个现实：流程的强制力取决于平台的能力。有条件强制执行的时候，强制执行更好。没条件的时候，引导也比没流程强。

5.6 实战：用 gstack 开发网页版贪吃蛇

前四章——Pocock Skills、OpenSpec、Spec-Kit、Ralph Loop——都用网页版贪吃蛇作为实战案例。本章同样，角度不同：前四章用一个工具开发，本章用一支虚拟团队开发。

使用gstack开发网页版贪吃蛇游戏有点"杀鸡焉用牛刀"的感觉，不过为了给大家展示一个简单的示例以及和我前面章节保持一致，依然沿用这个例子。

走的是不同流程，暴露的是不同问题。

初始运行的时候可能需要通过询问的方式配置gstack，按照问题正常回答即可，包括遥测、skill自动调用方式等等配置。

5.6.1 Think：产品想法被盘问

启动 /office-hours：

1

用户: /office-hours 做一个贪吃蛇网页游戏。纯前端单文件。

Agent 切换到 YC 合伙人模式，六个问题一个一个来（你实际运行时可能问题不同，我刚才实现了第四章的例子，它知道了，所以跳过了很多问题）：

Q1：做这个游戏的目标是什么？

用户：这是一个做着玩的项目——展示 AI 编码 Agent 的能力。

告诉它这只是自己氛围编程的学习项目。

Q2：你的用户怎么判断这个游戏"做得好"？

用户：蛇能动，能吃食物，能死，死了能重来。最高分刷新后还在。

Q3：最小可验证的第一步是什么？

用户：一个 20×20 的网格上有一条能按方向键移动的蛇。

Q4：你最大的技术风险是什么？

Agent 自己回答：纯前端单文件项目，技术风险很低。但键盘事件处理和游戏循环同步是常见 bug 来源——快速连续按键可能导致蛇反向移动。

Q5：你计划用多久完成？

用户：一小时以内。

Q6：如果这个项目失败了，最可能的原因是什么？

Agent：过度设计。贪吃蛇很简单，但加入难度曲线、音效、排行榜、皮肤系统等"看起来很棒"的功能，交付时间会从一小时膨胀到一周。

六问结束，Agent 产出一份设计文档，存入项目仓库。关键决策已明确：范围是"可玩的原型"，验收标准是"蛇能动、能吃、能死、能重来、最高分持久化"。不做的功能被显式记录——难度曲线、音效、排行榜、皮肤系统划入"不在此次 Sprint 范围"。

5.6.2 Plan：四个角色审查同一个方案

运行 /autoplan，CEO、设计、工程、DX 四个角色依次审查。注意：/autoplan 只跑 Plan 阶段的四层审查——它不写任何代码。它的输出是一份被四个角色分别挑战过的方案文档，而非可运行的程序。你必须手动告诉 Agent "按这份方案写代码"，Build 阶段才开始。

CEO 视角： "这是演示项目，不是产品。扩张模式不适用。维持模式：只做核心玩法，不做任何超出演示需求的功能。"

设计视角： "20×20 Canvas 网格合理。蛇绿色方块、食物红色方块——高对比度，可辨识。注意：游戏结束弹窗别用 alert()——那是 1998 年的设计。用 HTML modal，加半透明遮罩。"

工程视角： "状态层和渲染层需要明确分离。gameState 对象集中管理蛇身数组、方向、分数、游戏状态。gameLoop 每 150ms 调 update()（纯逻辑）和 render()（纯绘制）。键盘事件写入 nextDirection 缓冲，gameLoop 在 update() 中同步到 direction——防止快速连续按键的反向 bug。"

DX 视角： "TTHW 目标 < 30 秒。零依赖——打开 index.html 就能玩。不需要 npm install、不需要构建步骤、不需要本地服务器。"

工程视角的"nextDirection 缓冲机制"和设计视角的"HTML modal 替代 alert()"，是 Plan 阶段锁定的两个最关键决策。没这一步，它们会在 Build 或 Test 阶段才暴露——那时修起来多花五倍时间。

5.6.3 Build：一次实现，两次返工

gstack 的 Build 阶段有一个反直觉的设计：它没有定义编码 Skill。5.3.1 节的表格里，Build 行只列了 /design-shotgun（生成 4-6 个 AI 设计变体对比筛选）和 /design-html（将设计稿转为生产级 HTML/CSS）——都是设计专项，不是逻辑编码。

贪吃蛇的逻辑实现不需要这两个。它直接调 Claude Code 原生编码能力，Agent 阅读 /plan-eng-review 锁定的架构（状态层分离、nextDirection 缓冲、150ms 游戏循环），把 ASCII 架构图和状态机描述翻译为代码。Plan 阶段的输出在此充当"规格"——不是 OpenSpec 式的精确验收标准，而是一份角色化审查过的实现约束。

这暴露了 gstack 的一个刻意取舍：Build 阶段没有像 /review 或 /qa 那样定义专门的编码角色。因为编码本身是 Claude Code 的强项——给出约束，生成代码，不需要额外的"编码专家"人格来增强。Garrick Toubassi（YC 的工程合伙人，gstack 的另一位核心维护者）在一个讨论帖中说过大致的意思：我们不教 Agent 怎么写代码，我们教 Agent 在写代码之前和之后该做什么。Plan 和 Review 是 AI 的弱点——需要角色化审查来弥补。编码是 AI 的强项——给它审查过的约束，放手让它写。

Plan 阶段方案清晰，Agent 按工程审查锁定的架构生成了第一版代码，四个任务：

1. HTML 结构与 Canvas 渲染：20×20 网格，绿色蛇，红色食物。
2. 状态管理与蛇的移动：gameState 对象，nextDirection 缓冲，150ms 游戏循环。
3. 碰撞检测与食物系统：墙壁碰撞、自身碰撞、食物消费、随机生成。
4. 分数系统与游戏状态管理：当前分数/最高分、HTML modal 弹窗、重新开始按钮、localStorage 持久化。

第一版跑起来就暴露了两个问题。食物随机生成偶尔会刷在蛇身上——概率不高，但蛇长了以后越来越频繁。更隐蔽的一个：游戏结束弹窗写了 HTML modal，但没处理焦点——弹窗出现后方向键仍然能控制蛇，导致"死了还能动"的诡异画面。Agent 自己没发现这些问题，/review 阶段才被揪出来。返工两次，Build 才算消停。

所以这一步在调用 /autplan 命令时就自动实现了。

5.6.4 Review：员工工程师发现了什么

运行 /review：

Review

[CRITICAL] (confidence: 9/10) ch05/snake.html:164 — food=null crashes draw loop when board fills up

draw() accesses food[0] and food[1] at line 164 without null guard. When spawnFood() sets food = null (board full), every rAF frame throws TypeError.

const fx = food[0] * CELL + CELL/2, fy = food[1] * CELL + CELL/2;

Fix: guard food rendering.

[CRITICAL] (confidence: 9/10) ch05/snake.html:193 — ctx.roundRect() unavailable on older browsers

ctx.roundRect() requires Chrome 99+, Safari 15.4+, Firefox 112+. Older embedded WebViews throw and kill rendering. Fix: feature-detect with fallback to manual path.

[P2] (confidence: 7/10) ch05/snake.html:235-239 — touchstart+click double-fires start() on desktop touch

touchstart calls start(), then 300ms later synthetic click fires start() again. On desktop with touchscreen, this means: first touch during game-over resets AND starts in one tap
(not two separate actions). Fix: track if touchstart already handled.

不但review发现问题，它还会自动修复，直到没有问题。

5.6.5 Test：QA 用真实浏览器测试

运行 /qa：

Agent 通过 /browse 的无头 Chromium 实例打开 index.html，执行：

• 截图验证网格渲染正确（20×20 格子、蛇初始在中央）
• 模拟方向键按下，截图验证蛇的位置变化
• 模拟吃到食物的场景（脚本将食物坐标设为蛇头前方），验证蛇身变长、分数增加
• 模拟撞墙（蛇头移到边界外），验证游戏结束弹窗出现
• 验证最高分在 localStorage 中的持久化
• 验证隐私模式降级行为（清除 localStorage 后重试）

全部测试通过。QA 自动生成了四个回归测试脚本，存入测试资产库。

5.6.6 Ship：一键交付

运行 /ship：

• 同步主干 → 无冲突
• 运行全部测试 → 全部通过
• 审计测试覆盖率 → 关键路径 100% 覆盖
• 创建 commit（Conventional Commits 格式）
• 推送到远程
• 创建 PR（自动填写 What/Why/How）

运行 /land-and-deploy：合并 PR → 等 CI 通过 → 确认部署成功。

5.6.7 Reflect：基线存档

贪吃蛇这样一个小项目，/retro 的周回顾模式不太适用——它更适合多 Sprint 项目。但 /benchmark 还是跑了一遍：页面加载时间 180ms，首次渲染 320ms，游戏循环稳定性 ±2ms。这些数据作为基线存入项目仓库——将来有人加功能导致性能退化，对比基线立刻能发现。

5.6.8 gstack 和其他方法论的对比

同一个贪吃蛇任务，四种方法论，四种体验：

Pocock Skills 最快。七个斜杠命令，灵活，全程需要人驾驶。OpenSpec 最稳，规格先行不容易跑偏，代价是每步都要人写文档。Ralph Loop 最省心——写好 prompt 就能去睡觉，醒来验收，但 prompt 质量决定一切。gstack 最重。七个阶段走完确实比前三者都慢，多花的时间花在了审查记录上——CEO 为什么砍难度曲线、工程经理为什么锁定 nextDirection 缓冲、设计师为什么坚持 HTML modal 替代 alert。六个月后另一个人重构这个游戏，读到这些记录，省下的时间远不止当初审查花掉的那几十分钟。

回到第 1 章的框架：Pocock Skills 是一组工具，OpenSpec 是一份合约，Ralph Loop 是一个发动机。gstack 是一支军队。工具用在日常小任务上顺手，合约适合有规格的功能，发动机对付可以自动化验证的活，军队用在从零到一的完整项目上。

5.7 Nanostack：gstack 的轻量级衍生

gstack 的三十余个 Skill 和七阶段 Sprint 构成了一套完整的虚拟工程团队操作系统。但每个项目都走全流程？没必要。一个个人 side project、一个快速原型、一个只有一两个开发者的小项目——走 Think → Plan → Build → Review → Test → Ship → Reflect 全流程是杀鸡用牛刀。

Nanostack（由 garagon 开发）就是为这个场景设计的。受 gstack 启发，减掉了约三分之二的 Skill，保留了最核心的十三个。Sprint 同样是七阶段，但阶段门控可选——两种配置：Guided（更安全的默认，阶段间有门控）和 Professional（更自由的权衡，阶段间无强制门控）。

Nanostack 的十三核心 Skill 覆盖了：产品思考、工程计划、代码实现、自动审查、QA 测试、安全审计、发布交付、回顾分析。它和 gstack 的关系类似 Express 和 Rails——前者是后者核心思想的最小化实现，放弃了部分功能，换来了更低入门成本和更高灵活性。

怎么选？做需要完整治理轨迹的项目（合规性行业、多人协作、长期维护）——gstack，完整流程和强制门控的保障远大于流程成本。做快速验证（MVP、原型、个人项目）——Nanostack，保留一人多角色的核心价值，不会用流程锁住速度。

5.8 gstack 的适用边界

gstack 不是万能药。有些场景它是超级武器，有些场景它是负担。

最适合：

• 从零到一的绿野项目。 没历史包袱。CEO 审查不会和已有代码冲突，工程审查不需要考虑迁移成本。gstack 在绿野项目上能满负荷运转，每一层审查都在创造价值。
• 需要完整治理轨迹的项目。 合规性行业、ToB 产品、开源项目的核心模块——每次 PR 都需要能追溯谁在什么时间以什么理由做了这个决定。gstack 每个阶段的输出都是天然的审计轨迹。
• 单人团队。 这是 gstack 最反直觉的适用场景。独立开发者没同事 review 代码，没 QA 测功能，没安全官审计漏洞。gstack 给了这个开发者二十三个虚拟同事——每个专精一个维度，在自己的领域内比开发者本人更专业。

不适合：

• 小修小补。 "把按钮颜色从蓝色换成绿色"——走完 Think → Plan → Build → Review → Test → Ship 全流程是荒谬的。gstack 的流程成本是固定的，任务越小，占比越高。
• 存量项目中的增量变更。 给一个二十万行代码的项目加暗黑模式，不需要 CEO 重新审产品方向。gstack 没提供像 OpenSpec 那样的增量规格机制——它的设计假设是从顶层思考开始。
• 需求模糊的探索性项目。 gstack 的流程要求每个阶段做出承诺。CEO 审查后方向锁定，工程审查后架构锁定。如果项目本身还在探索"到底要做什么"，流程会变成形式主义——填模板而不是做决策。

一个实用的判断公式：任务能写出一份清晰的 PRD，gstack 值回票价。任务还在"试试看能不能 work"，先用 Pocock Skills 快速探索，方向明朗了再上 gstack。

5.9 与前后章节的关系

gstack 与 Skills（第 2 章）。 gstack 的每个专家角色本质上是披了人格外衣的 Skill。Pocock 的 /grill-me 和 gstack 的 /office-hours 做同一件事——盘问需求——但前者是通用协议，后者是有角色身份的顾问。Skills 是原子，gstack 是分子——用角色化把原子组织成了有结构的团队。

gstack 与 SDD（第 3 章）。 gstack 的 Plan 阶段产出——CEO 审查结论、工程审查锁定的架构、设计审查结论——功能上等于一份多维度规格文档。但 gstack 没把规格作为独立 artifact 管理，它把规格分散在了各个角色的输出中。如果你需要可单独引用、可版本对比的规格文档，OpenSpec 或 Spec-Kit 更标准。如果你需要在多个维度上同时锁定方向，gstack 的多角色审查覆盖面更广。

gstack 与 Ralph Loop（第 4 章）。 Ralph Loop 解决"做对了没"，gstack 解决"在对的方向上吗"。两者互补——用 gstack 定方向（Think + Plan），用 Ralph Loop 跑执行（Build 阶段的自主循环），用 gstack 验收（Review + Test + Ship）。第 9 章"方法论对比与融合"会详谈这个组合模式。

gstack 与 Harness Engineering（第 10 章）。 gstack 的强制门控直接依赖 Claude Code 的 PreToolUse hooks——它是 Harness Engineering 最典型的上层应用。没 hooks 机制，gstack 的阶段门控就是引导指令，失去了强制力。gstack 和 Claude Code Harness 的关系，就是应用程序和操作系统的关系。

5.10 本章小结

gstack 的名字来自 Garry Tan 的一句话——他本质上是一个工程经理，管理一支临时工模型大军。它的 GitHub 描述只有五个词——"open source software factory"。这两句话加起来就是 gstack 的全部：不是让 AI 变聪明，是给 AI 建一个组织架构。

它的核心贡献在于把三个工业时代就有的概念用在了 AI Agent 身上：

1. 专业分工。 不让一个 Agent 做好所有事。CEO 不写代码，员工工程师不思考产品方向，QA 不审计安全漏洞。二十三个角色各自审查自己擅长的维度，合起来覆盖一个人工审查者覆盖不了的面。
2. 流程门控。 "代码审查通过才能 commit"——不靠人的自觉，靠系统强制执行。gstack 用 Claude Code 的 PreToolUse hooks 做到了。在人不完美的地方，系统不该配合人的懒惰。
3. 工件传递。 每个阶段的输出自动成为下一阶段的输入。/office-hours 的设计文档被 /plan-eng-review 读，Plan 锁定的架构被 Build 读，Build 产出的代码被 Review 读，Review 的发现被 QA 验证。一环扣一环，不靠人传话。

这三个设计合在一起的效果是：一个人从代码生产者变成了工程管理者。Garry Tan 的八百一十倍产出不是因为编码变快了，是因为二十三个人同时在跑不同的线——他只需要定义目标、审查产出、做方向决策。

gstack 的适用边界也很明确。从零到一的绿野项目、需要完整治理轨迹的合规场景、单人团队——它是超级武器。小修小补、存量项目的增量变更、需求模糊的探索期——它太重了。实用的判断公式：能写出一份清晰 PRD 的任务，gstack 值回票价；还在"试试看能不能 work"的阶段，先用 Pocock Skills，方向明朗了再上 gstack。

如果第 2 章的 Skill 是能力单元、第 3 章的 Spec 是质量合约、第 4 章的 Ralph Loop 是执行引擎，那么 gstack 就是组织架构。它不让 AI 变得更聪明——它让一群 AI 在一个有纪律的团队里协作出一个人做不到的产出。

但 gstack 也沉重。三十余个 Skill，七阶段 Sprint，强制门控。下一章讲 superpowers，一个用 159K+ Stars 社区规模证明了相反设计方向的方法论系统：不靠流程锁住质量，靠足够多的 Skill 覆盖足够多的场景，让开发者在需要时自己选对的工具。一个讲究流程集成，一个讲究工具覆盖。两个系统的对比，会是全书方法论图谱中最有意思的一段。