技术 · 熟练
同一条下线公告，你有六个月还是二十天？
公告期本身，就是一条判据
看到下线公告，第一件该做的不是改代码，是判断这次你还有多少时间。官方通知期按模型档位分三种：正式版模型至少六个月 · 专用变体（对话 / 编码 / 深度研究）至少三个月 · 预览版可以短到两周 —— 一个实例是某专用模型从挂公告到硬关停只有约二十天，且没有宽限期。日期还会叠在一起：同一个月里两家的公告就在同一张日历上相遇（一家 10 月 19 日移除六个模型，另一家 10 月 23 日批量下线十二个快照加五类微调家族）。这一页把「先判档位、再算剩余天数、最后按日期排优先级」做成一张表，并附一条最容易忽略的核对：官方指定的替代品不总是更便宜。
方法 · 一图看懂
1
先判档位 — 正式版至少六个月 · 专用变体至少三个月 · 预览版可短至两周
2
算剩余天数，再排优先级 — 把日历上的日期一次列全，而不是撞上哪个处理哪个
3
替代品自己算一遍价 — 官方映射不总是更便宜，单价可能翻倍
4
微调家族单列一条线 — 基座换掉，微调必须在新基座上重训，不是改个名字
原理 · 为什么有效
通知期不是礼节，它是你能拿到多少准备时间的计量单位。同一份公告，落在正式版模型上意味着「这个季度排进去就行」，落在预览版上意味着「这周不动就是事故」。所以判断顺序必须是先定档、再定日：先问它属于哪一档，才知道该用「季度」还是「周」来安排。第二个容易漏的点在替代映射上 —— 替代关系是能力对应，不是价格对应：有实例是替代模型的输入单价反而翻了一倍，也有实例是从高价位降下来。最后，微调家族要单独走一条线：基座一换，微调不能继承，必须在新基座上重跑，这条最容易被当成「改个模型名」。
适用场景
适用：任何在 API、编码工具或自动化任务里用了具名模型的人 —— 尤其是模型名散落在脚本、定时任务、自定义 agent 与保存的默认设置里的情况。不适用：只通过某一个固定客户端使用、且从不改模型名的场景（那时由平台方替你迁移）。
自测 · 5 问
台账里每条都写了档位（正式版 / 专用变体 / 预览版），而不是只写关停日期
同一张日历上把所有已知日期列在一起，而不是分平台各记一处
对每个替代项都单独算过单价，而不是直接采信「官方推荐」
标出了所有微调对象的基座，并确认它们是否需要重训
每条命中都有关停日期与提前动手日 —— 只有模型名、没有日期的条目视为未做完
怎么上手 · 验证步骤
第一次做大概半小时：① 翻出你手上（或者你依赖的）全部具名模型，按来源分成三组 —— 生产脚本里引用的、定时任务与自动化里选的、客户端与自定义配置里保存的 ② 对每一个去官方弃用页查一次，同时记下它的档位与关停日期 ③ 把所有日期抄进同一张表，按日期升序排 —— 这张表就是你的行动顺序，不是按平台分，而是按时间分。
每月固定一天做一次「日期重排」：只看这张表，问三个问题 —— 本月到期的是哪几条、替代项的价格算过没有、有没有微调对象还没安排重训。三个问题都答得出来，这一轮才算过。