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

架构层面的解决方案并非“停止让客户进行定制”。定制化往往就是功能本身，而“我们将为你的合规团队提供系统提示词微调”有时甚至是客户签署合同的全部原因。真正的解决方案是将共享核心与客户特定的增量（delta）分开，从而让评估套件能够独立地对每一部分进行推理。

一个可行的方案如下：基础提示词（base prompt）是一个由 AI 团队拥有、经过版本控制、并针对标准评估集进行评估的产物，且只能通过评审进行更改。客户覆盖层（customer overlays）是另一类产物：结构化片段（例如 tone_override、refusal_additions、domain_glossary 等命名的插槽），它们在请求时通过定义的合并协议与基础提示词组合。该合并协议是确定性且可检查的——给定一个基础版本和一个覆盖层，你可以在不运行它的情况下静态地生成最终的提示词。

这带来了两个操作特性。首先，评估套件可以在模型迁移时对基础提示词进行一次评分，然后针对每个变体的分片逐一评估增量。迁移成本的增长规模是 base_eval + sum(overlay_evals)，而不是 base_eval × 47。其次，覆盖层产物现在成为了一个一级可部署实体。它可以拥有所有者、版本、变更日志、客户范围字段以及每个覆盖层的评估基准。当基础提示词更改时，系统可以标记哪些覆盖层是基于旧版本基础提示词保留的，并需要重新验证。

随架构而来的纪律则更难落地。增加一个新的覆盖层必须进行成本核算——不仅是“这对该客户是否有效”，还包括“在未来的迁移中承载此覆盖层的长期运营成本是多少”。一个每季度增加一个覆盖层而不淘汰任何覆盖层的团队，按线性进度将在 11 年内遇到 47 个变体的问题；如果销售周期加速，则只需 3 年。覆盖层审批工作流需要一个拒绝标准。如果该变体在合同期限内的预期维护成本超过了交易规模，那么答案应该是寻找另一种实现行为的方式——一个产品功能、模型端的修复或不同的客户管理姿态——而不是又一个分支。

导致债务的销售-工程脱节​

更深层次的失败模式是组织层面的，而非技术层面的。每一次定制化都由客户团队孤立地批准，而他们的动力是完成眼前的特定交易。所有定制化的累积成本则落在工程团队身上，而工程团队并不参与合同谈判。客户提出要求，销售答应下来，变体在 AI 负责人还没听说之前就已经上线生产环境了。

这种模式看起来像是一个架构问题，因为产物是一个提示词。但在结构上，它与老牌企业软件公司几十年来一直亏损的本地部署（on-prem）问题完全一致。一个为单个客户进行的“小型定制开发”，在四年后，当最初编写代码的人都已经离职时，会变成支持工程师在凌晨 2 点被传唤去处理的代码库。AI 提示词的半衰期比本地部署短，这使得这种动态变得更糟而非更好——在同样的时间跨度内，底层模型可能已经更新了三次。

解决办法不是在销售瞬间由工程端进行抵制。当 AI 负责人加入对话时，客户通常已经被承诺了该功能。解决方法在更上游：在销售过程中（而非之后）由工程部签署的定制化审批协议。该协议根据已批准的覆盖层插槽公开列表对每个新变体进行评估。如果客户的要求符合现有插槽，答案很快。如果不符合，在交易达成前，对话将上升为真正的架构决策——这个插槽是否属于产品，还是这个客户的要求本质上是一个分支。产品能承载的变体数量是有限的，只有将其视为有限资源，才能防止数量意外地漂移到 47 个。

针对变体的评估分片是强制函数​

最高杠杆率的操作纪律是：在每次模型迁移和预定节奏下，运行针对每个变体的评估分片（eval slice）。分片不需要太复杂。针对每个变体提供十几个代表性输入，并根据客户明确的成功标准进行评分，就足以暴露出重要的回归问题。评估分片的重点不在于对变体进行全面评估——那是另一项任务。其重点是为团队提供一个预警系统，在客户发现之前，标记出哪些变体在最新模型版本上发生了漂移。

那些能够很好处理 47 个变体迁移的团队，是在变体数量超过 5 个之前就建立了这种纪律。在客户入驻时添加评估分片的成本很低（客户成功团队可以在入驻期间引导出成功标准），事后添加则非常昂贵（没人记得承诺过哪些行为，且客户的期望已经固化）。强制函数是将针对变体的评估分片视为定制化审批工作流本身的交付物。没有评估分片，就不发布新的覆盖层；不通过分片测试，覆盖层就无法在迁移中存活；变体不正式废弃，评估分片就不会停用。

客户沟通手册是另一部分。当迁移提升了中位数表现但导致某个变体退化时，团队需要一个默认的响应方式，而不是“恐慌”。手册应该是：暂停受影响变体的切换，向客户传达具体的行为变化，提供修复计划（针对新模型修复覆盖层、在供应商允许的情况下暂时留在旧模型上，或一个结构化的由客户管理的过渡窗口），并将结果记录在每个变体的变更日志中，以便下次迁移时拥有上下文。这些都不神秘，但它要求将变体作为一级产物来跟踪，而不是隐含的配置差异。

战略性的认知​

企业级的提示词（Prompt）定制化并非一个 AI 功能决策。它是一个产品策略决策，关乎产品愿意吸收多少差异性（variance）来换取收入。那些深思熟虑后做决策的团队——在变体（variant）数量失控前，先构建好覆盖层基础设施、审批工作流、针对每个变体的评估切片（eval slices）以及客户沟通方案——会提前支付成本，并使其呈线性增长。而那些随性决策的团队——将变体积累视为单个销售谈判的副产品——其成本会呈阶梯函数式增长。这笔账会被推迟到下一次强制迁移时，届时账单会一次性结清，而处理这些问题所需的工程能力往往并未列入预算。

这种“随性”的版本总是比“深思熟虑”的版本更昂贵。而且这种做法更难回头，因为那些维护成本过高、无利可图的客户，已经根深蒂固地认为那个变体就是属于他们的。告诉客户“我们要弃用你的定制行为，因为它的运营开销过大”，这是一场关乎续约风险的对话，团队迟早得面对；但被迫在模型停用的截止日期压力下进行这种对话，远比在季度产品策略审查中进行要糟糕得多。

那些能够正确处理这一点的领导者，会将变体数量视为一项核心运营指标，就像基础设施团队追踪运行中的 EC2 实例一样。每一个变体都是团队至少需要迁移一次的对象。在这个框架下，任何团队无法合理解释其存在必要性的变体，都不应该存在。第 47 个变体不是一个配置项；它是一个规模虽小、文档简陋、仅供单一客户使用的产品。尽早看清这一点，才能防止公司在不知不觉中同时运营着 47 个这样的产品。