技术 · 熟练
同一个模型，你从哪条路调它？
厂商、合作云、第三方产品，三张日历不同步
官方公告只回答「厂商自己什么时候撤」，而你的调用可能走在三条不同的路上。厂商直连接口是一条，由合作平台运营的托管路由（官方资料里点名 Amazon Bedrock 与 Google Cloud 这类伙伴运营平台）是第二条 —— 它们自行设定退役日程；第三方产品内嵌是第三条（同一批模型，厂商侧 10-14 从自家产品退役，而某个编码助手侧的六个模型下线日是 10-19）。三条路各有各的时间表，互不继承。这一页给的是换期之后的第一件事：先确认路由，再查日期 —— 一张模型台账补一列「我是从哪条路调它的」，再按路由分三张日历。
方法 · 一图看懂
1
先问「这个模型我是从哪条路调的」 — 厂商直连 / 合作平台托管 / 第三方产品内嵌，三条路的时间表互不继承
2
每条路各记一张日历 — 官方公告只覆盖厂商自己那条；合作平台的退役日程由平台自己定，⛔ 不从厂商公告推
3
把「产品侧」与「接口侧」分开 — 同一天不等于同一个动作：产品入口撤了 ≠ 接口关了（有官方公告专门写一句「不适用于 API」）
4
只认官方原文那两个日期 — 弃用日与关停日是两栏数；只有二手汇总来源的条目标「待确认」，⛔ 不当成已完成
原理 · 为什么有效
退役公告的默认读法是「按厂商查」，但那回答的是厂商自己那条路 —— 你在别人平台上用它、或在别人的产品里用它，走的是另外两条路。合作运营平台有自己的退役日程（官方政策页明写这一点），第三方产品也会自己决定何时下线内嵌模型（所以同一个模型，在厂商产品里 10-14 停、在编码助手里 10-19 停，而直连接口那边可能还活着）。默认按厂商查的后果是确定的：你在 A 路写的迁移待办，对 B 路毫无意义；而先死的那条路，你根本没在看。判据一句话：先确认路由，再查日期。这也是为什么这一页要把「产品侧 / 接口侧」再拆一层 —— 官方公告里那句「本退役不适用于 API」，正是同一份文件里两个动作分家的证据。
适用场景
适用：任何把模型名写进脚本 · 定时任务 · 自定义 agent · 保存的默认值的人；尤其是通过云平台转售或第三方产品间接调用的人（那时厂商公告根本不会告诉你哪天断）。不适用：只在单一官方客户端里点选、从不改模型名的场景 —— 那由平台方替你迁移。
自测 · 5 问
台账里每条模型都标了「我从哪条路调它」，而不是只有模型名 + 一个日期
三条路由各有一张日期表，而不是把所有平台的日期混在一处
每条都区分了「产品入口下线」与「接口关停」两个动作，而不是写成一个日期
合作云托管与第三方产品那两条，是去平台自己的公告里查的，而不是从厂商公告推的
日期抄的是官方原文那两栏；只有二手汇总来源的条目视为未完成
怎么上手 · 验证步骤
最小可行做法是三步、二十分钟：① 把手上所有模型名搜一遍（脚本 · 定时任务 · agent 配置 · 保存的默认值），逐条记下「谁在调用它」② 给每条标注路由 —— 厂商直连 / 合作平台托管 / 第三方产品内嵌，并把这一列补进现有台账 ③ 按路由分三张日历：厂商那张抄官方两栏日期，另两张去对应平台自己的公告里查。最常被漏掉的是第二张（合作平台托管），因为厂商公告里根本不会写它。
把台账逐行过一遍，凡「只有模型名 + 一个日期」的行都标出来 —— 那一行还没回答「哪条路」。再问一句：如果这条路由明天换了，这张表能告诉你吗？