ralplan 是什么
ralplan 是开源框架 oh-my-claudecode（简称 OMC）中的规划工作流。所谓框架（harness），指的不是模型本身，而是规定模型以什么顺序、什么角色、经过哪些校验来工作的一整套规则。同一个模型，换一套框架，结果就不同。
用法只有一行。在 Claude Code 终端输入 /oh-my-claudecode:ralplan "为支付失败增加重试逻辑" 即可。这个名字是 /oh-my-claudecode:plan --consensus 的简写别名，consensus 即共识。
接下来发生的事与普通编码智能体不同。多数智能体一收到请求就打开文件开始写代码。ralplan 不写代码，而是让 Planner、Architect、Critic 依次围绕同一份规划文档反复讨论，直到达成共识。共识达成后才向人请求批准，获批之后才进入执行阶段。
为什么不能由一个智能体全包
看上去可以让同一个模型先写方案再自我审查三遍，但实际上三遍都会掉进同一个盲区。反驳自己刚写下的东西，对人来说同样很难。
因此 ralplan 给每个角色不同的权限与义务：写初稿的一方被格式约束，负责反驳的一方被剥夺修改权，负责判定的一方被赋予驳回义务。三个智能体使用不同的提示词与不同的工具权限运行，并非换了三个名字的同一次调用。
下面三节说明每个角色必须交付什么。
Planner — 至少拿出两个选项
Planner 负责写规划初稿，但不能随意发挥，必须填满名为 RALPLAN-DR 的格式。三项内容是必填的：本方案要遵守的 3 到 5 条原则、决定取舍的前 3 个决策要素，以及至少两个可行选项，每个选项都要写清有界的利弊。
最关键的是最后一条。如果最终只剩一个方案，就必须写明其余方案为何被否决的理由。这一条打断了「最先想到的办法自动成为答案」的惯性。因为被否决的选项留在文档里，几周后再问「当初为什么这么做」，答案依然在。
产出不会散落在对话里，而是以 markdown 文件保存在 .omc/plans/ 下。方案写成 3 到 6 个可执行步骤，每步都附上执行者可验证的完成标准 — 既不是 30 条琐碎清单，也不是两句空话。
面对高风险工作时加上 --deliberate，还会追加三种失败情景的事前验尸（premortem）以及涵盖单元、集成、端到端与可观测性的扩展测试计划。
Architect — 正因为不能动手，反驳才成立
Architect 读取 Planner 写的方案，并从架构角度提出反驳。它的定义里写着 disallowedTools: Write, Edit — 写入与编辑文件的工具被彻底禁用，是严格意义上的只读智能体。
拿掉权限正是要点。能动手的人会先动手，而不是先反驳。无法动手时，能做的只剩一件事。Architect 必须交付针对首选方案的最强反论（steelman antithesis）、至少一处真实的权衡张力，以及在可能时把两者调和的综合方案。
它的论据同样受约束：每条结论都要标注 file:line，必须指出根因而非症状，不允许出现「考虑重构一下」这类含糊建议。在 deliberate 模式下，还必须明确指出方案在哪里违反了 Planner 自己立下的原则。
若想把反驳者换成完全不同的模型，加上 --architect codex。装有 Codex CLI 时，这一步交给 Codex；没有则静默回退到默认 Architect。当你想连同一模型三次调用共有的盲区一并去掉时，就用这个开关。
Critic — 负责的是驳回，而不是放行
Critic 定义中的一个前提，决定了整个工作流的性格：错误放行的代价，是错误驳回的 10 到 100 倍。因此 Critic 被设计成最终质量闸门，而不是提供帮助的审阅者，作者则被视为前来申请批准的一方。
它的视角也不同。普通审查评估写了什么，Critic 还要评估没写什么，并轮流以执行者、利益相关方、怀疑者三种视角寻找缺口。检查项包括：原则与选项是否自洽、是否公平地探讨了替代方案、风险缓解是否具体、完成标准是否真的可测试、验证步骤是否写明。
它还负有驳回义务。浅薄的替代方案、决策要素之间的矛盾、含糊的风险、薄弱的验证，都必须被明确拒绝。在 deliberate 模式下，缺失或敷衍的事前验尸与扩展测试计划本身就是驳回理由。判定结果只有三种：通过、返工、驳回。
三个角色齐备才会出现的三项好处
第一，顺序被强制。Architect 结束之前绝不调用 Critic。文档里以大写标注了这条规则，甚至明确要求不要把两次调用放进同一个并行批次。同时调用意味着彼此读不到对方的意见，得到的不是共识，而是两段独白。
第二，返工是闭环。Critic 判定返工或驳回时，Architect 与 Critic 的意见会一并交回 Planner 修改，然后从 Architect 重新审查 — 不是只看改动的部分。这个循环最多跑五轮，五轮内仍未通过，就把最佳版本连同「未达成共识」的说明交给人。
第三，批准前代码是锁住的。方案会被标记为 pending approval，在此之前 ralplan 不能编辑文件、提交、推送、开 PR，也不能把工作移交给执行技能。一旦规划阶段开始动代码，方案就沦为对既成事实的事后辩护。
批准之后的执行也不由这个工作流亲自完成。使用 --interactive 时，最后会询问执行方式，并按选择移交给 team（并行执行）或 ralph（顺序执行加验证）。规划者与建造者分离的原则贯彻到底。
如何开始
首先需要装好 Claude Code，然后加入 OMC：执行 /plugin install oh-my-claudecode，或在终端运行 npm i -g oh-my-claude-sisyphus@latest。无论哪种方式，之后再跑一次 /oh-my-claudecode:omc-setup，准备工作就完成了。
基本用法是 /oh-my-claudecode:ralplan "任务描述"。不加任何参数时，Planner 到 Architect 再到 Critic 的循环会自动运行，把完成的方案标记为 pending approval 后输出并停止。中途不发问，也不执行任何操作。
常用参数有四个。--interactive 会在初稿审查与最终批准两个节点征询你的意见。--deliberate 追加三种情景的事前验尸与扩展测试计划；不过当请求带有认证、安全、数据迁移、线上故障、个人信息等明显风险信号时，它也会自动开启。--architect codex 与 --critic codex 分别只把反驳者或裁判换成 Codex。
产物以 markdown 保存在 .omc/plans/ 下，结尾附有 ADR 结构：决策、决策要素、考虑过的替代方案、选择理由、后果、后续事项。这份文件既是执行说明书，也是日后回溯决策的记录。
什么时候该用，什么时候不必
ralplan 价值最大的时刻，正是有人想直接开跑的时候。OMC 内置了一道闸门，会拦截「用 ralph 把这个应用改好点」这类含糊的执行请求，把它转给 ralplan。范围不清就启动多个智能体，等于让它们在执行中做本应在规划阶段完成的范围探索，结果往往是半成品或方向跑偏。
反过来说，改错别字、重命名一个函数、改一行配置这类容易回滚、没什么可判断的工作，用它就过头了。共识循环并不免费，它消耗时间与 token。
把标准压缩成一句话：撤销成本高于规划成本的工作，就用 ralplan。数据迁移、认证结构变更、公开 API 修改、动到支付流程都属于此类。Critic 的那条前提 — 错误放行比错误驳回贵 10 到 100 倍 — 在人的协作中同样成立。