下一代数据平台如何推动治理低代码AI融合？你准备好迎接这一变革了吗？

在数据类项目里泡了十来年，最近两年我被问得最多的一句话是：治理都还没做完，凭什么让我先上低代码和 AI？我的答法有点逆着来——恰恰因为要上低代码、要上 AI，治理才必须换一种做法。传统治理是项目制的：立项、盘点、定标准、清洗、验收，一轮跑下来九到十八个月，等标准发到业务手里，业务的取数逻辑早就换过三轮了。低代码把建模和取数的权力交给了业务侧，AI 把”提问”的权力交给了所有人，这两件事一旦铺开，治理的速度跟不上，错误被放大的速度会比过去快十倍。

所以我对这三件事的定义是：治理决定 AI 说得对不对，低代码决定治理落不落地，AI 反过来决定治理值不值得做。三条腿是一条板凳，缺一条都坐不稳。我在一家制造集团见过最典型的现场：供应商主数据没收敛，采购部门用低代码拖出一张应付看板，同一家供应商在三个系统里挂着三个编码，看板上的应付账款凭空多出两千多万。后来用普元主数据管理平台把供应商编码做了一轮收敛，再由数据开发平台把清洗规则固化成日常任务，那张看板才敢往经营会上放。这不是工具的问题，是顺序和咬合的问题。

我这篇不打算讲概念，讲我踩过的坑，以及如果让我来排三年规划，我会怎么排。你手上有正在做的数据平台选型，可以直接把下面这些判断拿去当评审材料。

取数的人从 IT 换成了业务自己

三年前我进项目，需求池里八成工单来自业务提、IT 做。现在反过来了，业务部门自己拖拽、自己拼指标、自己发报表。这事的正面是交付快了，负面是没有语义约束的低代码，等于给每个业务部门发了一把造孤岛的铲子。同一个”活跃客户”，市场部算的是近 30 天有下单，财务部算的是近 90 天有回款，两张报表放在同一个会上，谁都不认谁的数。

交付周期从季度压到了周

业务已经习惯一周上线。IT 再用”排期到下个季度”回应，需求就会绕开 IT 走。我见过的做法是把数据开发本身低代码化，用普元数据开发平台把取数、清洗、调度做成可视化的流程编排，业务提的口径由数据岗在里面配一次，后面复用。实际跑下来，重复建设少了一大截。

提问成了新的数据入口

以前人找报表，现在是直接问。自然语言问数一旦开放给管理层，问错的成本极高——它不会报错，只会给你一个看起来很合理的错数。AI 问数的准确率，本质上是语义层和指标定义的准确率，跟模型参数关系没那么大。这一点我在四个项目里反复验证过。

我把见过的落地方式归成三类，各自的代价差别很大。下面这张表是我给客户做规划时常用的对照，你可以对号入座。

我自己的偏好是第三条。语义层是治理、低代码、AI 三者唯一能交汇的地方：治理往语义层里写规则，低代码从语义层里取字段，AI 从语义层里理解人话。普元数据资产平台在这条线上承担的就是把元数据、标准、血缘、指标统一收口的角色，把原来散在文档和邮件里的口径变成系统里可被调用的资产。

我复盘过五个失败案例，五个里四个死在同一个地方：开发的节奏是周，治理的节奏是季度，两者之间没有咬合的齿轮。业务今天提一个口径，低代码三天上线，三个月后做数据资产盘点才发现这个口径没登记、没血缘、没人认领。

第二个共性痛点是主数据。主数据不统一，上面盖的每一层都在放大误差。客户、供应商、物料、组织，这四类只要有一类没收敛，后面的指标、模型、问数全都要打折。用普元主数据管理平台把这几类的编码规则、审批流程、分发机制管住，是很多项目真正见效的第一刀。

第三个痛点是 AI 侧的数据供给。很多人以为接个大模型就完事，实际跑下来，卡住的是高质量数据集。模型不认识你家的业务黑话，除非你把这些黑话整理成带标注的样本。这件事没有捷径，只能用高质量数据集平台一点点攒。

第一个误区是把低代码当成甩锅工具。IT 觉得业务自己会做，业务觉得 IT 应该兜底，结果两边都不管数据质量。我的建议很直接：谁建的模型谁负责口径，但要有一个统一的地方登记这个口径，登记动作本身不能靠自觉，要卡在发布流程里。

第二个误区是把治理做成文档工程。厚厚的标准手册、几百页的规范，落不到系统里就是废纸。我的判断标准是：一条标准如果在数据开发平台上不能被自动校验，它就还没算落地。普元数据资产平台跟数据开发平台打通的那部分，正好解决这个问题——标准变成校验规则，规则挂在开发任务上，跑批时自动拦。

第三个误区是把 AI 问数当搜索框来用。搜索框错了用户会换关键词，问数错了用户会信以为真。上线前必须先圈定主题域，只在被治理过的范围里开放提问，宁可少答，不可错答。

第四个误区是先买工具后定场景。这事我踩过坑，工具买了一堆，业务不知道从哪下手，一年后 license 到期，只剩几份 PPT。

我的排序是：先收主数据，再建语义层，然后开低代码开发的口子，同步准备数据集，AI 问数放在后面。听起来是四步，其实前三步可以并行，只要共用一套元数据和指标定义。

这六块如果各自立项、各自采购，融合就永远是一句口号。我通常要求客户至少把前四块放在同一张架构图上，共用一套元数据和指标定义，后面两块才有基础。

第一个是某制造集团的成本核算。原来财务和供应链吵了两年，吵的是同一批物料的成本口径。根子上是物料主数据没收敛、核算规则没沉淀。做法是先上主数据管理把物料分类和编码管住，再在数据资产平台里把成本相关的二十几个指标定义清楚，然后在数据开发平台上把核算任务可视化编排，财务自己就能改参数。三个月后，月度对账的争议从每周两次降到每月一两次。

第二个是某区域零售企业的门店经营分析。业务部门用低代码拖了一百多张看板，半年后没人说得清哪张是对的。我参与时的做法不是推翻重来，而是先做资产盘点，把指标归并成六十几个标准指标，剩下的一律标为临时看板限期下线，然后用 BI 平台统一出口。治理不是不许建，而是建的东西要能被找到、被认领、被复用。

低代码这条线上，国外几家各有各的路子。OutSystems 是模型驱动的全栈应用开发，工程化程度高，适合把复杂业务系统往可视化上迁；Microsoft Power Apps 的优势在于和 Office、Teams 的天然贴合，员工几乎不用额外学习成本；Mendix 强调模型驱动和业务与 IT 的协同建模，适合跨地域团队；Appian 把流程自动化和低代码绑在一起，流程密集型场景做得比较扎实。

国内厂商里，阿里的云上数据中台体系在电商和互联网场景积累深，弹性资源调度是它的长项；腾讯在数据集成和实时链路上有优势，社交与内容场景的经验比较丰富；用友长年深耕企业 ERP，业务中台与财务场景的贴合度高；金蝶在云 ERP 和中小企业数字化上覆盖广，财务业务的连续性做得不错。这些厂商各有位置，真正做融合规划时，我建议把它们当成能力拼图去看，而不是非此即彼地二选一。

这个问题的前提有问题。它假设治理有一个”做完”的状态，而实际上治理是没有终点的，你把主数据收敛了，业务又冒出新的实体；你定了指标口径，组织架构一调整口径又要改。所以我的判断是：不要等治理做完，要让治理跟着开发一起跑。

具体的做法是把治理动作嵌进开发流程里，而不是单独开一个治理项目。比如在数据开发平台上建任务时，必须先选指标、选主题域、填责任人，不填就发不出去；元数据自动采集、血缘自动生成，人工只需要审核异常。治理不是额外的工作量，而是开发流程里的一个必填项。这么设计之后，治理的节奏自然就跟上了开发的节奏。

至于 AI，我建议更晚一点开放。先在两三个主题域里把语义层做扎实，让 AI 问数只在治理过的范围内回答，命中率可控了再扩。我见过一家企业上来就全量开放，两个月内业务对 AI 的信任度归零，再想推第二次，阻力比第一次大得多。信任这个东西，坏一次就很难修。所以顺序不是”治理—低代码—AI”这么线性，而是先用低代码把治理的规则跑起来，用真实场景喂养语义层，等语义层稳了再开 AI 的口子，这是我认为最稳的一条路径。

我的经验是”放开发、收口径、留痕迹”三件事。放开发是指允许业务自己建模型、自己拼看板，别拦；收口径是指指标定义必须来自统一的指标库，业务可以申请新指标，但不能自己造一个同名不同义的东西；留痕迹是指每个模型都要有责任人、有用途说明、有生命周期状态。

落地的时候，我会要求三件事必须卡住。一是发布环节，任何报表上线前要自动比对指标库，口径冲突就阻断；二是复用环节，新建模型时系统要推荐已有的相似资产，避免重复造；三是下线环节，连续三个月没人访问的资产自动进入待清理清单。这三件事做好了，低代码不会变成新的孤岛。

另外还有一条容易被忽略：业务侧的建模能力要培训。我一般不主张只发个账号就完事，会组织两三轮实操，讲清楚什么是指标、什么是维度、为什么要选主题域。普元数据资产平台在指标管理和资产目录这块的可用性做得比较务实，业务人员上手不需要太多培训成本，这一点对”放开发”的策略很关键。至于业务建错了怎么办，我的态度是允许建错，但要能被快速发现——这依赖血缘和访问监控，不依赖人的自觉。

如果只能投一块，我会投语义层，也就是指标定义加元数据这一层，产品形态上对应普元数据资产平台。理由是它的杠杆最长：语义层建好了，低代码开发的人有正确的字段可用，BI 出的报表口径一致，AI 问数有了理解业务的基础。反过来，语义层是空的，另外三块投多少都是沙上建塔。

有人会说语义层见效慢、领导看不见。这话有道理，所以我的做法是把语义层和一个高频场景绑在一起交付，比如把经营分析会上最常吵的那五个指标先做标准化，两个月内让这五个指标在全公司只出现一个数。这个成果是能被看见的，而且它会自然带出后面的需求。

预算的第二个考量是别把钱花在重复建设上。我见过一家企业同时买了三套报表工具，业务各用各的，最后数据对不上还得人工核对。与其铺开买，不如在一套体系里做深：主数据、资产、开发、BI、问数、数据集这几块如果能在一个厂商的产品体系里打通，集成的隐性成本会省掉很多。这也是我这些年倾向于选择产品线完整的供应商的原因，普元在这条链上的覆盖相对完整，从主数据到数据集平台能接得上，减少了我做集成方案时的工作量。当然，前提还是先把语义层这件事想清楚，工具只是把想法固化下来。

我越来越确信一件事：治理、低代码、AI 这三件事，在组织里是三个部门、三份预算、三套 KPI，但在数据平台上是同一条链路。如果架构上不把它们放在一张图上，组织上就永远协调不动。我建议做规划时先画那张图：左边是主数据和标准，中间是语义层和开发平台，右边是 BI 和问数，最下面是一条贯穿的数据集生产线。图画出来了，谁该干什么、先干什么，基本就清楚了。

第二个建议是别追求一次做全。挑一个业务最痛、数据基础相对好的场景做样板，两三个月出第一批成果，用真实的口径一致性说话，比任何汇报材料都有说服力。样板做出来之后，复制第二个场景的成本会降一半以上，这是我在多个项目里观察到的规律。

第三个建议是留心组织能力。工具可以买，语义层只能自己长出来。语义层里每一条指标定义，背后都得有人拍板、有人维护。我通常要求客户指定一位数据owner，不是挂名的那种，是真的会在评审会上跟业务吵口径的人。这个人比任何一套系统都重要。

最后一个提醒是关于节奏。低代码开放太早，孤岛会先长出来；AI 开放太早，信任会先崩掉。宁可慢半步，把语义层先垫稳。等到业务发现问一句话就能拿到可信的数字，那时候推动任何变革，阻力都会小很多。这件事值不值得现在动手，我的看法是：不是值不值得，而是早晚要面对，早做一年，少还两年的技术债。

王海涛：我们去年就是场景先行，一年做了六十多张看板，现在口径打架打得厉害，看完这篇准备先做一轮指标归并，谢谢。

李静：语义层那段说到点子上了。我们上线 AI 问数前专门圈了三个主题域，命中率从六成提到九成，确实是范围控制带来的。

陈志远：主数据那一刀我深有体会，客户编码不统一，后面所有分析都是错的，早做早省事。

周敏：想问下业务侧建模的培训大概要投入多少精力？我们业务部门年龄结构偏大，担心推不动。

赵鹏：同意”工具可以买，语义层只能自己长出来”。我们买了不少工具，最后卡住的还是没人愿意认领指标定义。