首页 / AI

gstack 方法论：虚拟工程团队

鸟窝 2026-06-28 17:10:17 累计浏览 2 次

本机暂存

内容概览

gstack方法论通过虚拟工程团队概念革新AI辅助软件开发。它将AI代理组织成结构化团队，定义23个专家角色，每个角色由Markdown文件指定认知模式和职责。核心设计基于角色化、流程化和自动化：角色化使代理以专业人格执行任务，如YC合伙人审查产品想法；流程化通过七阶段Sprint强制执行，包括Think、Plan、Build、Review、Test、Ship、Reflect，确保阶段间产出流转；自动化利用Claude Code的PreToolUse hooks实现质量门控，如未通过代码审查则阻止commit。系统安装便捷，通过git clone和setup脚本快速部署，支持团队模式和多代理宿主如Claude Code、OpenAI Codex CLI等，确保版本同步。gstack解决了单个AI代理的局限，通过多角色协作提升开发效率与代码质量，适用于从产品发现到发布监控的完整生命周期，代表AI软件工程的重要进展。

<blockquote>"I basically operate as an engineering manager for a fleet of temporary models." 我本质上是一个工程经理，管理一支临时工模型大军。——Garry Tan, Y Combinator 总裁 & CEO, 2026 年</blockquote>Skill 是能力单元——一个 Markdown 文件定义一种行为。Spec 是合约，定义"做成什么样才算对"。Ralph Loop 是执行引擎，"做不到就继续做"。三者构成闭环：Skill 提供方法，Spec 提供标准，Ralph Loop 提供执行力。但它们都隐含了同一个假设：你只有一个 Agent。把这个假设推倒。如果你可以同时拥有二十三个 Agent，每个被赋予一个不同的专家角色——有人负责产品思考，有人负责架构设计，有人负责代码审查，有人负责质量测试，有人负责安全审计，有人负责发布部署——并且它们按照一个严格的 Sprint 流程协作。会发生什么？gstack 回答这个问题。它是一个虚拟工程团队的操作系统。<h2 id="5-1-一个人就是一支军队"><a href="#5-1-一个人就是一支军队" class="headerlink" title="5.1 一个人就是一支军队"></a>5.1 一个人就是一支军队</h2>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 怎么测应用、安全官怎么审计漏洞。调用 <code>/office-hours</code>，Agent 切换到"YC 合伙人"模式，六个强制问题盘问你的产品想法。调用 <code>/review</code>，同一个 Agent 切换到"员工工程师"模式，寻找能通过 CI 却在生产环境爆发的隐蔽 bug。调用 <code>/ship</code>，它变成"发布工程师"，同步主干、跑测试、审计覆盖率、推送代码、创建 PR。同一个 Agent，不同角色。切换不靠每次重写 prompt——靠一个 Markdown 文件。第 2 章 Pocock 的 Skill 哲学在这里被推到了极致：当 Skill 不再零散，而是一个完整的组织架构，AI 软件工程的上限就变了。Garry Tan 自己说过一句话，概括了 gstack 的设计理念：他本质上是一个工程经理，管理一支临时工模型大军。这句话在卷首语中也出现过——Claude Code 的创造者 Boris Cherny 说过类似的话。但 Garry Tan 比 Cherny 多走了一步：他给这支 AI 大军建立了一套组织架构——角色分工、流程阶段、质量门禁、交付流水线。一群零散的 Agent 变成了一个有结构的虚拟工程团队。<img src="/images/image-20260523135259179.png"><h2 id="5-2-安装与配置：30-秒建起一支虚拟军队"><a href="#5-2-安装与配置：30-秒建起一支虚拟军队" class="headerlink" title="5.2 安装与配置：30 秒建起一支虚拟军队"></a>5.2 安装与配置：30 秒建起一支虚拟军队</h2>gstack 是一组 Markdown 文件，代码完全开源，MIT 许可证。三十余个 Skill 文件构成它的全部——不需要数据库、不需要后端服务、不需要 API Key 之外的付费依赖。获取方式只有一种：<code>git clone</code>，然后跑一条 setup 脚本。<h3 id="5-2-1-依赖与前提"><a href="#5-2-1-依赖与前提" class="headerlink" title="5.2.1 依赖与前提"></a>5.2.1 依赖与前提</h3>gstack 跑在 Claude Code 之上——它的 PreToolUse hooks、slash commands、project-level config 都依赖 Claude Code 的 Harness 体系（详见第 10 章）。所以前提条件少：<ul><li>Claude Code —— gstack 的宿主。Claude Code 提供 Agent 运行时、hooks 机制和 slash command 支持。</li><li>Git —— Skill 文件通过 git 分发和版本管理。</li><li>Bun v1.0+ —— gstack 的 setup 脚本和 hooks 用 Bun 的 TypeScript 运行时，利用它的快速启动和内置工具链。</li><li>Node.js（仅 Windows）——Bun 在 Windows 上尚未完整覆盖，部分脚本需要 Node.js 作为回退。</li></ul><h3 id="5-2-2-基础安装"><a href="#5-2-2-基础安装" class="headerlink" title="5.2.2 基础安装"></a>5.2.2 基础安装</h3>在 Claude Code 会话中粘贴这行命令：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup </pre></td></tr></table></figure><code>--depth 1</code> 是浅克隆，只拉最新版本——几十 KB，秒级完成。<code>./setup</code> 做了三件事：把三十余个 Skill 文件注册到 Claude Code 的 skills 目录、生成 CLAUDE.md 的 gstack 配置区块、配置 <code>/browse</code> 无头浏览器 Skill。Agent 自己执行这些步骤，不需要人手动改文件。30 秒后，三十余个 <code>/</code> 命令全局可用——<code>/office-hours</code>、<code>/review</code>、<code>/qa</code>、<code>/ship</code>、<code>/cso</code>……任何一个 Claude Code 会话，在任何目录，都能调用。<h3 id="5-2-3-团队模式：共享-repo-的自动同步"><a href="#5-2-3-团队模式：共享-repo-的自动同步" class="headerlink" title="5.2.3 团队模式：共享 repo 的自动同步"></a>5.2.3 团队模式：共享 repo 的自动同步</h3>个人使用，全局安装就够了。但多人协作的 repo 需要团队模式——让每个 Clone 仓库的开发者自动获得 gstack，不需要手动安装。在项目目录内运行：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>(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" </pre></td></tr></table></figure>这条命令做的事：把 gstack 标记为项目的必需依赖，写入 <code>.claude/</code> 配置和 <code>CLAUDE.md</code>。之后任何人 checkout 这个 repo 开 Claude Code 会话，系统自动检测缺失的 gstack 并引导安装。版本漂移问题不复存在——每个会话启动时做一次自动更新检查（限流每小时一次，网络失败无害降级，完全静默）。<code>required</code> 可换成 <code>optional</code>——required 阻止未装 gstack 的会话进入，optional 只提示不阻止。<h3 id="5-2-4-多-Agent-支持"><a href="#5-2-4-多-Agent-支持" class="headerlink" title="5.2.4 多 Agent 支持"></a>5.2.4 多 Agent 支持</h3>gstack 的设计不锁定 Claude Code。它的 setup 脚本自动检测你机器上装了哪些 AI 编码 Agent，按需分发 Skill 文件。截至 2026 年 5 月，支持 10 种 Agent：<table><thead><tr><th>Agent</th><th>安装路径</th></tr></thead><tbody><tr><td>Claude Code</td><td><code>~/.claude/skills/gstack-*/</code></td></tr><tr><td>OpenAI Codex CLI</td><td><code>~/.codex/skills/gstack-*/</code></td></tr><tr><td>OpenCode</td><td><code>~/.config/opencode/skills/gstack-*/</code></td></tr><tr><td>Cursor</td><td><code>~/.cursor/skills/gstack-*/</code></td></tr><tr><td>Factory Droid</td><td><code>~/.factory/skills/gstack-*/</code></td></tr><tr><td>Slate</td><td><code>~/.slate/skills/gstack-*/</code></td></tr><tr><td>Kiro</td><td><code>~/.kiro/skills/gstack-*/</code></td></tr><tr><td>Hermes</td><td><code>~/.hermes/skills/gstack-*/</code></td></tr><tr><td>GBrain</td><td><code>~/.gbrain/skills/gstack-*/</code></td></tr></tbody></table>用 <code>./setup --host <name></code> 指定目标 Agent。核心 Skill 逻辑同一套 Markdown 文件，Agent 特定的适配层由 setup 脚本按注入方式生成。新增一个 Agent 宿主也简单——一个 TypeScript 配置文件，零代码改动（详见 gstack 仓库的 <code>ADDING_A_HOST.md</code> 文档）。这个设计反映了一个工程判断：Skill 的"认知模式"是平台无关的，只有 hooks 和门控机制依赖特定 Agent 的 Harness 能力。<h3 id="5-2-5-OpenClaw-深度集成"><a href="#5-2-5-OpenClaw-深度集成" class="headerlink" title="5.2.5 OpenClaw 深度集成"></a>5.2.5 OpenClaw 深度集成</h3>Peter Steinberger 的 OpenClaw（247K GitHub Stars）通过 ACP 协议批量管理 Claude Code 会话。gstack 对此做了原生适配：<ul><li>在 OpenClaw Agent 中安装 gstack 后，所有 Skill 在 OpenClaw 管理的 Claude Code 子会话中自动可用。</li><li>四个方法论 Skill（<code>/office-hours</code>、<code>/plan-ceo-review</code>、<code>/investigate</code>、<code>/retro</code>）以 OpenClaw 原生 Skill 形式发布到 ClawHub，无需 Claude Code 会话也能跑——它们是纯对话 Skill，不依赖 hooks：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>clawhub install gstack-openclaw-office-hours gstack-openclaw-ceo-review gstack-openclaw-investigate gstack-openclaw-retro </pre></td></tr></table></figure></li></ul>日常使用中，你不必手动加载 gstack——对 OpenClaw Agent 说"审查这个 PR 的安全性"，它自知要 spawn Claude Code 会话并执行 <code>/cso</code>。说"帮我规划 v2 API 重构"，它跑 <code>/office-hours</code> → <code>/autoplan</code>。OpenClaw 做调度，gstack 做执行。<h3 id="5-2-6-升级与维护"><a href="#5-2-6-升级与维护" class="headerlink" title="5.2.6 升级与维护"></a>5.2.6 升级与维护</h3>gstack 的维护模型建立在"文件即工具"这个前提上。升级只需重新跑 setup——覆盖旧 Skill 文件，保留用户自定义配置。<code>/gstack-upgrade</code> Skill 封装了这个流程，一条命令完成：拉取最新 git commit、重新执行 setup、输出 changelog。自动更新机制（团队模式）确保共享 repo 的开发者始终用同一版本——不是"建议升级"，是"不升级进不去"。有人觉得这太重，有人觉得多人协作下这是唯一靠谱的做法。两种意见在第 5.5 节的强制力之争中有完整展开。<h2 id="5-3-从工具到团队：gstack-的核心设计"><a href="#5-3-从工具到团队：gstack-的核心设计" class="headerlink" title="5.3 从工具到团队：gstack 的核心设计"></a>5.3 从工具到团队：gstack 的核心设计</h2>gstack 的设计围绕三件事：角色化、流程化、自动化。<h3 id="5-3-1-角色化：每个-Skill-是一个专家人格"><a href="#5-3-1-角色化：每个-Skill-是一个专家人格" class="headerlink" title="5.3.1 角色化：每个 Skill 是一个专家人格"></a>5.3.1 角色化：每个 Skill 是一个专家人格</h3>Pocock 的 Skills 系统中，一个 Skill 定义一种行为——"怎么做 TDD""怎么对齐需求""怎么调试"。行为是抽象的，不绑定人格。<code>/tdd</code> 直接给出红-绿-重构的循环规则。gstack 每个 Skill 既定义行为，也定义人格。<code>/plan-ceo-review</code> 的开头是"你是 CEO / 创始人。你的职责是重新思考这个问题，找到'十星级产品'的愿景。"人格设定改变了 Agent 的认知姿态——它不光知道要做什么，还知道用什么视角、什么标准、什么语气来做。这是工程决策，不是包装。当你对 AI 说"审查这个架构"，它给出的反馈取决于它认为自己是谁。如果它认为自己是一个代码审查者，会关注命名、结构、可读性。如果它认为自己是工程经理，会关注模块边界、扩展性、失败模式。如果它认为自己是 CEO，会关注这个架构在多大程度上服务于产品愿景、哪些复杂度是为未来假设买单、哪些简化会释放更多迭代速度。gstack 把这个洞见系统化了：不让一个全能 Agent 做所有审查。让二十三个专家 Agent 各自审查自己擅长的维度。<img src="/images/image-20260530005853351.png">以下是 gstack 七个 Sprint 阶段的核心角色：<table><thead><tr><th>Sprint 阶段</th><th>角色 Skill</th><th>人格设定</th><th>核心职责</th></tr></thead><tbody><tr><td>Think</td><td><code>/office-hours</code></td><td>YC 合伙人</td><td>六个强制问题盘问产品想法</td></tr><tr><td>Plan</td><td><code>/plan-ceo-review</code></td><td>CEO / 创始人</td><td>寻找"十星级产品"愿景</td></tr><tr><td>Plan</td><td><code>/plan-eng-review</code></td><td>工程经理</td><td>锁定架构、数据流、边界条件</td></tr><tr><td>Plan</td><td><code>/plan-design-review</code></td><td>高级设计师</td><td>0-10 设计维度评分，AI Slop 检测</td></tr><tr><td>Plan</td><td><code>/plan-devex-review</code></td><td>开发者体验负责人</td><td>TTHW 基准对比，摩擦点追踪</td></tr><tr><td>Build</td><td><code>/design-shotgun</code></td><td>设计探索者</td><td>生成 4-6 个 AI 模型变体，对比迭代</td></tr><tr><td>Build</td><td><code>/design-html</code></td><td>设计工程师</td><td>将设计模型转化为生产级 HTML/CSS</td></tr><tr><td>Review</td><td><code>/review</code></td><td>员工工程师</td><td>寻找 CI 通过但生产爆发的 bug</td></tr><tr><td>Review</td><td><code>/investigate</code></td><td>调试专家</td><td>系统化根因调试（铁律：不调查不修复）</td></tr><tr><td>Test</td><td><code>/qa</code></td><td>QA 负责人</td><td>真实浏览器测试，自动生成回归测试</td></tr><tr><td>Test</td><td><code>/cso</code></td><td>首席安全官</td><td>OWASP Top 10 + STRIDE 威胁建模</td></tr><tr><td>Ship</td><td><code>/ship</code></td><td>发布工程师</td><td>同步主干→跑测试→审计覆盖率→推送→开 PR</td></tr><tr><td>Ship</td><td><code>/land-and-deploy</code></td><td>发布工程师</td><td>一键从"approved"到"verified in production"</td></tr><tr><td>Ship</td><td><code>/canary</code></td><td>SRE</td><td>部署后监控：控制台错误、性能退化、页面故障</td></tr><tr><td>Reflect</td><td><code>/retro</code></td><td>工程经理</td><td>周回顾：个人细分、交付连贯性、测试健康趋势</td></tr><tr><td>Reflect</td><td><code>/benchmark</code></td><td>性能工程师</td><td>性能基准对比：页面加载、Core Web Vitals</td></tr></tbody></table>这十五个之外，gstack 还有一系列辅助角色——<code>/browse</code>（持久化无头浏览器，给 Agent 装上"眼睛"）、<code>/context-save</code> 和 <code>/context-restore</code>（跨会话状态持久化）、<code>/codex</code>（调用 OpenAI Codex 提供第二意见）、<code>/health</code>（代码质量仪表盘）、<code>/document-release</code>（发布后自动同步全部文档）——总共三十余个 Skill，覆盖从产品发现到发布监控的完整软件生命周期。<h3 id="5-3-2-流程化：Sprint-不是建议，是结构"><a href="#5-3-2-流程化：Sprint-不是建议，是结构" class="headerlink" title="5.3.2 流程化：Sprint 不是建议，是结构"></a>5.3.2 流程化：Sprint 不是建议，是结构</h3>有二十三个专家角色是第一步。第二步是让它们按正确的顺序工作。<img src="/images/image-20260530010322335.png">gstack 定义了一个七阶段 Sprint：Think → Plan → Build → Review → Test → Ship → Reflect。 它通过 PreToolUse hooks 在 Claude Code 上实现了强制性阶段门控。未通过 <code>/review</code> 的代码无法 commit。未通过 <code>/qa</code> 的功能无法进入 <code>/ship</code>。门控是系统执行的，不依赖人的纪律。每个阶段的产出自动成为下一阶段的输入。<code>/office-hours</code> 产出的设计文档被 <code>/plan-ceo-review</code> 和 <code>/plan-eng-review</code> 消费。<code>/plan-eng-review</code> 锁定的架构和数据流被 Build 阶段的 Agent 作为实现约束。<code>/review</code> 发现的 bug 被 <code>/qa</code> 验证修复。<code>/qa</code> 生成的回归测试变成后续所有迭代的自动化安全网。<code>/retro</code> 的周回顾基于 git 历史的客观数据——每个人的交付连贯性、测试健康趋势、增长机会——不依赖主观感受。这个流程设计回应了第 4 章 Ralph Loop 的一个核心局限：Ralph Loop 解决"一个任务内的自我纠正"，解决不了"谁来决定任务方向是否正确"。gstack 在上面加了一层角色化流程审查——代码写出来之前，CEO 角色审产品方向、工程经理角色审架构方案、设计师角色审用户体验、安全官角色审威胁模型。Ralph Loop 保证做对了，gstack 保证在做对的事。<h3 id="5-3-3-自动化：当流程可以被机器强制执行"><a href="#5-3-3-自动化：当流程可以被机器强制执行" class="headerlink" title="5.3.3 自动化：当流程可以被机器强制执行"></a>5.3.3 自动化：当流程可以被机器强制执行</h3>gstack 最激进的创新不在角色数量，在强制力。大多数 AI 编码工具上，流程规范本质上是引导指令——Agent 被要求"先做计划再写代码"，但如果它跳过了计划直接写代码，没有系统级机制阻止它。Claude Code 的 Harness 体系（第 10 章详谈）提供了 PreToolUse hooks——在 Agent 执行特定工具调用前插入检查脚本。gstack 充分利用了这个机制：<code>git commit</code> 前检查代码审查是否通过，<code>git push</code> 前检查 QA 测试是否完成，部署前检查安全审计是否执行。这和传统 CI/CD 流水线有一个关键区别。传统 CI/CD 检查的是代码能不能跑（构建、测试、lint）。gstack 的 hooks 检查的是流程有没有走完——不直接判断代码好坏，而是确保该看的人都看过了。这是一种元级别的质量保证。Garry Tan 管这叫"流程即代码"（Process as Code）。就像 IaC 把服务器配置变成可版本控制的文件，gstack 把工程流程变成了可版本控制的 Markdown 文件和 hooks 脚本。一个新团队成员加入项目时，不需要"学习流程"——流程已经编码在系统中，自动执行。<h2 id="5-4-Sprint-全景：七个阶段的深度拆解"><a href="#5-4-Sprint-全景：七个阶段的深度拆解" class="headerlink" title="5.4 Sprint 全景：七个阶段的深度拆解"></a>5.4 Sprint 全景：七个阶段的深度拆解</h2>上面是 gstack 的骨架。现在一个阶段一个阶段拆开，看肌肉怎么工作。<h3 id="5-4-1-Think：用六个强制问题杀死坏想法"><a href="#5-4-1-Think：用六个强制问题杀死坏想法" class="headerlink" title="5.4.1 Think：用六个强制问题杀死坏想法"></a>5.4.1 Think：用六个强制问题杀死坏想法</h3><code>/office-hours</code> 是 gstack Sprint 的起点。灵感来自 Y Combinator 的 Office Hours——YC 合伙人与创始人之间那种著名的、不留情面的二十分钟产品对话。这个 Skill 的人格设定是"YC 合伙人"。行为不是"听你说完然后给反馈"——它用六个强制问题盘问你的产品想法：<ol><li>你在解决谁的什么痛苦？——把你从"我觉得这个 idea 很酷"拽到"有一个具体的人正在经历一种具体的痛苦"。</li><li>他们现在怎么解决这个问题的？——不知道现有方案，就不了解竞争格局。</li><li>你的方案好在哪？——不是好在技术上，是好在用户愿意切换过来。</li><li>最小可验证的第一步是什么？——答案超过两周工作量，说明你还没想清楚。</li><li>为什么是你？——你有什么洞察、技能或资源让这件事只有你能做？</li><li>如果这个失败了，最可能的原因是什么？——正面假设自己的产品会死，倒推最可能的死因。</li></ol>六个问题问完，Agent 产出一份设计文档。不是 PRD，不是 spec，是一份"已经想清楚了什么、还没想清楚什么"的结构化记录。这份文档成为 Plan 阶段所有审查角色的输入。<h3 id="5-4-2-Plan：四层审查锁定方向"><a href="#5-4-2-Plan：四层审查锁定方向" class="headerlink" title="5.4.2 Plan：四层审查锁定方向"></a>5.4.2 Plan：四层审查锁定方向</h3>Plan 阶段是 gstack 的防御核心。写一行代码之前，四个角色各自从专业视角审查同一个方案。<code>/plan-ceo-review</code>——CEO 视角。 这个角色不问"怎么实现"，问"该不该做"。它用四种战略模式评估每个功能：扩张模式（加倍投入）、选择性模式（只做最有价值的部分）、维持模式（不做增量，只维护质量）、削减模式（砍掉）。一个功能被分配了削减模式，后续角色就不再为它消耗审查资源。<code>/plan-eng-review</code>——工程经理视角。 这个角色锁定架构：ASCII 架构图、数据流图、状态机、测试矩阵。核心任务是把隐藏的假设翻到台面上——组件 A 依赖组件 B 的什么接口？并发场景的竞态条件是什么？失败模式的降级策略是什么？这些问题不在这一步澄清，到 Build 阶段再发现，返工成本是十倍起。<code>/plan-design-review</code>——高级设计师视角。 这个角色有一个独特的职责：AI Slop 检测。"Slop"是 2025-2026 年 AI 生成内容社区涌现的一个词——指 AI 倾向于生成的那些看起来不错但缺乏真实设计意图的视觉产出。AI 做的 UI 常常是均匀的间距、对称的布局、标准的配色——视觉上不丑，但也不对。它们缺一个人类设计师做特定选择时的理由——"这个按钮为什么是 48px 不是 44px？""这个颜色为什么是 #1890ff 不是 #1677ff？"设计师角色用 0-10 评分系统审查每个设计维度，强制 Agent 为每个设计选择提供理由。<code>/plan-devex-review</code>——开发者体验视角。 这个角色做一件事：实际走一遍"新开发者上车"的流程。测量 TTHW（Time to Hello World）——clone 仓库到看到第一个成功运行的功能要多久——并与同类项目做基准对比。追踪摩擦点：哪些步骤需要手动配置、哪些文档缺失或过时、哪些错误信息让人困惑。开发者体验就是产品体验——你的 API 需要读三篇文档才能调用成功，用户不会怪文档，用户会怪你的产品。四个角色可以分别手动运行，也可以通过 <code>/autoplan</code> 一次性启动全流程——CEO、设计、工程、DX 依次审查，只在有人类判断需要的决策点暂停等待输入。<h3 id="5-4-3-Build：从方案到代码"><a href="#5-4-3-Build：从方案到代码" class="headerlink" title="5.4.3 Build：从方案到代码"></a>5.4.3 Build：从方案到代码</h3>gstack 的 Build 阶段没定义全新的编码 Skill——它复用 Claude Code 原生的编码能力，加了几个设计专项增强。<code>/design-shotgun</code> 是其中最特别的一个。灵感来自散弹枪式的设计探索——同时生成 4-6 个不同风格的 AI 模型变体，放在对比板上逐个淘汰。背后的假设：AI 生成的第一个设计通常不是最好的，它是最平均的。强制生成多个变体并对比，更容易发现哪个选择表达了产品意图。<code>/design-html</code> 将设计模型转化为生产级 HTML/CSS——零依赖、30KB 以内。这个约束本身就是质量声明：不被框架臃肿绑架的设计产出。<h3 id="5-4-4-Review：寻找-CI-抓不到的-bug"><a href="#5-4-4-Review：寻找-CI-抓不到的-bug" class="headerlink" title="5.4.4 Review：寻找 CI 抓不到的 bug"></a>5.4.4 Review：寻找 CI 抓不到的 bug</h3><code>/review</code> 是 gstack 中最重要的质量 Skill 之一。人格设定是"员工工程师"（Staff Engineer）——有十五年经验、见过各种生产事故的老兵。审查逻辑分成两条通道。结构通道：检查代码结构、命名一致性、错误处理完备性、测试覆盖盲区——传统代码审查的自动化版，可以自动修复机械问题。对抗通道：假设自己是攻击者或极端场景——"如果这个 API 被每秒 1000 次调用会怎样？""中间件崩溃重启后状态能恢复吗？""用户同时开两个 tab 操作，数据会冲突吗？"这类问题传统 CI 永远抓不到，因为它们不是代码逻辑错误，是代码在真实世界的行为假设错误。<code>/codex</code> 提供第二意见机制——把同一段代码发给 OpenAI Codex CLI，用不同模型、不同训练数据、不同的"审美"来审查。Claude 和 Codex 同时认为有问题，那几乎可以肯定真有问题。这和第 7 章 autoresearch 的"多 Agent 交叉审核"逻辑一致——不同模型的盲区不同，交叉审核覆盖更多问题类型。<h3 id="5-4-5-Test：给-Agent-装上眼睛"><a href="#5-4-5-Test：给-Agent-装上眼睛" class="headerlink" title="5.4.5 Test：给 Agent 装上眼睛"></a>5.4.5 Test：给 Agent 装上眼睛</h3>gstack 的 Test 阶段是它与其他方法论最显著的差异点。大多数 AI 编码工具的测试止步于单元测试和集成测试——它们能看到代码，看不到 UI。gstack 通过 <code>/browse</code> Skill 提供了一个持久化无头 Chromium 实例，让 Agent 能在真实浏览器中点击、截图、检查 DOM、读控制台输出。<code>/browse</code> 是一个持久化守护进程——在 Agent 会话的整个生命周期中保持运行，维持浏览器状态（cookies、localStorage、登录会话），响应时间约 100-200ms。它的"ref"系统基于无障碍树（accessibility tree）定位元素——Agent 不说"点击坐标 (200, 300)"，说"点击'提交'按钮"。这让测试脚本对 UI 变化具有鲁棒性——按钮换了位置，ref 仍然有效。在此之上，<code>/qa</code> 角色执行完整的 QA 流程：真实浏览器中测试应用、发现 bug、原子 commit 修复、重新验证、自动生成回归测试。<code>/qa-only</code> 提供纯报告模式——发现 bug 不改代码，把发现交给人类开发者处理。<code>/cso</code>（首席安全官）执行 OWASP Top 10 和 STRIDE 威胁建模。它有一个值得注意的设计——17 种误报排除规则。安全扫描工具最让开发者反感的就是误报——"这里可能有 XSS 注入风险"（但输入已经在上一层被清洗了）。<code>/cso</code> 不简单报告"发现 XSS 风险"，它会先检查输入是否已经在调用链的某处被验证或清洗——没有，才报告。<h3 id="5-4-6-Ship：从-approved-到-verified-in-production"><a href="#5-4-6-Ship：从-approved-到-verified-in-production" class="headerlink" title="5.4.6 Ship：从"approved"到"verified in production""></a>5.4.6 Ship：从"approved"到"verified in production"</h3>Plan 阶段是防御，Ship 阶段是进攻——把审查通过的代码投入生产。<code>/ship</code> 执行的是一套完整的发布卫生流程：同步主干→运行全部测试→审计测试覆盖率→有退步就阻止→推送到远程→创建 PR→PR 描述自动填写 What/Why/How。<code>/land-and-deploy</code> 更远一步——一键从"approved"到"verified in production"：合并 PR、等 CI 和部署流水线完成、生产环境跑冒烟测试、验证关键路径可用。<code>/canary</code> 进入 SRE 模式：部署后持续监控控制台错误、性能退化、页面故障。它用 <code>/browse</code> 的无头浏览器实例在部署后自动遍历关键用户路径，发现异常——页面白屏、API 超时、静态资源 404——立即报警。<h3 id="5-4-7-Reflect：数据驱动的回顾"><a href="#5-4-7-Reflect：数据驱动的回顾" class="headerlink" title="5.4.7 Reflect：数据驱动的回顾"></a>5.4.7 Reflect：数据驱动的回顾</h3><code>/retro</code> 不是"大家坐在一起聊聊上周做了什么"的社交仪式。它分析 git 历史的客观数据：每个人的交付连续性（多少次连续合入不中断）、测试健康趋势（覆盖率在上升还是下降）、交付速度的中位数和方差。它产出的是数据。<code>/benchmark</code> 提供性能退化检测：每次 PR 合入后自动对比页面加载时间、Core Web Vitals、资源体积。合入后的指标比合入前差，PR 就被标记为需要性能审查。两个 Skill 构成 gstack 的持续改进闭环——不只让开发更快，而且每一次 Sprint 都比上一次更好，有数据可查。<h2 id="5-5-gstack-的工程文化：强制力之争"><a href="#5-5-gstack-的工程文化：强制力之争" class="headerlink" title="5.5 gstack 的工程文化：强制力之争"></a>5.5 gstack 的工程文化：强制力之争</h2>gstack 有一个在社区中引发持续讨论的设计选择：它通过 PreToolUse hooks 实现了强制阶段门控。未通过 <code>/review</code> 的代码无法 commit。未通过 <code>/qa</code> 的功能无法进入 <code>/ship</code>。批评者和支持者各自引用书中的一章来支撑自己。批评者引第 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 的平台上退化为引导指令。这个设计认了一个现实：流程的强制力取决于平台的能力。有条件强制执行的时候，强制执行更好。没条件的时候，引导也比没流程强。<h2 id="5-6-实战：用-gstack-开发网页版贪吃蛇"><a href="#5-6-实战：用-gstack-开发网页版贪吃蛇" class="headerlink" title="5.6 实战：用 gstack 开发网页版贪吃蛇"></a>5.6 实战：用 gstack 开发网页版贪吃蛇</h2>前四章——Pocock Skills、OpenSpec、Spec-Kit、Ralph Loop——都用网页版贪吃蛇作为实战案例。本章同样，角度不同：前四章用一个工具开发，本章用一支虚拟团队开发。<blockquote>使用gstack开发网页版贪吃蛇游戏有点"杀鸡焉用牛刀"的感觉，不过为了给大家展示一个简单的示例以及和我前面章节保持一致，依然沿用这个例子。</blockquote>走的是不同流程，暴露的是不同问题。<img src="/images/image-20260531015936157.png">初始运行的时候可能需要通过询问的方式配置gstack，按照问题正常回答即可，包括遥测、skill自动调用方式等等配置。<h3 id="5-6-1-Think：产品想法被盘问"><a href="#5-6-1-Think：产品想法被盘问" class="headerlink" title="5.6.1 Think：产品想法被盘问"></a>5.6.1 Think：产品想法被盘问</h3>启动 <code>/office-hours</code>：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>用户: /office-hours 做一个贪吃蛇网页游戏。纯前端单文件。 </pre></td></tr></table></figure><img src="/images/image-20260531012451905.png">Agent 切换到 YC 合伙人模式，六个问题一个一个来（你实际运行时可能问题不同，我刚才实现了第四章的例子，它知道了，所以跳过了很多问题）：<blockquote>Q1：做这个游戏的目标是什么？用户：这是一个做着玩的项目——展示 AI 编码 Agent 的能力。</blockquote>告诉它这只是自己氛围编程的学习项目。<blockquote>Q2：你的用户怎么判断这个游戏"做得好"？用户：蛇能动，能吃食物，能死，死了能重来。最高分刷新后还在。</blockquote><blockquote>Q3：最小可验证的第一步是什么？用户：一个 20×20 的网格上有一条能按方向键移动的蛇。</blockquote><blockquote>Q4：你最大的技术风险是什么？Agent 自己回答：纯前端单文件项目，技术风险很低。但键盘事件处理和游戏循环同步是常见 bug 来源——快速连续按键可能导致蛇反向移动。</blockquote><blockquote>Q5：你计划用多久完成？用户：一小时以内。</blockquote><blockquote>Q6：如果这个项目失败了，最可能的原因是什么？Agent：过度设计。贪吃蛇很简单，但加入难度曲线、音效、排行榜、皮肤系统等"看起来很棒"的功能，交付时间会从一小时膨胀到一周。</blockquote>六问结束，Agent 产出一份设计文档，存入项目仓库。关键决策已明确：范围是"可玩的原型"，验收标准是"蛇能动、能吃、能死、能重来、最高分持久化"。不做的功能被显式记录——难度曲线、音效、排行榜、皮肤系统划入"不在此次 Sprint 范围"。<img src="/images/image-20260531013357046.png"><h3 id="5-6-2-Plan：四个角色审查同一个方案"><a href="#5-6-2-Plan：四个角色审查同一个方案" class="headerlink" title="5.6.2 Plan：四个角色审查同一个方案"></a>5.6.2 Plan：四个角色审查同一个方案</h3>运行 <code>/autoplan</code>，CEO、设计、工程、DX 四个角色依次审查。注意：<code>/autoplan</code> 只跑 Plan 阶段的四层审查——它不写任何代码。它的输出是一份被四个角色分别挑战过的方案文档，而非可运行的程序。你必须手动告诉 Agent "按这份方案写代码"，Build 阶段才开始。CEO 视角： "这是演示项目，不是产品。扩张模式不适用。维持模式：只做核心玩法，不做任何超出演示需求的功能。"设计视角： "20×20 Canvas 网格合理。蛇绿色方块、食物红色方块——高对比度，可辨识。注意：游戏结束弹窗别用 <code>alert()</code>——那是 1998 年的设计。用 HTML modal，加半透明遮罩。"工程视角： "状态层和渲染层需要明确分离。<code>gameState</code> 对象集中管理蛇身数组、方向、分数、游戏状态。<code>gameLoop</code> 每 150ms 调 <code>update()</code>（纯逻辑）和 <code>render()</code>（纯绘制）。键盘事件写入 <code>nextDirection</code> 缓冲，<code>gameLoop</code> 在 <code>update()</code> 中同步到 <code>direction</code>——防止快速连续按键的反向 bug。"DX 视角： "TTHW 目标 < 30 秒。零依赖——打开 <code>index.html</code> 就能玩。不需要 <code>npm install</code>、不需要构建步骤、不需要本地服务器。"工程视角的"nextDirection 缓冲机制"和设计视角的"HTML modal 替代 alert()"，是 Plan 阶段锁定的两个最关键决策。没这一步，它们会在 Build 或 Test 阶段才暴露——那时修起来多花五倍时间。<img src="/images/image-20260531013632751.png"><h3 id="5-6-3-Build：一次实现，两次返工"><a href="#5-6-3-Build：一次实现，两次返工" class="headerlink" title="5.6.3 Build：一次实现，两次返工"></a>5.6.3 Build：一次实现，两次返工</h3>gstack 的 Build 阶段有一个反直觉的设计：它没有定义编码 Skill。5.3.1 节的表格里，Build 行只列了 <code>/design-shotgun</code>（生成 4-6 个 AI 设计变体对比筛选）和 <code>/design-html</code>（将设计稿转为生产级 HTML/CSS）——都是设计专项，不是逻辑编码。贪吃蛇的逻辑实现不需要这两个。它直接调 Claude Code 原生编码能力，Agent 阅读 <code>/plan-eng-review</code> 锁定的架构（状态层分离、<code>nextDirection</code> 缓冲、150ms 游戏循环），把 ASCII 架构图和状态机描述翻译为代码。Plan 阶段的输出在此充当"规格"——不是 OpenSpec 式的精确验收标准，而是一份角色化审查过的实现约束。这暴露了 gstack 的一个刻意取舍：Build 阶段没有像 <code>/review</code> 或 <code>/qa</code> 那样定义专门的编码角色。因为编码本身是 Claude Code 的强项——给出约束，生成代码，不需要额外的"编码专家"人格来增强。Garrick Toubassi（YC 的工程合伙人，gstack 的另一位核心维护者）在一个讨论帖中说过大致的意思：我们不教 Agent 怎么写代码，我们教 Agent 在写代码之前和之后该做什么。Plan 和 Review 是 AI 的弱点——需要角色化审查来弥补。编码是 AI 的强项——给它审查过的约束，放手让它写。Plan 阶段方案清晰，Agent 按工程审查锁定的架构生成了第一版代码，四个任务：<ol><li>HTML 结构与 Canvas 渲染：20×20 网格，绿色蛇，红色食物。</li><li>状态管理与蛇的移动：<code>gameState</code> 对象，<code>nextDirection</code> 缓冲，150ms 游戏循环。</li><li>碰撞检测与食物系统：墙壁碰撞、自身碰撞、食物消费、随机生成。</li><li>分数系统与游戏状态管理：当前分数/最高分、HTML modal 弹窗、重新开始按钮、localStorage 持久化。</li></ol>第一版跑起来就暴露了两个问题。食物随机生成偶尔会刷在蛇身上——概率不高，但蛇长了以后越来越频繁。更隐蔽的一个：游戏结束弹窗写了 HTML modal，但没处理焦点——弹窗出现后方向键仍然能控制蛇，导致"死了还能动"的诡异画面。Agent 自己没发现这些问题，<code>/review</code> 阶段才被揪出来。返工两次，Build 才算消停。所以这一步在调用 <code>/autplan</code> 命令时就自动实现了。<h3 id="5-6-4-Review：员工工程师发现了什么"><a href="#5-6-4-Review：员工工程师发现了什么" class="headerlink" title="5.6.4 Review：员工工程师发现了什么"></a>5.6.4 Review：员工工程师发现了什么</h3>运行 <code>/review</code>：<blockquote> 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.</blockquote>不但review发现问题，它还会自动修复，直到没有问题。<h3 id="5-6-5-Test：QA-用真实浏览器测试"><a href="#5-6-5-Test：QA-用真实浏览器测试" class="headerlink" title="5.6.5 Test：QA 用真实浏览器测试"></a>5.6.5 Test：QA 用真实浏览器测试</h3>运行 <code>/qa</code>：Agent 通过 <code>/browse</code> 的无头 Chromium 实例打开 <code>index.html</code>，执行：<ul><li>截图验证网格渲染正确（20×20 格子、蛇初始在中央）</li><li>模拟方向键按下，截图验证蛇的位置变化</li><li>模拟吃到食物的场景（脚本将食物坐标设为蛇头前方），验证蛇身变长、分数增加</li><li>模拟撞墙（蛇头移到边界外），验证游戏结束弹窗出现</li><li>验证最高分在 localStorage 中的持久化</li><li>验证隐私模式降级行为（清除 localStorage 后重试）</li></ul>全部测试通过。QA 自动生成了四个回归测试脚本，存入测试资产库。<img src="/images/image-20260531020221179.png"><h3 id="5-6-6-Ship：一键交付"><a href="#5-6-6-Ship：一键交付" class="headerlink" title="5.6.6 Ship：一键交付"></a>5.6.6 Ship：一键交付</h3>运行 <code>/ship</code>：<ul><li>同步主干 → 无冲突</li><li>运行全部测试 → 全部通过</li><li>审计测试覆盖率 → 关键路径 100% 覆盖</li><li>创建 commit（Conventional Commits 格式）</li><li>推送到远程</li><li>创建 PR（自动填写 What/Why/How）</li></ul>运行 <code>/land-and-deploy</code>：合并 PR → 等 CI 通过 → 确认部署成功。<img src="/images/image-20260531020522283.png"><h3 id="5-6-7-Reflect：基线存档"><a href="#5-6-7-Reflect：基线存档" class="headerlink" title="5.6.7 Reflect：基线存档"></a>5.6.7 Reflect：基线存档</h3>贪吃蛇这样一个小项目，<code>/retro</code> 的周回顾模式不太适用——它更适合多 Sprint 项目。但 <code>/benchmark</code> 还是跑了一遍：页面加载时间 180ms，首次渲染 320ms，游戏循环稳定性 ±2ms。这些数据作为基线存入项目仓库——将来有人加功能导致性能退化，对比基线立刻能发现。<img src="/images/image-20260531020845630.png"><h3 id="5-6-8-gstack-和其他方法论的对比"><a href="#5-6-8-gstack-和其他方法论的对比" class="headerlink" title="5.6.8 gstack 和其他方法论的对比"></a>5.6.8 gstack 和其他方法论的对比</h3>同一个贪吃蛇任务，四种方法论，四种体验：<table><thead><tr><th>维度</th><th>Pocock Skills（第 2 章）</th><th>OpenSpec（第 3 章）</th><th>Ralph Loop（第 4 章）</th><th>gstack（本章）</th></tr></thead><tbody><tr><td>人类负担</td><td>手动选择每个 Skill</td><td>写 proposal、跑命令</td><td>写好 prompt 就放手</td><td>逐个阶段运行命令</td></tr><tr><td>流程长度</td><td>7 个 Skill 手动串联</td><td>3 个命令 + 1 个归档</td><td>1 个 <code>/ralph-loop</code></td><td>7 个 Sprint 阶段</td></tr><tr><td>自动化程度</td><td>低（人类驱动）</td><td>中（半自动）</td><td>高（全自动循环）</td><td>中（阶段自动，入口手动）</td></tr><tr><td>质量保证</td><td>Skill 内建验证</td><td>Spec 验收标准</td><td>自动重试+测试</td><td>四层角色审查+QA</td></tr><tr><td>发现问题的广度</td><td>聚焦单个 Skill 的领域</td><td>规格符合性</td><td>测试+运行验证</td><td>CEO/工程/设计/安全/QA 全景</td></tr><tr><td>最佳场景</td><td>日常编码、小任务</td><td>功能开发、需求管理</td><td>无人值守长任务</td><td>从零到一的完整项目</td></tr></tbody></table>Pocock Skills 最快。七个斜杠命令，灵活，全程需要人驾驶。OpenSpec 最稳，规格先行不容易跑偏，代价是每步都要人写文档。Ralph Loop 最省心——写好 prompt 就能去睡觉，醒来验收，但 prompt 质量决定一切。gstack 最重。七个阶段走完确实比前三者都慢，多花的时间花在了审查记录上——CEO 为什么砍难度曲线、工程经理为什么锁定 nextDirection 缓冲、设计师为什么坚持 HTML modal 替代 alert。六个月后另一个人重构这个游戏，读到这些记录，省下的时间远不止当初审查花掉的那几十分钟。回到第 1 章的框架：Pocock Skills 是一组工具，OpenSpec 是一份合约，Ralph Loop 是一个发动机。gstack 是一支军队。工具用在日常小任务上顺手，合约适合有规格的功能，发动机对付可以自动化验证的活，军队用在从零到一的完整项目上。<h2 id="5-7-Nanostack：gstack-的轻量级衍生"><a href="#5-7-Nanostack：gstack-的轻量级衍生" class="headerlink" title="5.7 Nanostack：gstack 的轻量级衍生"></a>5.7 Nanostack：gstack 的轻量级衍生</h2>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，保留一人多角色的核心价值，不会用流程锁住速度。<h2 id="5-8-gstack-的适用边界"><a href="#5-8-gstack-的适用边界" class="headerlink" title="5.8 gstack 的适用边界"></a>5.8 gstack 的适用边界</h2>gstack 不是万能药。有些场景它是超级武器，有些场景它是负担。<img src="/images/image-20260530010418181.png">最适合：<ul><li>从零到一的绿野项目。 没历史包袱。CEO 审查不会和已有代码冲突，工程审查不需要考虑迁移成本。gstack 在绿野项目上能满负荷运转，每一层审查都在创造价值。</li><li>需要完整治理轨迹的项目。 合规性行业、ToB 产品、开源项目的核心模块——每次 PR 都需要能追溯谁在什么时间以什么理由做了这个决定。gstack 每个阶段的输出都是天然的审计轨迹。</li><li>单人团队。 这是 gstack 最反直觉的适用场景。独立开发者没同事 review 代码，没 QA 测功能，没安全官审计漏洞。gstack 给了这个开发者二十三个虚拟同事——每个专精一个维度，在自己的领域内比开发者本人更专业。</li></ul>不适合：<ul><li>小修小补。 "把按钮颜色从蓝色换成绿色"——走完 Think → Plan → Build → Review → Test → Ship 全流程是荒谬的。gstack 的流程成本是固定的，任务越小，占比越高。</li><li>存量项目中的增量变更。 给一个二十万行代码的项目加暗黑模式，不需要 CEO 重新审产品方向。gstack 没提供像 OpenSpec 那样的增量规格机制——它的设计假设是从顶层思考开始。</li><li>需求模糊的探索性项目。 gstack 的流程要求每个阶段做出承诺。CEO 审查后方向锁定，工程审查后架构锁定。如果项目本身还在探索"到底要做什么"，流程会变成形式主义——填模板而不是做决策。</li></ul>一个实用的判断公式：任务能写出一份清晰的 PRD，gstack 值回票价。任务还在"试试看能不能 work"，先用 Pocock Skills 快速探索，方向明朗了再上 gstack。<h2 id="5-9-与前后章节的关系"><a href="#5-9-与前后章节的关系" class="headerlink" title="5.9 与前后章节的关系"></a>5.9 与前后章节的关系</h2>gstack 与 Skills（第 2 章）。 gstack 的每个专家角色本质上是披了人格外衣的 Skill。Pocock 的 <code>/grill-me</code> 和 gstack 的 <code>/office-hours</code> 做同一件事——盘问需求——但前者是通用协议，后者是有角色身份的顾问。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 的关系，就是应用程序和操作系统的关系。<h2 id="5-10-本章小结"><a href="#5-10-本章小结" class="headerlink" title="5.10 本章小结"></a>5.10 本章小结</h2>gstack 的名字来自 Garry Tan 的一句话——他本质上是一个工程经理，管理一支临时工模型大军。它的 GitHub 描述只有五个词——"open source software factory"。这两句话加起来就是 gstack 的全部：不是让 AI 变聪明，是给 AI 建一个组织架构。它的核心贡献在于把三个工业时代就有的概念用在了 AI Agent 身上：<ol><li>专业分工。 不让一个 Agent 做好所有事。CEO 不写代码，员工工程师不思考产品方向，QA 不审计安全漏洞。二十三个角色各自审查自己擅长的维度，合起来覆盖一个人工审查者覆盖不了的面。</li><li>流程门控。 "代码审查通过才能 commit"——不靠人的自觉，靠系统强制执行。gstack 用 Claude Code 的 PreToolUse hooks 做到了。在人不完美的地方，系统不该配合人的懒惰。</li><li>工件传递。 每个阶段的输出自动成为下一阶段的输入。<code>/office-hours</code> 的设计文档被 <code>/plan-eng-review</code> 读，Plan 锁定的架构被 Build 读，Build 产出的代码被 Review 读，Review 的发现被 QA 验证。一环扣一环，不靠人传话。</li></ol>这三个设计合在一起的效果是：一个人从代码生产者变成了工程管理者。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 覆盖足够多的场景，让开发者在需要时自己选对的工具。一个讲究流程集成，一个讲究工具覆盖。两个系统的对比，会是全书方法论图谱中最有意思的一段。

同分类推荐文章

Understand-Anything：代码知识图谱（2026-06-28 16:30:00）
Anthropic 官方插件：AI Agent 的领域知识插件（2026-06-28 16:00:00）
agent-skills：用生产级工程纪律武装 AI Agent （2026-06-28 15:30:00）

查看更多 AI 文章 →

建议继续学习

GitHub中的README.MD文件编写语法（累计阅读 5,596）
关于恐惧的自白（累计阅读 5,009）
GTD时间管理（累计阅读 3,791）
为什么创业公司需要写博客？（累计阅读 3,776）
一些做产品的项目经验：立项、流程、文档（累计阅读 3,682）
在公众号中优雅地呈现代码（累计阅读 3,428）
程序员如何写出一份好的文档？（累计阅读 3,361）
给明年依然年轻的我们（累计阅读 3,347）
Omi应用md2site发布-markdown转网站利器（累计阅读 3,066）
程序员为什么要学好英语（累计阅读 2,876）