多模型博弈

核心理念：多模型意见一致，再行动。

单个模型容易写得流畅、也容易走偏。ShunCode 让几个模型从同一起点独立想一遍，先对齐方案，再切到 Code 改仓库。共识经过交叉验证，任务成功率会明显高于「一个模型说完就动手」。

博弈发生在 Plan 模式。这一阶段只有只读工具，模型可以查代码、争对错，但还不能 apply_patch。没对齐之前，仓库保持不动。

视频教程

在 Bilibili 打开

为什么这能提高成功率

• 同一问题被不同模型独立分析，减少「一家之言」。
• 合并时要写清共识、分歧和依据；对不上的地方会标出来，而不是悄悄选边。
• 只有被采纳的那一条进入后续上下文，后面的 Code 步骤不会混进互相打架的方案。
• 分歧大时不自动执行，由你拍板。

怎么玩

1. 切到 Plan，用模型 A 正常提问，得到第一份方案。
2. 换成模型 B，清空输入框再点发送。此时是分支作答：从上一回合之前的上下文重新想，不看 A 的答案。
3. 需要的话再换模型 C，同样空输入发送。
4. 至少两个分支后，动作行出现 合并总结。合并模型阅读全部分支，必要时只读核对文件，写出：
   • 共识要点
   • 分歧点（带验证依据）
   • 最终方案
5. 合并结果默认成为主线。也可以手动「采纳此分支」。
6. 方案对齐后，再切到 Code 动手。

主线:  提问 Q ── 方案（被采纳的那一条）── 之后才允许改代码
                 │
        同一起点分头作答（互不看见对方的答案）
                 │
          模型 A    模型 B    合并模型

规则（这是玩法，不是装饰）

规则	用意
只在 Plan 里分支	博弈阶段只读，避免还没共识就改文件
空输入才是分支发送	有字的发送会带上全部上下文，变成普通追问
各分支看不见彼此的回答	真正独立，而不是第二个模型附和第一个
全局串行，同时只跑一个	不排队、不并发写，结果可对比
只有 canonical 进入后续对话	后面的步骤只执行一条对齐过的方案
合并默认可做只读核对	用仓库里的事实裁决分歧，而不是比谁更会写

左右箭头只切换这一回合的展示，不改变主线。重试、复制作用于当前看到的那一个变体。

建议怎么用

• 架构取舍、重构边界、该不该动公共模块：先博弈，再 Code。
• 简单改文案、改一行配置：不必开分支，直接 Code。
• 合并结果里分歧仍大：不要急着切 Code，先采纳你认的那条，或再开一个分支。

设置项在 shuncode.multiModel：是否开启、合并用哪一个模型、每回合最多几个分支、合并时是否允许只读核对。

更短的模式对照见 Ask / Plan / Code。