技术 · 熟练
官方说退役，为什么脚本还在跑？
产品里退了，API 里可能还在——先把两条时间线分开
同一个模型名，可以「在产品里退役」而「在 API 里继续提供」，也可以反过来；把两条时间线读成一条，就会得出两个都错的结论 —— 要么白改一遍，要么等到脚本报错才发现。这一页补的是「弃用自查」里最容易读错的那一格：先用两个问题把通知归类（退役的是产品入口还是接口 · 它给的是弃用日还是关停日），再把关停日期抄成一条待办，最后读那句最容易被跳过的话 —— 当官方写「实验性 / 不承诺生产负载」时，这次迁移就不是换个名字，而是排期。
方法 · 一图看懂
1
先分清两条时间线 — 产品侧（客户端选单里选不到）与 API 侧（接口还能调）各自有独立的退役日；同一天不等于同一个动作
2
抄日期只抄官方原文那两栏 — 弃用日（deprecation）与关停日（shutdown）是两个数；没有日期就标「待定」继续观察，⛔ 不用转述文章的日期
3
读那句「替代品还不成熟」 — 官方把替代方案写成实验性 / 不承诺生产负载时，迁移的实质是排期与降级预案，不是改名
4
提前动手日挂提醒，关停日只作最后期限 — 建议提前 2~3 周动手，避开临近截稿；提醒挂在提前日，⛔ 不挂在关停日
原理 · 为什么有效
退役通知的错读有三种，看清是哪一种就知道要做什么。① 把「产品退役」读成「接口关停」 —— 于是把还能跑的脚本全改了一遍（白干）；② 把「接口关停」读成「产品退役」 —— 于是以为「反正我没在界面里用它」（等着报错）；③ 把「弃用日」读成「关停日」 —— 于是在最后期限当天才动手。判据一句话：一条通知只有回答了「哪一侧、哪一天」两个问题，才算读完了。
适用场景
适用：你用 API 名、脚本、自动化任务或自定义 agent 跑东西；或者你在客户端里保存过默认模型。不适用：你只在网页聊天框里用过一次、没有任何脚本与保存的默认值 —— 那时只需跟着产品提示走就够了。
自测 · 5 问
你能说出这次退役落在哪一侧（产品入口 / API 接口），还是两侧都有
你手上是不是同时有「弃用日」和「关停日」两个数（只有一个 ⇒ 这条通知没读完）
官方指定的替代方案，有没有被写成「实验性 / 不承诺生产负载」
你的提醒挂在提前动手日，还是挂在关停日
关停日期是抄官方原文的，还是抄某个二手汇总文章的
怎么上手 · 验证步骤
四步：① 把这次通知归类 —— 回答「退役的是产品入口还是接口」，把答案写成一句话；② 只从官方页抄两个日期（弃用日 / 关停日），任一个拿不到就写「待定」；③ 找到官方指定的替代方案，读一句它的状态描述 —— 若含「实验性 / 不承诺生产负载」，在台账里多加一栏「降级预案」；④ 按提前 2~3 周算出提前动手日，把它设成日历提醒。
自检动作：把你这张台账给一个不在场的人看，请他回答两个问题 —— 这次退役影响的是界面还是脚本？我最早哪一天必须动手？他若答得出，这一轮就做完了；他若反问「是哪个模型」，说明第 1 条没落地。