Goal Workflow：目标驱动的研发闭环

<blockquote><p>&quot;你只需描述功能想法，剩下的交给工作流。&quot;</p><p>——smallnest, Goal Workflow 作者, 2026 年 5月</p></blockquote><p>三条路。gstack 覆盖从需求到交付，但你得手动驱动每个阶段。superpowers 覆盖从设计到代码，但止步于开发分支。autoresearch 覆盖从 Issue 到合入，但它假设 Issue 已经存在。每条路都只解了一段。</p><p>实际项目不是这样的。实际项目从一句&quot;我想做一个东西&quot;开始。然后你要搞清楚它是什么、设计它怎么做、拆成小块、逐块实现、审查代码、记录决策、最后合入上线。七个动作，缺一个就是断点。每个断点都是你手动接续的地方。</p><p>Goal Workflow 做的事就是把这些断点接上。不是做一个更强的 &#x2F;goal 命令。是做一条流水线——七个斜杠命令，首尾相连，从 PRD 到上线。</p><span id="more"></span><h2 id="8-1-smallnest-的两次转向"><a href="#8-1-smallnest-的两次转向" class="headerlink" title="8.1 smallnest 的两次转向"></a>8.1 smallnest 的两次转向</h2><p>smallnest 是 Go 生态里的熟面孔，rpcx 微服务框架的作者，也是本书的作者， 百度公司的网络软件架构师。2026 年上半年，他连续发布了两个 AI 研发工具——先做了 autoresearch（第 7 章），然后又做了 Goal Workflow。</p><p><img src="/images/image-20260531064324585.png"></p><p>这个顺序本身就有意思。autoresearch 追求的是全自动——你写完 Issue，脚本驱动五个 Agent 交替审查、实现、合入，十几分钟后回来看结果。他在真实项目里大量使用 autoresearch 之后，发现了全自动的问题。</p><p>不是质量问题。autoresearch 产出的代码质量不差——两到五个 Agent 交叉审查，正确性、安全性、性能都覆盖了。问题是控制。全自动意味着你在起点说了算，然后就没你的事了。PR 合入之后你才看到代码，如果 PRD 写偏了，Issue 拆错了，或者 Agent 对验收标准的理解和你不一样——你已经没有修正的机会了。</p><p>Goal Workflow 是他对这个问题的回答。既然全自动让你不安，那就把每一步的控制权还给你。但控制不等于手动——每个步骤内部仍然全自动，步骤之间留一个门，你点头了才开下一扇。</p><p>最重要的一点，autoresearch太耗token了，每一次修改都需要进行全面的review,每次review既耗时又耗token，我们不太可能像Claude Code的作者一样无限制的使用最好的LLM，我们必须考虑到成本。Goal Workflow这种单agent review 最新的变更的方式可以有效的减少token的消耗。</p><p>和前面几章不同，Goal Workflow 不跟你讲 Agent 自主性或多 Agent 轮转。它做的事更朴素：把研发流程中每一步写成一个 Skill，每个 Skill 有明确的输入、输出和质量标准。你推一步，它做完一步。推完七步，一个功能从想法变成了上线代码。</p><h2 id="8-2-安装与配置：一条-npx-命令装完全套"><a href="#8-2-安装与配置：一条-npx-命令装完全套" class="headerlink" title="8.2 安装与配置：一条 npx 命令装完全套"></a>8.2 安装与配置：一条 npx 命令装完全套</h2><p>Goal Workflow 由 smallnest 维护，代码仓库 <code>github.com/smallnest/goal-workflow</code>，官网 <a href="https://goal.rpcx.io/">goal.rpcx.io</a>。核心是一组 Markdown Skill 文件，通过 <code>npx skills</code> 分发——这是第 2 章 Skills 哲学的直接实践：用包管理工具安装 Skill，像 npm 装依赖一样。</p><h3 id="8-2-1-前提条件"><a href="#8-2-1-前提条件" class="headerlink" title="8.2.1 前提条件"></a>8.2.1 前提条件</h3><p>三条：GitHub CLI（<code>gh</code>）、Claude Code CLI（<code>claude</code>）、Node.js（提供 <code>npx</code>）。</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">brew install gh &amp;&amp; gh auth login</span><br><span class="line">npm install -g @anthropic-ai/claude-code</span><br></pre></td></tr></table></figure><p><code>gh</code> 是 <code>/ship-it</code> 和 <code>/to-issues</code>（GitHub 模式）的前置，没有它 PR 创建和 Issue 操作走不了。Claude Code 是 Skill 的运行宿主。<code>npx</code> 随 Node.js 安装，是 <code>npx skills</code> 的前提。</p><h3 id="8-2-2-安装"><a href="#8-2-2-安装" class="headerlink" title="8.2.2 安装"></a>8.2.2 安装</h3><p>安装全部 Skill（七个核心 + 七个增强，共十四个）：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">npx skills add smallnest/goal-workflow</span><br></pre></td></tr></table></figure><p><code>npx skills</code> 做四件事：拉取仓库中的 Skill Markdown 文件、注册到 Claude Code 的 skills 目录、生成对应的 <code>/</code> 斜杠命令、写入 <code>CLAUDE.md</code> 配置。</p><p>也可以只装单个 Skill：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">npx skills add smallnest/goal-workflow --skill prd</span><br></pre></td></tr></table></figure><p><code>--skill</code> 后面跟 Skill 名——<code>prd</code>、<code>prd-to-spec</code>、<code>to-issues</code>、<code>review-it</code>、<code>ship-it</code>、<code>note-it</code>、<code>humanize-it</code>、<code>listenhub-tts</code>、<code>insight-diagram</code>、<code>refactor</code>、<code>modern-go</code>、<code>code-to-spec</code>、<code>smell</code>。挑需要的装。</p><p>全局安装（所有项目共用）：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">npx skills add smallnest/goal-workflow -g</span><br></pre></td></tr></table></figure><p>指定 Agent（非 Claude Code，如 Codex）：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">npx skills add smallnest/goal-workflow -a codex</span><br></pre></td></tr></table></figure><p>Goal Workflow 的 Skill 可以在 Claude Code、Codex、OpenCode、DeepSeek TUI 四种 Agent 上运行。唯一例外是 <code>/goal</code>——它是 Claude Code 的内置命令，Skill 包里不包含它。Codex 上的等价命令是 <code>codex --goal &quot;...&quot;</code>。</p><h3 id="8-2-3-目录结构"><a href="#8-2-3-目录结构" class="headerlink" title="8.2.3 目录结构"></a>8.2.3 目录结构</h3><p>安装后，项目目录下自动生成以下结构：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br></pre></td><td class="code"><pre><span class="line">tasks/</span><br><span class="line">├── prd-[feature-name].md ← /prd 生成的 PRD 文档</span><br><span class="line">└── spec-[feature-name].md ← /prd-to-spec 生成的 SPEC（可选）</span><br><span class="line"></span><br><span class="line">.autoresearch/</span><br><span class="line">└── issues/ ← /to-issues 生成的本地 Issue 文件</span><br><span class="line"></span><br><span class="line">docs/</span><br><span class="line">├── issue#XXXX.html ← /note-it 生成的实现笔记</span><br><span class="line">├── SPEC.md ← /code-to-spec 生成的反向规格</span><br><span class="line">└── *.html ← /insight-diagram 生成的 UML 图</span><br></pre></td></tr></table></figure><p><code>tasks/</code> 放 PRD 和 SPEC，<code>.autoresearch/issues/</code> 放本地 Issue（和第 7 章的 autoresearch 共用同一套本地 Issue 系统），<code>docs/</code> 放设计文档、笔记和图。</p><h3 id="8-2-4-平台支持"><a href="#8-2-4-平台支持" class="headerlink" title="8.2.4 平台支持"></a>8.2.4 平台支持</h3><table><thead><tr><th>Agent</th><th>支持</th><th>备注</th></tr></thead><tbody><tr><td>Claude Code</td><td>全部 Skill</td><td><code>/goal</code> 内置，其余通过 Skill 包</td></tr><tr><td>Codex</td><td>全部 Skill</td><td><code>/goal</code> 内置，其余通过 Skill 包&#96;</td></tr><tr><td>OpenCode</td><td>除 <code>/goal</code> 外全部</td><td><code>/goal</code> 不适用</td></tr><tr><td>DeepSeek TUI</td><td>全部 Skill</td><td><code>/goal</code> (<code>/mubiao</code>)内置，其余通过 Skill 包</td></tr></tbody></table><p>Issue 创建支持三种平台：GitHub（<code>gh issue create</code>）、本地（<code>.md</code> 文件写入 <code>.autoresearch/issues/</code>）、百度 iCafe（<code>icafe-cli</code>）。</p><h3 id="8-2-5-升级"><a href="#8-2-5-升级" class="headerlink" title="8.2.5 升级"></a>8.2.5 升级</h3><p>重跑安装命令即可——覆盖 Skill 文件，CLAUDE.md 中的已注册命令自动更新：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">npx skills add smallnest/goal-workflow</span><br></pre></td></tr></table></figure><p>版本管理和 Skill 包注册由 <code>npx skills</code> 生态维护，Goal Workflow 本身不内置升级逻辑——这和 gstack 的 <code>/gstack-upgrade</code> 不同，更接近 OpenSpec 的 <code>openspec update</code>。</p><h2 id="8-3-流水线思维"><a href="#8-3-流水线思维" class="headerlink" title="8.3 流水线思维"></a>8.3 流水线思维</h2><p>Goal Workflow 的设计哲学和前面几章都不一样。gstack 相信角色覆盖——二十三个角色审查二十三个维度。superpowers 相信工具覆盖——十四个 Skill 覆盖十四个场景。autoresearch 相信模型覆盖——五个 Agent 交叉审查，不同模型的盲区互补。</p><p>Goal Workflow 相信的是流水线。每个工序有明确的输入、输出和质量标准。工序之间首尾相接，上游的输出是下游的输入。流水线不保证每个工序都完美。它保证的是工序之间没有裂缝。</p><p>这种思维在第 1 章就有了——&quot;在 AI 时代，你的价值不再是&#39;你能写多快的代码&#39;，而是&#39;你能不能定义清楚什么算做好&#39;。&quot;Goal Workflow 把这句话拆成了七步。PRD 定义需求的标准，SPEC 定义技术的标准，Issue 定义验收的标准，&#x2F;goal 把标准变成代码，&#x2F;review-it 验证代码是否达标，&#x2F;note-it 记录为什么这样达标，&#x2F;ship-it 把达标的代码送上生产线。每一步都问：这一阶段的&quot;做好&quot;是什么？然后让 Agent 去做到。</p><p>流水线在制造业用了一百年。把它搬到 AI 软件工程上，Goal Workflow 是第一套完整方案。前面的方法论都在解决&quot;如何让 Agent 做得更好&quot;——更好的 prompt、更好的审查、更好的模型组合。Goal Workflow 在解决另一个问题：如何让人更好地组织 Agent 的工作。与其绞尽脑汁让一个 Agent 一次性做对所有事，不如把流程切成七段，每段只要求 Agent 做好一件事。</p><h2 id="8-4-goal：流水线的引擎"><a href="#8-4-goal：流水线的引擎" class="headerlink" title="8.4 &#x2F;goal：流水线的引擎"></a>8.4 &#x2F;goal：流水线的引擎</h2><p>Goal Workflow 的流水线里，<code>/goal</code> 是唯一不在 skills 目录下的命令。它不是 smallnest 写的 Skill，是 AI 编码工具的内置功能。Goal Workflow 把它放在流水线正中心，让它成为&quot;把 Issue 变成代码&quot;的那一步。</p><p><code>/goal</code> 的概念最早来自 Codex CLI。2025 年 4 月，OpenAI 发布了 Codex CLI，首次引入了 <code>/goal</code> 斜杠命令。核心思想是&quot;声明式编程&quot;——你说目标，Agent 自己拆步骤。在这之前，AI 编码工具的交互都是&quot;指令式&quot;的：你说一步，Agent 做一步。Codex 把这个范式颠倒了过来。</p><p>Codex 之后，Claude Code 也内置了 <code>/goal</code>。到了 2026 年 5 月，Google 的 Antigravity CLI 正式发布，同样带着 <code>/goal</code> 登场。</p><p>三个工具，独立设计，三种底层模型（GPT-5、Claude 4.x、Gemini 2.5），却选择了同一个词。这不是巧合。它们都在解决同一个问题：如何让人类从&quot;指挥每一步&quot;变成&quot;定义目标，然后放手&quot;。</p><p>当然，实现各有侧重。Codex 提供了完整的生命周期管理——目标可以暂停、恢复、编辑、清除。Agent 自主但不失控，用户随时介入。Claude Code 的 <code>/goal</code> 更务实——接收 Issue 编号或文件路径，读取验收标准，端到端实现，逐条验证 checkbox。Antigravity CLI 最晚入场，吸收了前两者的经验，加上 Gemini 的长上下文优势，处理多文件项目时更从容。</p><table><thead><tr><th>维度</th><th>Codex <code>/goal</code></th><th>Claude Code <code>/goal</code></th><th>Antigravity CLI <code>/goal</code></th></tr></thead><tbody><tr><td><strong>发布时间</strong></td><td>2025 年 4 月（首个）</td><td>2026 年 5 月</td><td>2026 年 5 月</td></tr><tr><td><strong>底层模型</strong></td><td>GPT-5 &#x2F; Codex 系列</td><td>Claude 4.x</td><td>Gemini 2.5</td></tr><tr><td><strong>目标管理</strong></td><td>完整生命周期（暂停&#x2F;恢复&#x2F;编辑&#x2F;清除）</td><td>设置目标，逐条验证</td><td>完整生命周期 + Issue 联动</td></tr><tr><td><strong>验收方式</strong></td><td>目标完成判断</td><td>逐条对照 Issue checkbox</td><td>目标完成 + Issue checkbox</td></tr><tr><td><strong>安全模型</strong></td><td>默认确认执行 bash 命令</td><td>权限模式（ask&#x2F;auto）</td><td>沙箱隔离</td></tr><tr><td><strong>上下文优势</strong></td><td>代码推理</td><td>深度推理、复杂重构</td><td>长上下文、多文件项目</td></tr><tr><td><strong>最佳场景</strong></td><td>放手式自主开发</td><td>需要随时干预的开发</td><td>大型多文件项目</td></tr></tbody></table><p>和 Ralph Loop（第 4 章）比，<code>/goal</code> 是它的单次迭代实例化。核心循环一样——读需求、写代码、验证。区别在判断&quot;做完&quot;的方式。Ralph Loop 靠 completion promise 匹配——Agent 声明&quot;做完了&quot;，匹配到就停。<code>/goal</code> 靠 Issue 的 checkbox 验收标准——Agent 不自己判断，逐条对照。</p><p>Goal Workflow 的流水线在三个平台上都能跑。除了 <code>/goal</code> 这一步的调用方式不同，其余六个 Skill 完全通用。Goal Workflow 做的事是让 <code>/prd</code> 和 <code>/to-issues</code> 生成的 Issue 格式正好匹配 <code>/goal</code> 期望的输入——PRD → Issue → &#x2F;goal，三者的接口是对齐的。</p><h2 id="8-5-七个步骤"><a href="#8-5-七个步骤" class="headerlink" title="8.5 七个步骤"></a>8.5 七个步骤</h2><p>Goal Workflow 的核心流水线：</p><p><img src="/images/image-20260531064429830.png"></p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/prd → /prd-to-spec (可选) → /to-issues → /goal → /review-it → /note-it (可选) → /ship-it</span><br></pre></td></tr></table></figure><table><thead><tr><th>步骤</th><th>命令</th><th>输入</th><th>输出</th><th>角色隐喻</th></tr></thead><tbody><tr><td>1. 规划</td><td><code>/prd</code></td><td>功能描述</td><td>PRD 文档</td><td>产品经理</td></tr><tr><td>1.5 设计</td><td><code>/prd-to-spec</code></td><td>PRD 文档</td><td>技术 SPEC</td><td>架构师</td></tr><tr><td>1.6 拆解</td><td><code>/to-issues</code></td><td>PRD &#x2F; SPEC</td><td>Issue 卡片</td><td>Tech Lead</td></tr><tr><td>2. 实现</td><td><code>/goal</code></td><td>Issue 卡片</td><td>可运行的代码</td><td>开发工程师</td></tr><tr><td>3. 审查</td><td><code>/review-it</code></td><td>代码变更</td><td>通过审查的代码</td><td>代码审查者</td></tr><tr><td>3.5 记录</td><td><code>/note-it</code></td><td>已审查的代码</td><td>实现笔记 (HTML)</td><td>开发工程师</td></tr><tr><td>4. 交付</td><td><code>/ship-it</code></td><td>已审查的代码</td><td>已合入的 PR + 已关闭的 Issue</td><td>发布工程师</td></tr></tbody></table><p>七个步骤，四个角色隐喻。gstack 有二十三个角色，Goal Workflow 少得多。区别不在数量。gstack 的角色是人格化的——&quot;你是一个有十五年经验的员工工程师&quot;。Goal Workflow 的角色是功能化的——每个角色就是一个命令要做的事。你不扮演产品经理，你调用 <code>/prd</code> 让 Agent 生成 PRD。角色隐喻帮你理解命令在流程中的位置，不是让你去扮演。</p><p>两步标了&quot;可选&quot;：<code>/prd-to-spec</code> 和 <code>/note-it</code>。小功能 PRD 的验收标准就够了，不需要完整技术方案。简单实现不需要单独记录设计决策。但复杂功能少了这两步，Issue 拆解和后续维护都会受影响。</p><p>除了核心流水线，还有四个 Bonus Skills——<code>/refactor</code>、<code>/modern-go</code>、<code>/code-to-spec</code>、<code>/insight-diagram</code>——不参与流水线，各自独立使用。</p><p>下面走一遍实战。用 Goal Workflow 开发网页版贪吃蛇——同一个案例，第七种体验。每一步我会讲清楚发生了什么，以及背后的设计逻辑。</p><h2 id="8-6-第一步：一句话生成-PRD"><a href="#8-6-第一步：一句话生成-PRD" class="headerlink" title="8.6 第一步：一句话生成 PRD"></a>8.6 第一步：一句话生成 PRD</h2><p>打开 Claude Code，输入：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/prd 做一个贪吃蛇网页游戏。纯前端单文件 HTML/CSS/JS 实现。演示 AI 编码能力。</span><br></pre></td></tr></table></figure><p>Agent 没有直接开始写文档。它先问了五个问题，每个带选项：游戏复杂度（简化&#x2F;完整&#x2F;极简）、功能范围（蛇移动&#x2F;吃食物&#x2F;碰撞死亡&#x2F;最高分持久化）、技术偏好（纯单文件无框架&#x2F;轻量框架&#x2F;React）、UI 要求（简洁&#x2F;像素风&#x2F;现代）、代码质量侧重（结构清晰&#x2F;性能优先&#x2F;可维护性）。</p><p>这是 <code>/prd</code> 和 superpowers 的 brainstorming 的关键区别。superpowers 一次一个问题，逐个推进——适合需要深度讨论的探索性任务。<code>/prd</code> 一次甩出五个带选项的问题，你快速回复&quot;1B, 2ABCD, 3A, 4A, 5A&quot;，适合目标明确、只需确认细节的功能开发。</p><p>澄清完成后，Agent 生成一份 PRD，包含问题陈述、可衡量目标、User Story（每个带 checkbox 验收标准）、功能需求（编号，用&quot;系统必须&#x2F;应当&quot;）、非目标（明确不做什么）、成功度量、待确认问题。保存到 <code>tasks/prd-snake-game.md</code>。</p><p>SDD（第 3 章）说&quot;先写规格，再写代码&quot;。<code>/prd</code> 是这句话的工程化落地——你不需要掌握方法论框架，描述想法就行，Agent 产出规格文档。SDD 是施工规范，<code>/prd</code> 是规范指导下的预制构件。</p><p>贪吃蛇这个例子够简单——单文件实现，没有后端，没有 API——所以跳过 <code>/prd-to-spec</code>。但值得说一下什么时候该走这一步。</p><p><code>/prd-to-spec</code> 做的事是把&quot;做什么&quot;翻译成&quot;怎么做&quot;。PRD 说功能，SPEC 说架构、数据模型、API 设计、错误处理、安全、性能。它的产出里有两样东西最实用：Issue 映射表（把 SPEC 每个章节映射到对应 Issue，标注优先级和依赖）和验收标准映射表（每条 PRD 验收标准对应至少一个测试用例）。规格里有、代码里就有——不是靠人记忆，是靠文档的强制关联。</p><p>复杂功能值得走这一步。原因和 gstack 的 Think 阶段一样：在设计阶段找出问题，比在代码里找出问题代价低十倍。小功能跳过就行。</p><p>SPEC 有一个尴尬：写得越详细，和代码的同步成本越高。功能迭代后代码变了，谁来更新 SPEC？Goal Workflow 的答案是 <code>/code-to-spec</code>（后面会讲）——从代码逆向生成 SPEC。正向一次，逆向一次，保持同步。</p><h2 id="8-7-为什么可以跳过-prd-to-spec"><a href="#8-7-为什么可以跳过-prd-to-spec" class="headerlink" title="8.7 为什么可以跳过 prd-to-spec"></a>8.7 为什么可以跳过 prd-to-spec</h2><p>流水线图上 <code>/prd-to-spec</code> 标了&quot;可选&quot;，这不是客气。是设计。</p><p><code>/prd</code> 产出的 PRD 本身就是一份规格文档——产品级的规格。它包含 User Story（每个带 checkbox 验收标准）、功能需求（编号，用&quot;系统必须&#x2F;应当&quot;）、非目标、技术考量。这些内容已经足够让 <code>/to-issues</code> 和 <code>/goal</code> 工作了。<code>/to-issues</code> 的 SKILL 文件里写着：如果只有 PRD 没有 SPEC，直接从 User Story 生成 Issue。</p><p>不是文档不够详细所以妥协。是故意的模块化设计。</p><p>PRD 的 User Story 格式是被刻意约束过的——每个 Story 的验收标准必须是可验证的 checkbox 列表。&quot;按钮点击后弹窗出现&quot;是可验证的。&quot;用户体验良好&quot;不行。有了这个约束，PRD 的验收标准本身就能当测试用例用，不需要 SPEC 再翻译一遍。</p><p>贪吃蛇刚好说明这一点。四个 User Story，&quot;20x20 网格渲染正确&quot;&quot;蛇初始长度 3&quot;&quot;撞墙触发 game over&quot;，全是可验证的 checkbox。<code>/goal</code> 拿到就能直接实现。中间插一个 SPEC 去描述&quot;Canvas 渲染采用 requestAnimationFrame 驱动主循环&quot;，对 Agent 帮助不大，对读者负担不小。</p><p>那什么时候该走 <code>/prd-to-spec</code>？当 PRD 的 User Story 描述不了&quot;怎么做&quot;的时候。</p><p>一个典型场景：功能涉及多个服务或模块。PRD 说&quot;用户登录后看到个性化推荐&quot;，但推荐服务怎么调、缓存怎么设计、降级策略是什么——这些 PRD 管不着，得 SPEC 来约定。</p><p>另一个：有 API 设计或数据模型变更。新增接口、改数据库 schema、破坏性变更。SPEC 的 Issue 映射表在这里价值最大——把 API 端点、数据迁移、业务逻辑拆进不同的 Issue，标注依赖。</p><p>再加一个：多人并行。前后端分离，多个 Agent 同时实现不同 Issue。SPEC 是它们之间的共享合约。</p><p>功能越简单，PRD 和 SPEC 的重叠越大。贪吃蛇这个级别，PRD 已经把能说的都说了——单文件 HTML，没有后端，没有 API，没有数据库。SPEC 能补充的东西几乎为零。</p><p>反过来，功能越复杂，PRD 和 SPEC 的分工越清晰。PRD 回答&quot;用户看到什么、能做什么&quot;。SPEC 回答&quot;系统怎么做到&quot;。两者不重复，各管各的。</p><p>这也解释了 Goal Workflow 和 SDD（第 3 章）的区别。SDD 说&quot;必须先有规格再写代码&quot;，对所有功能一样。Goal Workflow 说：规格有好几层。产品规格（PRD）对所有功能都是必须的。技术规格（SPEC）只在复杂度超过阈值时才需要。阈值在哪？你读完 PRD，不确定 <code>/goal</code> 能不能独立完成的时候。</p><h3 id="PRD、设计文档、SPEC"><a href="#PRD、设计文档、SPEC" class="headerlink" title="PRD、设计文档、SPEC"></a>PRD、设计文档、SPEC</h3><p>这三个词在中国研发体系里经常混着用。理清它们的区别，才能理解为什么 Goal Workflow 选了 SPEC 而不是&quot;设计文档&quot;。</p><p><img src="/images/image-20260531064719502.png"></p><table><thead><tr><th></th><th>PRD</th><th>设计文档</th><th>SPEC</th></tr></thead><tbody><tr><td><strong>谁写</strong></td><td>产品经理</td><td>Tech Lead &#x2F; 资深工程师</td><td>架构师 &#x2F; Agent（<code>/prd-to-spec</code>）</td></tr><tr><td><strong>回答什么</strong></td><td>做什么、为什么</td><td>怎么做（叙事）</td><td>怎么做（契约）</td></tr><tr><td><strong>形式</strong></td><td>用户故事 + 验收标准</td><td>架构图 + 模块描述 + 决策理由</td><td>API Schema + 数据模型 + 错误码表</td></tr><tr><td><strong>读者</strong></td><td>全团队</td><td>开发团队</td><td>开发团队 + AI Agent</td></tr><tr><td><strong>精确度</strong></td><td>方向级</td><td>方案级</td><td>实现级</td></tr></tbody></table><p>PRD 最简单。产品经理写，用户是谁、要什么、验收标准是什么。所有人对&quot;做成什么样&quot;的理解对齐。</p><p>设计文档是中国研发体系里最常见的中间产物。Tech Lead Tech Lead 在动手前写一份，讲架构怎么设计、模块怎么拆、为什么选这个方案。叙事型的——读起来像一篇文章，&quot;我们打算这么干，理由是这些&quot;。对人友好，对机器不够友好。Agent 拿到一份设计文档，能理解意图，但没法直接执行。&quot;API 返回用户画像数据&quot;不如&quot;GET &#x2F;api&#x2F;v1&#x2F;recommendations?user_id&#x3D;{uuid} → 200 { items: [], generated_at: ISO8601 }&quot;好执行。</p><p>SPEC 不一样。它不是解释，是约定。契约型的——API 端点精确到路径和响应 Schema，数据模型精确到字段类型和约束，错误处理精确到错误码和 HTTP 状态码。人读起来啰嗦，Agent 读起来刚好。</p><p>Goal Workflow 的 <code>/prd-to-spec</code> 产出的就是这种契约型 SPEC——十一个章节，从架构到 API Schema 到错误分类到 Issue 映射表。不是让你读的（虽然你可以读），是让 <code>/to-issues</code> 拆解和 <code>/goal</code> 实现用的。PRD 给方向，SPEC 给精确坐标。</p><p>设计文档和 SPEC，本质都是把&quot;怎么做&quot;写下来。区别是读者。只有一个你和一个 Agent 在看，PRD 的验收标准就是够好的&quot;怎么做&quot;。当三个 Agent 加一个前端团队一起看，你才需要 SPEC 那份精确度。</p><h2 id="8-8-第二步：拆成-Issue"><a href="#8-8-第二步：拆成-Issue" class="headerlink" title="8.8 第二步：拆成 Issue"></a>8.8 第二步：拆成 Issue</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/to-issues</span><br></pre></td></tr></table></figure><p>Agent 自动定位刚才生成的 PRD，把四个 User Story 拆成四个 Issue：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br></pre></td><td class="code"><pre><span class="line">#1: HTML 结构与 Canvas 渲染 (frontend, high)</span><br><span class="line">#2: 游戏循环与方向控制 (frontend, high) — depends on #1</span><br><span class="line">#3: 碰撞检测与食物系统 (frontend, high) — depends on #2</span><br><span class="line">#4: 分数系统与 UI 状态 (frontend, high) — depends on #1, #2, #3</span><br></pre></td></tr></table></figure><p>拆解规则是隐式的，但可以反推出来：一个 User Story 至少一个 Issue；验收条件超过五条的 Story 拆成两到三个；太简单的合并；每个 Issue 必须能在一个 Agent 会话中独立完成。</p><p>这些规则是从 autoresearch 的经验中提炼出来的。Issue 太大，Agent 在上下文窗口里迷路。Issue 太小，启动成本高于实现成本。<code>/to-issues</code> 的粒度瞄准的就是这个区间。</p><p>Agent 展示 Issue 列表让你审核。你可以删除、合并、新增、调整优先级。确认后选择创建平台——GitHub（<code>gh</code> CLI）、本地文件、百度 iCafe——Agent 逐个调用对应 CLI，不需要手动复制粘贴。</p><p>这里有一个刻意的设计：<code>/to-issues</code> 创建的本地 Issue 文件，格式直接兼容 autoresearch 的 <code>--issues-dir</code> 参数。Goal Workflow 和 autoresearch 同作者，这种一致性不是偶然。拆解完想全自动？丢进 autoresearch。想手动逐个来？用 <code>/goal</code>。</p><h2 id="8-9-第三步：逐个实现"><a href="#8-9-第三步：逐个实现" class="headerlink" title="8.9 第三步：逐个实现"></a>8.9 第三步：逐个实现</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/goal .autoresearch/issues/issue-001-snake-game-render.md</span><br></pre></td></tr></table></figure><p>Agent 读取 Issue #1，理解验收标准——20x20 网格、初始长度 3 的蛇、Canvas 绘制。端到端实现，产出 <code>snake-game/index.html</code> 的基础结构和 Canvas 渲染层。</p><p>然后逐个推进：Issue #2 实现游戏循环和方向控制（requestAnimationFrame + 手动计时，方向缓冲防反向），Issue #3 实现碰撞检测和食物系统（随机生成、检查不重叠蛇身），Issue #4 实现分数系统和 UI（当前分&#x2F;最高分、HTML modal 弹窗、localStorage 持久化带 try-catch、空格键重置）。</p><p>这里能看出 <code>/goal</code> 的设计哲学：&quot;单次会话完成一个功能&quot;。上下文窗口里的所有内容都和当前 Issue 相关。不会出现 Ralph Loop 中上下文膨胀的问题——Issue 太大早被 <code>/to-issues</code> 拆掉了。不会出现 autoresearch 多 Issue 间依赖混乱的问题——依赖在拆解阶段就已标注，你按顺序逐个 <code>/goal</code> 就行。</p><p>和 autoresearch 比，<code>/goal</code> 是手动版。每次实现一个 Issue，你在旁边看着。autoresearch 一口气吞下所有 Issue，你喝茶睡觉。核心实现逻辑一样——读 Issue、写代码、跑测试。区别在循环由谁驱动。你驱动，是 Goal Workflow。脚本驱动，是 autoresearch。</p><h2 id="8-10-第四步：审查"><a href="#8-10-第四步：审查" class="headerlink" title="8.10 第四步：审查"></a>8.10 第四步：审查</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/review-it</span><br></pre></td></tr></table></figure><p>Agent 检测四个 &#x2F;goal 产出的代码变更，发起审查。四个维度：代码质量（命名、结构）、功能完整性（对照每个 Issue 的验收标准逐条核实）、安全性（localStorage 的 try-catch 是否在位）、性能（requestAnimationFrame 实现是否正确）。</p><p>审查发现两个问题。第一个是 modal 弹窗出现后方向键仍能控制蛇——和第 5、6 章实战中抓到的同一个问题。第二个是空格键重置后蛇状态未完全初始化。Agent 修复，重新审查，通过。</p><p><code>/review-it</code> 的审查逻辑和第 7 章 autoresearch 的质量门禁类似，但控制权在你手里。流程是：检测变更 → 发现问题 → Agent 修复 → 重新审查 → 直到无 actionable findings。支持四个 Agent——Claude Code、Codex、OpenCode、DeepSeek TUI。</p><p>审查结论是建议，不是命令。&quot;Treat review output as advisory. Never blindly apply it.&quot;Agent 对每条发现都要验证：读代码、读依赖、拒绝不合理的边界情况、拒绝过度工程化的修改。这和 gstack 的&quot;角色审查 → 你有否决权&quot;逻辑一致。自动化不是 AI 说了算，是 AI 找了问题，你判断该不该修。</p><p>审查通过的标准不是&quot;没有发现问题&quot;，是&quot;没有需要修复的问题&quot;。审查者可能提出建议但你决定不修——只要解释清楚为什么不修，就是通过。</p><h2 id="8-11-第五步：记录设计决策"><a href="#8-11-第五步：记录设计决策" class="headerlink" title="8.11 第五步：记录设计决策"></a>8.11 第五步：记录设计决策</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/note-it</span><br></pre></td></tr></table></figure><p>Agent 回顾四个 Issue 的实现过程，记录四条设计决策：为什么用 requestAnimationFrame 而非 setInterval（帧同步精度）、为什么方向缓冲不在键盘事件中直接更新（防止一帧内多次转向）、为什么 localStorage 用 try-catch 包裹（隐私模式兼容）、为什么 modal 弹窗出现时拦截所有键盘事件（防止死蛇漂移）。</p><p>输出是一份 HTML，存在 <code>docs/issue#0001.html</code>。设计得很轻——四条彩色标签，每条对应一个类别：设计决策、偏离、权衡、待确认。空类别直接写&quot;None&quot;。</p><p>代码能告诉你&quot;怎么做&quot;，但很难告诉你&quot;为什么这样做&quot;。<code>/note-it</code> 填补这个空白。smallnest 把它放在 <code>/review-it</code> 之后、<code>/ship-it</code> 之前，位置是有意的：审查通过意味着代码质量合格，此时回头记录设计决策，既不受审查来回修改的干扰，也不会被交付后的遗忘抹掉。</p><p>还有一个容易被忽略的价值：这些记录对 AI Agent 的后续维护极其有用。Agent 下次修改相关代码时，读到 <code>docs/issue#0042.html</code> 就能理解当初的设计考量。注释在代码里，只能解释当前实现。设计笔记记录的是&quot;当初还有别的选择，为什么没选&quot;。Agent 知道什么路试过但死了，就不会再试一次。</p><h2 id="8-12-第六步：交付"><a href="#8-12-第六步：交付" class="headerlink" title="8.12 第六步：交付"></a>8.12 第六步：交付</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/ship-it</span><br></pre></td></tr></table></figure><p>Agent 执行六步机械操作：创建分支 → 暂存相关文件（不混入无关变更）→ commit message 关联 Issue 编号 → 推送 → 创建 PR → squash merge → 删除分支 → 在 Issue 上添加实现总结评论。</p><p>和第 7 章 autoresearch 的收尾逻辑一样：传统 CI 到&quot;代码能跑&quot;就停了，PR 创建、等待 CI、合并、关闭 Issue 都要人手动做。每一步都是延迟和出错的机会。<code>/ship-it</code> 把它们全部自动化。</p><p>但有一个区别：<code>/ship-it</code> 需要你明确调用。autoresearch 在第 4 轮评分达标后自动合入——你不说合，它也合了。Goal Workflow 把控制权留给你——走完 <code>/review-it</code>，确认没问题，再敲 <code>/ship-it</code>。多一步手动，少一次意外合入。</p><p>PR 合入后，Agent 在 Issue 上评论一条总结——核心变更、PR 编号、commit hash。Issue 变成了可回溯的功能档案：Issue → PR → Commit → Code → Note，完整的一条链。</p><h2 id="8-13-实战：用-Goal-Workflow-开发网页版贪吃蛇"><a href="#8-13-实战：用-Goal-Workflow-开发网页版贪吃蛇" class="headerlink" title="8.13 实战：用 Goal Workflow 开发网页版贪吃蛇"></a>8.13 实战：用 Goal Workflow 开发网页版贪吃蛇</h2><p>本书每一章都用贪吃蛇作为实战案例。这是第七种体验——不是跑一条命令，不是写一个 Issue，而是走完一条完整流水线。</p><h3 id="8-13-1-第一步：-prd-生成需求文档"><a href="#8-13-1-第一步：-prd-生成需求文档" class="headerlink" title="8.13.1 第一步：&#x2F;prd 生成需求文档"></a>8.13.1 第一步：&#x2F;prd 生成需求文档</h3><p>在 Claude Code 中输入：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">/prd 做一个贪吃蛇网页游戏。方向键控制蛇移动，吃食物变长得分，</span><br><span class="line">撞墙或撞自己结束。纯前端单文件，最高分 localStorage 持久化。</span><br></pre></td></tr></table></figure><p>Agent 追问三个澄清问题：</p><blockquote><p><strong>Q1:</strong> 游戏画布多大？我建议 400×400px，20×20 网格——桌面端和移动端都够用。<br><strong>Q2:</strong> 蛇的移动速度？推荐 150ms&#x2F;步，有挑战但不至于太快。<br><strong>Q3:</strong> 游戏结束的交互？HTML modal 弹窗 + 重新开始按钮，比 alert() 好。</p></blockquote><p>用户逐一确认。Agent 产出 <code>tasks/prd-snake-game.md</code>，核心内容：四条用户故事（移动控制、食物消费、碰撞结束、最高分持久化），八条验收标准（全部 checkbox 格式），非目标明确标注（不加难度曲线、音效、排行榜）。</p><p>因为没有跨服务改动和合规需求，跳过 <code>/prd-to-spec</code>，直接进入拆解。</p><h3 id="8-13-2-第二步：-to-issues-拆解"><a href="#8-13-2-第二步：-to-issues-拆解" class="headerlink" title="8.13.2 第二步：&#x2F;to-issues 拆解"></a>8.13.2 第二步：&#x2F;to-issues 拆解</h3><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/to-issues tasks/prd-snake-game.md</span><br></pre></td></tr></table></figure><p>Agent 将 PRD 拆成四个 Issue，每个 Issue 的验收标准相互独立：</p><table><thead><tr><th>Issue</th><th>标题</th><th>验收标准</th><th>预估</th></tr></thead><tbody><tr><td>#1</td><td>Canvas 渲染与蛇的初始状态</td><td>20×20 网格 + 绿色蛇 + 红色食物</td><td>20min</td></tr><tr><td>#2</td><td>方向键控制与 150ms 游戏循环</td><td>四方向移动 + 禁止反向 + nextDirection 缓冲</td><td>25min</td></tr><tr><td>#3</td><td>碰撞检测与食物系统</td><td>墙壁&#x2F;自身碰撞 + 食物消费 + 随机生成不重叠</td><td>25min</td></tr><tr><td>#4</td><td>分数系统与游戏状态管理</td><td>当前分&#x2F;最高分 + modal 弹窗 + localStorage 降级</td><td>20min</td></tr></tbody></table><p>用户确认拆分合理，四个 Issue 在本地 <code>.autoresearch/issues/</code> 目录下生成。</p><h3 id="8-13-3-第三步：-goal-逐个实现"><a href="#8-13-3-第三步：-goal-逐个实现" class="headerlink" title="8.13.3 第三步：&#x2F;goal 逐个实现"></a>8.13.3 第三步：&#x2F;goal 逐个实现</h3><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/goal .autoresearch/issues/issue-001-snake-canvas.md</span><br></pre></td></tr></table></figure><p>Agent 读取 Issue #1，分析项目结构（纯前端，无框架），生成 <code>snake-game/index.html</code>，包含 Canvas 和渲染函数。跑测试，验收标准逐条验证——网格可见 ✓，蛇初始位置正确 ✓。Issue #1 完成。</p><p>依次执行 #2、#3、#4。和第 4-7 章贪吃蛇实现不同的是，Goal Workflow 的实现过程少了一类问题：Agent 在 #2 中就实现了 <code>nextDirection</code> 缓冲机制——因为 <code>/to-issues</code> 拆解时，Agent 读 PRD 中的技术要求（&quot;键盘事件写入 nextDirection 缓冲&quot;），直接写进了 Issue #2 的验收标准里。</p><p>四个 Issue 全部实现完毕，通过，约 6 分钟。</p><h3 id="8-13-4-第四步：-review-it-审查"><a href="#8-13-4-第四步：-review-it-审查" class="headerlink" title="8.13.4 第四步：&#x2F;review-it 审查"></a>8.13.4 第四步：&#x2F;review-it 审查</h3><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/review-it</span><br></pre></td></tr></table></figure><p>Agent 检测到分支上有未合入的 commit，运行 <code>--mode branch</code>，对比 <code>origin/main...HEAD</code>。审查发现两条：</p><blockquote><p><strong>发现 #1:</strong> <code>#3</code> 中食物随机生成逻辑在蛇身长度超过 200 格时（极端情况）会退化为线性扫描全网格——O(n²)。当前 20×20 网格不会触发，但可读性差。建议改为 Fisher-Yates 洗牌 + pick first。<strong>Auto-fix。</strong></p><p><strong>发现 #2:</strong> <code>#4</code> 中 <code>loadHighScore()</code> 的 try-catch 只处理了 <code>SecurityError</code>，没有处理 <code>QuotaExceededError</code>——Firefox 隐私模式下 <code>setItem</code> 可能抛这个异常。<strong>手动确认修复。</strong></p></blockquote><p>用户确认修复 #2。Agent 修改代码，重新跑测试——全部通过。</p><h3 id="8-13-5-第五步：-ship-it-交付"><a href="#8-13-5-第五步：-ship-it-交付" class="headerlink" title="8.13.5 第五步：&#x2F;ship-it 交付"></a>8.13.5 第五步：&#x2F;ship-it 交付</h3><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/ship-it</span><br></pre></td></tr></table></figure><p>Agent 执行：git add + commit → push → gh pr create → squash merge → comment → close Issue。约 40 秒走完。</p><p>贪吃蛇的完整功能档案留在仓库里：<code>tasks/prd-snake-game.md</code>（为什么做）→四个 Issue（每一步要验证什么）→ PR #43（代码变更）→ <code>docs/issue#43.html</code>（设计决策记录）。</p><p>跟前面六章比，Goal Workflow 的贪吃蛇开发全程约 15 分钟，比 autoresearch 的 3 分钟写 Issue + 12 分钟自动执行总共差不多。但人在每一步之间参与了四次——PRD 确认、Issue 拆分确认、审查修复确认、交付确认。每次参与花几秒钟，换来了每一跳的质量确认。</p><h2 id="8-14-七种方法的同一个案例"><a href="#8-14-七种方法的同一个案例" class="headerlink" title="8.14 七种方法的同一个案例"></a>8.14 七种方法的同一个案例</h2><p>同一个贪吃蛇，四种方法论的对比：</p><table><thead><tr><th>维度</th><th>gstack（第 5 章）</th><th>superpowers（第 6 章）</th><th>autoresearch（第 7 章）</th><th>Goal Workflow（本章）</th></tr></thead><tbody><tr><td><strong>人类参与</strong></td><td>逐个阶段运行命令，约 2 小时</td><td>回答 5 个设计问题，约 5 分钟</td><td>写一个 Issue，约 3 分钟</td><td>每个步骤确认一下，约 8 分钟</td></tr><tr><td><strong>流程驱动</strong></td><td>人驱动（手动调用每个阶段）</td><td>Agent 驱动（自动触发 Skill）</td><td>脚本驱动（全自动）</td><td>人驱动（手动调用每个命令）</td></tr><tr><td><strong>覆盖范围</strong></td><td>从想法到交付</td><td>从设计到代码</td><td>从 Issue 到合入</td><td>从想法到上线</td></tr><tr><td><strong>控制粒度</strong></td><td>粗粒度（Sprint 阶段）</td><td>细粒度（Skill 自动触发）</td><td>无控制（全自动）</td><td>中粒度（每个命令确认一下）</td></tr><tr><td><strong>产出质量</strong></td><td>高（角色全覆盖）</td><td>中高（工程维度强）</td><td>中高（依赖 Issue 质量）</td><td>高（每个步骤有明确标准）</td></tr><tr><td><strong>最佳场景</strong></td><td>从零到一的完整项目</td><td>中等复杂度的独立功能</td><td>Issue 明确、可独立验证的功能</td><td>需要完整流程但保留控制权的项目</td></tr></tbody></table><p>Goal Workflow 的参与时间比 autoresearch 长（约 8 分钟 vs 约 3 分钟），但每个参与点都有意义——PRD 生成后确认需求正确，Issue 拆解后确认拆分合理，审查通过后确认质量满意。这些确认不是流程冗余，是质量门禁。</p><p>和第 3-7 章的关系：</p><p>SDD（第 3 章）说&quot;先规格、后代码&quot;，Goal Workflow 给了你两个生成规格的命令。SDD 的规格是人机合约，Goal Workflow 的 PRD&#x2F;SPEC 不仅是人机合约，也是流水线步骤之间的合约——PRD 定义了 <code>/to-issues</code> 的输入标准，SPEC 定义了 <code>/goal</code> 的技术约束。</p><p>Ralph Loop（第 4 章）通过 completion promise 判断&quot;做没做完&quot;——Agent 自我声明。<code>/goal</code> 通过 Issue 验收标准判断——测试结果告诉你做没做完。前者适合验收标准就是一句话的简单任务，后者适合 checkbox 列表的结构化任务。</p><p>gstack（第 5 章）和 Goal Workflow 都是串行流程——七个 Sprint 阶段 vs 七个流水线步骤。核心区别在谁驱动。gstack 是角色驱动（&quot;你是一个产品经理&quot;），Goal Workflow 是命令驱动（&quot;现在生成 PRD&quot;）。前者适合不知道标准流程的开发者，后者适合知道每一步该做什么、只需要工具加速的开发者。</p><p>autoresearch（第 7 章）是同一个作者的另一种设计哲学——脚本驱动，你写 Issue，脚本跑 Agent，评分，合入。Goal Workflow 是人驱动——你调命令，Agent 执行，你确认。前者追求自动化程度，后者追求控制力。</p><h2 id="8-15-适用边界"><a href="#8-15-适用边界" class="headerlink" title="8.15 适用边界"></a>8.15 适用边界</h2><p>Goal Workflow 是为中小型项目设计的。从功能规划到上线一条龙，每个步骤有明确的质量标准，不需要自己设计流程。PRD 和 SPEC 天然适合多人协同——它们是产品和研发之间、前端和后端之间、开发和审查之间的合约。</p><p><img src="/images/image-20260531065006660.png"></p><p>如果你不信任全自动——autoresearch 的&quot;一觉醒来一排 merged&quot;让你不安——Goal Workflow 就是给你的。每个步骤结束时审核产出，通过再推进。如果你接手了一个没有文档的老项目，<code>/code-to-spec</code> 快速生成技术说明，然后走标准流水线规划改动。</p><p>但它不是万能药。</p><p>改个按钮颜色走 <code>/prd</code> → <code>/to-issues</code> → <code>/goal</code> → <code>/review-it</code> → <code>/ship-it</code>，流程成本高于实现成本。Pocock Skills 或直接让 Agent 修更合适。探索性原型——&quot;试试这个方案行不行&quot;——需要人的判断，不适合规格化流水线。紧急热修复更不行——流水线是串行的，每步都要人确认，线上故障等不了。</p><p>最常被问到的问题：Goal Workflow 和 autoresearch 怎么选？</p><p>选 Goal Workflow，如果你想要控制。每一步做完你看一眼。PRD 写偏了你马上纠正。Issue 拆大了你拆开。审查发现的问题你决定修不修。</p><p>选 autoresearch，如果你想要时间。Issue 写好后放手，十几分钟后回来看结果。信任 Agent 的判断——信任它不会在验收标准上摇摆，信任多 Agent 审查能覆盖盲区。</p><p>两者不互斥。你可以用 <code>/prd</code> + <code>/to-issues</code> 生成 Issue，丢进 autoresearch 全自动实现。也可以用 <code>/prd</code> + <code>/to-issues</code> + <code>/goal</code> 手动实现前几个关键 Issue，再 autoresearch 批量跑剩下的。流水线是模块化的——每一环都能独立使用。</p><h2 id="8-16-本章小结"><a href="#8-16-本章小结" class="headerlink" title="8.16 本章小结"></a>8.16 本章小结</h2><p>把第 4-8 章放在一起看，五条路线对应五种研发组织模式。Ralph Loop 是循环自治——Agent 反复迭代到正确。gstack 是角色治理——二十三个虚拟角色覆盖质量全维度。superpowers 是技能触发——Agent 自动激活对的工具。autoresearch 是全自动流水线——人类只定义目标。Goal Workflow 是手动流水线——人类推一下，Agent 走一步，每一步的质量都经过人的确认。</p><p>没有高下之分。它们都在回答同一个问题：在 AI 能写代码的时代，人应该做什么？</p><p>autoresearch 的回答是：人定义目标，然后放手。Goal Workflow 的回答是：人定义每个阶段的&quot;做好&quot;，然后确认。前者相信你一次能写清楚，后者相信你看了才知道对不对。</p><p>选哪个，取决于你对自己&quot;能一次写清楚到什么程度&quot;和&quot;愿意参与多少步骤&quot;的诚实判断。</p><p>下一章讲方法论对比与融合。前八章讲了八种方法论，各有优劣，互有重叠。第 9 章把八条路放在一起，帮你找到最适合自己的那条——或者把几条路拼在一起。</p>