技术 · 熟练
一次模型退役，其实是五件事同时变
模型退役 · 十篇的总入口
它难的地方不在改代码，在于「你手上到底有什么」和「它什么时候会变」—— 这两件事都不在你的代码里。
一 · 为什么「改个名字」这个直觉是错的
看到「某模型下线」，多数人的第一反应是改配置里那个字符串。这个反应在一种情况下是对的：官方给了同代的替代品，参数没变、价格没变、能力没变。这种情况确实只要改一行。
但「下线」这两个字背后至少有五种情况，处理成本差着一个量级：有的是改配置，有的是换供应商（那是产品变更），有的要你自己备 GPU 把开源权重部署起来，还有的连公告都没挂、只是接口上能填的值少了。把它当成同一件事，就会在第二种情况上按第一种方式处理。
二 · 五件事同时在变
退役发生时，下面五项每一项都可能变
资产 · 你真正在跑的是哪几个名字
不是你以为的那个，是请求里实际发出去的那个 —— 两者常常不一致（代理、封装层、SDK 默认值都会改它）。
这一项不先弄清，后面四件事都没法判断：你不知道哪个公告跟你有关。
形态 · 退的是模型、端点、路由，还是参数语义
模型名没了最容易发现，因为报错写得很清楚。
难查的是另外三种：托管端点关掉要自建、整条路由上的可选值变少、参数名还在但语义变了（同一个 temperature 传进去直接 400）。
日期口径 · 三家说的不是同一件事
一家写关停日：那天请求开始失败。
一家写寿命下限：保证至少活到那天。还有一家明写这是「最早可能」，意味着可以提前。
把三种口径并排读成一列，就会得出「谁先谁后」这个根本不存在的结论。
路径 · 你从哪条路调它
厂商直连、伙伴平台托管、自建代理，三条路的撤除时间通常不同。
官方公告只回答「厂商自己什么时候撤」，不回答你那条路。
时间线 · 产品退役不等于 API 退役
同一个模型名，可以在产品里下线而在 API 里继续提供，也可以反过来。
把两条时间线读成一条，会得出两个都错的结论：要么白改一遍，要么等到脚本报错才知道。
三 · 日期这一栏，最容易在「看起来懂了」的地方错
通知期是按模型档位分的：正式版至少六个月、专用变体至少三个月、预览版可以短到两周。这些天数会被调整，所以不要去背数字，要看它是按哪一档写的。
判断自己还有多少时间，最省事的做法反而不是翻公告：问接口。能调通的模型和公告上列着的模型，常常对不上，而前者才是你真正的处境。
五 · 如果只做一件事
1
把请求里实际发出去的模型名列出来 —— 从日志或调用记录里取，不要凭印象。
2
对着这串名字逐个查当前状态和退役日期，查完把结果记在同一张表上。
3
把这张表放进每月固定动作，而不是等公告来提醒你。
4
有任何变更，先归到这五个变量里判断，再决定要不要动代码。
这件事的价值不在「提前知道」，而在把不确定性挪到一个你可以查看的位置：公告是会漏的，台账不会。
六 · 这十篇里哪些会过时
具体天数会变（六个月的承诺可以改），具体供应商的页面会改，具体参数名会被替换 —— 这些都会过时，看到日期不对就按官方当前页面校正。
但这五项不会变：资产、形态、日期口径、路径、时间线。只要这五项还在，换一批供应商、换一代模型，判断方法依然是这一套。
如果只读两篇：先读
最早那篇 把台账建起来，再读
退役公告要看三样 弄清每种公告到底要你做什么。
读完先答三问：① 你能说出请求里实际发出去的模型名吗（不是你以为的那个）？② 上次核对官方变更页是什么时候？③ 你的调用走在几条路上？第一问答不出 ⇒ 先建台账，别的都还谈不上；第三问答不出 ⇒ 你以为的「一个模型」其实是三条不同的路，撤除时间不一样。