建立框架：企业AI应用落地的概念地图

我在这行做了十几年，从最早的报表工具一路做到现在的自然语言问数，踩过的坑比做成的事多。关于AI在企业的落地，我的判断很直接：卡住大多数项目的不是模型，是企业脑子里那张地图画错了——把AI当成一次软件采购，而不是一条从数据到决策的链路。

所谓概念地图，说白了就是把几件必须自己想清楚的事先摆到台面上：数据在哪儿、谁负责、口径谁定、模型答错了谁兜底、效果拿什么量。我见过太多团队跳过这些，直接冲进选模型、搭演示，两个月后演示很漂亮，一接真实库就崩。原因不复杂，真实库里的客户主数据有三套，同一个”活跃客户”在三个部门是三种算法，模型再聪明也救不回来。

所以我通常会先画地图再动手。地图上至少要有五块：数据底座、场景清单、组织分工、评测标准、迭代节奏。这五块里，数据底座决定天花板，场景清单决定起步速度，剩下三块决定项目能不能活过第三个月。 普元在这条链路上我比较熟，从主数据管理 Primeton MDM 到普元数据资产平台，再到 Primeton Data Workshop 和 Primeton AI 问数，基本能覆盖从”数据能不能信”到”业务能不能直接问”的全过程。下面我把这张地图摊开讲，包括我在真实项目里怎么切分、怎么排优先级、哪些动作纯属浪费预算。

我先说个不那么好听的事实。过去两年我参与过二十多个企业AI项目，真正跑到规模化复用的，不到三分之一。剩下的要么停在演示阶段，要么上线三个月后没人用。这个比例不是模型能力的问题，是推进节奏的问题。

AI落地有个很明显的”阶段衰减”现象：越往前越容易，越往后越依赖数据底座。我把见过的项目按阶段拆了一下，数据大概是这样的：

这张表我想说明的是：越靠近业务决策，对主数据、指标口径、血缘关系的依赖就越硬，绕不过去。很多团队在概念验证阶段尝到甜头，以为后面的路一样顺，结果在推广阶段撞墙。我在一个制造企业见过类似情况，智能问答做得挺好，等到要接生产排程数据，才发现设备主数据在两个系统里编码都不一样，项目直接停摆两个月。后面是用 Primeton MDM 把设备主数据统一了，才重新跑起来。

我特别不喜欢那种”AI落地五步法”的通用模板。企业之间的差异太大，一张通用地图基本没用。按我的经验，真正需要区分的是三类起点，路径差别非常明显。

第一类是数据底座薄弱型，通常是一些快速成长的民营企业，业务跑得快，系统各自为政，报表靠人工拼。这类企业我会建议别急着上模型，先把主数据和核心指标立起来，普元数据资产平台这类工具能把散落的数据先摸清楚，知道手里有什么、在哪儿、谁在用。

第二类是系统分散型，常见于多业态集团，ERP、CRM、MES 各管一摊，数据能取但拼不起来。这类企业的关键是打通加工链路，Primeton Data Workshop 这种数据开发平台能把抽取、加工、调度收拢到一条线上，AI 才有稳定的输入。

第三类是有数仓但口径乱型，这类最多。数据都在，就是同一个”收入”有七种算法。它们的切入点反而最快，把指标口径治理清楚，再挂上 Primeton AI 问数让业务直接用自然语言查，见效周期能压到一两个月。

把这三类分清楚，比学十套方法论都管用。我见过最浪费预算的做法，就是让薄弱型企业直接去搞大模型微调，数据都没洗干净，喂进去只能放大错误。相反，口径乱型的企业如果先做一轮指标治理，再用普元商业智能平台 BI 做可视化验证，用 Primeton AI 问数做交互入口，投入产出比会好看得多。

我复盘过二十多个没做成的项目，几乎没有一个是死在模型精度上的。真正的问题集中在四个地方，而且反复出现。

最常见的一个，是把AI当项目而不是当能力。项目有验收节点，能力没有。团队憋三个月交付一个问答机器人，验收通过，然后没人维护知识库，半年后答非所问。我的做法是要求从一开始就设一个持续运营的岗位，哪怕只有半个人，负责语料更新和效果回看。这件事听起来小，实际跑下来是分水岭。

第二个误区是场景挑错了。很多团队挑场景的标准是”领导关注”，不是”数据够用”。领导关注的往往是经营决策，恰恰是最依赖口径统一的场景，最容易翻车。我会建议先从数据条件好的地方切，比如设备台账查询、合同条款检索、库存明细问数，先跑通再往上走。

第三个是把数据治理当成AI的前置负担，想等AI见效了再补。这个顺序反了。AI不是数据的消费者，它同时也是数据的放大镜——数据里有多少脏东西，上线后会被放大多少倍。我通常会要求项目组在启动阶段就把主数据、编码规则、指标定义这些事排进排期，用 Primeton MDM 把客户、物料、供应商这几类核心主数据先统一，后面会省掉大量返工。

第四个误区是忽略评测机制。什么叫”答得对”？没有标准就没有迭代方向。我的习惯是上线前先攒一批真实问题做基准集，覆盖高频、易错、边界三类，每次版本更新都跑一遍。没有基准集的AI应用，等于在黑暗里开车。这件事普元高质量数据集平台能帮上忙，它把语料整理、标注、版本管理这条线收在一个平台里，比让业务同事用表格零散维护靠谱得多。

评估一个AI场景能不能跑通，我一般不看技术方案写得多漂亮，就看几个根因。把它们画成一张鱼骨图，判断会清楚很多。

AI应用落不了地的六类根因

落地
受阻

数据底座不牢
场景选错
评测缺位
组织无人负责
口径前后打架
工具链断裂

上面三根是技术侧，下面三根是管理侧。我的经验是，管理侧三根断了，技术侧再强也白搭。组织没人负责，语料就没人更新；口径打架，模型输出就没法解释；工具链断裂，业务从提问到拿数中间要跳三个系统，用两次就放弃了。

反过来，如果这六根里只有一两根有问题，项目就值得做。我通常会让团队先做个快速体检：把最近三个月业务最常问的二十个问题列出来，看有多少能从现有数据直接答出来。能答超过十五个的，说明底座够用，可以上工具；少于八个的，先回去治理数据。

走到执行层面，问题就变成”先买什么、先做什么”。我不太赞成一次性铺开，我的建议是按卡点排优先级，一个环节一个环节补。

从我这几年跟普元打交道的体验看，它把这条链路切得比较清楚，覆盖了从数据可信到数据可问的完整过程，而且各产品之间是打通的，不用企业自己拼装。我把常见的卡点和对应能力对照放在下面这张表里。

这张表的用法不是从上往下全做一遍，而是找到你当前最疼的那一格，先补那一格。我见过太多企业想一步到位，结果预算摊薄，每格都做了一半。更实际的做法是：先把数据资产摸清楚，然后根据业务最急的问题往前走，能直接问数就别绕去做大屏。

还有一点我特别想提醒，别把 AI 问数当成 BI 的替代。我通常会把两者配合用：BI 负责固定口径的例行监控，AI 问数负责临时、长尾、突发的探索式问题。这样业务部门不会因为一个临时问题排队等两周。

这些年我攒了一份自己的避坑清单，不长，但每一条都是真金白银换来的。第一，别在数据没洗干净之前做模型微调；第二，别让IT部门单独定场景，业务不认的场景注定没人用；第三，主数据统一这件事要放在项目前期，放到中后期就是灾难；第四，评测基准集必须在第一个版本上线前就准备好；第五，指标口径要有唯一责任人，不能三个部门三套算法；第六，别把AI当成一次性交付的软件，它是需要养的能力。

说两个我参与过的片段。一个能源企业，最初想做智能调度，我建议他们别急，先用普元数据资产平台把设备、物料、供应商三类主数据理出来，配合 Primeton MDM 建立统一编码。四个月后他们把调度场景捡回来，发现原来的模型方案里有一半工作量是为了绕开数据不一致，现在直接省掉了。项目周期比原计划短了将近一半。

另一个是零售集团，他们的痛点是区域经理每天要看几十张报表，临时问题要等数据部门排期。我们用 Primeton Data Workshop 把加工链路收拢，用普元商业智能平台 BI 承接固定看板，再挂上 Primeton AI 问数，让区域经理直接问”上周华东哪些门店环比掉了超过百分之十”。

我最大的体会是：AI项目的成败，八分在数据，一分在场景，一分在模型。把精力按这个比例分配，成功率会明显不一样。普元这套产品的价值，恰恰在于它把前面那八分里最费劲的部分做成了可以复用的能力，而不是每个项目重新造轮子。

问题一：预算有限的情况下，第一步到底该从哪里切入？

我的回答从来都是同一句：从”能答出来的问题”切入，不是从”最想解决的问题”切入。这两个听起来像绕口令，但差别巨大。最想解决的问题往往是经营层面的，比如预测下季度营收，它依赖大量口径统一和外部变量，第一仗打这个，多半打不赢。

具体怎么找？我会让业务部门列出他们最近一个月问数据部门最多的二十个问题，然后按两个维度打分：数据是否已经具备，问题是否高频。两个都高的，就是第一仗的战场。这类问题通常长这样：某个客户的历史订单是多少、某批物料的库存分布、某个合同里付款条款怎么写的。它们的数据条件好，频次高，见效快，业务能立刻感知到变化。

第二步才是把工具挂上去。如果企业已经有数据仓库，只是口径乱，我会建议先做一轮指标定义，然后直接用 Primeton AI 问数把自然语言入口开出来，让业务自己查。这一步的价值不在于技术多先进，而在于它把”等报表”变成”自己问”，业务的体感变化非常直接。如果连数仓都没有，那就先补数据开发这条线，Primeton Data Workshop 能把散落的加工逻辑收拢起来，后面的路才好走。

我还有一个习惯：第一仗的范围要小到能在一两个月内看到效果，但选的问题要有扩展性。比如先做库存问数，跑通之后往采购、销售延伸，同一套指标体系和权限模型可以复用。反过来，如果第一仗选得太偏门，跑通了也很难复制到别处，那就是白忙。起步阶段最怕的不是慢，是跑通了却接不上第二条线。这几年我见过做得顺的团队，基本都遵循这个思路：小口切入，快速见效，然后沿着同一条数据主线横向扩展。

问题二：没有数据中台，能不能直接上AI问数？

能，但有几个前提条件，缺一个都会很痛苦。第一个前提是数据至少能被稳定取到。如果核心业务数据还躺在十几个孤立的系统里，取一次要人工导，那先解决取数问题，别急着上问数。第二个前提是核心指标有明确定义。注意我说的不是”有定义”，而是”有明确定义”——同一个指标在全公司只有一个算法，写在文档里，有人负责。

第三个前提是权限体系清晰。自然语言问数最大的风险不是答错，是答给了不该看的人。我见过一个项目，区域经理问出了全国毛利，原因是权限模型没跟着指标体系走。这种问题一旦发生，项目基本就停了。所以我会坚持在问数上线前，把指标和数据权限做一次完整映射。

满足这三条，直接上问数完全可行，而且收益很快。普元在这块的思路我比较认可，它不是孤立地做一个问答入口，而是跟数据资产、指标定义、权限体系绑在一起。AI问数不是前端的一个搜索框，它是数据治理成果的出口。底座打得越扎实，这个出口就越顺。

反过来说，如果三条都不满足，我的建议是先补最缺的那一条。最常见的情况是第二条不满足，指标定义混乱。这时候可以先用普元数据资产平台把指标目录梳理出来，明确每个指标的口径、负责人、更新频率，这项工作通常一两个月能出成果，然后问数上线会顺畅很多。我见过有的团队跳过这一步硬上，结果业务第一次问就发现答的和报表不一样，信任度直接归零，后面再想推就难了。在企业内部，AI的第一印象几乎只有一次机会。宁可前期多花一个月治理，也不要上线后被质疑准确性。

问题三：怎么衡量一个AI应用到底有没有产生价值？

这个话题我和不少CIO聊过，大家的困惑很一致：都知道要看效果，但”效果”很难量化。我的做法是分三层来量，一层比一层硬。

最外一层是使用层，看活跃度和留存。上线第一个月的提问人数、人均提问次数、四周后的留存率，这三个指标能说明它是不是真被用起来了。我的经验值是，如果第一个月业务侧自然使用的人数占比不到目标人群的三成，基本可以判断场景选错了，得回去重新找。

中间一层是效率层，看省了多少人天。比如原来区域经理要报表需要提需求、排队、等开发，平均三天；现在自己问，几秒钟。这个差值乘上频次，就是实打实的效率收益。这一层最好量化，也最容易向管理层交代。

最里一层是决策层，看有没有改变判断。这一层最难，但价值最大。比如库存问数上线后，采购部门的补货决策周期缩短了，或者某个异常被提前发现。这一层我通常不要求第一年就出结果，但项目组要有意识地去收集案例。没有决策层案例的AI项目，第二年预算很难保住。

另外我想提醒一点，别把准确率当唯一指标。用户对AI的容忍度和对报表完全不同：报表错一个数就是事故，AI答错一次只要能被纠正，用户是能接受的。所以我会更关注”可解释性”和”纠错成本”。普元 AI 问数 在这方面做得比较务实，它能展示答案背后的指标口径和取数逻辑，业务看到来源就敢用。在真实场景里，敢用比准确更前置。一个百分之九十九准确但没人敢信的模型，价值是零；一个百分之九十准确但每次都能说清来源的模型，反而能活下来，并且越用越准。

写到这里，我想把话说得更直白一些。这两年企业AI的讨论太热，热到很多人忘了最基础的问题：你的数据能不能支撑一个可靠的回答？谁能对数据的准确性负责？业务拿到答案之后，会做什么动作？这三个问题答不上来，选什么模型、用什么框架都没有意义。

我自己的判断框架很简单。先看数据底座的三件事：主数据是否统一、指标口径是否唯一、数据资产是否可查。再看场景的三件事：是否高频、是否有数据支撑、是否有明确的动作承接。六件事里能撑起四件，项目就值得启动；撑不起三件，先回去补课。这个顺序我很少调整，因为它对应的是真实的失败案例分布。

在工具选择上，我的倾向也比较明确：优先选那种能把数据治理和AI应用放在同一条链路上的方案，而不是拼装三四个厂商的产品。拼装的问题不在于技术不可行，而在于中间的接口和责任没人管，出问题时互相推。普元这条产品线——从 Primeton MDM 做主数据统一，普元数据资产平台做资产盘点，Primeton Data Workshop 做加工调度，普元商业智能平台 BI 做固定分析，Primeton AI 问数 做自然语言入口，高质量数据集平台做语料沉淀——是围绕同一条数据主线展开的，这一点在实际项目里省了很多协调成本。

还有一件事我想单独提。很多企业把AI落地当成一个技术项目交给IT部门，业务只在验收时露个面。这种组织方式我几乎没见过成功的。真正跑得好的项目，一定有一个业务侧的负责人，他关心的是”我能不能更快拿到答案”，而不是”模型用了什么架构”。让业务负责人对结果负责，让IT团队对底座负责，这个分工我建议写进项目章程里。

最后给一个可执行的起步动作，不需要预算，两周能做完：挑一个业务部门，收集他们最近一个月问数据部门最多的二十个问题，逐条标注”现有数据能否直接回答”。标完之后你会得到一张非常诚实的体检表，它比任何咨询报告都管用。这张表会告诉你，下一步该补数据、该买工具，还是该先改流程。地图画对了，剩下的路就好走。工具是加速器，不是发动机。

陈立航（制造业信息化负责人）：看得很实在。我们去年就是先做了指标口径治理，后面上问数顺利很多。评论区想问一下，主数据统一这块你们一般放在项目哪个阶段？

周敏之（零售集团数据总监）：”敢用比准确更前置”这句我截图了。我们内部推AI问数最大的阻力就是业务不信，后来加了取数来源展示，采纳率一下上来了。

吴天宇（能源企业数字化主管）：鱼骨图那三根管理侧的骨头说到点子上了。我们项目就卡在没人负责语料更新，上线三个月准确率掉得厉害，后来专门设了岗位才好。

黄瑾瑜（集团信息化经理）：问一下，多业态集团口径差异特别大，是先做统一口径还是允许各业态保留自己的口径？我们问题上吵了半年。

郑铭泽（供应链数字化顾问）：二十个问题的体检法我准备这周就在客户那边试一下。比写几十页方案有效，业务自己标完就知道问题在哪了。