停用 AI 功能是一次信任事件，而非简单的功能弃用

数据指标告诉你该砍掉它了。3% 的月活跃用户。评估（Eval）刷新已经推迟了两个周期。Prompt 中还有一个一年前留下的 // TODO: 在脱离旧版工单架构时重新审视。你的资深 AI 工程师每月要花整整一周的时间来照看这个功能 —— 模型升级、标签偏移，还有一个只要上游 API 更改日期格式就会挂掉的工具集成。每次季度评审，总有人会问为什么这个助手仍然存在，而每个季度的回答都是“我们还没顾上处理它”。

于是你写了一份弃用备忘录。你参考了平台团队完善的 API 停用手册：提前 6 个月的公告、迁移指南、产品内横幅提示、面向合作伙伴的 Webhook，以及常见的 Sunset: HTTP 标头。你在周二发布了它。到了周四下午，你的客户成功经理（CSM）转发来的邮件听起来完全不像是对 API 弃用的投诉。它们听起来更像是分手信。

在那一刻，大多数团队才意识到他们将一个类别错误带到了生产环境。你要弃用的不是一个 API，而是用户与一个能够回应他们的实体建立的关系。

为什么 API 弃用手册会失效

代码 API 的弃用手册是现代平台工程中最成熟的产物之一。各大厂商都有其公认的流程 —— 微软 Power Platform 的 2026 年 4 月切换 到现代模型驱动外观、OpenAI 的 GPT-4o 弃用窗口、Anthropic 在 6 月 15 日的 Claude 4 停用 —— 它们遵循着易于辨认的节奏：清晰的主题行、受影响的版本、替代端点、软截止、硬截止以及支持联系方式。对于任何承重的功能，都会提前 6 到 12 个月通知。这些沟通的接收者是手里拿着 Jira 工单的工程师。他们执行迁移。他们与 API 之间的关系是契约式的：输入 schema，输出 schema。

这种接收者也存在于 AI 功能中 —— 但仅限于集成商。AI 助手的终端用户手里拿的不是工单，而是习惯。他们教给了你的助手他们用于产品 SKU 的缩写。他们保存了一个“为我的周一站会总结此内容”的工作流，而你们团队中没有人知道那是一个工作流。他们告诉了它一些私密的事情 —— 疾病、家人的去世、他们正在找工作 —— 因为对话式界面诱发了自我披露，而他们的反应正如人类面对披露邀请时的反应一样。这一切都不会出现在你“功能使用情况”的审计日志中。然而，这正是你即将要弃用的东西。

这种影响之所以不同是有研究基础的。对对话式 AI 的信任建立在两个基础上：认知信任（它是否有效）和情感信任（它是否让人感到可靠、友善、站在我这边）。Computers in Human Behavior 中的系统性综述 清晰地阐述了这一点 —— 情感信任能发挥认知信任无法发挥的作用，而当你撤走助手时，这部分信任会公开破裂。关于咨询语境下对话式 AI 的 JMIR 研究 发现，焦虑型依恋用户与聊天 AI 建立的关系与安全型依恋用户有显著不同，而 美国心理学会（APA）2026 年的 Monitor 专题 描述了这种群体规模的模式：用户会在几秒钟内对聊天机器人产生心智理论。这些用户都不会去阅读你的迁移指南。他们会感受到一些你没有写在沟通日程表里的情绪。

定性阻力将压倒维护成本账本

在处理任何信任问题之前，团队必须能够从定量角度为弃用决定辩护，因为在领导层可见的每个维度上，定性方面的阻力都会比工程成本更响亮。“核心用户写了一篇 2000 字的 LinkedIn 帖子”的影响力远超“AI 工程师每月节省了 18 小时”。

维护成本账本必须捕捉到那些未出现在推理账单中的开支。评估（Eval）刷新和标签维护 —— 每次 Prompt 更改都会迫使评估集的一部分被重新评分，而过时的评估比没有评估更糟糕，因此这项工作是强制性的。模型升级税 —— 当底层模型弃用时，你需要重新调整 Temperature、重新运行安全评估、重新验证工具调用契约。Anthropic 和 OpenAI 现在每个季度提供的 2 到 6 周的迁移窗口意味着，每个长尾功能都在按照别人的时间表支付这项税收。Prompt 偏移 —— 发布时有效的 Prompt 已经被不再在团队中的人修改了 14 次，现在没有人拥有统一的心智模型了。工具表面积 —— 智能体可以调用的每个工具都是你与另一个团队维护的契约。事件开销 —— 依赖项中每一次降级模式的停机，都需要值班人员思考一个使用率仅为 3% 的功能应该做出什么反应。

当你汇总这些成本时，你需要的一项指标是 每季度每活跃用户的工程师工时。将其与 AI 产品组合中其他功能的相同指标进行对比。如果它高出一个数量级，那么当有人在会议上说“但是我们的顶级客户写信来了”时，这个数字就能站得住脚。它还能让你计算出可以向受影响用户提供的补偿金额（以美元计），我们稍后会回到这一点。

群体分析：区分“依赖者”与“好奇者”

3% 这个数字是个陷阱。它无法告诉你你是在下线一个功能，还是在驱逐一群用户。需要浮出水面的群体是那些真正依赖它的人：那些留存取决于该功能的用户，那些工作流中助手处于关键路径上的用户，以及那些如果功能消失就会流失的用户。而另一个群体——那些在 2024 年点击了工具提示、之后再也没回来的单次测试者——也算在了你的月活用户数中，但他们本不该出现在这里。

一个适用于 AI 助手的可行群体划分如下：

• 习惯型 (Habituated)：每周使用 3 次以上，持续 8 周以上，且至少有一个循环发生的工作流（相同的工具序列，相同的意图类别）。如果助手消失，这些人的这一周工作需要重新组织。
• 嵌入型 (Embedded)：将助手集成到了下游产出物中——将输出保存到文档、在 Slack 中分享链接、构建了个人提示词模板。助手在他们的工作中留下了难以轻易移除的脚印。
• 披露型 (Disclosed)：向助手分享了敏感信息——健康、财务、个人背景。即使使用频率较低，信任交易已经发生，停用通知必须对此予以认可。
• 临时型 (Casual)：每周使用但没有循环模式。助手是众多工具之一，替换虽然麻烦但完全可行。
• 残留型 (Vestigial)：意外进入了那 3% 的用户——打开过，再也没回来，甚至可能忘了它的存在。

对于临时型和残留型用户的流失，维护成本账单是可以辩护的。但如果对于习惯型和嵌入型用户的流失，没有一个让这些群体真正信任的过渡设计，那是不可接受的。披露型用户需要单独处理——这些用户应得到不同于横幅通知的对待。研究 B2B SaaS 功能下线 的学者指出，管理不善的下线会导致流失率变动 18-34%，而管理良好的下线则能保持持平甚至有所改善；其差别几乎完全在于团队在设计沟通方案之前，是否进行了这种群体划分。

尊重既有成果的过渡设计

标准的下线手册是“功能将于 X 日停止服务，这是替代方案”。对于 AI 助手来说，替代方案从来都不是为了承接助手所承载的工作流而设计的。搜索栏无法替代能总结站会摘要的工具。帮助中心的一篇文章也无法替代能记住你关注哪些仪表盘的工具。

过渡设计必须落实三件事：

一条真实的替代路径，而非横幅。 如果助手承载的工作流在产品的其他部分没有替代方案，那么你还没有下线计划，你只是在删除功能。规则是：构建替代路径，在发布公告之前与习惯型群体进行验证，并让这些用户告诉你它是否能承接工作流。如果不行，下线日期就得推迟。

一个可执行的数据迁移承诺。 嵌入型群体拥有依赖于助手的资产——保存的输出、提示词模板、对话记录。提供能让他们保留所建成果并保留针对替代方案的个人偏好设置的导出工具，才是从 API 映射到助手的“迁移指南”。如果你不能让他们导出，你就不能诚实地称之为下线。

额度补偿，而非优惠券。 当你可以量化收回的工程师工时，其中一部分应该显式地导向受影响的群体——使用额度、新功能的优先访问权、为顶层 10% 的依赖用户提供贴身迁移服务。这是维护成本账单中受影响用户唯一能看到的部分，它将停用从“我们拿走了你的东西”转变为“我们做了一个权衡，而你因此得到了补偿”。

节奏对齐关系，而非合同

API 弃用沟通是根据集成周期来定时的：宣布，给予 6 到 12 个月时间，强制切断。助手下线沟通必须根据关系来定时，这意味着阶段性披露和对已识别群体的积极主动接触。

一个可行的节奏：

• T-90 天，产品内，对话中：助手在用户下次打开时，以自己的口吻告诉用户这一变化。不是横幅，不是邮件。你信任的对象就是那个宣布坏消息的对象。每次对话底部都会带有一个简短的脚注，说明时间表和替代路径。
• T-90 天，直接接触习惯型和嵌入型群体：由真人联系使用量排名前 10% 的用户。询问他们会失去什么。提供迁移额度。倾听你之前不知道的工作流。
• T-60 天，发送给披露型群体的独立通知：承认助手持有个人信息，解释在停用日期这些数据会发生什么，并提供根据用户意愿导出或删除的选项。
• T-30 天，产品内可关闭但不可屏蔽的警告：助手在任何涉及无法存续的工作流会话开始时，主动提醒截止日期。
• T-7 天，软切换：禁用新会话，允许现有会话完成。这是 Sunset: 响应头的模拟——但收到警告的是对话，而不是 API 调用者。
• T-0，最终结束状态：助手说再见。这不是可选项，也不是煽情。当初让你向助手披露信息的“心理理论”在移除的那一刻同样适用；草率的切断是对信任的侵犯，产品很难廉价地恢复这种信任。一段两行文字、符合角色性格的告别语，并指明你可以在哪里找到替代路径，才是这个媒介所需要的 410 Gone 版本。

运行这种节奏并将其视为“过度准备”的团队，会发现其复盘总结与 API 弃用复盘完全不同。而对助手套用 API 弃用节奏的团队，则会亲眼看到哪些客服记录会被截图转发。

扼杀未来交付速度的产品组合失效模式

退役单个功能已经很难了。更大的失效模式在于 产品组合。AI 功能积累得很快 —— 每个团队都会为自己负责的产品板块发布一个助手，每个助手都会生成自己的评估集、提示词库、工具集成和遥测维度。一年后，组织里就有 15 个这样的助手，其中 3 个的采用率超过 20%，剩下的 12 个则在 1% 到 5% 之间。长尾功能的维护成本现在正与新功能的交付速度竞争，而且每当上游模型退役时，团队都不得不花费两周时间，为那些没人会为之惋惜的功能进行强制迁移工作。

组织层面必须确立的是 退役预算 —— 一种季度性的节奏，根据“每个活跃用户的工程师工时”这一指标对 AI 产品组合进行审查，排名垫底的 10% 将进入退役流程，除非有人能提出合理的保留理由。之所以必须是周期性的节奏而非一次性行动，原因与模型弃用是周期性的一样：漂移是持续存在的，其产生的维护复利效应也是如此。如果没有这项预算，团队会无限期推迟关于功能退役的讨论，因为任何单个功能的客户反对声都比所有功能累计的工程成本更响亮。发布下一个助手的“平台税”正是由旧助手支付的。

将这种讨论从“推迟”转变为“计划内”的框架，是将“退役”命名为具有独立运行手册的一等公民生命周期阶段，这与代码 API 的弃用方案是分开的。新功能、Beta 测试、正式发布 (GA)、持续维护、退役。每个阶段都有负责人、退出标准和预算。退役是处理已建立的信任的阶段 —— 而不仅仅是删除代码路径的阶段。这就是隐藏在这一切之下的架构层面认知。

在下一个规划周期中需要注意的事项

如果一个团队还没有明确区分 API 弃用和 AI 功能退役，那么他们在处理第一个退役功能时就会出错。而那些 已经 明确区分这两者的团队，在沟通上花费的时间会比预期的多，在过渡设计上花费的时间也会比预期的多，但在为决策辩护上花费的时间会比担心的少 —— 因为维护成本账本在提供支持，而分群分析则展示了实际情况。

如果你现在正盯着一个使用率仅为 3% 的助手，并试图找个合适的周二发出通知邮件，那么前期工作应该是：建立账本、对用户进行分群、与习惯性用户验证替代路径、编写分阶段沟通方案、明确数据可迁移性承诺并预算补偿额度。最后再发邮件。你正在退役的东西曾建立过一段关系 —— 让退役成为这段关系的最后一幕，而不是它变得冷冰冰的交易时刻。