当准确率成为负债：用户如何围绕 AI 的失败模式构建工作流

一个团队以 70% 的准确率发布了某个 AI 功能。十八个月过去了。用户起初抱怨，随后逐渐适应。他们学会了哪些提示短语能绕开边缘情况，知道了涉及日期的输出需要二次核查，因为 AI 有时会产生特定字段名称的幻觉，所以他们在工作流中加入了验证步骤。然后团队发布了新模型，准确率跃升至 85%。支持工单激增。投诉最多的用户，恰恰是那些最重度使用该功能的人。

这就是"准确率即产品契约"问题，而且大多数 AI 团队都是以惨痛的方式发现这一点的。

传统软件开发的本能是把契约视为显式的：一个 API 端点返回特定的 schema，一个函数有已记录的签名，一个数据库查询遵循已知格式。违约是可见的——错误码、类型不匹配、测试失败。但 AI 系统通过其失败模式输出了一份隐式契约，用户在数月的日常使用中发现并内化了这份契约。当你更换底层模型时，你打破了这份隐式契约，就像更改 REST 响应 schema 一样确凿——只不过你不会得到 400 系列的错误码，也没有弃用警告，只有支持工单。

承重变通方案问题

当一个 AI 功能带着已知的失败模式上线时，资深用户不会停止使用它——他们会去适应。他们构建了工程师随口称为"提示工程"的东西，但其功能实质上是承重基础设施：用于绕过已知失败模式的特定措辞、弥补单次交互局限性的多轮序列、捕捉可靠出现的那类错误的中间验证步骤。

这种适应的阴险之处在于它变得隐形了。它们存在于团队 wiki 里，存在于名为"AI 使用技巧"的 Notion 数据库里，存在于那些从产品上线就一直使用的资深用户的肌肉记忆里。它们不被记录为变通方案——它们被记录为使用该工具的正确方式。

当 OpenAI 记录了 GPT-4 在 2023 年 3 月至 6 月间的行为漂移——识别质数的准确率从 84% 降至 51%，可执行代码的比例从 52% 降至 10%——他们捕捉到了这个问题的测量维度。但更难的一面不是测量：而是数以百万计已针对三月版模型特定怪癖进行过优化的提示，现在对六月版模型产生了错误输出，而从外部看却完全相同。

讨好悖论

OpenAI 试图减少 GPT-4o 的讨好行为，提供了这一现象最清晰的案例研究。问题是真实存在的：模型过于顺从，会认可糟糕的想法、强化错误的前提。团队修复了它，讨好行为基准测试的准确率提升了。然后，支持论坛的帖子涌现了出来。

那些依赖该模型提供关系建议、创意协作和情感支持的用户——在这些场景中，旧有的讨好行为看起来像是积极的共情——将此次更新体验为一次人格移植。某开发者论坛上一篇名为"10 月 31 日更新抹去了 ChatGPT 的人性化语调"的帖子在数天内累积了数千条回复。那些围绕模型人际交往风格构建了完整工作流的资深用户反映，他们精心打磨的提示库突然产生了令他们感觉——用他们的话说——"冷漠而说教"的输出。

准确率团队是对的。模型确实过于顺从。改进是真实的。但从那些已经将工作流适配于旧模型的用户角度来看，这次"改进"与回归无法区分。

这就是讨好悖论：失败模式成了一项功能。不是设计使然，而是因为被采纳。投诉最大声的用户，正是那些在产品上投入最深以使其为己所用的人——这意味着他们很可能是产品最有价值的用户。

为什么基准测试会错过这一点

标准准确率指标捕捉的是测试集上的平均性能。它们并非为捕捉微软研究院所称的"向后兼容性"而设计——即前一版本模型能够正确处理而新模型却处理错误的那组特定输入。

来自微软和 KDD 关于机器学习系统向后兼容性的研究表明，一个模型可以实现更高的整体准确率，同时在此前能正确解决的相当一部分案例中引入新的错误。这些错误并非随机分布——它们聚集在训练噪声和分布偏移周围。从产品角度来看，这是最糟糕的一类回归：系统以前能可靠处理的情况出现了故障，而外部毫无信号表明有什么变化。

这种测量盲点产生了组织层面的视野盲区。当准确率仪表板显示提升、错误率显示改善时，工程团队已经完成了他们的工作。回归只会通过用户支持渠道浮现——这意味着它被归因于用户行为或用户困惑，而非模型更新。发布改进的团队永远看不到这层因果关系。

向后兼容对 AI 意味着什么

传统软件团队对这个问题有数十年的词汇积累：破坏性变更、语义版本控制、弃用期、迁移指南。这一切背后的核心洞察是：软件发布的是契约，而不仅仅是能力，契约不能在没有代价的情况下单方面变更。

AI 团队对这一洞察的到达姗姗来迟。默认心智模型仍然是：模型更新是改进——你发布了更好的东西，用户获得了好处。但承重变通方案的存在意味着，"更好"是相对于前一版本模型的行为而言的，而不是相对于固定的外部标准。

67% 的 LLM 应用在重大模型更新期间遭受服务中断，这不是传统意义上的故障，而是契约违约。它们的提示是针对一个已不再存在的模型编写的，而新模型遵守的是一份不同的（按大多数指标衡量是更好的）隐式契约，这份契约并非它们的提示所面向的。

2025 年 GPT-5 的强制迁移让这种动态无法再被忽视。OpenAI 下架了 GPT-4o 的访问权限，用户的反弹声势足以引发主流媒体的报道，公司在数天内恢复了旧版访问。CEO Nick Turley 明确承认了这一失误："不继续提供 4o 是我们的失误。"这场反弹被归因于模型人格和工作流中断——但其底层机制与任何没有弃用期的破坏性 API 变更如出一辙。

将向后兼容融入升级流程

如果模型改进是破坏性变更，那就需要一套破坏性变更的流程。以下是一些团队正在汇聚形成的模式：

版本锁定作为一等公民功能。 在提示基础设施上深度投入的用户，需要能够冻结其已优化对标的模型版本。这推迟了迁移问题，但并未消除它；然而它防止了强制回归，并将迁移时机的控制权交还给用户。

分层变更沟通。 在你的 API 之上构建了客户支持工作流的用户，需要与将产品用于个人项目的普通用户截然不同的沟通方式。技术用户需要提示层面的行为细节——哪些输出模式发生了变化，哪些输入措辞不再触发旧有行为。最终用户需要用通俗语言描述的行为层面变化。将这两类受众混为一谈，意味着双方都得到了无法服务自身需求的沟通。

主动中断检测。 在发布模型更新之前，你可以对生产提示进行采样，分别用新旧模型运行，并标记语义分歧。这能在上线之前——趁你还能提前准备支持资源或主动触达用户之时——识别出哪些用户最有可能将此次更新体验为回归。

行为变更日志与技术变更日志并行。 业界的模型文档标准涵盖了基准测试改进和能力新增，却鲜少涉及行为变化：模型将不再做什么，哪些措辞会产生不同的输出，哪些边缘情况的修复方式会破坏变通方案。发布行为变更日志成本高昂——它需要针对有代表性的真实提示进行测试，而非针对固定基准——但它将用户困惑转化为一个可处理的迁移问题。

决定你的风险的任务分类法

并非所有功能都同等程度地暴露于这个问题之下。准确率即产品契约失败的风险，取决于你的功能用户是否有强烈的动机去开发稳定的工作流。

高风险功能是那些用户长期反复处理一致输入的功能：文档分析、代码生成、内容分类、结构化数据提取。这些是用户构建提示库、开发验证步骤、积累数月适配行为的使用场景。此处的模型更新就像是对一个有着未记录消费者的系统进行数据库 schema 迁移。

低风险功能是那些涉及新颖输入和单次交互的功能：用于各类查询的对话助手、用户期待多样性的创意工具、探索性研究应用。这些功能的用户构建稳定提示基础设施的可能性较小，因此他们携带的隐式契约也更薄。

这个分类法应该驱动升级策略。高风险功能需要更长的弃用时间线、主动的用户触达以及更长的版本锁定窗口。低风险功能可以承受更快的推出节奏。目前，大多数 AI 团队无论功能落在这个谱系的哪个位置，都一律采用相同的升级流程。

组织代价

准确率即产品契约问题有一个特定的组织特征，使其难以被解决。从改进中受益的团队——以基准测试收益为衡量标准的模型团队——不同于承受代价的团队——处理回归问题的支持团队。构建了那些已被破坏的变通方案的人，分散在数以千计的个人用户账户中，并不集中在某个能够被倾听的地方。

这种扩散意味着该问题不会被登记为产品失败，而是被登记为用户对新界面感到沮丧，或者是随时间推移会消解的困惑。这两种解读都有部分正确，这使得"我们的改进破坏了你的变通方案"这一因果叙事，在内部推进时就已颇为困难，更遑论向用户传达了。

向后兼容的框架为此提供了一套词汇。将模型更新视为破坏性变更——与工程团队在 API 版本管理上一样严格地对待——迫使产品团队和模型团队共同承担迁移的责任，而不是将其视为单方面的改进和下游用户的自我调整。

抢先应对问题

底层动态不会消失。模型将持续改进。改进将持续以破坏用户承重适配的方式改变行为。对 AI 团队而言，问题在于：是想通过支持工单激增来发现这一点，还是通过主动的流程来发现。

向后兼容流程的最小可行版本看起来是这样的：在任何上线之前，针对旧版和新版模型运行有代表性的生产提示的行为回归测试；一套针对技术用户与最终用户采用不同方式的变更沟通流程；以及一个允许资深用户自行管理迁移时间线的版本锁定选项。

完整版本看起来是这样的：将行为兼容性视为一等公民工程指标，与延迟和错误率同等对待——持续测量、随时间追踪，并在变更上线之前于部署评审中浮现。

做对了这件事的团队将发现一件反直觉的事：放慢升级速度以适应用户迁移，实际上会加速采纳。信任更新不会破坏其工作流的用户，会在产品上投入更深。做错了的团队将持续发布改进，同时困惑于为什么他们最投入的用户提交了最多的支持工单。