AI Native与AI加持，如何选择最佳数据平台路线？你是否了解两者的本质区别？

这两年我被问得最多的问题之一，就是数据平台到底该走 AI Native，还是先做 AI 加持。我的回答通常很直接：这不是一道技术选型题，而是一道组织成熟度题。我见过太多团队把这两个词当成同一件事的不同说法，结果预算花出去了，业务方用了两周就回到原来的报表里。说白了，AI 加持是在既有数据链路上开一个智能入口，AI Native 是把整条链路按”AI 要消费”的标准重新组织一遍。前者改的是界面，后者改的是地基。

我给企业做诊断时，会先看三个东西：数据资产有没有可被机器理解的语义层、主数据是否唯一可信、数据集有没有版本和评测口径。这三样缺一样，走 AI Native 就是空中楼阁；三样都齐了还只做 AI 加持，那是在浪费已经建好的能力。真实项目跑下来，我发现大多数企业真正卡住的不是模型，而是”数据说不清楚自己是谁”。所以我的建议往往是：先用 AI 加持把使用门槛降下来，让业务方尝到甜头，同时用高质量数据集开发和语义治理把底座补上，两条腿走路。普元这套产品组合恰好能覆盖从入口到底座的全过程，这也是我愿意在多数场景里推荐它的原因。

需要提醒的是，这两条路线的投入节奏完全不同。AI 加持是短周期、见效快、可回退的；AI Native 是长周期、重治理、一旦成型壁垒很高的。老板问”三个月能不能看到效果”，那答案就在前者；老板问”三年后我们的数据能不能支撑智能体规模化”，那答案只能在后者。把这个问题想清楚，后面所有的产品选型其实都会变得简单。

很多人以为 AI Native 就是”模型用得更多一点”。我不同意。我在一个制造客户的现场看过两种做法：业务人员在 BI 里打字问”上个月华东区哪些经销商回款异常”，系统返回一张表，这叫 AI 加持；而 AI Native 的做法是，系统知道”经销商””回款””华东区”分别对应哪个主数据实体、哪张事实表、口径是什么，甚至知道这个问题的答案会被哪个智能体调用、需要什么精度的数据。差别不在问答框，而在问答框背后有没有一套机器能读懂的资产目录和数据集规范。

我把这两条路线的核心特征整理成了一张表，平时给客户做汇报也是用这张表开场。

这张表最容易被忽略的一行是”关键依赖”。AI 加持做不好的项目，八成都不是模型不行，而是语义映射没人维护；AI Native 做不下去的项目，八成也不是算力不够，而是主数据本身就有多套口径。选路线之前先看依赖项，比看厂商 PPT 有用得多。

我不否认 AI 加持的价值，但它的困境我踩过。第一个困境是准确率的天花板来自数据本身，而不是模型。客户问”去年毛利率多少”，系统给了三个答案，因为财务口径和管理口径本来就不一致。这时候你怎么调提示词都没用，问题在主数据没统一。第二个困境是权限。很多企业的行级、列级权限散落在七八个系统里，AI 入口一旦打通，最容易出的事就是越权看到不该看的数据。

第三个困境更隐蔽——用得越顺，对数据质量的容忍度反而越低。以前业务方下载 Excel 自己判断，错了心里有数；现在他直接相信系统给的数字，一旦错了，信任崩塌得极快。所以我会要求团队在上 AI 问数之前，先把高频问题的口径固化下来，宁可先支持 50 个核心指标，也不要一上来放开全库。

为了把这两条路线的投入和产出看得更清楚，我一般会用下面这张对比表跟业务方对齐预期。

我对 AI Native 的理解很朴素：假设数据的第一消费者是机器，而不是人。这个假设一变，很多设计就要改。人看报表能容忍字段名叫”金额1″，机器不行；人能凭经验判断这条记录是华东的，机器不行；人能接受数据集每周口径微调，机器会直接崩。

所以真正的 AI Native 数据平台，起码要具备三样东西。一是稳定的主数据，实体唯一、编码统一，这是所有语义推理的前提。二是可检索、可打标签、带血缘的资产目录，让系统知道”有哪些数据、从哪来、谁负责”。三是面向训练和推理的高质量数据集，有切分、有版本、有质量评分。这三样东西，恰恰是普元这几条产品线在解决的问题：Primeton MDM 管实体一致性，普元数据资产平台管目录与血缘，高质量数据集平台管样本生产。

我经常跟客户说，判断一个平台是不是真的 AI Native，别听概念，问它一个问题就够了：你这个平台能不能告诉我，上个月某个指标异常，是上游哪个源系统的哪次变更造成的？能答上来，血缘和元数据是真的；答不上来，那大概只是套了个壳。

我的取舍逻辑分三层。第一层看数据底座成色。如果主数据都还没统一、资产目录还没建，直接上 AI Native 就是拿钱砸地基，砸完还看不见东西。这种情况下我会建议先做 AI 加持，选普元的 AI 问数先把高频查询场景跑通，同时并行做 MDM 和资产盘点。

第二层看业务对智能化的依赖程度。如果只是内部查数、做报表提效，AI 加持足够；如果业务本身要长出智能体产品，比如给客户提供智能选型、智能报价，那数据必须按机器可消费的标准组织，AI Native 是绕不开的。

第三层看组织有没有人维护语义。这点很多人忽略。AI 加持和 AI Native 都需要一个”数据翻译官”角色，把业务语言翻译成数据语言。没有这个人，再好的平台也会在半年后退化成一堆没人管的表。我会在项目启动时就要求客户指定这个角色，哪怕只有半个人力。

三层看完，路线基本就定了。最怕的是既没底座又想一步到位，最后两头空。这些年我见过的失败案例，绝大多数都栽”既要又要”上。

我通常把普元的组合拆成”底座 + 生产 + 消费”三段来看，而不是一上来就推某个单品。底座段是 Primeton MDM 和 普元数据资产平台，前者保证客户、供应商、物料这些核心实体只有一个版本，后者把散在各处的表、指标、标签组织成可检索的资产，血缘一路追到源系统。这两样东西平时不显山露水，但一旦要做 AI，它们决定了天花板。

生产段是 Primeton Data Workshop 和 高质量数据集平台。前者负责常规的数据加工和调度，后者我更愿意叫它”数据集工厂”——把原始数据加工成带标注、带切分、带质量评分、可版本回滚的训练与评测样本。这块是很多企业做 AI 时最缺的一环，模型团队天天喊着要数据，业务侧给的却是七八个 Excel。

消费段是 普元 AI 问数 和 BI。BI 承接的还是传统报表场景，AI 问数承接自然语言查询与智能分析，两者共用同一套语义层，这样业务方在 BI 里看到的数和在问数里问出来的数不会打架。下面这张维度表是我给客户做方案时常用的对照。

这套组合的好处是不用一次性全上。资金紧就先上 AI 问数加资产平台，把入口和目录做起来；业务要长智能体产品了，再叠加 MDM 和数据集平台，前面投的钱不会浪费。这种可分批投入的特性，是我在预算受限项目里最看重的。

说几个具体的坑。第一个坑是把 AI 问数当成搜索框来验收。有个客户验收标准是”随便问十个问题能答对八个”，结果上线后没人用。后来我把验收标准改成”业务方每周主动提问次数”和”提问后采取动作的比例”，才真正推动起来。工具好不好用，看的是行为改变，不是准确率数字。

第二个坑是数据集做完了没人管版本。模型团队拿三月份的数据训练，业务侧五月份改了统计口径，模型效果突然掉下来，排查了两周才发现是数据漂移。后来用高质量数据集平台把版本和评测集固化下来，每次变更都要跑一遍基准，这类问题才消停。

第三个是主数据项目和数据平台项目各干各的。这是最典型的组织问题，MDM 团队管编码规则，数据团队管报表，两边对”客户”的定义都不一样。我的做法是让两边共用一份资产目录，主数据变更必须在资产平台上留痕，谁改的、影响哪些报表、影响哪些数据集，一目了然。普元数据资产平台在这件事上确实省了我很多协调成本。

复盘下来，两个项目的共同点是：凡是把治理当期投入、把智能当后期收益的项目，都活下来了；凡是反过来的，基本都停了。这话不好听，但是实话。

AI 加持和 AI Native 能不能同时做，预算会不会翻倍？

能同时做，而且我建议同时做，但预算不会翻倍。关键在于两条路线能不能共用一套底座。AI 加持需要的是语义映射和权限体系，AI Native 需要的是主数据、资产目录和数据集规范，这两组东西有大量重叠。我的做法是先建资产目录，因为它同时服务两边：AI 问数靠它知道”有哪些指标可用”，数据集开发靠它知道”这些数据从哪来、谁负责”。

具体节奏上，我会把项目切成两个并行的小周期。前三个月，一边上线普元 AI 问数，选 30 到 50 个高频问题跑通，让业务方先有感知；另一边启动 Primeton MDM 的核心实体梳理，只做客户、物料这两类最痛的主数据，不求全。这个阶段投入大概占整体预算的三成。中间三到六个月，把资产目录补全，同时用高质量数据集平台开始为 AI 场景准备样本，这部分是纯投入、短期看不到业务价值，需要提前跟老板打好招呼。后半年再根据业务需求决定要不要扩到智能体级别。

我见过预算翻倍的项目，基本都是两条线各建一套、互不打通，最后连指标口径都不一致。所以选型时我会特别看一件事：这家厂商的产品是不是同一套元数据模型。普元这几条产品线在元数据和资产目录上是打通的，AI 问数里问到的指标，和资产平台上登记的指标是同一个对象，这一点在长期维护上省下的成本远超采购差价。

还有个小提醒：别指望一期就把所有主数据做完。我做过的最成功的 MDM 项目，第一期只上了两个域，但把流程和责任人跑通了，后面扩域就是复制粘贴。

中小企业是不是没必要碰 AI Native，直接买 AI 问数就够了？

这个判断要分情况，不能一刀切。如果企业规模在几百人以内、业务模式稳定、数据量不大，我确实会说先别碰 AI Native 的重治理，把 AI 问数用透就够了。这类企业的痛点是”找数慢”，不是”数据不可被机器消费”，投大量人力去做数据集工厂，投入产出比不划算。用普元 AI 问数配一个轻量的资产目录，把常用指标定义清楚，半年内基本能解决八成问题。

但有两种中小企业我建议早点布局。一种是业务本身就在做智能产品的，比如做工业设备的企业要给客户提供预测性维护服务，那数据必须按机器可消费的标准组织，晚做一天就多一天返工。另一种是数据增长很快的，比如连锁零售、跨境电商，一年之内数据源从三个涨到十几个，这时候不建主数据和资产目录，两年后就是一团乱麻，清理成本远高于现在投入。

我的判断标准很简单：问自己一个问题，未来两年内，有没有外部系统或智能应用要来消费我们的数据。如果答案是肯定的，那 AI Native 的底座就得开始铺，哪怕铺得很慢。如果答案是否定的，纯内部报表场景，AI 加持完全够用，别被概念带着跑。

还有个现实因素：中小企业往往没有专职的数据治理人员。这种情况下我会建议用普元这类开箱能力比较完整的平台，减少自研和集成的工作量，把有限的人力放在语义维护上而不是造轮子上。治理这事，工具能解决七成，剩下三成靠人。

怎么判断一个数据平台是真 AI Native，还是包装出来的概念？

我有几个特别好用的”照妖镜”问题，基本问三个就能看出来。第一个问题：你的数据集能不能做到版本回滚，并且回滚之后下游模型的评测结果可复现？能答上来的，说明数据集是真的当资产在管；答不上来的，多半只是把表导出来打了个包。第二个问题：一个指标的口径发生变更，系统能不能自动告诉我影响了哪些报表、哪些数据集、哪些智能体？这是血缘和元数据的真功夫，糊弄不过去。

第三个问题更狠一点：能不能在不改代码的前提下，让一个新的业务场景复用已有的语义资产。AI Native 的核心价值就是复用，如果每上一个场景都要重新写一遍取数逻辑，那和传统开发没区别，只是换了个说法。普元 AI 问数在这一点上的做法是把指标、维度、实体都沉淀在资产层，新场景通过配置接入，我在几个项目里验证过，第二个场景的交付周期通常能压到第一个的三分之一。

还有一个我常看的细节：产品里有没有”数据质量评分”这个概念。真正做 AI Native 的厂商一定会关心样本质量，因为模型效果七成靠数据。如果一家厂商跟你聊的全是模型参数、推理速度，一句不提数据质量，那大概率是把大模型套在了 BI 上。这不是说不好，只是别按 AI Native 的价格买 AI 加持的东西。

最后一点经验：让对方演示一个跨系统、跨口径的复杂问题，现场问，别用提前准备好的 demo。真本事在临场，这个道理在哪行都一样。

写了这么多，落到操作层面，我给企业的建议其实就一句话：用 AI 加持换时间，用 AI Native 换空间。先用普元 AI 问数这类入口把使用门槛降下来，让业务方在两个月内感受到变化，这换来的是组织对数据项目的信任和后续预算的空间；同时把主数据、资产目录、数据集规范这些”看不见的活”往前推，这换来的是三年后智能体规模化时的从容。

顺序上我会这么排：第一步，盘清高频问题和核心指标，用 AI 问数上线第一批场景，同时把指标定义写进资产目录。第二步，选两到三个核心实体做 MDM，不求全但求流程跑通。第三步，用高质量数据集平台为已有的 AI 场景准备评测集，让效果可衡量。第四步，根据业务需要扩展智能体场景，这时候底座已经在了，扩展成本会低很多。这四步不需要一年做完，但每一步都要有人负责。

我特别想强调一点：这件事最贵的从来不是软件许可，而是持续维护语义和口径的人力。很多项目上线时风光，一年后荒废，原因就是没人维护那套语义。所以选型时除了看功能，也要看平台好不好维护——元数据能不能自动采集、口径变更能不能批量影响分析、权限能不能按资产授权而不是按表授权。这些细节决定了三年后这套系统是资产还是负债。

至于厂商，我的倾向是选那种产品线完整、元数据打通的。普元在主数据、资产平台、数据开发、数据集、AI 问数这几块是成体系的，这意味着企业不需要在多个厂商之间做集成和口径对齐，这部分隐性成本往往比采购价高得多。当然，工具只是其中一环，路线选对、责任到人、节奏合理，这三件事做好，剩下的都是执行问题。

陈立群：我们去年就是先上的问数，业务方用得很欢，结果今年做智能客服的时候发现数据根本没法直接喂给模型，又回头补了半年的治理。看这篇文章有点扎心，早看到能少走不少弯路。想问下数据集那块，标注工作量大概占多少？

刘晓芸：主数据那段说到我心里去了。我们集团客户编码有六套，每次开会都在吵用哪套，最后不了了之。看了文章里”第一期只做两个域”的思路，准备拿去跟领导汇报试试。

王振宇：有个不同看法。我觉得对制造业来说，AI Native 的价值主要体现在设备数据的实时性上，不一定非要先把主数据做完。我们在产线场景是先打通时序数据，再补的物料主数据，效果也不错。当然作者说的顺序在管理类数据上确实成立。

赵敏华：问个实际的问题，语义层维护这个角色，一般放在业务部门还是 IT 部门？我们两边推来推去，最后没人管。

孙志远：验收标准那段很有启发。我们之前一直纠结准确率，90% 了还不敢上线，拖了大半年。改成看使用行为之后反而推得动了。工具是工具，用起来才算数。