计划仲裁者 是做什么的？
将竞争性计划转化为一条可执行的方向。保留最优秀的想法， 拒绝薄弱的假设，并生成清晰的交接文档，而不是混合的模糊产物。
工作流程
- 收集原始计划。
- 将每个计划标准化为可比较的声明。
- 对计划进行相互评审，并将它们与实际代码库或任务上下文进行对比。
- 选择一个胜者，合并出更好的混合方案，或将计划发回进行修改。
- 生成一份包含验证关卡和被拒绝备选方案的执行交接文档。
除非用户明确要求你在决策后实施，否则计划阶段是只读的。
收集原始计划
接受以粘贴文本、本地文件、会话 ID、记录路径、PR、评论、可视化计划链接或聊天历史形式出现的计划。尽可能解析原始产物，以便你可以看到可能从最终摘要中缺失的提示更改和假设。
如果计划仍在编写中且用户要求你等待，则监控该计划直到它完成或被阻止。如果计划无法解析，则继续使用可用的计划文本，并将缺失的来源标记为风险。
标准化
对于每个计划，提取：
- 目标和范围。
- 关键假设和未解决的问题。
- 提议的文件、模块、API、数据形状、UI 状态或工作流。
- 实施顺序。
- 验证策略。
- 回滚或迁移问题。
- 成本、复杂性和预期的执行者适配度。
不要奖励冗长。优先选择具体、基于真实代码且对权衡诚实的计划。
交叉评审
就像另一个能干的代理编写了这些计划一样评审它们：
- 检查它是否满足用户的真实请求。
- 在相关且可用时，对照仓库、文档、测试、截图或外部系统验证声明。
- 识别隐藏的依赖关系、缺失的测试、有风险的排序、模糊的步骤、不必要的范围以及难以逆转的决定。
- 注意互补的优势：一个计划可能有更好的架构，而另一个可能有更好的迁移或验证路径。
- 将计划质量与执行者偏好分开。如果一个执行者更便宜/更快，它可能也是实施的正确选择，即使另一个模型产生了最佳的批评。
当计划很大、代码库很广，或者决策将从独立的技术和产品审查中受益时，使用子代理进行独立评审。
决策
选择以下三种结果之一：
- 采用： 基本按照原样选择一个计划。
- 混合： 将特定部分组合成更强的执行计划。
- 先修改： 请求另一轮计划制定，因为两个计划都错过了关键约束条件或依赖于未解决的决策。
使用以下平局决定顺序：
- 正确性及对用户请求的适配度。
- 基于真实文件、API、测试、数据和 UI 行为。
- 不阻碍未来目标的更简单的初始实施。
- 更好的验证和回滚能力。
- 一旦质量可接受，执行所需的更低 token/时间成本。
交接
返回一份简洁的决策备忘录：
决策
- 采用计划 A / 混合 / 先修改。
原因
- 决定性的证据和权衡。
执行计划
- 有序的步骤，包含需要修改的文件或界面。
从其他计划借鉴
- 从非胜出计划中保留的有用部分。
已拒绝
- 明确不采纳的想法及其原因。
验证
- 需要的测试、浏览器检查、截图、CI、审查或部署检查。
执行者建议
- 应实施此计划的代理/模型及其原因。
当用户已要求执行且选定路径清晰时，在简短报告决策后继续执行所选的计划。否则，在交接处停止并请求批准。