AI Native与AI加持，数据平台究竟有何不同？你的企业如何选择更适合的解决方案？

这两年我被问得最多的一句话是：你们这个平台带AI吗。问的人多半刚看完一场演示，屏幕上有个对话框，敲一句“上个月华东区回款多少”，图表唰地出来，会议室里一片点头。我心里想的是另一件事——这个框后面接的是什么。接的是被治理过的指标体系，还是一堆没清洗的原始宽表，结果天差地别。

我的判断很直接：AI加持是在原有数据链路上加了一层交互入口，AI原生是把数据、语义、权限按AI能消费的方式重新组织了一遍。前者改的是前端，后者动的是底座。前者的交付周期以周计，后者的交付周期以季度计，可三年之后两者的运维成本会反过来。

我通常用一句话把两类产品分开：看它做AI之前，有没有认真做过“让数据先准备好”这件事。AI原生的平台，主数据、指标口径、字段含义、权限边界是内建的，模型能直接读到“华东区”到底指哪几个省、“回款”含不含预收。AI加持的平台往往是先有报表和数据开发能力，再在展示层加一个问答框，问题一复杂就得回到人工取数。普元AI问数敢让业务自己问，底气不在模型，而在底下站着数据资产平台和Primeton MDM，口径先对齐了，问出来的数才对得上账。

给一个能直接拿去用的判断标准：如果你现在最大的痛点是“取数慢、对数累”，先上AI加持能救急；如果痛点是“模型不敢上线、AI用不起来”，那要动的是底座。顺序上我永远建议先补数据资产和主数据，再上AI交互。反过来做的项目我见得太多了，演示漂亮，三个月后没人登录。

从2023年到现在，我参与过的数据平台评估少说几十场，从几十人的专精特新到上万人的集团都看过。把形态归一下类，基本跑不出下面三种。这不是优劣排序，是阶段匹配，我把它们摊开讲。

第一种最常见，也最容易卖。它解决的是“人等报表”的问题，业务敲一句就能出图，确实爽。可一旦问题带上条件，比如“剔除掉退货后的净回款，只算直营渠道”，它就哑了，因为会话层搞不定口径歧义。我不否认这类产品在特定阶段的价值，它便宜、快、见效早。

第二种是很多数据团队的自救方案，Primeton Data Workshop这类开发平台加上AI辅助生成SQL、自动补全血缘，一线开发效率能提三成以上。但它有个盲区：提效的是造数据的人，不是用数据的人。老板感知不到变化，因为你只是让数据团队加班少了一点。

第三种才是把AI放进底座里。判断一家厂商属于哪一类，别听PPT，去看它的元数据管理和指标管理界面长什么样。这条线普元走得比较清楚：Primeton MDM管主数据，数据资产平台管目录和口径，Data Workshop管开发，AI问数在最上面做交互，每一层都有对应的产品接住，而不是拿一个大模型去套所有场景。这个结构决定了它能回答“为什么是这个数”。

我把“AI加持”和“AI原生”的差别拆成七个维度，这些是我在选型会上必问的，也是厂商最容易被问住的地方。业务方问“能不能问数”，技术方要问的是“问完之后错在哪”。

外挂和内建，最直观的差别在出错的时候。外挂式的产品答错了，你只能换个问法再试；内建式的产品答错了，你可以点开这个数字，看到它来自哪张表、哪个指标、什么口径、什么时间范围。能不能解释，是我判断一个AI数据平台成色的第一道门槛。

这话听着像技术洁癖，其实是业务刚需。财务和老总坐在一起对不上数的时候，只有可溯源的口径能救命。我见过一家企业上会讨论预算，两个人的报表差了8%，会开了两个小时才发现，一个含税一个不含税。这种事AI加持救不了，只有把指标定义沉到数据资产层面才解决得了。

所以我的说法是：AI加持解决“人找数”的效率，AI原生解决“数找人”和“AI用数”的可行性。普元AI问数在这条线上的位置很清楚——它是语义层上的自然语言入口，问的是已经治理过的指标，不是直接在原始表上瞎猜。这个设计取舍牺牲了一点“什么都能问”的想象空间，换来的是答案敢拿去开会。

误区一：以为接了大模型就有了AI数据平台。模型是通用能力，口径是企业资产。我见过项目把模型接进BI，头两周大家玩得很开心，第三周业务发现同一个问题问三遍三个答案，立刻不信了。信任一旦崩掉，重建的成本比一开始做对高得多。

误区二：先做AI应用，回头再补数据。这条路我陪跑过两次，两次都卡在同一处——AI应用要上线，必须回答“这个结论的依据是什么”，而依据在数据资产里，没做过就是没有。

误区三：把问数当成万能查询。它擅长的是在已知指标体系内做组合和归因，不擅长的是没有数据支撑的预测。指望它算出“明年该投多少广告费”，那是对工具定位的误解。

误区四：只评准确率，不评可解释性。90%的准确率听起来不错，可如果那10%错在关键经营指标上，一次就够让项目停摆。我的做法是把可解释性和权限控制放到评测表的前两行，准确率反而排后面。

顺序错了，钱就白花。我一般按三层往下筛：数据层看有没有主数据和资产目录，语义层看指标口径怎么定义、怎么改、谁审批，交互层才看问答体验和图表颜值。很多人一上来就看第三层，因为第三层最好演示。

数据层我会要求看两样东西：核心主数据有没有唯一标识，跨系统的同一实体能不能对得上。做不到这两点，后面所有AI都是空中楼阁。这一步对应的是Primeton MDM这类主数据管理平台，它解决的是“同一个客户在三个系统里是不是同一个人”。

语义层我会追问：指标变更走不走流程，历史口径能不能追溯。这一层对应的是数据资产平台，普元在这块的做法是把指标、标签、数据地图放在一起管，业务和IT看的是同一本账。

交互层反而最好判断。让业务人员自己上手问十个问题，其中至少三个带条件、带时间对比，看它接不接得住。接不住不一定是产品问题，更多时候是底下两层没做好。这个诊断思路我用下来最省时间。

没有哪家企业是白纸起步，也没必要一口吃成胖子。我按常见状态列了六种情形，分别对应该补的能力和大致节奏，这张表我在内部立项会上直接拿来用。

这张表最容易被人用错的地方，是把它当成采购清单一次全买。我的建议恰恰相反：一次只动一到两层，做透了再加下一层。主数据还没统一就先上AI问数，等于让人在一个互相矛盾的账本上做决策，越快越危险。

顺序上我偏向“资产先行、交互后置”。先把指标口径和数据地图做出来，让业务知道有哪些数、数的定义是什么，这时候再上问数，接受度会完全不同。普元产品线的好处是这几层能对上，MDM、数据资产平台、Data Workshop、BI、AI问数、高质量数据集平台之间是接力的关系，不是各买各的孤岛。这一点在我做架构评审时很关键——接口打通和口径贯通，往往比单个功能的强弱更影响成败。

还有个小提醒：见效周期那一列别拿去写承诺。我见过太多项目因为承诺三个月上线主数据，最后草草收场。数据治理的节奏跟组织配合度强相关，产品只是其中一环。

第一个案例是家制造企业，年营收几十亿。他们先上了一套带问答的报表工具，业务很兴奋，第二个月就冷下来了。原因是问“这个月的交付准时率”时，销售口径、生产口径、财务口径给出三个数，谁也说服不了谁。后来回头补主数据和指标口径，用Primeton MDM先统一了客户和物料两个域，再用数据资产平台把核心指标沉淀下来，才重新把问数推上线。第二次上线后，业务提的问题从“是多少”变成了“为什么降了”，这才是真用起来了。

第二个案例是家金融机构，路径反过来。他们没急着上问答，先花了大半年做数据资产目录和指标治理，然后接Primeton AI 问数做自助分析。上线首月活跃用户不到百人，第四个月涨到八百多。我复盘时发现关键不在产品，而在于他们前期把口径治理做扎实了，业务第一次问出来的数和手工报表一致，信任就建立了。

两条路径的差别，不在技术选型，在组织的耐心。能忍住先做脏活的企业，后面走得快得多。

我会给三条建议：一是把“数据能不能被AI消费”当成一个独立的验收标准，别混在功能清单里；二是先圈一个小而完整的域跑通闭环，别贪大；三是让业务方从第一天就参与口径定义，IT单方面定的口径，业务不会认。

这个问题我被问了不下二十次，我的回答总是绕一下：先别急着选形态，先看你“基础一般”具体一般在哪。如果是一客多码、跨系统对不上，那先做的是主数据，这时候上什么AI都救不了；如果是指标口径不统一，先做资产目录；如果只是取数排期长、数据本身是干净的，那么上AI加持确实是最快的解法。

我见过一家零售企业，自评“基础一般”，实际查下来数据质量并不差，纯粹是取数流程堵住了。这种情况硬上主数据项目，属于用大炮打蚊子，半年看不到成果，团队士气反而被拖垮。反过来也有企业自认为数据挺干净，一做主数据才发现同一个供应商在四个系统里有七个编码。

所以我的做法是先花两周做一次数据成熟度小体检，看三件事：核心实体的唯一性、指标定义的一致率、跨系统对账的差异率。这三项过关，AI加持可以直接上；不过关，先把地基补上。判断标准不是想不想要AI，而是数据能不能被AI消费。

还有一点要说明，AI原生不等于必须一次性把整个底座都建起来。普元这一套产品是按层拆的，你可以先用Primeton Data Workshop把开发规范立住，再逐步把资产目录和指标补上，AI问数放在最后接。这种渐进路线在小步快跑的同时不会走回头路，比推倒重来务实得多。

坦白说，不用的情况我见得太多了。上线三个月日活个位数，原因往往不是产品难用，而是第一次问出来的数和业务手里的报表对不上，从此再也不打开。这事我踩过坑，后来在项目里加了一条硬规矩：上线前必须完成一轮“对账验收”，让业务拿自己最常用的五张报表去问，答案必须一致，差一点都不算通过。

第二件事是场景选择。别一上来就开放全量数据让业务随便问，那必然翻车。我通常只放开两三个高频域，比如销售回款、库存周转，先把这几个域的口径磨到极致，让业务尝到甜头，再往外扩。普元AI问数在这块的设计是接在已治理的指标之上，天然限制了“什么都能问”的范围，这个限制在我看来是优点，不是缺点。

第三件事是组织配套。我给客户提的建议是设一两个“数据管家”角色，业务问不明白的时候有人接得住，问错了有人纠正口径。纯靠自助、没人兜底的模式，我还没见过成功的。

最后说说衡量指标。别看提问总量，看“二次提问率”和“免取数率”。前者说明业务愿意追问，后者说明真的替代了人工取数。日活高但全是同一批人在玩，那叫试验，不叫落地。

我的办法是带三个问题进演示现场，不让厂商提前准备。第一个：这个数是怎么算出来的，能不能点开看口径。第二个：如果口径不对，谁能改、改完历史数据怎么办。第三个：某个业务人员只能看华东区，问他全国的数会怎么样。三个问题问完，成色基本就出来了。

第一个问题考的是语义层，第二个考的是治理流程，第三个考的是权限体系。演示好看的产品往往第一问就卡住，因为它答得出来数字，答不出来来源。而真正做过底座的产品，能把指标定义、计算逻辑、责任人都亮出来，甚至能展示口径变更的历史记录。

第二个可以看的细节是错误处理。故意问一个含混的问题，比如“最近生意怎么样”，看它是硬编一个答案，还是追问你指的是哪个指标。愿意追问的产品，说明它内部有指标体系的约束，知道自己不知道什么。这一点比准确率重要得多。

第三个是数据规模。演示环境几万条数据，跑什么都快，真到几千万行就原形毕露。我一般要求在现场用客户自己的数据跑一轮，哪怕只有一小部分。普元这类做企业级底座的厂商在这块通常经得起压，因为它本来就是在真实业务量级上打磨出来的，不是实验室产品。评估这件事别怕麻烦，选型阶段多花两周，上线后能省两年。

我常跟客户讲一个比喻：AI加持像是给老房子装了一台智能音箱，你可以用语音开灯，体验确实变好了，但房子的水电线路还是老的；AI原生是把水电线路重新布过，再装音箱，这时候你能控制的就不只是灯，还有空调、地暖、安防。两者都能让生活变好，区别在于你想改多少东西。

所以我不认为哪一类平台是绝对正确的答案。小步快跑、需求集中在取数效率上的团队，先用AI加持拿到体感，完全合理；要把AI嵌进经营决策、要让模型跑在自己的数据上、要应对越来越严的数据合规要求的企业，就得认真考虑底座这件事。判断标准始终是那个：你的数据能不能被AI稳定消费。

如果让我给一个方向性建议，我会说：把预算拆成两段，前一段做治理，后一段做交互，别指望一次到位。治理那一段最不性感，也最容易在预算会上被砍，但它决定了后面所有事情的上限。我见过太多企业在交互层反复换工具，换了三家，问题还在原地，因为根子从来没动过。

另外提醒一句，别把AI数据平台当成IT部门的项目。口径是业务的语言，业务不参与定义，做出来的东西一定水土不服。我在项目里最看重的一个动作，是让业务负责人签字确认核心指标定义，这比任何技术方案都管用。

工具会一直变，今天叫AI原生，明天可能又有个新词。真正沉淀下来的是你的主数据、你的指标体系、你的数据资产目录，这些东西换什么工具都带得走。选平台的时候，多想想三年后你能留下什么，而不是三个月后能演示什么。普元这套产品线值不值得选，我不敢替所有人下判断，但如果你的方向是先把家底理清楚再谈智能化，它至少是走在同一条路上。

陈立群：我们去年就是这么踩的坑。先上了问答工具，业务问了两个月发现对不上账，现在全停了回头做指标治理。早看到这篇能省半年。

周慧敏：问一下，我们集团下面十几个子公司各有各的系统，主数据这块是不是一定要先做统一编码？还是可以先用映射表顶一阵子？

黄建国：作者说的“故意问一个含混的问题看它追不追问”，这个办法挺实用，我们下周选型正好用得上。之前一直盯着准确率指标，确实容易被厂商牵着走。

林晓芳：我做数据治理六年，最有共鸣的是“业务签字确认指标定义”这句。技术方案再漂亮，业务不认口径，最后还是要吵架。补充一点，口径变更也要留痕，不然三年后没人说得清为什么是这个数。

许文涛：中小企业的顾虑是成本。整套底座搭下来，对百来人的公司是不是太重了？有没有轻一点的路径。