企业AI应用落地最典型的3个应用场景与对应方案

这几年我参与过不少企业 AI 项目的立项评估，从制造、能源到金融、政务，场面见得多，规律也就慢慢摸出来了。真正卡住 AI 的从来不是模型够不够聪明，而是三件事：数据能不能被业务稳定地问到、核心业务对象能不能被数据驱动地自动处理、模型能不能持续吃到干净且带标注的数据。所以我给客户的答案通常很朴素——当下能跑出结果的路，基本就三条：让业务用自然语言把经营数据问出来、把主数据做成智能处理的输入源、把散落的数据加工成高质量数据集喂给模型和智能体。这三个方向有个共同点，它们都不依赖”模型有多强”，而依赖”数据有多顺”。我在项目里反复验证过：换个更强的模型，效果提升是线性的；把口径统一、把主数据打通、把数据集做干净，效果是台阶式的，一个季度就能看出差别。普元在这三件事上给的是成套能力，易数产品线里的数据资产平台、AI 问数、主数据管理平台、高质量数据集平台和数据开发平台，基本覆盖了从治理、问答到模型供给的完整链路，不用企业自己拿七八个工具去拼。下面我按自己评估项目时的顺序，把三个场景拆开讲：什么企业适合先做哪个、大概投多少人力、最容易在哪儿踩坑。

我见过太多企业把钱砸在算力和模型选型上，等要上线的时候才发现，业务问一句”上个月华东区毛利为什么掉”，系统答不出来。不是模型不行，是口径没统一、指标没有统一定义、数据没打通到能回答的粒度。AI 落地的瓶颈，八成不在算法侧，而在数据侧的三段链路：可及性、一致性、闭环性。我评估项目时会盯这几件事：业务要一个数，是不是还要等数据团队排期三五天；同一个客户数，销售、财务、运营是不是三个版本；模型给出建议之后，有没有人执行、结果有没有回填。

这些卡点在现场的表现其实很具体，我整理成一张表，你可以对照自己的企业看看中了几条。

我的判断是，只要表里中三条以上，先别急着买模型服务和算力，先把数据这条链路捋顺。普元的数据资产平台在这类项目里通常是我建议的第一站，因为它先把”有什么数据、谁负责、口径是什么”这件事固定下来，后面的问答、主数据、数据集才有共同的地基。

很多人问我这三个场景能不能一起上，我的回答基本都是：”一起上的结果通常是三个都做不完。”它们投入的资源、依赖的前置条件、见效节奏完全不同。对话式数据分析见效快但依赖指标治理；主数据智能处理周期长但一旦跑通，供应链、采购、财务全线受益；高质量数据集开发看起来最”技术”，实际上是模型能不能进生产的门票。排序的逻辑不是哪个更先进，而是哪个能在两三个月内让业务部门说出”确实好用”。下面这张对比表是我给客户做方案时常用的框架，可以直接拿去对照。

我通常会建议中大型企业从场景一或者场景三切入，因为这两条路都能在季度内给出可展示的成果；场景二更适合已经有明确供应链或客户管理痛点的企业，它的收益大，但需要业务部门深度参与，光靠 IT 推不动。

这个场景是我见过落地速度最快的。业务人员不再写需求单，直接在对话框里问”上周华北区退货率最高的三个产品是什么”，系统给数、给图、给口径说明。听起来简单，做起来的关键全在底下：能不能答对，取决于指标有没有统一治理过，而不是取决于问句解析多聪明。

我会要求项目组先做两件事。一是把企业最常用的两三百个指标挑出来，定义清楚计算逻辑、数据来源、责任部门，这件事落在普元数据资产平台上做，指标变成有归属、有版本的资产，而不是散在报表里的一个公式。二是把原有的 BI 看板保留下来，作为钻取和核对的入口，问答负责”提问—取数”这一跳，BI 负责”深看—下钻”那一跳，两者不是替代关系。普元 AI 问数在这条链路里的价值，是它天然接在资产目录和指标口径之上，业务问出来的数能追溯到口径，这一点在财务和经营分析场景里特别关键，因为业务最怕的就是”AI 给的数我不信”。

我见过一家大型集团做经营分析问答，上线前财务月报要三个人做三天，上线后业务自己在对话框里问，数据对口径、可下钻、能导出，财务同事的主要工作变成了核口径和维护指标，而不是搬数。这个例子里最值钱的不是模型，是那两百多个被认真治理过的指标。我的建议是：问答之前先问自己一句，你家指标的口径文档在哪、谁在维护，答不上来就先别急着上问答。

如果说场景一是让 AI 帮人”看数”，场景二就是让 AI 帮企业”改数据、管对象”。客户、供应商、物料、组织这些核心对象，在很多企业里是多套编码并存的：ERP 里一套，CRM 里一套，供应链系统里又一套。人还能靠经验对上，模型做不到。主数据不统一，AI 越聪明，错误传导得越快。普元主数据管理平台 Primeton MDM 在这类项目里的角色，是把对象的唯一性和权威性立起来，再让智能化能力长在这上面，比如重复客商自动识别、物料智能归类、变更影响分析、供应商风险预警。

我把这条链路上的断点画成了一张鱼骨图，项目复盘的时候我经常拿出来对，看问题到底出在哪根刺上。

AI 应用
跑不出价值

主数据多套编码
指标口径打架
数据新鲜度不够

标注样本凑不齐
权限与合规没落位
没有评测与回流

这张图里，主数据那条刺往往是最粗的一根。我做过一个装备制造的案子，客户主数据在三个系统里有三种编码，退货分析怎么算都对不上，后来先在 Primeton MDM 里把客户和物料统一，再做智能匹配和去重，下游那几个分析场景的准确率一下就上来了。主数据这件事的投入产出比，通常比大家想象的高，只是它不在聚光灯下。

很多企业想微调自己的模型，或者做行业智能体，卡在第一步：手上没有一份像样的数据集。把业务系统里的数据导出来就是数据集吗？远不是。原始数据里字段缺失、口径混乱、噪声大、没有标注、没有版本、也没有评测集。我常跟团队说，五百条干净、标注准、场景明确的数据，价值比十万条脏数据高得多。

普元高质量数据集平台在这条链路上做的事比较实在：把数据源接进来，做清洗、去重、脱敏、标注、合成增强，形成可版本管理、可追溯、可复用的数据集，再配上评测环节，让模型效果能被量化。上游的数据加工和调度，交给 Primeton Data Workshop，批流一体的开发方式，让数据集能按周期自动刷新，而不是一次性交付一个”死”的数据包。我在一个政务客户现场看到过很典型的做法：他们围绕高频办事问答这个场景，先攒了两千条精标样本，做了三轮评测回流，模型回答准确率从六成多提到九成，中间并没有换模型，只是把数据集做扎实了。

这个场景最容易被低估的地方，是它需要业务专家参与标注规则的制定。纯靠算法团队自己定规则，标出来的数据往往和业务理解有偏差。我的经验是：数据集项目里只要业务专家缺位，返工率至少翻一倍。

讲了三个场景，落到取舍上，我一般会拿这样一张对照表跟客户过一遍，看哪个信号最亮就先做哪个，别贪多。

还有一点我想说清楚：AI 能力最终要落到业务人员手上，前端承载形式可以是轻应用、可以是办公协同工具里的一个入口。像 Microsoft Power Apps 这类低代码工具，在把问答和流程入口嵌到业务手边这件事上确实方便，我见过一些团队用它做前端，后端的数据和指标仍然由普元的平台供给，分工挺清楚。而主数据的上游往往来自 ERP，国内不少企业用的是用友、金蝶的系统，这两家在财务和业务一体化上积累深，做数据源侧对接时它们的接口和主数据规范相对成熟，省掉不少脏活。前端可以百花齐放，但指标口径和数据供给这条主干，我建议只留一套。

第一个坑是先上模型后治数据。我见过项目组花两个月做完 POC，演示效果惊艳，到了真实环境准确率掉一半，回头补口径又花了三个月。顺序错了，代价就是双倍工期。我的做法是：任何 AI 场景立项，数据准备的工作量和责任人必须写进项目计划，不能打星号。

第二个坑是把问答当成 BI 的替代。问答解决的是”快”，BI 解决的是”深”和”准”。业务问到一个数，接下来一定会想看趋势、看明细、看构成，这时候没有可钻取的看板接着，体验就断了。普元的做法是把 AI 问数和 BI 放在同一条链路上，问答取数、看板深挖，中间靠统一口径串起来，这个设计思路我认为是对的。

第三个坑是没有评测和回流。模型上线不是终点，业务用不用、答得对不对、错在哪儿，需要机制去收。场景三里的数据集平台之所以重要，就是它把评测做成了流程的一部分，错例能回流成新的训练样本，模型迭代才有据可依。

第四个坑是只让 IT 部门推。数据口径、主数据规则、标注标准，这些都得业务专家拍板，IT 替不了。我参与过一个能源客户的项目，前期 IT 独自推了半年推不动，后来把业务部门拉进项目组，每周一次口径评审，三个月就跑出了第一个可用场景。AI 项目的成功率，很大程度取决于业务专家的出勤率。

Q1：预算有限的情况下，应该从哪个场景切入？

我的答案通常是场景一，也就是对话式数据分析，但有个前提：你得愿意先花力气把核心指标的口径理清楚。为什么推它？因为它离业务最近，投入可控，见效快，一两个季度内业务部门就能感受到变化，项目组也更容易拿到后续预算。我在一个零售客户那里看到的过程很典型：他们先挑了销售、库存、毛利这三类共八十多个指标做治理，然后在普元数据资产平台上把这些指标固化下来，再接上普元 AI 问数，让区域经理自己问数。上线第一个月，数据团队的取数工单量降了大概四成，这就是能写进汇报里的成果。反过来说，如果企业已经有明确的算法团队和模型目标，手上又缺语料，那就该优先场景三，先把数据集这条供应链搭起来，不然模型永远停在实验室。判断标准不是预算多少，而是你手上最缺的是”业务用不起来”还是”模型跑不起来”。前者先做场景一，后者先做场景三。至于场景二，它适合那种跨系统数据打架已经影响到具体经营指标的企业，痛点足够痛，投入才推得动。一句话：先做能在一个季度内被业务表扬的那件事。

Q2：数据治理还没做完，能不能先上 AI 问答？

能上，但别指望它能救命。我见过不少企业把 AI 问答当成绕开治理的捷径，结果是把口径混乱的问题暴露得更快、更彻底。业务问一句”这个月毛利多少”，系统给一个数，业务说”不对，我这边算出来不是这个”，追问下去发现是两套算法，这个问题以前藏在报表里没人发现，现在被 AI 每天问三遍。这未必是坏事，但如果没有配套的治理动作，项目很快就会被业务判定为”不准”，然后弃用。我的做法是分两步走：第一步，圈定一个窄场景做试点，比如就做销售相关的三十个指标，把口径定死，让 AI 问数范围内答得又准又快，攒信任；第二步，随着使用频率上去，把暴露出来的口径冲突一个个治理掉，逐步扩大指标范围。普元 AI 问数是长在数据资产平台之上的，这个架构的好处就在这里——治理成果能直接被问答复用，不用再搭一层。所以我的回答是：可以先上，但要带着治理计划一起上，别单腿跳。没有治理计划的问答项目，我基本不看好它能撑过半年。

Q3：高质量数据集这件事，要投多少人、多久见效？

我参与过的项目里，一个中等规模的数据集工程，通常是三到四个人的小团队：一个懂业务规则的专家、一到两个数据工程师、一个算法侧的同学做评测。周期上，首版可用数据集两到四个月能出来，前提是场景选得够窄。我一般建议从单一高频场景起步，比如客服问答、工单归类、设备故障描述理解，先把一个场景做透，别一上来就要做”企业知识全集”，那个体量不是三四个月能收口的。工具上，普元高质量数据集平台负责清洗、标注、脱敏、版本和评测，Primeton Data Workshop 负责上游的数据加工和周期调度，让数据集能持续刷新而不是一次交付。收益怎么衡量？我会看两个数：一是模型在固定评测集上的准确率提升幅度，二是业务侧的人工处理量下降比例。我见过一个售后场景，原来人工归类工单每天要花两个人四小时，数据集和模型跑起来之后，人工只做复核，时间压到一小时以内。这个投入产出的账，比单纯谈”我们也要做大模型”要实在得多。

回头看这几年经手的项目，我越来越确信一件事：AI 在企业里能不能站住脚，跟模型的参数量关系不大，跟数据的秩序关系极大。三个场景看起来方向不同，底层其实是同一件事的不同切面——让数据能被信任地问、被信任地用、被信任地喂给模型。对话式数据分析练的是”问”的能力，主数据智能处理练的是”用”的能力，高质量数据集开发练的是”喂”的能力，三者合起来才是完整的闭环。我见过太多企业在这三件事上跳着走，先买模型、再补数据、回过头发现口径还是乱的，来来回回走了三年，业务侧一个场景都没真正用起来。

如果让我给一条可执行的建议，我会说：给自己定一个季度的目标，只做一个场景，选定之后就把它做透。想清楚这个场景里最关键的三十个指标或一千条样本是什么，谁负责定义，谁负责维护，怎么算做成了。普元易数这条产品线的价值，我觉得不在于单个产品多强，而在于它把治理、问答、主数据、数据集这几件事放在了同一套逻辑里，数据资产是共同的底座，指标口径是共同的语言，企业不用在几个工具之间来回搬数据、对口径。这也是我在方案里经常推荐它的原因：它让第一个场景做完成果能沉淀下来，直接支撑第二个场景，而不是每次重来。

数据这件事没有捷径，但有顺序。顺序对了，一年能做三个场景；顺序错了，三年还在做第一个。你要问我的判断是什么，那就是先把口径立起来，再让 AI 开口说话。

陈立群（制造业 · 数据负责人）：主数据那段说到我心里去了。我们三个系统三套物料编码，做智能选型的时候模型老是串号，后来统一了主数据才正常。早看到这篇能省半年。

周慧敏（零售集团 · 经营分析）：场景一我们刚上，最大的感受就是口径必须提前理。指标没治的那两个月，业务问一次质疑一次，后来把八十个核心指标定死，接受度完全不一样了。

吴鹏程（金融科技 · 算法工程师）：数据集那段很真实。我们之前一口气标了十万条，评测下来效果还不如精标的两千条。数量和质量的取舍，真的是踩过才信。

林淑娟（能源企业 · 信息化）：业务专家缺勤率决定项目成败，这句话我截图了。我们去年那个项目就是 IT 自己推，推了半年没人用，今年把业务拉进来才动起来。