在模型之间迁移

一个更好的模型发布了。你换掉模型标识符。输出以你没想到的方式变差了。

这很正常，原因在于 prompt 是冲着具体模型调出来的。 你为了修某个具体失败而加的每一条约束，修的都是那个模型的特定毛病。新模型有的是别的毛病。

会变的东西

啰嗦程度。 最常见的意外。模型答得明显变长或变短，会弄坏对长度敏感的界面，并让成本往两个方向偏。

格式遵守。 原本稳定输出干净 JSON 的模型，可能开始用散文把它包起来，反过来也一样。如果你的解析代码是围绕某个模型的习惯写的，那这套解析现在建立在错误假设上了。

指令理解。 同样的措辞会被读出不同的意思。对某个模型是隐含的约束，换一个模型就得明说。

拒答边界。 各模型、各版本之间的对齐训练不同，所以以前处理得好好的请求现在可能被拒——反过来也有可能。

推理行为。 更新的模型可能默认先推理再回答。这会改变延迟、成本和输出形态，而你那句要求一步步来的 prompt 现在可能是多余的，甚至起了反作用。见推理模型是怎么工作的。

分词。 词表不同，同样的文本 token 数就不同，于是你的成本估算和上下文窗口余量都会变。

你的 prompt 为什么是特定于模型的

随便看一条成熟的生产环境 prompt，里面都有为了修特定毛病而加进去的行：不要写开场白、一律用双引号、如果答案不在上下文里就直说。

每一条都是针对某个模型习性的补丁。换到新模型上，有些变得多余——无害但浪费——还有些反而制造出它原本要防的问题。约束写得过细，会和强模型的默认行为对着干，把它拖差。

这就是写注释的习惯为什么重要：一句注明「加它是因为它编造引用」的话，能告诉你这行还需不需要。没有它，迁移就是对着每一条约束猜。

迁移步骤

1 · 先给当前模型打基线，用你的评测集。没有可比的数字，就发现不了回归。

2 · 用没改过的 prompt 跑新模型。 有时候它确实就是更好。更多时候它是在某一个具体维度上变差了，而那个维度就是你要干的活。

3 · 按类别诊断。 格式失败、啰嗦程度变化、拒答、推理差异，各自需要不同的修法。把它们归类，而不是一个一个单独处理。

4 · 先删约束，再考虑加。 试着删掉那些针对旧毛病的补丁。这有点反直觉，而且往往就是全部的修复——更短的 prompt 在新的模型上常常效果更好。

5 · 两边都重新打基线。 确认调整后的 prompt 在新模型上胜过旧 prompt 在旧模型上。如果还需要留退路，也确认它没有把旧模型弄坏。

6 · 先影子流量，再按比例放量。 真实流量能发现评测漏掉的东西。

7 · 让回滚保持简单。 改一行配置就能回去。别删掉旧的 prompt 版本。

静默迁移

那个你没选择去改的版本：厂商会在稳定的版本名底下更新模型。

你的 prompt 是针对某个行为调出来的，而那个行为不声不响地变了。这就是为什么即使你这侧什么都没改，定时跑评测也很重要——它是唯一的检测手段，否则症状会在几周后以用户投诉的形式出现。

实际做法：定时跑评测，分数掉了就告警，把结果当作变更检测信号，而不只是上线前的一道闸。

减少日后的痛苦

显式锁定版本，不要用会漂到最新版的别名。

让 prompt 保持精简。 约束少，要重调的就少。写得过细是迁移时的负债。

格式用受 schema 约束的生成，而不是靠 prompt 里的说明。强制机制能跨模型迁移，措辞不能。

把评测集当成一项资产来维护。 是它让迁移变成一个有度量依据的项目，而不是一场猜谜，而且第一次就能回本。

把厂商调用抽象到一个接口后面，这样切换就是改配置，而不是在各项功能里到处改代码。

要点回顾

• prompt 是冲着具体模型调的；换版本是一个正经项目，不是改改配置。
• 预期会在啰嗦程度、格式遵守、指令理解、拒答、推理行为和 token 数上出现变化。
• 先试试删约束——旧补丁可能主动伤害更新的模型。
• 打基线、原样测、按类诊断、重新打基线、影子流量、带简单回滚地放量。
• 厂商会静默更新模型；定时评测是唯一的检测手段。
• 格式靠 schema 约束而不是靠措辞，因为强制机制能跨模型迁移。

下一篇： 自托管模型