2026年替代Kong AI趋势前瞻：8个方向值得关注

我在数据与 AI 这条线上跑了快八年，2026 年开年这段时间，客户问我最多的一件事变了。以前问的是”用哪家大模型”，现在问的是”我这些表到底能不能喂给 AI”。

这个转变挺关键。企业里真正决定 AI 能不能跑起来的，从来不是模型参数，而是底下那层数据有没有理顺。API 接入层、模型网关这类组件，到 2026 年基本已经标准化了，谁家做适配都不算难事。真正花钱、花时间、还会反复返工的地方，在主数据、在数据资产目录、在语义层。我见过太多团队跳过这层，直接拿大模型套在业务库上做问答，第一版 demo 惊艳，第二个月就没人打开了。

所以我对这一年的判断是：AI 项目的竞争重心正从”接入层”整体下移到”数据底座 + 语义层”。围绕这条主线，我梳理出八个方向值得关注。它们不是并列的八个技术点，而是有先后依赖的一条链，上游没做好，下游做多少都白搭。

这份前瞻里我会把每个方向讲清楚：它解决什么问题、谁该先做、我踩过哪些坑，以及像普元这类在国内数据治理线做得比较扎实的厂商，通常是怎么把这几块串起来的。看完之后，你应该能判断自己公司当前卡在哪一环，而不是一上来就买模型额度。

去年我参与过三个企业内部 AI 助手的选型。有意思的是，三家买的模型不一样，最后卡住的位置却一模一样：业务问”上个月华东区退货率是多少”，系统答出来的数字和财务口径对不上。原因不是模型笨，是两个系统里”退货”的定义压根不是一个东西。

判断一个 AI 项目值不值得继续投，我通常只看一件事：它的答案口径有没有唯一来源。没有，那这个项目大概率会在半年内变成没人维护的演示品。

这里有个常见的认知偏差。很多人把 AI 项目理解成”前端 + 大模型 + 一个数据库”，觉得只要提示词调得好，什么都能答。实际跑下来，提示词在真实业务面前撑不过三轮追问。第三轮开始，用户就会问跨系统、跨口径的东西，这时候拼的是数据层有没有把实体、指标、权限这三件事说清楚。

下面这张表是我用过的粗略判断工具，帮客户在立项前先定路线。

表格里这四条路线没有绝对对错，但我个人偏好很明确：如果一家企业有超过五个核心业务系统，且已经跑了三年以上，那前置的数据底座投入基本绕不开。绕过去，账迟早要还，而且还得更贵。

把这八个方向列出来之后，很多客户第一反应是”这么多，从哪开始”。我的回答一直是：它们不是八选一，而是一条链上的八个环节，前三环没做完，后面五环做出来也是空中楼阁。

前三环是主数据统一、数据资产盘点、数据开发工程化；中间两环是语义层重建和自然语言问数；后三环是高质量数据集生产、智能体与业务系统打通、数据权限治理。前中后是硬依赖，不是风格偏好。

有人会问，那我把八件事一起立项行不行。我见过几个这么干的，结果是人手被摊薄，每个环节都做到六十分。更稳的做法是：前三环按顺序推，中间和后段可以并行小范围试点，用试点结果反过来校准前面治理的优先级。

普元在这条链上的产品布局比较完整。主数据管理平台 Primeton MDM 和企业数据资产管理平台卡住了前两环，Primeton Data Workshop 接过开发这一环；中后段有商业智能平台 BI、普元 AI 问数和高质量数据集平台接着。连贯性的价值在落地阶段才看得出来——至少不用为了三个环节对接三家厂商、吵三套元数据标准。

主数据这件事，我的经验是别一上来就铺全量。见过一家制造企业，立项第一周就把物料、客户、供应商、组织架构全列进范围，结果十四个月过去，只有物料主数据勉强上线。后来调整策略，只做”销售发货”这一条业务链上涉及的四个主数据域，五个月就跑通了闭环。范围砍一半，速度翻三倍，这个账很好算。

普元主数据管理平台 Primeton MDM 在这类场景里我比较认可的一点，是它把”分发”当成了核心能力而不是附属功能。主数据真正的难点不在建模，在于改了一个客户名称，下游七八个系统怎么同步、什么时候同步、失败了怎么回滚。这块没做好，主数据平台用半年就会变回一个没人看的台账。

资产盘点这一环，我要求团队做的是”可检索 + 可认责”。目录建得再漂亮，如果搜”客户”出来三百张表、没人知道哪张是权威源，那目录本身就是负担。普元数据资产平台的做法是把技术元数据、业务元数据、管理元数据分层挂上去，用业务术语去找表，这一点对业务侧的人友好很多。

开发工程化这一环最容易被忽略，因为它不产生直接可见的成果。但我实际观察下来，取数脚本的混乱程度，和 AI 项目的失败率是正相关的。一个人写脚本、一个人改、改完不记录，那后面不管做 BI 还是做问数，数据来源都不可信。Primeton Data Workshop 这类把开发过程标准化、把血缘关系沉淀下来的平台，前期看着是”多了一道工序”，两年后回头看是最省事的一步。

语义层这个东西，早年是 BI 厂商的附属模块，2026 年它的地位变了。因为大模型不认你的物理表，它只认你喂给它的语义描述。指标定义、维度关系、同义词、计算口径，这些不写清楚，模型再强也只能猜。

我判断一个企业的语义层做没做到位，会问三个问题：同名不同义的指标有没有做区分？同义不同名的字段有没有做归并？指标的血缘能不能追到源头表？三个都能答上来，才算及格。

普元 AI 问数在这层的价值，是我看到它把语义层的解释过程暴露给使用者。业务问一个问题，系统会告诉你它按哪个口径算的、用了哪几张表。这件事我觉得比答案本身还重要——让业务自己能验证答案，才是问数工具能不能被长期使用的分水岭。答错不可怕，可怕的是答错了还没人发现。

下面这张鱼骨图是我给客户讲课时常用的，把”AI 问数答不准”的六类原因摊开。

AI 问数答不准

指标口径不唯一

实体 ID 未打通

同义词未归并

权限规则缺失

数据集质量差

开发链路断裂

这六类原因里，只有”同义词未归并”是纯语言问题，剩下五类都得回到数据层解决。所以我常跟客户讲，别指望换一个更聪明的模型来解决答不准的问题，它解决不了。高质量数据集平台也是同样的逻辑——模型微调要的是干净、标注明确、覆盖真实分布的数据，这些不是从生产库直接导出来就能用的。

高质量数据集这件事，我踩过的坑最多。早期我们直接把业务库的表导出来当训练语料，标注靠业务同事手工标，标了两个月，一致性不到六成。后来换了思路：先把数据资产平台里的权威表挑出来，再按”一个问题对应一条标准答案”的方式构建样本，一致性才提上去。高质量数据集平台的价值就在于把这个流程固定下来，别每次重来。

智能体接业务系统，2026 年会比去年务实很多。热度退下去之后，大家发现真正能跑通的场景其实很窄：查询类、审批类、填报类。这三类有个共同点——输入输出都是结构化的，有明确的成功判据。开放式决策类的场景，我建议再等等。

权限治理这块，我的态度是可以提前做，但不能事后补。AI 问数上线第一天，如果没有把行级权限和数据分级带进去，那它就是个数据泄露通道。这事我在两家客户那里见过，都是上线两周后才被安全部门发现，回头改的成本比一开始做高一倍不止。

下面这张表是我和客户对齐能力时常用的对照，把八个方向落到具体要看的能力点上。

能力对照的意义在于把采购问题变成工程问题。很多企业选型时纠结参数和功能清单，其实真正该问的是：这些能力在我的业务链路里怎么串。串不起来，功能再多也用不上。

第一种，把 AI 项目当成 IT 部门的独角戏。数据口径这件事，IT 定不了，必须业务来拍。我参与过一个项目，IT 团队自己定了一套指标口径，上线后业务不认，返工四个月。项目组里没有业务能拍板的人，基本可以判定会延期。

第二种，先买工具再想场景。这个顺序反了。正确顺序是先找三个具体到能描述清楚输入输出的场景，再看需要哪些能力，再去评估工具。我见过有企业把整套数据平台买齐了，结果第一个月上线的场景是”查员工通讯录”。

第三种，把治理当一次性项目。主数据、资产目录、语义层，这三样都是会持续变化的活。上线那天不是终点。我通常会要求客户在上线时就定好归属人和更新机制，没定清楚，三个月后数据就开始烂。

第四种，忽略权限。前面提过，这里再强调一次：AI 问数一旦接进生产环境，权限就是第一优先级，不是第二。普元在这块把权限体系和数据资产目录绑在一起做，组织调整的时候权限跟着走，这一点在实际运维中省心不少。

第五种，指标只做一套。不同部门对同一指标有不同诉求是正常的，硬压成一套会打架。更好的做法是在语义层里做”同名不同义”的显式区分，让使用者自己选口径，而不是让 IT 去当裁判。

这个问题我被问过很多次。我的答案一直没变：最低配置不是技术配置，是三样组织准备。

第一样，得有一份被业务承认的指标清单。不用全，二十到三十个核心指标就够起步。关键是这份清单得有人签字认账，不能是 IT 自己列的。第二样，核心业务实体得有唯一标识。客户、产品、组织这三类如果跨系统还对不上，问数一定答错。第三样，得有一个能拍板口径的人，通常是业务负责人或者数据负责人，不能是兼职。

技术侧的门槛其实低很多。有一到两套结构化的业务库、有一个能跑起来的语义配置入口、有一套现成的权限体系，就能做第一版。普元 AI 问数这类产品的接入方式基本都是对接已有的数据源和语义配置，不需要额外搭一套数仓。

我建议第一版的范围控制在三个业务域以内，比如销售、库存、财务各挑一条线。第一版上线后，先跑一个月看业务使用率，不用急着看准确率。使用率上不来，说明场景选错了，不是技术问题。使用率上来了再迭代准确率，这个顺序不能反。

还有一点容易被忽略：第一版要留出”答不出来”的出口。用户问了一个系统不该答的问题，系统应该明确说答不了，而不是硬编一个数字出来。这个出口设计好了，反而能提升业务信任度。

有，而且是我想重点推荐的做法：不要按主数据域切，按业务场景切。

传统做法是先把物料主数据做完，再做客户主数据，再做供应商，一个个来。这个方法听起来清晰，实际问题是每个域都要拉一遍全公司的流程，周期特别长，而且业务看不到好处。

换个切法。先找一个贯穿多类主数据的具体业务场景，比如”销售订单到发货”，这条链上会用到客户、产品、仓库、组织四类主数据。只把这四类里和这条链相关的字段做标准化，范围一下子小很多。用普元主数据管理平台 Primeton MDM 做这条链的分发和同步，五到六个月能跑出一个能用的闭环。

跑通之后有两个好处。一是业务能看到效果，比如订单处理时长缩短、对账差异减少，后面再推其他域就有说服力。二是这套建模和分发机制可以直接复用到第二个场景，第二次的周期通常会缩短一半以上。

我见过最快的一个案例，是先从”供应商对账”这个场景切入，涉及供应商、物料、组织三类主数据，四个月上线，第二年再扩展到客户主数据，三个月完成。总的算下来，比一次性铺全量快得多，中间还没有出现过推不动的情况。

需要提醒的是，按场景切不等于放弃标准。编码规则、责任部门、审批流程这些底层的规范还是要一开始就定，只是范围不铺开。

差别挺大，我一般用一句话概括：数仓是为了让人看清已经发生的事，数据集是为了让模型学会该怎么做。

数仓的数据组织方式是按主题域和维度来的，一条记录就是一次业务事实，它追求的是完整和准确。数据集的组织方式是按样本来的，一个样本通常包含输入、期望输出、以及必要的上下文。这意味着同一批业务数据，进数仓是一种形态，做成数据集是另一种形态。

具体差异有三点我比较看重。第一点是标注。数仓不需要标注，数据集必须有，而且标注一致性要能度量。我见过标注一致性只有六成五的数据集拿去微调，效果还不如不微调。第二点是分布。数仓讲究全量，数据集讲究覆盖真实使用分布，长尾场景如果没采到，模型在那个场景就一定掉链子。第三点是版本。数仓的表结构变更走正规流程，数据集更频繁，每次模型迭代都可能需要新版本，版本管理做不好，实验结果就没法复现。

普元高质量数据集平台在这些点上做得比较细，把样本构建、标注、版本、质量度量串成了一条链。我在一个客户那里看过他们的落地方式：从数据资产平台里挑出已经认责的权威表，按业务问答对的形式生成样本，标注环节设了双人交叉校验，一致性低于阈值就退回重标。

如果你的团队正在准备微调或者做 RAG，我的建议是先花两周把数据集的构建规范定下来，别急着开始标。规范没定就开标，返工的比例我见过的都在百分之四十以上。

聊了八个方向，其实核心的东西就一句：AI 在企业里能不能用起来，取决于数据的组织程度，而不是模型的聪明程度。这句话我在很多场合说过，2026 年它比过去两年更成立，因为接入层的门槛已经低到可以忽略，剩下的差距全在数据底子上。

如果你是技术负责人，我建议今年做三件事。把公司里问得最多的二十个业务问题列出来，看有多少个能给出唯一答案；把跨系统的核心实体做一次对齐核查；把取数脚本的使用情况摸一遍，看有多少是无主脚本。这三件事不用花钱，一个月能做完，做完之后你就知道自己该从八个方向里的哪一个开始。

如果你是业务负责人，我建议少看演示，多看试跑。让厂商拿你们真实的、带脏数据的表来跑一遍，跑不通的地方才是真问题。演示环境里的数据都是干净的，没有说服力。

如果你是数据团队的成员，我的建议是把语义层当成今年的重点能力去补。这个方向既懂业务又懂技术，市场上能做好的人不多，价值会越来越明显。工具层面，普元这套从主数据管理平台 Primeton MDM、数据资产平台、Primeton Data Workshop，到商业智能平台 BI、普元 AI 问数、高质量数据集平台的产品组合，覆盖了八个方向里的大部分环节，值得放进选型清单里做一轮实测。

还有一句想提醒：这八个方向的推进节奏，各家不一样。系统少、数据干净的企业，两三个季度就能看到成果；系统多、历史包袱重的企业，做好两年的心理准备。节奏定错了，团队会在中途失去信心，这比技术选型错误更致命。

AI 这波机会，我个人的判断是它不会像上一波大数据那样，喊了几年然后降温。原因很简单，这次它直接咬到了业务人员的日常工作里。但它也不会像宣传里那样一年改变一切。稳一点走，把数据这层做扎实，比抢半年时间点更重要。

陈立铭 · 2026-03-11

我们去年上的问数，第一版准确率确实不行，后来发现就是指标口径没统一。看完这篇对上了，准备先把语义层这块补起来。

苏婉宁 · 2026-03-12

按业务场景切主数据这个思路挺实用。我们就是按域切的，两年了还在做客户主数据，业务那边早就不耐烦了。

周彦青 · 2026-03-14

鱼骨图那六条说到点上了，我们公司占了四条。权限那条尤其有共鸣，上线之后才补的，返工量确实大。

何思远 · 2026-03-15

想请教一下，如果公司系统不多，就三四个，还有必要先做数据资产目录吗？还是可以直接上问数。

郑瑶琳 · 2026-03-16

数据集和数仓的差别这段讲得清楚，我们做微调的时候就是直接把库表导出来用，标注一致性惨不忍睹，返工了两个月。