# 模型要退休了，别只改那一行名字

> OpenAI 宣布部分 GPT-4 系列 API 快照将在 2027 年 1 月 14 日下线。推荐替代已经写好，应用里那些从未说清的行为约定，才刚到交接的时候。

- 作者：芝士AI吃鱼
- 发布日期：2026-10-15
- 栏目：[AI锐评](https://ai-knowledgepoints.cn/commentary)（观点与分析）
- 主题：AI锐评、模型迁移、评测、AI工程
- HTML 正文：[https://ai-knowledgepoints.cn/blog/commentary-2026-10-15-model-retirement-contract](https://ai-knowledgepoints.cn/blog/commentary-2026-10-15-model-retirement-contract)
- Markdown 永久链接：[https://ai-knowledgepoints.cn/blog/commentary-2026-10-15-model-retirement-contract/index.html.md](https://ai-knowledgepoints.cn/blog/commentary-2026-10-15-model-retirement-contract/index.html.md)
- 原始来源：[OpenAI API 弃用公告与官方评测文档](https://developers.openai.com/api/docs/deprecations)

引用本文时，请注明作者与 HTML 正文链接。Markdown 版本用于机器阅读，与 HTML 正文共享同一内容来源。

## 正文

食堂的老师傅要退休了。新师傅履历漂亮，刀工更快，拿手菜更多。交接时，负责人递过去一张菜单，觉得事情办完了。

直到午饭开窗，才有人想起来：这份菜要少盐，那份不能放葱；有位常客每次说“老样子”，其实要的是小份、不浇汁。

菜单上一个字都没有。过去一直没出错，只因为老师傅记得。

这是一个假想场景。但模型退休时，应用里那些没写下来的规矩，也会一起走到交接窗口。

**OpenAI 在 2026 年 10 月 14 日更新了 [API 弃用公告](https://developers.openai.com/api/docs/deprecations)**：其中列出的 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 文档](https://developers.openai.com/api/docs/guides/structured-outputs)也明确提醒，结构化输出仍可能包含错误。格式约束很有用，但不会顺带定义业务上的正确。

下面的图把迁移时常被揉成一团的三个问题拆开。它是本文的验收建议，不是新旧模型的测试成绩。

![模型迁移需要分别检查接口兼容、任务行为和停服后兜底。请求成功与 JSON 可解析只覆盖接口层；任务行为要按业务规则判断，旧模型停服后不能再作为可用回退。原创机制示意，不含性能数据。](https://ai-knowledgepoints.cn/images/articles/model-retirement-commentary/three-handoffs.svg)

AI 辅助制作的原创分析图。三个检查面互不替代；不是官方迁移流程或新模型实测结果。

[查看竖版大图](https://ai-knowledgepoints.cn/images/articles/model-retirement-commentary/three-handoffs-mobile.svg)

模型还在服务的这段时间，有一件事以后很难补：让同一批经过授权、脱敏的输入，在可控条件下留下新旧两边的结果。输入、提示词、工具返回和运行配置尽量固定，才能知道差异来自哪里；随机输出则需要重复观察，不能挑一次顺眼的回答当结论。

这里说的对照，首先应在隔离的回放环境完成。若任务会发消息、建工单或改数据，两边都接上真实执行工具，可能把一次迁移测试变成两次业务操作。留下提议动作供比较，和让两套系统同时执行，是两回事。

[官方评测指南](https://developers.openai.com/api/docs/guides/evaluation-best-practices)建议围绕任务目标建立数据与评价标准，并随系统变化持续评估。落到这次交接，我更在意的是：那些过去只能由老同事一眼看出的错误，能否连同原因一起留下来。旧答案是证据之一，经过审查的业务要求才是判定依据。

也别把迁移做成永远结束不了的大考。只做低风险文本改写、输出始终由人确认的工具，可以采用更轻的验收；有不可逆动作、特殊输入或长期积累的微调行为，交接就需要更厚的证据。投入该跟实际后果走，而不是跟公告上的模型代数走。

## “有问题再切回去”，也有截止日期

这次公告里最值得仔细读的一句，是微调版本跟随基础模型一起下线。

投入过微调，并不会让这条托管服务自动获得永久营业资格。能带走多少能力，要重新检查训练样本、标签定义、评测集和目标平台支持；公告里的推荐替代，也没有承诺把旧微调模型原样搬过去。本文没有验证替代模型的微调可用性，更不据此建议直接启动重训。

真正值得早一点整理的，是当初为什么收集这些样本、哪些错误必须被纠正、哪些标签后来改过。只留下一个微调模型 ID，就像交接时说“味道都在师傅手里”，新师傅很难照着做。

另一个常见安慰是：先换，有问题再切回旧模型。

在旧服务仍可用、账号权限和依赖都满足时，这可能是合理的短期回退。但按当前公告，到了 2027 年 1 月 14 日，不能再把那些下线快照写成仍然可调用的救急方案。日期之后的退路，需要另行验证：缩小自动处理范围、交给人工，或者使用已经验收过的其他可用路径。它们各有成本，不能拿一句“自动降级”糊过去。

老师傅还在的时候，新旧两边可以一起试菜；老师傅已经离开，还把他的名字写在值班表上，值班表再完整也没用。

所以，这条新闻给 AI 应用团队的提醒，不是恐慌性地追新型号。模型会更新，服务会调整，合理的迭代本就需要这些变化。真正令人不安的，是团队到收到下线通知，才发现自己说不清应用到底依赖了什么。

一行模型名称可以改得很快。把曾经默认“它应该懂”的那些事，整理成下一位也能接受检查的要求，才算真的交了班。

资料核对：2026 年 10 月 15 日。下线范围、日期与推荐型号据 OpenAI 10 月 14 日公告，属于供应商公布的计划，后续仍须以官方更新为准；本文没有调用这些模型做对比测试。食堂与工单场景为原创假想示例，迁移、回放与兜底建议为本文分析，不声称新旧模型业务等价或效果下降。

想把验收条件落到可检查的记录，可以继续看 [RAG 评测实战：平均分涨了，就能上线吗？](https://ai-knowledgepoints.cn/blog/rag-evaluation-04-release-gates)。AI 实践讨论入口在[知识星球](https://ai-knowledgepoints.cn/planet)，公众号入口在[关于页](https://ai-knowledgepoints.cn/about#wechat)。

本文文字与图解由 AI 辅助制作，来源已在正文列明。