为什么很多公司的 AI 产品上线三个月就没人用了？

声明：本文讨论的是 AI 产品从"演示成功"走向"持续被使用"过程中的工程与运营问题，不含任何产品与厂商推广。文中给出的阈值均为经验参考值，需要结合具体业务校准。

0 先给结论

把三个月后归零的 AI 产品拉出来看，失败原因高度集中，而且几乎都不是模型能力问题。

真正缺位的是三件事：

1. 场景的重复性——这件事用户一周要做几次？
2. 结果的可预期性——输出错了，用户能不能低成本发现并修好？
3. 成本的可持续性——单位调用成本乘以真实频次，还剩多少毛利？

用一句话概括这三个月的衰减机制：演示验证的是能力上限，留存考验的是结果下限。

上限靠模型，下限靠系统。上线后所有精力都花在"把上限再推高一点"、而没人管下限的团队，三个月后必然掉下去——因为用户不是因为"它最强"留下的，而是因为"它很少出错，且已经嵌进了我每天要做的事"。

这篇文章按三层展开：先看清衰减的形状（三次断点），再拆七个根因，最后给六项工程能力和可直接抄的配置。

1 衰减的形状：不是一条平滑曲线，是三次断点

"三个月没人用了"这个说法容易被误读成缓慢下滑。实际观察到的形态是阶梯式的——绝大部分流失发生在三个时间窗口里，每个窗口的动因完全不同，需要的干预也完全不同。

这张表最重要的一列是观测信号。三次断点在数据上长得完全不一样，但很多团队只看一个数（日活），于是三次都用同一种办法应对——加功能。加功能对三个阶段都无效。

一个反直觉的推论：T3 的流失其实早在 T1 就决定了。第 8–12 周之所以没人提起，是因为 T2 期间没有任何业务指标被这个产品改善过。等到预算周期回头复盘时，它拿不出"我改变了什么业务数字"这个答案。

2 根因一：把"能力"当"产品"——价值密度与使用频次的错配

这是所有根因里最基础的一条。

用户完成一件事，通常要经过一串步骤。AI 加速的往往只是其中一步。问题在于：中间那一步变快，不会自动让整件事变快，剩下的整合成本、校验成本、交接成本仍然由用户承担。

所以留存成立的条件是一个不等式：

周收益 ≈ 单次节省时间 × 周调用频次切换成本 ≈ 学习成本 + 集成成本 + 迁移成本 + 信任建立成本
留存成立：周收益 > 切换成本，且这个差距要能被用户在一周内感知到

这个不等式解释了一个常见现象：演示效果越惊艳的场景，往往越难留存。 因为惊艳来自单次质量的极端值，而频次来自场景本身的重复性——两者经常负相关。

三种典型错配：

真正值得投的场景有共同特征：高频、单次收益中等但稳定、任务形态重复。

3 根因二：没进工作流——多一次跳转，少一层留存

"另一个需要打开的网站"，是 AI 产品的头号死因。

原因很朴素：用户产生需求的瞬间，人在某个具体的上下文里（正在写一封邮件、正在看一条工单、正在改一份表格）。从那个上下文切换到你的产品，需要付出注意力成本。 每多一个动作，就筛掉一批人。

按调用距离排，留存能力大致是这个顺序：

判据只有一句话：从用户产生需求到 AI 开始工作，中间有几个动作？超过 2 个就要警惕。

工程上的推论很直接：如果只能做独立站点，就必须额外投资"上下文传递"（一键带入原文、跳转后自动带上选中的内容）。否则用户每次都要重新描述一遍需求，这个成本会直接吃掉留存。

4 根因三：结果方差——第一次惊艳，第三次不可用

生成式输出的质量不是一个"好/坏"二值，而是一条分布：能用、勉强能用、不可用。

用户对这个分布的容忍方式，和产品经理的直觉相反：

用户不会因为"有时候很惊艳"留下，只会因为"很少出错"留下。

一次惊艳会被记住三天，一次在关键场合出错会被记住三个月。尤其在 B 端场景，一次错误输出的后果可能是对外发出的一封错邮件、一份错报价单，这种事故的负向权重极高。

所以这类产品的核心工程目标不是"把最好结果做得更好"，而是压缩方差、明确边界、给出纠错路径。四个动作：

1. 结构化输出——不让模型自由发挥格式，用约定 schema 约束返回，让结果可以被程序校验。
2. 校验与重试——校验不通过就带着错误信息重试一次，而不是直接把不合格结果交给用户。
3. 降级与转人工——低置信度不硬答，走人工队列或模板兜底。
4. 可编辑而非黑箱——让用户能改，且改动被记录，成为后续优化的样本。

有了这种轨迹，才能在 T1 阶段回答那个决定生死的问题：流失是因为结果不可用，还是因为流程太麻烦？ 两者需要的修复完全不同。

5 根因四：成本结构撑不住留存

这一条最容易被推迟处理：上线前用最好的模型跑通，觉得成本"以后优化"。但成本不是运营问题，是产品设计问题——它决定了产品形态上限。

常见的三种死法：

正确做法是把成本控制做成分级路由，而不是事后砍：

两个设计要点值得单独说：

第一，escalate_on 比 match 更重要。 让"先小后大"成为默认路径——小模型跑不顺再升级，而不是一上来就用最大的。这一步通常能把大部分常规请求留在低成本档位，而把预算留给真正难的请求。

第二，on_budget_exceeded 用降级而不是拒绝。 预算耗尽时直接报错，用户感受到的是"产品坏了"；降级后体验变差但功能仍在，用户感受到的是"慢了/差了"，后者不会立刻导致流失，前者会。

6 根因五：没有数据资产沉淀——迁移成本为零

如果用户用了三个月，所有积累都还在他自己的脑子里，那么这个产品随时可以被下一个更强的模型替代。

反过来，沉淀下来的东西就是迁移成本。沉淀分三层：

第三层最关键，也最少有人做。具体形态很简单：把用户的每一次人工修改都存成一条样本，按周归拢成评测集。它同时解决两个问题——一是能客观衡量"改了 prompt 之后到底有没有变好"，二是能定位是哪类任务在持续出错。

没有这一层，团队就只能靠"感觉这次输出好像好一点"来做决策，三个月里所有的迭代都是盲调。

7 根因六：没人对"三个月后"负责

前面五条是工程问题，这一条是组织问题，而且往往更致命。

典型过程是：立项靠一次演示，验收靠一次演示，上线即结项，团队转向下一个"创新项目"。没有人被要求回答"三个月后这个产品还在被用吗"。

三个必须落地的动作，缺一个都会回到原点：

1. 指定业务侧 owner，不是技术侧。技术侧天然关心"做得出来吗"，业务侧才关心"有人用吗"。
2. 把 AI 指标并入既有业务看板，而不是单独建一个创新看板。单独建的看板没人看，这是它三个月后消失的直接原因。
3. 预设止损与加注判据。上线前就写清：第 30 天达到什么指标就加注，低于什么指标就停。没有预设判据，项目就会以"再看看"的方式无限期悬停，直到预算被下次复盘收走。

8 根因七：信任与合规摩擦

这一条在实际项目里被低估得最严重，尤其在 B 端和强监管行业。

摩擦来自四个地方：

这四条的共同后果是一样的：用户把使用范围收缩到不重要的事情上，而这个范围没有留存价值。

需要注意的是最后一条。它不是合规问题，是产品问题——出错时用户能否知道"为什么"、能否纠正、能否追溯。一个能给出失败原因、能一键撤销、能查到这次输出依据了哪些输入的产品，和每次都只回一句"抱歉，我无法完成"的产品，留存曲线完全不同。

9 根因到能力的映射

把七条根因收起来，对应六项工程能力。这张表可以作为立项时的自检：

下面五节逐项展开。

10 场景选择器：三判据与一张打分卡

判据一：频次。 周频次到不了 3 次，就谈不上形成习惯。低于这个数的场景不是不能做，但不能作为主场景。

判据二：容错。 输出错了，用户能不能在下游发现并纠正。错了发现不了、纠正成本高的场景，对结果方差极度敏感，不适合在能力成熟前上线。

判据三：可验证。 用户判断对错的成本。给定原文让他核对摘要，成本很低；让他判断一段专业分析是否准确，成本很高。验证成本越低，用户越愿意持续使用。

打分卡的意义不在于算出的数字，而在于它把"这个场景好不好"从主观判断变成了可复核的输入。三个维度分别填 0 分的场景，无论演示多惊艳都不该作为主场景。

11 确定性工程：把方差压下去

第 4 节已经给了管道定义和轨迹格式，这里补三个容易被忽略的实现点。

第一，校验规则要写在服务端，不能只写在提示词里。 提示词里的格式要求是概率性的，服务端 schema 校验是确定性的。两者都要有，但只有后者能拦住不合格结果。

第二，重试要带着错误信息，而不是原样再问一遍。 原样重试的失败率和不重试差别不大；把"缺少 risk_items 字段"这类信息回灌，第二次成功率明显更高。重试次数上限定在 1–2 次，再往上收益迅速衰减，成本却线性增长。

第三，置信度阈值要分场景设，不要全局一刀切。 同一套 auto_accept 阈值用在内部草稿和对外文书上，结果必然是前者太严、后者太松。建议按输出的下游用途分档：

12 反馈闭环：让三个月后的产品比第一天更好

这一节的交付物只有一个：修正样本库。

实现上很朴素——用户编辑过的输出、被重新生成的请求、转人工后被修正的结果，全部落库，字段至少包含：任务类型、模板版本、模型档位、原始输出、修正后输出、时间。

然后每周做一次归因：把修正率按任务类型拆开，找出修正率最高的一两类，只优化它们。 不要试图全面改善，三个月的窗口里只够做两三件事。

为什么不用满意度？ 满意度是滞后指标，且和留存的相关性远低于修正率。用户对"帮了个小忙"的满意度可以很高，但依然不会持续使用。修正率是行为指标，改不动就是改不动。

13 30 / 60 / 90 天体检查表

把上面所有内容压成可勾选项。带 P0 标记的项未完成，不应进入下一阶段。

第 30 天（保住所：把 T1 的流失堵住）

• [ ] P0 所有输出经服务端 schema 校验，不合格结果不直达用户
• [ ] P0 低置信度有明确去向（转人工或模板兜底），不出现"硬答"
• [ ] P0 每次请求可回溯：模板版本、尝试次数、最终路径
• [ ] P0 输出可编辑，且编辑内容被落库
• [ ] P1 失败请求按任务类型归类，找出 top 3 失败场景
• [ ] P1 调用动作数 ≤ 2 且无上下文切换，否则补齐上下文传递

第 60 天（留住人：把 T2 的流失堵住）

• [ ] P0 主入口已嵌入用户原有工作流，而非独立站点
• [ ] P0 分级路由生效，常规请求走低成本档位
• [ ] P1 修正样本库累计样本可支撑一次归因分析
• [ ] P1 完成第一轮"只优化 top 1 失败场景"的迭代，并用评测集验证
• [ ] P2 共享模板库或术语表上线，形成团队级资产

第 90 天（进组织：把 T3 的流失堵住）

• [ ] P0 业务侧 owner 明确，且对指标负责
• [ ] P0 四个指标已并入既有业务看板，而非独立创新看板
• [ ] P1 止损与加注判据已书面化，并有明确的决策时点
• [ ] P1 组织级评测集成形，可支撑"改完到底有没有变好"的判断
• [ ] P2 成本与质量档位完成一次再平衡

14 成熟度分级

多数"三个月没声了"的产品停在 L0 到 L1 之间。从 L1 到 L2 的关键不是技术，是嵌入点和指标；从 L2 到 L3 的关键不是指标，是责任归属。

15 六个反模式

1. 用日活衡量 AI 产品——日活对低频高价值场景天然失真，且无法区分"来试一下"和"真的在用"。
2. 靠加功能救留存——三次断点没有一次是功能不足导致的，加功能只会让主流程更重。
3. 把提示词当接口契约——格式约束写在提示词里，等于没有约束。
4. 上线后再优化成本——成本决定了能做到什么形态，它是设计输入，不是运营输出。
5. 为控成本静默降级——用户能感觉到质量变化，只是不知道原因，归因到"这产品不行"。
6. 把项目挂在技术侧 KPI 上——技术侧的完成定义是"交付"，业务侧的完成定义是"被用"，两者不是一回事。

16 FAQ

Q1：我们场景频次确实低，是不是就没救了？ 不必然。低频场景的出路是提高单次收益的可见度——让用户明确感知到"这次省了我两小时"，而不是"好像快了一点"。同时需要更强的入口设计（降低唤起成本），否则低频必然遗忘。

Q2：加人工确认会不会反而降低留存？ 取决于加在哪。加在高风险输出的出口上，用户接受度高，因为它降低的是事故概率；加在主流程的每一次生成上，用户会烦。原则是按下游用途分档，而不是按技术置信度分档。

Q3：用户反馈很好，为什么还是不用了？ 反馈和留存测的不是一回事。用户在访谈里评价的是"东西好不好"，在实际行为里权衡的是"值不值得为它改变习惯"。看修正率和放弃率，不看满意度。

Q4：模型升级了，留存会不会自动变好？ 不会，除非升级直接改善了那个持续出错的任务类型。盲目升级还可能改变输出风格，让已形成的使用习惯失效——升级必须配评测集回归。

Q5：小团队做不到这么多，先做哪一件？ 先做 schema 校验和请求轨迹。这两件投入最小，但能同时解决"结果不可用"和"不知道问题在哪"两个最致命的问题。其余项可以排在后面。

Q6：这三个月的判据是硬性的吗？ 不是。三个月是经验观察出来的典型窗口，真实项目里取决于业务周期（例如按季度决策的组织，T3 会来得更整齐）。关键是三个断点各自需要不同的干预，而不是严格卡时间。

17 结语

AI 产品的三个月，本质是一次从"能力"到"系统"的考试。

能力考试的成绩由模型决定，这部分今天已经不难拿到——任何一个团队都能在两周内做出一个让人眼前一亮的演示。真正难的是系统考试：结果能不能稳定交付、成本能不能长期支撑、有没有沉淀、有没有人负责。

最后落在一个工程判断上：留存不是运营出来的，是被设计出来的。 它由上线前就确定的那几个决定共同决定——场景选在哪里、入口放在哪里、失败时怎么退、成本怎么分档、指标挂给谁。

这五个决定没有一个需要更强的模型，但每一个都需要在上线前想清楚。

本文为工程实践方法整理，不构成对任何具体产品或技术选型的推荐。文中阈值均为经验参考值，请结合自身业务数据校准。