方法论对比与融合

<blockquote><p>&quot;小孩子才做选择题，成年人当然全都要&quot;</p><p>——网络梗</p></blockquote><p>前八章覆盖了七条路线。</p><p>Pocock Skills 拆能力。OpenSpec 写规格。Ralph Loop 自己循环到对。gstack 用角色覆盖质量。superpowers 让 Agent 替你选工具。autoresearch 一口气自动到合入。Goal Workflow 串成七步，每步等你说过。</p><p>每条路都能走通。真实项目从来不只走一条。Ralph Loop 做实现，谁来审查？gstack 走流程，需求从哪来？autoresearch 全自动跑，Issue 谁拆的？</p><p>贪吃蛇案例已经验证了这一点。第 5 章 gstack 走了七个 Sprint 阶段，手工推着走，约两小时。第 6 章 superpowers 后台监听关键词，你答了五个设计问题，约五分钟。第 7 章 autoresearch 你写了一个 Issue，约三分钟，然后等结果。第 8 章 Goal Workflow 每步确认一下，从 PRD 到上线，约八分钟。</p><p>同一个贪吃蛇，同一个产出，四种交互模式。</p><p>本章把七条路摊开，看它们怎么拼。</p><span id="more"></span><h2 id="9-1-一张表看完七种方法论"><a href="#9-1-一张表看完七种方法论" class="headerlink" title="9.1 一张表看完七种方法论"></a>9.1 一张表看完七种方法论</h2><table><thead><tr><th></th><th>Pocock Skills</th><th>OpenSpec</th><th>Ralph Loop</th><th>gstack</th><th>superpowers</th><th>autoresearch</th><th>Goal Workflow</th></tr></thead><tbody><tr><td><strong>核心机制</strong></td><td>原子 Skill</td><td>变更提案</td><td>自主循环</td><td>角色审查</td><td>自动触发</td><td>多 Agent 评审</td><td>串行流水线</td></tr><tr><td><strong>覆盖范围</strong></td><td>单任务</td><td>需求→代码</td><td>实现</td><td>需求→交付</td><td>设计→代码</td><td>Issue→合入</td><td>PRD→上线</td></tr><tr><td><strong>人类参与</strong></td><td>每次调用</td><td>提案+审核</td><td>设 prompt</td><td>每阶段确认</td><td>设设计问题</td><td>写 Issue</td><td>每步确认</td></tr><tr><td><strong>控制粒度</strong></td><td>细</td><td>中</td><td>粗</td><td>粗</td><td>细</td><td>无</td><td>中</td></tr><tr><td><strong>自动化程度</strong></td><td>低</td><td>中</td><td>高</td><td>中</td><td>中高</td><td>极高</td><td>中高</td></tr><tr><td><strong>模型依赖</strong></td><td>无</td><td>无</td><td>无</td><td>无</td><td>无</td><td>依赖多模型</td><td>无</td></tr><tr><td><strong>中文适配</strong></td><td>无</td><td>spec-kit-zh</td><td>无</td><td>无</td><td>superpowers-zh</td><td>无</td><td>iCafe 支持</td></tr><tr><td><strong>安装复杂度</strong></td><td>低</td><td>中</td><td>中</td><td>低</td><td>低</td><td>中</td><td>低</td></tr><tr><td><strong>最佳场景</strong></td><td>单点任务</td><td>有规格意识</td><td>放手式实现</td><td>从零到一</td><td>中等功能</td><td>Issue 明确</td><td>完整控制</td></tr></tbody></table><p>扫完这张表，几条规律浮现出来。往右，覆盖范围变大。往下，控制变粗。</p><p>也有反直觉的数据点。autoresearch 自动化程度最高，覆盖不如 Goal Workflow——它从 Issue 起步，不管需求和拆解。Goal Workflow 从 PRD 覆盖到上线，但每步都等人。自动化和覆盖不是正相关：覆盖看流程设计，自动化看控制权分配。</p><p>还有一个数据点。Pocock Skills 和 superpowers 都是&quot;原子 Skill&quot;，但 superpowers 自动化更高。区别不在 Skill 定义，在触发机制。Pocock Skills 等开发者主动调用——测试写完了吗？跑一下 lint 吧。superpowers 后台监听关键词，干活时自动激活。同样的东西，加个触发机制就改变了交互节奏。第 6 章里 superpowers 自动跑 lint 和 test 的那一刻，开发者甚至没意识到它在工作，直到它报错。</p><p>再看安装复杂度那一行。最低的三个——Pocock Skills、superpowers、Goal Workflow——覆盖了完全不同的三种场景：单点任务、中等功能、完整控制。安装成本和方法论的野心不成正比。</p><p>控制粒度那一行，Pocock 和 superpowers 都是&quot;细&quot;粒度，一个手动一个自动。gstack 和 Ralph Loop 都是&quot;粗&quot;粒度，一个靠角色驱动，一个靠循环收敛。细粒度让开发者捏住每一步，粗粒度让开发者只看结果。</p><h2 id="9-2-它们在回答同一个问题"><a href="#9-2-它们在回答同一个问题" class="headerlink" title="9.2 它们在回答同一个问题"></a>9.2 它们在回答同一个问题</h2><p>把七条路的设计摊在一起，你会发现它们都在回答：</p><p><strong>AI 能写代码了。人干什么？</strong></p><p>答案不是七个。是一条光谱，从左到右，人介入越来越少。</p><p><img src="/images/image-20260531043146883.png"></p><p>► Pocock Skills 在最左端。人做每一步。</p><p>每个 Skill 是一个场景的 SOP，你封装最佳实践成指令，AI 执行。要测试了，调 test skill。要提交了，调 git skill。要重构了，调 refactor skill。什么时候用什么，你判断。</p><p>第 2 章里 Pocock 在直播中演示过用 test skill 自动生成测试。代码写完，一个命令，测试就出来了。AI 不会漏边界条件。</p><hr><p>► 往右一步，人不再做每一步，只在关键节点把关。</p><p>OpenSpec 和 Goal Workflow 都在这个位置。都要求人在决策节点介入，中间的执行自动完成。</p><p>OpenSpec 让你在代码之前写规格。先定义&quot;对长什么样&quot;，再让 AI 实现。propose 阶段审核提案，apply 阶段 AI 执行，archive 阶段确认归档。三张牌 proposal.md、tasks.md、design.md 管住了一个变更的完整生命周期。第 3 章的 SDD 理念是它的理论基础：规格是人机之间的合约，合约签好了，执行可以放手。</p><p>Goal Workflow 让你在七个流水线步骤之间把关。&#x2F;prd 产出的需求你确认了，才进 &#x2F;to-issues。&#x2F;to-issues 拆出的 Issue 你审核了，才进 &#x2F;goal。&#x2F;review-it 发现的问题你决定修不修，&#x2F;ship-it 你敲了才合。第 8 章里 smallnest 从 autoresearch 转向 Goal Workflow 的原因就是这个，全自动让他不安。&quot;一觉醒来一排 merged&quot;，代码已经在主干上了，PRD 写偏了也没机会纠正。</p><p>两者信的是同一件事：在决策点介入比在执行中参与更高效。不是在 Agent 写代码时指手画脚，而是开始写之前说清楚&quot;对是什么&quot;，写完以后确认&quot;确实是对的&quot;。</p><hr><p>► 再往后一步。人不直接管执行了，转去定义角色和规则，让 Agent 互相审查。</p><p>gstack 的代表作是二十三个虚拟角色。产品经理、架构师、安全专家、性能工程师、数据库管理员，各有各的审查维度。&quot;你是一个有十五年经验的员工工程师，审查这份代码的安全问题&quot;和&quot;review this code for security&quot;的区别，第 5 章实测过。前者能发现上下文相关的逻辑漏洞，后者只能看到 SQL 注入。角色不是噱头，是审查深度。</p><p>superpowers 走另一条路。十四个 Skill 覆盖十四个场景，你不需要判断&quot;现在该用哪个工具&quot;，Agent 自己听关键词触发。但它不止于自动触发。第 6 章的 brainstorming 是它最独特的东西，Agent 反问设计问题，每次一个，逐步逼近方案。和 <code>/prd</code> 一次甩五个带选项的问题完全不同。前者适合探索，后者适合目标明确的功能开发。</p><p>gstack 和 superpowers 各有一个盲区。gstack 需要你手动驱动每个阶段，&quot;现在进入 Think 阶段&quot;&quot;现在进入 Explore 阶段&quot;。superpowers 自动触发但止步于开发分支，不管你 PR 合不合、Issue 关不关。它们覆盖了流程中不同的空缺。</p><hr><p>► 快到尽头了。人连规则都不设了，只给一句验收标准。</p><p>Ralph Loop 是这个位置的代表。核心机制简单到一句话：设一个 completion promise，Agent 自己循环实现、测试、修复，直到 promise 匹配或达到循环上限。第 4 章的 <code>test-then-commit</code>，&quot;当所有测试通过且没有 lint 错误时，提交代码&quot;。</p><p>和 <code>/goal</code> 比，Ralph Loop 更轻。不需要 Issue，不需要 checkbox 列表，一句验收标准就够。&quot;确认路径已更新，服务正常&quot;，Ralph Loop 能搞定。但复杂任务需要结构化验收时，<code>/goal</code> 的逐条 checkbox 对照更靠谱。两者互补。小任务一句话闭环，大任务逐条验收。</p><hr><p>► 光谱最右端。人只管两头，中间全自动。</p><p>autoresearch 在这个位置。写清楚 Issue 和验收条件，走人。脚本驱动五个 Agent 交替实现和审查，评分够了自动合入。第 7 章的实战数据，四个 Issue 的贪吃蛇变体在十几分钟内全部合入。</p><p>但它有一个被忽略的前提：Issue 必须写对。五个 Agent 能交叉审查代码质量、安全、性能，不质疑 Issue 本身。你写&quot;实现一个登录功能&quot;，Agent 就实现登录。但登录要不要二次验证？要不要 OAuth？要不要记住我？这些不在审查范围里。</p><p>smallnest 后来做 Goal Workflow，部分原因就是这个。他发现写 Issue 时已经需要想清楚架构了，Issue 质量决定了 autoresearch 的产出。与其把思考压缩成一份 Issue，不如把思考过程展开。PRD 管需求，SPEC 管技术，Issue 管实现，每一步可回溯。</p><hr><p>► 光谱不是好坏表。是舒服区。</p><p>没人应该永远待在一个位置。一个项目里，核心模块走 Goal Workflow 全流程，PRD → SPEC → Issue → &#x2F;goal → &#x2F;review-it → &#x2F;ship-it。辅助脚本丢给 Ralph Loop，一句&quot;测试全过就行&quot;。文档更新用 autoresearch，写完 Issue 就不用管了。日常编码靠 superpowers 在后台干活。</p><p>第 8 章 smallnest 讲过，选哪个，取决于你对自己&quot;能一次写清楚到什么程度&quot;和&quot;愿意参与多少步骤&quot;的诚实判断。不是方法论之间的选择，是你对自己工作方式的理解。</p><h2 id="9-3-它们怎么拼"><a href="#9-3-它们怎么拼" class="headerlink" title="9.3 它们怎么拼"></a>9.3 它们怎么拼</h2><h3 id="9-3-1-规格层：OpenSpec-Goal-Workflow"><a href="#9-3-1-规格层：OpenSpec-Goal-Workflow" class="headerlink" title="9.3.1 规格层：OpenSpec + Goal Workflow"></a>9.3.1 规格层：OpenSpec + Goal Workflow</h3><p>OpenSpec 管变更级，每个 PR 一个 proposal，包含改什么、为什么、怎么验证。Goal Workflow 管项目级，PRD 管需求，SPEC 管技术方案，Issue 管实现单元。一个微观，一个宏观。</p><p>拿支付模块举例。Goal Workflow 的 <code>/prd</code> 产出整体需求：用户下单、微信支付、退款、账单。<code>/prd-to-spec</code> 产出技术方案：支付接口设计、数据库 schema、错误处理策略。<code>/to-issues</code> 拆成十个 Issue。每个 Issue 内部，如果用 OpenSpec 管变更，比如 Issue #3 &quot;接入微信支付 API&quot;涉及三个文件，propose 阶段写一份 proposal.md 说清楚改什么，apply 阶段 AI 执行，archive 阶段归档。</p><p>Goal Workflow 的 SPEC 有 Issue 映射表，OpenSpec 的 proposal 有 tasks.md。两层规格首尾相接。SPEC 告诉你这个大功能有哪些小块，proposal 告诉你这个小块怎么改。</p><h3 id="9-3-2-实现层：Ralph-Loop-goal"><a href="#9-3-2-实现层：Ralph-Loop-goal" class="headerlink" title="9.3.2 实现层：Ralph Loop + &#x2F;goal"></a>9.3.2 实现层：Ralph Loop + &#x2F;goal</h3><p>Ralph Loop 适合一句话能说清的任务，设个 completion promise，Agent 自己跑到满足。<code>/goal</code> 适合 checkbox 列表的任务，逐条对照验收。</p><p>真实项目里两种都有。还是支付模块。Issue #7 &quot;写一个生成订单号的工具函数&quot;，验收标准就一条：返回 32 位不重复字符串，带时间戳前缀。丢给 Ralph Loop，completion promise 写&quot;函数通过单元测试&quot;。Agent 写好、跑测试、通过、提交。全过程你没看。</p><p>Issue #3 &quot;接入微信支付 API&quot;不一样。验收标准有七条：统一下单、支付回调验签、超时关单、退款接口、异常重试策略、日志记录、幂等处理。用 <code>/goal</code>，Agent 逐条实现，你逐条看到 checkbox 勾上。</p><h3 id="9-3-3-审查层：gstack-review-it"><a href="#9-3-3-审查层：gstack-review-it" class="headerlink" title="9.3.3 审查层：gstack + &#x2F;review-it"></a>9.3.3 审查层：gstack + &#x2F;review-it</h3><p>gstack 用二十三个角色看一个变更，看得深。<code>/review-it</code> 用四个维度看一个变更，看得快。</p><p>大版本发布前跑 gstack 全维度。支付模块上线前，安全专家的角色发现退款回调的签名验证没有防重放攻击。这个漏洞 <code>/review-it</code> 的静态检查抓不到，它不是代码质量或常见安全问题，是业务逻辑的设计缺陷。&quot;你是一个有十五年经验的支付安全专家&quot;，这个 prompt 让 Agent 想了它本来不会想的事。</p><p>日常开发用 <code>/review-it</code> 做增量。改了个配置文件，三秒扫完四个维度，没有 actionable findings，直接 <code>/ship-it</code>。为这个跑二十三角色全维度不值得。</p><p>第 5 章里 gstack 强调过：角色的价值不在数量，在视角。二十三个角色就是二十三个视角。<code>/review-it</code> 的价值在速度，一个命令覆盖四个维度，不用手动指定审查角色。</p><p>支付模块十个 Issue。Issue #1 &quot;数据库表结构&quot;、Issue #10 &quot;生成 API 文档&quot;、Issue #8 &quot;单元测试补充&quot;，独立性强，出错了也不影响核心流程，丢进 autoresearch。你写完 Issue 去开会，回来三个 PR 已经合入。</p><p>Issue #3 &quot;接入微信支付 API&quot;、Issue #4 &quot;退款流程&quot;，核心交易链路，用 <code>/goal</code> 手动逐个来。每步写完看一眼，确认支付回调的签名逻辑对了，退款的状态机没有漏洞。</p><p>这个组合能成立，是因为 <code>/to-issues</code> 产出的 Issue 格式同时兼容两条路。同一个 Issue 文件，丢给 <code>/goal</code> 就是手动单步，丢给 autoresearch 就是全自动。不是两套流程，是一套输入两个出口。</p><p>什么时候走哪个出口，判断标准也简单。这个 Issue 做错了会怎样？丢了钱、丢了数据、用户投诉——走 <code>/goal</code>。只是个工具函数、文档更新、测试补充——走 autoresearch。风险和控制的权衡，不该由方法论替你决定。</p><p>全流程控制和全自动加速不是非此即彼。是你判断哪些值得控制，哪些值得加速。</p><h3 id="9-3-4-能力单元层：Pocock-Skills-superpowers-Goal-Workflow-Bonus"><a href="#9-3-4-能力单元层：Pocock-Skills-superpowers-Goal-Workflow-Bonus" class="headerlink" title="9.3.4 能力单元层：Pocock Skills + superpowers + Goal Workflow Bonus"></a>9.3.4 能力单元层：Pocock Skills + superpowers + Goal Workflow Bonus</h3><p>三套 Skill，组织方式各不一样。</p><p>Pocock 散装，自己挑。superpowers 自动触发，Agent 判断时机。Goal Workflow Bonus 是独立工具集，<code>/refactor</code>、<code>/modern-go</code>、<code>/code-to-spec</code>，需要时才调。</p><p>日常编码靠 superpowers 自动激活测试和 lint。你改了一个函数，保存，Agent 静默跑测试。没过，报错。你修。保存，测试通过。全程没手动调 skill，superpowers 在后台干的。</p><p>但有些场景 superpowers 覆盖不到。你要把项目从 Go 1.16 升到 1.22，35+ 条 API 变更规则，superpowers 没有这个领域知识。这时候调 Goal Workflow Bonus 的 <code>/modern-go</code>，一次性批量现代化。Pocock 的精品 Skill 同理，他的 Git skill 能自动生成 conventional commits 格式的提交信息。</p><p>三套东西不冲突，但有个容易踩的坑：同一类任务装了两套 Skill。比如 superpowers 已经有自动测试了，你又装了 Pocock 的 test skill。它们不会打架，但你会在两个地方看到测试结果——一个自动弹出的，一个手动触发的。时间长了你会只信其中一个，另一个变成噪音。装之前想清楚：这个场景你是想让 Agent 自动判断，还是自己决定什么时候调。</p><h2 id="9-4-不同场景的推荐组合"><a href="#9-4-不同场景的推荐组合" class="headerlink" title="9.4 不同场景的推荐组合"></a>9.4 不同场景的推荐组合</h2><p>不同的场景和团队规模下，你可以选择一个或者多个合适的工具&#x2F;开发流程。</p><p><img src="/images/image-20260531043524131.png"></p><h3 id="9-4-1-个人开发者"><a href="#9-4-1-个人开发者" class="headerlink" title="9.4.1 个人开发者"></a>9.4.1 个人开发者</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">Pocock Skills（工程基础）+ Goal Workflow（端到端流程）+ OpenSpec（规格管理）</span><br></pre></td></tr></table></figure><p>一个人开发，代码质量靠自己。Pocock Skills 给你测试、lint、Git 这些工程基础。不是每个个人开发者都会主动写测试，但装了 test skill 之后，&quot;写测试&quot;从&quot;要不要做&quot;变成了&quot;敲一下命令&quot;。心理门槛降低了。</p><p>日常用 superpowers 替代 Pocock 也行，自动触发更省心。喜欢自己控制节奏，&quot;现在该跑测试了，我自己来&quot;，就用 Pocock。区别不在效果，在体验。</p><p>Goal Workflow 是保险绳。小功能直接让 Agent 写就行，不需要 <code>/prd</code>。但一个功能要三天，涉及多个模块，同时管需求、设计、实现，<code>/prd</code> → <code>/to-issues</code> → <code>/goal</code> 帮你把复杂度拆开。不是让你做更多流程，是不用在脑子里同时记住所有事。</p><p>OpenSpec 养习惯。先写规格再写代码，没人 review 你的 proposal，但三个月后的你回来看代码，proposal.md 和 design.md 会告诉你当初怎么想的。</p><h3 id="9-4-2-创业团队（2-5-人）"><a href="#9-4-2-创业团队（2-5-人）" class="headerlink" title="9.4.2 创业团队（2-5 人）"></a>9.4.2 创业团队（2-5 人）</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 Workflow（流程骨架）+ gstack（质量审查）+ autoresearch（自动化加速）</span><br></pre></td></tr></table></figure><p>创业团队的核心矛盾：要快，但质量不能垮。没有 QA 团队，没有专职安全工程师。一个人写，另一个人 review，review 质量取决于第二位同事的精力。</p><p>Goal Workflow 给一份共享的骨架。PRD 不是写给自己的，是写给同事的。&quot;我以为你要做的是 X&quot;&quot;不，PRD 上写的是 Y&quot;，这种对话在创业团队里每周都在发生。PRD 让它在动手之前发生。</p><p>gstack 在三个人都忙的时候替代交叉审查。不是替代同事 review，是让 Agent 先把二十三个维度扫一遍，同事 review 时只需要看 Agent 标记的问题和自己关心的部分。</p><p>autoresearch 处理辅助模块，测试脚本、文档生成、数据迁移。三分钟写 Issue，回来代码已经合入，不用等同事有空。</p><h3 id="9-4-3-企业团队（10-人）"><a href="#9-4-3-企业团队（10-人）" class="headerlink" title="9.4.3 企业团队（10+ 人）"></a>9.4.3 企业团队（10+ 人）</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">superpowers（技能基础）+ Spec-Kit/OpenSpec（规格管理）+ gstack（审查流水线）+ Goal Workflow /ship-it（交付）</span><br></pre></td></tr></table></figure><p>企业场景的核心是合规、可追溯、跨团队协作。三个月后的审计人员不看你跑得多快，看你能不能拿出当时的 SPEC 和设计笔记。</p><p>superpowers 统一团队的 Skill 基础。十个工程师用同一套规则，输出的测试格式一致，lint 标准一致。不用问&quot;你用的是哪个版本的 test skill&quot;。</p><p>OpenSpec 管规格。每次技术决策留下记录。三个月后审计问&quot;为什么选这个方案&quot;，proposal.md 里有当时的备选方案和选择理由。</p><p>gstack 做审查流水线。二十三角色全维度跑完，产出审查报告。合规部门要的就是这份报告，不是&quot;谁 review 过了&quot;，是&quot;二十三个角色分别审查了什么，发现了什么，修复了什么&quot;。</p><p><code>/ship-it</code> 管交付，PR、CI、合并、关 Issue，全自动。企业项目里 PR 等 CI 通过、等同事 approve、等合并，每一步都是延迟和出错的机会。<code>/ship-it</code> 把机械操作自动化，人做决策，approve 或 reject。</p><p>Goal Workflow 的 PRD → SPEC → Issue → Note 链，是合规需要的&quot;从需求到代码&quot;的完整追溯线。第 8 章的 <code>/note-it</code> 在这里价值最大，不是记录代码做了什么，是记录为什么选择这样做。对三个月后的审计和半年后的新同事，这两者的价值差一个数量级。</p><h3 id="9-4-4-中文环境开发者"><a href="#9-4-4-中文环境开发者" class="headerlink" title="9.4.4 中文环境开发者"></a>9.4.4 中文环境开发者</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">superpowers-zh（中文技能）+ Goal Workflow（iCafe/Gerrit 集成）+ spec-kit-zh（中文规格）</span><br></pre></td></tr></table></figure><p>两个特殊需求。工具链，iCafe 管卡片、iCode&#x2F;Gerrit 管代码，Goal Workflow 原生支持。<code>/to-issues</code> 直接创建 iCafe 卡片，<code>/ship-it</code> 推到 Gerrit review。</p><p>文档质量。英文 Skill 生成的 PRD 翻译后丢精度。&quot;The system must validate user input&quot;翻译成&quot;系统必须验证用户输入&quot;没问题。但带技术精确度的内容，&quot;Handle race condition on concurrent refund callbacks using idempotency key&quot;，翻译后语义会变形。superpowers-zh 和 spec-kit-zh 直接中文产出，不经过翻译层。</p><h2 id="9-5-AI-研发成熟度模型"><a href="#9-5-AI-研发成熟度模型" class="headerlink" title="9.5 AI 研发成熟度模型"></a>9.5 AI 研发成熟度模型</h2><p>不是谁都需要全套。你在哪一级，决定了你该用什么。</p><p><strong>Level 1：裸奔的 Vibe Coding。</strong> 跟 Agent 聊天写代码。&quot;帮我写个登录页&quot;，看一眼，&quot;不对，蓝色&quot;，再看。快，代码质量全凭运气。三轮需求之后 Agent 开始忘第一轮说了什么。第 1 章定义过 Vibe Coding：&quot;完全用自然语言描述需求，AI 生成代码，人工验证&quot;。是起点，不是终点。</p><p><strong>Level 2：用一个 Skill。</strong> 装了测试 Skill 或 Git Skill。单个场景有保障了，比如每次提交前自动跑测试，测试不过不提交。流程还是散的，什么时候用哪个 Skill 靠自己判断。但至少有一个场景不再靠运气。第 2 章的 Pocock 和第 6 章的 superpowers 都在解决这个级别的问题。</p><p><strong>Level 3：Skill 串起来了。</strong> 有了一条完整的链路。Goal Workflow 的 PRD → Issue → &#x2F;goal 实现。或 OpenSpec 的 propose → apply → archive。像第 3 章的 SDD 和第 4 章的 Ralph Loop，不只是用一个工具，是用一条规则串起多个步骤。规格写好了自动进实现，实现完成了自动进审查。有形状了，还没全链路。</p><p><strong>Level 4：完整的 Spec-Driven 闭环。</strong> 七条路至少用了三条以上，从需求到交付全覆盖。每个阶段有输入输出和质量标准。不靠感觉，靠可验证的东西说话。</p><p>举个例子。你要做一个支付模块。<code>/prd</code> 产出一份 PRD，四个 User Story，每个带 checkbox 验收标准。<code>/prd-to-spec</code> 产出一份 SPEC，API 端点、数据库 schema、错误码表全在里面。<code>/to-issues</code> 拆成十个 Issue，标注依赖。接下来你逐个 <code>/goal</code>，Agent 对照 checkbox 逐条实现，每勾上一个你知道进度往前走了。关键的 Issue 跑完，<code>/review-it</code> 扫一遍，gstack 全维度再扫一遍。确认没问题，<code>/ship-it</code> 合入，<code>/note-it</code> 记下设计决策。三个月后审计来了，从 PRD 到 Note 一条线拉到底，每个决策都有记录。不是&quot;我记得当时好像是这样想的&quot;，是文档里有。</p><p>多数个人开发者在 Level 2-3。多数团队在 3 往 4 过渡。</p><p><strong>Level 5：多 Agent 自动协作 + 持续改进。</strong> 第 7 章的 autoresearch 是这个级别的雏形，五个 Agent 交叉审查，评分达标自动合入。但 Level 5 真正的门槛不是自动化。是你看数据了。</p><p>哪些 Issue 一次过审查？哪些反复返工？哪类 bug 多 Agent 也抓不住？第 7 章提到 autoresearch 有一个持续改进的反馈环，审查中发现的问题模式被反馈到生成和审查 prompt 里，下次同类 Issue 的首次通过率就会提高。</p><p>更进一步的场景：项目跑了三个月，积累了上百条 Issue 的审查数据。你发现&quot;并发处理&quot;类 Issue 的平均返工次数是其他类型的三倍。不是 Agent 不行，是你的并发 Issue 写得太抽象，Agent 理解偏了。下次写并发相关的 PRD，自动增加&quot;并发场景覆盖率&quot;检查项。</p><p>数据喂回去，流程自己变好。Level 5 现在还是稀罕东西，autoresearch 的&quot;一觉醒来一排 merged&quot;通常只发生在 Issue 明确的中小功能上。但方向很清楚。</p><p>你现在在哪一级？</p><p>不用一步到位。先从 Level 1 跳到 Level 2，装一个 Skill，让 Agent 帮你跑测试。习惯了再串起来，试试 <code>/prd</code>，下个功能开始前生成一份 PRD。小步往前走，每步都能验证。</p><h2 id="9-6-本章小结"><a href="#9-6-本章小结" class="headerlink" title="9.6 本章小结"></a>9.6 本章小结</h2><p>前八章讲了怎么做。这一章讲怎么选。</p><p><img src="/images/image-20260531043908188.png"></p><p>选的核心不是对比表。是两个问题。</p><p><strong>第一：你愿意在哪个环节管？</strong> autoresearch 说只在开头管，写好 Issue 放手。Goal Workflow 说每一步管，每站等人。gstack 说在关键节点管，规划、审查、交付前。没有对错，看你愿意在哪停下来。第 8 章 smallnest 做完了全自动的 autoresearch，发现自己还是想每步看一眼，于是做了 Goal Workflow。他选了自己的舒服区。你也要选你的。</p><p><strong>第二：你需要多强的追溯？</strong> 个人项目不需要三个月后解释设计决策。创业团队可能需要，投资人在问&quot;登录模块为什么选了自建而不是第三方&quot;。企业团队一定需要，合规部门等着。追溯越强，越需要结构化的 SPEC 和设计笔记。</p><p>七条路摊开之后，有意思的不是它们各有多少功能。是它们能拼。Pocock Skills 管测试。superpowers 在后台自动触发。OpenSpec 管变更规格。Goal Workflow 管项目流程。Ralph Loop 处理一句话就能说清的小任务。gstack 做全维度审查。autoresearch 把辅助模块全自动跑完。七个工具，一套积木。</p><p>下一章进入本书的第二部分。前面九章都在讲用 AI 做软件工程。Harness Engineering 回答另一个问题：如果你要开发一个 AI Agent 产品，基础设施怎么搭。沙箱、工具安全、产出验证，这些东西没人替你设计。</p>