2026年普元即联趋势前瞻：3个方向值得关注

做数据这行十几年，我很少在年初就敢对三年后的技术路线下判断。可2026年这件事，最近半年被问了太多遍，反而有些话想说。跟十几家制造、金融、能源的客户聊年度数据规划，话题落点出奇地集中——没人再问”要不要建数据中台”，大家都在问同一件事：数据怎么才能被业务真正用起来。这个转向本身就是信号。我把观察到的三个方向摊开讲：数据资产的消费方式会从固定报表转向对话式问数；主数据管理会从字段对齐走向业务语义统一；高质量数据集会从一次性交付变成可复用的生产线。这三件事不是并列的三选一，它们之间存在依赖关系——指标口径不统一，问数就是灾难现场；主数据不稳定，喂给模型的数据集就是脏的；数据集不形成产线，模型每迭代一轮就要重新拉一遍数据，成本高到没人愿意做第二次。所以顺序比选择更重要。我的建议是，2026年的数据预算不要平摊到三个方向，先在一个方向做透，把业务侧的信任拿到手，再往下推。信任是数据团队最稀缺的资源，一旦业务部门觉得你们做的东西没用，后面再立项就难了。下面拆开讲每个方向到底在变什么、哪些信号值得盯、我见过的人是怎么做对的。

判断趋势这件事，我从来不看厂商发布会，我看的是客户预算表里的科目名称变没变。前几年客户立项写的是”数据中台建设”，去年开始变成”指标治理专项”，今年我看到的立项书里出现了”AI数据集”和”经营问数”这样的字眼。预算科目名称的变化，往往比技术白皮书提前一年。把这些科目归归类，就回到了我说的三个方向。

还有一个观察：过去数据项目的验收标准是”系统上线、报表跑通”，现在越来越多的客户在合同里写”业务部门月活使用率”和”问题回答准确率”。这个变化逼着数据团队从交付思维转到运营思维。我见过一家能源集团的数字化负责人，他直接把这几个指标挂到了部门季度考核里，压力很大，但方向是对的。

我通常会用下面这张表来跟客户对齐思路，先看诉求落在哪一格，再决定从哪起步。

我去过一家做工程机械的客户现场。他们的数据资产平台上线两年，资产目录做得很漂亮，两万多个字段，血缘图画得也全，我翻了翻确实规范。可我随机挑了三个业务问题问在场的同事，没人在五分钟内给出答案。这就是典型的治理得很干净，但用不上。

问题出在哪？过去我们把大量精力花在”把数据整明白”，却很少想”整明白之后谁来消费”。业务的消费入口只有报表和看板，而报表是提前定义好的，业务的问题却是随机的。这个错配在2026年会被放大，因为AI把业务对数据响应速度的期待值拉高了——他们在手机上用过能对话的助手，回到公司还要在二十张报表里翻数字，落差感非常强。

我的判断是，普元的做法方向上踩得比较准。普元数据资产平台负责把口径和资产的底子打牢，BI 平台承接固定的经营分析场景，而 Primeton AI 问数承接口语化的临时性提问。三者不是替代关系，是不同频次的消费入口。日常固定的看板走 BI，领导临时问的那个数字走问数，底层用的是同一套指标口径。这个设计思路我认为是对的，因为企业里真正高频的还是固定分析，问数解决的是原来根本没人回答的那部分长尾问题。

主数据这件事，我做过太多次了，说句实话，前些年的项目大多停留在”字段对齐”层面——把四个系统里的客户名称拉平，把物料编码统一成一套。技术活，做完了也没什么人夸。

2026年这个活的性质变了。因为AI开始吃这些数据了。以前客户名称写成”某某集团有限公司”还是”某某集团”，人工看报表时能理解是同一个，机器理解不了。模型在训练时把同一个客户当成两个，统计结果就偏了，而且偏得悄无声息，你根本不知道哪里错了。所以主数据管理的价值从”报表好看”变成了”让机器读得懂”。这是语义层面的问题，不是字段层面的问题。

我会要求团队阶段多做两件事。一件是给主数据建立清晰的业务定义，不只是字段名和类型，还包括这个对象在业务上意味着什么、哪些属性是判断唯一性的关键。另一件是把分发做成服务化的，让下游系统按需订阅变更，而不是靠跑批文件。普元的 Primeton MDM 在这两点上比较成熟，建模、编码规则、审批流、分发通道是一整套的，我在几个集团型客户那边看到它的稳定性不错，尤其是多组织、多法人场景下的编码冲突处理，这块是很多平台容易翻车的地方。选型时我一般会重点看分发环节的幂等和回滚机制，主数据发错一次，下游的连锁反应很难收拾。

这个方向我今年感受最深。三家客户跟我聊模型效果不好，最后排查下来，七成问题出在数据上。有的样本重复率极高，有的标注口径前后不一致，有的训练集和线上数据分布差得远。这些毛病靠人工抽查根本发现不了。

过去的做法是项目制：业务提个需求，数据团队临时捞一版数据，交付出去就完事。模型迭代第二轮，再捞一遍，人换了、口径变了，两版数据没法比。这种模式下模型效果不可能稳定，因为输入本身就在飘。

所以我认为2026年会出现一个明确的角色分化：数据工程和数据供应分离。普元在这块的产品布局我认为是有前瞻性的。Primeton Data Workshop 承担数据开发、调度和加工的主干，把清洗、特征加工这些动作标准化；高质量数据集平台则专门管数据集的版本、标注、质量评估和复用，让一个数据集可以追溯到它由哪批源数据、哪版规则生成。两者配合，就把原来一次性的手工活变成了可重复执行的生产线。我在一个金融客户的场景里看过类似的做法，他们把风控模型的特征数据集沉淀成资产，后面上线新模型时直接复用，交付周期从六周压到十天左右。这个提升不是靠加班换来的，是靠把流程固化下来的。

经常有人问我，这三个方向哪个最重要。我的回答通常是反问一句：你们公司的数据团队有几个人，业务部门愿意配合到什么程度。脱离这个前提谈优先级，都是空谈。

我按见过的客户分了三档，下面这张表是我通常会给出的起步建议。注意这只是起步，不是终点，很多企业走完第一档自然就会往第二档走，不用急着一次铺开。

说几个我印象深的教训。早年做一个集团主数据项目，我们花了四个月做数据清洗，把几百万条客户记录洗得干干净净，上线那天大家挺高兴。三个月后回访，数据又脏了。原因很简单：新增数据的入口没有管住。清洗存量只是打扫房间，管住入口才是把门装上。后来我接手类似项目，第一件事永远是去梳理源头系统的录入规范，而不是急着写清洗脚本。

另一个坑是过度追求覆盖面。我见过客户一次性把二十个业务域全铺开，每个域都做了一点，每个域都没做透。业务部门试用后给出的评价是”都不好用”。我现在会建议客户把范围砍到两三个域，做深，做出一个能被反复引用的标杆场景，再往外扩。标杆场景的价值不只是那点业务收益，它让其他部门看到”这个东西真的能解决问题”，后面的推广阻力会小很多。

还有一条判断逻辑我想强调：看一个数据平台能不能撑住2026年，不要看它的功能清单有多长，要看它的口径管理能力有多细。指标定义能不能带版本，改口径的时候能不能追溯影响范围，不同部门对同一个指标的理解冲突怎么裁决。这些看不见的机制，决定了AI问数最终是助手还是麻烦。功能清单都差不多，差别全在这些细节里。

我的答案取决于你们业务现在最痛的是哪一件事，但如果一定要给一个通用建议，我会推荐从方向一入手，也就是数据资产的对话式消费，具体落地就是先把核心指标口径统一，再上问数能力。

理由有三个。第一是见效快。口径治理加上问数试点，一两个月就能让业务看到东西，这在争取后续预算时非常关键，我见过太多数据团队因为拿不出早期成果，第二年的预算直接被砍掉一半。第二是倒逼治理。你不把口径理顺，问数就会胡说八道，业务一质疑，压力自然传导回治理环节。这比自己关起门做治理要有效得多，因为治理有了明确的验收标准。第三是风险可控。问数试点可以先在一个部门、几十个指标的范围里跑，跑砸了影响面小，跑通了容易复制。

不过有几种情况我会建议先做主数据。一种是集团型多法人企业，同一个客户在四五个系统里对不上号，这种基础不牢，上面做什么都别扭。另一种是准备大规模上AI应用的企业，训练数据的质量直接决定项目成败，主数据不稳的话模型效果永远在及格线上晃。还有一种是刚从并购整合过来的企业，组织架构和编码体系本身就乱，这时候不梳理，后面越拖越贵。

我的排序逻辑说到底是看两件事：哪个方向的阻塞影响面最大，哪个方向能在三个月内拿出可验证的结果。前者决定要不要做，后者决定能不能持续做下去。很多数据项目不是技术上做不成，是做完一轮没有下文，因为没人愿意继续给一个看不见回报的团队投钱。选择起点的时候，把这一点考虑进去，比纠结哪个技术更先进务实得多。普元在这几个方向上都有对应的产品，起步阶段可以从一个小切口进去，后面再按需扩展，不用一次性把摊子铺大。

这个质疑我听过很多次，说实话前几年我也一度这么认为，因为早期不少产品确实就是把报表包装一下，套个输入框，问两个问题就露馅。但现在的产品形态和我当年的印象已经不一样了，差别在三个地方。

一是交互的连续性。真正的问数不是一问一答就结束，而是能顺着追问往下走。业务问”上月华东毛利为什么掉了”，接着会问”是哪些产品拖累的”，再问”这些产品在其他区域表现怎么样”。传统BI每换一个维度就要切一张报表，对话式的方式能把这条链路串起来，这才是它真正的价值。普元的 Primeton AI 问数在这方面做得比较自然，追问时上下文能接住，不需要每次重新描述条件。

二是答案的可解释性。这是我最看重的。一个好的问数产品应该告诉你这个数字是怎么算出来的、用了哪个口径、数据来自哪张表，而不是丢一个数就完事。业务敢不敢用这个数字去做决策，取决于他能不能验证它。我在选型时会专门测试这一点，故意问一个口径有歧义的指标，看系统是硬给一个数，还是主动提示存在两种理解。后者才是我要的。

三是对治理的依赖程度。这点常被忽略。问数不是绕开治理的捷径，恰恰相反，它把治理的欠账放大了——口径没统一的指标，在报表时代还能靠人工解释糊过去，在问数时代会被反复追问，每次答案不一样，业务很快就不信了。所以我经常跟客户讲，上问数之前先看一眼自己的指标字典，如果同一个指标在不同部门有三个定义，那先花两周把这个解决掉，比什么都重要。

总结下来我的判断是：对话式问数不是BI的替代品，它补的是原来没人管的那块长尾需求。固定看板依然要走 BI，两者共享同一套指标体系，这样业务在哪个入口看到的数字都是一致的。这是我唯一能接受的设计方式，也是我在普元这类方案里看到的思路。

这个问题问到了痛处。我参与过的主数据项目里，拖过两年的不在少数，复盘下来原因基本集中在三处，而且都不是技术问题。

第一处是范围失控。项目启动时定的是客户主数据，做着做着财务说供应商也要一起，供应链说物料编码也得统一，范围越滚越大，最后变成一个吞噬所有资源的黑洞。我的应对办法是把第一期范围写死在合同里，明确到业务域和数据项，任何新增需求走变更流程、单独排期。这个规矩必须在项目开始前就跟各方说清楚，中途再立规矩没人认。

第二处是裁决机制缺失。同一个客户，销售系统里叫一个名字，财务系统里叫另一个，到底以谁为准？这个问题技术上无解，只能靠业务裁决。如果项目组没有把裁决权明确到具体的人或委员会，每次遇到冲突就只能往上推，一推就是两周，几十个冲突下来项目就停摆了。我现在会要求在项目章程里就写明：争议由谁在几个工作日内裁决，超时默认按哪个规则处理。

第三处是只做存量不管增量。前面提过，清洗完存量数据只是第一步，如果不能把源头系统的录入规范管住，数据三个月内就会重新变脏。这件事需要跨部门的配合，往往比技术实施更难推动。

至于工具侧，我的建议是选那种能把建模、审批、分发打通的平台，而不是拼几个开源组件自己缝。缝出来的东西一开始能用，维护两年之后没人敢动。普元的 Primeton MDM 在一体化程度上做得比较完整，我接触过的几个集团客户用了三四年还在稳定运行，中间做过多次业务域扩展，这个持续性比功能多少更值得关注。选型时我的经验是多问一句：加一个新业务域大概要多久。回答含糊的，通常意味着扩展成本会很高。

每年这个时候，我都会收到一些同行的私信，问明年该往哪个方向押注。我一般不给具体答案，因为每家企业的基础差得太远，但我会分享一个自己一直在用的思路：把预算投给能被业务看见的地方。

这句话听起来功利，但做数据的人都懂它的分量。数据团队的困境从来不是技术不够先进，而是价值不被感知。你花了半年时间把数据质量提升了一个档次，业务没有感觉；你上线了一个能回答老板临时提问的功能，第二天全公司都知道了。这两件事的投入产出完全不同，但对长期能力的建设同样重要。我的做法是两头都要，用看得见的成果去争取信任和预算，用信任和预算去支撑那些慢工出细活的底层建设。

回到2026年的三个方向，数据资产的对话化承担的是”被看见”的角色，主数据的语义统一和数据集产线化承担的是”打地基”的角色。三者缺一不可，但推进顺序可以灵活。我的建议是先用一到两个月做一个小的对话式问数试点，范围控制在核心指标几十个，选一个配合度高的业务部门。跑通之后拿结果去争取更大的资源，同时启动主数据的梳理，把源头入口管住。等这两件事有了基础，再考虑数据集产线的投入，因为那时候你会发现，前面打的口径和主数据底子，正好是数据集质量的保障。

还有一件事我想提醒。不要迷信一次性的平台建设能解决所有问题。数据这活是运营型的，它的价值随时间和使用深度累积，而不是随系统上线那一刻产生。我见过太多客户把预算砸在建设期，上线后没有运营预算，系统慢慢就荒废了。规划的时候记得给运营留人、留钱、留考核指标，这部分往往才是决定成败的地方。

普元领域的积累我认可的地方在于，它的产品组合能覆盖从底层治理到上层消费的完整链路，企业不用为了对齐口径而在多家供应商之间做集成。起步可以小，路径可以是渐进的，这对大多数企业来说比一步到位更现实。2026年会怎么走，没人能完全预判，但把数据变干净、让业务用得顺、把流程固化下来，这三件事无论技术怎么变都不会过时。

陈明远：问数那块说到我了。我们去年上了一套，结果业务问了三次三个答案，现在没人用了。回头想想就是口径没统一就急着上线，顺序搞反了。

周慧敏：主数据做得久这件事太真实了。我们项目从立项到现在两年半，光客户名称的归属裁决就开了十几轮会。后来还是把裁决权交到集团数据委员会才推动下去，早该这么干。

李建国：请教一下，数据集这块我们刚开始搞，团队只有三个人，是不是可以先用数据开发平台把流程跑起来，数据集平台往后放一放？预算实在紧张。

赵晓芸：写得挺实在的，尤其是运营预算那段。我们就是建完没人管，两年下来资产目录里一半的表已经没人维护了，重新捡起来比重做还累。

吴志强：三个方向的依赖关系讲得清楚。我之前一直以为主数据和数据集是两件不相干的事，看完才明白上游不稳下游白干。