技术 · 熟练
最危险的下线，是调用还成功
报错会被人发现，静默改路由不会
「下线」有两种：一种会报错，一种不会。会报错的那种反而安全 —— 它制造了一个必须处理的事件，凌晨也会被看见。不会报错的那种只是把你的请求转给另一个模型：ID 没变、代码没动、日志照旧写着旧名字，而答你的已经是别人。这一页给一条判据：一个模型 ID 是不是还在「服务你测过的那个模型」，要看三处 —— 替代栏、有没有关停日期、以及你自己的 token 曲线在变更日前后有没有台阶。然后给三个动作：钉死 ID、把迁移当升级做、给下一次价格台阶留一行预算。
方法 · 一图看懂
1
先分清三种下线 — 硬停（报错）· 软改写（不报错 · 答你的已是另一个模型）· 产品侧退役（界面选不到、接口还在）
2
软改写为什么更难查 — 代码没变、日志仍写旧 ID、评测基线过期、token 用量可能上一个台阶
3
查三处 — 那行的「替代」栏写了什么 · shutdown 日期是日期还是 N/A · 变更日前后你的 token 与工具调用次数
4
把 ID 钉死 — 请求里写明你要跑的那个 ID，⛔ 不用裸别名、不靠服务端路由替你决定
5
当升级做，不当改名做 — 重跑评测、比工具调用次数、给下一次价格台阶留一行预算
原理 · 为什么有效
「下线」之所以要分管，是因为两种形态制造的信号量完全不同。硬停制造一个异常：请求失败、任务中断、日志红了一片 —— 你不想处理也得处理。软改写什么都不制造：请求成功、返回正常、告警为零，唯一变化的是「谁在回答」。于是你手上三样东西同时失真：日志记的是你请求的 ID（不是实际服务你的模型）、评测基线测的是旧模型、成本曲线变了你会先怀疑自己的代码。更麻烦的是，新模型可能更愿意用工具、推理步更细 —— 同一件事它多调两次工具，按步数设的限额、按任务设的预算就可能被顶穿，而单价一分没涨。所以判断顺序必须反过来：先问「它还是我以为的那个吗」，再问「它贵了吗」。
适用场景
适用：你在用模型 ID（API 名 / SDK 默认值 / 自动化任务 / 自建 agent）；你的服务里有按步数、按 token、按任务设置的限额；你要对输出做结构化解析（格式一变就报错的那种）。不适用：你只在网页聊天框里用过一次、没有任何脚本与保存的默认值 —— 那只需跟着产品提示走。另有一条边界：⛔ 别把「钉死 ID」理解成「永远不升级」 —— 钉死是为了让升级成为你的决定，而不是别人的默认。
自测 · 5 问
我能说出我请求的那个 ID 全名，而不是「默认那个」「最新的那个」
我知道这次变更的替代栏写了什么，以及 shutdown 日期是具体日期还是 N/A
我手上有变更日前后各一周的 token 用量与工具调用次数，能看出有没有台阶
我在变更后重跑过评测，而不是只看「请求还成功」
我的预算里有一行写着下一次价格变化的具体日期
怎么上手 · 验证步骤
三步：① 钉死 —— 把所有别名换成明确 ID（含 SDK 里的默认值、prompt 管理工具里的模型字段、自动化任务的设置），grep 一遍旧 ID 在哪些地方出现；② 对齐 —— 在变更日前后各取一周，比三个数：每请求 token、每任务工具调用次数、每任务耗时，任一项跳台阶就说明「同一个任务换了算法」；③ 重跑评测 —— 把旧 ID 下的基线全部作废，用新 ID 重跑一遍再谈结论，然后给下一次价格变化写一行预算。
自检动作：打开你的日志，看模型字段记的是「请求的 ID」还是「实际返回的 ID」。如果只记前者，你就没有能力发现软改写 —— 这是这一页最值钱的一句：先把「实际返回的模型」记下来，再谈监控。第二步：搜一遍代码库与配置文件里的裸别名（不带版本号的那种），列出来，想想它下次会替你选什么。