从 GPT 换到 Claude，远不止换个接口

2026 年 10 月 31 日起，OpenAI 的 Evals 平台对现有用户变为只读；2026 年 11 月 30 日，平台将彻底关闭。凡是靠 Evals 在换模型前做测试的团队，只剩不到八周时间寻找替代方案。

客户问：换成 Claude 效果会不会更好？用 Gemini 会不会更便宜？Llama 能不能跑在自己的基础设施上？假设你是这个项目的前线部署工程师（FDE），这个问题落到了你头上。

最省事的做法是换掉接口地址、保留提示词，看看效果如何。但 OpenAI、Anthropic、Google 和 Meta 的官方文档都表明，这样行不通。表现好的提示词是为某个特定模型调出来的。换模型时，要保住的是测试集，而不是提示词的措辞。

提示词是为特定模型写的

先看 OpenAI 自己。OpenAI 建议生产应用固定使用某个模型快照，因为即使是同一系列的不同快照，表现也可能不同。也就是说，还没离开 OpenAI，风险就已经存在。

OpenAI 还区分了两种提示风格：推理模型只需给出高层目标，效果更好；GPT 模型通常需要精确的分步指令。为了让 GPT 答对而写得很细的提示词，可能并不适合推理模型，反之亦然。

同一家厂商内部的差异都这么大，提示词换到另一家厂商就更难原样适用。原因在于，写提示词的人往往会加上一些弥补旧模型短板的句子。新模型已经没有这些短板了，这些句子却还留在提示词里。

好用的 GPT 提示词，到了 Claude 上可能帮倒忙

设想一个为物流公司提取发票数据的提示词，已经在 GPT 上调了好几个月。它用 markdown 划分各个部分，包含督促模型认真彻底的指令，比如“MUST read every line, MUST NOT skip anything”（必须逐行阅读，不得跳过任何内容）。末尾还有一步，要求模型检查自己的输出。助手轮次用 { 做了预填充（prefill），以强制模型返回 JSON。

迁移到 Claude 4.6 时，这个提示词有四处需要复查。第一处会让集成立刻出错。Anthropic 明确表示，从 Claude 4.6 系列模型起，不再支持对最后一个助手轮次做预填充。因此，用 { 强制输出 JSON 的技巧必须换成别的办法。

第二处更难察觉。根据 Anthropic 的迁移说明，Claude 4.6 更主动，可能对旧模型需要的指令反应过度。Anthropic 建议弱化那些督促模型更彻底的指令。过去用大写字母防止旧模型遗漏的句子，现在可能让新模型用力过猛。

第三处是自检步骤。Anthropic 提醒，从为早期模型编写的提示词中沿用下来的复查指令，可能导致模型过度检查，增加 token 用量和延迟。

第四处涉及格式和成本。VentureBeat 的一篇独立分析指出，OpenAI 的模型更适合用 markdown 划分提示词的各个部分，Anthropic 的模型则更适合用 XML 标签。该文还指出，Anthropic 的分词器通常会把同样的文本切成更多 token。

所以，即使提示词一字未改，旧表格里的成本数字也不再成立。

Gemini 和 Llama 的坑在别处

如果目标是 Gemini 3，问题出在别的地方。Google 建议提示词直接、结构清晰，采样参数保持默认值，并提醒把 temperature 设到 1.0 以下可能导致模型出现意外行为。

如果你习惯在提取任务中把 temperature 设为 0，迁移到 Gemini 3 时应尽早检查这个习惯。

Google 还建议在给 Gemini 的提示词中始终加入少样本（few-shot）示例。按照 Google 的说法，不带示例的提示词效果可能较差。一个在其他模型上只靠指令就能正常工作的提示词，需要补上几组输入输出示例。

Llama 的差异在更底层。Meta 的模型使用自有的提示格式和特殊 token，Meta 的文档要求函数调用严格遵循指定格式，对工具的支持也更有限。因此，按 GPT 风格写的提示词和工具 schema 不能直接照搬，工具调用层几乎总要重写。

下表把这些要点整理成按目标模型划分的检查清单。其中关于 XML 标签和分词器的建议来自 VentureBeat 的独立分析，并非 Anthropic 的官方指南：

目标模型	可能引发故障的旧习惯	应对方法
GPT（换快照或换成推理模型）	不固定快照；给推理模型写分步指令	固定快照；对推理模型改为说明高层目标
Claude 4.6	预填充助手轮次；督促彻底的指令；遗留的自检步骤；markdown 分节	去掉预填充；弱化指令；删除或精简检查步骤（依据 Anthropic）。尝试 XML 标签，并按分词器重算成本（依据 VentureBeat 的分析）
Gemini 3	temperature 设为 0；提示词不带示例	采样参数保持默认；加入少样本示例；写直接、结构化的提示词
Llama	GPT 风格的工具 schema 和函数调用	按特殊 token 格式重写；工具调用严格遵循 Meta 的格式

先写评测，再改提示词

这张表只告诉你该看哪里。改过的提示词是否真的更好，只能靠测量。OpenAI 建议在修改生产环境的提示词之前，先准备有代表性的测试样例（fixture）、测试和评测检查。

Anthropic 更进一步，把这一步当作前提：做提示词工程之前，需要先有清晰的成功标准和验证方法。

自动化工具也替代不了这一步。OpenAI 的提示词优化器提醒，它改写出的提示词可能表现更差，上线前必须经过评测和人工审核。

回到发票的例子。假设你有 50 张真实且已标注的发票，包括模糊的、多页的和缺字段的。先在当前模型上跑一遍，得到基线，比如 46/50。

然后把提示词移植到新模型上再跑一遍，记录三个数字：通过率、平均 token 数和平均延迟。

有了这张表，和客户的对话就完全不同了。你不必再说“Claude 看起来还行”，而是可以说清楚新模型通过了 50 个用例中的多少个、哪些没通过、token 用量多了还是少了多少。Anthropic 也指出，有时换个模型比调提示词更容易。

但只有做了评测，你才知道自己属于哪种情况。

如果团队在用 OpenAI 的 Evals 平台，2026 年 11 月 30 日这个截止日期就是现在把测试样例迁到自己代码仓库的理由。把它们保存为文件，纳入版本控制，并且能针对任何模型运行。

对于上表没有涉及的目标模型，比如 Grok，同样适用这个原则：阅读厂商的提示词文档，列出自己的旧习惯，然后让测试样例集来做判断。

一套测试样例集，胜过一句“精通提示词”

对于想成为 FDE 的开发者，模型迁移是很好的练习，因为它贴近真实工作。拿一个自己写过的提示词，移植到另外两个模型上，搭一个小型评测框架来运行同一套测试样例，再写一页记录哪里出了问题、怎么修好的。成果可以直接放进作品集。

阅读岗位描述时，留意“eval”“LLM evaluation”“model migration”或“multi-model”等字眼。如果出现了，就把这段经历放到简历最前面，并用可衡量的结果来描述，例如“将一条提取数据管道从 GPT 迁移到 Claude，在 50 个测试样例上保持通过率不变，并通过删除多余的自检步骤降低了延迟”。

这样一句话，比“精通提示词工程”更有说服力。

模型会不断被替换，而用客户真实数据标注的测试样例集，每次切换都能复用。如果只能先做一件事，那就先建测试样例集，再优化提示词。