一个 API 模型曾长期只有两个固定名字：一个对应对话，一个对应推理。调用方按名字写好提示词、跑通流程，直到某天发现输出不对了——名字没变，后端模型已经被换过，且没有任何通知。这是录制前一年的普遍体验，也是许多“模型变笨”讨论的起点。
模型名是使用者与服务之间最基础的契约。讨论这个契约为什么松动，需要把混在一起的几件事分开。
版本号正在消失
滚动发版正在成为行业默认做法。厂商先发 Preview 试探口碑；有的用日期代替版本号；有的宣布线上持续更新、不再出版本号，默认一周更新好几次。对厂商，这是把后训练的迭代速度直接暴露给用户；对使用者，这意味着“我调用的是哪个模型”不再有确定答案。
这对评测是一把双刃剑：没法再针对某个版本说它烂，反过来也没法说它好。曾经“某个版本模型能力强”这种可以固化的公共认知，正在失去载体。
厂商对名字的松紧，跟着商业模式的重量走。同一家厂商，早先以“顺手用用”的姿态发布模型，基本不理会用户诉求；随着商业化深入、开始服务企业客户，它对反馈的响应明显变快，有争议的调整也会撤回。一个模型服务越接近公共基础设施，名字的稳定性就越不是技术细节，而是承诺。
名字背后的四件事
用户感知到的“变了”，其实是四件不同的事在各自变化。
一是更新：后端模型悄悄更换，行为随之改变。固定名字的设计初衷是让调用方无感升级，代价是行为差异只能由使用者自己发现。
二是路由：录制前不久发生的一起争议里，一个模型 ID 被临时指向了另一个更便宜的模型，几天后又改回去。名字、价格和实际模型三者短暂脱节，对按名字编程的使用者来说，这就是接口变化。这次操作虽然短暂，讨论里仍指出了它的性质差异：持续更新自己的模型，与把一个 ID 指向别的模型，是两件事——前者是迭代，后者改变了名字本身的含义。
三是计价：面向企业的服务需要价格稳定。模型频繁滚动更新时，一万家企业如何跟着你调定价、调预算，是很麻烦的事。这也是为什么有人认为，愿意挣企业服务钱的厂商，需要提供稳定版本；不愿意做的，等于把这个市场让给第三方——而第三方转售通常要在速度和缓存效率上付出代价。
四是兼容：提示词、插件和工作流都建立在特定行为之上。值得留意的是，提示词在产品中的影响比例这两年其实在下降，更多约束被内化进模型；但工作流对“行为可预期”的依赖没有降低，反而更高了。
“变笨”的争论，先拆成可核对的观察
同一时期，“模型变笨”的讨论在社区反复出现。这个印象本身值得先描述清楚：同一个模型，刚上线时口碑很好，过一段时间却被普遍认为不如从前。流传的解释包括：把简单问题路由给小模型、调控思考量、调整输出策略等。这些说法来自社区对服务的逆向猜测，没有厂商证实，不能当作结论。可以确认的事实要少得多：确实发生过 bug 导致的质量问题——用户大规模反馈后厂商排查修复；对异常使用行为的限制属于产品策略，与模型能力是两回事；而使用者的体感是真实的，值得认真对待。
指控“故意降智”既难以证实，也无助于解决问题。真正缺的是证据：同一任务、同一设置、不同时间的输出记录。有了这组对照，才能区分是模型变了、路由变了，还是使用方式变了。社区口碑在这个过程里反应最快，但样本有偏差，适合当作线索，不适合当作归因。
把失败案例留下来
对依赖模型的工作流，可行的做法是补上厂商没提供的那部分：记录每次调用的版本信息、参数设置和输出结果。出现异常时，先对照记录确认“哪里变了”，再决定是改提示词、锁定第三方稳定版本，还是调整流程。服务商做内部评测，同样需要这种可复现的场景，而不是凭一次体验下结论。
模型名字大概率会越来越抽象——日期、代号、持续更新的大版本。契约松动之后，可靠性的一部分责任转移到了使用者手里：谁留住了记录，谁才有资格判断“到底什么变了”。