被你的团队视为独立于模型版本的提示词版本

你的事故时间线显示“过去 72 小时内没有部署”。你的 Prompt 注册表也印证了这一点：prompt v37 已经冻结三周了。你的评估工具链在周二晚上运行正常。但在周三早上，你其中一个 Agent 的结构化输出失败率翻了三倍，另一个 Agent 的重试预算翻了一倍，而第三个 Agent 开始愉快地忽略一条它已经遵守了一个月的指令。什么都没变。除了确实有东西变了，而且变在组织中两边都没盯着的地方：模型。

Prompt 注册表记录 Prompt 版本。模型网关记录模型版本。但在实践中，几乎没有人追踪这两者的“配对”关系。Prompt v37 并不是一个独立的工件——无论你的工具链是否承认，它都是一份针对特定模型协商后的契约。当平台团队将 claude-sonnet-latest 别名向前推进一个补丁版本时，另一端的契约已经被悄悄修改了。由于部署发生在别人的基础设施上，且名称未变，你的事故时间线依然显示“没有部署”。

没人记录的“配对”关系

Prompt 有版本。模型也有版本。你的注册表存储前者。你的网关解析后者。我观察过的几乎所有系统中，唯独缺少了“联合版本（Joint Version）”——即明确声明“我们针对 2026-04-15 的模型快照测试了 prompt v37，并且该配对在 2026-04-22 发布”。如果没有这个，你就是在运行时组合两个独立版本化的东西，而产出结果的是这种“组合”，而非任何单独一方。

这种情况发生的原因是组织架构层面的，而非技术层面的。Prompt 存在于应用团队的仓库中，由他们的 PR 评审和评估套件把关。模型选择存在于平台团队的网关配置中，由另一套评审流程（通常还有另一套评估套件，如果有的话）把关。每一方都对自己拥有的东西进行版本控制，但没有哪一方拥有这两者的“交叉乘积”。因此，当一方变动时，另一方甚至不知道自己已经被迫发生了变动。

“别名（Alias）”是其中的关键细节。大多数生产系统不会调用像 claude-sonnet-4-6-20250929 这样固定的模型快照。它们调用的是 claude-sonnet-latest，或者是网关侧映射到“本季度选定的任何模型”，又或者是平台团队拥有的环境变量。这些抽象都在履行抽象的职责——隐藏变化的名称——但代价是应用侧对变化变得不可见。在模型变动的那天，Prompt 团队没有任何 Diff 可以查看。

为什么“没有部署”是错误的判断

当平台团队将别名从 4.6 快照升级到 4.7 快照时，应用团队会看到一个更严格遵循指令、更看重最新训练数据、且可能在未明确约束的输出格式上产生细微差异的模型。由于应用团队没有推送代码、没有提升 Prompt 版本、CI 也没有运行，这一切都不会出现在部署日志中。然而，一个外部工件已经被替换进产生行为的“组合”中了。

这并非假设。别名升级引发的事故是 2024 年以来构建的 LLM 系统中最常见的生产故障模式之一。它有一个固定的形态：一个稳定的端点名称解析到了新快照，新快照比旧快照更严格地执行 Prompt 指令，曾经用来掩盖旧模型怪癖的指令现在反而限制了新行为，系统在针对旧特性微调的评估套件上发生了退化。评估工具链没坏，模型从大多数指标来看也更好了，但这个“配对”却是未经测试的。

关于这种失效模式，我见过最清晰的表述是：每一个 Prompt 都是一份与其调试时的模型达成的隐性契约，而“切换模型”就是对该契约的重新谈判，无论是否有人将其记录为契约变更。 将这种变动称为“模型升级”掩盖了它在 Prompt 视角下的本质，即：交易对手变更。

Prompt 并非可移植的资产

人们普遍假设 Prompt 是可移植的——认为只要在供应商 SDK 上加一层薄薄的抽象，就可以像更换数据库驱动程序一样更换模型。这是一个范畴错误。数据库驱动程序隐藏的是传输（Transport）的差异，底层的 Schema 才是契约。模型抽象层隐藏的是传输的差异，而 Prompt 才是契约。仅仅因为传输格式变得可移植，并不代表契约也随之变得可移植。

加载中…