GPT-4o 退役日已定：十五个月的迁移清单

退役日是明确的，麻烦在于它不只是一个模型名

GPT-4o、4o mini、4.1、4.1 mini 这一代的接口下线时间已经给了出来：2027 年 1 月 14 日。距今十五个月左右，听起来很宽裕。

真正的难点不在时间，在于你以为这是一次「换个模型名」的改动，实际上它是三类隐性依赖一起到期。

很多团队的系统里，「调用 GPT-4o」这句话散落在十几个位置。SDK 的默认参数里写死了模型名，配置文件的兜底分支里藏着老 model 字符串，某些一次性脚本连配置文件都没走，直接把名字写死在代码里。这些位置不会因为官方发了一封停服邮件就自动浮出来。

更要命的是另一样东西：你手上那些调了半年的提示词，是在 4o 这个具体的模型上调出来的。换了模型，哪怕官方说行为兼容，输出的实际分布也在变。这一层不会有报错提示。

开工之前，先把三类隐性依赖挖出来

先做盘点，别急着改代码。花半天做一次全量搜索，比后面反复回滚划算。

• 硬编码的模型名。在代码库里搜这一代模型的几个名字，注意带点、带 mini、带横杠的变体。一次性脚本、数据清洗脚本、测试夹具里经常藏着。
• 跟具体模型绑定的提示词。凡是写过「直接输出 JSON」「只回答是或否」这类约束的，都算。不同模型对这类硬约束的服从度不一样。
• 依赖输出细节的下游逻辑。比如你的解析器假设模型一定返回三个字段，或者假设列表一定用短横杠开头。这类假设从来没人写进设计文档，但它们真实存在于解析代码里。

把这三样东西列出来，按「改崩了影响多大」排序。你会发现真正让你睡不着的是其中一两个位置，而不是全部。

候选模型怎么选：先分层，再算账

一个常见的错误动作是按总价直接换到最便宜的替代品。这会把质量风险一次性放大。

合理的做法是把现有流量按任务分层。

第一层是纯机械搬运类，比如格式转换、抽取关键词、把一段话改写成另一段话。这类活对推理深度没要求，但要稳。

第二层是需要多步推理的，比如智能体里的规划、复杂表格的处理、长文档的判断。

第三层是直接面向用户的，比如客服回复、文案生成、对外可见的内容。这一层出错立刻被看见。

分完层你才能算账。用单价乘以各层的月调用量，得出的数字才有意义。只看「某模型比 4o 便宜几成」没有意义，因为你各层的占比是固定的，权重最大的那一层决定了总成本。这里提醒一句，每家的定价页要自己去看当天的数字，别用别人文章里抄来的单价做长期决策。

迁移顺序比迁移方案更重要

顺序对了，每一步都很小。

• 挑风险最低的一类流量做试点。从机械搬运类里挑一条量小的流水线，给两周。
• 只改一个变量。这一轮只换模型，不要同时改提示词，不要顺手重构。否则出问题你分不清是谁的锅。
• 验收标准先写出来。抽一百条真实输入跑新旧两版，人工过一遍差异。别用「感觉差不多」验收。
• 灰度放量。百分之一、百分之十、百分之五十，每个档位留至少三天观察窗。
• 剩下的按业务重要性往下推。最难的那条留到你心态好、又有整块时间的时候改。

关键就在于让每一次改动都只有一个可能的原因，并且随时能退回去。

提示词要重写的三类地方

不是所有提示词都要重写。经验上要动的是这三类。

靠语气和习惯起作用的。 4o 时代调出来的「语气像有十年经验的同事」，换模型之后往往变成另一种味道。这类没有对错，只能抽样例对比，接受一部分风格漂移，或者补更具体的描写。

靠格式约束起作用的。 老模型习惯先寒暄两句再给结果，你的解析还能容错。新模型可能直接进入正文，也可能换个说法。凡是靠截取、靠正则提取的，都要重新测。

靠上下文位置起作用的。 长上下文里关键信息放在开头还是结尾，不同模型的敏感度不一样。如果你原来的信息排布是为了迁就老模型的注意力习惯，现在要给新模型重新排一遍。

输出怎么对齐：别追求完全一致

要把新模型调得跟老模型一模一样，成本极高，而且大概率做不到。更实用的目标是三条。

• 结构一致。字段名、列表符号、契约格式对齐。这决定了下游解析器能不能接。
• 边界一致。遇到无法回答的问题，是返回空、返回兜底句，还是抛异常。这个行为必须写死。
• 长度大致一致。给个区间就行，不必逐字。

至于措辞和风格，允许有差异。有一句话要提前跟团队讲清楚：这次迁移的目标是「业务不受影响」，不是「输出看起来一模一样」。把目标定错，你会在没有意义的调优上耗掉两个月。

给接下来的十五个月排一下时间表

十五个月听起来很长，拆开看其实很紧。

• 第 1 到 2 个月。做盘点，出三条候选路径，挑低风险流量试点上线。
• 第 3 到 5 个月。机械类流量全量迁移完成，跑通的模式固定成团队模板。
• 第 6 到 9 个月。啃多步推理那一层。这段时间大概率要重写一批提示词，留够工作量。
• 第 10 到 12 个月。面向用户的那条线迁移，配合灰度。
• 第 13 到 15 个月。留缓冲。清掉最后的硬编码，在测试环境里彻底断掉老模型，确认没有隐藏依赖。

最后一步很重要：把「硬切断」变成一个显式动作，比让它在某个凌晨悄悄失效要好处理得多。

三个常见误区

误区一，等官方出迁移工具。 工具能改模型名，改不了提示词的行为差异。它替你做的最多是最外层那部分。

误区二，当成一次批处理。 分批分层和一次全量切换，风险差一个量级。前者的每一次失误都很小并且可逆。

误区三，只改生产环境。 开发环境、集成测试里的夹具、一次性脚本、文档里的示例，全都带着老模型名。等到生产切完才发现文档全是错的，是很常见的返工。

切换期最容易被忽略的一件事：人和流程

技术方案讨论得很充分的项目，最后栽在流程上的并不少见。有一件事值得提前跟团队说清楚：迁移期要允许临时不一致。

同一个功能，A 客户走的还是老模型，B 客户已经走新模型了，这在几个月里是正常的中间态。别为了追求整齐而一次性切换。真正要避免的是没人知道某个客户现在在哪一档。

做法很简单，给每条流水线打一个标签，标明当前模型和切换日期，贴在大家都知道的位置。另一件要提前备好的是回滚开关：新旧模型各留一份可切换的配置，出问题能在几分钟内退回，而不是重新发一次版。这个开关成本很低，它带来的从容值不少钱。

这笔账别只算单价

比较模型时大家把注意力放在每百万 token 多少钱上。这个数字当然重要，但它经常不是主导项。

先看发出去的上下文有多长。如果每次调用都带着一份很长的系统提示词，或者习惯把历史对话全塞进去，上下文部分占的成本可能远超输出部分。压一下上下文长度，比换一个便宜两成的模型收益更大。

再看有没有命中缓存。重复的前缀能走缓存时单价会明显下降，前提是提示词结构足够稳定。今天改一个字、明天换一段话，命中率就接近零。

最后看批处理。离线任务不必追求实时返回，走批量通道通常有价格优惠。把实时和离线两条路分开，是很常见的一刀省钱操作。

现在就能做的三件事

不用等方案评审通过，今天就可以动手。

• 全库搜一遍老模型名，把结果丢进一个待办清单。 这一步半小时，收益最大。
• 挑一条最不重要的流水线，换成候选模型，跑一周。 你会拿到第一手的行为差异，比看任何评测都准。
• 把模型名从代码里抽到配置层。 哪怕这次只用一款替代模型，把硬编码抽出来这件事本身就值了。下一个退役通知来的时候，改一行就行。

模型退役这种事不会只发生一次。你这次搭起来的可切换结构，是给未来三年买的保险。

等到哪天又有人提到某个更新模型的退役时间，你会发现这套东西还在用，而且这次你一点也不慌。