dev.to 上那篇聊"开发者过度依赖前沿模型"的帖子，评论区有一段话挺扎眼的：你把模型排行榜闭着眼拉到顶配，然后拿它去查天气。这话有点损，但基本属实。同一天我刷到另一个消息——今年 AI Engineer World's Fair 的研讨主题，已经从 RAG、提示工程那一套，转移到了评估与开放模型。两件事放在一起看，指向的是同一个问题：模型能力早就不是主要瓶颈了，可绝大多数人的使用习惯，还停在被瓶颈支配的那个年代。
这篇想拆的，不是"该不该用最强模型"——这种判断交给你自己下。我想拆的是另一层："模型选择"这个动作本身，一直被放在错误的位置上，以至于很多人根本没意识到它是可以被挪的。
先把那个前提捋清楚：快速模型距离前沿模型，已经没多远了。Sonnet 4.6 跟半年前的 Opus 4.1 打得有来有回，Gemini Flash 3.5 敢跟 Pro 3.1 坐在同一桌，GPT-5.4 Mini 也蹭到了大模型的边。就算你对这些对比打个对折——快速模型依然只需要前沿模型一个零头的成本，响应速度还明显更快。
说人话就是："最强模型"这件商品的保质期，正在肉眼可见地变短。半年前你花大价钱才能拿到的能力，半年后就是标配，零头价。这带来一个很直接的推论——你为"最强"付的溢价，买的是差不多半条命的时间差。而工程里绝大多数任务，压根用不着这半条命。
那问题来了：明明用不上，为什么还是默认最强？
这里最容易被搞混的是：工程师选前沿模型，和任务需要前沿模型，是两件事。选便宜的出了错，账记在"你选了不合适的工具"上；选最贵的出了错，账记在"模型还不够好"上——反正你已经把能拿出来的最好的给了它。这个归因结构的不对称，才是无数"顺手拉满"的真实驱动力。说人话就是：选最贵的模型，永远不会是账面上你个人的错。这笔溢价买的不是能力，是出事时不背锅的资格证。这句话有点重，但机制层面它就是事实。
上面这些都还算表层。真正有意思的是另一件事：模型选择这个动作，在现在的技术栈里发生在什么位置上。
大多数人的答案是：写在代码里，写一次，之后每次请求都复用这一个选择。但一个 agent 循环里的每轮任务，难度分布其实极不均匀。你让 agent 去把一坨遗留系统接进新 API——前几轮它只是在读文件、列清单、整理调用关系，这种活儿 Mini 干得绰绰有余；要到最后一轮，真正涉及重构那个继承了三层的诡异类的时候，才轮到最强模型上场。现在的做法是什么？一张 prompt 写死，从头到尾用同一个模型。等于你为了最后十分钟的楼顶施工，给整栋楼都租了一圈塔吊。这个类比到这儿就该收了——机制上，它说的是：你在用一个全局的静态决策，覆盖一个局部波动很大的运行时需求。
还有一层容易被忽略的：在 agent 循环里，最强模型的质量优势，会被错误的传播方式进一步稀释。模型在这一轮的工作方式，是把"目前发生了什么"整个塞回上下文，然后重新采样一次"下一步该干嘛"。上一轮如果出了个错，这个错不会自动浮出水面，它只是变成上下文的一部分，被下一轮当成既成事实继续推演。也就是说，一个模型在循环里的表现，很大程度取决于前面环节给它喂的料有多干净。单次输出的质量优势，在迭代中被摊薄了——那些不该传到后面的低级错误，如果不靠外部机制拦截，照样会传给最强的模型，让它陪着错下去。
所以"动态路由"这个词听起来就是正解：运行时根据任务复杂度决定这一轮用哪个模型。我一开始也这么以为，直到发现它把问题换了个位置——谁来判定"这一轮有多难"？你用一个分类器去判，分类器本身的准确率就决定了整个方案的上限。判错了，该上重炮的时候派了侦察兵，输出糊了；不该上的时候上了，成本没省下来。动态路由不是没解，但它的解本身就是评估问题：你得先能判断一轮任务的复杂度，才谈得上给它配模型。而判断复杂度，跟判断输出质量，是同一个困难的两种形态——都需要你对"什么算好"有一条说得清的标尺。
你回看那篇帖子底下的评论，会发现有意思的事。有人提：默认用快速模型，用户不满意了再升级或者重新生成——这个方案本质上是把"模型选择"从工程师写码那一刻，挪到了每一次请求发生的时刻。也有人算过另一笔账：如果你有可靠的评估和状态管理，跑五次便宜模型、挑最好的一次，多半比直接调一次最强模型便宜。两条建议的路子不同，但地基是同一块——评估。再往下，就是那条被反复点名的：模型选择根本不是瓶颈，瓶颈是"我们凭什么相信 AI 输出"的基础设施一直没建齐。
今年 AI Engineer World's Fair 把主题从 RAG 转向评估，顺着这个逻辑看就顺理成章了。RAG 回答的是"模型不知道的怎么让它知道"，这个问题已经有了标准答案，可以按部就班地上线；但"模型给出一个答案，我怎么知道能不能信"——所有人都卡在这一步。开放模型的受重视，也从侧面印证了同一件事：当模型本身的差距在快速抹平，评估和微调这两件事的可控性，才慢慢成了真正能拉开距离的地方。
这层的难处在于，评估一个模型的输出，本质上是个递归的坑：你要判断"这个回答对不对"，前提是你自己知道对的答案长什么样。而"知道对的答案"这件事，正是模型在替你干的活。所以你没法单纯地用一个更强的模型来充当评审——那个评审模型本身又需要一个评审。这就是为什么评估集、对抗样本、人工标注这些东西永远省不掉：你不是在测模型，你是在定义"什么是对的"。这个定义过程，没法外包给那个被你评估的玩意儿。
所以把整件事压缩回一句话：全用最强模型的习惯，是在用一个笨办法补"没有评估"这个洞——因为没法判断哪次输出可信，就只能用最强的模型来缩短出错的可能性。可模型贬值太快，这条路径的成本一年比一年高，而它买的那个"资格证"，一次都没让你用上过。
模型选择这件事，说到底应该发生在循环内部，由每一轮的实际任务说了算。至于怎么让它发生在那里、由什么信号去驱动、评估那一层怎么补——再往下拆就是评估基础设施的具体设计了，那个坑深。先填到这儿，改天专门开一篇。