食堂的老师傅要退休了。新师傅履历漂亮，刀工更快，拿手菜更多。交接时，负责人递过去一张菜单，觉得事情办完了。
直到午饭开窗，才有人想起来：这份菜要少盐，那份不能放葱；有位常客每次说“老样子”，其实要的是小份、不浇汁。
菜单上一个字都没有。过去一直没出错，只因为老师傅记得。
这是一个假想场景。但模型退休时，应用里那些没写下来的规矩，也会一起走到交接窗口。
OpenAI 在 2026 年 10 月 14 日更新了 API 弃用公告：其中列出的 GPT-4 系列快照将在 2027 年 1 月 14 日下线。具体是 GPT-4o 的 2024-08-06、2024-11-20 两个快照，GPT-4o mini 的 2024-07-18，以及 GPT-4.1、GPT-4.1 mini 各自的 2025-04-14 快照。表中推荐替代均为 gpt-6-luna，这些基础模型的微调版本也遵循相同下线时间。
这里说的是公告列明的 API 模型，不是宣告所有叫 GPT-4 的产品同时停止，也不是一份 ChatGPT 界面调整通知。
最容易让人松口气的，是替代型号已经填好了。配置里换一个名字，请求能返回，监控没有红灯，似乎就可以把这件事划掉。
可“新师傅到了”和“老顾客的饭还能按要求出”，中间还有一场交接。
过去没出错的地方，可能只是没人写过要求#
模型迁移会让一种很隐蔽的依赖暴露出来：业务依赖了某种输出习惯，却没有把它变成明确规则。
比如一个合成的工单分类场景。用户说“按钮有时点不动，但刷新就好了”。系统需要决定是否进入人工处理队列。旧模型经常把这类表达归入“偶发问题”，产品团队也一直接受这个结果。但团队从没定义：涉及什么操作时，即使偶发也必须升级处理。
换一个模型后，它可能给出另一种分类。这不必然说明新模型更差；也可能是旧模型替团队猜了很久，而团队把猜对的那些次，当成了自己的业务规范。
这时把所有旧输出都当标准答案，新模型就得学着保留旧错误；把所有差异都说成“新模型更聪明”，真正的业务退化又会被放过。
比较难、也最有价值的工作，是在交接前把争议摆出来：哪些差异只是措辞变化，哪些触碰了不能改变的规则，哪些是应该批准的新行为。不能让“尽量和以前一样”包办这三个问题。
食堂可以换菜，甚至应该换掉不好吃的菜。但给不吃葱的人撒上一把葱，不能解释成厨艺升级。
这个意象也有边界。模型并不真的记着每个常客，输出还受提示词、上下文、工具结果和采样设置影响。要交接的是整条应用路径里的要求，不能把所有变化都归因于模型名字。
JSON 能接住，业务未必接得住#
有团队会说：已经约束成 JSON 了，字段和类型都一样，还能差到哪里去？
恰恰可能差在字段里面。
同样一个合法的分类值，同样一段完整的摘要，可能省略了决定后续动作的限定词。解析器只知道盘子没碎，不知道里面端的是什么。OpenAI 的 Structured Outputs 文档也明确提醒，结构化输出仍可能包含错误。格式约束很有用，但不会顺带定义业务上的正确。
下面的图把迁移时常被揉成一团的三个问题拆开。它是本文的验收建议，不是新旧模型的测试成绩。
模型还在服务的这段时间，有一件事以后很难补：让同一批经过授权、脱敏的输入，在可控条件下留下新旧两边的结果。输入、提示词、工具返回和运行配置尽量固定，才能知道差异来自哪里；随机输出则需要重复观察，不能挑一次顺眼的回答当结论。
这里说的对照，首先应在隔离的回放环境完成。若任务会发消息、建工单或改数据，两边都接上真实执行工具，可能把一次迁移测试变成两次业务操作。留下提议动作供比较，和让两套系统同时执行，是两回事。
官方评测指南建议围绕任务目标建立数据与评价标准，并随系统变化持续评估。落到这次交接，我更在意的是：那些过去只能由老同事一眼看出的错误，能否连同原因一起留下来。旧答案是证据之一，经过审查的业务要求才是判定依据。
也别把迁移做成永远结束不了的大考。只做低风险文本改写、输出始终由人确认的工具，可以采用更轻的验收；有不可逆动作、特殊输入或长期积累的微调行为，交接就需要更厚的证据。投入该跟实际后果走，而不是跟公告上的模型代数走。
“有问题再切回去”，也有截止日期#
这次公告里最值得仔细读的一句，是微调版本跟随基础模型一起下线。
投入过微调，并不会让这条托管服务自动获得永久营业资格。能带走多少能力，要重新检查训练样本、标签定义、评测集和目标平台支持；公告里的推荐替代，也没有承诺把旧微调模型原样搬过去。本文没有验证替代模型的微调可用性，更不据此建议直接启动重训。
真正值得早一点整理的，是当初为什么收集这些样本、哪些错误必须被纠正、哪些标签后来改过。只留下一个微调模型 ID，就像交接时说“味道都在师傅手里”，新师傅很难照着做。
另一个常见安慰是：先换，有问题再切回旧模型。
在旧服务仍可用、账号权限和依赖都满足时，这可能是合理的短期回退。但按当前公告，到了 2027 年 1 月 14 日，不能再把那些下线快照写成仍然可调用的救急方案。日期之后的退路，需要另行验证：缩小自动处理范围、交给人工，或者使用已经验收过的其他可用路径。它们各有成本，不能拿一句“自动降级”糊过去。
老师傅还在的时候，新旧两边可以一起试菜；老师傅已经离开，还把他的名字写在值班表上，值班表再完整也没用。
所以，这条新闻给 AI 应用团队的提醒，不是恐慌性地追新型号。模型会更新，服务会调整，合理的迭代本就需要这些变化。真正令人不安的，是团队到收到下线通知，才发现自己说不清应用到底依赖了什么。
一行模型名称可以改得很快。把曾经默认“它应该懂”的那些事，整理成下一位也能接受检查的要求，才算真的交了班。
资料核对：2026 年 10 月 15 日。下线范围、日期与推荐型号据 OpenAI 10 月 14 日公告，属于供应商公布的计划，后续仍须以官方更新为准；本文没有调用这些模型做对比测试。食堂与工单场景为原创假想示例，迁移、回放与兜底建议为本文分析，不声称新旧模型业务等价或效果下降。
想把验收条件落到可检查的记录，可以继续看 RAG 评测实战：平均分涨了，就能上线吗？。AI 实践讨论入口在知识星球，公众号入口在关于页。
本文文字与图解由 AI 辅助制作，来源已在正文列明。
