你不是选择了一个模型，而是和它结婚了：无人预估的提示词级锁定

询问任何工程主管，他们是否被模型供应商锁定了，他们都会指向抽象层。“我们通过网关路由所有内容。更换供应商只是配置更改。”端点只有一行代码。Base URL 是一个环境变量。在纸面上，迁移只需要一个周二下午。

然后他们尝试了。他们将配置切换到不同的模型系列，集成测试依然通过，但生产环境却悄然崩溃。原本总能解析的 JSON 现在被包裹在 Markdown 代码块中。准确率曾达 94% 的分类器降到了 80% 出头。一个稳定运行了一年的提示词开始因为无人能复现的原因，在每 20 个请求中拒绝 1 个。端点在几秒钟内完成了切换，但行为并没有随之迁移。

这就是没人预料到的锁定。它不在你的合同或 SDK 中，而是在你的提示词（prompts）中——你的团队为了适应单一模型系列的特性，一次又一次地做出的数千个细微调整。你选的不是模型，而是与之“联姻”，而“婚前协议”就是你发布过的每一个提示词。

锁定发生在提示词，而非 API

当人们想象供应商锁定时，他们想到的是基础设施：私有 SDK、自定义分词器（tokenizers）、无法重新生成的嵌入（embeddings）、连接到特定仪表盘的监控。这一层确实存在，而像兼容 OpenAI 的路由器这样体面的网关可以掩盖大部分问题。请求格式标准化了，响应结构标准化了，账单也合并了。

但网关只标准化的外壳。它无法标准化提示词 内部 的内容，而这正是真正的耦合积累的地方。每个模型系列都有其个性——一套格式习惯、指令遵循惯例、拒绝反应和推理风格。你的提示词并非在真空环境下编写的，而是针对这种个性编写的，并在每次出现问题时针对它进行调整。

想想一个提示词实际上是如何演变的。初稿要求返回 JSON，模型偶尔会加一段前言，于是有人加上了“仅返回有效的 JSON，不要包含其他文字”。模型有时会模棱两可，于是有人加上了“语气要果断”。它在某种良性的边缘案例中过度拒绝，于是有人加了一句话向它保证请求是合法的。六个月后，那个提示词有了 11 个类似的补丁，而 其中每一个补丁都是它所针对调优的那个模型的“指纹”。迁移到新的模型系列，这些补丁不仅不再起作用，其中好几个甚至会起到反作用，因为它们正在修正一个新模型根本不存在的倾向。

将这种情况乘以你产品中的几百个提示词，你就得到了没人列入路线图的迁移成本。行业估计，实际的模型迁移成本占原始开发时间的 20% 到 50%，而最主要的支出项并不是工程上的切换，而是重新推导那些你以为属于自己、实则是“租赁”来的提示词行为。

你一直在默默忍受的三种特性

锁定之所以会加剧，是因为这些适配工作是隐形的。它们给人的感觉像是“提示词的工作方式”，而不是“这个模型 的工作方式”。在切换模型时，有三类情况造成的损害最大。

格式和输出纪律。 模型在履行输出约定方面的可靠程度大相径庭。有的系列在你要求时会返回干净的 JSON；有的默认将其包裹在代码块中；第三种则倾向于在正文前进行叙述，除非你极力阻止。你的解析层编码了对你最初使用的模型的假设。即使是原生的结构化输出和函数调用功能在严格程度上也各不相同——什么算作有效模式、枚举如何处理、模型极是否会在模糊情况下捏造字段。切换的那天，你的下游解析器会遇到它们从未准备好去处理的输出。

拒绝边界。 这是最被低估的锁定形式，也是最难测试的。每个供应商划定的安全线都略有不同，而且那条线并不是一个清晰的阈值，而是一个嘈杂的局部决策边界。最近的评估工作发现，即使两个来自同一供应商的模型拒绝了超过 94% 明确禁止的提示词，大约三分之一的基础提示词在经过细微的、保持原意的改写后，其拒绝行为也会发生逆转。在 不同 供应商之间，这种差异甚至更大。你的提示词已经悄悄地围绕当前模型的精确边界进行了塑造——能够通过的措辞、能让良性但处于边缘的请求得以执行的保证、你学会避开的话题。这些都无法迁移。切换之后，你会像用户一样发现新的边界：在生产环境中，一次又一次地遇到错误的拒绝。

加载中…