如果只选一个真实场景来解释这篇文章，我会选“客服混合链路”。
这个链路里同时存在三类请求：
项目最初为了省事，几乎所有请求都默认走最强模型。早期流量小，大家只觉得“效果不错，就是稍微贵一点”。但一旦请求量上来，问题很快暴露：
这也是我后来越来越笃定的一点：不是所有请求都要走最强模型。模型分层不是为了抠预算，而是为了让系统真正进入可运营状态。
如果只讲原则，这篇文章还是会显得空。所以我直接拿一个真实得不能再真实的例子来说：退款工单分诊。
这类任务的目标通常是把用户自然语言输入转成一个后续系统能继续处理的对象，例如：
团队最早的做法很常见：先让模型直接输出一段 JSON，大概长这样：
{
"title": "用户申请退款",
"summary": "用户表示重复支付，希望退款",
"tags": ["退款", "重复支付"]
}
看上去没毛病，前端也能展示，测试样本甚至都能过。但真正进系统后，这种 Schema 很快就会把问题暴露出来：它描述了内容，却没有描述动作边界。
真正让系统难受的不是模型会不会吐 JSON，而是下游根本不知道怎么用这个结果继续执行。
这周我做了一轮很朴素的小模型实验。任务不复杂，就是把用户问题先分到固定类别里，再交给后面的规则链路处理。我原本只是想验证“小而快”的模型能不能扛住这类基础分类，结果最后最有价值的发现并不是成本更低，而是另一个更值得记住的事实：当问题边界足够清楚时，小模型往往比大家想象中更稳。
当时的任务很像很多团队都会有的第一层网关能力：先判断用户意图，再决定往知识检索、订单查询、人工转接还是普通 FAQ 解释去走。它没有复杂推理，也不追求文风，只要求三件事：标签别漂、格式别乱、延迟别太高。
过去一年我最常被问到的问题，不是“哪个模型更强”，而是“这个业务值不值得接大模型”。我后来发现，很多团队在这个问题上一开始就问歪了。他们问的是“技术上能不能做”，而不是“产品上值不值，工程上扛不扛得住，出问题以后谁来接”。
为了让这个判断不要继续停留在口头经验里，我后来逼自己把它压成一套更像决策表的东西。它不保证每次都选对，但至少能逼团队先看代价，而不是只盯着 Demo 效果。