第9章: 方法论对比与融合

前八章覆盖了七条路线。

Pocock Skills 拆能力。OpenSpec 写规格。Ralph Loop 自己循环到对。gstack 用角色覆盖质量。superpowers 让 Agent 替你选工具。autoresearch 一口气自动到合入。Goal Workflow 串成七步，每步等你说过。

每条路都能走通。真实项目从来不只走一条。Ralph Loop 做实现，谁来审查？gstack 走流程，需求从哪来？autoresearch 全自动跑，Issue 谁拆的？

贪吃蛇案例已经验证了这一点。第 5 章 gstack 走了七个 Sprint 阶段，手工推着走，约两小时。第 6 章 superpowers 后台监听关键词，你答了五个设计问题，约五分钟。第 7 章 autoresearch 你写了一个 Issue，约三分钟，然后等结果。第 8 章 Goal Workflow 每步确认一下，从 PRD 到上线，约八分钟。

同一个贪吃蛇，同一个产出，四种交互模式。

本章把七条路摊开，看它们怎么拼。

9.1 一张表看完七种方法论

扫完这张表，几条规律浮现出来。往右，覆盖范围变大。往下，控制变粗。

也有反直觉的数据点。autoresearch 自动化程度最高，覆盖不如 Goal Workflow——它从 Issue 起步，不管需求和拆解。Goal Workflow 从 PRD 覆盖到上线，但每步都等人。自动化和覆盖不是正相关：覆盖看流程设计，自动化看控制权分配。

还有一个数据点。Pocock Skills 和 superpowers 都是"原子 Skill"，但 superpowers 自动化更高。区别不在 Skill 定义，在触发机制。Pocock Skills 等开发者主动调用——测试写完了吗？跑一下 lint 吧。superpowers 后台监听关键词，干活时自动激活。同样的东西，加个触发机制就改变了交互节奏。第 6 章里 superpowers 自动跑 lint 和 test 的那一刻，开发者甚至没意识到它在工作，直到它报错。

再看安装复杂度那一行。最低的三个——Pocock Skills、superpowers、Goal Workflow——覆盖了完全不同的三种场景：单点任务、中等功能、完整控制。安装成本和方法论的野心不成正比。

控制粒度那一行，Pocock 和 superpowers 都是"细"粒度，一个手动一个自动。gstack 和 Ralph Loop 都是"粗"粒度，一个靠角色驱动，一个靠循环收敛。细粒度让开发者捏住每一步，粗粒度让开发者只看结果。

9.2 它们在回答同一个问题

把七条路的设计摊在一起，你会发现它们都在回答：

AI 能写代码了。人干什么？

答案不是七个。是一条光谱，从左到右，人介入越来越少。

► Pocock Skills 在最左端。人做每一步。

每个 Skill 是一个场景的 SOP，你封装最佳实践成指令，AI 执行。要测试了，调 test skill。要提交了，调 git skill。要重构了，调 refactor skill。什么时候用什么，你判断。

第 2 章里 Pocock 在直播中演示过用 test skill 自动生成测试。代码写完，一个命令，测试就出来了。AI 不会漏边界条件。

► 往右一步，人不再做每一步，只在关键节点把关。

OpenSpec 和 Goal Workflow 都在这个位置。都要求人在决策节点介入，中间的执行自动完成。

OpenSpec 让你在代码之前写规格。先定义"对长什么样"，再让 AI 实现。propose 阶段审核提案，apply 阶段 AI 执行，archive 阶段确认归档。三张牌 proposal.md、tasks.md、design.md 管住了一个变更的完整生命周期。第 3 章的 SDD 理念是它的理论基础：规格是人机之间的合约，合约签好了，执行可以放手。

Goal Workflow 让你在七个流水线步骤之间把关。/prd 产出的需求你确认了，才进 /to-issues。/to-issues 拆出的 Issue 你审核了，才进 /goal。/review-it 发现的问题你决定修不修，/ship-it 你敲了才合。第 8 章里 smallnest 从 autoresearch 转向 Goal Workflow 的原因就是这个，全自动让他不安。"一觉醒来一排 merged"，代码已经在主干上了，PRD 写偏了也没机会纠正。

两者信的是同一件事：在决策点介入比在执行中参与更高效。不是在 Agent 写代码时指手画脚，而是开始写之前说清楚"对是什么"，写完以后确认"确实是对的"。

► 再往后一步。人不直接管执行了，转去定义角色和规则，让 Agent 互相审查。

gstack 的代表作是二十三个虚拟角色。产品经理、架构师、安全专家、性能工程师、数据库管理员，各有各的审查维度。"你是一个有十五年经验的员工工程师，审查这份代码的安全问题"和"review this code for security"的区别，第 5 章实测过。前者能发现上下文相关的逻辑漏洞，后者只能看到 SQL 注入。角色不是噱头，是审查深度。

superpowers 走另一条路。十四个 Skill 覆盖十四个场景，你不需要判断"现在该用哪个工具"，Agent 自己听关键词触发。但它不止于自动触发。第 6 章的 brainstorming 是它最独特的东西，Agent 反问设计问题，每次一个，逐步逼近方案。和 /prd 一次甩五个带选项的问题完全不同。前者适合探索，后者适合目标明确的功能开发。

gstack 和 superpowers 各有一个盲区。gstack 需要你手动驱动每个阶段，"现在进入 Think 阶段""现在进入 Explore 阶段"。superpowers 自动触发但止步于开发分支，不管你 PR 合不合、Issue 关不关。它们覆盖了流程中不同的空缺。

► 快到尽头了。人连规则都不设了，只给一句验收标准。

Ralph Loop 是这个位置的代表。核心机制简单到一句话：设一个 completion promise，Agent 自己循环实现、测试、修复，直到 promise 匹配或达到循环上限。第 4 章的 test-then-commit，"当所有测试通过且没有 lint 错误时，提交代码"。

和 /goal 比，Ralph Loop 更轻。不需要 Issue，不需要 checkbox 列表，一句验收标准就够。"确认路径已更新，服务正常"，Ralph Loop 能搞定。但复杂任务需要结构化验收时，/goal 的逐条 checkbox 对照更靠谱。两者互补。小任务一句话闭环，大任务逐条验收。

► 光谱最右端。人只管两头，中间全自动。

autoresearch 在这个位置。写清楚 Issue 和验收条件，走人。脚本驱动五个 Agent 交替实现和审查，评分够了自动合入。第 7 章的实战数据，四个 Issue 的贪吃蛇变体在十几分钟内全部合入。

但它有一个被忽略的前提：Issue 必须写对。五个 Agent 能交叉审查代码质量、安全、性能，不质疑 Issue 本身。你写"实现一个登录功能"，Agent 就实现登录。但登录要不要二次验证？要不要 OAuth？要不要记住我？这些不在审查范围里。

smallnest 后来做 Goal Workflow，部分原因就是这个。他发现写 Issue 时已经需要想清楚架构了，Issue 质量决定了 autoresearch 的产出。与其把思考压缩成一份 Issue，不如把思考过程展开。PRD 管需求，SPEC 管技术，Issue 管实现，每一步可回溯。

► 光谱不是好坏表。是舒服区。

没人应该永远待在一个位置。一个项目里，核心模块走 Goal Workflow 全流程，PRD → SPEC → Issue → /goal → /review-it → /ship-it。辅助脚本丢给 Ralph Loop，一句"测试全过就行"。文档更新用 autoresearch，写完 Issue 就不用管了。日常编码靠 superpowers 在后台干活。

第 8 章 smallnest 讲过，选哪个，取决于你对自己"能一次写清楚到什么程度"和"愿意参与多少步骤"的诚实判断。不是方法论之间的选择，是你对自己工作方式的理解。

9.3 它们怎么拼

9.3.1 规格层：OpenSpec + Goal Workflow

OpenSpec 管变更级，每个 PR 一个 proposal，包含改什么、为什么、怎么验证。Goal Workflow 管项目级，PRD 管需求，SPEC 管技术方案，Issue 管实现单元。一个微观，一个宏观。

拿支付模块举例。Goal Workflow 的 /prd 产出整体需求：用户下单、微信支付、退款、账单。/prd-to-spec 产出技术方案：支付接口设计、数据库 schema、错误处理策略。/to-issues 拆成十个 Issue。每个 Issue 内部，如果用 OpenSpec 管变更，比如 Issue #3 "接入微信支付 API"涉及三个文件，propose 阶段写一份 proposal.md 说清楚改什么，apply 阶段 AI 执行，archive 阶段归档。

Goal Workflow 的 SPEC 有 Issue 映射表，OpenSpec 的 proposal 有 tasks.md。两层规格首尾相接。SPEC 告诉你这个大功能有哪些小块，proposal 告诉你这个小块怎么改。

9.3.2 实现层：Ralph Loop + /goal

Ralph Loop 适合一句话能说清的任务，设个 completion promise，Agent 自己跑到满足。/goal 适合 checkbox 列表的任务，逐条对照验收。

真实项目里两种都有。还是支付模块。Issue #7 "写一个生成订单号的工具函数"，验收标准就一条：返回 32 位不重复字符串，带时间戳前缀。丢给 Ralph Loop，completion promise 写"函数通过单元测试"。Agent 写好、跑测试、通过、提交。全过程你没看。

Issue #3 "接入微信支付 API"不一样。验收标准有七条：统一下单、支付回调验签、超时关单、退款接口、异常重试策略、日志记录、幂等处理。用 /goal，Agent 逐条实现，你逐条看到 checkbox 勾上。

9.3.3 审查层：gstack + /review-it

gstack 用二十三个角色看一个变更，看得深。/review-it 用四个维度看一个变更，看得快。

大版本发布前跑 gstack 全维度。支付模块上线前，安全专家的角色发现退款回调的签名验证没有防重放攻击。这个漏洞 /review-it 的静态检查抓不到，它不是代码质量或常见安全问题，是业务逻辑的设计缺陷。"你是一个有十五年经验的支付安全专家"，这个 prompt 让 Agent 想了它本来不会想的事。

日常开发用 /review-it 做增量。改了个配置文件，三秒扫完四个维度，没有 actionable findings，直接 /ship-it。为这个跑二十三角色全维度不值得。

第 5 章里 gstack 强调过：角色的价值不在数量，在视角。二十三个角色就是二十三个视角。/review-it 的价值在速度，一个命令覆盖四个维度，不用手动指定审查角色。

支付模块十个 Issue。Issue #1 "数据库表结构"、Issue #10 "生成 API 文档"、Issue #8 "单元测试补充"，独立性强，出错了也不影响核心流程，丢进 autoresearch。你写完 Issue 去开会，回来三个 PR 已经合入。

Issue #3 "接入微信支付 API"、Issue #4 "退款流程"，核心交易链路，用 /goal 手动逐个来。每步写完看一眼，确认支付回调的签名逻辑对了，退款的状态机没有漏洞。

这个组合能成立，是因为 /to-issues 产出的 Issue 格式同时兼容两条路。同一个 Issue 文件，丢给 /goal 就是手动单步，丢给 autoresearch 就是全自动。不是两套流程，是一套输入两个出口。

什么时候走哪个出口，判断标准也简单。这个 Issue 做错了会怎样？丢了钱、丢了数据、用户投诉——走 /goal。只是个工具函数、文档更新、测试补充——走 autoresearch。风险和控制的权衡，不该由方法论替你决定。

全流程控制和全自动加速不是非此即彼。是你判断哪些值得控制，哪些值得加速。

9.3.4 能力单元层：Pocock Skills + superpowers + Goal Workflow Bonus

三套 Skill，组织方式各不一样。

Pocock 散装，自己挑。superpowers 自动触发，Agent 判断时机。Goal Workflow Bonus 是独立工具集，/refactor、/modern-go、/code-to-spec，需要时才调。

日常编码靠 superpowers 自动激活测试和 lint。你改了一个函数，保存，Agent 静默跑测试。没过，报错。你修。保存，测试通过。全程没手动调 skill，superpowers 在后台干的。

但有些场景 superpowers 覆盖不到。你要把项目从 Go 1.16 升到 1.22，35+ 条 API 变更规则，superpowers 没有这个领域知识。这时候调 Goal Workflow Bonus 的 /modern-go，一次性批量现代化。Pocock 的精品 Skill 同理，他的 Git skill 能自动生成 conventional commits 格式的提交信息。

三套东西不冲突，但有个容易踩的坑：同一类任务装了两套 Skill。比如 superpowers 已经有自动测试了，你又装了 Pocock 的 test skill。它们不会打架，但你会在两个地方看到测试结果——一个自动弹出的，一个手动触发的。时间长了你会只信其中一个，另一个变成噪音。装之前想清楚：这个场景你是想让 Agent 自动判断，还是自己决定什么时候调。

9.4 不同场景的推荐组合

不同的场景和团队规模下，你可以选择一个或者多个合适的工具/开发流程。

9.4.1 个人开发者

Pocock Skills（工程基础）+ Goal Workflow（端到端流程）+ OpenSpec（规格管理）

一个人开发，代码质量靠自己。Pocock Skills 给你测试、lint、Git 这些工程基础。不是每个个人开发者都会主动写测试，但装了 test skill 之后，"写测试"从"要不要做"变成了"敲一下命令"。心理门槛降低了。

日常用 superpowers 替代 Pocock 也行，自动触发更省心。喜欢自己控制节奏，"现在该跑测试了，我自己来"，就用 Pocock。区别不在效果，在体验。

Goal Workflow 是保险绳。小功能直接让 Agent 写就行，不需要 /prd。但一个功能要三天，涉及多个模块，同时管需求、设计、实现，/prd → /to-issues → /goal 帮你把复杂度拆开。不是让你做更多流程，是不用在脑子里同时记住所有事。

OpenSpec 养习惯。先写规格再写代码，没人 review 你的 proposal，但三个月后的你回来看代码，proposal.md 和 design.md 会告诉你当初怎么想的。

9.4.2 创业团队（2-5 人）

Goal Workflow（流程骨架）+ gstack（质量审查）+ autoresearch（自动化加速）

创业团队的核心矛盾：要快，但质量不能垮。没有 QA 团队，没有专职安全工程师。一个人写，另一个人 review，review 质量取决于第二位同事的精力。

Goal Workflow 给一份共享的骨架。PRD 不是写给自己的，是写给同事的。"我以为你要做的是 X""不，PRD 上写的是 Y"，这种对话在创业团队里每周都在发生。PRD 让它在动手之前发生。

gstack 在三个人都忙的时候替代交叉审查。不是替代同事 review，是让 Agent 先把二十三个维度扫一遍，同事 review 时只需要看 Agent 标记的问题和自己关心的部分。

autoresearch 处理辅助模块，测试脚本、文档生成、数据迁移。三分钟写 Issue，回来代码已经合入，不用等同事有空。

9.4.3 企业团队（10+ 人）

superpowers（技能基础）+ Spec-Kit/OpenSpec（规格管理）+ gstack（审查流水线）+ Goal Workflow /ship-it（交付）

企业场景的核心是合规、可追溯、跨团队协作。三个月后的审计人员不看你跑得多快，看你能不能拿出当时的 SPEC 和设计笔记。

superpowers 统一团队的 Skill 基础。十个工程师用同一套规则，输出的测试格式一致，lint 标准一致。不用问"你用的是哪个版本的 test skill"。

OpenSpec 管规格。每次技术决策留下记录。三个月后审计问"为什么选这个方案"，proposal.md 里有当时的备选方案和选择理由。

gstack 做审查流水线。二十三角色全维度跑完，产出审查报告。合规部门要的就是这份报告，不是"谁 review 过了"，是"二十三个角色分别审查了什么，发现了什么，修复了什么"。

/ship-it 管交付，PR、CI、合并、关 Issue，全自动。企业项目里 PR 等 CI 通过、等同事 approve、等合并，每一步都是延迟和出错的机会。/ship-it 把机械操作自动化，人做决策，approve 或 reject。

Goal Workflow 的 PRD → SPEC → Issue → Note 链，是合规需要的"从需求到代码"的完整追溯线。第 8 章的 /note-it 在这里价值最大，不是记录代码做了什么，是记录为什么选择这样做。对三个月后的审计和半年后的新同事，这两者的价值差一个数量级。

9.4.4 中文环境开发者

superpowers-zh（中文技能）+ Goal Workflow（iCafe/Gerrit 集成）+ spec-kit-zh（中文规格）

两个特殊需求。工具链，iCafe 管卡片、iCode/Gerrit 管代码，Goal Workflow 原生支持。/to-issues 直接创建 iCafe 卡片，/ship-it 推到 Gerrit review。

文档质量。英文 Skill 生成的 PRD 翻译后丢精度。"The system must validate user input"翻译成"系统必须验证用户输入"没问题。但带技术精确度的内容，"Handle race condition on concurrent refund callbacks using idempotency key"，翻译后语义会变形。superpowers-zh 和 spec-kit-zh 直接中文产出，不经过翻译层。

9.5 AI 研发成熟度模型

不是谁都需要全套。你在哪一级，决定了你该用什么。

Level 1：裸奔的 Vibe Coding。 跟 Agent 聊天写代码。"帮我写个登录页"，看一眼，"不对，蓝色"，再看。快，代码质量全凭运气。三轮需求之后 Agent 开始忘第一轮说了什么。第 1 章定义过 Vibe Coding："完全用自然语言描述需求，AI 生成代码，人工验证"。是起点，不是终点。

Level 2：用一个 Skill。 装了测试 Skill 或 Git Skill。单个场景有保障了，比如每次提交前自动跑测试，测试不过不提交。流程还是散的，什么时候用哪个 Skill 靠自己判断。但至少有一个场景不再靠运气。第 2 章的 Pocock 和第 6 章的 superpowers 都在解决这个级别的问题。

Level 3：Skill 串起来了。 有了一条完整的链路。Goal Workflow 的 PRD → Issue → /goal 实现。或 OpenSpec 的 propose → apply → archive。像第 3 章的 SDD 和第 4 章的 Ralph Loop，不只是用一个工具，是用一条规则串起多个步骤。规格写好了自动进实现，实现完成了自动进审查。有形状了，还没全链路。

Level 4：完整的 Spec-Driven 闭环。 七条路至少用了三条以上，从需求到交付全覆盖。每个阶段有输入输出和质量标准。不靠感觉，靠可验证的东西说话。

举个例子。你要做一个支付模块。/prd 产出一份 PRD，四个 User Story，每个带 checkbox 验收标准。/prd-to-spec 产出一份 SPEC，API 端点、数据库 schema、错误码表全在里面。/to-issues 拆成十个 Issue，标注依赖。接下来你逐个 /goal，Agent 对照 checkbox 逐条实现，每勾上一个你知道进度往前走了。关键的 Issue 跑完，/review-it 扫一遍，gstack 全维度再扫一遍。确认没问题，/ship-it 合入，/note-it 记下设计决策。三个月后审计来了，从 PRD 到 Note 一条线拉到底，每个决策都有记录。不是"我记得当时好像是这样想的"，是文档里有。

多数个人开发者在 Level 2-3。多数团队在 3 往 4 过渡。

Level 5：多 Agent 自动协作 + 持续改进。 第 7 章的 autoresearch 是这个级别的雏形，五个 Agent 交叉审查，评分达标自动合入。但 Level 5 真正的门槛不是自动化。是你看数据了。

哪些 Issue 一次过审查？哪些反复返工？哪类 bug 多 Agent 也抓不住？第 7 章提到 autoresearch 有一个持续改进的反馈环，审查中发现的问题模式被反馈到生成和审查 prompt 里，下次同类 Issue 的首次通过率就会提高。

更进一步的场景：项目跑了三个月，积累了上百条 Issue 的审查数据。你发现"并发处理"类 Issue 的平均返工次数是其他类型的三倍。不是 Agent 不行，是你的并发 Issue 写得太抽象，Agent 理解偏了。下次写并发相关的 PRD，自动增加"并发场景覆盖率"检查项。

数据喂回去，流程自己变好。Level 5 现在还是稀罕东西，autoresearch 的"一觉醒来一排 merged"通常只发生在 Issue 明确的中小功能上。但方向很清楚。

你现在在哪一级？

不用一步到位。先从 Level 1 跳到 Level 2，装一个 Skill，让 Agent 帮你跑测试。习惯了再串起来，试试 /prd，下个功能开始前生成一份 PRD。小步往前走，每步都能验证。

9.6 本章小结

前八章讲了怎么做。这一章讲怎么选。

选的核心不是对比表。是两个问题。

第一：你愿意在哪个环节管？ autoresearch 说只在开头管，写好 Issue 放手。Goal Workflow 说每一步管，每站等人。gstack 说在关键节点管，规划、审查、交付前。没有对错，看你愿意在哪停下来。第 8 章 smallnest 做完了全自动的 autoresearch，发现自己还是想每步看一眼，于是做了 Goal Workflow。他选了自己的舒服区。你也要选你的。

第二：你需要多强的追溯？ 个人项目不需要三个月后解释设计决策。创业团队可能需要，投资人在问"登录模块为什么选了自建而不是第三方"。企业团队一定需要，合规部门等着。追溯越强，越需要结构化的 SPEC 和设计笔记。

七条路摊开之后，有意思的不是它们各有多少功能。是它们能拼。Pocock Skills 管测试。superpowers 在后台自动触发。OpenSpec 管变更规格。Goal Workflow 管项目流程。Ralph Loop 处理一句话就能说清的小任务。gstack 做全维度审查。autoresearch 把辅助模块全自动跑完。七个工具，一套积木。

下一章进入本书的第二部分。前面九章都在讲用 AI 做软件工程。Harness Engineering 回答另一个问题：如果你要开发一个 AI Agent 产品，基础设施怎么搭。沙箱、工具安全、产出验证，这些东西没人替你设计。