AI 项目验收完就没人用了：六个真实原因
一个 AI 项目最尴尬的结局不是做砸了，是做完了、验收了、然后没人用。
系统跑得好好的，指标也达标，三个月后打开后台一看，日活个位数。
这类失败的原因很少是技术问题。这篇讲六个真实原因。
原因一：解决的不是真问题
最根本、也最常见的一个。
甲方说要做个「智能客服」，你就做了个智能客服。但没人问过：他们现在的客服到底卡在哪？
有的组织真正的问题是人手不够，那 AI 能帮上；有的是流程太长，那 AI 只是在一个烂流程上加了层皮；有的其实是知识从来没被整理过，AI 上线后照样答不上来——因为答案压根不存在。
怎么预防：需求阶段问三个问题——现在这件事是怎么做的？一天发生多少次？做不好的后果是什么？答不上来的，说明需求还没想清楚。
原因二：答案不在文档里
这是上一条的具体化，值得单独说，因为它太普遍了。
很多组织的知识分布是：一部分在文档里，一大部分在老员工脑子里。
系统上线后，用户问了几个问题都答不上来——不是检索不准，是文档里压根没有。用户试两次，得出「这东西没用」的结论，然后再也不来了。
怎么预防：报价之前，让甲方列出二三十个最常问的问题，逐个去文档里找答案。找不到的比例，就是这个项目的真实缺口。 缺口大的话，第一阶段其实是知识梳理，不是系统建设——这件事要在方案里讲明白。
原因三：第一印象毁了
用户对新系统的耐心，通常只有两三次。
上线初期答错几个问题，用户就得出「不准」的结论，然后不再使用。而这个印象一旦形成，后面你再优化也没人知道——因为没人回来试了。
怎么预防：
- 先小范围放，别一上来就全员推。 选一批愿意配合的用户，用真实使用暴露问题。
- 范围划窄一点。 只答有把握的那类问题，答不上来的明确说不知道并转人工。一个「范围窄但准」的系统，比「什么都答但经常错」的可信得多。
- 上线前用真实问题测一轮，别用理想化的样例。
原因四：入口太深
功能再好，用户找不到就等于没有。
我们见过做得不错的系统，入口藏在某个二级菜单里，用户要点三次才能到。而他们原来的做法是直接在群里问一句同事——你的系统必须比这个更方便，否则不会有人用。
怎么预防：把入口放在用户已经在的地方。他们习惯用企微就接企微，习惯用某个业务系统就嵌进去。不要指望用户为了用你的系统而改变习惯。
原因五：没有反馈闭环
系统答错了，用户没地方说，也不知道说了有没有用。
于是错误一直在，用户慢慢流失。而你这边看不到任何信号——后台数据只显示「使用量下降」，不告诉你为什么。
怎么预防：
- 做一个简单的反馈入口，答得不对能一键标记
- 有人定期看这些标记，并且真的去改
- 改了之后让反馈的人知道——这一步最容易省，但它决定了用户还愿不愿意反馈
原因六：没人维护
这是最隐蔽的一个，因为它的后果要几个月后才显现。
制度更新了，知识库里还是旧版；新的业务上线了，系统不知道；模型接口的额度用完了，没人续。
系统在缓慢地失效，而没有人负责。交付时大家都很兴奋，三个月后所有人都忙别的去了。
怎么预防：
- 交付时明确谁负责维护知识库，写进文档，最好写进合同
- 给甲方管理员留一份带截图的操作说明——培训会忘，文档能查。而且真正需要操作时，往往已经过去几个月，来听培训的人可能都换岗了
- 约定一个定期回顾的节奏，哪怕一个季度看一次
还有一个原因：期望被抬得太高
这一条不在前六个里，因为它发生在项目开始之前——销售阶段。
为了拿下项目，方案里把能力描述得很满：「智能问答，让员工再也不用翻文档」「7×24 小时替代人工客服」。甲方领导听了很兴奋，于是项目立项。
然后系统上线，实际能力和描述之间的落差就变成了失望。
而落差往往不是因为系统做得差，是因为一开始就承诺了做不到的事。检索式问答天然不擅长跨文档对比推理、不擅长精确计算、答不了文档里没有的东西——这些边界如果在方案阶段没讲，验收时就会变成「你们做的东西不行」。
怎么预防：
- 方案里同时写「能做什么」和「不能做什么」。 后者才是专业度的体现，也是保护自己。
- 别用「替代人工」这类表述，用「减少重复问题」更准确，也更容易兑现。
- 演示时用真实数据，别用精心挑选的样例。 演示效果和实际效果差太远，是信任崩塌的开始。
一个反直觉的经验：把预期管理好的项目，即使功能一般，用户满意度也可能不错；把预期抬得过高的项目，即使做得很好，也会被认为不达标。
一个能大幅提高存活率的做法
上线后第一个月，主动去看真实对话记录。
你会发现两件事：
一、用户实际问的和甲方当初说的不一样。 这几乎是必然的——甲方给的是他们以为的高频问题，真实数据才是准的。
二、有一批问题的答案根本不在文档里。 这时候拿着数据去找甲方补资料，比空口说容易得多。
这一个月的投入，通常决定了这个项目最后是「用起来了」还是「验收完就没人用」。
验收标准要可测
顺带说一个能避免很多扯皮的做法。
「回答得准不准」没法验收，双方各说各话。可行的做法是提前定一批测试问题——三十到五十个真实业务问题，双方一起确认标准答案，验收时按这批题跑。
好处有三个：验收有客观依据；开发过程中能当回归测试；甲方在整理测试题的过程中，自己会想清楚需求。
同时要提前说明能力边界：跨文档对比推理、精确计算这类问题，检索式问答天然不擅长。写在方案里，别等验收时才解释。
具体方法见知识库项目七成工作量在文档和 FastGPT 部署与交付。
如果需求超出了现成平台的能力，判断标准见低代码 Agent 平台的能力边界。项目上拿不准的可以找我们聊聊。