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