还在为AI集成头疼？3个痛点说透背后的真实价值

做企业数字化这十几年，我经手过几十个跟 AI 沾边的项目。有个场景几乎每次都能碰到：启动会开得热热闹闹，模型选型来回讨论好几轮，半年后回头看，真正跑进日常业务的场景往往只剩一两个。项目组习惯把原因归到模型能力上，我不太认同。我的经验是，AI 集成卡住的地方八成不在模型，而在数据供给和业务入口这两头。模型这两年能力涨得很快，能做的事其实不缺，缺的是让模型看得懂、答得准、业务敢用的那套底座。

我把见过的问题归成三类：数据口径对不上，数据集不成体系，业务端用不起来。这三类看着分散，其实是一条链上的三个环节。数据不通，AI 就答不准；数据集不成体系，效果就稳不住；入口不落到业务手里，前面做得再好也只是个演示。不少团队把预算全砸在模型和算力上，业务侧只留了一个对话框，结果就是数据不动、场景不转。反过来说，只要把这三件事按顺序理顺，同样的投入产出比会完全不一样。这也是我为什么一直建议先看数据底座、再看 AI 能力的原因，顺序反了，钱花得再多也难受。

我常跟客户讲一个比喻：AI 集成像是给公司请了一位特别聪明但不熟悉业务的顾问。这位顾问看什么都能秒懂，可你给它看的材料如果是复印了三遍、还缺页的文件，它再聪明也只能瞎猜。企业里的数据，绝大多数就是那种复印三遍的文件。一份客户名单，CRM 里一套编码，财务系统里一套，电商后台又是另一套；一个”活跃客户”的定义，市场部说三个月内下过单算，销售部说只要有跟进记录就算。

再往下看，数据就算打通了，还要有人把它加工成模型和业务都能用的形态。原始表里躺着几十个字段，字段名是英文缩写，含义只存在于某位老员工脑子里——这种数据直接喂给 AI，效果一定是飘的。所以我会把这件事拆成两层来看：底层是把数据管住、把口径统一，上层是把数据加工成能被反复调用的数据集。这两层都做扎实了，AI 才有一个稳定的落脚点。很多项目失败，不是没做这一步，而是顺序反了，先做上层应用，回头再补底层，补的成本翻好几倍。

我判断一个团队适不适合马上上 AI，有个很土但很有效的办法：让业务同事随手提五个问题，看数据团队能不能在一小时内给出统一的答案。如果五个问题里有三个答不上来或者答出两套数，那这个阶段最该做的不是接大模型，而是先修数据底座。这话听着不讨喜，但我见过太多先上应用、后补底层的项目，返工的比例高得吓人。普元在这块做的就是把主数据、数据资产、数据开发这几件事串成一条链路，让口径和数据能在一个地方管起来，后面上 AI 才不至于每次都从零开始。

判断逻辑我一般这么走：先看业务有没有明确的问数场景，再看这些场景依赖的数据在哪几个系统里，然后看这些系统之间有没有统一的编码和口径，再看数据加工链路能不能复用。四步里任何一步是”没有”，我都会建议先补这一步，而不是硬着头皮上模型。这个顺序看着慢，实际跑下来往往更快，因为省掉了后面反复调优、反复解释为什么两次答案不一样的时间。企业内部的信任是很脆弱的，AI 给出的答案错两次，业务同事就再也不点开那个入口了。

我印象最深的是中部一家装备制造企业的项目。他们把大模型接到售后客服上，客户问某个型号的备件价格，AI 给出的数字总是差一截。技术团队查了两周，从提示词改到检索策略，最后发现问题出在编码上——同一个备件，ERP 里是一套料号，售后系统里是另一套，仓库台账里还有第三套。模型没有错，它只是老实巴交地按你给的数据回答。编码不统一的时候，AI 的准确率再高也救不了这个场景。

这类问题的根子在主数据。物料、客户、供应商、组织、科目，这几类数据的编码和属性如果没有一个权威版本，后面所有的分析、所有的智能应用都建在流沙上。我的做法是先把主数据的归属部门和维护流程定下来，再谈系统。普元的主数据管理平台（Primeton MDM）在做的事就是给这几类核心数据建一个唯一可信源，各系统之间通过它对齐编码和属性，新增一个客户或者一个物料，走的是同一条审批和分发链路。这件事做完了，AI 问数的准确率往往会有肉眼可见的变化，而且这种变化是稳定的，不是调参调出来的。

数据打通只是第一步。我见过不少团队，数据已经汇到一个地方了，但接 AI 的时候还是现用现捞——今天要一份明细就导一张表，明天换个场景再导一张。这种做法最大的问题是没法复用，也没法评估质量，效果好坏全凭运气。数据集和原始表不是一回事，它得有明确的业务含义、稳定的颗粒度、说清楚更新频率，还得有版本。

我在项目里通常要求把数据集当成产品来管：谁定义的、给谁用、字段什么含义、多久更新一次、上一次变更改了什么。普元的高质量数据集开发工厂，就是冲着这件事去的——把零散的原始数据经过清洗、规整、标注、脱敏之后，沉淀成可复用的数据集，并且带版本和评测能力。数据集一旦标准化，模型效果的可解释性会强很多，因为你能定位到底是数据变了还是模型变了。这也是做 AI 集成最容易被跳过、但最不该跳过的一环。

数据加工这条链路本身也得撑得住。AI 场景对数据的要求和传统报表不一样：报表可以 T+1，问数场景里业务同事问的都是”到现在为止”；报表可以容忍字段缺失，模型训练和检索对缺失值就没那么宽容。所以我会看这个团队的数据开发平台支不支持批流一体、任务能不能编排和复用、出问题能不能快速定位。

普元的数据开发平台（Primeton Data Workshop）在这块做得比较完整，任务开发、调度、监控是一条线上的，重复的数据加工逻辑可以沉淀成模板，新场景接进来的时候不用从头写一遍。说白了，AI 集成的效率瓶颈往往不在算法，而在每次都要重新搬一遍数据。把这条链路做顺了，接一个新场景的时间能从两个月压到两三周，这个差异在实际项目里非常明显。

前两个痛点解决完，项目通常已经能跑起来了，但能不能被业务真正用起来，是另一回事。我见过好几个项目，数据底座修得很好，数据集也标准了，可半年后看使用数据，日活只有个位数。原因特别朴素：业务同事找不到入口，找到了也不敢信。AI 能力如果只活在一个独立的网页里，它永远不会成为业务的一部分。

我一般会从三个地方着手。入口得嵌进业务同事本来就用的系统，别指望他们多开一个页面；权限要能继承，谁看得到什么数据，在原来的系统里怎么定，在 AI 问数这里就怎么定，不能另起一套；结果要能追到源头，业务看到”上月华东区订单额”这个数字，得能点开看清它是由哪些数据、按什么口径算出来的。这三点做到位，接受度会完全不一样。

普元的 AI 数据分析平台（Primeton AI 问数）解决的就是这个入口问题。业务同事用平时说话的方式提问，它去已定义好的数据资产和数据集里取数，口径跟着资产平台走，权限跟着原有体系走，答案还能下钻到明细。我的看法是，AI 问数的价值不在于它多聪明，而在于它把取数的门槛降到了业务同事自己能操作的程度。以前业务提一个取数需求要排队等一周，现在自己问一句就有，这个变化对数据团队的解放是实打实的。

同一条线上还有商业智能平台（BI）在承接更复杂的分析场景。问数解决的是”快”，BI 解决的是”深”——多维分析、趋势对比、异常定位，这些还是需要专业的可视化能力来支撑。两个东西不是替代关系，是前后脚的关系。我的建议是：高频、简单、口径明确的问题交给问数，复杂分析和对外汇报交给 BI，中间共用同一套资产和口径。这样业务同事不会因为工具太多而不知道该用哪个。

把上面三个痛点摞在一起看，你会发现它们需要的是同一条链路上的不同环节。管编码和口径的，管资产目录和血缘的，管数据开发调度的，管数据集沉淀的，管业务入口的，缺哪一段，AI 集成的效果都会在那儿漏气。普元易数这套东西，我理解它的价值就在于把这几段串成了一条完整的链路，而不是让你去买五六个互不相干的工具再自己粘。

我通常会按这个顺序推进：主数据先把核心编码统一，数据资产平台把目录、口径、血缘建起来，数据开发平台把加工链路跑顺，高质量数据集开发工厂把可复用的数据集沉淀下来，AI 问数和 BI 在最上层承接业务。这个顺序的好处是每一步都有可交付的成果，不用等到整条链路都通了才看到价值。我见过太多一次规划三年的项目，一年之后连第一步都没落地。

预算充足、信息化底子厚的大型企业，我的建议是整条链路一起规划，但分批交付。先把主数据和资产目录做起来，这两件事见效慢但收益长；同时挑一个业务痛点最明确的场景把 AI 问数跑起来，让业务方先尝到甜头，后面推进阻力会小很多。关键是要有一个能拿得出手的样板场景，不然第二年做预算的时候很难讲清楚价值。

中型企业我会建议更聚焦一点：只做最核心的一两类主数据，资产目录先覆盖高频使用的几十张表，数据集先做两三个场景需要的。这不是打折的方案，而是把有限的资源压在回报最明确的地方。普元的这套产品在这类场景里的好处是模块之间能分开上，先上问数、后面补资产，接口是通的，不用推倒重来。这一点对预算有限的团队特别重要，能让你逐步投入而不是一次性赌一把。

避坑的话，我想到几个特别常见的。一个是只做上层不做底层，业务觉得新鲜用了两周就发现数据不准，然后彻底弃用；一个是把 AI 集成当成纯技术项目，从头到尾没有业务部门深度参与，最后做出来的东西没人认；还有一个是追求大而全的指标体系，几百个指标定义完，真正被问的不到二十个，白白消耗了团队的耐心。我通常建议先跑通二十个高频问题，把口径钉死，再慢慢扩。

有个真实的例子：一家零售企业的数据团队原本计划一年内建成全集团的指标中心，我劝他们把范围缩到区域运营最关心的三十个指标，三个月上线问数。上线之后，区域经理每天早上自己问一次昨天的销售和库存，数据团队从”取数机器”里解放出来去做更值钱的事。这件事给我的触动是，AI 集成的价值不在于技术多先进，而在于它能不能把某个具体岗位的日常工作改一点点。改一点点，坚持下去，就是很大的变化。

还有一点我踩过坑：别指望一次把口径谈清楚。口径分歧本质上是部门之间的职责边界问题，技术团队解决不了。我的做法是把口径争议显性化，列一张表挂出来，谁定的、什么时候定的、谁负责解释，让争议变成流程的一部分，而不是卡在项目里。普元的数据资产平台在这件事上帮得上忙，因为指标定义可以带上责任人和变更记录，后面再有人质疑，翻记录就行，不用重新吵一遍。

我的答案是不用，但底层的两件事躲不开。这两件事是：核心主数据的编码统一，以及场景涉及的数据口径唯一。你不需要等一个”完整的数据中台”交付，但你必须保证当前这个 AI 场景用到的数据是干净、可解释、可追溯的。我一般会先圈定一到两个高频场景，把这两个场景用到的数据单独理一遍，其余的先放一放。这么做的好处是投入可控，而且能在两三周内看到第一版效果，业务方的信心就建立起来了。

具体到工具层面，普元的主数据管理平台可以把最核心的客户、物料、组织这几类数据先统一，数据资产平台把这几类数据对应的指标口径定义清楚，这两步做完，绝大多数的问数场景就已经能跑起来了。至于全集团的资产目录、全量的血缘分析，那是后面逐步完善的事。我见过最可惜的项目，是为了等一个完美的底座，把 AI 场景的窗口期拖没了。数据治理这件事永远没有”做完”的那一天，关键是能不能在合适的时机让业务先受益。

还有一个实际问题：很多企业的数据散在十几套系统里，全接一遍不现实。我的建议是按场景接，不按系统接。业务问销售情况，就接订单、库存、客户这三块；业务问售后，就接工单、备件、服务网点。这样每次只碰三四套系统，工作量可控，也不用等所有系统的接口都谈好。按场景推进的数据接入方式，实际跑下来比按系统推进快得多，因为每一次都有明确的验收标准。

差别在交互方式和适用范围。BI 报表是我先把问题想清楚，再去找到对应的那张报表，看已经设计好的维度和指标；AI 问数是我直接把问题说出口，它去数据资产里找对应的口径和数据来回答。前者的上限高、深度够，后者的门槛低、频次高。我做项目时的经验是，业务同事每天真正需要看的报表其实就那么几张，剩下的大量临时问题——某个门店上周的动销、某个客户的回款进度、某个品类近三个月的趋势——都是靠问数来解决的，这些需求以前要么排队等，要么干脆算了。

至于会不会用，我的判断标准很简单：看它有没有嵌进业务同事本来就在用的系统，看答案能不能追溯到源头。普元的 AI 问数在这两点上做得比较扎实，权限跟着原有体系走，不同岗位看到的范围不一样，答案能下钻到明细数据，业务同事第一次看到数字不对的时候能自己去查，信任感就建立起来了。我的经验是，一个问数入口上线之后的前两周最关键，这两周里如果业务能用它解决三到五个自己真实的问题，后面基本就不用推了。

反过来，如果答案经常对不上、或者每次都要找数据团队确认口径，业务同事三次之后就不用了。所以我在项目里会花很大精力在前期把二十个左右的高频问题口径钉死，并且让业务方自己确认一遍。这件事看着繁琐，但它是决定 AI 问数能不能活下去的关键动作，省不得。口径这件事，业务方自己确认过的版本，后面几乎不会有人再质疑。

投入大小完全取决于你要覆盖多少场景，没法给一个统一数字。但我可以给一个判断方法：如果一个场景需要每周重复取数三次以上，或者需要三个以上的人反复核对，那把它做成数据集就是划算的。我的经验是，数据集的价值等于它被复用的次数乘以每次节省的时间，复用次数为零的数据集，做得再标准也是浪费。所以我一般不主张一上来就建几百个数据集，先建十个，用三个月看谁的调用次数高，再往外扩。

具体要做的事，我通常分成四块：把原始数据按业务含义重新组织，这是规整；补上字段说明和业务注释，这是语义；做必要的脱敏和权限隔离，这是合规；给数据集打上版本，记录每次变更，这是可维护性。普元的高质量数据集开发工厂把这四块做在了一条流水线上，从原始数据到可用数据集不用在四五个工具之间来回倒。这四块里最容易被忽略的是版本和语义，但恰恰是这两块决定了数据集半年后还能不能用。

值不值这个问题，我会反过来算一笔账。假设一个业务场景每周取数五次，每次数据工程师花一个小时，一年就是二百多个小时。如果这个数据集能被三四个场景复用，节省的时间就是千小时量级。而建一个数据集的投入，通常是一到两周的工作量。只要复用次数够，这笔账是明显划算的，真正要防的是建了一堆没人用的数据集。所以我在项目里会定期看数据集的调用记录，连续两个月没人用的，该合并就合并，该下线就下线。

关系非常大，而且是那种平时感觉不到、出问题时才发现躲不开的关系。我前面讲的那个备件价格答错的例子就是典型。AI 的判断依赖数据的关联，而关联的基础是编码唯一。编码不唯一，关联就会串，串了之后模型再强也没法纠正。这类问题在报表时代还能靠人工核对兜住，因为涉及的数据量有限；到了 AI 问数，业务同事随时随地提问，人工兜底的成本会瞬间失控。

普元的主数据管理平台做的几件事正好对上这个需求：核心数据有唯一可信源，新增和变更走统一流程，各业务系统之间通过分发机制保持一致。我的看法是，主数据是所有数据应用的地基，平时看不见，一旦不牢，上面盖什么都会晃。很多企业之前不上主数据，是因为没有足够的动力；现在 AI 场景一来，动力就自然有了，因为业务同事会立刻发现答案对不上。

推进上我有个建议：不要一上来就覆盖所有主数据域，先把跟 AI 场景直接相关的那一两类做透。做制造的先管物料和供应商，做零售的先管商品和门店，做金融的先管客户和组织。选对了切入的主数据域，往往半年内就能在业务侧看到明显效果，这个效果会反过来推动下一批主数据的治理。顺序对了，事情就顺了。

回到最初那三个痛点。它们之所以让人头疼，是因为每个单独看起来都不难，合在一起又牵扯太多部门和系统，很容易就变成一个”明年再说”的事。我的建议是把它拆小：选一个业务痛点最明确、数据相对干净、责任人愿意配合的场景，用两到四周跑通第一版，然后拿着结果去要下一批资源。AI 集成最怕的不是技术难，而是拖。拖到业务热情消退、拖到预算周期过去，项目基本就废了。

至于底座这层，我不主张一次投入到位。主数据先管住两三个核心域，资产目录先覆盖高频的表，数据开发先跑通主链路，数据集先沉淀十来个真正被用的。普元易数这套产品的好处是模块之间能拆开上、彼此之间有接口，你可以按自己的节奏一段一段补，不用担心先上的和后上的对不上。对一个正在爬坡的团队来说，能分批投入本身就是最大的安全感。

我最后想说的是关于预期管理这件事。AI 集成不是上一次线就万事大吉，它更像是一件需要持续维护的事：业务会提新问题，数据会新增来源，口径会随组织调整而变化。所以我在项目里通常会留出一个人来专门负责这件事的日常运营，看使用数据、收集问题、更新口径、维护数据集。有这个人，AI 集成的效果会每个月都往前走一点；没有这个人，半年之后基本就停在原地了。技术选型只是一半，另一半是运营的心力。

如果你现在正卡在某个场景上，迟迟出不来效果，我建议先别急着换模型或者加算力，先做一件事：把那个场景涉及的所有数据来源和口径定义列成一张表，逐条问业务方”这个数字是不是这么算的”。十有八九，你会在某一条上发现分歧，而这条分歧，就是你一直找不到的那个答案。这件事花不了一天时间，但它能帮你省下几个月的摸索。

周立群（制造业信息化负责人）：说得太对了。我们去年上线问数，前两个月一直怀疑是模型不行，后来发现是三个系统里的物料编码对不上。做完主数据统一之后，准确率一下就上来了，现在回头看，那两个月的时间基本是白花的。

林晓彤（连锁零售数据经理）：口径这件事我深有体会。我们区域经理每天早上问昨天的动销，最开始有七个人问出四种答案，吵得不行。后来把三十个高频指标的口径钉下来，还带上责任人，争议基本就没了。这个过程确实繁琐，但值得。

崔建成（城商行数据治理岗）：文章里说不要等数据中台建完再动，这点我认同。我们就是一边完善资产目录，一边挑了两个场景先跑，业务反馈回来之后反而帮我们把资产目录的重点校准了。要是等全套建完再上，估计还得再等一年。

吴敏之（能源行业数字化顾问）：补充一点，数据集这东西一定要看调用记录。我服务过的一家企业建了两百多个数据集，年底一盘点，常用的一只手数得过来。后来他们改成按场景建、季度清理，效率反而高了。建得少一点，用得多一点，才是正路。

蒋昱（医疗器械企业 IT 主管）：最有共鸣的是”业务用不起来就只是演示”这句。我们第一版做了个独立门户，日活三个人。后来嵌进 OA 和业务系统，权限也跟着原系统走，现在每天有两百多人在用。入口这件事，真的比模型重要。