AI 更新日志问题：为什么你的提示词更新正在破坏其他团队的工作

一个平台团队对他们的摘要服务的系统提示词（system prompt）进行了一行细微的调整。没有代码审查，没有迁移指南，没有版本更新——这“仅仅是一个提示词”。两周后，法律产品团队发现他们的合规自动脱敏功能一直在静默地泄露姓名。调查耗费了一个冲刺（sprint）。修复很简单。损害的是信任。

这是 AI 变更日志问题的缩影。行为现在是你系统的一等输出（first-class output），当提示词、模型、检索器或工具模式（tool schemas）发生变化时，行为也会随之改变——而这些变化都不会出现在消费方应用的 git diff 中。如果团队像对待后端部署那样对待 AI 更新，认为在 #releases 频道发一条 Slack 消息就足够了，那么他们最终会重蹈 2010 年代早期那种“我们先上线，稍后再告诉 QA”工作流的覆辙。

令人沮丧的是，组织层面的差距比技术层面的差距更大。大多数平台团队已经对提示词进行了版本控制并运行评估（evals）——提示词版本控制的工具已经很成熟了。缺失的是一份契约：一个共享的格式，告知下游消费者需要重新测试哪些工作流、什么可能会损坏，以及他们什么时候必须采取行动。没有这份契约，每一次提示词编辑都变成了一场影响范围难以预料的赌博。

为什么“它只是个提示词”是错误的思维模型

传统的 API 消费者可以阅读响应模式（response schema）。字节输入，字节输出，类型匹配——如果模式是稳定的，你就是稳定的。AI 消费者没有这种奢侈。同一个提示词和同一个模型在下个季度可能会返回语义上完全不同的答案，因为供应商进行了一次未披露的更新；一项被广泛引用的斯坦福/伯克利分析显示，GPT-4 的素数识别准确率在三个月内从 84% 下降到 51%，且没有宣布任何版本变化。当你自己的团队编辑提示词时，你就在这种不确定性之上增加了第二个静默变化的源头。

更糟糕的是，失败模式不是 500 错误。它是一个带有微妙错误答案的 200 OK。你的端点返回结构完美的 JSON。你的错误率没有变化。你的延迟仪表盘显示为绿色。唯一的信号是客户的投诉单变得更加愤怒——有时是在变更发生几周后。Anthropic 和 Apple 的研究人员都将此称为“负向翻转”（negative flips）：即之前模型能处理正确的实例现在变错了，即使整体准确率有所提高。你的下游团队关心的是他们那部分输入分布上的负向翻转，而不是你的综合评分卡。

因此，提示词更新不是代码重构。它是对公共接口的行为变更，它理应像任何其他共享依赖项的破坏性变更一样对待：需要结构化的变更日志、明确的版本控制契约和升级窗口。

静默变化的三个来源

在你能够清晰地沟通 AI 变更之前，你需要诚实地面对什么才算作变更。以下三类编辑都会改变下游行为，但大多数团队只将其中一类视为发布事件：

提示词编辑。 系统提示词、指令模板、少样本（few-shot）示例、格式化规则。即使是重新排列提示词中的项目符号，也可能改变输出风格，足以破坏下游的正则表达式。一家 LLM 可观测性供应商引用的研究指出，大多数生产环境中的 AI 事故并非归咎于模型，而是源于团队自身对提示词的更新。

模型升级。 这包括有意的更换（Claude 4.5 → Claude 4.7, GPT-4o → GPT-4.5）、供应商在“latest”别名下的静默滚动、参数更改（temperature, top-p）以及分词器（tokenizer）更新。Anthropic 的弃用政策为退役模型提供至少 60 天的通知，但那是简单的情况——困难的情况是那些名称未变但行为发生偏移的原位变化。

工具和模式变更。 如果你的智能体（agent）调用的工具在响应形状、延迟特性或参数验证规则上发生了变化，智能体的行为也会随之改变。重命名一个字段、缩减枚举值或将同步工具替换为流式工具都属于此类。重写 MCP 工具的文档字符串（docstring）也是如此，因为 LLM 会将工具描述视为提示词的一部分。

一个有用的练习：回顾你的 AI 平台最近发布的十个“小”变更，询问每一个属于这三个桶中的哪一个，以及是否通知了下游团队。大多数团队会发现他们只宣布了其中一类——通常是模型升级，因为供应商强迫他们不得不这样做。

语义化版本控制，但针对行为

这里最被低估的工具是最古老的那个：语义化版本控制（Semantic Versioning），并针对 AI 产物进行改造。如果你根据行为而非语法来重新定义“破坏性变更”，这个规范依然运行良好。

一个可行的经验准则：

• 主版本号 (MAJOR, X.0.0) — 输出格式更改、功能移除、模式不兼容的工具更改，或任何需要消费者更新代码或评估套件的更改。例如：重命名 JSON 字段；从 Markdown 输出切换到 HTML；缩减枚举值。
• 次版本号 (MINOR, 1.X.0) — 新功能、扩展输出、通过了你的黄金评估集（golden eval set）但可能会出现新边界情况的行为偏移。例如：添加工具；切换到更强大的模型；更改人设（persona）。
• 修订号 (PATCH, 1.0.X) — 错误修复、幻觉缓解、延迟或成本优化，且评估套件在黄金评估集上显示没有行为差异。例如：修正提示词中的错别字；加强护栏（guardrail）。

关键的转变在于，规则是针对你的黄金评估集进行评估的，而不是针对代码差异（diff）。一个改变了 12% 评估案例的一字符提示词更改属于 MAJOR。而一个保持了评估基准的完整提示词重写属于 PATCH。版本号描述的是观察到的行为，而不是补丁的大小——这正是消费者所需要的。

这重新锚定了整个对话。与其争论一个变更是否“真正”具有破坏性，你的发布流程会产生一个每个人都能看懂的行为差异数值。

变更日志中应该包含什么

一个有用的 AI 变更日志条目大约包含六个字段。少于这些，使用者就无法决定是否采取行动；多于这些，就没人会读。

1. 版本和日期。 SemVer 字符串、时间戳以及发布的可读名称（例如 "Q2-summarizer-tone-cleanup"）。
2. 变更内容。 Prompt 差异（或其链接）、模型变更（from/to）、工具架构（tool schema）的变化、检索器（retriever）的变更。要具体 —— “改进了提示词” 不是一个条目，而是一个道歉。
3. 变更原因。 触发变更的工单、评估（eval）结果、客户投诉或供应商弃用通知。这能让下游团队预测 他们的 使用场景是否受到了影响。
4. 行为差异。 来自评估套件的具体数字：黄金数据集（golden set）在变更前后的通过率，并标注出差异超过告警阈值的任何子组。包含 3–5 个样本输入，并并排展示旧版与新版的输出。这是最有价值的部分。
5. 迁移指南。 下游使用者必须做的事、建议做的事或可以忽略的事。要明确说明“无需操作”的情况 —— 大多数使用者不应该需要动一根手指，说明这一点可以避免无用功。
6. 回滚窗口。 旧版本在固定别名（pinned alias）下保持可调用的时长，以及弃用日期（如果有）。对于 MINOR 版本，14 天的重叠是一个合理的默认值；MAJOR 版本应给予 30 天以上。

注意缺失的内容：营销语言、内部致谢、术语黑话。变更日志不是发布公告；它是工程师为了维持系统运行而使用的接口文档。

固定别名模式

变更日志的技术补充是固定别名（pinned-alias）模式，这借鉴了 API 网关处理版本控制的方式。你的平台暴露的不是 summarizer/latest，而是 summarizer/v2、summarizer/v3 等等。使用者显式地绑定到一个版本。在幕后，每个别名都指向一个冻结的提示词 + 模型 + 工具包（tool bundle）。

这听起来很昂贵，但如果你的 Prompt 注册表已经支持带标签的发布（tagged releases），那么这几乎是免费的 —— 大多数现代的 Prompt 管理工具都支持这一点。成本主要在于纪律：永远不要就地编辑已标记版本的提示词。新的行为对应新的标签。

收益是巨大的。使用者可以按照自己的节奏采用 MAJOR 版本。你的团队可以每天发布而不会触发任何人的回归警报。当出现问题时，“使用者绑定的是哪个版本？”是一个单行查询，而不是在 Slack 里进行考古式的挖掘。

要避免的一个陷阱：不要将 latest 作为推荐的默认值。要让选择浮动版本变得显式且费力，因为每个选择 latest 的使用者都是下次你发布新版本时会给你发报警（page）的人。

评估门禁让变更日志保持诚实

带有虚构数字的变更日志比没有变更日志更糟糕。让其具有公信力的纪律是发布流水线中的评估门禁 (eval gate)：每一次 Prompt PR 都会运行黄金数据集，差异会发布到 PR 中，并根据差异机械地应用版本升级规则。

从生产环境日志中构建黄金数据集，而不是使用合成查询。每个主要用例 20 到 50 个真实案例足以捕捉到关键的回归。每个使用者团队都应该贡献自己的那部分 —— 代表 他们 工作流的五个例子，并由他们信任的评判器（judges）评分。当他们的部分出现回归时，变更日志会点名提醒他们。

这也是你捕捉供应商静默更新问题的地方。即使没有任何更改，也要定期针对别名背后的模型运行黄金数据集。昨天流水线还是绿色的，今天变红了，期间没有任何代码提交，这意味着供应商在你不知情的情况下进行了更改。这算作一次发布事件，也值得记入变更日志 —— 即使内容只是 “供应商推送了行为变更；以下是受影响的评估案例；这是解决方法。”

无瓶颈的协作

这一切在组织上的风险是造成审批瓶颈。如果每次 Prompt 编辑都需要召开利益相关者评审会议，你的平台团队就会开始将变更隐藏在更大的 PR 中以避免繁琐的仪式。这比没有流程更糟糕。

诀窍是将协调成本推给变更分类，而不是变更本身。PATCH 变更可以无仪式地发布 —— 评估通过、自动部署、根据 PR 生成变更日志。MINOR 变更在当天发布，但需要向使用者发布加入公告（Slack、电子邮件等 —— 但要附带变更日志条目）。只有 MAJOR 变更才需要在弃用窗口开始计时之前得到每个使用者团队的主动确认。

这镜像了成熟的变更管理计划在非 AI 背景下的运作方式：大多数变更是常规的，少数是重大的，而罕见的破坏性变更（breaking change）则值得真正的协调。试图将沉重的流程应用于所有三个类别，只会让工程师厌恶流程并设法绕过它。

什么是理想的状态

一个解决了 AI 变更日志 (changelog) 问题的团队通常是这样的：他们的 Prompt 注册表拥有带标签的版本和不可变的变更历史。每一次变更都会运行“黄金评估 (golden eval)”，并将行为差异 (behavior diff) 发布到 PR 中。版本号是根据差异机械地计算出来的。变更日志会发布到下游团队订阅的固定频道，并清晰标注“必须执行的操作”与“可选操作”。消费者会固定版本，并根据自己的计划采用新的主版本 (MAJOR)。当供应商默默更新底层模型时，定期的评估会在几小时内捕捉到变化，并且当天变更日志中就会出现一条“供应商增量 (vendor delta)”条目。

这些都不是什么稀奇事。这与后端平台使用了几十年的变更管理规范如出一辙，只是被应用到了一个大多数团队尚未将其视为公共接口的层面上。现在就开始培养这种能力的团队会交付得更快，因为他们在修改内容时不会破坏其他人的工作；而没有这样做的团队最终会积累足够的下游恐惧，导致每一次 Prompt 修改都变成一场耗时数周的博弈。

更深层次的转变是认识到 Prompt、模型选择和工具架构 (tool schemas) 不再仅仅是实现细节。它们就是 API。像对待 API 一样对待它们，编写变更日志，交付速度自然会随之提升。