模型已到生命周期终点，并带走了你的提示词

弃用通知看起来人畜无害。它以更新日志或邮件中一段平静的文字形式出现：该模型快照将在几个月后的某个日期从 API 中移除，这里是推荐的替代方案，感谢你与我们一起构建。其中暗含的工作量似乎只是一行代码的改动 —— 换掉模型字符串，重新部署，搞定。

这种设想是错误的，而且错得很昂贵。模型字符串是你损失的最小的东西。真正随着旧模型一起消失的，是你花了六个月调优的提示词（prompt） —— 每一个针对边缘案例的补丁、每一个重新排序的指令、每一个你因为那个特定模型会有特定烦人行为而添加的“仅以有效的 JSON 响应，不要用 Markdown 包装”。这些都不是可移植的。从统计学意义上讲，它是针对一个模型的行为进行拟合的。替代模型并不是“缺陷对缺陷”兼容的，因此这种拟合不再成立。

模型生命周期的结束是一个迁移项目。如果把它仅仅视为一次配置更改，你就会在生产环境中、在新模型上通过真实流量发现其中的差异。

弃用通知开启的是倒计时，而非一个任务

通知是真实的，而且非常频繁。OpenAI 计划在 2026 年 2 月从 API 中移除 chatgpt-4o-latest 和多个 GPT-4 级别的快照，并提前大约三个月通知了开发者。Azure 为其托管的每个模型发布滚动退役表。DeepSeek 宣布旧版 V4 模型名称在截止日期后将停止解析。在领先的供应商中，仅 2025 年上半年就有十几个主要模型发布，每一次发布都悄悄地缩短了你当前运行系统的寿命。

这一切背后的规律是：一个可用的生产模型，其货架期大约只有十二到十八个月。这还不是最坏的情况，而是中位数。如果你的系统已经上线两年，你至少已经经历过一次强制迁移，无论你当时是将其视为一个正式项目，还是通过处理一连串的小型突发状况消化的。

弃用通知给了你一个日期。它并没有给你计划、测试或预估。它真正开启的是一个倒计时，而这个时钟正在针对你尚未确定范围的工作运行：重新验证每个提示词、重新检查每个工具调用路径，以及在那些从未出现在演示中的流量片段上重新确认行为。那些受伤的团队通常是读了通知、将其归类为“在日期截止前更换字符串”，直到日期临近才开始评估真正工作量的团队。

你的提示词是某个模型怪癖的化石

令人不安的部分在这里。一个在生产环境中运行了六个月的提示词，并不是对你需求的清晰规范。它是一个关于特定模型失败模式的考古记录。

每一行以“不要”、“始终”或“记得”开头的指令，都是为了应对特定模型的表现而添加的。模型在 JSON 中填充了散文，所以你加了一行禁止散文；模型对工具的使用不足，所以你加了一条强调使用工具的指令；模型太容易拒绝请求，所以你放宽了安全框架；模型误读了歧义字段，所以你重新排列了上下文，把重要的部分放在最后。每一个补丁都是针对局部怪癖的局部修复。六个月下来，这些补丁堆叠在一起，形成了一个精确契合特定模型理解风格的提示词 —— 除此之外别无他用。

这就是为什么在测试之前，提示词的可移植性大多是虚构的。同样的指令文本，交给不同的模型，效果完全不同。在一个模型上能稳定生成纯 JSON 的提示词，在另一个模型上可能会生成带 Markdown 围栏的 JSON，或者生成正确的 JSON 加上一句多余的友好陈述。一个模型将其视为优先级的指令顺序，另一个模型可能仅将其视为建议。这方面的研究非常直白：在少样本（few-shot）设置下，仅格式变化 —— 空格、分隔符、示例顺序 —— 就被证明会导致准确率出现几十个百分点的波动。仅仅增加一个“请”字就可能改变输出质量。你六个月的调优将所有这些无形地编码进了一个你现在认为是“规范”的提示词中。

陷阱在于，这个提示词读起来仍然像是一个干净的规范。文本中没有任何内容说明“这一条款的存在是因为 3 月份的模型快照会对引号进行双重转义”。因此，当你迁移时，你带着整个化石前进，对旧模型起支撑作用的补丁对新模型来说变成了死重 —— 甚至是活跃的负债。新模型从未有过你那个条款所修复的怪癖，而现在你的条款正在与一个并不存在的行为作斗争。

评测集是切换模型后唯一能存活下来的东西

如果提示词在模型切换中无法完好无损，那么什么能留下？有一件东西：一个可重复运行的评测集（eval set）。

评测集是唯一根据“你想要什么”而定义的产物，而不是根据“特定模型的行为方式”而定义。“给定这份支持工单，回复必须正确识别退款政策，且不得承诺窗口期外的退款”这一断言始终成立，无论背后是哪个模型。这个断言比任何模型都长寿。但满足它的提示词却不是。

这重新定义了评测集的用途。大多数团队将评测作为提示词更改的质量关卡 —— 修改提示词、运行评测、如果是绿色就发布。这很有用，但低估了这项资产。评测集也是你的迁移保险。它让你能够拿出一个候选替代模型，针对编码了你真实需求的数百个具体案例运行它，从而得到一个数字而不是一种“感觉”。如果没有它，“新模型是否足够好？”这个问题的答案只能由一名工程师花一个下午随便试两下并宣布没问题。

迁移评测集必须比提示词迭代评测集更广泛，因为模型切换改变的表面积比提示词修改要大。提示词迭代主要影响你已经在考虑的案例。而模型切换会改变拒绝行为、欠规范模式下的输出格式、工具调用频率、延迟分布，以及模型如何处理那些与你的理想路径完全不同的输入。在公开基准测试中得分完全相同的两个模型，在 15% 混乱、对抗性或仅仅是怪异的生产流量中，表现可能截然不同。因此，迁移评测集需要从真实的生产记录中收集案例 —— 尤其是失败案例 —— 而不仅仅是演示脚本。

迁移过程中诚实的排序应该是：首先针对新模型运行现有的提示词。许多提示词在跨代升级中能表现良好；你不想重写那些没有出故障的东西。让评测集告诉你哪些提示词退步了，并且只重写那些。重写一个本不需要动的提示词，是你引入新漏洞却解决不了任何问题的捷径。评测集能将“焦虑地重写一切”转变为“有证据地重写这四个”。

如果你从中学到一个操作习惯，那就是：在你上线 LLM 功能的那天，你就欠它一个可重复运行的评测集，因为当下一次模型退役时，那个评测集将是唯一依然屹立不倒的东西。

同时运行两个模型并非没有代价

迁移并非瞬间完成的切换，而在这中间的过渡期，隐藏着预算外的成本。

一个负责任的迁移在完全切换之前，会以影子模式（shadow mode）或金丝雀模式（canary mode）运行新模型 —— 将一部分生产流量镜像到候选模型，对比输出，或者路由一小部分真实流量并观察指标。这是正确的做法。但在迁移期间，这同时也意味着你要支付两次推理费用。影子流量是纯粹的开销：你用旧模型响应请求，同时又花钱让新模型运行一次。金丝雀部署成本较低，但建立信心的过程较慢。无论哪种方式，迁移都会产生一项在稳定状态下不存在的成本支出，且其规模取决于你同时运行两个模型的时间长短。

这种“脚踩两只船”（straddle）的成本不仅体现在金钱上。当两个模型同时在线时，每一个提示词（prompt）的更改都必须进行两次修改和测试。每一次故障排查都要从“这个请求是哪个模型处理的？”开始。每一个新功能要么等待迁移完成，要么针对两个目标模型分别构建。工程师需要在两种行为模型之间进行上下文切换。团队往往会低估这一点，因为双机并行期感觉像是一个不需要真正规划的临时状态 —— 结果它被无限拉长，因为新模型出现了一个难以解决的退化问题（regression），需要一个月才能搞定，于是这种并存状态悄然变成了常态。

教训并不是要跳过这个并存阶段，而是要对其进行时间盒（time-box）管理。在开始之前就决定双机并行期允许持续多久，以及退出标准是什么 —— 评估通过率、退化数量、成本上限。无期限的并存是进行迁移最昂贵的方式，因为你付出了双倍的推理费用和双倍的工程注意力，却没有终止它的强制机制。

将这种“跑步机式”的更迭视为固定成本，而非意外

最深刻的错误是将每次迁移视为一次性事件。它不是一个事件，而是一个循环往复的运营状态。

如果可用模型的更迭周期是 12 到 18 个月，那么生产环境中的 LLM 系统就应该有一个永久排程的迁移项目，就像依赖项升级、证书轮换和安全补丁一样。没有人会对 TLS 证书过期感到惊讶；它就在日历上，有明确的负责人，且更换过程是例行公事。模型弃用（deprecation）理应受到同样的对待，但现实中很少如此，因为每次发生时大家仍觉得像是个新闻。

将这种更迭纳入预算意味着几件具体的事情。这意味着评估集（eval set）是持续维护的，而不是在接到通知后惊慌失措地临时重建 —— 当你最需要它时，一个过时的评估集几乎毫无价值。这意味着有一个明确的负责人来负责“模型时效性”，就像有负责人负责依赖项的健康度一样。这意味着每个季度的容量规划都要为迁移工作预留空间，使其能够诚实地与路线图中的功能竞争资源，而不是搞突然袭击。这意味着整个系统的成本模型包含了一个周期性的迁移预算法单，通过摊销计算，而不是每 12 个月出现一次循环往复的“意外”超支。

一个有用的认知框架是：模型是一个具有已知且较短支持周期的依赖项。你不会在构建一个每年都会停止维护（EOL）的库之后，还每年都表现得大吃一惊。模型正是那样的库，而供应商甚至已经把时间表发给了你。

核心总结

模型弃用通知不是一个等着被修改的配置项。它是一个有着截止日期的迁移项目，而这个日期并非由你设定。模型字符串的替换只需一秒钟；但你为了适配旧模型特性而调整的提示词却无法沿用，唯一能留存下来的是一套根据你实际需求定义的、可重复运行的评估集。

因此，请将其视为常备基础设施。保持评估集的实时性和广泛性，以便捕获行为变化，而不不仅仅是准确性变化。首先在新模型上运行旧提示词，只重写那些评估集标记出问题的部分。通过明确的退出标准对双机并行期进行时间盒管理。现在就将下一次迁移列入预算，因为供应商几乎肯定已经安排好了 —— 你只是还没读到那条变更日志而已。