AI 功能退役取证：被废弃的功能教给我们的经验，是成功功能无法企及的

这里有一个令人不安的模式：你的团队计划在下个季度推出的 AI 功能，其实早在两年前就在公司里“死”过一次了。它当时以不同的名称发布，带着不同的提示词（prompt），解决一个略有不同的问题，并在经历了六个月的增长停滞后被悄然关停。没有人记录它，没有人把这些点串联起来。本可以拯救这个周期的领先指标，一直躺在那些随功能一起被归档的数据看板里。

大多数工程组织都是为了记住成功而设计的精妙机器。发布会有复盘、博客文章和内部庆祝。但那些被砍掉的功能——尽管有精美的演示，但周活跃用户仅为 12% 的功能；当 Token 成本在超预期的工具链中叠加时导致单位经济效益倒挂的功能；那些用户先是学会信任、随后失去信心、最后完全绕开的功能——几乎没有留下任何组织记忆。而这些“死亡”中蕴含的失败模式，恰恰是你的规划流程无法预估并纳入成本的。

这不是文化问题，而是应用在错误层级的可观测性问题。团队对模型进行插桩（instrument），对提示词进行插桩。但他们很少对最初决定发布该功能的决策过程进行插桩，而且几乎从不回头根据实际发生的情况审计这些决策。功能下线取证（Decommissioning forensics）是一门系统地研究已关停 AI 功能的学科，就像 SRE 研究事故一样：通过模板、数据库，并假设下一次失败会与之前的失败产生共鸣。

为什么发布复盘抓不住真正的失败模式

发布复盘假设最难的部分是交付。对于传统软件，这基本是对的——一旦功能上线，代码就会按预期运行，有趣的失败模式会在几周内浮现。对于 AI 功能，难点恰恰相反：功能很容易发布，演示效果很好，早期指标看起来不错，然后六个月后，一场慢动作式的失败开始上演，而针对发布的复盘从结构上就无法捕捉到这一点。

三种失败类型驱动了大多数 AI 功能的“死亡”，且这三者在发布时都是不可见的：

• 信任侵蚀。功能在 85% 的时间里运行良好，这孤立来看很棒，但如果那 15% 出现在用户最关心的任务上，那就是灾难性的。用户会开发出一套绕过方法，然后养成完全避开该功能的习惯。等到流失数据反映出这一点时，该功能已经失效好几个月了。
• 成本叠加。一个单次调用成本为 0.003 美元的功能在发布时看起来是有利可图的。当产品驱动的增长将使用场景推向多轮对话、智能体工具链或更大语料库的检索时，单次会话成本会悄无声息地攀升 10–30 倍。在财务部门察觉之前，毛利率就已经倒挂了，因为成本核算将 Token 映射到基础设施，而不是映射到功能。
• 新鲜感过后的采用率崩溃。第一个月的使用量很高，因为功能很新且有内部推广。第 12 周的使用情况才反映了真实情况，而那时团队已经转向其他项目了。

这些都不会出现在发布周的复盘中。它们也不会出现在标准的商业智能看板上，因为那些看板通常只展示 DAU 和功能打开率的趋势线——这些指标掩盖了上述失败模式，而不是将其暴露出来。你必须回头研究那些经历了完整生命周期（包括死亡）的功能，才能清晰地看到这些模式。

让失败功能产生价值的事后分析模板

通用的发布复盘在这里行不通，因为有价值的问题是 AI 功能特有的。我见过行之有效的模板是围绕五个取证问题构建的，每个问题都由团队必须提供的特定产出物支持。

1. 该功能的可证伪假设是什么？ 不是它的用户故事，而是假设。例如“用户会接受 70% 以上由 AI 生成且未经编辑的文档摘要，这证明了在当前 Token 价格下的推理成本是合理的”。如果你无法从原始文档中重建一个可证伪的假设，这就是发现 #1：该功能是基于某种“感觉”构建的，并凭着惯性发布的。我见过的几乎每一个被关停的 AI 功能在追溯时都未能通过这项测试，而经历过这些的团队后来都采用了发布前假设文档，这使得未来的关停决策变得更快。

2. 哪个领先指标本可以更早地告诉我们？ 这是整个模板中杠杆率最高的问题。对于每个被关停的功能，找出回过头来看最早偏离预期的指标——以及它领先于最终决策多少周。如果信任侵蚀在第 4 周就体现在“编辑-接受比率”中，但关停决策直到第 7 个月才做出，那么你既拥有了一个经过验证的领先指标，也衡量了组织的决策延迟。随着时间的推移，这将建立起一个目录。

3. 我们的评估（Evals）在何处误导了我们？ 评估分数很少能预测生产环境的成功，但有趣的问题不是它们是否误导了我们，而是 如何 误导的。评估集是否太干净了？它是否遗漏了占据实际使用主导地位的长尾查询？它是否在生产环境是多轮对话的情况下只测试了单轮性能？答案应该写入你的评估规范手册，而不仅仅是功能讣告。

4. 峰值使用时的真实单位经济效益是多少？ 使用实际生产中的 Token 数量重新计算成本模型，而不是基于规划阶段的假设。包括那些没有人预估的开销：重试、工具链扩展、冷启动部署时的缓存未命中、监控以及每次请求的评估成本。单次成功交互的计划成本与实际成本之间的差值，几乎总是事后分析中最令人惊讶的数字。

5. 我们忽视了哪些组织信号？ 团队内部其实很清楚。总有人知道。找到那条 Slack 消息、那位持怀疑态度的工程师、那位在第 6 周就标出采用率曲线异常的产品经理，并询问是什么结构性原因阻止了该信号转化为决策。这通常是极具迁移价值的经验教训所在，因为结构性原因几乎总是会持续到下一个功能的开发中。

该模板生成的文档具有可预测的形状：假设、偏离时刻、成本意外、评估盲点、被忽视的信号。通过持续归档，这些文档将成为一个可搜索的语料库，供未来的规划参考。

真正能预示失败的领先指标

在我见过并研究过的各种功能下线案例中，总会反复出现一小组指标。就其本身而言，它们并不新鲜——资深的 AI 产品团队大多了解其中大部分——但这些指标很少被集中追踪，很少有明确的阈值定义，而且几乎从未被用来触发预设的行动。将它们集中在一处本身就具有一半的价值。

• 编辑与接受比（Edit-to-accept ratio）。 对于用户可以修改的任何 AI 输出，编辑过的输出与按原样接受的输出之比。该比例随着时间的推移而上升（尤其是针对资深用户时），是信任崩塌最可靠的单一预示指标。
• 覆盖操作耗时（Time-to-override）。 用户在看到 AI 生成的输出后，多快会切换回手动输入。覆盖操作耗时的缩短意味着用户正在学会不信任该功能。
• 功能绕过率（Feature bypass rate）。 在符合条件的会话中，静默绕过 AI 功能的比例。这是最难衡量的指标，因为它需要统计用户未采取的行动——但它也是与最终失败相关性最强的指标。
• 重新查询率（Re-query rate）。 对于检索和搜索功能，用户在 AI 响应后立即重构查询的比例。该指标的持续上升等同于一个由用户端自发运行且免费的评测套件，正在对你的功能进行评估。
• 会话深度衰减（Session depth decay）。 对于多轮对话功能，对话长度随留存时间的变化趋势。新用户会探索；老用户的使用则取决于其实用价值的底线。衰减加剧意味着该功能未能转化为习惯性使用。
• 单个完成任务的隐形成本增长（Silent cost growth per completed task）。 不是指单次请求的成本，而是指每个真正有用的结果所产生的成本。当重试、降级处理和级联工具调用增加了完成交互的成本，却没能提高成功率时，你正在实时见证单位经济效益的逆转。

每一个指标都应该有一个预设的阈值，一旦跨越，就会触发审查——不是自动终止，而是强制性的讨论。其价值不在于终止本身，而在于消除证据与决策之间的组织延迟。大多数已经宣告失败的 AI 功能，早在决策做出之前很久就已经有了证据。

AI 特有的沉没成本失败模式

传统的沉没成本偏见已经够糟了。对于 AI 功能，它有一种特定的变体，使得下线变得更难：功能“差一点就能用”。总有一个你还没试过的版本——不同的基础模型、更干净的 Prompt、更大的上下文窗口、微调、新的检索策略——团队可以很有说服力地争辩说，再迭代一个月就能迎来转机。有时确实如此，但通常并非如此。迭代预算被无限期延长，因为没有哪次单一迭代看起来是明显浪费的。

解决方法是在“事前验尸”（pre-mortem）中定义的承诺机制：一个具体的指标，如果到特定日期仍未达到，无论团队对最新实验的感觉如何，都要触发停用。这必须在发布前决定，以书面形式记录，并由有权执行的人负责。如果没有这种预先承诺，每一次迭代在孤立来看都是合理的，功能会比其自然生命周期多拖延 6 到 12 个月。

事后分析的纪律强化了这种闭环。当被下线的功能得到严格研究，并且“超出阈值的迭代”模式在报告中反复出现时，未来的规划会议自然会开始提问：“这会不会又是其中之一？”这个问题如果问得早且有证据支持，其价值将超过任何单一的评测（eval）改进。

领先指标目录作为组织资产

在一致地提交了三四份停用分析报告后，一些不同寻常的事情开始发生：领先指标目录变成了一项可以持续增值的组织资产。新的功能提案可以对照它进行评分。随着更多下线案例贡献数据点，阈值会变得更加精准。目录开始在提案阶段就能捕捉到问题——“这看起来像功能 X，它在第 4 个月因为检索陈旧度而失败了”——这才是事后分析真正的投资回报率（ROI）所在。

这是大多数团队从未达到的阶段，因为他们没有坚持记录。单个被下线的功能只产生一个教训。十个案例的语料库则能产生模式。语料库正是区分“能学习的团队”和“不断重复犯错的团队”的关键。

建立这一体系的实用建议：将每一个 AI 功能的停用记录放入存放在单一、可搜索位置的标准文档中（专门的仓库路径、Notion 数据库、Confluence 空间——工具本身并不重要，重要的是一致性）。要求每份报告都回答那五个问题。在每份文档中标记出预警问题的领先指标，以及从信号出现到采取行动之间经历了多少周的决策延迟。团队每年至少集体回顾两次这些语料。

这样做的团队会停止发布那些换个 Prompt 却本质相同的、注定失败的功能。而不这样做的团队则会给同样的失败换个新名字不断上报，每次都在疑惑为什么演示时效果如此惊艳，现实却如此骨感。

一个可落地的建议

如果你正在阅读本文，且你的团队在过去 18 个月中至少下线过一个 AI 功能，那么你今天能做的最有用的微小行动就是：利用上述五个问题写下那次下线的总结。一份文档，两小时的工作。包括最早出现偏差的具体指标，以及组织花了多长时间对此采取行动。传阅这份文档。然后，在下一个规划周期中，询问任何提议的功能是否具有你刚刚记录下来的失败特征。

这一次练习的价值将超过你团队今年将构建的大多数评测基础设施。它几乎肯定会改变至少一个发布决策。它将开启一个语料库，只要耐心地积累，它最终会捕捉到那个即将让你白白耗费六个月工程时间、并透支试用用户信任的功能。

失败的功能是 AI 工程领域最诚实的老师。唯一的要求是愿意倾听它们。