90%的企业AI项目没有产生效果——落地到底难在哪?

大部分企业搞反了一件事的顺序

最常见的情况是这样的：某个企业的管理层在年初开会时说“今年我们要拥抱AI”，然后IT部门领了任务，开始选模型、搭平台、做PoC。三个月后平台搭好了，演示效果也不错，但真正让业务部门用起来的时候，发现对接不上。

为什么对接不上？因为顺序反了。

正确的顺序应该是：先花足够的时间把业务痛点吃透，搞清楚到底是哪些工作在消耗人的时间和精力，这些工作的流程是什么、规则是什么、判断依据是什么，然后再去想AI在里面怎么切入。但大部分企业是反过来的——先有了AI这把锤子，再满世界找钉子。

我举一个具体的例子。

集团企业每个季度要出一份财务分析报告，这是很多大中型企业都有的刚需。这份报告要把几十甚至几百家子公司的数据汇总起来，做同比分析、预算完成率分析、异动指标识别和归因，最后形成一份可以拿上会的报告。一个有经验的财务分析团队通常要干两到三周。

如果你让一个纯技术团队来做这个项目，他很可能的思路是：用大模型读Excel、生成分析文本、输出Word报告。技术上没问题，但做出来的东西业务部门大概率不会满意。为什么？因为他没有拆解过这份报告到底是怎么“长”出来的。

拆开来看，这份报告的生成至少涉及这么几个不同性质的环节：

数据提取和指标计算——这是纯代码的事，跟大模型没什么关系，用pandas就能做到100%准确。格式排版——这是模板引擎的事，python-docx就够了。异动识别——同比变动超过一定阈值的指标自动标出来，也是代码逻辑。真正需要大模型能力的环节是归因分析和报告撰写——“营收下降了15%，到底是哪个子公司贡献的？是行业因素还是企业自身的问题？”这些分析需要结合数据趋势、历史背景、行业对比来做判断。

但即便是归因分析，也有不同的“确定性等级”。“哪个子公司贡献了最大变动量”——这一层是纯计算，可以做到100%准确。“哪个业务板块导致的”——如果底稿数据有分业务的明细，也能做到准确。但到了“为什么变了”这一层，情况就复杂了：如果有足够的信息来源（历史数据、研报、公告），AI可以给出合理的推断；如果信息不足，那就应该老老实实标注“信息不足，建议线下确认”。

把这些环节拆清楚、把每个环节里“AI做什么、代码做什么、人做什么”想明白，才是AI落地的第一步。但大部分项目跳过了这一步，直接奔着“让AI生成报告”去了，结果可想而知。

这是我观察到的第二个普遍问题，也是我认为很多企业对AI理解最不到位的一个地方。

大部分企业在评估一个AI系统的时候，关注的是“它能不能给我正确的答案”。这当然重要，但还有一个同样重要甚至更重要的问题被忽略了——“当它可能给错答案的时候，它自己知不知道？”

这两个问题的区别很大。前者是“能力”问题，后者是“可信度”问题。一个有时候会犯错但每次犯错都会提醒你的系统，远比一个大部分时候正确但偶尔悄悄出错的系统可靠得多。

拿财务分析来说。AI生成了一段话：“A子公司2025年营收同比下降32%，主要原因是下游需求萎缩叠加原材料价格上涨。”这段话看起来很专业，但问题是——“下游需求萎缩”这个判断是从哪来的？是根据行业研报推断的？还是AI自己“编”的？如果是后者，这段话出现在正式的上会报告里，后果不堪设想。

所以，一个真正可用的企业级AI系统，不能只有“做分析的AI”，还需要有“检查分析的AI”——就像审计和会计不能是同一个人一样。做分析的AI负责生成内容，检查分析的AI负责验证：数字对不对？逻辑通不通？结论有没有信息来源支撑？如果某条结论没有可靠的信息来源，就必须标注出来，告诉使用者“这是AI的推测，不是有据可查的事实”。

我一直有一个观点：敢说“我不知道”的AI，才是值得信任的AI。

但要让AI做到这一点，技术上并不简单。它需要一套完整的质量验证机制——数字层面的勾稽校验、逻辑层面的一致性检查、事实层面的信息溯源。这些机制的设计，又回到了对业务场景的深度理解：你得先知道“这份报告里哪些地方最容易出错、出错的后果是什么”，才能设计出有针对性的验证规则。

纯技术团队做不到这一点，因为他们不知道“什么样的错误在这个业务场景里是致命的”。纯业务团队也做不到，因为他们不知道技术上怎么实现这种验证。这又是一个需要“翻译”的地方。

AI落地是一个业务问题

不是一个技术问题

上一篇文章里我用了一个比喻——大模型像发动机，光有发动机造不出好车。这篇想把这个比喻再展开一点。

今天市场上做大模型的公司很多，DeepSeek、通义千问、智谱、百度文心，国产模型的能力提升速度有目共睹。做AI应用开发的技术团队也不少，能写代码、能调API、能搭Demo的人并不稀缺。

但你仔细看那些落地效果好的案例——不管是上一篇聊的摩根大通，还是国内一些先行者——会发现一个共同特点：项目成功的关键环节，往往不在“模型选了哪个”或者“代码写得好不好”上，而在于前期的业务拆解做得有多深。

摩根大通之所以能把450多个AI用例推到生产环境，不是因为它用了最贵的模型，而是因为它有一个非常清晰的方法论：先识别高价值场景，想清楚AI在这个场景里具体做什么、不做什么，快速验证效果，然后再逐步推广。这个方法论的核心不是技术架构，而是对业务流程的深度理解。

反过来看那些失败的案例，模式也很统一：技术先行、场景模糊、缺少业务侧的深度参与、做出来的东西“技术上没问题但业务上用不起来”。

有时候我会这样跟人解释这件事：你想想看，如果你要给一家医院做AI辅助诊断系统，你会不会找一个完全不懂医学的技术团队来做？大概率不会。你会希望这个团队里至少有人深刻理解医疗场景——知道医生的工作流程是什么、哪些诊断环节耗时最多、哪些错误后果最严重、AI给出的建议医生会怎么看待和使用。

财务分析、投资研判、风险评估、运营管理……这些领域的AI落地逻辑完全一样。模型是通用的，但场景是专属的。谁能把通用的模型能力“翻译”成特定业务场景下的可靠解决方案，谁就掌握了AI落地的真正钥匙。

写在最后

回到开头那组数据——90%的公司投了钱，不到40%看到了回报。

这个gap中间差的不是更好的模型、更多的算力、更大的预算。差的是一种能力：把AI技术和具体业务场景之间的鸿沟填上的能力。

这种能力，需要既懂技术又懂业务的人，需要耐心地拆解每一个工作流程，需要诚实地面对AI能做什么和不能做什么。这些事情不性感，但很关键。

或者换一种说法：AI时代最稀缺的，不是能造发动机的人，而是知道这台车该往哪开的人。