不存在的 AI 关闭开关：当用户参与共创归档内容时，如何下线功能

在你发布 AI 写作助手六个月后，你打开分析仪表盘，发现了你想要的指标：平台上 40% 的用户生成文档现在包含 AI 创作的内容。董事会将此称为参与度提升。三周后，模型提供商涨价，单位经济效益发生逆转，有人提出了一个显而易见的问题：我们能把它关掉吗？你去寻找开关，却发现那并不是一个简单的开关。这是一次涉及产品、法务和 UX 层面的迁移，要干净利落地撤除它需要两个季度，并会耗费三个原本不知道自己是利益相关方的团队的政治资本。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E4%B8%8D%E5%AD%98%E5%9C%A8%E7%9A%84%20AI%20%E5%85%B3%E9%97%AD%E5%BC%80%E5%85%B3%EF%BC%9A%E5%BD%93%E7%94%A8%E6%88%B7%E5%85%B1%E5%90%8C%E5%88%9B%E4%BD%9C%E6%A1%A3%E6%A1%88%E5%90%8E%EF%BC%8C%E5%A6%82%E4%BD%95%E5%81%9C%E7%94%A8%E5%8A%9F%E8%83%BD"]

这是 AI 产品生命周期中没人预料到的部分。发布手册涵盖了提示词工程、频率限制、评估框架和应对失控成本的紧急开关。但它没提到，当用户花了半年时间生成的产物仅因生成器的存在而存在时，会发生什么。现在，你档案库中的读取路径依赖于一个你想要退役的功能。“关闭开关”只是一个概念：它是配置文件里的一个标志。而实际的停用是一套关于存量兼容、版本化、内容溯源以及一场关于参与度提升究竟是价值还是仅仅是依赖的尴尬对话的协调决策。

大多数团队走到这一步时都会陷入僵局。他们继续亏本运行该功能，因为干净利落地撤除它的成本看起来比维持它的成本更高。这种停滞会产生复利：每多出一个月的共同创作内容，迁移面就会扩大，最终的下线会变得越来越难，而不是越来越容易。出路不是在最后时刻随机应变，而是将停用视为一种从发布之初就开始的准则。

“开关”是读取路径问题，而非写入路径问题

退役 AI 功能时的第一个惊喜是：关闭生成器是容易的一半。难的一半是档案库。该功能生成的每一份文档、摘要、草稿、转录、图像或回复仍留在系统中，仍然可读，仍然被创建它的用户及其共享的同事查看。如果你的下线计划只是“发布一个禁用写入器的标志”，那么你只解决了未来，却忽略了过去。

读取路径带来了一些特定的问题。首先是那些包含提示词、模型输出或作为元数据存储在用户可见内容旁边的工具调用轨迹的产物。在没有计划的情况下撤除功能可能会留下悬空引用，导致 UI 尝试针对一个不再存在的推理端点渲染“重新生成”按钮，或者加载一个新代码无法识别其模式（Schema）的转录。其次是那些合成生成但表现得像是用户编写的内容——从某种意义上说，用户确实编写了这些内容，因为他们进行了策划、编辑和发布，但这些内容带有只有生成器才能产生的隐藏产物。撤除功能会以用户可见的方式破坏这些产物的读取路径。

能够干净处理这一问题的模式是将写入器与读取器分离，并按不同的时间表停用。写入器——即推理调用、成本中心、你真正想要停止运行的部分——首先下线。读取器——即渲染代码、模式、知道如何显示历史产物的视图层——则在一个更长的周期内保持运行，被视为维护面而非功能面。这为你节省了成本，同时又不会破坏档案库，并且让读取路径随着用户替换或迁移旧内容而自然消亡。

对产物进行存量兼容处理与版本化

在下线时，你能做出的最有用的决策就是为现有档案打上版本标签。将弃用功能生成的每个产物视为属于某一代：“2025-Q3 生成”、“由 writer-v2 生成”、“在旧版助手下生成”。这并非虚饰。它是让你能够对档案进行后续推论的元数据——用于法律审查、内容审计，以及应对不可避免的用户提问：为什么新助手的输出与旧助手不同。

这种做法在内容溯源工作中已有先例。OpenAI、Adobe Firefly 和 Google Imagen 都嵌入了 C2PA 内容凭证标准，该标准在生成的图像中附加了一个加密签名的清单，描述了产物是由哪些工具在何时产生的。该标准旨在实现组织间的信任，但其核心理念——每个 AI 生成的产物都应携带版本化的溯源记录——同样适用于你的平台内部，尤其是在下线阶段。如果你在不进行版本化的情况下对产物进行存量兼容处理，三年后当问题出现时，你将无法区分哪些是“由弃用功能生成的”，哪些是“由当前功能生成的”。有了版本化，你只需一次查询就能找到答案。

版本化还为你提供了一个清晰的迁移单元。如果你决定为用户提供一键式操作，将旧系统下的内容重写为新系统下的内容，版本标签就是你划定迁移范围的依据。如果监管机构询问在特定窗口期生效的模型行为下产生了多少平台内容，版本标签就是答案。如果用户想要删除或标注弃用功能涉及的所有内容，版本标签就是谓语。

停止按日历日期砍掉功能，开始按用户群组逐步下线

在下线功能时，人们往往倾向于选定一个日期——比如 11 月 1 日、第四季度末或下一个重大版本发布日——并宣布该功能在那天关停。对于 AI 功能来说，这是一种错误的方法，因为用户受到的影响是不均衡的。一个整个工作流都依赖于写作助手的重度用户，与一个只试过一次就忘了的用户，对功能关停的感受完全不同。一刀切的日期将他们等同对待了。

用户群组法（Cohort approach）是根据用户行为而非日历日期，分波次地将用户迁出该功能。第一组是从未使用或仅试用过一次的用户——直接静默删除功能即可，无需通知，因为他们根本不会察觉。第二组是中度用户，他们可以通过简单的产品内提示转向替代方案。第三组是工作流高度依赖该功能的资深用户；他们需要较长的废弃过渡期、手把手的迁移支持以及直接的沟通。如果还有第四组，那就是合同或集成中明确包含该功能的客户，他们需要的是合同重新谈判，而非一份下线通知。

分波次执行能做到日期切换无法做到的两件事。首先，它让你能从每一波中学习，并为下一波调整迁移工具——从未使用过的用户不会产生反馈，但第二组用户会提出第三组用户将以更激烈的方式提出的问题，从而让你提前做好准备。其次，它限制了影响范围。如果迁移工具有 Bug，你会先在第一或第二组用户中发现，而不是在那些信任流失代价极高的资深用户中发现。

让这一切奏效的埋点建设虽简单但并非没有成本：你需要每个用户的遥测数据，以区分偶然使用和核心使用；你需要能够针对特定群组而非仅按百分比投放的功能开关（Feature-flag）基础设施；你还需要一种超越“他们是否停止请求接口”的指标来衡量迁移的成功。没有这些埋点，群组计划就会退化为日期计划。在下线期间构建这些是可行的但很慢。在发布时就将其作为功能埋点的常规部分进行构建，是能够体面退役 AI 功能的团队与不能的团队之间的分水岭。

在发布时规划退出标准，而不是在下线时

AI 领域之外的下线文献已达成明确共识：退出标准属于发布计划，而非事后复盘。同样的逻辑也适用于 AI 功能，但多了一个难点。AI 功能特别容易产生隐蔽的依赖蔓延——用户开始依赖那些他们没意识到是 AI 生成的输出，积累了只有 AI 才能生成的内容，而仪表板上显示的“活跃度提升”实际上是由于该功能的存在，而非其价值本身。这使得事后的下线判断变得尤为危险，因为你用来证明保留该功能的指标在结构上就偏向于保留它。

具体的退出标准看起来像：采用质量阈值（不仅是采用率，还包括带有粘性或任务完成信号的采用率）、单位经济效益阈值（每个成果的成本低于设定值，且成果需预先定义）、竞争阈值（该功能仍以设定的优势领先于用户的其他可选方案）以及战略契合度阈值（该功能仍处于公司想要投入的产品领域）。其中任何一项触达红线都应触发下线评估。这些都不必是硬性的自动关停触发器——触发器启动的是决策过程，而非决策本身——但触发器必须预先定义，否则最亲近该功能的人会为失败的指标寻找借口。

其中最难设定的是单位经济效益阈值，因为 Token 价格和模型性能都在不断变动。应将其设定为一个比例而非绝对数值——例如，使用该功能的用户群组中，每个成果的成本相对于人均收入的比例——这样即使 Token 价格下降 50%，该阈值仍有意义。

关于“活跃度提升即依赖”的对话

退役 AI 功能最令人不安的时刻，是产品团队意识到活跃度的提升源于依赖而非价值。这是一种特定的失效模式：功能显示出极佳的活跃度、留存贡献和使用增长，所有仪表板上的曲线都很完美，当你提议撤掉它时，团队会担心用户流失。接着有人做了一个实验，对 10% 的预留组撤掉该功能，结果预留组并没有流失——他们只是适应了，一个季度后，他们的满意度评分与对照组无异。提升是真实的，但其价值远比数据所暗示的要小。

这是产品工作中通用的度量问题的 AI 版本，古德哈特定律（Goodhart's law）描述了它的形态：当一个指标变成目标时，它就不再是一个好的度量标准了。活跃度指标尤其难以区分“用户觉得这很有价值”和“用户已经习惯了这一流程，且能同样轻易地适应其他流程”。应对之道不是忽视活跃度，而是针对任何 AI 功能，每季度至少进行一次预留组实验来衡量其反事实价值，并将该实验作为继续投入的必要条件，而非仅仅作为关停标准。

该实验的结果也是与领导层沟通的话术。“我们在 X 组中撤掉了该功能，并观察到 Y 对我们真正关心的结果产生的影响”是无论支持还是反对都站得住脚的论据。“活跃度增长了 40%，请不要让我们关掉它”不是下线计划，而是一种合理化借口。一种要求提供反事实数据的规范，会迫使这些借口浮出面。

这对你交付的下一个 AI 功能意味着什么

核心启示在于架构。你交付的每一个 AI 功能在设计之初都应该包含一个真实的、书面的且具有约束力的下线计划：在生成瞬间对产物进行版本化，以便归档记录来源；将写入端与读取端分离，以便它们可以独立退役；建立基于群组的迁移工具，使最终的下线不再需要成为一个特定的日程事件；将退出准则锚定在结果而非参与度上；以及每季度的反事实实验，用以区分真正的价值与单纯的依赖。

这一切并非全新的产品工作。新颖之处在于，AI 功能使得通用玩法的失败代价变得异常昂贵，这是以往功能退役时不曾有的 —— 因为产物会持久存在，因为参与度具有迷惑价值的粘性，因为运行成本是多变的且在持续上升，还因为围绕生成式内容的监管范围正在扩大而非缩小。那些能在 2027 年干净利落地让 AI 功能下线的团队，正是那些在 2025 年功能上线时就写好了下线计划的团队；他们在上线时展现的自律，决定了那个关闭开关是否真的存在。

你在下线时想要的那个关闭开关，必须是在上线时的设计中就内置好的。如果你没有这样做，你拥有的就不是开关，而是迁移 —— 且等待的时间越长，代价就越昂贵。