通用方法 · 熟练
替代栏空着，还不是最坏的一种
模型下线要改配置，接口没模型要改代码
「某个模型下线」这句话，多数人能读出三种情况：改个名字就好、替代栏是空的要换供应商、微调挂在上面会连带失效。还有第五种更隐蔽的 —— 被关掉的不是一个模型，而是一整条路由：官方文档页还在、没有弃用横幅，可那条接口上能填的模型名一个不剩。这一页给一份三条判据的补充读法：先分清「配置变更」与「集成变更」→ 再核对那四个换了名字也没用的参数 → 最后处理官方两页日期口径不一致时该怎么定。判据只有一句话：改一个字符串能修好的，和要重新排期的，从来不是同一件事。
方法 · 一图看懂
1
先分清配置变更还是集成变更 — 换名字是配置，换路由是集成，后者要动手写代码的人
2
去另一页反查「这条路由还剩什么」 — 弃用表只说哪条模型走，不说这条接口还留不留得下东西
3
核对四个换名字也带不走的参数 — 它们不在新接口里，等于功能被静默砍掉
4
官方两页日期打架时按最晚的算 — 同一份文档里两个日期，取更早的那个当截止
5
收成一条部署期自检 — 让「哪条路由会空掉」在部署时就被发现，而不是等凌晨报错
原理 · 为什么有效
为什么「端点空掉」和「模型下线」要分开看？因为两者的迁移动作落在不同的人身上。模型下线是一次配置变更：把某个字符串换成另一个字符串，谁维护配置谁就能改完，也不需要理解调用代码。而一条路由上没有可用模型，是一次集成变更：调用方要知道这段代码原来靠的是这条接口特有的能力，才能决定是换接口、换供应商，还是把这部分功能整体重写 —— 这需要的是懂这段代码的人，而排期也不同。把它当成配置变更，代价不是当下报错，而是「排期到最后四周才发现要动代码」：那四周通常还不够。
适用场景
适用：任何还在用早期接口（文本补全一类老路由）的脚本与自动化；接手别人项目、只看得懂调用点却不知道依赖了哪些接口特有参数的人；要在部署清单里加一条「退役自检」的维护者。
⛔ 不适用：只调用当前主流对话接口、且全部走官方 SDK 封装的项目 —— 那类项目真正要做的是「台账 + 每月对一遍」和「替代栏空了要换供应商」两件事，不涉及本页。
⚠️ 前提：手上能读到官方的两页 —— 弃用表与接口参考页；只读得到一页时，本页的判据用不上。
自测 · 5 问
我能不能说出自己项目里，用到了一个「只在某条接口上存在」的参数或返回字段？
上次看到「某模型下线」时，我第一反应是改配置，还是先确认这条路由还留不留得下？
我的部署清单里，有没有一条专门查「这条路由上还有没有可用模型名」？
如果官方同一页给出两个不同的关停日期，我手里有没有一条固定的取法？
我上一次做退役核对，用的是官方原文，还是别人整理好的那张表？
怎么上手 · 验证步骤
只查一条：把你项目里所有调用点筛出「用的还是早期文本补全一类接口」的那些。然后做两件事：① 打开接口参考页，确认它现在列出的可用模型名单里还剩几个（如果名单里的名字恰好就是本轮被关停的那几个，这条路由今天之后就没有东西可填了）② 在代码里搜那四个参数名（连提示一起返回 · 填空式插入 · 服务端多候选择优 · 逐位置候选概率），逐个标注「还用不用」。两件事都做完，你就有了一张「这条路由要改成什么、要多久」的实际判断 —— 而不是等到某个早晨脚本报错。
自检动作：把你标出来的调用点按「改字符串就能修好」与「要动调用代码」分两栏写下来。分完看一眼两栏的数量 —— 如果第二栏里出现了你以为属于第一栏的东西，那正是这次核对的收获。