别迷信旗舰模型：AI 任务的按需路由思维

刚开始大量使用 AI 辅助编程的时候，我有一个根深蒂固的习惯：什么任务都用当前最强的模型。理由很朴素——反正又不会更差，为什么要冒风险用小模型？

这个逻辑表面合理，但它忽略了几个真实代价：旗舰模型更慢，响应延迟显著影响交互节奏；在大量并发任务下，成本以平方级累积；更重要的是，这种「一律拉满」的做法让人失去了对任务复杂度的感知。你开始分不清什么是真正需要深度推理的任务，什么只是机械的格式转换。

三档路由：一个够用的决策框架

我用的是一个极简的三档模型：

| 任务类型 | 推荐层级 | 典型例子 | |---|---|---| | 深度架构推演、模糊权衡、跨文件不变量分析 | 旗舰（如 Opus） | 分布式系统设计、根因诊断、跨模块重构方案 | | 功能实现、bug 修复、代码生成、有上下文的写作 | 中档（如 Sonnet） | 写一个新接口、改一处逻辑错误、起草文档初稿 | | 简单问答、格式转换、快速查询、摘要 | 轻量（如 Haiku） | 翻译三行文字、提取 JSON 字段、生成变量命名建议 |

关键不是这三个模型的名字，而是判断任务落在哪一格的那个思维动作。

「只在下一档失败时才升级」

这是我用下来最有效的一条操作原则。

意思是：从中档开始，输出有明显推理缺口再升到旗舰；从轻量开始，输出质量不满足再升到中档。升档的依据是「上一档给出了有推理缺口的输出」，而不是「感觉这个任务看起来很难」——后者是经验主义在作怪，很多「看起来难」的任务其实只是信息密集，不是推理密集。

反过来，「降档」也值得刻意练习。很多人写了一个复杂 prompt、用旗舰模型跑了一遍，发现效果不好，于是反复调 prompt，却从没想过：问题可能不是模型能力，而是任务定义本身含糊，或者需要拆成两步而不是一步。

路由背后是对任务的清醒认知

强迫自己做路由决策，有一个意外的副作用：它逼你在启动前就想清楚任务的本质是什么。

「这是一个纯格式变换，还是需要跨上下文推理？」——这个问题本身就值得问。很多时候你发现自己说不清楚，任务边界是模糊的，或者把多个不同类型的任务混在了一起。这时候正确的动作是先拆分任务，而不是选模型。

所以模型路由不只是成本优化手段，它更是一个任务清晰度的照镜子工具。每次你能顺利做出路由决策，说明你对任务理解得够清晰；每次你犹豫不决、感觉哪档都不太对，往往说明任务本身需要先重新定义。

一句话心法

路由决策的价值不只是省钱，更在于它强迫你在执行前说清楚任务到底是什么。