2026年元启智脉趋势前瞻：3个方向值得关注

圈里把2026年前后这轮数据与智能深度咬合的变化，起了个有点玄的名字——元启智脉。名字玄，事情一点都不玄。我做了十几年数据项目，今年最大的感受是：数据团队和AI团队不再各干各的，两边开始抢同一批人、同一套口径、同一个预算池。

过去讲数据治理，交付物是报表准确率；今年客户坐下来第一句话往往是”大模型能不能直接读我们的数”。这一句话背后，藏着三件绕不开的事：数据资产得让机器读得懂，数据开发得被自然语言调得动，喂给模型的数据集得挂着质量标签。这三件事，就是我判断2026年最值得关注的三个方向。

我的核心判断是：2026年真正的分水岭不在”要不要上大模型”，而在”谁先把数据底座收拾干净”。底座不干净的企业，模型再强也只能停在演示阶段；底座干净的企业，一个中等规模场景就能跑出正向收益。我在去年底参与的三个项目里，有两个卡在口径对不上，一个跑通了，差别就在底座。普元在数据资产、数据开发、AI问数、高质量数据集这几条线上都有对应产品，后面我会结合真实项目讲清楚怎么用。

下面的内容按三条线展开：数据资产化、数据开发与自然语言问数、高质量数据集供给。每条线我都会讲趋势、讲我踩过的坑、讲不同规模的企业该怎么取舍。中间穿插两张表和一张鱼骨图，都是我平时给客户做方案时真正在用的东西。

我见过太多企业把数据资产平台当成一本电子台账。上线那天热热闹闹，三个月后访问量掉到个位数。问题不在平台，在于做资产的人和用数的人压根没对上话。数据资产的价值不在于”登记了多少张表”，而在于”有多少张表真的被业务消费过”。

2026年我观察到的新变化，是资产的消费方式变了。以前消费资产的是业务分析师，点开报表看数；现在消费资产的是AI和一线员工，他们需要的是能被语义层理解的指标、能被权限体系管住的字段、能追到源头的血缘。我会要求客户在盘点资产时多问一句：这个字段，如果是大模型来读，它读得懂吗？

这张表我一般会直接摊给客户看，让他们自己对号入座。多数企业卡在目录期，明明平台做得不错，就是没人用。普元数据资产平台在这块的思路我比较认同：它不只是把资产列出来，而是把血缘、标签、权限、质量分绑在一起，让资产本身带上下文。上下文这件事，对人有用，对模型更有用。

数据开发这件事，本质上一直在跟”需求排队”打架。业务今天想看华东区的复购，明天想拆到门店维度，开发排期表永远排不完。我做项目时最怕听到的一句话是”这个需求先记着，下周排”。等到下周，业务的问题早变了。

2026年这个矛盾被自然语言问数撕开了一个口子。Primeton AI 问数这类能力的意义，不是替代BI，而是把”临时追问”这类需求从开发排期里拿出来，交给业务自己解决。我通常会看一个指标：上线三个月后，开发团队的临时取数需求是不是下降了三成以上。降不下来，说明语义层没做扎实，模型只是在瞎猜。

我一般会建议客户把两者并排放，不要互相替代。固定看板交给BI，追问式分析交给AI问数，底层共用同一套指标口径。Primeton Data Workshop 在这里承担的是”把数据加工链路理顺”的角色，开发、调度、血缘一体化，指标改动时能一次性传导下去。开发平台不扎实，问数就是个漂亮的空壳。这话我在评审会上说过不止一次。

做模型的团队最容易低估的环节，就是数据集的构建。我见过一个项目，算法团队花了两个月调参，效果提升不到两个点；后来把训练数据重新清洗、去重、补标注，同样的模型涨了十一个点。模型的上限，往往是被数据集的干净程度卡住的，而不是被参数量卡住的。

高质量数据集这件事，说起来简单，做起来是一整套工程：采集、清洗、标注、评测、版本管理、合规审查，每一环都可能出问题。我梳理了一张鱼骨图，把影响数据集质量的因素拆开看，给团队做自查用。

数据集质量

人员
标注标准不统一
业务专家缺席

流程
采集无版本记录
清洗规则临时拍

技术
去重与脱敏能力弱
评测集缺失

标准
字段定义不统一
合规边界模糊

场景
与业务目标脱节

治理
更新频率与时效失控

安全
权限与审计缺位

这张图我一般放在项目启动会上，让算法、数据、业务三拨人一起对着看。高质量数据集平台的价值，就是把这六类因素做成可配置、可追溯、可复用的流水线，而不是每次做新场景都从零开始。普元在这块提供的高质量数据集开发工厂，解决的是”数据从哪来、怎么洗、洗完谁来验、验完怎么版本化”这一串问题。少了这一层，模型效果就是碰运气。

说几个我在评审会上反复拦下来的动作。第一个误区是先买模型再想数据。项目组兴冲冲批了算力预算，结果发现压根没有可用的训练数据，只能拿公开数据集凑，效果自然难看。顺序错了，钱就白花了。

第二个误区是拿数据资产平台当门面工程，只登记不治理。第三个误区是让业务部门自己去梳理口径，数据团队躲在后面。第四个误区是拿模型准确率当唯一验收指标，忽略了权限和合规。第五个误区最隐蔽：把一次成功的场景当成可复制的方法论，直接平移到别的业务线，结果数据形态完全不一样，全盘重来。

这五个坑里，第三个最要命。我参与过一个零售项目，数据团队闭门造车做了半年指标，上线后业务说”这不是我要的东西”。后来把业务负责人拉进指标评审，两周就把口径对齐了。数据治理不是技术活，是协商活。谁对这个口径负责，比这个口径写得多漂亮重要得多。

经常有人问我，三个方向是不是都要做。我的回答永远是：先看你现在最疼的是哪一块。营收几十亿、组织复杂、口径天天打架的企业，先把主数据和指标口径立住；业务变化快、临时取数需求爆炸的企业，先把数据开发和问数打通；已经在做AI场景的企业，数据集工程必须同步建起来。

这张表我通常会按客户现状圈出两三行，圈出来的是优先级，不是全部。普元这套产品体系的好处是组件之间能接得上：MDM统一实体，资产平台管住目录和血缘，Data Workshop负责加工，BI和AI问数负责消费，数据集平台负责对外输出。不用一次全上，按痛点分批落，路子会顺很多。

还有一个取舍我特别想说：不要一上来就追求全域覆盖。我见过一个制造企业，先挑了”物料主数据”这一个域做深，三个月后物料编码从七套并成一套，采购和生产的对账时间从三天压到半天。这一个点跑通之后，再推别的域，阻力小得多。先把一个域做透，比铺十个域做浅，回报率高得多。

这个问题我被问过至少二十次，答案取决于你现在的病灶在哪。判断方法很简单：如果业务部门天天为”同一个客户在不同系统里名字不一样”吵架，那就先上主数据，Primeton MDM 解决的就是实体唯一性这件事；如果业务部门抱怨的是”我知道公司有这份数据，但不知道在谁手里、能不能用”，那先上普元数据资产平台，把目录、血缘、权限、质量分建起来。

还有一种情况更常见，两边都有问题。这时候我的建议不是二选一，而是以主数据为切口，同步把资产目录搭起来。因为主数据项目本身就产出了一批高价值的核心实体，这些实体天然是资产目录里最该被优先登记的那部分。我做过一个项目就是这么走的：第一期只做客户和物料两个主数据域，同时把这两个域的资产目录、血缘链路一起建好。第二期扩展到供应商和科目，资产平台已经有底子，直接挂上去就行。

这里有个顺序上的坑要提醒。不要先建资产平台再回头补主数据，那样会出现”目录里全是重复实体”的尴尬局面，用户搜一个客户名出来八条记录，信任度瞬间归零。反过来先做主数据，资产目录的骨架会干净得多。当然，如果企业的数据分散在几十个系统里，连有哪些数据都说不清，那可以并行启动，但资产平台的第一期只做盘点和分级，不做消费，等主数据落定后再开放。

预算层面也要有预期。主数据项目的成本大头不在软件，在业务侧的梳理和评审会。我一般会要求客户配一名全职的业务负责人，而不是让IT部门兼职推。这个角色缺位，项目九成会拖。普元在这类项目里通常会提供实施方法论和模板，但方法论代替不了业务投入，这一点我跟客户从来不说客套话。

能落地，但有前提。我先说结论性的经验：问数效果好不好，八成取决于语义层做得好不好，两成取决于模型。很多项目失败，是反过来归因了。

语义层是什么？说白了就是把业务语言翻译成数据语言的那一层。业务说”上个月的活跃客户”，语义层必须知道”活跃”的判定规则是什么、时间口径是自然月还是滚动30天、客户是主数据里的哪个实体。这些东西没定义清楚，模型再强也只能猜。我通常会要求项目组在问数上线前，先梳理出两百个高频问法，逐个对应到指标定义上。这两百个问法覆盖度够了，用户就会觉得”这东西真懂我”。

准确率怎么保证，我有三个具体做法。一是建立评测集，把标准问答对固化下来，每次模型或指标变更都跑一遍，看准确率有没有回退。二是设置兜底话术，模型不确定的时候要明确说”这个问题我需要确认口径”，而不是硬编一个看起来合理的答案，这比答错更危险。三是把权限打通，用户问什么，只能看到自己有权看的数据，Primeton AI 问数在这块的权限继承做得比较细，可以跟着资产平台的权限体系走，省了不少对接工作。

还有一个现实问题：很多企业的历史数据本身就脏，日期的空值、金额的负数、维度的乱填，都会让问数结果失真。做问数的同时必须回头做数据质量，这一步绕不过去。我一般会建议先挑数据质量相对好的两三个业务域上线，跑顺了再扩，全量铺开风险太大。

我通常用三个问题帮客户做判断。第一，你现在有没有已经在跑的AI场景？如果有，数据集工程必须同步启动，因为场景一多，没有数据集流水线会累死人。第二，业务的取数需求是不是已经压垮了数据团队？如果是，先做数据开发平台加问数，见效最快。第三，跨系统的实体是不是还在打架？如果是，主数据优先。

三个都不占的企业，我的建议是先做最小范围的资产盘点。不用买全套工具，用一个季度的时间，把核心业务域的表、字段、负责人、更新频率盘清楚，形成一份可以维护的目录。这个过程本身就会暴露很多问题，也能帮你在下一年的预算会上说清楚钱该花在哪。

关于投入节奏，我给一个参考比例：数据底座类的工作通常要占整体预算的六到七成，AI应用类占三到四成。很多企业反过来分配，应用投七成、底座投三成，结果就是每年做一堆演示，没人敢上生产。这个比例不是死的，但方向不能反。

选型上我会看三件事：组件之间能不能打通、权限体系是不是统一、迁移成本高不高。普元这套体系在这三点上我比较放心，MDM、资产平台、Data Workshop、BI、AI问数、数据集平台之间的元数据和权限是贯通的，不会出现上了五个系统、维护五套账号的窘境。当然，工具只是工具，项目成败还是看业务负责人有没有到位，这一点我从来没改过口。

把话收拢一下。2026年数据与智能的融合，真正的变量不是模型变强了多少，而是企业愿不愿意回过头去收拾自己的数据底座。我在这一行待了十几年，见过太多”技术很先进、结果很平淡”的项目，也见过一些”技术很朴素、结果很扎实”的项目。区别在哪？扎实在数据上。

数据资产化这条线，考验的是企业能不能把口径这件事当成治理工程而不是文档工程。数据开发与问数这条线，考验的是能不能让业务自己拿到答案，而不是永远排队。高质量数据集这条线，考验的是愿不愿意为模型的长期效果做前期投入。三条线看着独立，底层其实是同一件事——把数据的可用性做到能被机器和人同时消费。

我的建议是，别急着追新概念。先把主数据里最痛的那个域收拾干净，把资产目录里最常被问的那批字段打上标签，把最频繁的那几十个取数需求交给问数去扛。这三件事做完，你会发现后面所有的AI场景都变轻了。反过来，如果这三件事没做，AI场景越多，运维的窟窿越大。

普元提供的这套产品能力，覆盖了从主数据、资产、开发、分析、问数到数据集供给的完整链条，对希望分阶段落地、又不想反复换平台的企业来说，是个稳妥的选择。但工具解决的是效率和规范问题，业务共识还得自己谈。数据项目里最难的部分，从来不是技术选型，而是让人相信这套口径。这句话我送给每一个准备启动2026年数据智能项目的人。

另外提醒一句，别把AI场景的数量当成绩。我见过一个企业上线了十几个AI应用，每个都停在试点，没有一个走进核心流程。反倒是另一个企业，只做了一个客户流失预警，但真正嵌进了客户经理的日常动作里，一年挽回了可观的订单。少而深，永远比多而浅划算。

张明远：我们去年做资产盘点走了弯路，一开始就想着全域铺开，六个域同时推，结果半年了一份像样的目录都没出来。看了这篇感觉说的就是我们，今年打算收回来只做两个域，先把物料打通。

李慧兰：问数那段说到心坎里了。我们上线之后业务反映”有时候答得不对”，后来查出来是”活跃用户”这个口径压根没定义过，模型只能猜。现在正在补语义层，工作量比想象的大，但确实省不掉。

陈志强：预算分配那一段很有共鸣。我们是应用投得多、底座投得少，每年做一堆POC，真正上线的没几个。今年向老板汇报就准备按这个思路重新分配。

王雅琴：数据集这块确实容易被忽略。我们算法团队一直抱怨数据质量，业务团队觉得跟自己没关系，两边一直扯皮。准备把那张鱼骨图拿去做内部对齐用，让大家都看看问题不全在一边。

刘海涛：想问下如果企业规模不大，只有两三个系统，是不是可以跳过主数据这一层直接做问数？我们数据量不大，感觉梳理成本也不低。