企业官网建设流程全解析

oh-my-claudecode 的执行模式怎么选？autopilot、team、ralph 与 ultrawork 的决策依据

【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode

在 oh-my-claudecode（OMC）里跑任务时，第一步往往是选执行模式：一个产品想法要一路自动走到可运行代码用autopilot，要多个 worker 并行认领任务池用/team，要"不验证通过就不停"的持久化循环用ralph，而ultrawork则是被它们复用的并行执行引擎。选错模式的代价是：autopilot 会对单点小修发起五阶段重流程，team 会把一个人能更快干完的工作套上协调开销。这篇文章基于仓库内的模式选择文档和三个模式各自的 SKILL 文档，给出一条可执行的决策路径：按什么问题选哪个模式、命令怎么调、以及跑完后拿什么证据判断它真的完成了。

适用前提：已安装 Claude Code 并装好 OMC 插件（Claude Max/Pro 订阅或ANTHROPIC_API_KEY，安装与omc-doctor验证步骤见 GETTING-STARTED.md）；本文依据的仓库版本标记为 5.0.2（CLAUDE.md 中的OMC:VERSION注释）。

先分清四种模式类型，以及一个版本事实

mode-selection-guide.md 把模式分成四类，这个分类决定了哪些模式可以叠加、哪些互斥：

mode-hierarchy.md 给出的继承关系：

autopilot (autonomous end-to-end) ├── includes: ralph (persistence) │ └── includes: ultrawork (parallelism) └── includes: plan (strategic thinking) ralph (persistence wrapper) └── includes: ultrawork (parallelism engine) (adds: loop until done + architect verification) ultrawork (parallelism engine) └── COMPONENT only - parallel agent spawning (no persistence, no verification loop)

写作与选型时必须注意的版本事实：5.0.0 起，ultrawork、ultrapilot、swarm、pipeline、ultraqa等 17 个名字被整体移除，且不作为别名保留（CLAUDE.md、MIGRATION.md）。也就是说在 5.x 里ultrawork不再是可直接调用的独立命令，官方替代映射是/oh-my-claudecode:execute或/team（协调式并行 worker 用/team）；ultrapilot和swarm则并入team。而模式选择文档里仍把ultrawork作为模式列出——那描述的是 ralph/autopilot 内部的并行引擎概念，不再是独立入口。本文按这条边界处理：涉及"并行"的选型，落到/team或/oh-my-claudecode:execute。

按三个问题走一遍决策流程

mode-selection-guide.md 的决策流程图按下面的顺序提问：

不确定需求、想法模糊？ ├── YES: 先用 deep-interview 澄清再执行 └── NO: 继续 想要自主执行（autonomous）？ ├── YES: 任务能拆成 3 个以上独立组件吗？ │ ├── YES: team N:executor（带文件所有权的并行自主执行） │ └── NO: autopilot（顺序执行 + ralph 阶段） └── NO: 想要并行执行 + 人工监督？ ├── YES: 要成本控制吗？ → 是: eco + 并行模式；否: 纯并行 └── NO: 需要"直到验证通过才停"？ ├── YES: ralph（持久化 + 并行 + 验证） └── NO: 标准编排（直接向 agent 委派） 有大量相似的独立任务（例如"修 47 个错误"）？ └── YES: team N:executor（N 个 agent 从任务池认领）

判断依据是任务结构，不是个人偏好。文档给出的示例（原文示例，可直接对照自己的任务）：

需求模糊时不要直接进执行模式：文档建议先跑/deep-interview，用苏格拉底式提问澄清模糊想法并暴露隐藏假设，之后再进 autopilot——autopilot 检测到.omc/specs/deep-interview-*.md已存在时会直接把它当 Phase 0 输出。

autopilot：从想法到已验证代码的自主链路

触发方式：关键词autopilot、"build me"、"I want a"，或直接/oh-my-claudecode:autopilot "<task>"；GETTING-STARTED.md 的首个任务示例就是一行autopilot build me a hello world app。

执行结构（autopilot SKILL）：Phase 0 扩展需求 → Phase 1 规划（planner 出计划、critic 审计划）→ Phase 2 执行（executor 按任务难度分 haiku/sonnet/opus，独立任务并行）→ Phase 3 QA → Phase 4 多视角验证 → Phase 5 清理状态文件。

何时判断该停下/继续，文档给了明确的停止条件：

• QA 循环最多 5 轮；同一个错误连续出现 3 次 → 停止并报告根本问题，等人工介入；
• 验证（architect 功能完整性、security-reviewer 漏洞、code-reviewer 质量）要求三方全部批准，被拒项修复后重新验证；重验证失败累计 3 轮后停止报告；
• 用户说 "stop"/"cancel"/"abort" 即停。

完成判定（SKILL 的 Final Checklist）：5 个阶段全部完成、Phase 4 全部验证者批准、有新鲜的测试运行输出且全部通过、有新鲜构建输出且成功、状态文件已清理。运行中可通过 Claude Code 状态栏 HUD 观察（文档示例输出，非固定预期）：

[OMC] autopilot:execution | agents:3 | todos:2/5 | ctx:45%

恢复：取消或失败后重新运行/oh-my-claudecode:autopilot会从断点继续，/oh-my-claudecode:cancel会保留进度。

不适合 autopilot 的情况（SKILL 的 Do_Not_Use_When）：想探索方案/头脑风暴（用plan）、单一聚焦的代码修改（用ralph或直接委派 executor）、快速小修（直接委派）。

team：并行 worker + 分阶段验证

触发与语法（team SKILL）：

/oh-my-claudecode:team N:agent-type "task description" /oh-my-claudecode:team "task description" /oh-my-claudecode:team ralph "task description"

• N是 worker 数量，范围 1–20，缺省时按任务分解自动定规模；
• agent-type只覆盖team-exec阶段的 worker 类型（executor、debugger、designer 等），其余阶段由 lead 按阶段路由表选专用 agent；
• 文档示例：/team 5:executor "fix all TypeScript errors across the project"、/team 3:debugger "fix build errors in src/"。

执行结构是固定管道：team-plan → team-prd → team-exec → team-verify → team-fix（循环）。每个阶段切换时 lead 会写 handoff 文档到.omc/handoffs/<stage-name>.md（记录已决定/已拒绝/风险/遗留项），验证失败生成 fix 任务回流；team-fix有次数上限（max_fix_loops默认 3），超过即转终态failed，不会无限循环。

完成判定：所有真实任务（非内部任务）在任务列表中标记completed，或到达带证据的明确 failed/blocked 终态；随后 lead 逐个向 teammate 发shutdown_request、等shutdown_response（30 秒超时），确认后才清理 OMC 状态并删除.omc/state/team-state.json。终态只有三种：complete、failed、cancelled。

取消与恢复：/oh-my-claudecode:cancel处理 team 清理；lead 崩溃后可通过state_read(mode="team")找到最后阶段并从该阶段恢复，而不是重复 spawn worker。

两个使用边界：

• 平台检查：原生 Windows 上先运行tmux -V确认 tmux 兼容二进制（psmux 受支持），不要直接告知用户"必须 WSL"；只有确实没有 tmux 兼容二进制时才建议安装 psmux 或改用 WSL2。
• team ralph组合：team 管道包在 ralph 持久化循环里，team-verify通过后 ralph 再做 architect 验证（至少 STANDARD 档）；任一侧取消都会连带取消另一侧。

不适合 team 的情况：选择指南的 "Avoid when" 一列写明——一个人能比协调开销更快地干完时不要用 team。

ralph：以 PRD 为完成依据的持久化循环

触发方式：关键词ralph、"don't stop"、"must complete"、"keep going until done"，或/oh-my-claudecode:ralph "task"（ralph SKILL）。

执行结构：ralph 是 PRD 驱动的循环——启动时会生成prd.json脚手架（活动状态在.omc/state/sessions/{sessionId}/prd.json），你必须先把脚手架里 "Implementation is complete" 这类泛化验收标准替换成任务专属标准（例如"函数 X 在给定 Z 时返回 Y"），然后逐条 story 实现、逐条验收、把passes置为true，直到所有 story 通过。

验证是 ralph 与"跑到一半就宣称完成"的区别：

• 选--critic=architect（默认）、--critic=critic或--critic=codex指定完成审核者；
• 审核档位：小于 5 个文件、少于 100 行且有完整测试 → 至少 STANDARD 档（Sonnet）；超过 20 个文件或涉及安全/架构变更 → THOROUGH 档（Opus）；
• 审核者是针对 prd.json 里的具体验收标准审，不是泛泛问"完成了吗"；
• 批准后还要过 Step 7.5 的ai-slop-cleaner清理与 Step 7.6 的回归重验证（测试/构建/lint 全重跑），最后才/oh-my-claudecode:cancel干净退出；可用--no-deslop跳过清理。

完成判定（Final Checklist 摘录）：所有 prd.json story 为passes: true且无未验证的活跃标准；新鲜的测试运行输出全绿、构建输出成功；所选 reviewer 针对具体标准批准；/oh-my-claudecode:cancel已执行。

停止条件：遇到需要用户输入的根本阻塞（缺凭据、需求不清、外部服务挂了）时停止报告；同一问题连续 3 轮以上复发时报告为潜在根本问题；reviewer 拒绝则修复后重验，不是停。

不适合 ralph 的情况：想要从想法到代码的完整自主管线（改用 autopilot）、想先探索规划（用plan）、一次性快修（直接委派 executor）。

ultrawork 在 5.x 中的位置

ultrawork的定位在 mode-hierarchy.md 里写得很明确：它是 component only——只做并行 agent 调度，没有持久化、没有验证循环，并行度有、持久化无、验证无。它的设计用途是被 ralph 和 autopilot 内部复用。

在 5.0.0 之后你需要"并行执行 + 人工监督"（选择指南里 ultrawork 那一行的场景）时，文档给出的落点是：

• 协调式并行 worker →/team（MIGRATION.md 的替代映射："Use/teamwhen you want coordinated parallel workers"）；
• 单条并行执行 →/oh-my-claudecode:execute。

ultrawork的状态文件ultrawork-state.json仍出现在模式状态表里（见 mode-hierarchy.md），取消命令也会清理它——这是 ralph/autopilot 内部并行阶段留下的状态，不代表你还要直接调用 ultrawork 命令。

组合规则：哪些能叠，哪些互斥

来自 mode-selection-guide.md 的组合表：

无效组合：

eco的触发关键词是 "eco"、"budget"，作用是让模型路由偏好廉价档（mode-hierarchy 说明它"does NOT include persistence — that's ralph's job"）。

除了模式间互斥，还有一条更硬的规则：一个会话只有一个主循环权威。选择指南的 "Goal-Oriented Workflow Selection" 一节要求 Ralph、Team、/goal、artifact-only Ultragoal 之间只选一个持久化循环作为主权威，不同时跑竞争的持久化循环；冲突处理使用确定性的refuse、adopt_existing、artifact_only策略。各循环的适用边界（文档表格的要点）：

• Claude Code/goal：单一可度量完成条件、需要跨轮持续；注意其评判者只看会话中已呈现的证据，不会独立跑命令或读文件；
• Ralph：单所有权实现，必须完成全部 PRD story 且经 reviewer 验证；
• Team：显式任务所有权的并行工作 + 分阶段验证；
• Artifact-only Ultragoal：只有持久目标台账/检查点、没有活动执行循环时的规划与交接场景。

另外 HOOKS.md 给出了钩子层的冲突裁决顺序：cancel 优先级最高，其次 ralph > autopilot > ultrawork。如果你同时触发了多个模式关键词，按这个顺序理解哪个生效。

运行中怎么核对状态，结束后怎么验证

运行中：HUD 状态栏显示当前阶段、活跃 agent 数、任务完成数与上下文占用（前文 autopilot 的示例同样适用于其他模式）；状态文件位于.omc/state/{name}.json（项目级），全局备份在~/.omc/state/{name}.json，模式与文件的对应关系：

文档特别强调：不要把 OMC 状态存进~/.claude/，那是 Claude Code 自己的目录。

结束后，三个模式的"完成"都不是以进程停下来的那一刻为准，而是以各自证据为准：autopilot 看 Phase 4 全验证者批准 + 新鲜测试/构建输出；ralph 看 prd.json 全passes: true+ 新鲜测试/构建 + reviewer 批准 + 回归重验证通过；team 看全部真实任务终态 + shutdown 确认 + 状态已清理。清理统一走/oh-my-claudecode:cancel——它自动检测活跃模式（autopilot、ralph、ultrawork、pipeline 等），不要手动删状态文件替代它。

如果你的任务同时命中了多个模式关键词（例如 "don't stop 并 build me 一个 REST API"），按本文的决策顺序先确定主循环权威（持久化 → ralph；单一交付物自主 → autopilot），其余模式只作为其内部组件出现，而不是并排调用。

【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode