GPT-5.5 将在 10 月 14 日退役：这次要维护的是你的 AI 工作流

如果你每天只是打开 AI 聊天，模型退役可能表现为选择器少了一个名字；如果你已经把 AI 接进固定流程，它就更像一次需要安排的系统维护。

OpenAI 已公布 GPT-5.5 将于 2026 年 10 月 14 日从 ChatGPT、ChatGPT Work 与 Codex 退役。本文核查日是 10 月 7 日，安排已公布，退役尚未到期。更关键的是，官方明确说这次不适用于 OpenAI API。原始更新记录可以核对这两个边界。

图：根据官方更新记录整理的原创时间线。它区分公告日、核查日与计划退役日，不是界面截图。

从一条消息，走到一项依赖

9 月 14 日公布安排，10 月 14 日计划执行，中间这段时间的价值，是让用户检查自己究竟在哪些地方固定选择了 GPT-5.5。

一个可能的例子是每天整理报表的任务。你手动聊天时已经选了新模型，自动任务却仍保存旧名称。两个入口并不必然一起改变；到了执行日，才发现任务行为与预期不同，就会增加排查成本。

这个例子只是说明依赖在哪里，不是对特定产品故障的预言。真正需要做的是查看实际保存设置，而不是根据新闻猜测系统一定怎样自动替换。

OpenAI 的模型说明与套餐页会随产品开放状态更新，迁移时应以账号当前能使用的选项为准。企业工作区还需要同时看管理员的模型可用性说明。

同样叫 Codex，也要区分登录方式

退役消息经常被转述成“模型彻底不能用了”，但官方公告写的是产品范围。通过 ChatGPT 账号使用 Codex，与使用自己的 API Key 接入，是不同访问方式。

API 用户应查看API 退役清单，不能拿聊天产品的日期直接套在接口上。反过来，某个模型仍有 API，并不意味着你的聊天套餐继续保留它。

这听起来像细节，却决定了你是否需要立即修改程序、是否需要改变订阅选择，以及迁移该看哪份说明。完整报道应该交代适用范围，不能只留下“10 月 14 日”这个醒目的日期。

你要迁移的是工作，不只是模型名

一份提示词在旧模型里得到的效果，在新模型里可能有变化。段落长度、默认工具使用、对模糊需求的处理方式，都可能影响最终结果。

因此，先拿一项常见任务验证，比一口气改完所有流程更稳妥。比如新闻整理可以检查来源与日期，代码工作可以检查修改范围，文档工作可以检查是否保留原有事实。验收标准尽量保持不变，这样差异才容易解释。

不必从头重写全部指令。哪个条件被遗漏，就明确哪个条件；哪个输出字段变了，就检查读取它的程序。把一次迁移变成可观察的小变化，会比“新模型应该更好”更有说服力。

定时任务文档也区分了独立任务与同一聊天里的持续任务。对于自动工作，保存提示与运行环境都属于需要核对的部分。

为什么旧模型告别也是行业新闻？

模型发布总容易占据头条，退役安排却体现了另一面：厂商的产品资源如何分配，用户怎样承担维护成本，以及工作流能否跨版本持续使用。

我们的观察是，AI 越深入日常工作，用户就越需要生命周期信息。什么时候公布、给多久准备时间、哪些入口受影响、替代选择如何验证，都成为服务体验的一部分。

这不等于所有用户都必须追逐最新版本。对于个人使用，可能只是重新选择；对于团队，则应把模型配置纳入正常维护，而不是等到报错才想起它。

截至 10 月 7 日，本文能确认的是上述日期与范围。后续若官方调整安排，应以最新通知为准。想了解目前另一项产品更新，可以阅读GPT-6.1 Sol 的定位与开放范围。