模型偏好分叉：为什么你的提示词库有三个版本且没人追踪漂移

打开任何交付 LLM 功能超过一年的团队的提示词库，你都会发现同样的情况：每个提示词都有三个略有不同的版本。一个是喜欢 Sonnet 及其指令遵循能力的工程师调优的。一个是由于延迟预算而切换到 Haiku 的工程师重写的。还有一个属于那个只在 Opus 上运行且从未迁移过的原型。每个版本都有略微不同的系统消息、不同的工具目录描述方式、不同的格式引导 —— 而且没有人追踪它们是如何产生漂移的。

""

这不是卫生问题。而是一种在每次模型升级时都会累积的协作税，它正在悄悄破坏你的评估套件与线上流量之间的关系。词库本应是共享资源。而在实践中，每个功能交付时都使用了作者最后测试的版本，评估套件运行的是评估作者偏好的版本，而路由层则根据成本而不是根据哪个变体实际通过了线上评估来选择。

那些没有察觉到的团队，已经在付出代价了。

分叉是如何发生的

分叉不是由单一决策造成的。它是许多微小的、局部合理的选择在无人察觉的情况下缓慢累积的结果。

第一个因素是开发者偏好。大量使用某种模型的工程师会对该模型产生一种“手感” —— 它处理否定词的方式，它对 "DO NOT" 与 "avoid" 的反应，它是遵循数字列表还是将其混在一起，它如何解释带有可选字段的 JSON Schema。当那名工程师编写新的提示词时，他们会针对自己有直觉的模型进行编写。随后，一位偏好不同模型的同事接手了这个提示词，发现它在自己选定的模型上表现不佳，于是进行了本地修改，而不是向上游提交一个可跨模型的重写版本。两个月后，提示词在两个不同的文件中有了两个版本，分歧变成了永久性的。

第二个因素是原型债务。有人在 Hackweek 中使用了任何能最快实现 Demo 的模型构建了一个功能。Demo 奏效了。功能在特性标志下发布了。但该标志从未被切换到“迁移到生产模型”，因为原型提示词已经针对该模型的特性进行了调优，重写它可能会导致 Demo 效果回退。因此，原型模型在功能的整个生命周期内一直留在生产环境中，提示词积累了像 // only works on opus, do not change 这样的内联注释，这些注释对人类是警告，但对路由层毫无意义。

第三个因素是评估作者偏见。编写评估套件的人选择了一个默认模型来运行它。添加到套件中的每个新提示词都会在该模型上进行验证。评估分数反映了评估作者偏好模型上的性能 —— 而这未必是处理大部分生产流量的模型，特别是在经历了评估作者毫不知情的成本驱动型路由更改之后。评估结果是绿色的；但生产环境的行为与评估结果背道而驰；没有人能解释原因，因为分析中缺失了“模型”这一列。

从内部看，这些因素都不像是有问题的。每一个都是明智的局部举措。病态在于整体：一个“看起来”像是单一共享资源的库，实际上是特定模型分叉的并行 Monorepo，而捕获这种分歧的唯一产物是六个月前某条没人找得到的 Slack 讨论帖。

评估盲区

危险不在于这些变体的存在，而在于评估套件无法告诉你哪个变体实际上正在承载生产流量，路由层也无法告诉你哪个变体实际上经过了评估。

大多数生产 LLM 系统根据成本或延迟进行路由。路由逻辑看起来很合理：将简单的请求发送给便宜的模型，将复杂的请求发送给强大的模型，在主模型被限流时进行回退。路由层并不知道提示词变体 A 是为便宜模型调优的，而变体 B 是为强大模型调优的。它根据请求的形状选择模型，并提取网关注册为“此意图的提示词”的任何变体。如果注册的变体是为与路由层刚选定的模型不同的模型调优的，那么请求就会在一个不匹配的对子上运行 —— 一个从未针对该精确提示词进行验证的模型，以及一个从未针对该精确模型进行评估的提示词。

评估套件无法捕捉到这一点，因为评估套件通常是围绕“提示词-输入”对构建的，而不是“提示词-模型-输入”三元组。你针对测试集评估 prompt_v3，套件报告一个准确率数字。评估是在 Sonnet 上运行的，而生产环境运行在 Haiku 上，这一事实只是配置中没人检查的一个脚注。当生产环境中出现回退时，团队的第一直觉是调试提示词 —— 但提示词本身没问题。提示词与模型的配对才是回退的根源。

这就是为什么“提示词漂移” —— 大多数团队用来描述这种现象的术语 —— 具有误导性。提示词并没有漂移。提示词与它们合并时完全一致。发生漂移的是提示词与理应渲染它的模型之间的隐式契约。契约从未被记录下来，因为没有人相信他们依赖于特定的模型。但事实确实如此。

协作成本在每次模型升级时都会成倍增加

分叉在稳定状态下令人烦恼。但在每次模型升级、弃用或迁移时，它都会变得异常昂贵。

当供应商发布新模型时，库中的每个变体都必须针对它重新评估。如果库中每个意图有三个分叉，那么评估成本就是 3 倍，而且对比起来更加困难，因为这些变体没有共同的基准。你无法有意义地比较“新模型上的变体 A”与“新模型上的变体 B”，因为这些变体是在不同的假设下编写的；这种比较混淆了两种变量（模型 + 提示词），而不是隔离单一变量。

当供应商弃用某个模型时，团队必须迁移为该模型调优的每个提示词。迁移不是简单的搜索和替换。这是一项重新调优的工作——提示词的前缀、格式引导、工具描述都必须针对替代模型重写。如果弃用窗口期是 90 天，而团队有 50 个特定于模型的提示词分叉，那么迁移就会变成一个谁也没预料到的全季度项目。弃用公告是预定的，但迁移成本却不是。

当成本路由层被调优为将更多流量发送到更便宜的模型时，负责路由层的团队会认为提示词会随之调整。而负责提示词的团队则认为路由器会使用经过验证的变体。两个团队都没有意识到“经过验证”是含糊的，变体是特定于模型的，切换路由权重会默默地将流量转移到未经验证的“提示词-模型”组合上。成本节省仪表盘上升了；质量仪表盘却在慢慢下降；六周后的复盘才发现了这种脱节。

每一个这类事件都是可以预见的。但每一个这类事件都让团队措手不及。原因是一样的：在某些因素迫使进行全局重新校准之前，分叉是隐形的，而到那时再进行重组已经太晚了。

必须落实的规范

解决方案不是“只用一个模型”。跨模型路由是一种合理的优化，强迫每个功能都使用同一个模型会丧失实际的成本和延迟优势。解决方案是在提示词库和评估套件中明确模型维度，让这种分歧不再是隐形的。

每个意图一个规范提示词，使用模型条件部分而不是三个分叉。 提示词是一个单一的主体，其正文具有明确的分支：一个仅在模型属于 Sonnet 级别时运行的部分，一个用于 Haiku 级别的不同部分，以及一个适用于所有模型的共享核心。分支是简短且命名的。当有人想添加特定于模型的微调时，他们编辑的是条件部分，而不是独立的文件。与规范提示词的 diff 差异使特定于模型的增量对评审者来说清晰可见，而不是埋在没人会交叉引用的分叉文件中。

如果提示词变体在发布时没有针对该特定模型运行的匹配评估切片，则 CI 任务失败。 评估套件必须能够识别模型身份，而不仅仅是提示词身份。配置是一个三元组——(prompt_version, model_id, dataset_slice)——如果任何使用的 (prompt_version, model_id) 组合没有通过评估，CI 门控将拒绝发布该提示词。像 promptfoo 和现代提示词评估平台这样的工具原生支持并行的多模型评估；规范的要求是将这种能力作为门控，而不是作为探索工具。

为每个提示词设定模型可移植性分数。 对于每个提示词，针对路由层可能分发到的每个模型运行评估并报告差异。一个在 Sonnet 上得分 92%、在 Haiku 上得分 91%、在 Opus 上得分 90% 的提示词是可移植的。一个在 Sonnet 上得分 92%、在 Haiku 上得分 67%、在 Opus 上得分 78% 的提示词则是意外地变成了特定于模型的，团队需要明确知道这一点，以便他们可以 (a) 添加缺失的模型条件部分，或 (b) 约束路由层仅将此提示词分发到它实际生效的模型上。可移植性分数将“隐式模型依赖”转化为一个可见的属性，系统其余部分可以据此做出反应。

每季度的分叉检测审计。 在提示词库中运行相似性扫描，找出团队未察觉到的趋同副本。这种扫描成本很低——对提示词正文进行嵌入相似度分析（embedding similarity），调整阈值以标记内容重合度超过 80% 但未正式关联的提示词。输出是一份按使用量排序的疑似意外分叉列表。团队每季度挑选前十个，要么将它们整合进带有模型条件部分的规范提示词中，要么正式记录为什么这种分歧是故意的。两者皆可。病态的情况是那种分歧未被记录的隐性中间状态。

具备路由感知能力的弃用方案（Playbook）。 当一个模型即将被弃用时，负责路由层的团队不能停用该模型，直到针对该模型验证过的每个提示词都针对其替代模型进行了重新验证。评估三元组——(prompt, model, dataset) — 为他们提供了一份需要重新验证的精确清单。没有这个三元组，弃用就像是大海捞针；有了它，弃用就是一个检查清单。

提示词库是一个契约，而不是一个文件夹

让这一切变得通顺的心智模型是：停止将提示词库（prompt library）仅仅看作是一个包含文本文件的文件夹。一个提示词库是一个面向随机系统（stochastic system）的多作者单仓（monorepo），而单仓所要求的所有其他规范——每个意图的单一真理来源（single source of truth）、显式的接口契约、CI 门禁、弃用政策、漂移检测（drift detection）——都同样适用。尽管其产出物是自然语言字符串而非带类型的代码，但这并不能让该库免于这些规范的约束。事实上，这反而让规范的执行变得更难，因为字符串所编码的契约是隐式的，而且这些契约的消费者（模型）是非确定性的。

在单一模型上发布第一个 LLM 功能的团队很少会察觉到分叉（fork）正在形成。而跨越三个模型发布第十个功能的团队几乎肯定已经存在分叉了。中间阶段是最危险的——团队仍将提示词库视为一个共享文件夹，模型维度仍被视为路由层（routing-layer）的问题，而评测套件（eval suite）仍将提示词视为没有任何模型特定行为的对象。等到症状在生产环境中出现时，这种分歧已经积累了数月之久，清理成本极高。

引入规范成本最低的时机是在开发第二个功能时。其次就是现在。你每等待一个季度，库中就会增加一层偶然产生的分叉，而六个月后的模型升级成本也会比上一次更高一点。

一个不强制执行单一真理来源不变性的共享提示词库并不是真正的库。它是一个冠以文件夹名称的协作债务。