通用方法 · 熟练
三家都说「要退役」，日期却不是一回事
一个写截止日，一个写下限，一个写「最快可能」
把三家供应商的退役页面并排放，最先撞上的不是模型名，是「日期」这两个字在三种口径下指的不是同一件事。一家写的是关停日（那天请求开始失败）；一家写的是寿命下限（保证至少活到那天）；还有一家在文档里明写自己的日期是「最早可能」而不是截止。这一页把三种语义分开，再把你那条跨供应商 fallback 链按最保守的一档排期 —— 判据一句：一条链上三个模型各自的「日期」，必须换算成同一种语义之后才能比较。
方法 · 一图看懂
1
先给每个日期定名 — 逐条标出它是「关停日 / 寿命下限 / 最早可能」三者中的哪一种，别直接抄进日历
2
把下限换算成动工日 — 寿命下限不是排期日，要按「至少提前一档」倒推自己的迁移窗口
3
一条链按最保守者算 — 主模型与备用模型里只要有一档是「最早可能」，整条链的排期就以它为准
4
留一道部署期自检 — 让「哪个模型名已经无效」在部署时就被发现，而不是等线上凌晨报错
原理 · 为什么有效
为什么不能只抄日期？因为「退役」在三家文档里是三种不同的承诺。第一种是截止日：到了那天，那个字符串上的请求开始失败 —— 它可以被写进日历、可以被监控告警。第二种是寿命下限：官方公布的意图是「保证这个模型至少活到某天」，它是一句保底承诺，不是死亡通知 —— 照它排期，你会把动工日排得比真实窗口更晚。第三种最容易被误读：官方文档里那句「公布日期表示该模型最早可能被退役的时间，确切日期另行通知」—— 它连承诺都不是，是一个下界估计。三种语义混进同一张表之后，做出来的排序必然错，而且错在方向相反的两头：把下限当截止，你会白忙；把最早可能当截止，你会漏排。还有一层结构性的原因：真正的排期单元不是单个模型，而是一条 fallback 链 —— 链上只要有一档是「最早可能」，整条链就都失去了确定性，所以判据落在链上，不落在模型上。
适用场景
适用于任何把模型名写在代码或配置里、并配了备用模型的人：自建脚本 · 跑在定时任务上的自动化 · 团队内部的固定管线 · 用多供应商做容灾的小团队。尤其是「主模型 A、备用模型 B」这种两段式配置 —— 它天然跨供应商，也就天然会把两种日期语义叠在一起。不适用于：只用一个平台、且不配 fallback 的轻量用法（那种情况按前一页「先看替代品那一栏」就够）；也不适用于已经把模型名全部收进一个配置文件的团队 —— 你们要做的只是「照日期改一行」，不涉及语义换算。
自测 · 5 问
我手上那张表里，每个日期旁边写没写它是哪一种（关停日 / 寿命下限 / 最早可能）
我那条约定的 fallback 链上，有没有哪一档的日期是「最早可能」（若有，整条链的排期就不该以其他档为准）
我是不是把「寿命下限」当成了排期日 —— 换句话说，我的动工日会不会比真实窗口更晚
模型名是不是还硬编码在多个地方（同一个名字出现三处以上 ⇒ 改一次漏一处）
有没有一条部署期自检，能在服务起来时就说清「哪个名字已经无效」
怎么上手 · 验证步骤
一轮大约 30 分钟，分三步。① 造表：把三家 deprecations 页面里与你有关的行抄进一张表，每条只填四个字段 —— 官方 ID · 日期 · 语义（关停日 / 寿命下限 / 最早可能） · 是否我方在用。② 换算：把所有「寿命下限」统一倒推成动工日（按你自己的迁移工作量估，别套用别人的天数）；把所有「最早可能」标成不可排期，只留作「留意」项。③ 收口：把模型名从代码里 grep 出来，挪进一处配置；再加一条部署期自检 —— 服务启动时查一次模型清单，把无效名字拦在部署阶段。做完对着那张表念一遍：现在我说得出「哪一天、哪一个字符串会失效」吗？
回看时重点核两处。第一处是「语义」那一列有没有空着的行 —— 空着的那几行，正是将来会让你误判的行。第二处是方向：如果你的结论是「还早，下季度再说」，回头确认这个结论是基于关停日还是基于寿命下限 —— 基于下限得出的「还早」，通常比真实窗口晚。另外核一条：官方的两页（弃用表与接口参考页）如果日期不一致，取更早的那个当截止，并把两页的差异记在备注里，别悄悄选一个。