技术 · 熟练
模型偷偷换了一版，为什么没人发现？
别把版本交给别名
平台方的「模型名」多数是别名 —— 它指向哪个具体版本，是平台方的运营决定，不是你的决定。你以为自己在用同一个模型，它在某次静默切换后已经是另一版；反过来，当你以为「正在用最新版」时，别名也可能还停在上一版。这一页做两件事：① 把进件侧的版本钉死 —— 组织级托管设置里屏蔽不需要的模型、把可选模型匹配改为「精确版本」、并在代码与配置里一律写带日期后缀的完整 ID 而不是简称；② 审计存量写法 —— 官方已经给了检查工具，专门挑出「为更老的模型写的」提示词、技能与自定义 agent（这类写法在换版后不会报错，只会悄悄变差）。判据一句话：凡是你没法一眼说出「这条链路现在跑的是哪个精确版本」的地方，就是下一个要出事的地方。
方法 · 一图看懂
1
先分清「别名」与「精确版本」，把链路里的模型名逐个定性 —
2
进件侧钉死：托管设置屏蔽 + 精确匹配 + 完整 ID 落配置 —
4
留一条可回退的缝：模型 id 进配置，随每次输出记型号 —
原理 · 为什么有效
为什么必须钉：模型层的寿命表不是你定的。官方把通知期写成了阶梯 —— 正式可用模型至少六个月、专用变体至少三个月，而预览版模型可能以两周这种量级的通知期下线；并且 partner 平台（如云厂商渠道）有自己的一套时间表，同一个模型可以在一条路上还活着、在另一条路上已经没了。这套规则下，「版本漂移」有三种来源，只有第一种你会察觉：① 显式下线（会发公告）② 别名静默改指向（通常不公告，因为对平台方来说是例行运营）③ 你以为在钉版本、其实写的是别名。钉死版本做的事，是把前三种都变成可查的配置事实。另一层：老写法失效是无声的 —— 为上一代模型写的提示词与技能，在新版上不会报错，只会从「很好用」退成「好像也行」，而这种退化最难归因。
适用场景
适用：任何把模型名写进了配置文件 / 脚本 / 定时任务 / 自定义 agent / 保存的默认设置的地方 · 多人协作的仓库（你的版本和同事的不一致时最难查）· 已经把 agent 放进周期性运行的人。不适用：只在网页对话框里手打提问、从不保存设置的人 —— 你没有需要钉的链路，别为一个一次性问题引入配置。
自测 · 5 问
我能说出每条链路正在跑的精确版本 ID（带日期后缀那种），而不是只能说出简称
我的托管设置里屏蔽了不需要的模型，而不是靠「记得别选错」
我跑过一次老写法审计，并处理了它挑出来的项（提示词 / 技能 / 自定义 agent）
模型 id 在配置里，不在代码硬编码里；换版是一次配置改动而不是一次改代码
每次输出旁边能看到当时用的型号，出事时能一眼归因
怎么上手 · 验证步骤
三步，半小时能做完第一步。第一步：把「模型名出现在哪里」清一遍 —— 三类地方各看一遍（代码与脚本里的硬编码 · 定时任务与自动化流程里选的模型 · 客户端设置里保存的默认模型与自定义 agent），每条记下「现在写的名字」。第二步：把每条名字标注成「别名」还是「精确版本」—— 这一标注的动作本身就会暴露大部分风险，因为你会发现绝大多数链路写的是别名。第三步：在托管设置里做两件事，屏蔽掉不该被选到的模型，并把可选模型匹配改为精确版本；然后跑一次官方给的提示词审计，把它挑出来的老写法逐条处理。
改完之后做一个对照实验：把同一份任务分别在「钉死版本」与「别名」两条链路上各跑一次，比对输出差异。这一步的价值不在结果好坏，而在你会亲眼看到「同一个名字」是不是同一个东西 —— 如果两条差异明显，说明你的链路里确实混着两个版本。