我在过去几年里接过不少企业AI项目有给制造业做的质检模型有给金融客户做的智能文档处理也有给零售企业做的需求预测。几乎每个项目都经历过同一个尴尬周期汇报演示的时候全场眼睛发亮领导拍板说好业务部门也点头认可结果真正部署上线两三个月再去问使用量惨不忍睹有些功能甚至上线当天就再也没有人打开过。“演示很好上线没人用”——这句话我听得太多了自己也踩过不少坑。后来我慢慢想明白一件事演示和上线本质上就是两个物种。演示是在一个你能完全控制的环境里证明可能性而上线是在一个充满脏数据、复杂流程、人情世故的真实环境里接受检验。这篇文章不聊大道理就想用我经手的真实项目和踩过的坑拆一拆“演示好看但没人用”到底卡在哪几个环节以及怎样从第一天就把项目往“有人用”的方向推。先说个大概结论后面细拆绝大多数企业AI项目死在三个地方——数据条件不真实、需求理解错位、上线后没有运营。这三个问题在演示阶段几乎全部被掩盖了等上线才暴露已经没有时间给你补救。如果你正准备启动一个企业AI项目或者你已经被“上线没人用”的问题折磨过这篇文章应该能帮你少走一段弯路。1. 先泼一盆冷水演示和上线是两个物种1.1 演示现场的“完美滤镜”是怎么搭起来的我做过一次印象很深的汇报。客户是一个区域连锁零售商想用AI做销售预测。演示当天我准备了一套非常干净的三个月历史销售数据没有缺货断档没有大促异常没有门店手工调账甚至天气异常那几天的数据我都提前“温和处理”了。模型跑出来的预测曲线几乎贴着真实值MAPE平均绝对百分比误差做到6%出头客户运营总监当场就说这比他们人工预测准太多了。后来项目上线第一周真实数据灌进去MAPE直接跳到27%。为什么因为真实业务里门店促销改价是常态总部下发的商品主数据经常和实际门店对不上一些老店的历史销售里还混杂着盘亏、报废、团购冲单数据口径乱七八糟。演示时我用的是一份专门清洗过的黄金样本而上线时模型面对的是每天都在变的原始生产数据。这不是我一个人的问题。很多企业AI项目从立项开始就是“为了演示而演示”样本数据精心挑测试场景反复调连演示界面都是前端单独写的数据量小、响应快、还专门做了漂亮的图表。演示环境的本质是一个无菌实验室而生产环境是充满各种病菌的菜市场。你在无菌实验室里培养出的模型拿到菜市场里能不能活下来取决于你对真实环境的理解有多少而不是你的算法有多先进。1.2 业务方想解决的事和技术方演示的事常常不是同一件事另一个经常被忽视的错位是业务方嘴上说“我们要AI”但心里想的其实是“我们要省人、省时间、少背锅”。技术方理解成“我们要做一个高大上的智能系统”。有个做合同审核的项目特别典型。我们团队花了很多精力做一个漂亮的端到端演示合同PDF上传后系统自动抽取出甲方、乙方、金额、期限、违约责任合规风险点标红还生成一段审核摘要。演示效果非常惊艳客户法务总监连连点头。结果上线后法务部的人用了一周就弃用了。后来回访才发现法务同学根本不需要系统帮他们抽取信息他们需要的是系统理解每条合同条款对应的业务风险并直接告诉他们这条款能不能签能签的话要加什么保护性条款。抽取字段只是手段判断风险才是目的而我们拿一个“手段”去当“交付物”。这类错位很常见。业务方描述需求时往往会顺着技术方的话往下说因为领导在场、供应商在场谁都不想把场面搞尴尬。但真到用的时候业务人员是按自己的日常工作流来判断这个东西值不值得用的。如果AI做的事情没有嵌进他现有流程的关键节点上没有帮他省掉最烦的那一步他打开两次也就不想再打开了。2. 根因拆解为什么“看着好用”会变成“没人用”2.1 数据条件差的不是一个量级前面已经聊到数据的问题但这里我想往深挖一层企业AI项目上线后的数据条件和演示时的数据条件差的通常不是一个量级而是几个维度。第一个维度是完整性。演示时你通常能拿到想用的字段可生产环境里的业务系统经常是十年前的旧系统连数据库表结构都不一定有文档。缺表、缺字段、缺历史数据是家常便饭你想建模的那张业务表可能三个月前才有人开始维护。第二个维度是时效性。很多企业AI场景依赖的是近实时数据比如风控、反欺诈、库存调度。演示时是离线跑批数据晚几个小时无所谓上线后要是实时接口不稳定特征算不出来模型就直接罢工。我见过一个制造业的质量预测项目传感器数据通过工业网关采集演示时是录好的历史文件稳稳当当。上线后现场网络抖动网关消息堆积消息中间件处理不过来模型输入的特征缺失系统干脆静默降级给出一堆质量预测均值产线工人看了一眼觉得完全是乱猜再也不看了。第三个维度是口径一致性。演示时数据口径你自己定上线后你会发现不同部门对同一个指标的理解完全不一样。销售部门提的“销售额”是含税实收财务部门理解的“销售额”是不含税开票收入模型训练时糊里糊涂都用上线预测结果自然没人认账。所以我会建议所有做企业AI项目的朋友在立项后第一周就去做一次真实数据的可用性审计哪些表能访问、更新频率是多少、字段缺失比例有多高、各系统之间口径是否一致。这个动作哪怕只是拍脑袋评估也会让你对整个项目的风险认知清晰很多。演示做得漂不漂亮是次要的数据底座扎不扎实才是决定生死的事。2.2 用户要的不是AI是省事做企业AI项目最容易钻进的一个牛角尖是——拼命优化算法的准确率却忽略了用户使用AI额外付出的认知成本。去年做一个客服知识库智能问答机器人我们团队把模型换了一版又一版意图识别准确率从83%打到94%。但上线后一线客服的使用率只有不到20%。后来拉了几个客服聊原因特别扎心客服接到电话时他们需要在系统里切换到问答机器人窗口手打关键词搜索然后阅读三条类似答案再自己判断整个流程比直接查内部Wiki还慢。有几个客服说得很直接我又不是不会搜你们这个机器人给出的答案我还得再核一遍凭什么多花这个时间这就是典型的“技术自嗨”。我们以为给用户提供了准确率很高的AI但在用户视角里引入AI后他的操作流程变长了而且他还要额外花时间去验证AI的答案。一个人每天的工作时间是有限的如果你的AI让他在单位处理量不降反升他就算嘴上说好身体也会很诚实。真正被高频使用的企业AI几乎都遵循“省事原则”不改变用户原有操作路径AI在后端默默辅助。就算要改变也必须让用户在第一次使用时就明显感到“省了一步”。宁可准确率暂时低一点也不要在界面上让用户做太多选择题。一套好的企业AI产品应该是用户感知很轻、后台工作很重。感知太重用户就会退回老路上去。2.3 没有治理和反馈闭环的上线就是一次性演示我还想强调一个容易被忽略的坑企业AI项目上线后模型效果不是一条水平线而是会慢慢衰减的。业务规则在变数据分布在变用户行为在变几个月前还表现良好的模型几个月后可能已经悄悄变得不准了。我们做过一个供应链的需求预测项目刚上线时预测精度不错采购部门确实用了一阵子。但第三个月的时候动态定价策略调了一版促销频率大幅增加销售数据形态变了模型没有来得及重新训练预测结果开始持续偏离。偏偏当时没有建立效果监控告警没人发现模型已经悄悄“变笨”了。采购同学对比了几次自己的判断和系统预测发现系统越来越不靠谱就默默回到Excel表格手工拍数的老路连提都不提这事。很多项目上线即死亡不是死在技术能力而是死在没人为它持续负责。企业AI项目从演示到上线必须像做互联网产品一样建监控、埋点、反馈、迭代。没有这套闭环AI系统就会像一个没人上油、没人保养的机器迟早卡死。3. 实操方法怎么把演示变成真正能用的产品3.1 选切口从高频、低风险、可量化的小场景开始我在内部带项目时经常强调一句话第一次上线宁小勿大。企业AI项目一上来就想做“全流程智能化平台”的基本都会死在半路上。不是因为技术实现不了而是因为涉及的角色太多、流程太长、风险面太大任何一个环节出问题都会影响整体推进。正确的做法是选一个高频、低风险、可量化的具体场景先打透。什么叫高频就是这个场景每天都会发生用户重复操作频率高省下来的时间是可感知的。什么叫低风险就是AI即使犯错了后果也可控不会直接导致业务事故。夫妻老婆店和银行核心系统对AI错误的容忍度完全不同你选场景时心里要有数。什么叫可量化就是业务价值能算成钱或者算成时间比如“每周报表制作时间从8小时降到30分钟”“询价单录入的字段错误率从15%降到3%”。我第一次带团队做RPAAI的发票录入项目就是因为选错了切口差点翻车。本来想做一个全流程应付账款自动化从发票接收、识别、验真到入账全部自动化。做了三个月发现发票验真环节涉及和税务系统的对接、多种发票版式兼容、异常发票的人工介入处理复杂度远超预期演示倒是好看但上线后的稳定性根本撑不住。后来我们把切口缩小到“只处理单一供应商的标准增值税发票录入”场景明确规则清晰效果稳了以后才逐步推广。所以不要怕场景小“小切口”才是企业AI项目少踩坑的核心策略。场景小意味着业务方容易配合、数据容易对齐、效果容易评估。有了第一个真实成功案例再向其他场景复制阻力会比直接推大平台小得多。3.2 演示前先做一轮“脏数据压力测试”很多团队做演示是用自己准备好的数据去验证模型的“能力上限”这其实方向就反了。正确做法是用真实生产数据的原始样本去测试模型的“能力下限”。我后来负责的每个项目在做正式汇报前都会要求团队完成一次“脏数据压力测试”。具体做法不复杂找业务方拿最近三个月的真实原始数据不要清洗、不要过滤、不要贴标签。直接把这些数据丢进模型里跑一遍记录模型报错、特征缺失、结果异常的比例。然后系统地观察模型在哪些样本上崩了崩的原因是数据缺失、格式异常、还是逻辑冲突针对崩掉的样本类型反推这只会在真实业务中出现多少比例评估是否在业务方可接受的范围内。这个测试最大的价值不是把模型调到完美而是帮你提前知道模型在真实环境里的“丑态”。你带着这种丑态和业务方沟通的时候会有两个好处一是你不会盲目承诺业务预期不会被拉得太高二是能提前讨论清楚哪些地方不能自动化哪些地方需要人工兜底上线后不会因为“AI没做到你们演示那版的效果”而被投诉。我自己有个惨痛教训一个文档分类项目演示时给的样本都是干净清晰的PDF或者Word识别准确率非常好。上线前我没有做脏数据压力测试结果真实环境里有大量模糊扫描件、手机拍照件、带水印和手写批注的图片这些样本直接让分类准确率掉了20多个百分点上线计划被迫推迟了一个半月。后来我们花了整整三周的时间在数据预处理管线上才把性能拉回来。如果在演示前就做过压力测试这些时间完全可以前置也不至于上线前那么狼狈。3.3 把演示对象从领导换成真实用户这条经验虽然听起来反直觉却是我认为最值得分享的一条。一般企业AI项目的汇报对象都是管理层你要给他们一个“预算继续批”的理由所以演示通常做得越宏大、越吓人越好。但如果你全程只在管理层面演示你根本不知道真实用户到底怎么想。管理者关心的问题和一线用户关心的问题是完全错位的——管理者想知道投入产出比和战略价值而一线用户想知道这东西能不能让我少加一次班、少背一次锅。我的建议是在正式汇报之前先约几个真实用户做一轮“最小可行性体验测试”。不用做得太精致原型也好、半成品也好让用户在真实任务里用一用然后让他们吐槽。有一次我们做库存异常预警系统内部觉得界面设计得挺好看图表丰富信息全面。结果约了仓库主管来体验他看了一眼就皱眉你们这东西好是好但我仓库一天到晚都在拣货发货哪里有功夫坐下来盯屏幕看预警我需要的是异常出现时直接弹一条消息到我手机告诉我哪个库位、哪个SKU、数量差多少现在应该怎么处理。后来我们整套交互逻辑都改了系统默默在后台算出问题推一条短信或者企业微信消息用户反馈“这才是有用的东西”。所以一定要记住你服务的不是领导的期望而是一线用户的时间。把演示对象换成真实用户虽然他们的反馈会让你难受但难受完你会发现项目的方向一下子清晰了。3.4 把AI嵌进用户已有的工作流里还有一点特别想强调企业AI要“上线有人用”关键不是做一个独立的智能系统而是把AI能力嵌入用户已经在用的工具和工作流里。用户不会因为一个工具“智能”就去用而是会在自己熟悉的环境里顺手用掉它。举个例子同样是做合同信息抽取做一个独立的网页应用让大家上传合同、查看抽取结果用户的使用成本是很高的但如果你直接用OCR和NLP能力做一个插件放进他们平时使用的OA系统或者企业微信里用户在审批流程里顺手就能看到AI抽取的关键摘要根本不需要切换系统使用率一定高得多。我在项目里经常向团队传递一个原则AI不要做个新工具要做一个看不见的助手。最好的形态是让用户感觉自己的活儿变少了但又说不清楚到底哪里变了。要做到这一点就需要在动手之前先画出用户当前的“工作流程图”找到最费时费力的环节再考虑怎么把AI插进去。而不是先想好一个AI功能再强行塞给用户。4. 上线后如何避免“二次弃用”4.1 上线不是终点运营才是起点很多企业团队做AI项目默认上线就是交差。系统部署完了验收测试过了发票开了项目组就解散了。这种做法在“演示好看”的阶段就埋下了“上线没人用”的种子。企业AI项目上线后其实需要一段至少一两个月的“陪伴期”。这段时期项目团队要做的不是开发新功能而是回答用户的真实使用问题、观察用户的真实行为、收集使用门槛高在哪、特意去抠那些用户“用了但不顺手”的细节。我记得有个项目上线AI辅助写周报的功能我们觉得这个功能不复杂用户把做的事情一填AI直接扩写应该没什么学习成本。结果上线后连续几天使用量都很低。后来一问发现Hit是用户找不到功能入口——产品团队把“AI写周报”的按钮埋得比较深用户打开周报模板根本不知道能点哪里。就这么一个小问题不通过运营陪伴期的用户访谈你很难靠自己发现。我们赶紧做了一次入口优化把按钮直接放到了周报页面的最显眼位置第二周使用率翻了三倍。所以上线后的运营动作绝不是可做可不做的锦上添花而是决定项目生死的关键工作。一个AI项目如果没有配置专门的运营或者产品经理角色去盯用户反馈它的生命力通常不会超过三个月。4.2 用埋点数据说话别靠感觉另外判断一个AI功能到底有没有人用不能靠汇报PPT上“试用用户数”这类虚荣指标要靠行为埋点。每次发版前我会和团队约定三组核心指标第一组是使用深度比如每天有多少用户使用了AI功能、人均触发次数是多少、功能在不同部门间的渗透率怎么样。第二组是转化成功率用户发起一次AI请求到拿到结果并采纳结果这中间的完成和放弃比例是多少。第三组是业务效果指标比如使用了AI的工单处理时长相比没有使用AI的工单处理时长是否缩短、单位处理量有没有提升、错误率有没有下降。埋点数据能帮你回答非常具体的问题比如“到底是没人用还是用了但没解决需求”“到底是功能入口藏得太深还是AI结果根本没有命中用户的预期”。如果发现AI结果点了“采纳”的比例很低那就不是运营问题而是模型能力问题你需要回头去看训练数据是不是太干净了。如果发现入口点击率很高但生成结果很少被采纳那就要去看是不是用户输入的门槛太高或者AI生成的内容永远带有一股AI味让人不放心直接用。有个客服智能问答项目最初埋点只统计了“调用量”看起来每周都在涨团队还挺高兴。后来把埋点细化到“调用后是否复制了回答发送给客户”才发现复制率低得可怜。也就是说客服同学打开了问答助手但输出的答案不符合他们的表达习惯他们宁愿自己重打一遍。如果没埋点这个问题可能要一直到项目整体复盘才发现。4.3 建立一条快速反馈和迭代的通道上线后的AI项目最怕的就是“告状无门”。用户发现模型预测得不准、页面用起来卡顿、某类新样本识别不了却没有一个便捷的反馈渠道那他最自然的反应就是不用了而不是帮你把问题提出来。我建议每个项目上线时都建一个最低成本的反馈闭环企业内部微信群也好、工单系统也好、产品内的“反馈”按钮也好关键是让用户知道“说了有人听而且改得快”。有一次我们做了一个销售预测的调整功能用户可以手动修改系统预测值希望把人工经验也融入模型。上线后用户每天都会改十几条预测但系统没有做“人工修正回流”的机制修改完就完了模型下次还是按老逻辑预测。用户改了两个星期发现系统完全没有变聪明积极性一下就被打击没了。后来我们快速加了一个机制把用户的人工修正数据定期回流到训练集里定期重新微调模型让用户感觉到“我每次的修正系统真的记住了”。这个功能上线两轮之后使用深度发生了肉眼可见的增长。企业AI项目的迭代速度不需要像互联网产品那样快但至少要有一个“按周迭代”的节奏感。用户提出一个合理的小问题你最快下周就改了。用户发现提了意见有回应他才愿意继续用下去、继续帮你发现问题。这比你把模型精度再往上提一个百分点要重要得多。5. 我踩过的坑和最后想说的话5.1 现场复盘三个项目的真实教训说了这么多方法论最后分享几个我印象最深的现场复盘每一个都是花钱买来的教训。第一个项目是做供应链需求预测的。刚才提到的动态定价策略变化导致模型预测失准其实根源上是需求方和算法团队之间没有建立“业务规则变更通知”机制。业务策略更新了但算法团队完全不知道模型还在用旧逻辑学新的数据当然越跑越偏。后来我们和业务方约定任何影响销售数据分布的活动必须在系统里提前登记模型再根据规则做切换或者重新训练。企业AI项目里业务规则变更和技术系统之间要有“握手协议”这件事比调参重要得多。第二个项目是做合同审核的。我们最初花了大量时间优化法务条款的风险标注模型能识别出几十种风险点。但真正上线后法务用户告诉我标注太多等于没有标注他们打开界面看见满篇密密麻麻的红标根本不知道先看哪个。后来我们换了一个策略模型只输出“这个条款能不能签”一句话然后提供“建议理由”和“参考条款”其他信息统统折叠。用户反馈反而大幅改善。这说明在复杂业务场景里AI需要勇敢去做决策哪怕决策有时候不够周全也比罗列一堆信息让用户自己决策更有价值。第三个项目是做客服知识库问答的。最开始的版本直接让用户输入问题AI返回答案。后来回访发现用户真正高频的操作其实是“找一个特定单据的处理方法”而这类问题在知识库里有标准文档可以查。我们后来把产品改造成“先分类问题类型再引导用户一步步找到解决方案”变成了一个智能助手流程导航而不是一个“问答机器人”。使用率提升非常明显。有时候AI项目没人用不是AI不够强而是你把问题定义错了。5.2 如果只记住一件事让AI承担“脏活累活”总结这么多我想说如果只让你记住一个中心思想我希望是这句企业AI项目的目标不是展示AI有多酷而是让AI去承担人类不想干的脏活累活。一线用户不会为了“智能”买单只会为了“省事”买单。演示好看固然重要但那是获得预算的门票真正决定项目成败的是用户在使用产品那一刻的真实体感。我见过太多团队把80%的精力花在模型准确率上、把20%的精力花在系统集成和用户体验上但真实世界的反馈恰恰相反系统集成和用户体验的权重应该超过模型算法。模型精度从90%提到95%可能需要三个月但把功能入口从二级页面移到首页、把操作步骤从八步压缩到三步可能只需要一周而带来的使用率提升可能远超那5%的准确率提升。最后分享一个小技巧如果你现在正准备做演示试着把PPT里那些“智能”“赋能”“全流程自动化”的词去掉换成用户每天都会说的“少输入一遍”“自动汇总”“出错直接提醒”然后看看你的方案是不是还成立。如果去掉这些词以后你的方案就站不脚说明你要么是在自嗨要么还没真正理解用户要什么。想清楚这个问题再动手项目上线的命运就会很不一样。