<使用时间> * 用户希望从想法到工作代码的端到端自主执行 * 用户说“自动驾驶”、“自动驾驶”、“自主”、“构建我”、“创造我”、“让我”、“全自动”、“处理这一切”或“我想要一个...” * 任务需要多个阶段：规划、编码、测试和验证 * 用户想要放手执行并愿意让系统运行完成 <何时不使用> * 用户想要探索选项或集思广益——使用“计划”技能 * 用户说“只需解释一下”、“仅草稿”或“您有什么建议”——以对话方式回复 * 用户想要单一的集中代码更改 - 使用“ralph”或委托给执行代理 * 用户想要审查或批评现有计划——使用“plan --review” * 任务是一个快速修复或小错误 - 使用直接执行程序委托大多数重要的软件任务都需要协调各个阶段：了解需求、设计解决方案、并行实施、测试和验证质量。 Autopilot 自动编排所有这些阶段，以便用户可以描述他们想要的内容并接收工作代码，而无需管理每个步骤。 <执行策略> * 每个阶段必须在下一阶段开始之前完成 * 尽可能在阶段内使用并行执行（阶段 2 和阶段 4） * QA 周期最多重复 5 次；如果相同的错误持续出现 3 次，请停止并报告根本问题 * 验证需要所有审稿人的批准；被拒绝的项目得到修复并重新验证 * 随时使用 `/cancel` 取消；保留进度以供恢复 * 如果存在深度访谈规范，请将其用作高清晰度阶段输入，而不是从头开始重新扩展 * 如果输入对于可靠扩展来说太模糊，请首先提供/触发“$deep-interview” * 在预先背景基础存在之前，不要进入扩展/规划/执行密集的阶段；如果被迫快速执行，则仅在明确的风险说明下继续 * 默认为简明、证据密集的进度和完成报告，除非用户或风险级别需要更多细节 * 将较新的用户任务更新视为活动工作流分支的本地覆盖，同时保留早期的非冲突约束 * 如果正确性取决于额外的检查、检索、执行或验证，请继续使用相关工具，直到工作流程落地 * 自动继续执行清晰、低风险、可逆的后续步骤；仅当下一步是实质性分支、破坏性或依赖于偏好时才询问 1. **阶段 0 - 扩展**：将用户的想法转化为详细的规范 * 如果此任务存在`.omx/specs/deep-interview-*.md`：重用它并跳过多余的扩展工作 * 如果提示非常模糊：路由至“$deep-interview”以进行苏格拉底式模糊性门控澄清 * 分析师（全面层）：提取需求 * 架构师（全面层）：创建技术规范 * 输出：`.omx/plans/autopilot-spec.md` 2. **阶段 1 - 规划**：根据规范创建实施计划 * 架构师（全面层）：制定计划（直接模式，无面试） * 评论家（彻底层）：验证计划 * 输出：`.omx/plans/autopilot-impl.md` 3. **第 2 阶段 - 执行**：使用 Ralph + Ultrawork 实施计划 * 低层执行者/搜索角色：简单任务 * 标准层执行者角色：标准任务 * 彻底的执行者/架构师角色：复杂的任务 * 并行运行独立任务 4. **第 3 阶段 - QA**：循环直至所有测试通过（UltraQA 模式） * 构建、lint、测试、修复失败 * 最多重复 5 个循环 * 如果相同的错误重复 3 次，请尽早停止（表明存在根本问题） 5. **第 4 阶段 - 验证**：并行多角度审查 * 架构师：功能完整性 * Security-reviewer：漏洞检查 * Code-reviewer：质量审查 * 必须全部同意；修复并重新验证拒绝 6. **阶段 5 - 清理**：成功完成后通过 OMX MCP 工具清除所有模式状态 * `state_clear({模式: "自动驾驶仪"})` * `state_clear({mode: "ralph"})` * `state_clear({模式: "ultrawork"})` * `state_clear({mode: "ultraqa"})` * 或运行 `/cancel` 干净退出 <工具_用法> * 在第一次使用 MCP 工具之前，调用 `ToolSearch("mcp")` 来发现延迟的 MCP 工具 * 使用 `ask_codex` 和 `agent_role: "architect"` 进行第 4 阶段架构验证 * 使用 `ask_codex` 和 `agent_role: "security-reviewer"` 进行第 4 阶段安全审查 * 使用 `ask_codex` 和 `agent_role: "code-reviewer"` 进行第 4 阶段质量审核 * 代理商首先形成自己的分析，然后参考 Codex 进行交叉验证 * 如果 ToolSearch 发现没有 MCP 工具或 Codex 不可用，则不使用它继续 - 永远不会阻止外部工具 ## 状态管理使用“omx_state”MCP 工具获取自动驾驶仪生命周期状态。 * **启动时** : `state_write({mode: "autopilot", active: true, current_phase: "expansion",started_at: "", state: {context_snapshot_path: ""}})` * **关于阶段转换** : `state_write({mode: "autopilot", current_phase: "planning"})` `state_write({mode: "autopilot", current_phase: "execution"})` `state_write({mode: "autopilot", current_phase: "qa"})` `state_write({mode: "autopilot", current_phase: "validation"})` * **完成时** : `state_write({mode: "autopilot", active: false, current_phase: "complete",completed_at: ""})` * **取消/清理** ：运行 `$cancel` （应该调用 `state_clear(mode="autopilot")`） ## 场景示例 **好：** 在工作流程已经有了明确的下一步之后，用户说“继续”。继续当前的工作分支，而不是重新启动或重新提出相同的问题。 **好：** 用户仅更改输出形状或下游交付步骤（例如“制作 PR”）。保留早期不冲突的工作流程约束并在本地应用更新。 **不好：** 用户说“继续”，工作流程会重新启动发现或在收集缺少的验证/证据之前停止。 <升级和停止条件> * 当相同的 QA 错误在 3 个周期中持续存在时停止并报告（需要人工输入的基本问题） * 3轮重新验证后验证仍然失败时停止并报告 * 当用户说“停止”、“取消”或“中止”时停止 * 如果要求太模糊并且扩展产生不明确的规范，请在继续之前暂停并重定向到“$deep-interview” <最终清单> * 已完成所有 5 个阶段（扩展、规划、执行、质量保证、验证） * 所有验证者均在第 4 阶段获得批准 * 测试通过（使用新的测试运行输出进行验证） * 构建成功（使用新的构建输出进行验证） * 状态文件已清理 * 用户获悉完成情况并附有所构建内容的摘要 `~/.codex/config.toml` 中的可选设置： [omx.自动驾驶仪] 最大迭代次数 = 10 最大Qa周期 = 5 最大验证轮次 = 3 扩展后暂停 = false 计划后暂停 = false 跳过Qa=假跳过验证 = false ## 简历如果自动驾驶仪被取消或失败，请再次运行“/autopilot”以从停止的位置恢复。 ## 推荐的澄清度管道对于不明确的请求，首选：深度访谈 -> ralplan -> 自动驾驶仪 *“深度访谈”：含糊不清的苏格拉底要求 * `ralplan`：共识规划（规划师/建筑师/评论家） * `自动驾驶仪`：执行 + QA + 验证 ## 输入的最佳实践 1. 域名要具体——“书店”而不是“商店” 2. 提及关键功能——“带有 CRUD”、“带有身份验证” 3.指定约束——“使用TypeScript”、“使用PostgreSQL” 4. 让它运行——除非真正需要，否则避免中断 ## 管道编排器 (v0.8+) Autopilot 可以由可配置的管道编排器 (`src/pipeline/`) 驱动，它通过统一的 `PipelineStage` 接口对各个阶段进行排序： RALPLAN（共识规划）-> team-exec（Codex CLI 工作人员）-> ralph-verify（架构师验证）管道配置选项： [omx.自动驾驶仪.管道] maxRalphIterations = 10 # Ralph验证迭代上限 workerCount = 2 # Codex CLI 团队工作人员数量 agentType = "executor" # 团队工作人员的代理类型管道通过“pipeline-state.json”保留状态，并支持从最后一个未完成阶段恢复。有关完整 API，请参阅“src/pipeline/orchestrator.ts”。 ## 故障排除 **陷入某个阶段？** 检查 TODO 列表中是否有被阻止的任务，运行 `state_read({mode: "autopilot"})`，或取消并恢复。 **QA 周期已耗尽？** 相同的错误 3 次表明存在根本问题。检查错误模式；可能需要手动干预。 **验证不断失败？** 查看具体问题。要求可能过于模糊——取消并提供更多细节。

自动驾驶仪

包含技能