大多数团队会在最糟糕的时机发现同一个事实：下线一个 AI 功能与废弃一个 API 完全不同。你在文档中添加了停用日期，发送了常规的三封系列邮件，切换了标志位——然后眼睁睁地看着支持队列激增 80%，而用户则大声解释替代方案“运行方式不一样”。他们的意思是：旧智能体的怪癖、特定的故障模式、以及它独有的错误答案，都已经变成了业务中不可或缺的支撑。他们在那些直到消失才被察觉的行为基础上，构建了整个工作流。
这就是 AI 功能废弃的核心问题。确定性 API 具有明确的契约（contracts）。如果你移除一个端点，每个依赖它的调用者都会收到 404 错误。损坏是可追踪、有限且可预测的。概率性 AI 的输出则不同——用户集成的不是契约，而是行为分布。移除一个模型不仅是移除了一项功能，它还移除了一种特定的行为模式，用户可能在没有意识到的情况下花了几个月的时间去适应它。
当你废弃一个 REST 端点时，用户清楚地知道什么坏了：调用失败。当你废弃一个 AI 功能时，破坏是弥散性的。一个在解析升级意图方面“足够好”的客服智能体，可能被支持代表们默默地补偿了——他们学会了重新表述工单，以引导它得出正确的结果。当你用更准确的东西替换它时，同样的代表突然看到了不同的路由——这并不是因为新模型更差，而是因为他们的适应策略不再适用。
这种动态在你的用户群中大规模上演。每个与你的 AI 功能接触超过几次的用户，无论是有意识还是无意识，都建立了一个关于其行为的心理模型——包括它的怪癖。停用该功能不仅是移除了一项能力，它还使这些心理模型失效。这就是为什么功能下线会产生不成比例的用户流失，远超同等的产品变更，以及为什么在过渡期间支持成本通常会激增 40-120%。
这对工程的启示是：一次成功的 AI 下线需要将行为发现（behavioral discovery）视为头等工程问题，而不是产品沟通问题。
这是一个合理的骨架，但它优化的是管理的清晰度而非行为的迁移。对于具有深度用户集成的 AI 功能，你需要在“废弃”和“退役”之间插入一个专门围绕行为设计的迁移支持阶段——而不仅仅是切换到一个新的端点。
影子模式窗口 (The shadow mode window)：在宣布任何时间线之前，让你的替代系统与现有系统并行运行。记录两者的输出，而不将新系统的结果暴露给用户。这会给你带来两个关键的东西：行为偏差的具象测量（这两个系统产生显著不同输出的频率是多少？），以及它们分歧最大的案例清单。这些分歧案例正是用户会遇到破坏的地方——你现在知道该把迁移指导重点放在哪里了。
