同一个提示词，三个模型三种失败：跨模型提示词移植指南

把在 A 模型上调好的提示词原样丢给 B 模型，然后抱怨”B 模型不行”——这是最常见的误判。同一段提示词在不同模型上失效，通常不是能力差距，而是训练偏好不同导致的响应方式差异。理解这些差异，移植时能省掉大量返工。

差异一：指令密度容忍度不同

有的模型对”规则清单”响应极好：给它 12 条编号规则，它逐条遵守。有的模型在规则超过 6～7 条后开始丢条目，尤其是排在中间的。

移植时的改法：把长规则清单改成”角色 + 少量硬约束 + 正反例”。例如原来的 10 条格式要求，压缩成 3 条硬约束加一个完整的输出样例。样例对指令密度容忍度低的模型效果远好于规则罗列。

判断方法很简单：把同一份规则清单缩到一半，看输出质量是否下降。如果不降，说明原清单本来就是冗余的。

差异二：对”禁止”的响应方式不同

“不要使用 Markdown”、“不要编造数据”这类否定指令，部分模型会理解成”要注意这件事”，然后更频繁地提到它——这就是否定式指令的反效果。

更稳的写法是给出替代行为：

❌ 不要编造数据
✅ 如果资料中没有相关数字，写"资料未提供"，并说明需要补充哪项数据

这条在移植时一定要做全文替换：把所有”不要 X”改成”当出现 X 情形时，改为做 Y”。

差异三：结构化输出的可靠度不同

JSON 输出在不同模型上差别巨大。有的模型只要在提示词里写”只输出 JSON”就稳，有的必须给完整 schema 加一个字段齐全的样例，还有的必须开原生 structured output 能力。

移植策略按可靠度递进：

1. 提示词说明 + 完整样例（最低要求）
2. 加 schema 定义（字段名、类型、是否可空）
3. 用模型原生 JSON mode / structured outputs（有就开）
4. 代码层做一次解析校验 + 失败重试（兜底，永远要做）

第 4 步不能省。任何模型都有 1～2% 的输出损坏率，线上没有重试逻辑就是等事故。

差异四：长上下文的”注意力位置”

把关键信息放在长文档中间，部分模型会漏看（经典的 lost in the middle）。移植时做两个小改造就能显著改善：

• 关键要求在开头和结尾各说一次。开头定基调，结尾复述关键约束。
• 把待处理内容放进明确的分隔符，并在内容后紧接指令：

<document>
...
</document>

基于上面 <document> 中的内容，回答：...

这个”指令后置”写法对几乎所有模型的稳定度都有帮助。

移植的标准流程（别跳过对照）

不要凭单次体验判断。按这个流程走：

1. 固定测试集：20～30 条真实输入，覆盖正常、边界、异常三类。
2. 两个模型同时跑，记录：格式合规率、关键信息完整率、幻觉条数、平均长度。
3. 只改一处再重跑。同时改提示词和参数，你永远不知道是哪个起作用。
4. 温度参数分开调：提取类任务用 0～0.2，生成类用 0.6～0.8。移植时新模型常需要不同的温度区间。

一个反常识的建议

如果你是做一个要长期维护的产品，不要为每个模型维护一份提示词。维护两套就等于维护两套 bug。更实际的做法是：写一份”结构化、少规则、多样例、指令后置”的通用提示词，再为每个模型加一层很薄的适配（通常就是 system 部分的一两句话）。

这样做的代价是通用版在单个模型上做不到极致 95 分，可能只有 90 分。但它换来了模型可替换性——而模型迭代速度远比你的提示词稳定。