三个月实战后的 Sonnet 4.6 / GPT-5.5 / Gemini 3.1 日常路由

一句话结论

作者按任务类型在三个标签页间路由：Sonnet 4.6 负责长文档、文风和代码边角推理，GPT-5.5 负责结构化输出和工具调用，Gemini 3.1 负责时效与超长上下文；Sonnet 覆盖其约 90% 工作，Opus 大约每周才需要一次。

适用场景

• 适合的任务：同时处理文档分析、写作、代码边角案例、表格/报告和近期事件检索，并愿意承担切换成本。

• 不适合的任务：需要单一会话内连续上下文、不能重贴材料的任务；也不是可复现的受控评测。

• 适用的模型版本：作者明确写的是 Claude Sonnet 4.6、GPT-5.5、Gemini 3.1 Pro；Opus 仅作为低频升级。

• 适用的客户端、Agent 或 API：三个独立聊天标签页；作者强调每次切换都要重贴上下文。

• 推荐的推理档位和参数：帖文未给出 effort / thinking 配置。

可直接使用的内容

这是路由清单，不是模型提示词。按任务选模型，不要把下面内容发给模型当 system prompt：

路由规则（复制后按任务勾选，一次只选一个主模型）

1. 选 Claude Sonnet 4.6，当任务是：
   - 需要细读的长文档
   - 写作，且语气和用词精度重要
   - 代码里的边角案例推理
   - 本能反应是“先仔细想”的问题

2. 选 GPT-5.5，当任务是：
   - 表格、报告、固定格式摘要
   - 把复杂事情讲给非技术人员
   - 更看重可预期输出、而不是深度
   - 需要工具 / function calling

3. 选 Gemini 3.1 Pro，当任务是：
   - 明显依赖近期事件
   - 超长上下文且不能明显掉质量
   - 需要和 Claude / GPT 不同的检索角度

4. 只有任务明显开放、探索性强时再升到 Opus。
   作者自报：Sonnet 能处理约 90% 输入；Opus 大约每周一次。

5. 切换前准备：
   - 三个模型分三个标签页
   - 每次切换重新粘贴同一份上下文
   - 接受切换开销；只在复杂任务上值得

评论区补充的分层（不是原帖作者的清单，但可一并试验）：

Haiku 适用（vezwyx）：无分析的摘要、套话、小块明确代码、写 PR。
Haiku 不适用：需要记住两轮之前信息的对话。
Haiku 子代理（Fun-Fish3077）：需要读大量上下文只为写计划时，可派 Haiku 子代理。

测试/工作流步骤

1. 准备 10–20 个真实任务，事先标好“长文档 / 结构化输出 / 近况检索 / 代码边角 / 开放探索”。

2. 每个任务只按上表选一个主模型，保存完整输入、输出和是否重贴上下文。

3. 记录切换次数、重贴耗时、一次通过率和需要改写的次数。

4. 对失败任务再试 Opus，统计“每周真正需要 Opus”的比例，而不是默认全程 Opus。

原始证据与数据

• 原帖明确写“Not benchmarks — actual tasks, actual results.”，没有公开逐任务日志、仓库或评分表。

• 作者回复称 Sonnet 处理约 90% 输入，Opus 大约每周一次。

• war4peace79 确认自己绝大多数情况用 Sonnet 且满意。

• Timo425 认为 Sonnet 性价比一般，自己的路由是 Composer 2.5 做杂活、GPT-5.5 做较难任务、Opus 做最难探索；认为 Sonnet 对日常任务偏贵。

• vezwyx 认为 Haiku 会丢掉两轮前的基本推断，只适合无推理的轻任务。

适用边界

• 这是个人路由经验，样本是作者自己的日常工作，不能外推到所有团队。

• 没有公开提示词、effort、客户端版本或对照实验。

• “三个标签页 + 重贴上下文”本身会损失连续记忆；有统一 workspace 的产品不必照搬。

• 评论区对 Sonnet 是否“偏贵”存在分歧，路由表应配合自己的单价和失败成本。

来源摘录或观察（仅做合规短引）

作者原文把 Sonnet 4.6 用在 “Long documents that need nuanced analysis” 和 “Reasoning through edge cases in code”（合规短引）。