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 周就标出采用率曲线异常的产品经理，并询问是什么结构性原因阻止了该信号转化为决策。这通常是极具迁移价值的经验教训所在，因为结构性原因几乎总是会持续到下一个功能的开发中。

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

加载中…