季度模型迁移：将其变成日程安排，而非消防演习

弃用通知邮件在一个周二的下午寄达。你的计费流水线赖以生存了 14 个月的模型现在进入了 60 天的倒计时。提示词是由一名在 3 月离职的工程师调优的。评估套件自发布以来从未重新设定基准。客户成功团队正在询问为什么两个企业账户的“AI 感觉不一样了”。没有人把这件事列入路线图，也没有人能清爽地接手，因为在你组织的心理模型中，这是一个一次性项目 —— 尽管这已经是今年的第四次了。

每个在生产环境中运行 AI 功能的团队在 18 个月内都会得出同样的感悟：基础模型提供商正以团队未曾预料的频率弃用模型，而团队的迁移应对措施始终是由于收到通知邮件而触发的被动仓促应对。解决方法不是为下一次迁移准备一个更好的操作手册 —— 这类手册已经很多了，你的团队可能也写过一个。解决方法是停止将迁移视为一个项目，而是将其视为一个经常性的运营原语。把它排进日历。

供应商已经强加给你的节奏

阅读任何主要模型提供商的弃用政策，你就会发现一种模式。Anthropic 在公开发布的模型退役前至少提前 60 天发出通知。OpenAI 在模型退役前约 90 到 120 天宣布替代模型，然后开始计算弃用窗口。Microsoft Foundry 将模型保持在“已弃用”状态至少 90 天，然后才进入“已退役”。xAI 提前数月宣布了其 2026 年 5 月退役旧版 Grok 标识符（slugs）的计划，并在切换当天自动重定向到继任模型。

数字各不相同，但节奏是一致的：2 到 4 个月的通知期，由提供商自行决定发布，且时间表不会与你的发布日历协调。这种节奏在不同的供应商和年份之间已经足够稳定，现在已不再是意外。看看最近的弃用动态：Claude 3 Haiku 于 2026 年 2 月弃用，8 月关闭。Claude 3.5 Haiku 1 月弃用，7 月关闭。多个 OpenAI 快照在同一窗口期被弃用和移除。GitHub Models 在 2 月的一次更新日志中一次性清理了一批 Anthropic 和 OpenAI 版本。如果你的团队发布了 AI 功能，你每年将面临 2 到 4 次这样的情况，这是可以预见的。

这就是季度运营节奏的形态。它不是一个项目的形态。实际上，一个不断将其作为项目来应对的团队，每年要支付三四次“迁移税”，并且每次都要从头开始重新推导迁移模式。组织在迭代过程中学不到任何东西，因为每次迁移都被视为一次独特的事件。负责这项工作的工程师并不是在构建持久的基础设施；他们是在反复搭建同样的临时脚手架。

季度迁移演练是什么样的

迁移演练是工程时间表上的一个日历事件，由指定的直接负责人（DRI）负责，具有定义的范围和定义的退出条件。无论是否有待处理的弃用，它每个季度都会运行。演练的目的不是迁移 —— 大多数季度都没有什么可迁移的。演练的目的是保持迁移机制的灵敏度。

一个典型的演练是这样的：从与当前生产模型不同的家族中选择一个候选模型。针对候选模型运行回归套件。在最近的一段生产流量上，运行当前模型与候选模型之间的行为差异分析（behavioral diff）。检查你在意的类别的差异 —— 拒绝率、格式漂移、工具调用形态、延迟百分位偏移、评测分数（judge-score）增量。将结果整理到版本化报告中。用你学到的任何东西更新迁移运行手册。完成。

演练并不是关于是否迁移的“绿灯”决策。这是一项练习，它产生了团队以前没有的三种产出：关于生产模型与其潜在替代模型接近程度的最新评估、一份在过去 90 天内由仍在公司工作的员工更新过的运行手册，以及一份当弃用邮件真的寄达时，可以在两天内（而不是两周内）被重新启用的候选模型评估。演练的效果会随着季度累积。到第三次时，团队的迁移反应就成了肌肉记忆。

DRI 的问题比技术内容更重要。迁移在技术失败之前，往往先在组织层面失败。当弃用邮件寄达，而隐含的负责人是“提示词专家会搞定的”时，实际发生的情况是，直到截止日期只剩六周时才有人安排会议，提示词专家发现回归套件需要改进，时间线随后崩溃。指定一名季度迁移 DRI —— 在高级工程师之间轮换 —— 可以在电子邮件迫使在时间压力下进行对话之前，解决所有权模糊的问题。

评估重锚是一项日常惯例，而非专项项目

迁移中最困难的部分不是提示词重写或部署切换，而是回答每一位利益相关者在迁移上线后 24 小时内都会问的问题：质量下降了吗？ 如果你唯一的答案是来自看过 20 个样本的工程师的随口意见，那么这个问题将被反复争论数周，回滚决策将仅凭感觉做出，而团队的一半士气将在不断的自我怀疑中消耗殆尽。

团队需要的答案是一个数字。具体来说，就是在新模型上运行回归测试套件所得出的流量评估得分，其使用的提示词、输入以及评审员配置必须与产生迁移前基准的配置完全相同。迁移前的得分是 X，迁移后的得分是 Y，差异是 Z。这样对话才有据可依。

陷阱在于评估套件在两次迁移之间会发生漂移。案例会增加，评审员会重新调优，提示词会演进，八个月前有意义的基准已无法与当前运行的结果进行干净的对比。对评估套件进行“重锚 (Re-anchoring)”——即在迁移前紧接着在当前生产模型上运行一遍，以确保基准是新鲜的——是让迁移后的数字值得信赖的实践。请将其纳入你的操作指南 (Runbook) 中。在每次演练中都运行它，即使没有待处理的迁移，这样团队在任何时刻都有一个近期的基准。

一个更微妙的问题：评审员模型本身也会改变。如果你的评估评审员也是一个面临弃用压力的模型——而且现在的评审员越来越多地由基础模型担任——那么评审员本身就成了测量工具中的变量。请明确固定评审员模型的快照。以独立的节奏跟踪评审员模型自身的迁移。如果在同一个季度内评审员模型和目标模型同时发生变化，得分差异将变得无法解释。

提示词可移植性审计

加载中…