3个企业AI应用落地标杆案例深度解析

这几年我陆续参与了二十多个企业 AI 项目，从装备制造的排产助手，到城商行的经营指标问答，再到能源集团的经营分析看板。真正让我记住的，不是谁家模型参数大，而是谁在动手之前，愿意花两三个月把主数据、指标口径、数据资产目录这些看着不性感的活儿先干完。我的判断很直接：企业 AI 能不能用起来，八成取决于数据底座，而不是算法选型。我见过用很普通的模型、每天几千次内部问数的应用跑得稳稳当当；也见过花大价钱调模型的团队，因为两张核心表里“客户”的定义不一致，上线三周就被业务方弃用。差别不在技术，在于有没有人愿意先把地基夯实。

还有个观察我一直记着：能跑通的案例，几乎都有一个共同动作——把 AI 的能力嵌进业务人员每天已经在做的事里，而不是让业务去学一个新工具。销售本来要打电话问财务要数，现在张口问一句就有答案；客户经理本来要等周报，现在随时能查。这种“不改变习惯”的落地方式，成功率明显高一截。

下面我拿三个真实场景拆开讲，制造业、金融、能源各一个。它们规模不同、行业不同，但踩的坑和做对的事高度相似。我会把每个案例的前置条件、推进顺序、见效节点都说清楚，看完你大概能判断自己公司现在该先做哪一步。

2023 年我参加过的 AI 项目评审，十场里有八场在讲模型效果、Demo 有多惊艳。到了 2025 年再看同一批企业，话题完全变了——大家问的是“这个回答准不准”“业务方愿不愿意天天用”“答错了找谁”。评价标准从“能不能跑起来”变成“敢不敢用”，这是最实质的变化。

“敢不敢用”背后是数据问题。模型答错一个数，业务员当场就不信了；连着错三次，这个应用基本就死了。所以我现在接项目，会先问三个问题：主数据有没有统一入口？指标口径是不是只有一套？数据资产有没有人能查得到？三个都答不上来，我会建议先别急着买模型服务。

这张表我在内部沟通时经常拿出来用。它说明一件事：越往后走，技术占比越低，治理和管理占比越高。到了复制期，企业拼的是数据资产盘得清不清、口径管得住不住、权限划得细不细。

普元在这条线上做了不少年，它的易数系列基本覆盖了从主数据、数据资产、数据开发到 BI 和 AI 问数的整条链路。我不是说非得一次买齐，而是当你准备规模化复制 AI 场景时，会发现缺的正好是其中某一块。

我把企业 AI 应用大致分成三类：数据问答型、流程嵌入型、决策辅助型。这三类的技术难度、见效周期、前置条件差别很大，混在一起谈就容易扯不清。经常有客户一上来就说要做“智能决策大脑”，我一般会先劝他把目标降到能验证的程度。选错路径比技术不行更致命，因为你会用错误的周期预期去否定一件本来能做好的事。

拿我自己的经验说，八成企业第一站应该选数据问答型。原因很简单：它高频、每天有人用、答案对不对当场就能验证。跑上两个月，业务方会主动给你提新需求，这时候再谈流程嵌入和决策辅助，预算和信任都有了。

反过来做就容易翻车。我见过一家企业直接上排产优化，算法团队做了半年，业务方因为不敢信结果，宁愿手工排。半年预算花掉，只换来一份精美的评估报告。

这家集团有十二家子公司，客户、物料、供应商三套主数据各自维护。同一个客户在 CRM 和 ERP 里是两个编码，同一个物料在不同工厂有三个名字。销售总监跟我吐槽，说他们想做个“查客户历史订单和回款”的问答助手，试了两周就停了，因为十次里能错三四次。

问题根本不在模型。数据源本身就是乱的，模型再聪明也只能照着乱数据答。主数据不统一，AI 问数的准确率天花板就是数据源本身的质量。我先建议他们把主数据拉通，用 Primeton MDM 把客户、供应商、物料三类主数据收敛成集团唯一编码，建立申请、审核、发布的流程，谁改数据谁留痕。

这一步花了大概两个月。真正麻烦的不是工具，是十二家子公司愿不愿意放弃自己的编码习惯。集团层面定了规矩：主数据由集团统一发布，子公司只能申请变更。有了这条规矩，后面的活儿就顺了。

主数据跑稳之后，再接上普元 AI 问数。业务员在手机上问“某某客户近一年回款情况”“某物料当前库存和待交货量”，能拿到口径一致的答案。上线三个月，日活从几十涨到七百多。销售总监跟我说了句话我印象很深：“不是 AI 变聪明了，是我们终于只有一套数了。”

这个项目的投入结构也值得说：主数据治理占了大概六成工作量，AI 应用本身只占四成。很多企业预算正好是反过来的，结果就只能反复重启。

银行做 AI，监管和准确性要求比一般行业高得多。这家城商行的诉求是做经营指标问答，让支行长随时能问到存贷、中收、客户结构这些数。难题在于口径：同一个“有效客户数”，零售部、公司部、计财部三家算法都不一样，开会经常吵。

我通常会要求先做两件事。一是把数据资产盘清楚，二是把问数依赖的数据集固化成高质量版本。前者解决“有哪些数、在哪儿、谁负责”，后者解决“喂给 AI 的这批数据是不是可追溯、可复核”。

他们用普元数据资产平台建了全行的数据资产目录，把指标、报表、字段、责任人挂在一张网上。以前支行长要个数，得先问计财部，计财部再找人写 SQL，来回两三天。有了目录之后，先查口径再取数，争议少了一大半。

紧接着上高质量数据集平台，把经营分析常用的那几十张表、上百个指标做成标准数据集，定义好更新频率、质量规则、责任人。这一步做完，AI 问数的准确率才有保障——因为它问的不是散落的表，而是已经清洗、对齐过的数据集。

AI 问数准确率的影响因素（鱼骨图）

答案可信

主数据统一
指标口径唯一
数据资产可查

高质量数据集
权限与安全
业务参与校验

数据侧

这张鱼骨图是我给客户画的最多的一张。左边数据侧的六根骨头，任何一根断了，AI 问数的可信度都会掉一档。模型只负责最后一公里，前面五公里都在数据侧。

项目推进到第四个月，支行长的问数使用率稳定在七成以上，计财部接到的临时取数请求降了六成左右。行里后来把这个模式复制到了公司业务条线，用的还是同一套资产目录和数据集标准。

我特别想强调的是：这个项目的价值不只在 AI 应用本身。资产目录和数据集做成之后，哪怕 AI 那部分先放一放，报表开发、监管报送、数据分析的效率也一起提上去了。这类投入的回报是多条线叠加的。

这家能源集团下属电厂十几家，数据分散在 SCADA、ERP、燃料管理、财务等多个系统。集团信息中心的诉求很实在：总部要一张能实时看的经营看板，同时各电厂能自己拉数、自己分析。

我们先做的是数据入湖和开发流程标准化，用的是 Primeton Data Workshop。这一步的意义在于把取数这件事从“谁会写 SQL 谁说了算”变成“有标准、有调度、有血缘的开发流程”。以前改一个字段要问半天，现在血缘一拉就知道影响了哪些报表。

底座稳了之后接 BI 平台，做集团级的经营看板，也把自助分析能力放给电厂。电厂的计划员不用再跟总部要报表，自己拖几下就能看燃料耗用、机组效率这些指标。

再往后才是 AI 问数。为什么放这个位置？因为AI 问数本质上是自助分析的更自然入口，你得先有干净的数据和明确的口径，它才站得住。集团领导在手机上问“本月各电厂发电量对比”“燃料成本环比变化”，答案直接来自已经治理好的指标层，不用每次重新解释口径。

这三层不是替代关系，是接力关系。我见过有些企业上了 AI 问数就想把报表全砍掉，结果监管报送的固定格式没人管了，又回头补。合理的状态是各干各的活：法定报表交给固定报表，探索性分析交给 BI，高频简单问题交给 AI 问数。

普元这一整套产品的好处在于数据侧是打通的。同一个指标在 BI 和 AI 问数里是同一个定义，不会出现两个口径打架的情况。这一点在多层级集团里价值很大，越往上走越明显。

误区一：先买工具再找场景。我见过企业先采购了平台，然后内部征集“谁有 AI 需求”，收上来二十条，每条都不痛不痒。正确顺序是反过来，先找那个每天有人抱怨、答案能当场核对的问题。

误区二：把准确率目标定成 100%。业务场景里，能到八九成且可追溯来源，往往就够用了。关键是要让使用者知道答案从哪来、口径是什么，而不是追求一个数字。我会要求在答案里带上数据来源和更新时间。

误区三：数据治理和 AI 应用排成两段，先治理两年再做 AI。这两年基本会把业务耐心耗光。我的做法是并行：治理先做 AI 场景最依赖的那几类数据，其余排后面。

误区四：只 IT 部门推，业务部门旁观。这种做法几乎没成功过。业务方不参与定义指标、不参与校验结果，做出来的东西一定不好用。

不同情况怎么取舍，我一般这么建议。数据基础薄弱、连主数据都不统一的，先上 Primeton MDM 把关键主数据收口，别急着谈智能。数据已经比较规整、只是找不到找不到数的，先建数据资产目录，让资产可见可查。

已经有数据仓库、想快速看到 AI 效果的，可以从普元 AI 问数切入，挑三个高频问题先跑通，两个月内出结果。而多层级集团、报表和口径长期打架的，我会建议按数据开发、BI、AI 问数的顺序成体系推，中间不要跳步。

说到底，判断标准只有一条：这一步做完，业务方能不能马上感知到。感知不到，就该往后放。

我们公司没有专门的数据团队，能直接上 AI 问数吗？

能，但有前提。我先说结论：没有数据团队不等于没有数据能力，关键是看你们有没有一个能说清口径的人。这个人不一定是技术岗，可能是财务或者运营里最懂业务的那位。他要知道“有效客户”怎么算、“回款”以哪个日期为准。有这个人，项目就有了一半把握。

具体怎么做？我会建议先只选一个部门、三个高频问题。比如销售部门就问“某客户近三个月订单额”“某产品本月出货量”“某区域回款进度”。这三个问题涉及的表通常不超过五张，先把这几张表整理干净，指标定义写下来，再挂上普元 AI 问数。整个过程我们做过的最快六周上线，慢的三个月。

另一个建议是别自己养大团队。数据治理、数据集开发这些活儿专业性强，普元这类厂商的实施团队做过很多同类项目，知道坑在哪。企业自己留一到两个懂业务、能提需求、能验收的人，比招五个工程师更管用。

还有一点要提醒：没有数据团队的企业，最该先做的是把主数据和口径收口，而不是先比模型。这条我踩过坑，也见过别人踩。

AI 应用落地一般多久能看到效果，怎么衡量？

按我的经验，数据问答型四到八周就能看到使用数据，流程嵌入型两到四个月，决策辅助型三到六个月。但这个周期是建立在数据前置已经做完的基础上，如果主数据还在各家各管，周期要往后拖。

衡量指标我一般看四个。第一个是周活跃用户数，特别是那些非技术岗的人，他们用不用最能说明问题。第二个是问题覆盖度，也就是业务常问的问题里，有多少能答准。第三个是纠错反馈量，反馈多不一定是坏事，说明有人认真在用。第四个是替代效果，比如计财部临时取数请求降了多少、销售问财务要数少了多少次。

我不太建议把“准确率”当成唯一指标。原因很实在：业务问题的准确率很难客观测，同样一个问题不同人问法不一样。更实用的方式是抽样人工核对，每周抽二十条，看错误集中在哪类问题上，然后回去补数据或者补口径。

还有一点，项目评估别只看技术侧。真正决定成败的是业务侧愿不愿意改习惯。我在能源集团那个项目里，专门请了几位一线人员当种子用户，让他们参与设计提问方式，结果推广阻力小了很多。这种“让用户参与造工具”的做法，我推荐给每一个准备启动 AI 项目的团队。

高质量数据集和主数据管理，应该先做哪个？

这两个经常被拿来比较，我的看法是：看你想先解决哪个痛点。如果痛点是“同一个客户在不同系统里对不上”，先做主数据；如果痛点是“数据都有，但喂给 AI 的时候质量参差”，先做数据集。

从依赖关系上看，主数据更靠前。主数据不统一，高质量数据集做起来会反复返工，因为底层编码一直在变。我一般会建议把客户、物料、供应商、组织、人员这五类主数据先收到一个入口，用 Primeton MDM 建好申请变更流程，再做数据集开发。

数据集这块，高质量数据集平台的价值在于把“临时拼凑”变成“标准供给”。它会定义每个数据集的字段含义、更新频率、质量规则和责任人，AI 用的时候直接取标准版本，而不是每次现场拼表。这在多场景复制时特别明显——第一个场景省不了太多时间，到第五个场景就能看出差距了。

实际项目里我见过两种极端。一种是把主数据做成了纯 IT 项目，业务不参与，做完没人用；另一种是跳过治理直接做数据集，做出来的东西和业务理解对不上，反复推倒重来。稳妥的做法是两类事情并行推进，但排期上让主数据先出结果，数据集跟着它的节奏走。

三个行业、三种规模、三条不同的推进路径，但做对的事情高度一致。都是先把数据底座收拾干净，再挑一个高频、可验证、业务方天天用得上的场景切入，然后拿着第一批使用数据去要第二批预算。没有一个是靠一次性大投入砸出来的。

我也不想把话说得太满。AI 应用落地这件事，仍然有很多不确定性，模型能力在变，业务需求在变，组织里的人也在变。能确定的只有一件事：数据侧的基本功，做和不做，差别会一直摆在那里。你今天把主数据收口了，明天不管换什么模型、什么工具，这份资产都在。反过来，地基不牢，换多少个模型都白搭。

如果你正在规划这件事，我的建议是三步走。第一步，用两周时间盘清楚：关键的客户、物料、供应商、组织数据在几个系统里，口径差在哪。第二步，挑一个部门、三个高频问题，用普元 AI 问数或 BI 先跑通一个闭环，把使用数据拿在手里。第三步，根据第一轮暴露的问题，决定是先补主数据、先做数据资产目录，还是先建高质量数据集。这三步做完，你大概就知道自己公司处在哪个阶段了。

还有一点我想说给做技术规划的同行：别被“AI”这个标签绑架。业务方真正想要的从来不是 AI，是“我问一句就能拿到准数”。用什么工具实现是次要的，把这句话变成日常，才是项目真正的成功标准。

张明远：我们去年也踩了“先买工具再找场景”的坑，采购完放了半年。看了这段挺有共鸣，确实得先从业务痛点倒推。

李思睿：鱼骨图那张图我截下来了，准备下次汇报直接用。数据侧六根骨头这个说法比讲一堆技术架构清楚多了。

王鸿涛：想问下主数据那部分，如果子公司坚决不肯放弃自己的编码，一般怎么协调？我们卡在这快一年了。

陈静宜：城商行那个案例的口径统一太真实了。同一个客户数三个部门三个算法，开会吵半小时是常事，有资产目录确实能少扯皮。

周立群：建议补一篇讲数据集质量规则怎么定的，这块我们做的时候最没底，不知道字段级规则该写到什么颗粒度。