技术 · 熟练
模型还剩几天，问接口比翻公告准
公告表是给人读的，接口是给程序读的
退役这件事最容易被漏掉的一环，是「查日期」还停在手工阶段 —— 上一页给的做法是「每月对一次官方变更页」，那一页对；但只要你还在靠人去翻表，它就有两个已知漏点：翻得不够勤、以及你手上真正在跑的模型名未必都在那张表上。这一页补的是另一个入口：同一个日期，官方除了挂在公告页上给人看，还放在接口里给程序读。把「还剩几天」从文档任务挪到代码任务 —— 让启动流程或定时任务自己去问一次，命中就报警。关键动作只有一个：把「查公告」换成「问接口」，其余判据不变。
方法 · 一图看懂
1
两个入口指向同一件事 — 公告页给人读（含弃用日期与关停日期两栏）· 接口字段给程序读，两个入口取数应当一致
2
清点你要巡检的模型名 — 三处：代码与脚本里硬编码的 · 自动化任务里选的 · 客户端保存的默认模型与自定义 agent
3
把结果接进一次固定自检 — 启动时或流水线里跑一次，命中就输出「模型名 + 关停日期 + 建议动手日」
4
按路由分开问 — 厂商直连 / 合作平台托管 / 第三方产品内嵌，三条路的日程互不继承，⛔ 不互相推导
5
程序只负责发现，迁移仍由人做 — 换模型有副作用，自动改配置是另一个量级的风险
原理 · 为什么有效
为什么会漏：把「查退役」当文档任务的代价，是它的执行频率由人的记忆力决定。你可以给自己定「每月看一遍」，但月与月之间新加的引用、临时写的小脚本、别人接手时改的那份配置，都不会自动进你的清单。接口入口的价值在于把发现动作变成一次固定执行 —— 它不解决「你要不要迁」，只解决「你有没有可能在到期前不知道」。两者是不同的失效：前者靠判断，后者靠频率。而频率这件事，交给程序比交给人可靠。另有一条与日期同样重要的口径：同一个模型在不同调用路上有各自的时间表 —— 官方公告只回答厂商自己那条路，所以你问到的日期要挂在「哪条路上」才有意义。
适用场景
适用：手上用着模型接口、且引用散在不止一处的人 —— 脚本 · 自动化任务 · 客户端保存的默认值都算。
⛔ 不适用：只在一个网页对话框里用、不写代码也不配自动化任务的人 —— 这种情况下接口入口没有可挂的位置，看公告页更直接。
⚠️ 前提：你能拿到一次模型列表调用（或有对应的管理页），并且它确实返回关停日期字段。
自测 · 5 问
我说得出自己最依赖的三个模型，它们的官方 ID 写法（不是口语名）分别是什么吗？
这三处引用 —— 代码 / 自动化任务 / 客户端保存的默认值 —— 我每一处都清点过了吗？
我上一次主动核对关停日期是什么时候？是靠什么触发去核的？
如果明天有个模型被关停，我是从告警里知道，还是从报错日志里知道？
我手上的模型，分别是从哪条路调的（厂商直连 / 平台托管 / 产品内嵌）？我说得清吗？
怎么上手 · 验证步骤
第一次别写完整巡检脚本。先手工跑通一次取数：调一次模型列表，看你最依赖的那个模型返回的关停日期字段在不在、值是什么；再拿这个值去官方公告页对一遍两栏日期（弃用日期与关停日期），确认两个入口说的是同一件事。对齐之后再把这一步写成一行自检 —— 建议挂在你本来就会周期性执行的地方（启动脚本、或每周一次的任务），只输出异常项，其余静默。先跑通取数、再谈告警：取数阶段最容易出问题的是名字写法，而不是接口本身。
自检动作：把你清单里每一条模型名，逐个拿去接口问一次，把返回的关停日期抄在它旁边。能抄出日期的打勾，返回空的或报错的圈出来 —— 圈出来的那几条说明名字写法与官方不一致，这比重写脚本更值得先修。