提示词-模型耦合陷阱：为何你的提示词只会说一种模型的「方言」

大多数提示词迁移在预发布环境看起来都很顺利。90% 的测试用例通过，新模型的响应感觉更清晰，演示也运行得很流畅。然后你上线了，不到两天，结构化输出解析器开始在 12% 的响应中抛出异常，一个面向用户的分类流水线开始返回错误标签，一个工具调用 Agent 在一个之前能正常处理的 Schema 上陷入了循环。没有人改动过提示词。是模型变了。

这就是提示词-模型耦合陷阱：在某个模型上可靠运行的提示词，会悄然积累对该模型特定行为怪癖的依赖，而这些依赖在迁移日之前根本看不见。

随时间悄然滋生的隐性依赖

提示词工程师很少一开始就打算将自己的工作与某个特定模型绑定。这种耦合是逐步积累的，每次针对线上系统微调提示词，就多加一层依赖。

JSON 格式化假设是最常见的罪魁祸首。不同模型对结构化输出的格式有不同的默认行为。GPT-3.5-turbo 经常将 JSON 嵌入 Markdown 代码块中；GPT-4 则直接输出裸 JSON 对象；GPT-4o 对 Schema 中的可空字段和可选参数比较宽容；而它的继任者则执行更严格的合规性检查，拒绝处理前一版本能优雅处理的 Schema。那些正常运行了十八个月的解析器，在模型版本切换的那天就开始抛出异常。

拒绝和安全阈值带来另一类耦合。每家主要实验室对安全性的调优都不一样，每一代模型都会移动这条边界线。一个要求 Agent "修改用户文件"而没有明确权限脚手架的提示词，可能在一个模型上正常运行，却在下一个模型上触发安全拒绝。针对某个模型输出分布校准的内容审核提示词，在底层模型的敏感度改变后就会失准。那些绕过特定模型拒绝模式的团队——通过小心措辞来避免触发护栏——会发现下一个模型在完全不同的地方设置了不同的护栏。

指令层级解析是最隐蔽的耦合，也是最难测试的。针对 20+ 个专有模型和 26 个开源模型的研究发现，不同模型处理冲突指令的方式差异巨大。有些模型将系统消息视为覆盖一切的硬约束；另一些则将最后一条指令视为最高优先级。大多数模型在面对来自不同层级的冲突指令时，准确率仅约 48%。那些隐式依赖特定冲突解决行为的提示词——系统提示词说一件事，用户消息说另一件事——在具有不同层级语义的模型上表现会截然不同。

响应详细程度和格式默认值很容易被低估。一个只说"总结这份文档"的提示词，从一个模型得到三句话，从另一个模型得到带标题的五段式响应。解析响应长度、提取特定位置或格式化输出以供展示的下游代码，会以一种看起来像是代码出错而非提示词过于模型特定的方式崩溃。

为什么"模型无关的提示词"基本上是个谎言

当这个问题被提出时，常见的建议是编写更具可移植性的提示词——更明确、指定格式要求、不依赖模型默认值。这在边际上有所帮助，但解决不了根本问题。

核心问题是欠规范（underspecification）。每个提示词都留下了一些未规定的行为。模型使用其训练分布来填补这些未规定的空白。不同的训练分布产生不同的填补行为。量化这一现象的研究发现，欠规范的提示词在模型或提示词变更时发生回归的可能性是前者的两倍，准确率下降超过 20%。那 20% 不是你提示词里的 Bug——那是模型在做一件合理的事，只不过碰巧与你流水线期望的不符。

还有能力差距的问题。思维链提示在具有不同原生推理能力的模型上效果不同。一个指示较弱模型"逐步思考"的提示词，会产生一个机械的步骤列表；同样的提示词用在更强的模型上，会触发一个质量上截然不同的推理过程——有时更有用，有时与下游解析期望的兼容性更差。为较小模型校准的少样本示例，可能让较大模型的输出变得冗长，从而破坏长度受限的输出。

训练数据分布造成的耦合，是任何量级的提示词工程都无法完全抽象掉的。主要基于代码训练的模型倾向于产生更结构化、简洁的响应；基于大量网络文本训练的模型则产生更口语化的响应。针对一种分布调优的提示词，在另一种分布上表现会不同，即使提示词在语法上完全相同。

实际的后果是：当你升级模型时，你的某些提示词需要重写，而不仅仅是重测。关于跨模型提示词迁移的研究发现，直接将为一个模型优化的提示词复用到目标模型上，比实际为目标模型优化的提示词性能差 27–39%。这就是耦合税。

构建可移植性测试框架

应对隐性耦合的解药，是在迁移日之前让耦合变得可见。这意味着要构建一个测试框架，不仅测试输出的正确性，还要明确地探测模型特定的行为。

首先为当前模型建立行为基准画像。 在任何迁移之前，在测试集上运行你的提示词，记录的不只是正确性，还包括格式特征：响应长度分布、JSON 有效率、Schema 合规率、指令冲突解决行为、拒绝率。这些将成为你的基准线。当新模型来临时，你运行同样的画像并对比分布差异。JSON 有效率从 99.7% 降到 97.2% 的变化，说明有什么东西改变了。等待生产错误浮现，那会在三天后才告诉你。

构建有针对性的可移植性探针。 通用测试用例能捕获输出正确性回归，但会遗漏行为耦合。你需要专门设计用于暴露模型特定行为的测试：

• 指令冲突测试：系统提示词说 X，用户消息说 Y——模型会怎么做？
• Schema 严格性测试：发送一个含有可选/可空字段的 Schema，验证响应结构。
• 详细程度测试：在相同输入下测量不同模型版本的响应长度。
• 边缘案例拒绝测试：探测触发安全响应的边界。

这些测试应该是你 CI 流水线的一部分，而不是迁移前才运行一次的东西。

将行为分类为通用行为或模型特定行为。 在多个模型上运行可移植性探针后，你会得到两类行为：可靠迁移的行为和模型特定的行为。通用行为——比如遵循带示例的明确输出格式指令、尊重温度设置、处理结构化的少样本示例——可以依赖。模型特定的行为——特定的 JSON 字段排序惯例、默认详细程度级别、指令层级语义——则不能依赖。依赖模型特定行为的提示词需要迁移工作；只依赖通用行为的提示词则可以以较低风险迁移。

为可接受的回归设置数值阈值。 "迁移看起来还不错"不是上线条件。"格式有效率在基准线 0.5% 以内，任务成功率在 2% 以内"才是。量化阈值将一个判断性决策变成了自动化门控。

Promptfoo 等工具支持这种模式：你可以针对多个模型端点运行相同的提示词配置，并根据定义的阈值比较结果，集成到 CI 中，使每次模型版本升级都自动触发测试框架。

编写低耦合提示词

你无法为复杂任务编写零耦合的提示词。但你可以通过更明确地说明你所依赖的行为来编写低耦合的提示词。

明确指定你依赖的每一个输出约束。 如果你的解析器期望没有 Markdown 包装的 JSON，就明确说明："只输出 JSON 对象，不含任何周围文本、代码块或说明。"如果你依赖某个字段即使为空也要存在，就明确说明："即使为空，也始终包含 reasoning 字段。"明确说明格式要求而不是依赖模型默认值的提示词，迁移可靠性更高，因为它们是在规定行为，而不是假设行为。

对格式关键行为使用少样本示例。 描述格式的指令文本，弱于展示格式。对于正确性至关重要的结构化输出，两三个展示你期望的确切格式的示例，比格式描述更具可移植性，因为示例触发的模式跟随行为，比指令跟随行为在不同模型间更一致。

避免依赖隐式模型惯例的措辞。 说"保持简洁"的提示词依赖每个模型对简洁的定义。说"响应不超过两句话"的提示词则不依赖。说"专业地回应"的提示词依赖每个模型训练中对专业的定义。明确指定实际风格约束的提示词更具可移植性。

隔离模型特定的提示词部分。 在复杂提示词中，识别哪些部分可能是模型特定的——为避免特定拒绝模式而调整的措辞、补偿已知模型怪癖的格式提示、为修复模型特定故障模式而选择的少样本示例。在你的提示词版本控制中清晰地标注这些部分。迁移时，你确切地知道哪些部分需要重新评估，而不用审计整个提示词。

将提示词与模型版本并排进行版本控制。 提示词就是代码。它们应该存在于版本控制中，提示词变更应该以与代码变更同等的严格性进行审查。当模型版本升级时，该升级应触发对任何含有模型特定部分的提示词的审查。处理迁移最好的团队，将模型版本变更视为需要回归测试的依赖项升级——与你对主要库版本升级所用的纪律相同。

当模型在你脚下悄然改变

最后一块拼图是将对模型漂移的响应常态化。即使你不主动升级，模型也会漂移。提供方的内部更新、提供方的 A/B 测试，以及批量大小依赖的行为，都可能在没有任何对你可见的版本变化的情况下改变模型响应。只监控硬失败（异常、空响应、Schema 违规）的监控设置，会遗漏在不破坏解析器的情况下降低输出质量的渐进式行为漂移。

处理好这个问题的团队，在语义层进行监控：他们持续追踪任务成功指标和格式分布指标，对与基准线的统计偏差设置警报，并且即使没有硬错误触发，也将响应详细程度或 Schema 合规率的突然变化视为生产事故。那些处理不好的团队，在漂移开始六周后才通过用户投诉发现问题。

随着基础模型弃用周期运行 12–18 个月，模型迁移将一直是生活的一部分。问题不是你的提示词是否需要迁移工作——它们肯定需要。问题是你从测试框架还是从生产事故中发现需要做什么工作。

---

耦合陷阱不是纪律的失败。它是针对线上系统调优提示词这一自然过程的必然结果。每一小时的优化，都在将提示词的兼容性收窄到它所针对的那个特定模型。对策不是孤立地编写更好的提示词，而是构建一个可移植性框架，在迁移截止日期到来之前，让那些依赖变得显而易见。