ray-multimodel

name	ray-multimodel
description	在 Grok、Claude、Codex 之间按任务价值做最小充分分工，并由当前会话担任主控完成验收。用于用户明确要求「让 Grok 先做」「多模型协作」「两家独立给方案」「模型竞赛」「找第二意见」「用 Grok 查 X / 实时反馈」，或任务本身值得引入跨模型执行、复核、竞赛、实时调研时。支持 auto / fast / review / race / scout 五种入口；默认 Grok 承担清晰且产量大的执行与 X 调研，Claude 承担高判断工作，Codex/当前主控整合并验证。不用于没有明显收益的简单问答，也不允许多个模型同时写同一工作区、静默换模型或用模型自报代替实际验证。触发：/ray-multimodel。

ray-multimodel：多模型协作

把模型当成不同工种，不当成投票器。当前会话始终是主控：理解目标、写任务包、选择通道、控制权限、比较证据、完成最终验收。外部模型只承担边界清楚的工作。

用法

/ray-multimodel auto <任务>    # 自动选择最小充分组合
/ray-multimodel fast <任务>    # Grok 优先完成清晰任务，主控验收
/ray-multimodel review <对象>  # 另一模型独立复核，默认只读
/ray-multimodel race <任务>    # 两条独立通道竞争，主控按证据裁决
/ray-multimodel scout <议题>   # Grok 优先查 X / 网页，主控核实来源

用户没写模式时使用 auto。用户明确点名某家时尊重指定，但仍保留隔离与验收规则。

一、先判断值不值得分发

只在至少满足一项时引入外部模型：

• 工作量大但规格清楚，外部执行能节省主控上下文。
• 错误代价高，需要另一模型独立找盲点。
• 两种方案都合理，值得并行比较真实产物。
• 需要 X、网页或实时舆情，Grok 有明显通道优势。
• 用户明确要求使用某家或多家。

简单改写、单一事实、一步操作默认由当前会话直接完成。不要为了展示“多模型”而增加往返。

二、选择模式

模式	默认通道	适用情况	写入规则
fast	Grok	规格充分的实现、机械修改、批量初稿	代码写入独立工作区；非代码写入单独产物文件
review	与产出者不同厂商的模型	查错、反例、遗漏、回归风险	只读，不改原产物
race	Grok + 另一家	高价值方案或实现，需要比较	方案只读；实现必须各用独立工作区
scout	Grok	X、网页、竞品反馈、最新争议	只读；不得发布、点赞或发送消息
auto	主控选择	用户只说“多模型处理”	采用上面最小充分的一种

默认不要一次调用三家。两条独立通道通常已经足够；第三家只在用户点名或前两条证据冲突且影响重大时加入。

三、建立主控与通道

1. 把当前会话设为主控，不递归调用与当前会话相同的 CLI。
2. 检查所选 CLI 是否存在、已登录、能返回当前可用模型。每条检查单独执行，避免复合命令触发授权循环。
3. 不写死模型版本；使用账户当前可用的默认模型，除非用户明确指定。
4. 只把完成子任务必需的上下文交给外部模型。绝不传递密钥、令牌、私密配置或无关文件。
5. 分发前标记材料为公开、内部或敏感。外部 CLI 会把所给内容发送给对应厂商；只有用户授权范围和当前数据策略都允许时才分发。
6. CLI 调用与权限建议见 references/cli-recipes.md。

若通道不可用，返回 STATUS: unavailable 和原始原因。未经用户或主控明确决定，不得悄悄换成另一家。

四、写完整任务包

每条通道都看不到主控的完整对话。分发前必须写完五部分：

1. 目标：这次只完成什么。
2. 输入与范围：允许读取的材料、允许修改的文件。
3. 交付物：文件、方案、字段或接口长什么样。
4. 约束：不能碰什么、权限边界、是否禁止再次分发。
5. 验收：主控可以重新执行的检查，以及必须返回的证据。

直接使用 references/task-contract.md 的任务包与回报格式。写不完任务包，说明主控还没做完判断；不要把歧义外包。

五、按模式执行

fast：Grok 优先执行

1. 把已经充分确定的工作交给 Grok，不让它重新定义需求。
2. 涉及代码或原文件修改时，先建立独立工作区；禁止 Grok 与主控同时写主工作区。
3. 要求 Grok 返回实际变更、自己运行过的检查和未完成项。
4. 主控读取真实产物或差异，并独立重跑验收；Grok 的“完成”不是证据。
5. 验收失败时，把失败证据写入修正任务包再交回同一通道；不要由主控偷偷补丁后仍声称 Grok 完成。

review：独立复核

1. 选择与原产出者不同厂商的模型；不知道原产出者时优先 Grok 或 Claude 中尚未参与的一家。
2. 默认只给原始需求、产物和检查结果，不给主控先前的评价，减少锚定。
3. 要求按严重度列问题，并为每项给出可定位证据；禁止直接修改。
4. 主控逐项复核，不因复核者措辞自信就接受结论。

race：独立竞赛

1. 给两条通道完全相同且冻结的任务包，不让它们看到对方答案。向用户说明竞赛采用了“同题、盲跑”，不能只在内部默认。
2. 方案竞赛保持只读；实现竞赛分配两个独立工作区，绝不共享写入目录。
3. 等两条通道都交付后再裁决。完成速度只能记录，不能作为胜出条件。“谁先通过就用谁”不是竞赛，而是昂贵的抢跑。
4. 回收后匿名标为 A / B，按正确性、证据、范围纪律、可维护性、不确定性处理五项比较。
5. 选择较强产物或组合互补部分，但组合后必须重新验收。
6. 不用“多数意见”裁决；两条相同结论仍可能共享错误前提。

若用户真正优先的是速度，把任务改走 fast：只启用一条写入通道，交付后再用另一家做只读 review。不要同时启动两个写入者、拿第一个通过者就取消另一边，却把它称为跨模型竞赛。

scout：Grok 实时调研

1. 明确时间范围、平台、关键词和要回答的商业问题。
2. 要求 Grok 返回来源标题、作者/机构、日期、原始链接、支持哪条判断。
3. 把“发现线索”和“确认事实”分开。主控打开关键链接，优先用官方或一手来源核实。
4. X 帖子只代表公开表达或样本，不自动外推成市场事实。
5. 只允许搜索和读取，不得发帖、互动、私信或改动外部账户。

六、权限与隔离闸门

• 只读优先：调研、复核、架构建议一律只读。
• 单写者：同一目录同一时间只允许一个写入者。
• 隔离实现：代码竞赛和 Grok 写代码使用独立工作区；主控验收后再决定是否整合。
• 不越权：禁止使用跳过全部授权、关闭沙箱或无限制自动批准。
• 不破坏：删除、覆盖、发布、部署、发消息仍遵守原任务授权；本 Skill 不扩大权限。
• 不递归：任务包明确“不要再调用其他模型或子代理”，防止成本和责任链失控。
• 不绕数据保护：未公开仓库、客户材料和内部文档被外发策略拦截时，停止该通道；改用公开合成样例、本地校验，或明确向用户申请授权，禁止换路径绕过。

七、主控验收

接受外部回报前必须完成：

1. 对照任务包检查范围，确认没有多做或漏做。
2. 查看真实文件、差异、链接或输出，不只看总结。
3. 重跑验收命令或代表性检查。
4. 检查失败、空结果、权限拒绝和超时是否被如实披露。
5. 明确最终采用了哪条通道的什么内容，以及主控做了什么验证。

只有主控完成上述检查后才可向用户说“完成”。

八、失败处理

• unavailable：保留原任务包，说明哪家不可用和原因；由主控决定是否改道。
• permission_denied：把复合操作拆开，缩小授权范围；不得改用全放行。
• timeout：保留已生成产物和最后输出，先判断是否可验证，再决定续跑或改道。
• partial：明确已完成、未完成、当前产物位置和下一条最小任务。
• 通道结论互相冲突：比较证据；若仍不能裁决，再引入第三家或向用户暴露真正的决策点。

完成标准

最终回报必须让用户看清：为什么用了这些模型、各自做了什么、主控实际验证了什么、结果是否已可用。不要汇报冗长的模型对话过程。

若采用 race，计划与最终回报还必须明确写出：两边收到同一份任务包、互相不可见、使用独立工作区、主控等待双方后按证据比较。缺任何一项都不能称为跨模型竞赛。