一家 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 来调和这两者。
一个有效的诊断方法：询问两个团队，演示录像属于哪个日历。如果销售说“交易日历”，而工程说“什么日历？”——那就是你要寻找的未签名的契约。
演示录像清单 (Manifest)
修复模式与生产环境 LLM 团队在 Prompt 和评估（evals）上达成的共识一致：固定每个输入，对捆绑包进行版本化，并将版本附加到制品上。
演示清单（manifest）是一个与录像一起提交的小型 JSON 或 YAML 文件。它捕捉了录制瞬间的四个支点，其细节要具体到足以让当前的部署通过配置来重现录制的行为：
- 模型快照标识符 —— 绝不使用滚动别名。使用
claude-opus-4-5-20251101，而不是 claude-opus-latest。
- Prompt 版本 —— 系统 Prompt 的 git SHA、Prompt 管理平台的版本 ID，或两者兼有。
- 工具目录版本 —— 录制时智能体可用的工具集，包括它们的描述、Schema 以及向模型呈现时的顺序。
- 检索基座 —— 嵌入模型 ID、分块器版本以及语料库状态的快照标识符。矢量数据库快照或内容哈希（content hash）可以；“当前索引”不行。
- 输入 —— 演示使用的确切 Prompt、文件或交互。没有这些，你就无法重新运行演示以确认它依然有效。
清单很小。难点在于要在录制时编写它，而不是在三个月后买家投诉时才去进行考古式的工作。
重新录制触发器与 Demo 评估
一份清单（Manifest）是必要的，但还不够。Pin 会变动；Demo 需要知晓这一点。
闭环的模式由两部分组成。首先是自动化触发器：任何活动 Demo 清单中的 Pin 发生变化，都会向该 Demo 的负责人发出警报。被 Pin 模型的供应商发布了弃用通知？在快照失效前重新录制。修改了 Demo 所依赖的系统提示词（System message）？重新录制，或者确认该更改保留了录制时的行为。工具库（Tool catalog）发生了变化？同样处理。触发器的构建成本很低；难点在于首先要让 Demo 清单存在，这就是上一节所讨论的内容。
其次是 Demo 评估套件。对于处于活动轮换中的每一次录制，清单中的输入都会针对当前的部署环境进行每晚运行。评估的断言（Assert）非常精准：“给定这些输入，Agent 的行为在录制内容所展示的维度上，应与录制内容实质上保持一致。”工具选择、拒绝姿态、回答范围、买家预期中特定短语的出现。这与 LLM 团队用于提示词回归测试的模式相同；唯一的调整在于，这里的“黄金标准集”（Golden set）是“销售团队向潜在客户承诺的 Demo 行为”。
当评估失败时，该 Demo 会自动移出轮换序列——资产库将失败的评估视为“门禁”（Gate），而非转化率。销售团队会收到一个重录工单。买家永远不会看到一个当前部署环境无法复现的视频。
这比大多数销售团队习惯的 LLMOps 纪律要严苛。但它比大多数 AI 团队在生产环境提示词上所做的要少。资产库是这种纪律必须延伸到的新边界。
资产库是一个负债面
领导层的思维重构既简单又令人不安。每一次在活动轮换中的录制，都是一份你的工程团队在不知情的情况下签署的行为承诺。轮换窗口越长，底层基座（Substrate）变动越快，录制所承诺的内容与部署所交付的内容之间的差距就越大。这个差距就是你无法调试的支持工单，是以“等等，为什么它不像 Demo 那样运行了”为开场的续约谈判，是入职（Onboarding）发现产品名不副实后悄然将你从候选名单中删除的潜在客户。
这不是销售问题，也不是工程问题。这是两者边界上的契约问题。解决方法是使契约显式化：命名 Pin，对 Bundle 进行版本控制，以通过评估作为轮换的门禁，并在底层基座变化时重新录制。做到这一点的团队将继续销售与其 Demo 相匹配的产品。做不到的团队将继续在已经悄然变成“负债账本”的资产库之上录制新视频。
这种纪律最廉价的版本只需为每次录制准备一个 YAML 文件和一个定时任务。而最昂贵的代价，则是买家看了一个 Demo，签了合同，却在第二个月流失，并告诉了三个同行原因。在这两种情况下，录制的内容是一样的。但其底层的基座却并非如此。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
