通用方法 · 熟练
换了模型，为什么错误率一点没变？
看得见的那类有告警 · 看不见的那类没有
官方下线一个模型，往往不是当天通知、当天生效 —— 平台会先挂「弃用日期」，再挂「关停日期」，中间常留几周。真正让人翻车的不是那条公告，而是公告之外的另一类变化：别名指向悄悄变了、默认模型换了、同一段提示词给出的答案漂了。这类变化不会让你的错误率上升一分，所以任何按错误率排的告警都抓不到它。这一页做三件事：把模型名从调用点搬进配置文件（调用点只写「角色」，比如「审 diff」「提发票字段」）；给每个角色配一段固定提示集 × 固定期望输出的回归，定期跑一次；再把官方变更按日期写进一张能看见的日程。判据只有一句：换了模型，你能不能在三分钟内说出「哪几个角色的输出变了」。
原理 · 为什么有效
为什么按角色而不是按模型组织？因为模型 ID 的寿命比「要做的活」短得多。角色（总结工单 / 审 diff / 提取字段）跨代稳定，模型 ID 每一代都换 —— 把两者绑在一起，你每次都得改代码；把它们分开，改的只是一个数据文件，不用过评审、不用重新发版。第二层机理是可观测性错配：退役公告带来的失败是显式的（`model_not_found` 之类，一告警就响），而别名与默认值带来的失败是静默的 —— 它不改变调用成功率，只改变输出内容，所以只有「固定输入对固定期望」的回归能把它逼出来。第三层是降级链的幻觉：一条「A 模型 → B 模型 → C 模型」的备链看着很稳，实际上每个字符串的到期日都由它自己的厂商排，到期那天主备一起走 —— 降级链解决的是「临时不可用」，不解决「永久退役」。
适用场景
适用：任何有代码或自动化任务在调模型 API 的人；把模型名写在好几个脚本与定时任务里的人；要给团队定「模型升级怎么走」的人；已经吃过一次「某天早上脚本全红」的人。⛔ 不适用：只用网页版聊天、没有任何自动化调用的人（那种情况只需要偶尔看官方公告页）；还停留在手写一次性提示词的临时实验（没到需要回归的规模）。
自测 · 5 问
我说得出自己一共有几个「角色」，以及每个角色现在映射到哪个模型 ID 吗
我的调用点写的是模型名，还是角色名（模型名只在一处配置里出现）
我有一个定期跑的固定提示集吗；没有的话，我凭什么知道输出漂了
我知道哪一类退役会体现在错误率上、哪一类不会吗
我的降级链里，几个模型的到期日是不是都由同一家排的
怎么上手 · 验证步骤
从最小一步开始：① 先在代码里搜出所有出现模型名的位置（脚本 / 配置 / 自动化任务 / 客户端默认设置都算），列成一张清单 ② 给每一处标一个角色名（动词 + 对象，如「审 diff」「提发票字段」），把它们抽进一个单独的文件，调用点只引用角色 ③ 给使用频率最高的那两个角色各写一段回归：一段固定输入 + 一个你能一眼看出对错的期望（⛔ 别用「感觉差不多」当判据）④ 把这两段回归挂到每周一次的定时任务上，结果贴到同一个地方。⛔ 不要一次把所有角色都做回归，也不要为了做回归引入一套评测平台。
做完自己核对三件：① 全局搜一遍，除了那个配置文件，代码里再也搜不到模型名 ② 至少有两个角色有回归，且回归的期望输出是可判对错的（不是一段自由文本）③ 官方变更页在你的日程上有一个固定复查日。三条缺一条，这套就还是「靠记得」。