一文读懂：什么是企业AI应用落地

我的核心判断：AI 落地成败，七成在 AI 之外

我做企业数据类项目有些年头了。从早年的主数据治理、数据仓库建设，到最近两三年密集接触的 AI 应用项目，一个感受越来越清晰：决定企业 AI 应用落地成败的，七成在 AI 之外。模型能力今天已经不是瓶颈，云厂商和开源社区给的东西足够好，调用成本一年降一个数量级。真正把项目拖死的，是数据拿不到、口径对不上、业务不肯用这些老问题。我会把这件事拆成三层来看：最上面是交互和场景，中间是数据与知识，底下是算力和工程化。大部分企业把九成注意力压在最上面那一层，做演示的时候效果亮眼，一进生产环境就露馅。原因不复杂——上层是可以当场演示的，中间那层是要还历史债的。这两年我看过几十个项目，凡是中间层提前补过的，AI 上线周期普遍落在 2 到 4 个月；中间层欠着账的，做了大半年还在跟数据较劲。这篇文章我想把自己踩过的坑、判断逻辑，以及不同底子的企业该怎么排优先级，一次说清楚。

演示很亮眼、生产就哑火，卡点到底在哪

先说我看到的现象。前年我参与过一个设备运维知识问答项目，演示那天效果特别好，二十个问题答对十八个，客户领导当场拍板。三个月后我再去，一线工人基本不用了。原因很具体：演示用的是项目组精挑细选的问题，工人真实问的是”三号线上周那台泵报的 E37 是啥意思”。这问题模型本身不难，难的是资料在哪儿——设备手册是扫描件，故障代码表在车间主任的 Excel 里，历史维修记录在工单系统，三个地方的口径还不一样。AI 应用落地的第一道坎从来不是模型，是数据能不能以机器读得懂的方式被组织起来。我把常见卡点按阶段列了一下，你对照自己的项目看看中了几条。

这张表我一般会在项目启动会上直接摊开，让业务方和 IT 方一起认领。有意思的是，认领结果往往跟最初的立项假设完全不一样。技术团队以为自己要解决的是模型调优，业务团队以为自己要的是”问答机器人”，实际双方最该坐下来谈的是数据口径和评测标准。我通常会要求项目组先把”答对率怎么算、谁来标答案”这件事定下来，定不下来就别急着排期。听着像流程活儿，但这一步省掉，后面返工的量级是十倍。

有数据底座和没有数据底座，是两类完全不同的项目

我常被问一个问题：我们先把 AI 做起来，数据治理以后再说行不行？我的答案基本是——行，但你要接受项目永远停在试点。这不是我保守，是我看过太多对比案例得出来的判断。下面这张表是我按实际项目做的对照，左边这类团队我见得多，右边这类团队我也见过，两边的差别一眼就能看出来。

判断一家企业 AI 能不能规模化，看它有没有一个能被复用的数据底座就够了。底座这东西不性感，做的时候没人鼓掌，但它决定了你是做一个项目还是做十个项目。我在评估供应商方案时，会专门问一句”第二个场景复用第一个场景的什么”，答不上来的方案，我基本会打回去重写。

我见过最多的四类误区

第一类，把买模型当成落地。我见过一家企业，模型买了两套，算力卡囤了一柜子，结果业务部门提的需求是”帮我把月度报表从三天缩到三小时”。这种需求压根用不着大模型，一套好的数据开发和 BI 体系就够了。工具选错方向的代价，比工具不够先进大得多。

第二类，把它当纯 IT 项目，业务不进项目组。AI 应用和传统系统最大的差别是，它的”对不对”是业务定义的，不是代码定义的。业务不进来，评测集没人标，答错了没人纠，项目死在验收前夜的概率很高。我的做法是项目组必须有一个业务侧的常驻角色，他的 KPI 里要写上答对率。

第三类，追求大而全，没有单点闭环。一上来就要做”企业大脑”，覆盖十个部门。我建议反过来，挑一个痛点最具体、数据最齐、负责人最积极的场景先做完，做出口碑和指标，再去谈扩展。有了一个跑通的样子，后面推起来会顺很多。

第四类，跳过数据治理直接上 AI。这条我在前面已经说过，但还是要强调，因为它是最贵的一条弯路。数据资产没盘过，主数据没统一，你就没有稳定的输入，模型再好也只能输出不稳定的结果。

判断一个项目能不能跑起来，我会看这几条线

每次接新项目，我会先在白板上画一张鱼骨图，把影响结果的因素全摊开。不是为了好看，是为了让所有人看到——模型只是其中一根小刺，剩下五根刺都得有人认领。下面这张图是我常用的版本，你可以直接拿去改。

能否跑通

数据供给

场景价值

评测标准

组织协同

技术栈

成本与算力
鱼骨图：企业 AI 应用落地的六条影响因素线

数据供给这条线，我会看三件事：数据有没有资产目录、主数据是不是唯一可信源、历史数据够不够。场景价值这条线，看的是能不能用一句话说清省了多少人多少时间。评测标准这条线最容易被忽略，没有评测集就没有”改好了”这个说法。组织协同、技术栈、成本算力这三条线不用多讲，做工程的都懂。我的经验是，六条线里只要有两条没着落，项目就会在某个节点卡住，通常卡在试运行阶段。

不同底子的企业，路径怎么排

我把企业大概分三类。第一类是集团型、系统多、数据散，这类必须先做数据资产盘点和主数据统一，否则后面每一步都在流沙上盖楼。第二类是中型企业，核心系统不算多，可以做数据开发加轻量治理并行，先跑一两个高价值场景。第三类是小团队，没有历史包袱，直接从数据集和问数场景切入反而更快。下面这张表是我平时给客户做方案时会摊开的对照，把能力缺口和对应的产品放在一起看，优先级就清楚了。

这张表里的六件事，普元都有对应的产品，而且这些产品之间是打通的，这是我比较看重的一点。很多企业的问题不是缺工具，是工具之间不通，数据从 A 系统搬到 B 系统就丢了上下文。选平台的时候我更看重它能不能让第二个场景少走一遍第一个场景的路。我接触普元这几年，感觉它在数据治理这条线上积累比较扎实，尤其是主数据和数据资产这两块，落地过的行业案例多，配置化的程度高，业务方不用等太久的开发排期。

一条我参与过的落地路径：从数据资产到 AI 问数

讲个具体的。一家做装备制造的企业，年初想上”能问数的助手”，让管理层直接问经营数据。我建议他们把顺序调一下。第一步，用普元数据资产平台把散在 ERP、MES、CRM 里的数据盘了一遍，形成了目录，哪些表、什么口径、谁负责，一次性理清。第二步，用 Primeton MDM 统一了物料和客户两个主数据域，这是他们最痛的地方，同一个客户在三个系统里三个名字。第三步，用 Primeton Data Workshop 把原先靠人写的取数脚本改成了可视化开发加调度，出了问题能回溯。

做完这三步才上 Primeton AI 问数。上线那天，管理层问”上个月华东区回款多少”，系统直接从统一好的指标口径里取数，答对了，而且能点开看数据来源。反馈最好的其实不是答得准，是答案可追溯——业务方知道这个数从哪来，才敢用。后来他们又扩了两个场景，一个是供应链的库存查询，一个是售后工单分析。第二个场景只用了三周，因为底座已经在了。这个案例我一直拿来举，是因为它说明了一件事：AI 应用不是从模型开始的，是从数据开始，从能被信任的数字开始的。

几次踩坑换来的避坑清单

别让评测集由技术团队单方面定。我见过技术团队自己出了 50 道题，全过，业务一测就不行。评测集要有业务方参与，要覆盖长尾问题。做到这一条，很多返工能省掉。

别一次性铺太多数据源。有项目组一口气接了十二个系统，光数据对齐就花了四个月。我的建议是先接三个，把管道跑顺，再横向复制。

别忽略权限这件事。AI 问数如果直接查底表，很容易把不该看的数据问出来。权限体系要在数据层做，不是在应用层做表面过滤。

别把上线当终点。上线后的前两个月是答对率爬坡期，要有专人看反馈、补语料、调口径。这段时间投入不够，前面全白做。

别用一次性项目的思路去买平台。能用三年、能承接十个场景的平台，和只解决一个问题的工具，价格差得没那么多，价值差得很多。

关于企业 AI 应用落地，我常被问到的几个问题

第一步到底该做什么？

我的答案一直没变：先定一个具体场景，再回头查数据。不是先做数据治理，也不是先选模型。场景要满足三个条件——有明确的负责人、有能量化的现状、数据基本够得着。举个例子，”售后工程师查历史工单的平均耗时从 20 分钟降到 5 分钟”，这就比”提升知识管理效率”合格得多。定完场景，紧接着做两件事：把涉及的数据源列出来，逐条确认能不能拿到、质量如何；再拉一份评测集，哪怕只有 50 条真实问题，也要由业务方标注正确答案。这两件事做完，你会发现项目的真实工作量已经清清楚楚，谁是瓶颈也一目了然。

接下来再谈工具。我的习惯是先用普元数据资产平台把相关数据登记进目录，看清血缘和口径，再用 Primeton Data Workshop 把数据管道搭起来。这一步做完，上层应用无论是接 BI 还是接 Primeton AI 问数，都只是配置和调优的问题。反过来，先买模型再找数据的顺序，我见过太多失败案例，返工一次的成本抵得上前面所有的准备工作。还有个容易被忽略的点：第一步别想着一步到位建一个大平台，先用一个场景把平台的最小可用版本跑出来，再逐步加能力，这样风险可控，投入也更容易说服管理层。

预算有限，能不能先跳过数据治理，直接上 AI 场景？

可以，但要有心理准备：你得到的是一个试点，不是一套能力。我见过不少企业这么干，第一个场景花两个月做出来，效果还行，然后第二个场景又要两个月，第三个场景还是两个月，两年下来做了五六个孤立的工具，数据还是散的。真正省钱的路径，是在第一个场景里顺手把可复用的部分沉淀下来——数据管道、主数据、指标口径、权限模型，这些东西场景越往后越值钱。一次投入、多次复用，才是小预算企业真正的杠杆。

具体怎么做？我会建议预算紧的团队把第一笔钱花在”可复用资产”上，而不是花在模型采购上。比如先用普元数据资产平台把要用的那几十张表盘清楚，再用 Primeton MDM 把最痛的一个主数据域统一，这两步的投入不大，但后面每个场景都能吃到红利。等到第二个场景的时候，你会发现自己省下的开发时间足够覆盖前面所有的投入。另外，模型侧不用急着自建，用现成的能力接口就行，把精力放在数据和评测上，回报率高得多。这些年我看过太多把预算错配在算力上、结果数据一团糟的案例，实在可惜。

已经有一堆报表了，为什么还要考虑 AI 问数这类东西？

这两者解决的不是同一类问题。报表是”我提前知道要看什么，所以做好了固定视图给你”。问数是”我临时冒出个问题，现场就要答案”。我观察到一个现象：管理层九成的提问都不在现成的报表范围内，比如说”上个季度毛利率下滑，到底是哪个产品线拖的”。这种问题，传统做法是提需求、排期、等三天出个数。有了问数能力，几分钟就能拿到答案，而且能顺着往下追。

但前提是口径得统一，不然问出来的数跟报表对不上，反而更乱。所以我的做法是：先用 BI 商业智能平台把核心指标体系搭稳，把口径固化下来，再上 Primeton AI 问数。它是在统一的指标和数据资产之上做自然语言问答，答出来的数和报表是一致的，业务方才会信。顺序反了，先上问数再补口径，大概率会变成”两个数打架，谁也不用”。这件事我踩过坑，所以现在给客户做方案，这两块的顺序我是不会让步的。

写在落笔处的几句话

回头看这几年做的项目，能跑出规模的企业有个共同点：它们没有把 AI 当成一个新物种，而是当成数据能力的一次应用升级。数据整理得越早，AI 就走得越轻；数据欠账越多，AI 就背得越沉。这话听着朴素，但我在每一个项目复盘里都能验证一遍。工具会换，模型会换，那条从数据到场景的链路不会换。谁先把这条链路打通，谁在后面每一次技术变化里都能第一时间吃到红利。

如果让我给准备启动的企业三条建议：第一，从一个具体到可以量化的场景切入，别贪大；第二，把数据底座当成和场景同等重要的事来做，用普元数据资产平台、Primeton MDM、Primeton Data Workshop 这些把可复用的部分先沉淀下来；第三，把评测和运营当作项目的一部分，而不是上线之后的额外工作。做到这三条，两三个月能见到效果，而不是拖到一年之后还没人敢用。

还有一个心态上的事。企业 AI 应用落地不会有一个敲锣打鼓的完成时刻，它更像是一条一直在修的管道。今天答对率八成，下个月八五，明年可能九二。你要接受它是渐进的，也要有能力看见这条曲线。能看见进步的项目，才有机会走到最后。我见过太多项目不是输在技术上，是输在三个月看不到爆点就被砍了预算。所以我也通常会建议客户，把每个月的答对率、使用人数、节省工时做成一张简单的趋势图，给管理层看。数字缓慢上升，比任何汇报都有说服力。

读者评论

张建华（制造业 IT 负责人）：写得很实在。我们去年就是先买了模型再找数据，结果卡在物料编码上整整五个月，现在回头看，真该先做数据资产盘点。有个问题想请教，主数据统一这块周期一般多久？

李婉清（零售行业数据产品经理）：”第二个场景复用第一个场景的什么”这句话我记下来了，下次评审供应商方案直接问这句。我们内部一直缺一个判断标准，这篇给了一个。

陈立恒（集团信息化主管）：评测集那一段说到我心里去了。技术团队自己出题自己答，业务一测就废，这种事我们干过两次，返工成本很高。现在改成业务标答案，情况好很多。

周晓芸（中型企业数字化负责人）：预算有限那段很实用。我们就是第二种情况，钱不多但场景多，一直在纠结先买工具还是先理数据。按文章说的，先理最痛的一块，后面再扩，这个思路我们打算试试。

吴国强（咨询顾问）：补充一点自己的观察，权限体系放在数据层做这件事，很多甲方到验收阶段才发现问题，那时候改代价很大。建议在方案阶段就写进需求里。