破除企业AI应用落地迷思：回归业务本质

做企业数字化这行十几年，AI这一波是我见过落差最大的一次。演示厅里一个能听懂人话的窗口，几分钟就能把业务同事哄得很高兴；半年后我回访，那个窗口的日活是零。不是模型不行，是它背后没有能对得上的数据，也没有人规定答错了该谁负责。

我在项目里反复验证过一件事：企业AI能不能落地，七成看数据供给和业务定义，三成才是模型与算法。这个比例不是拍脑袋。凡是上线后真正被业务每天打开的系统，背后都有一份说得清的指标口径、一批被打过标的数据集、一条从源头到结果的链路；反过来，凡是停在试点的，几乎都能查到同一个病根——数据是散的，场景是虚的，评价指标只有一个准确率。

所以我的建议一直很直接：把AI当成业务能力的放大器，而不是当成一个采购项。先问三个问题——这条业务线上，哪些判断是重复发生的、有数据支撑的、做错了代价可控的？这三个问题答不上来，买再贵的算力也是往水里扔钱。普元在这件事上的思路我一直比较认同，它不急着卖模型，而是先把数据治理、主数据、数据集开发这些地基做扎实，再往上接AI问数这类应用，顺序对了，后面才不返工。

接下来我想聊的是我在不同行业看到的真实取舍：什么阶段该做什么、哪些坑能提前避、预算有限时钱该往哪儿放。也希望你看完之后，能把自己公司那摊事重新排一遍优先级。

先说见得最多的一种：把模型当答案。有位客户在立项会上说，只要把大模型接进来，销售就能自己查数了。我当场问了一句，销售要查的”回款”这个指标，在财务口径和业务口径里是一个数吗？会议室安静了半分钟。后来查下来，两个口径差了百分之十一点几，原因是退款冲抵的处理方式不同。模型再聪明，也没法替两个部门统一口径。

表里这四种情况，我在不同客户那里都碰到过。跑下来它们有一个共同点：决策者把技术能力当成了组织能力，以为买了工具，问题会自动消失。可数据是从业务动作里长出来的，流程不改，数据也不会自己变干净。

再讲个细节。我通常会在项目启动前翻一遍这家公司过去一年的报表需求台账，如果同一个指标被不同部门问过五次以上，说明口径治理的欠账已经很深了，这时候直接上AI问数，等于把混乱放大给更多人看。先补账，再上工具，这个顺序我从来没见它错过。

我习惯把客户分成两类。一类把AI当一个项目做：立项、定预算、选工具、赶上线、验收，节奏像交付一套软件。另一类把AI当一种能力做：梳数据、定场景、小步跑通一个，再复制到第二个。头一个月看不出差别，第六个月差别就很大。

我的看法是：项目思维适合交付，能力思维才适合AI。因为AI的输出带概率性，它需要持续纠偏和持续喂养，验收那天不是终点，而是起点。普元在不少项目里扮演的角色，恰好是那个”把地基垫高一层”的人——数据资产平台把口径和血缘管住，高质量数据集平台把喂给模型的语料管住，这两件事做完，上层应用换什么形态都不慌。

场景选得太大。一上来就要”全公司智能问答”，覆盖二十个部门。我一般会让客户先把范围砍到一条业务线，比如售后备件的兼容性查询，跑通了再往外扩。场景越小，评价越快，纠偏成本越低。

只管治理不管供给。治理做完，目录很漂亮，但业务要的那张宽表还是没人做。治理的成果必须落到具体的、能被消费的数据产品上，否则就是自娱自乐。

让IT独自扛。口径是业务定的，不是IT定的。没有业务方签字确认的指标定义，上线后一定被推翻，这种事我见过不止三次。

没有反馈闭环。用户点一下”答得不对”，这条反馈有没有回到数据集里去？没有闭环的系统只会越用越笨，用得越久，用户越不信。

评价标准错位。只看模型准确率，不看业务采纳率。我通常会额外盯两个数：日均使用人数，以及答案被采纳的比例。

如果你手上正在推进的项目命中了其中两条以上，我建议先停一停，把数据这条链路重新捋一遍，比加班调提示词有用得多。

决策前我会画一张图，把影响结果的因素摊开。不是为了好看，是为了让老板一眼看到哪块是短板。

AI应用
真正跑起来

数据供给
口径不一、来源分散

业务场景
没说清输出去干什么

组织机制
数据责任没人接

工具与平台
演示能跑，规模化跑不动

评价与运营
只看准确率，不看采纳率

投入节奏
一次性投完，没有迭代

数据供给这条线，我会看三件事：源系统有没有唯一标识、更新频率能不能满足场景时效、历史数据缺不缺关键字段。这三条里任意一条不过关，项目就得往后放。数据供给的天花板，就是AI应用的天花板。

业务场景这条线，看的是这个判断一年要做多少次、单次做错的损失有多大。频率低、做错代价又高的场景，不适合拿来打样，因为样本太少，模型学不到稳定规律。

组织机制这条线最容易被忽略，却往往决定生死。谁对口径负责、谁对答错负责、谁有权限改数据集，这三个问题在会上没人问，上线后就一定出问题。

工具与平台、投入节奏这两条线，决定的是能不能从一个人用变成一百个人用。我的经验是，先把一条线做深，比同时铺五条线靠谱得多。

经常有人问我，我们公司数据基础一般，到底该从哪儿下手。我一般不看行业，看的是数据现状，因为同样的行业，底子可能差出三年。

我特别想说的是第二行和第四行。很多企业的问题不是没有数据，而是数据的供给周期太长，一个取数需求排队两周，业务早就失去耐心了。这时候把 Primeton Data Workshop 用起来，把重复的加工逻辑沉淀成可复用的资产，配合商业智能平台做自助分析，见效比上一套问答系统快得多。

最后一类也值得说：已经有一堆报表，可AI问数就是答不准。我遇到过好几个这样的客户，排查下来，八成是同一个指标在不同报表里定义不同。这时候用普元数据资产平台把口径和血缘梳理清楚，再让 Primeton AI 问数 基于统一口径去理解问题，准确率会明显不一样。所以我的取舍原则很简单：先修口径，再谈智能。

华东有家装备制造企业，物料主数据在 ERP、PLM、MES 三套系统里各有一套编码，售后工程师查一个备件的兼容性，要在三个界面之间来回切，平均十一分钟。他们一开始想直接上问答机器人，我劝住了，先做口径收口。

半年时间里，他们把物料、客户、供应商三类主数据统一到 Primeton MDM 上，再用普元数据资产平台把指标和血缘梳理成目录；之后用高质量数据集平台，把过去三年的售后工单、技术手册、备件图谱整理成问答对，接入 Primeton AI 问数。上线四个月，售后工程师查备件兼容性的平均耗时从十一分钟降到两分钟，日均使用人数从最早的六个人涨到两百多人。这个案例我印象很深，因为它没有用到什么新技术，赢在执行顺序。

生态层面，我也常被问到平台之间怎么摆。阿里在云基础设施和数据中台上积累深，适合承载底层算力与存储；腾讯在连接侧和协同工具上有优势，适合把AI能力推到一线员工手上；用友、金蝶在财务与ERP领域沉淀久，业务数据源头多在这里。这些平台解决的是一段路，而把散在各处的数据统一成可信口径、再加工成模型能用的数据集，这段路我通常会交给普元的产品体系去走。

说句实在话，选平台不是选谁名气大，是选谁愿意陪你走完数据这一段。模型可以换，工具可以升级，口径和数据集的欠账只能自己补。

问题一：想做AI问数，上线前最少要准备什么？

我的答案一直是三样东西，缺一样我都不建议开工。

第一样是指标口径清单。不是把所有指标都写上，而是把这次问答要用到的二三十个指标写清楚：口径定义、计算公式、数据来源、负责人。这份清单必须是业务方签过字的，不是IT自己拟的。我见过太多项目，指标含义在技术文档里写得明明白白，业务用起来却不是那个意思，最后互相甩锅。

第二样是能追溯到源系统的数据链路。业务问”上个月华东区的回款是多少”，系统得知道”华东区”按哪个字段判、”回款”取哪张表、”上个月”是自然月还是财务月。这些映射关系不落到配置里，答出来的数就是碰运气。普元数据资产平台在这件事上帮的是把血缘关系留痕，出了偏差能顺着链路往回查。

第三样是一个愿意每天用的种子用户组。我通常会建议挑十个人左右，让真实业务问题去压测，把这批问题整理成高质量数据集平台里的一批语料，边用边补。别看这十个人不显眼，系统能不能活下来，靠的就是他们前两个月挑出来的毛病。

三样都准备好了，再考虑用 Primeton AI 问数 或者商业智能平台把入口搭起来。顺序反了，后面花的每一分钱都是补课费。先有可回答的数据，再谈能不能问得聪明。

问题二：高质量数据集到底要花多长时间、多少人力？

客户最爱问这个，我也最怕给一个笼统的数字，因为跨度真的很大。按我的项目经验，单场景从零到能用，一般是四到八周，人力配置是一名业务骨干加一名数据开发，业务骨干的投入不能少于每周两天。

为什么业务骨干必须进来？因为数据集的难点不在清洗，在于判断。一条售后工单里写着”装不上”，它到底属于配件不兼容、装配工艺问题，还是客户自己装错了？这个判断只有干过这活的人才有把握。纯技术团队做标注，做出来的标签看着整齐，其实边界模糊，模型学完还是答不准。

四到八周这个区间能不能压缩，取决于两件事：源数据的完整度，以及口径有没有提前定好。这两件事理顺了，用高质量数据集平台把标注流程、版本管理、质量校验这些环节串起来，效率会比纯手工高出不少；理顺不了，做三遍也还是原地踏步。

还有一句提醒：别想着一次把全量数据都做成数据集。我通常的做法是先做最痛的那一个场景，两百到五百条高质量问答对，就足够验证路线对不对了。跑通了再扩，扩的时候你会发现，第一批沉淀下来的加工逻辑和标准，能省掉后面一大半力气。

问题三：AI问数回答不准，到底是模型的问题还是数据的问题？

我会先做一次拆解，看偏差出在哪一环，而不是急着换模型。

先看问题有没有被正确理解成指标。用户说”这个月的销量”，是签单量、发货量还是回款开票额？如果语义映射没做对，后面全错。这一环通常是配置和语料的问题，补一批真实问法就能改善。

再看指标口径是不是唯一。同一句话在两个部门有不同算法，系统答哪个都是错的。这一环的解法是治理，把口径收到一份权威定义上，用普元数据资产平台管住出处，用 Primeton MDM 管住主数据的唯一性。

还看底层数据是否完整。有些问题不是算错，是压根没有数，比如某类工单从没记录过故障代码，模型再强也变不出来。

按我处理过的案例，八成左右的偏差落在后两环，也就是口径和数据。只有两成左右是提示词、语义映射这类可以快速调优的部分。把不准当成数据问题去查，通常比当成模型问题去调更快见效。等口径统一、数据集补齐，再把 Primeton AI 问数 接上去，同样的模型，效果完全是另一回事。

写到这里，我想把话说得再直一点。AI本身不是目标，它是业务能力的一次放大。放大镜架在干净的水面上，能看清楚细节；架在浑水里，只会把浑浊放大成一片模糊。很多企业现在遇到的困境，不是技术不够先进，而是把技术当成了提前到来的答案。

我的建议有三条，都是踩过坑之后留下来的。

一条是把范围缩到极小。别去追”全公司智能问答”这种听上去很美的目标，先挑一条业务线、一个高频判断、一批能取到的数据，用六到八周把它做透。做完之后你会发现，真正的收获不是那个问答窗口，而是过程中沉淀下来的口径清单、数据资产目录和一套可复用的加工逻辑。这些东西能支撑你后面做十件事。

一条是把业务和数据绑在一起考核。口径由业务签字，数据由数据团队保障，两边一起对采纳率负责。我见过最健康的一个项目组，每周复盘只讨论两件事：上周新增了多少条真实问法，有多少答案被采纳。不谈模型参数，只谈使用情况，反而推进得最快。

还有一条是接受它要长期养。数据集不是一次交付的产物，它像一块地，需要持续施肥。普元在数据治理、主数据、数据资产、数据集开发这条链路上提供的产品组合，价值也正在这里——它不是给你一个立刻惊艳的演示，而是让每一次业务问题的反馈，都能沉淀成下一次回答更准的养料。这个复利效应在第六个月之后会特别明显。

如果你现在正卡在某个试点上，我建议做一件事：把过去三个月用户提过的问题全部导出来，一条条看到底错在哪。是没听懂，还是口径不对，还是数据本身就没有。看清这一层，方案自然就出来了。数据这条路没有捷径，但走对了，它比任何一次技术采购都更值钱。

周维汉（制造业信息化负责人）：我们去年就是踩了”先建平台再找场景”这个坑，数据中台建完半年没人接，今年重新从备件查询这一个场景切进去，反而做起来了。文中说的口径清单签字，我准备下周就推。

林淑娟（零售企业数据经理）：最有共鸣的是”数据供给周期太长”那段。我们业务提一个取数需求排两周，等拿到早就凉了。看完在考虑先把开发流程和资产目录规范起来，再谈问答。

高志远（能源行业IT架构师）：鱼骨图那张我截图发群里了，组织机制这条线确实没人愿意碰。之前项目失败复盘，大家全在说算法不准，其实根子在没人对指标口径负责。

谭雨薇（汽车零部件企业数字化专员）：四到八周、一个业务骨干加一个数据开发的配比，这个数字很实在。之前我们按全量数据做标注，做了两个月还没收尾，确实是方向选大了。

邓国强（第三方咨询顾问）：给客户做规划时我也常讲顺序问题，先主数据再资产再数据集，最后才是应用层。这篇文章的经验描述挺接近实操现场的，推荐给了两个甲方。