你在三月份录制的演示视频是它最后一次正常工作的时候

一家 B 轮 AI 公司的销售工程师在 3 月的一个周二录制了一段五分钟的演示视频。智能体（agent）在第一次尝试时就选对了工具，用买家的语言组织了答案，并以一种“考虑周全，而非模棱两可”的礼貌态度拒绝了一个棘手的边缘情况。那段录像被存入了资源库。在接下来的七周里，它促成了五笔交易。

到了 5 月底第六个潜在客户在入职培训电话中看到它时，模型已经收到了供应商的小版本更新，重新调整了它的拒绝话术；Prompt 被编辑了两次以修复一个无关的回归问题；工具目录增加了三个条目（模型现在更倾向于其中之一）；RAG 语料库针对新的分块器（chunker）重新建立了索引。演示视频不再是产品的录像，而是一个已经不存在的产品的录像。

买家察觉到了。客户成功代表察觉到了。AI 团队却没察觉到——因为资源库与部署之间的契约是隐性的，工程端没人被告知他们是这份契约的维护者。

演示录像背后的四个变动支点

演示视频是冻结在某一瞬间的行为承诺。在光标背后有四个移动部件，任何一个都可能在没人编辑文件的情况下让承诺失效。

模型快照。 Anthropic 的文档区分了像 claude-opus-4-5-20251101 这样的快照标识符（可重现、版本固定、有公布的停用日期）和总是指向家族最新版本的滚动别名（rolling aliases）。滚动别名对开发很方便，但对于任何需要在六周后表达相同意义的产物来说则是灾难性的。生命周期的更迭正在加快：过去能维持 18–24 个月的快照现在只有 6–12 个月，供应商经常在两个月前发出通知停用 ID。针对滚动别名录制的演示，在潜在客户观看视频的那天，其实是“贴”在了该字符串背后碰巧对应的权重上。

Prompt。 这是没人固定的组件，因为它存在于配置文件或功能开关（feature flag）中，而不是带版本的制品。在真实的 LLM 应用中，模型权重是变动最不频繁的；Prompt 每周、甚至每天都在变，而且修改者往往不知道销售演示依赖于之前的措辞。为了修复拒绝策略回归而进行的单行修改，会改写所有已录制交互的社交语调。

工具目录。 演示中的智能体从五个候选工具中选择了工具 A。到潜在客户观看时，候选工具变成了八个，其中三个的描述得到了澄清，模型的工具选择也随之发生了偏移。演示没有错，只是菜单变了。

检索基座。 如果你的演示展示了从文档中回答问题，该答案取决于检索到了哪些分块，而这又是分块器、嵌入模型和语料库快照的函数。其中任何一项的改变——尤其是嵌入模型——都会重新排列模型看到的段落，从而改变它所说的话。录制好的答案变成了一场行为彩票，而它的中奖号码已被重新洗牌。

这四个支点中的每一个都按自己的时钟漂移。在实际操作中，录制七周后这四个支点都没有移动的概率为零。

导致这一重复性事故而非偶然错误的责任鸿沟

这种情况不断发生的原因并不是因为哪个团队粗心大意，而是因为演示录像处于两个互不了解对方变更日历的职能部门的交界处。

销售团队拥有资源库。他们按照交易周期的节奏制作录像。他们根据“什么能促成交易”来对资源进行版本化——只要转化率能维持，录像就会一直轮换。AI 团队拥有部署。他们根据模型今天的表现来进行版本化。两者之间的契约是隐性的：销售认为工程基座足够稳定，3 月的视频在 6 月依然能描述产品；工程认为视频是对话式的，而非承诺性的。

这两种假设在模型生命周期面前都无法幸存。演示说：“这就是产品的功能。”经过六周无声的偏移后，部署说：“不，它不是。”买家通过认定产品有 Bug 来调和这两者。

一个有效的诊断方法：询问两个团队，演示录像属于哪个日历。如果销售说“交易日历”，而工程说“什么日历？”——那就是你要寻找的未签名的契约。

加载中…