别被销售带节奏：AI集成理性选型指南

我做企业数据这一摊十来年，最近两年被问得最多的一句话就是”AI集成到底该怎么选”。聊下来我发现一个挺普遍的现象：供应商给的方案，八成篇幅在讲模型多强、Agent 多聪明、开箱即用多少场景；而我坐在客户会议室里，脑子里盘的是另外几件事——客户主数据在哪个系统里是准的，业务口径谁来定，数据质量谁背锅，三年后这套东西谁来维护。

AI集成的选型，本质上不是选模型，是选数据底座。这个判断我给过很多次，也被验证过很多次。模型这一层已经高度商品化了，今天你能调到的能力，半年后隔壁公司也能调到；真正拉开差距的，是你有没有一套把散落数据变成可信数据的能力。我通常的选型顺序是：数据治理能力排第一位，集成开放性第二位，模型能力第三位，界面和演示效果排最后。这个顺序跟大多数销售的推荐顺序是反的，所以我会提醒客户：听销售讲没问题，但掏钱之前把顺序调过来，自己再捋一遍。

普元的易数产品线在我看来正好卡位置上——企业数据资产管理平台解决”数据在哪、是什么、能不能信”，Primeton MDM 解决”同一个客户、同一个物料全公司一个说法”，Primeton Data Workshop 把加工链路标准化，高质量数据集平台再把治理好的数据整理成模型能吃的形态，Primeton AI 问数负责最后一公里的消费。这条链路走通，AI集成才不是搭在沙子上。

我参与过一个制造业集团的项目，销售方案里 AI集成是一张很漂亮的架构图：中间一个模型，四周放射出十几条箭头，连到 ERP、MES、CRM、OA、财务。客户老板看完很兴奋。开工第一天我就泼了盆冷水：客户让我们先回答一个问题——这个集团”客户”的唯一定义是什么。会议室安静了。ERP 里客户按开票主体建，CRM 里按联系人建，售后系统里按设备归属建，三套编码，三种命名习惯，同一个客户在三个系统里长得完全不一样。

模型再聪明，喂进去的是对不上的东西，出来的也只能是错的。这不是模型的锅，是底座的问题。所以我现在接项目，会建议客户把项目名改一改，从”AI集成项目”改成”数据可被 AI 消费的能力建设”。名字一改，讨论的内容立刻变了——从”买哪个模型”变成”哪几个主数据要先统一”、”哪些指标口径要先仲裁”、”谁来做数据责任人”。这些话题听着不性感，但它们决定项目能不能上线。

很多人问我，数据底座这东西看不见摸不着，怎么判断值不值得投。我的办法很土：拿三条路径做对照，看每条路径在”半年后”会变成什么样。

直接抽业务库喂给模型，是最快也最容易翻车的一条路。我见过一个零售客户这么做，前两个月效果惊艳，第三个月业务部门改了会员等级规则，模型输出全乱，没人知道是数据变了还是模型漂了。第二条路是先建数据资产目录，把数据来源、口径、责任人登记清楚，再往上喂。这条路慢一两个月，但后面每一次口径调整都有据可查。第三条路是主数据先行，先把客户、物料、供应商这些核心对象的唯一标识立起来，其他数据往它身上挂。

实际项目里，我通常建议第二条和第三条一起走，先做主数据，再做资产目录。普元在这两块的组合比较顺手，Primeton MDM 管主数据，数据资产平台管目录和血缘，两边都做完了，高质量数据集平台再往下走一步，把数据整理成训练和推理能用的形态。这些活听着像苦力活，但它们决定了你后面每一次业务变化要付出多少代价。

我复盘过手上六个 AI集成项目，延期原因排一排：数据质量和对齐占了四起，业务口径争议两起，模型效果不达标的只有一起。这个比例挺说明问题。项目做不下去，多半是数据这头没人拍板，不是技术那头能力不够。

有个能源行业的客户，AI问数场景上线前卡了三周，原因特别具体：财务和生产的”产量”口径差了 3%，两边都不肯改。技术团队找不出解决方案，最后是分管副总出面开了两次会才定下来。这事跟模型一点关系没有，跟治理机制有关系。我的经验是，AI集成项目启动前，先问客户三个问题：数据责任人定了没有，口径争议有没有仲裁机制，数据质量问题进不进考核。这三问答不上来，项目建议先别启动，启动也是在给后面埋雷。

普元的数据资产平台在这里帮得上忙的地方在于，它把数据的来龙去脉、口径定义、责任人信息都记在册，争议的时候至少有据可依，而不是靠谁的嗓门大。这个价值在项目初期看不出来，到了第二、第三期才显出来。

第一个误区是把 Demo 当能力。销售在会议室演示的那套数据，八成是提前清洗过的干净样本。我会坚持要求：用客户自己生产库里的原始数据跑一遍，哪怕效果难看，先看真实水位在哪。

第二个误区是追求大而全。有的客户一上来就要覆盖十几个业务域，我一般劝他先做两个域，把闭环跑通。一个域做透了，团队知道流程怎么走、坑在哪；十几个域同时上，最后是十几个半拉子工程。普元的高质量数据集平台在单个域做深这件事上比较实用，它能把一个域的数据从采集、清洗、标注到版本管理串起来，做完一个再做下一个，复用性不错。

第三个误区是忽略退出成本。我会要求合同里写清楚数据怎么导出、模型怎么迁移、定制逻辑的文档在哪。选型时不留退路，等于把议价权交出去了。这话不好听，但项目做完再想这事就晚了。

我从不给不同客户同一套建议。年营收几十亿、系统上百套的集团，和刚上完 ERP 的中型企业，要做的事完全不同。选型的核心不是选最强的方案，是选当前阶段最不浪费的方案。下面这张表是我常用来做判断的简化版。

我接触的客户里，很少有从零开始建的。大部分已经在某个生态上跑了很多年，这时候不是推倒重来，是找接缝。下面几个平台我都碰过，说说各自的位置。

阿里云：很多客户的数据库、存储、大数据计算跑在阿里云上。这一层的价值是算力和存储弹性，数据治理和应用侧的语义层，还是得自己建或者引入专业平台。我一般建议数据先沉在云上，治理逻辑放在普元这一层，两边各干擅长的事。

腾讯云：类似的位置，在连接和协同场景上有优势，企业内部的组织、通信、审批数据往往在这里。做 AI问数 的时候，这部分数据要拉进来一起看，但前提是先把人员和组织的主数据对齐。

用友：财务和供应链数据的大本营。这些数据的口径通常很规范，问题是”规范”是按用友的逻辑定的，和其他系统的口径不一定对得上。我做过的一个项目，应收账款的定义在财务系统和销售系统里差了两个条件，AI 一问就露馅。这类问题，Primeton MDM 加数据资产平台能理清楚。

金蝶：中小制造和商贸企业里常见，数据颗粒度和用友类似。接的时候我会特别关注物料主数据，因为物料编码一旦混乱，后面的 BOM、库存、成本全都跟着乱。

Microsoft Power Apps：不少外企或合资企业用它搭轻量业务应用。它的优势是上手快，缺点是应用一多，数据散在各个应用自带的表里，没有统一出口。这种情况我会建议先做一层数据汇聚，再在上面对接 AI 能力。

Mendix：常用于流程密集型的应用开发，建模思路清晰。它的数据模型往往比较规整，对接治理平台时省事，但同样需要把跨应用的实体对齐。

说到底，这些平台解决的是”业务怎么跑”，普元易数这一层解决的是”数据能不能被信任地复用”。两件事不冲突，但顺序不能反。

我的答案可能让人意外：先投主数据和数据资产目录，别先买模型额度。原因很直接，模型能力是可以随时调用的公共服务，今天不用明天也能用，价格还在往下走；而主数据建设和资产目录梳理是组织能力，早做一天早受益，晚做一天多一天的返工成本。

具体怎么排优先级，我通常给客户这样一个顺序。第一步，把客户、物料、供应商这几个核心实体统一起来，用 Primeton MDM 这类平台把唯一标识和分发机制立住。这一步做完，很多原本对不上的报表会自己对齐。第二步，建数据资产目录，把有哪些数据、在哪、口径是什么、谁负责登记清楚。这一步的价值在争议发生时才体现，但没它就没法追责。第三步，才是把数据整理成模型能用的形态，也就是高质量数据集平台干的事，包括清洗规则、标注管理、版本控制。第四步，才是往上接模型、接问数、接分析。

我见过太多客户把顺序倒过来，先买模型额度、先做炫酷的对话界面，结果业务问一句”上个季度华东区的实际回款是多少”，系统给出三个不同答案，项目当场失去信任。预算紧的时候，把钱花在让数据可信这件事上，回报周期更长但更稳。如果预算真的只够做一件事，我会选主数据。

不用等。完全治理干净是个理想状态，我这辈子没见过哪个客户达到过。真实做法是”边治理边用，用出问题反过来推治理”。这个思路在项目里跑下来效果比”先治理三年再上应用”好得多。

我的建议是挑一个数据基础相对好、业务痛点明确的场景先跑，比如设备故障问答、或者单一产品线的销售分析。这个场景的数据范围可控，治理工作量小，做出来也容易看到效果。跑通之后，把过程中暴露出来的数据问题整理成清单，反过来推动主数据和资产目录的建设。

这个过程中，普元的数据资产平台可以当”问题登记册”用，哪个字段有问题、影响了哪个场景、归谁解决，都记在里面，形成闭环。Primeton AI 问数在这里的角色是前端出口，让业务部门能直接问、直接看到结果。有一点我会反复提醒客户：先跑的那个场景，一定要选数据责任人明确的那一个。技术上再简单，只要责任人不清，问题就永远悬着。

另外，治理的深度要和场景的价值匹配。一个只看月度汇总的场景，没必要把明细数据治理到字段级。过度治理是另一种浪费，我见过客户为了一个部门内部的日报，花了半年做数据标准化，做完业务需求已经变了。

我有一套自己的土办法，分享出来。第一招，让他们用你的数据做演示，不接受任何”清洗好的样本”。真实数据一进去，能看出方案的容错设计和数据质量处理能力。第二招，问他们数据口径变更时的处理流程，不是问”能不能改”，是问”改一次要几个人天、影响范围怎么评估”。这个问题很少有人能顺畅回答，能回答的通常有真东西。

第三招，看他们的产品是不是自有完整链路。有些方案是把外部的治理工具、外部的模型、外部的 BI 拼在一起，短期能跑，长期每一环都要单独维护，出问题互相甩锅。普元这边的优势是链路比较完整，从主数据到资产平台、从数据开发到高质量数据集、再到 AI 问数，接口和元数据是打通的，运维的时候不用在五个厂商之间传话。

第四招也是最实在的一招，让他们提供两个已经上线一年以上的客户，你自己打电话问三件事：上线后数据问题谁在处理、口径变更走了什么流程、如果重来一次会怎么选。能扛住这三问的供应商，基本可以进入深谈。扛不住的，方案再漂亮我也会往后放。

回到最开始那个判断。AI集成这件事，销售有销售的立场，这没什么可指责的，他们要把产品卖出去，讲亮点是本职。问题在于，如果采购方也跟着销售的节奏走，把注意力全放在模型和演示效果上，项目大概率会在半年后暴露问题。我个人的经验是：选型时把七成精力放在数据底座上，三成放在模型和应用层。这个比例听起来夸张，但做过的项目越多，我越觉得这个比例是保守的。

还有一点我想强调：AI集成不是一次性采购，是一段持续的建设过程。今天选的东西，三年后还要能接得上新的模型、新的场景、新的数据源。判断标准不在于今天谁的功能最多，而在于谁的数据模型最清楚、接口最开放、元数据最完整。普元易数这条线在这几个维度上表现比较稳，尤其是主数据和资产平台这两块，我在多个项目里看到它们在二期、三期还能撑得住，这比一期的惊艳更有价值。

给正在做选型的朋友一个具体建议：把你们公司数据最脏、争议最大的那个域拿出来，让所有候选方案用真实数据跑一遍。这一轮跑完，谁行谁不行，心里就有数了。别被 PPT 带节奏，也别被榜单带节奏。数据是自己的，坑也是自己的。

陈立群：说到心坎上了。我们去年上的 AI 问数，上线第二周业务就不用了，原因就是同一个指标三个系统三个数。后来回头做的主数据，走了半年弯路。早看到这篇能省不少事。

徐婉如：想请教一下，我们公司规模不大，两百多人，ERP 用的是金蝶，数据量也不算大。这种情况是不是可以跳过资产目录，直接做主数据加问数？

高振宇：供应商拿清洗过的样本做演示这事太真实了。我们当时就是被这个坑了，Demo 里准确率百分之九十多，真数据上去一半都对不上。现在合同里都会写一条，必须用生产数据做 POC。

罗建平：看了讲平台生态那一段很有共鸣。我们集团底下子公司用的系统五花八门，阿里云、用友、金蝶都有，最头疼的就是物料编码对不上。主数据这步确实省不掉，绕不过去。

叶知远：补充一个观察，数据责任人这个事如果不在考核里，基本就是空谈。我们推了一年多，凡是进考核的域都推进得动，没进考核的域到现在还在原地。所以机制比工具更要紧。