为什么弃用 AI 功能比你想象的更难：用户构建了你看不见的信任脚手架

2025 年 8 月，当 OpenAI 试图从 ChatGPT 中移除 GPT-4o 时，遭遇了强烈的抵制——有组织的标签、付费用户威胁取消订阅、几天内的公开反转——最终迫使公司将其恢复为默认选项，并承诺在未来任何移除之前提供“实质性通知”。替换它的模型在团队关注的每一项基准测试中都表现得更好。但这并不重要。用户已经花了几个月的时间来了解该模型的怪癖，根据其失效模式校准自己的判断，并将它的特定措辞整合进团队从未检测过的工作流中。用“更好的版本”替换它，会让这种校准归零。

这种失效模式是标准的弃用策略手册所未涵盖的。下线一个常规的 SaaS 功能——宣布、迁移、灰度发布移除、退役——假设用户契约是 API 接口。而对于 AI 功能，契约是模型的观察行为：措辞、倾向、失效模式，以及它处理歧义的特定方式。用户在这些行为之上构建了“脚手架”，而这些脚手架大多存在于他们的头脑中、笔记本电脑上以及你的团队从未触及的下游系统中。

这个架构层面的认知令人不安：AI 功能的弃用尾部比常规功能更长，因为你无法撤销用户已经习得的东西。适用于重命名 REST 端点的迁移计划，不适用于更换模型、提示词或工具目录。下文所述的准则，区分了那些能干净利落地交付“更好版本”的团队，与那些在切换当天眼睁睁看着采用率跌至谷底的团队。

隐藏的信任校准

Hyrum 定律指出，只要有足够多的用户，接口的每一个可观察行为都会成为某些人的支撑。对于传统 API，可观察表面是字段、状态码、延迟包络。对于 AI 功能，它包括用户在输出中能看到的一切，以及他们学到的关于何时不信任它的一切。

一个与智能体合作了三个月的用户构建了四种脚手架：

• 绕过式提示词 (Workaround prompts)，用于补偿已知的弱点。“记得引用来源。”“使用项目符号，不要用段落。”这些是针对系统盲点的个人补丁。
• 下游管道，依赖于特定的输出形状。将智能体的摘要粘贴到幻灯片中的营销分析师，已经记住了摘要的长度和项目符号的样式。一个写流利段落而不是简明项目符号的新模型会破坏幻灯片模板。
• 校准后的怀疑态度。用户了解模型擅长哪些问题，以及哪些问题会自信地胡编乱造。他们据此分配信任。一个具有不同失效面的“更好”模型——总的幻觉更少，但在不熟悉的领域——会瓦解用户内心已经形成的路由规则。
• 针对 C 端产品的感情共鸣。4o 的抵制并非由基准测试退化驱动，而是由那些已经与特定对话语调建立联系的用户驱动的。

这些脚手架都不会出现在你的评估套件中。它们也不会出现在你的支持工单中。它们只会在切换当天浮出水面，表现为采用率指标下降，以及定性反馈如洪水般涌来，描述为“感觉不对劲”。

并行运行，而非“旗帜日”切换

尊重这种脚手架的弃用模式是具有明确版本表面的并行运行，而不是在功能开关背后的无声更替。与标准手册相比，有两个改变是不可商榷的。

让版本对用户可见。当用户知道他们是在与“v2 (新)”还是“v1 (旧)”对话时，行为变化就变得可追溯而非神秘。版本可见性是一种信任机制，而不仅仅是调试辅助工具。如果一个团队悄悄升级模型并等待用户报告，他们就已经失去了话语权——每一次退化看起来都像是产品坏了，而不是已知的过渡。

让切换变为先加入、后退出、再强制——按此顺序，间隔数周。在“加入 (opt-in)”窗口期，核心用户会发现他们的脚手架实际上依赖于什么。他们在此期间提交的 Bug 报告是你迁移过程中能产生的最高信号数据，因为这些报告来自选择尝试新版本并注意到具体差异的人。跳过这一阶段，同样的退化会在“旗帜日”出现，但会混杂在那些不知道发生了什么的普通用户的噪音中。

OpenAI 在 2026 年 1 月宣布 chatgpt-4o-latest API 模型将于 2 月 16 日退役（约三个月的过渡期），正是遵循了这一模式。而 2025 年 8 月试图在 ChatGPT 中提前两周发出警告就更换模型的尝试则不然。用户反应的差异清晰地对应了过渡纪律的差异。

用户可检查的行为差异仪表板

在停用（deprecation）过程中，真正重要的评估原则不是“哪个模型在基准测试中得分更高”，而是“当我们切换时，哪些用户任务的连贯性被破坏了”。这需要一个用户——而不仅仅是平台团队——可以检查的行为差异仪表板。

具体来说，将相同的输入以影子模式（shadow mode）路由到旧模型和新模型，存储这两份输出，并让用户在他们自己的查询中发现差异。出现的模式往往不是团队所预测的。即便一个通过了评估集验证的迁移，仍可能带来破坏下游管道的语气转变，或者破坏幻灯片模板的长度分布变化，亦或是破坏校准后质疑能力的信心模式改变。用户察觉到这些的时间远早于任何聚合指标。

这种仪表板能带来双重回报。在迁移期间，它为用户提供了一个根据自己的工作流验证过渡的工具。在迁移之后，它为团队提供了取证记录：当客户投诉“该代理以前会做 X，而现在不会”时，可以指向并排的差异对比，而不是模糊地回答“模型变了”。

一个有用的技巧：根据 用户定义 的准则而非平台定义的准则来展示差异。例如长度、格式、引用密度、拒绝率。让用户标记那些重要的差异。这些标签是衡量哪些回归将主导迁移后支持工作量的先行指标。

保留旧产物以便回放

在停用流程中最容易被忽略的一步是保留前任版本以便回放。在 v1 退休三个月后，某位客户投诉说 v2 正在做一些 v1 从未做过的事情。如果没有保留 v1 的提示词与模型产物，团队就无法重现 v1 的行为，无法确认回归是否真实存在，也无法校准修复该问题的优先级。

对于 AI 功能而言，保留不仅意味着归档提示词文件。它意味着固定切换当天的确切模型版本、确切的工具目录、确切的检索索引、确切的裁判配置以及确切的评估准则。可重现的运行取决于对评估涉及的每个组件进行版本固定。如果其中任何一个组件发生了偏移，回放就毫无意义。

当 AI 输出影响重大决策（如贷款、招聘、审核、医疗分诊）时，这就不再仅仅是工程上的优雅做法，而是一项合规要求。在停用后幸存下来的审计线索，是应对监管机构或原告在一年后询问 v1 时唯一的辩护方式。AI 的溯源必须覆盖训练阶段和运行阶段：塑造模型的训练数据集以及塑造特定输出的实时输入。

一个切实的保留政策是：每个发布的提示词与模型产物都会获得一个冻结的回放环境，其存续时间至少要超过产物退休后的任何法律留存期或监管窗口。回放环境不需要具备扩展性；它只需要存在。一个包含固定组件的单租户容器，且能按需运行，就足够了。

衡量过渡的评估原则

大多数评估套件独立地对系统评分：v1 得分 X，v2 得分 Y，如果 Y 大于 X 则发布。这忽略了决定停用是否成功的关键问题：从 v1 到 v2 的用户任务连贯性如何？

一个具备“过渡意识”的评估集会对每个查询提问：v1 成功了吗？v2 成功了吗？如果两者都成功了，那么输出在用户依赖的维度上是否连贯？第三个问题正是大多数“新模型更好但用户讨厌它”这类失败的隐匿之处。两个系统可能都通过了质量门槛，但产生的输出差异仍大到足以破坏下游脚手架。过渡评分必须惩罚 无谓的 差异，而不只是针对单个系统的错误。

必然的结果是，评估集本身必须与 v1 产物一起保留。如果一个团队在停用 v1 提示词的同时，让评估套件在三个月后发生偏移，那么他们就无法回答“v1 以前做过这个吗？”因为本可以展示 v1 在该输入下行为的评估已不再运行。评估套件是产物的一部分，而不是独立的基础设施。

这是我最常观察到的团队失败模式：清理发生了。与 v1 绑定的评估套件被修剪，因为“我们不再需要那些测试用例了”。随后出现了一个需要重现 v1 的客户投诉，团队才发现重现已不再可能。

采用率暴跌是信号，而非失败

如果并行运行、行为差异仪表板、保留策略和过渡评估全部到位，而切换时的采用率仍然下降，那么答案不是“用户会适应的”。答案是信任脚手架破坏的速度快于用户重建的速度，迁移进行得太快了。解决办法是放慢速度，而不是硬推。

领导层的直觉是将采用率下降解读为沟通或培训的失败。有时确实如此。但更多时候，尤其是对于高级用户的工作流，采用率下降意味着新系统解决的问题与旧系统不同——更好，但不同——你必须在恢复到以前的工作速度之前重建脚手架。这种重建需要几周，有时是几个月，而通过强制切换来猛冲会破坏用户在一年后投资 v3 所需的信任校准。

AI 功能的停用尾期比团队的规划周期更长。驱动切换时间表的指标不应该是“有多少用户已经迁移”，而应该是“迁移后每个用户的任务完成率有多稳定”。后者才能告诉你脚手架何时完成了重建。

架构必须承认的事实

契约并非 API 表面。它是模型在用户实际工作流中表现出的行为，加上用户所习得的关于何时可以信任它的所有经验。这份契约从未被记录在案，从未被审查，也从未签署。但它确实存在，而废弃它正是发布下一个版本时最困难的部分。

具体而言，这意味着大多数团队都会忽略的三项架构承诺：

• 将每个发布的 “提示词-模型” (prompt-and-model) 产物视为一个长期存在的、可重现的单元，而不是一个会被就地编辑的配置。
• 将行为差异 (behavioral-diff) 仪表盘视为产品表面，而不是内部工具。因为只有用户才会察觉到那些真正重要的差异。
• 将评估套件 (eval suite) 视为产物的一部分，与其评分的提示词和模型同步退役，而不是作为一套按自身进度演进的共享基础设施。

那些能利落地发布 AI 功能升级的团队，正是最早内化了这些理念的团队。而那些通过惨痛教训才学会这一点的团队，其 v2 版本的发布往往会演变成反面教材 —— 这并非因为 v2 更差，而是因为围绕 v1 建立的信任脚手架在崩塌之前，从未出现在任何人的视野中。