按客户定制的提示词分支：为什么你的下一次模型迁移是 47 次迁移

我上个月交流过的一位 AI 初创公司 CTO 打开她的笔记本电脑，给我看了一个数字：47。那是目前在生产环境中运行的独立系统提示词（System Prompt）的数量，每个企业客户或每个逻辑分组各占一个。基础提示词在第四个月为一家需要更温和拒绝态度的医疗客户派生（Fork）了一次。然后为一家需要引用的法律客户又派生了一次。接着是为一家金融服务客户派生的，因为他们的合规团队有一份违禁词清单。当时，这些看起来都不是什么大事。每一个都是独立批准的小需求，让大客户经理团队能够顺利签下订单。

两年后，模型提供商宣布了她那些针对旧版本调优的提示词的切换截止日期。她的工程团队直觉反应是对新模型运行评估套件（Eval Suite）。评估套件仅针对基础提示词。基础提示词仍在为 0 号客户提供服务，该客户没有任何覆盖配置，且约占收入的 9%。

另外 91% 的收入则存在于那 47 个变体中——这些变体的评估切片（Eval Slices）从未正式化，工程端的负责人至少更迭过一轮，而且它们的具体行为是客户成功团队在续约谈判中商定的，而 AI 团队中没有一个人参加过那些会议。

这就是企业级规模下的提示词派生（Prompt-Fork）问题。这不仅是一个提示词工程问题，而是一个伪装成配置开关的“派生产品线”问题。

定制化在变成棘手的派生问题之前，看起来都不像派生

大多数团队都会以同样的顺序遇到这种模式。基础提示词发布了。客户要求进行微调。最自然的处理方式是将其放入配置字段——在请求时将客户特定的指令块追加到系统提示词中。PR 只有二十行代码，评估差异微乎其微，客户很满意，团队继续前进。

团队实际上做的是 AI 领域的“数据库派生”。客户特定的指令不是数据；它们是在模型上下文窗口中运行的代码，并以尚未完全表征的方式改变模型行为。今天运行这个变体的工程成本看起来为零，因为请求路径是一样的。但在环境发生变化之前（如模型版本更新、底层评估变动、基础提示词重构），维护成本是隐形的，直到那时变体必须被重新验证。

错误在于定性。团队将定制化理解为“又一个配置开关”。它更接近于“又一个部署目标”。每个变体都有其潜在行为、故障模式、以及与提出要求的客户之间的隐性契约，并且在基础假设发生变化时都带有重新验证的负担。这些在 API 层面都不可见，但在 18 个月后的运营账本上却清晰可见。

这种复杂性的复利效应立即开始。第二次定制化很少与第一次形式相同。一个要求改变语气，下一个要求增加拒绝项，第三个则希望在特定位置注入 few-shot 示例块。在经过十次定制后，架构已不再是一个带有追加覆盖的基础提示词——而是一个模板化的拼凑产物，其中注入片段的顺序很重要，片段之间的交互很重要，而“这个客户使用哪个变体”则变成了一个无人管理的配置表查询。

没人预先计算过的迁移成本

当模型提供商弃用某个版本时，运行单个提示词的团队只需进行一次迁移。而运行 47 个变体的团队则需要进行 47 次迁移，外加处理同时运行这些变体所产生的跨变体工作。

47 个变体的迁移在结构上不同于运行 47 次评估套件。每个变体都有其独特的行为表现，团队必须在新模型上对其进行表征。每个变体都需要自己的上线/不推（go/no-go）阈值——而且这个阈值不能借用基础提示词的，因为客户对“回归”的容忍度是由他们所购买的特定变体的具体行为决定的。每个变体都有一个客户沟通周期：必须有人告诉客户他们的 AI 行为可能会发生变化，获取他们的签字认可，安排切换时间，并在变化引发投诉时承担支持工作。

更糟糕的是，故障模式是不对称的。迁移对中位数变体是成功的；中位数评估得分提升了；团队发布了。然而，某一个变体——那个依赖于旧模型中特定拒绝模式来进行语气微调的变体——发生了无人察觉的回归。客户在一周后发现了。到那时，回滚路径要么是回滚所有 47 个变体（这对那 46 个已经提升的变体来说是不可接受的），要么是进行针对单个变体的回滚（而部署架构并不支持这一点，因为变体从未被视为独立可版本化的产物）。

反向的逻辑计算同样残酷。为了避免这些工作而决定推迟迁移的团队正在积聚风险。供应商的弃用窗口是固定的。不用于迁移的每一周都是团队在未来欠下的债，而时间表并不受控。变体不会变得更容易迁移；如果有的话，它们只会变得更难，因为每当有人对基础提示词进行“微调”并隐形地传播到所有变体时，基础评估套件与各变体行为表现之间的差距就会进一步拉大。

“基础+覆盖”架构：有意识地构建

加载中…