我在 Ralph 详解 中记录过 aimo 项目从 Ralph 切换到 Superpowers 的过程，实践对象是 Aimo。这篇文章最初将两者概括为「Ralph 像敏捷开发、Superpowers 像瀑布开发」，上一版改为「Ralph 事后纠偏、Superpowers 事前确认」。通读六个 Skill 套件的源码（见六大套件源码级对比），并核对 Geoffrey Huntley 的原文、Ryan Carson 的 Ralph 实现之后，我认为「事前确认与事后纠偏」这个框架同样不成立，本文据此再次重写。
为什么事前与事后的划分不成立
这个划分在两个方向上都遇到反例。
Ralph 的需求同样由人事前共创。Huntley 在原文中说明，specs 来自项目启动阶段与 LLM 的长对话，讨论需求后再让模型按主题把规格写入 specs/。社区最流行的实现 snarktank/ralph（2026 年 1 月发布，两万余 star）把这一步做成了明确的工作流：先用 /prd 技能向用户提 3 到 5 个带选项的澄清问题，用户回答后生成 PRD，再转换为结构化的 prd.json，之后循环才启动。Superpowers 的 brainstorming 是同一机制的不同粒度：逐项提问、给出候选方案、分段呈现设计并逐段获批，设计文档同样落盘到 specs 目录。两边都是人机对话共创需求、规格落盘、再驱动执行，差别只在确认环节切分的粗细。
另一个方向，Superpowers 的事后纠偏比 Ralph 更系统。Superpowers 的子 Agent 每完成一个任务，由 reviewer 做两阶段审查（spec 合规与代码质量），全部任务完成后再做一次 whole-branch 评审；评审发现的修复轮次最多 5 轮，第 5 轮时逐条裁决未决问题，只有影响正确性的问题才中止流程并上报给人。Ralph 的循环内没有任何评审环节，质量只靠 typecheck、lint、test 这类可执行检查把关，通过才允许提交。「Ralph 事后、Superpowers 事前」的描述恰好把两者的纠偏能力说反了。
执行阶段人的位置
排除时间轴上的划分后，第一个可核实的差异是执行阶段人站在哪里。
Ralph 的设计原则是把人放在循环之外。Playbook 有专门一节 “Move Outside the Loop”：启动后人坐在循环上而不是循环里，通过观察输出发现失败模式，再通过修改 prompt 增加约束来纠偏；计划被视为可抛弃的，出现偏差就重跑一轮 planning 重新生成。人对循环的控制是间接的，手段只有调 prompt 和重建计划。
Superpowers 把人物理地放在流程里。设计获批后才写计划，计划获批后才执行，执行方式（内联还是子 Agent）也由人选择；熔断触发、计划冲突时，人是升级路径的终点。这些确认全部是 prompt 层约定，没有运行时强制，模型在上下文压力下仍可能跳过确认直接执行；这一点与 Ralph 的 prompt 约束是同一性质，只是 Ralph 另有 bash 循环和可执行检查兜底。
纠偏信任的对象
第二个差异是两者把正确性押在不同的东西上。
Ralph 信任确定性反馈。每轮必须通过类型检查、测试和 lint 才能提交，不合格代码不会进入 git 历史；单轮做错没关系，错误模式是稳定的（Huntley 称之为 “deterministically bad in an undeterministic world”），下一轮可以用更精确的 prompt 修正。纠偏的成本是一轮迭代，正确性通过多轮迭代收敛。
Superpowers 信任 LLM 评审链。它同样要求 TDD（plan 模板中的 RED-GREEN 步骤、执行报告中的 TDD Evidence），但在可执行检查之上叠加了多层非确定性的模型评审，并用 ledger 文件和落盘的审查记录对抗上下文压缩。子 Agent 使用独立上下文，主会话只通过文件传递任务和证据。
两种押注各有失效场景。Ralph 的检查覆盖不到的地方（界面行为、需求理解偏差）会在无人值守中持续累积，snarktank/ralph 的 Claude 版模板已经把浏览器验证从必需降级为可用时才执行。Superpowers 的评审由模型执行，评审质量随上下文长度下降，且评审标准同样是 prompt 层约定。
对比
| 维度 | Ralph | Superpowers |
|---|---|---|
| 需求确定 | 与 LLM 对话后写入 specs 或生成 PRD，启动前由人确认 | brainstorming 分段获批，设计文档落盘 |
| 执行阶段人的位置 | 循环外，通过调 prompt 和重建计划间接控制 | 流程内，设计、计划、执行方式、熔断升级都经过人 |
| 循环内质量把关 | typecheck、test、lint，不过不提交 | 可执行检查之外叠加两阶段 LLM 评审与 whole-branch 评审 |
| 纠偏方式 | 失败模式稳定，修改 prompt 后在下一轮迭代中修正 | 评审发现问题后修复，5 轮未决则逐条裁决，必要时中止上报 |
| 上下文管理 | 每轮新进程，状态存于 prd.json、progress.txt 和 git 历史 | 子 Agent 独立上下文，ledger 文件应对压缩 |
| 约束性质 | prompt 层约定，外加 bash 循环与可执行检查兜底 | prompt 层约定，外加文件化产物与 ledger 兜底 |
| 适用阶段 | greenfield 批量实现功能，检查基建完善 | 存量维护和需要在关键环节人工判断的加固任务 |
可借鉴的做法
aimo 的切换基于执行阶段人的位置这一差异。前三周接近 greenfield，功能连续产出，Ralph 的批量循环适用；进入存量代码库的加固迭代后，任务需要在关键环节进行人工判断，人在流程内的 Superpowers 更适合该阶段。
两个套件的部件可以拆开复用。Superpowers 的子 Agent 和 checkpoint 模式有时会遗漏细节；Ralph 每轮创建干净会话，在这些任务中表现更稳定。brainstorming 用于需求共创的作用则独立于执行模式。此前我通过 /prd PROMPT 调用 Ralph，生成 PRD 后需要阅读并经过多轮调整才能拆分任务；现在使用 brainstorming 在单个 session 中与 AI 讨论需求，减少了后续调整次数，也会得到此前未考虑的方案。AIMO 的 AI 知识回顾功能来自这一过程。
使用条件
两者共享同一组前提：任务可拆小、有至少一类可自动验证的完成标准、需求能够落成规格文件。Skill 数量过多会增加当前模型的上下文干扰，任务应保持足够小，使目标在单轮或单个任务内稳定。
选择时可以用两个问题判断。第一个：这类任务的错误能否靠 typecheck、test、lint 发现？能，则 Ralph 的循环成本低，人可以站在循环外；不能（界面行为、权限边界、需求理解），则需要人在流程内确认或使用评审。第二个：错误的代价能否由下一轮迭代覆盖？greenfield 批量实现通常可以，存量代码库的加固迭代通常不行。
