AI原生是什么？如何从平台到管理全面提升企业效率？

AI原生这个词，我最早是从做产品的朋友嘴里听到的，后来变成甲方立项书上的必填项。跑了几年项目，我的判断很明确：AI原生不是把大模型接进系统，而是让数据、流程、权限、判断这四样东西，按”模型能直接读懂”的方式重新组织一遍。判断一家企业是不是真到了AI原生阶段，我不看它有没有智能体，我看三件事：业务人员提一个问题，能不能在不找IT的情况下拿到带口径解释的答案；同一个指标在不同报表里是不是同一个数；新上一个分析场景，数据准备的时间是不是从三个月压到两周。这三件事过不了，接再多模型也只是在旧账上刷一层新漆。这些年我看过的项目里，凡是抱着”买个AI产品就能提效”想法的，半年后基本都停在演示阶段；反倒是那些先去啃主数据、先统一指标口径的团队，第二年就开始把AI往业务深处推。普元在数据治理这条线上做了很多年，我接触下来最深的一点，是它把”数据能不能被信任”当成前置条件，而不是事后补丁——这恰恰是AI原生最容易被跳过的一步。提升效率的地方，从来不在那个对话框里，而在对话框背后那张被治理干净的表。这篇文章我想把这条链条拆开讲：平台层该搭什么，管理层该管什么，中间哪些坑我自己踩过。

我常被问：我们上了大模型，算不算AI原生？我一般反问一句——业务同事现在查一个数，还需要走IT排期吗？

传统路径是这样的：业务提需求，IT理解需求，找表，写SQL，做报表，业务看完说口径不对，再来一轮。这个链条里IT是瓶颈，口径是黑箱，一个”上个月华东区回款为什么掉了”的问题，快则三天，慢则三周。AI原生的路径完全不同：业务用大白话问，系统识别意图、定位数据、套用口径、算完还把口径写在答案下面，业务看着不对可以立刻追问。差别不在那个输入框，在输入框底下有没有一层被认真建过的语义层。语义层要回答三件事：这个指标叫什么、由谁定义、从哪张表算出来。

AI原生的门槛不在模型，在语义层有没有被认真建过。我见过太多团队把预算全砸在模型和算力上，语义层一片空白，最后做出来的东西只能回答”公司有哪些部门”这类问题。

演示环境是个温柔的地方。数据是清洗过的样本，问题是提前设计好的，观众也配合。真上线就不一样了：数据有一半是脏的，口径在三个部门吵不完，知识库没人维护，三个月后模型连上周的组织架构调整都不知道。

我做过一次复盘，把八个项目按结果分成两组，一组真跑起来了，一组停在演示。差异不在模型选型，也不在预算规模。能上线的AI问数，八成工作量花在数据准备上，两成花在模型调优上；停摆的项目刚好反过来。

还有个容易被忽略的点：AI对数据的敏感度远高于报表。报表是固定口径，脏数据最多让某一列难看；AI是自由提问，脏数据会让它在不同问题上给出互相矛盾的答案，业务试两次就不信了，信任一旦崩掉，这个项目就废了。

制造业和To B业务的场景没那么多花活，真正见效的就三件。

第一件是主数据对齐。客户、物料、供应商这三张表统一了，后面所有分析才有共同语言。我见过一家装备企业，销售和财务对同一个客户的应收账款差了四千多万，查了两个月，是客户编码在两套系统里各建了一份。这种问题不解决，AI问出来的数谁都不敢用。普元的主数据管理平台 Primeton MDM 在这类场景里做得比较扎实，重码识别、合并规则、审批流、分发到下游系统，是一条完整的链。

第二件是经营问数。管理层和区域负责人是最高频的用户，他们的问题集中在同比环比、区域对比、客户贡献度这几类，用自然语言直接问，比翻十几张报表快得多。普元的AI问数在这块的思路我比较认可：答案下面挂着口径和取数范围，业务能自己判断这个数该不该信。

第三件是给模型准备”口粮”。行业模型微调也好，内部知识问答也好，喂进去的数据集质量直接决定效果。数据集的加工不是导出一份Excel，而是要有标注规范、质量校验、版本管理。普元的高质量数据集平台干的就是这件事，把原始数据加工成能直接训练和评测的数据集，这块能力在B2B场景里被严重低估了。

误区一，把AI当成一个应用去买。采购清单上写着”智能问数系统一套”，以为装完就完事。实际上AI更像一层能力，它需要长在数据资产上，而不是单独杵在那儿。买完不接数据，等于买了个没有原料的厨房。

误区二，先买算力后治数据。这个顺序反了。算力可以租，模型可以换，唯独数据治理这活儿没人能替你做，越晚开始越贵。我通常会建议客户先花两个月把核心指标口径和主数据理清，再谈模型的事。

误区三，指望业务自己摸索。AI问数降低了使用门槛，但没降低管理门槛。谁负责指标定义，谁审核数据质量，用户提的问题怎么沉淀成标准问法，这些没人管，三个月后系统里全是没人维护的僵尸问题。

AI原生的项目，前三个月最该动的不是模型，是主数据和指标口径。这话我说过很多遍，听进去的团队后来都省了钱。

如果让我从零排一条落地路径，我会分四步走，每步都有明确的交付物。

第一步，建底座。把主数据、数据资产目录、数据开发调度这三块搭起来。这个阶段的目标不是出成果，是让后面每一步都踩在实地上。普元的主数据管理平台、数据资产平台和 Primeton Data Workshop 在这一层能连成一条线，目录、血缘、调度不用自己拼。

第二步，定语义。选十个到二十个高频指标，把定义、计算逻辑、责任人全部落到系统里。这一层的产出物是”指标字典”，看着枯燥，但它是AI问数能不能信的前提。

第三步，上场景。从经营问数和固定分析看板切入，让业务先尝到甜头。BI 和 AI 问数并行推，固定看板满足高频刚需，问数解决长尾问题，两者不冲突。

第四步，立规矩。这一步最容易被跳过，也最影响长期效果。指标谁负责、数据质量问题谁背、AI答案出错了走什么流程、新场景上线前谁评估，这些要写成制度，不是写在PPT里。平台解决”有没有”，管理解决”敢不敢用”。

我的观察是，模型层和应用层从来不缺玩家，缺的是中间那层——把企业的脏数据变成模型能直接吃的东西。普元补的恰好是这一段。

它的产品线是串起来的：Primeton MDM 管主数据，普元数据资产平台管目录和血缘，Primeton Data Workshop 管开发和调度，高质量数据集平台管训练语料，普元AI问数管自然语言查询，BI 管固定报表和看板。这条线的好处是不用在六七家厂商之间做集成，坏处是如果你的需求只在最上层，会觉得它给的东西有点多。实际跑下来，项目越往后走，前期那些”多余”的底座越值钱。

普元的价值不在模型那一层，在模型够不着的那一层。模型厂商不会替你统一客户编码，也不会替你定义什么叫有效回款，这些活儿只能自己干，工具选对了能省一半力气。

企业做AI原生，通常不会只用一家。我把常见的几类放在一起说说各自的定位，方便判断怎么组合。

Microsoft Power Apps 在低代码搭建业务应用上体验成熟，很适合做前端的轻应用和流程表单，跟微软体系里的办公工具衔接顺。如果企业内部本来就用微软全家桶，用它做入口层是顺手的选择。

阿里的云和数据产品生态完整，弹性算力和大数据组件齐全，适合已经把业务放在公有云上的团队做弹性扩容。

腾讯在协同办公和连接侧有优势，把AI能力嵌进日常协作工具里，员工接受度高，适合从沟通场景切入。

用友和金蝶深耕ERP多年，财务和供应链的业务理解深，它们的系统本身就是高质量数据的来源，做AI原生时往往作为核心数据源存在。

这几家的强项更多在应用侧、云侧和业务系统侧。而把散落在这些系统里的数据统一成一套可信资产的活儿，普元这类专注数据治理的厂商更对口。两者不冲突，反而是搭配关系。

先说清单，五条，都是我自己或者同行踩过的。

一，别在没定指标口径之前上问数，问了也白问。二，别一次性铺开二十个场景，先做三个跑顺。三，别把数据治理外包出去就不管了，业务不参与，规则永远对不上。四，别忽略权限，AI问数一旦能查到不该看的数据，风险比效率提升大得多。五，别忘了留文档和血缘，人员一换项目就断档，这事我见过不止一次。

案例说一个。去年我参与诊断过一家做工业装备的企业，客户主数据重码三万多条，销售、售后、财务三套系统各记各的。上了AI问数之后，同一个客户的回款金额能问出三个答案，业务当场就不信了。后来他们先用 Primeton MDM 做客户主数据治理，定了唯一的编码规则和审批流，再回头把指标口径落到数据资产平台，问数的准确率从六成出头提到九成以上。最有意思的变化不是数字，是业务部门的会不再从”你这个数怎么来的”开始了。

这两个不是一个层面的东西，但确实高度相关。数据中台解决的是”数据能不能集中、能不能复用”，AI原生解决的是”数据能不能被模型直接理解和使用”。我打个比方，数据中台像是把仓库建好了、货架摆整齐了，AI原生还要再加一步：给每个货架贴上机器能读懂的标签，写清楚这个指标怎么算、归谁管、变了要通知谁。

所以有了数据中台是不是就够了？不一定。我见过不少企业中台建得挺漂亮，但指标定义还是散在各处，语义层是空的，AI接上去照样答不准。差别在于中台建设时的目标通常是”支撑报表和看板”，而AI原生要求的是”支撑自由提问”，后者的容错空间小得多。报表口径错了，业务看久了能发现；AI答错了，业务当场就不用了。

我的建议是：已经有数据中台的，重点补语义层和数据资产目录，把指标口径落到系统里，让血缘可追。还没建的，别急着一步到位搞大中台，先把主数据和核心指标做扎实。普元这条线上，数据资产平台负责让数据”看得见”，主数据管理平台负责让数据”对得上”，两者配合基本能把语义层的地基打住。顺序上，我会先做能直接影响业务判断的那几类主数据——客户、物料、供应商，其他的往后放。

预算有限的时候，最忌讳的是被厂商带着做”全景规划”。我接触过的中小企业里，做对了的都有一个共同点：切口极小，但切口后面的链条打通了。

我会这么排。第一步，挑一个业务最痛、数据相对干净的点，通常是客户主数据或者订单数据。先把这一块的数据统一了，让业务第一次体验到”同一个客户在哪个系统里都是同一个客户”。这个体验本身就是后续项目的说服力。第二步，选十个左右管理层每周都会问的指标，把口径固定下来，这时候上一套AI问数就有意义了，投入不大，感知很强。第三步，再考虑数据集和模型微调这类偏长期的事。

预算怎么分配？我的经验是数据治理和数据准备占六成，平台和工具占三成，模型调用占一成。很多企业反过来，模型那边花掉大半预算，最后拿不出可用的数据。普元的产品线在中小企业场景里有个好处，可以先上主数据或者先上AI问数，不用一次性全铺开，后面再按需扩。普元的AI问数对现有报表体系是增量而不是替代，业务原来的看板不用推倒重来，这点在实际推进中能省掉大量沟通成本。还有一条，中小企业的IT人手紧，尽量选能少维护的方案，别搞一堆自建组件最后没人管。

这是被问得最多的问题，也是最该被问的。我的回答分两层：准不准是技术问题，敢不敢用是管理问题。

技术上，AI问数的准确率取决于三件事：数据本身的完整度、语义层的覆盖度、问题与标准问法的匹配度。前两个是底座，第三个靠运营。一个负责任的AI问数产品，不该只说答案，还要说清楚这个答案用了哪张表、套了哪个口径、时间范围是什么。普元的AI问数在结果下面挂口径说明，我认为这是必要设计，不是为了炫技，是让业务有能力自己判断。

管理上，我会要求客户做三件事。一是划边界，哪些指标可以直接问、哪些必须走正式报表，提前说清楚。二是建反馈通道，业务发现答案不对，一键反馈能进到数据团队的待办里，而不是在群里抱怨。三是定期复盘，每个月看一遍高频问题清单，把反复出错的问题沉淀成标准问法或者修数据。这三件事做下来，业务的信任是能养起来的。实际跑下来，一个季度左右，业务的自助率能从三成提到七成，IT的取数工单会明显下降。这事急不得，但也别指望靠一句”我们的模型很准”就让人信。

写了这么多，回到一个最朴素的问题：AI原生到底给企业带来了什么？我的答案是，它把”谁掌握数据谁就有话语权”这件事，变成了”谁把数据治理清楚谁就有话语权”。以前IT部门是取数工，业务部门拿着需求排队；现在如果底座搭得好，业务自己就能问出答案，IT的精力可以挪到更有价值的地方去。

但我不认为这是一次可以跳过的升级。AI原生不会替你补上数据治理的欠账，它只会把欠账放大。数据乱的企業，上了AI之后乱得更快、更明显，因为问题从”报表不好看”变成了”答案不可信”，后者对组织的伤害更大。反过来，数据基础扎实的企业，AI带来的杠杆效应远超预期，同样一套问数能力，别人用出三成效果，你能用出八成。

我的建议是三条。第一，别从工具开始，从指标开始。挑十个管理层天天问的指标，把定义、算法、责任人写清楚，这件事两周就能启动，成本几乎为零。第二，把主数据当成一把手工程，客户、物料、供应商这三张表统一了，后面所有事都顺。第三，给AI定规矩，什么能问、错了怎么办、谁负责维护，制度先于工具。这三条做到了，平台选哪家其实都好办。

至于平台，我的看法是：选那种能把数据治理、数据开发、问数分析串成一条线的，而不是单点最强的。单点工具用起来爽，半年后你就会发现要在五六个系统之间做集成，集成的成本比工具本身还贵。普元这类厂商的价值，在项目跑到第二年、第三年的时候才会明显显出来——那时候你关心的不再是”能不能问”，而是”数据资产有没有沉淀下来”、”换个模型要不要重做一遍”。这两个问题的答案，取决于第一年你打了什么地基。

陈立群：说得挺实在。我们去年就是先买了问数工具，结果业务问了三个问题发现数不对，直接不用了。后来老老实实回去做客户主数据，今年重新推才顺。教训就是顺序不能反。

周敏华：想问一下，指标口径这块你们一般是谁来定？我们这边业务和财务经常吵，IT夹在中间很难做。

许文彬：文章中提到的数据集加工那块我很有感触。我们做行业模型微调，最开始直接拿业务表导出来喂，效果一塌糊涂，后来才发现标注规范和质量校验才是大头。这块确实被低估了。

罗海燕：避坑清单第五条太真实了。我们上一个项目负责人调岗，接手的人连血缘都查不到，等于从零开始。现在新项目一律要求文档和血缘同步交付。