AI 功能下线决策:当指标显示正常时,何时该果断关停
你的 AI 功能拥有 12,000 名月活跃用户。参与度图表呈上升趋势。演示每季度依然能让利益相关者印象深刻。而你的用户正悄悄绕过它。
这是产品团队会逃避数月——有时甚至数年——的下线决策,因为每个表面指标都显示该功能运行良好。仪表盘显示了采用率。但它没显示的是,支持工程师在将每个 AI 生成的摘要转发给客户之前,都在手动纠正其中的三分之一;或者高级用户已经发现,点击三次“重新生成”就能产生可以接受的输出,并默默接受了这种工作流负担。
AI 功能的下线决策异常困难,因为当演示效果令人印象深刻时,沉没成本会带来更大的冲击。传统功能的失败是显而易见的——用户不点击按钮。而 AI 功能的失败则是微妙的——用户点击了按钮,得到了平庸的结果,并产生了补偿性行为,这使得功能在你的分析中看起来依然活跃,但在实践中却带来了负面价值。
僵尸功能问题在 AI 时代更严重
每个软件产品都会积累无人使用的功能。但 AI 功能带有一种成本结构,使得“僵尸”功能尤为危险:每一次交互都会产生计算费用。与被忽略时几乎不产生费用的静态设置页面不同,一个用户勉强接受但并不信任的 AI 功能在每次请求时都会消耗 Token。
这种经济效益是具有惩罚性的。传统的闲置功能静静地躺在服务器上。而一个用户在忍受但并不信任的 AI 功能会产生推理成本,随着模型更新需要维护 Prompt,需要监测质量漂移,并且在产生令人尴尬的内容时需要工程时间来处理不可避免的边缘案例。你正在为只发挥了预期价值一小部分的功能支付全额运营成本。
这创造了一种扭曲的动态:功能的变动成本随参与度而增加——用户在没有获得实际价值的情况下尝试得越多,烧的钱就越多。而且由于 AI 功能的退化方式与传统软件不同(模型漂移、训练数据过时、竞争性替代方案改进),即使你什么都不改变,运营成本与交付价值之间的差距也会随着时间的推移而扩大。
指标无法显示的五个信号
标准的产品分析是为确定性软件设计的。AI 功能需要不同的诊断视角,因为其失败模式是概率性的和行为性的。以下是在仪表盘显示问题之前,预示下线决策的信号。
1. 重新生成的税收 (The regeneration tax)。习惯性点击“重新生成”、“再试一次 ”或在利用 AI 输出前手动编辑的用户是在告诉你,这个功能不起作用。请测量 AI 生成内容与用户最终提交内容之间的编辑距离(Edit Distance)。如果中位数编辑距离超过 40%,说明用户正在亲自操刀,你的功能只是一个针对他们原本就要写的内容的建议引擎。
2. 复制粘贴绕过 (The copy-paste bypass)。留意那些将 AI 输出拷贝到单独工具进行修改,而不是使用内置编辑功能的用户。这表明 AI 的输出足够接近起步点,但离真正有用还差得很远,以至于用户需要自己的环境来修复它。这是最糟糕的结果:你教会了用户依赖一个半成品功能,他们无法抛弃它,但也无法信任它。
3. 专家流失曲线 (The expert abandonment curve)。你最专业的用户——那些最了解该功能应该达到什么水平的人——最先停止使用它。他们意识到了 AI 产出与高质量标准之间的差距。如果你的高级用户群体的参与度下降,而整体数字却因尚未了解功能局限性的新用户而上升,那么你衡量的是无知曲线,而非采用率。
4. 支持信号反转 (The support signal inversion)。统计提及 AI 功能的支持工单。现在将它们分为两类:关于功能无法运行的工单(Bug)和关于用户困惑于输出是否正确的工单(信任)。如果关于信任的工单多于关于 Bug 的工单,说明用户无法评估 AI 的输出——这意味着即使输出是正确的,他们也无法自信地使用它。
5. 工作流重复 (The workflow duplication)。当用户建立手动流程来复制 AI 功能所做的工作时,他们已经用行动投了票。寻找那些影子化你的 AI 功能的电子表格、脚本或手动检查表。这是最清晰的下线信号,因为用户正在主动承担重复工作的成本——一次是为了运行你的功能(因为这是预期或强制 的),另一次是为了真正完成工作。
沉没成本放大器
产品团队之所以坚持失败的功能,是因为沉没成本。对于 AI 功能,有三个因素会将这种偏见放大到超出常规的水平。
令人印象深刻的演示效应 (The impressive demo effect)。AI 功能的演示效果极其出色。现场演示你的摘要功能如何从 50 页文档中提取出完美的两段摘要,确实令人印象深刻——这锚定了整个组织对该功能价值的信念。演示成了参考点,而不是日常现实,在现实中,同样的功能可能会产生幻觉(如错误的合同条款),或者遗漏关键的核心条款。关闭该功能意味着承认演示具有误导性,这感觉像是在承认无能,而不是在做一个明智的产品决策。
叙事投资 (The narrative investment)。AI 功能承载了传统功能所不具备的组织叙事。“我们是一家 AI 优先的公司”或“我们的 AI 驱动型工作流每周为客户节省 4 小时”会出现在融资计划书、财报电话会议和招聘材料中。该功能不仅仅是交付代码——它是一种战略承诺。移除它会引发对战略而非仅仅是对产品决策的质疑,而这些对话的成本非常高,以至于团队会下意识地回避它们。
边际改进陷阱 (The marginal improvement trap)。AI 功能似乎总是离成功只差一次 Prompt 修改。与传统软件中损坏的功能就是坏了不同,AI 功能存在于质量连续谱上。每周都会带来看似合理的改进:更好的 Prompt、新的模型版本、改进的检索策略。这创造了一个无限期推迟的循环,下线决策总是显得为时过早,因为“我们还没试过 X”。但在功能持续表现不佳的情况下,尝试 X、然后 Y、最后 Z 的累积成本会不断叠加。
3 倍法则与纬度测试
有两个框架可以看穿 AI 功能是否名副其实。
3 倍法则(The 3X Rule): 一个 AI 功能创造的可衡量价值应至少三倍于其直接计算成本。如果单次交互的推理成本为 0.15 美元,那么它需要证明能产生 0.45 美元或更多的具体用户价值——如节省的时间、避免的错误或产生的收入。如果无法达到这个门槛,请将其重新分类为研究项目并从产品中移除。做研究没问题,但将研究成果作为产品发布则不可取。
纬度测试(The Latitude Test): 询问当一个重度用户每天运行该功能 100 次时会发生什么。该用户的毛利是上升还是下降?这项测试揭示了那些在平均使用量下看起来合理,但在长尾端却变成“碎钞机”的 AI 功能。如果你的单用户经济模型在高参与度下发生倒置,那么你的激励结构就出问题了——你是在惩罚你最活跃的用户,而是在补贴那些参与度最低的用户。
这两个框架共同促成了一场数据看板所规避的对话:不是“这个功能有人用吗?”,而是“这个功能值它的成本吗?”
决策矩阵:关停、迭代或转型
并非每个表现不佳的 AI 功能都应该被砍 掉。但决策需要结构化,而非感性化。以下是如何区分这三种结果的方法。
关停(Kill): 当基本抽象模型错误时。如果用户不希望在这种语境下使用 AI 生成的内容——如果任务需要的判断力是用户无论准确度如何都不愿授权的——那么再多的提示词工程(Prompt Engineering)也无法解决产品与市场匹配(PMF)的问题。麦当劳在与 IBM 合作三年后撤下了其 AI 自动点餐系统,并不是因为技术不可行,而是因为顾客不想为了午餐而与机器讨价还价。
迭代(Iterate): 当质量差距是可衡量的且正在缩小进时。如果你能证明你的输出质量在用户关注的维度上逐季提升,并且用户正在向你提供真实的反馈(而不只是条件反射式地点击倒赞),那么就有改进的空间。但要设定一个时限:最多两个季度。如果到那时差距仍未缩小,你已经了解到了足够的信息,知道它可能永远无法缩小。
转型(Transform): 当 AI 有效但界面(Interface)无效时。有时底层能力是可靠的,但产品表现层是错误的。一个作为自动摘要失败的 AI 摘要功能,如果转型为“带有不确定性标注的草稿摘要”,可能会获得成功——模型相同,但交互模式不同,信任动态关系也会发生剧变。在关停 AI 之前,先问问你是否已经先审视了界面。
如何真正执行关停
最难的部分不是决定,而是执行。AI 功能会积累技术和组织上的依赖关系,使清理工作变得困难。
在发布前设定预设的关停标准。 在发布任何 AI 功能之 前,定义在什么条件下你会移除它。要具体、可衡量、有时限:“如果连续两个评审周期负面反馈超过 15%”或“如果六个月内活跃用户的人均成本超过该用户订阅价值的 20%”。在乐观情绪高涨的发布前写下这些,可以在标准达成时产生一种履行承诺的心理动力。
将关停传达为一个决策,而非一次失败。 在内部,将移除功能框定为产品纪律性的体现。这个功能教会了你一些东西:用户真正想要什么 vs 他们说他们想要什么,AI 在这个领域能可靠地交付什么 vs 它不能交付什么。在外部,为用户提供替代 AI 功能的手动工作流,并确保过渡无缝。大多数一直在避开该功能的用户反而会感到如释重负。
循序渐进地关停。 不要直接切断开关。先移除推广位。从默认开启改为手动开启(Opt-in)。观察是否有人主动开启。在 4-6 周内进行清晰的沟通并弃用。这种方法生成的数据要么会确认关停决策,要么偶尔会揭示出一个你此前不知道的狂热小众用户群体。
保留经验,而非代码。 记录下该功能教给你的关于用户行为、模型局限性以及特定领域失败模式的知识。这些是真正有价值的组织知识。代码则不然。要抵制住“保留基础设施以备我们要把它带回来”的冲动。你不会把它带回来的。你会利用所学到的一切去构建不同的东西。
那个六个月前就该消失的功能
每个产品团队都有这样一个功能。那个每个人都心知肚明效果不够好、在提示词维护 和模型更新上耗费大量工程周期、产生大量支持工单和规避方案,但却没人主张移除的 AI 功能,因为这样做感觉像是放弃。
这不是放弃。这与让你编写测试、重构混乱代码以及偿还技术债的纪律是一样的。发布功能是一个假设。有些假设是错误的。由于持续的推理成本、维护负担和信任流失,在 AI 功能上犯错的成本特别高,而且你拖延决策的每个月,这些成本都会产生复利。
行业正进入问责阶段。2023-2024 年的实验时代——那时每个产品无论是否有帮助都需要一个 AI 功能——正在让位于一个生硬的问题:这个功能证明了自己的价值吗?Gartner 预测,到 2027 年底,超过 40% 的 Agentic AI 项目将被取消。及早意识到这一点并采取行动的团队将构建出更好的产品。那些没有意识到的团队将继续缴纳“僵尸税”——在那些在仪表盘上看起来活着但在关键处已经死掉的功能上,空耗算力、工程时间和用户信任。
- https://www.mindtheproduct.com/the-2026-ai-product-strategy-huide-how-to-plan-budget-and-build-without-buying-into-the-hype/
- https://a16z.com/state-of-consumer-ai-2025-product-hits-misses-and-whats-next/
- https://www.uservoice.com/blog/when-to-kill-a-feature
- https://blog.gearflow.com/the-sunk-cost-trap-in-ai-assistants
- https://itidoltechnologies.com/blog/saas-roadmaps-2026-prioritising-ai-features-without-breaking-product/
- https://www.gleap.io/blog/ai-feature-adoption-2026
- https://techstartups.com/2025/12/09/top-ai-startups-that-shut-down-in-2025-what-founders-can-learn/
- https://www.ratomir.com/blog/when-to-kill-a-feature-a-framework-for-product-managers/
