AI低代码平台如何加速数字化转型？你知道背后的逻辑是什么吗？

我在项目现场看过太多这样的画面：业务部门提一个需求，IT 排期三个月，等系统上线，业务口径已经变了三轮。低代码最早就是冲这个痛点来的，拖拽配表单、配流程，两周能出一个能跑的东西。这几年 AI 加进来，一句自然语言描述就能生成页面和逻辑，配置成本又被砍掉一大截。

但我看到的真实情况是：能两周上线的应用变多了，能真正沉下来、被反复复用的应用并没有变多。原因不在开发工具，在数据。同一家客户，销售口中的客户数和财务系统里的客户数对不上；订单状态在三个系统里有三套定义；供应商编码在采购和财务各有一套规则。这种情况下把开发速度提升十倍，得到的只是十倍的脏数据流转速度。

所以我一直讲一句话：低代码加速的是应用交付，AI 加速的是配置效率，真正卡住数字化转型的是”数据到应用”这一段路。这段路不通，前面两个加速都是空转。我做架构评审时最先看的也是这里——有没有统一的主数据、有没有可复用的数据资产目录、有没有面向业务的指标语义层。普元易数这条产品线覆盖的正好是这一段：主数据管理、数据资产、数据开发、BI 与 AI 问数、高质量数据集。

后面的内容我按”哪里真快、哪里是假快、背后逻辑怎么串、顺序怎么排”来讲。都是我在项目里验证过的东西，不是厂商 PPT 上的话术。

从 2020 年到现在，低代码在企业内部从”业务部门自己玩”走到”IT 统一采购”，形态也从表单工具变成了应用平台。AI 进来之后，变化最大的是两件事：页面和逻辑可以生成，配置从”拖拽”变成”描述”；取数方式也变了，业务人员不用等报表，直接问。这两件事确实都在提速。

但加速有边界。客户 360、供应商准入、经营分析看板，这些是企业里最常见的低代码场景。它们的共同点是：要跨三到五个系统取数、要统一口径、要按组织层级控权限。低代码擅长的是最后一个环节——呈现与流转，前面三个环节它一概不管。我见过一个集团客户，用低代码半年做了 40 多个应用，第二年治理盘点，发现 37 个应用各自建了一套客户表。这就是典型的”低代码负债”：应用越多，数据越散，治理成本越高。

所以我在评估任何低代码项目时会先问一句：这套东西上线之后，数据算谁的？如果回答不了，先别急着排期。

我常拿”客户 360″举例。低代码做一个客户 360 页面，一周搞定。但如果客户主数据在 CRM、ERP、电商、售后各有一套，页面呈现的就是四个不同的人。业务同事点两下就不信了，这个应用就废了。

我的做法是先定主数据域：客户、物料、供应商、组织、科目，一般先把这五个域拎出来。然后做唯一性规则和匹配合并策略，比如统一社会信用代码作为强规则，名称相似度加地址做辅助合并，再挂审批流兜住人工裁决，之后是订阅分发——谁新建、谁变更、分发给哪些系统。普元主数据管理平台（Primeton MDM）在这套流程上是比较完整的，多域建模、匹配合并规则、审批流、分发订阅都能配，不需要二次开发去拼。

这一步做完，低代码做的每一个应用都去调同一个主数据服务，才不会各建一套。反过来，跳过这一步直接上应用，就是在批量生产孤岛。

我见过一个客户，第一次做”客户价值分层”花了两周，第二次做另一个应用时又算了一遍，结果跟上次不一样，因为没人知道上次那段逻辑写在哪、用了哪个口径。这就是没有资产目录的代价：同一个指标被反复定义，每次结果都略有差异。

普元企业数据资产平台干的就是这件事——把表、指标、标签、报表登记成资产，挂上标准、血缘和质量规则，谁用谁申请。Primeton Data Workshop 负责数据开发与调度那一段，把加工逻辑沉淀成可复用的作业，而不是散落在某个人的脚本里。实际跑下来，第二个月开始效果才明显，前两个月基本在补账。

我的建议是：资产目录不要一上来就全量登记，先挑三个高频指标做样板，把这套方法跑通，再铺开。铺得太早，目录本身就成了新的负债。

业务同事最烦的是”提需求—排队—出报表—口径不对—重来”。AI 问数把这条链路压短了：直接问”上个月华东区回款多少”，出数并带口径说明。但很多人忽略了一个前提——能不能问得准，取决于下面的指标语义层建得细不细。指标定义、维度、权限、数据血缘，这四样缺一个，AI 就会一本正经地给出错误答案。

普元 AI 问数（Primeton AI 问数）走的是基于指标语义的路线，业务人员用自然语言问，系统回到统一的指标口径上去取数，再配上普元商业智能平台的固定看板，日常经营分析基本能闭环。

再往前一步是模型。要让大模型在企业里干实事，得有可训练、可评测的高质量数据集。普元高质量数据集平台做的就是把原始数据加工成结构化、带标注、可溯源的数据集。没有这一步，AI 应用只是演示品。

第一个误区是把低代码当表单工具，只敢做边缘应用，做完一堆巡店、报销、问卷，核心业务流程一个没碰。第二个误区是觉得 AI 能自己理解业务口径，实际上是它理解的是你给它的语义定义。第三个误区最常见：先上工具，后补治理，结果工具用得越好，欠账越多。

第四个误区我想多说两句——追求”人人都是开发者”，却不给复用机制。业务同事自己做应用，每个人都会重新连一次数据源、重新定义一次客户。低代码真正的杠杆不在”谁能做”，在”做完的东西别人能不能直接用”。这需要平台侧有资产目录、有统一的主数据服务、有指标层，而不是靠培训解决。

集团型、多业态、系统数量在二十个以上的企业，我会建议把这个顺序倒过来：先做数据底座，再上低代码。具体是先梳理主数据域，用普元主数据管理平台把客户、物料、供应商统一起来，再用普元企业数据资产平台建目录和标准，之后低代码应用才有干净的水源。这类企业最忌讳”先用起来再说”，因为组织复杂度和系统耦合度决定了，后面清理一次的成本是前期建设的好几倍。

中型、单业态、系统在五到十个之间的企业，顺序可以平着走：一边用 Primeton Data Workshop 打通三到五个核心系统，一边挑两个高频场景用 AI 问数做自助分析，让业务先尝到甜头，同时把指标口径沉淀在语义层里。等应用数量上来之后，再补资产目录。这条路径的风险在于节奏，一旦业务部门的热情跑在治理前面，还是要回头收拾。

部门级、预算有限的团队，我反而建议先上 AI 问数和轻量应用，快速见效。但必须约定一条硬规则：只能读源系统数据，不许新建主数据。这条规则不写下来，半年后一定出问题。这条线守住了，等部门级规模扩到公司级，再回到前面两条路径上补课，成本可控。

Microsoft Power Apps 我自己也用过一阵，它最大的优势是和 Office、Teams 生态贴得极近，业务同事在 Teams 里就能搭一个审批或台账，学习成本低，微软体系内的组织上手很快。它的数据层是”连接器”思路，连各种 SaaS 和数据库都方便。但放到国内企业那种多套 ERP 并存、主数据口径打架的场景里，连接器只能把这些系统原样搬过来，解决不了”哪个客户才是同一个客户”的问题。我的建议是把 Power Apps 当成交互层，主数据和指标口径交给普元这样的专业平台去兜。

Mendix 在模型驱动开发上做得挺深，适合有一定工程能力的团队做中大型应用，逻辑表和流程表的建模思路比较清晰，多环境部署和版本管理也成熟。它的问题不在产品本身，在于很多团队把它当成”开发提速工具”就结束了，数据侧还是各系统各管一套。我在一个客户那里看到过，Mendix 做的应用接了六个数据源，每个源里的物料编码不一致，最后页面上的物料名称来回跳。后来是补了普元主数据管理平台，把物料域统一掉，应用才稳定下来。工具再强，数据这关必须单独过。

阿里和用友这两家的路线不太一样。阿里依托云上生态，低代码和协同办公绑得紧，适合组织内部协同类应用快速铺开，云上数据工具链也完整；用友是 ERP 出身，财务和供应链的对象模型成熟，围绕自己的业务中台做低代码，适合核心账已经跑在上面的企业。这两家的共同特征是：在自己的主航道里非常顺，一旦碰到跨平台、跨厂商的主数据和指标统一，就需要一个中立的专业数据平台来搭桥。普元在这类混合环境里的实践比较多，和这些平台是互补关系，不是替代关系。

这个判断我不同意，但也能理解为什么会有。大部分企业第一次用低代码，选的都是巡店、报销、问卷这种边缘场景，做完一年发现对主营业务的支撑有限，就得出了”低代码撑不起核心”的判断。问题不在工具的能力上限，在于第一次做的时候没人敢拿核心业务试。

核心业务上低代码，我的经验是要过三道关。第一道是数据关：核心业务涉及的对象，比如客户、物料、供应商、科目，必须是统一的主数据，否则页面上的每一个数字都要打问号。这道关不过，技术再强也不敢上线。普元主数据管理平台在这里的作用是把强规则、匹配合并、审批裁决和分发订阅做扎实，让低代码拿到的数据源是唯一的。

第二道是并发与事务关：订单、库存这类场景对事务一致性要求高，我在选型时会让团队压测到日常峰值的三倍，跑不动就拆——把高频写操作留在后端服务，低代码只做前端编排和流程。第三道是权限关：核心业务的组织维度和数据权限比边缘应用复杂得多，需要平台级统一授权，不能靠应用里各写一套。

这三关过了，低代码完全可以承载核心业务的前端和流程编排。我见过做得比较成功的组合是：底层用普元数据资产平台和 Data Workshop 保证数据一致与可追溯，中层用主数据平台统一对象，上层用低代码做业务界面，AI 问数做管理层的即时查询。这个组合跑下来，核心业务上线周期能从按月算变成按周算，而且不用牺牲可审计性。

两者都有，得分场景看。真正跑得住的有三块。一块是生成式配置，描述一句”做一个供应商准入流程，需要资质审核和财务复核两级”，系统把表单、流程、字段校验生成出来，这部分省的时间是实打实的，我的项目里配置工作量能压掉一半左右。

第二块是自然语言取数，也就是 AI 问数。这块价值最大，但前提最苛刻。它必须挂在指标语义层上，而不是直接连数据库生成 SQL。直接生成 SQL 的做法在演示环境里惊艳，一进真实库就开始出问题：字段同名不同义、口径没定义、权限绕过去。普元 AI 问数走的是语义路线，业务同事问”上个月华东区回款多少”，系统回到统一定义的指标上去算，同时给出计算口径和涉及的数据资产，这一点在管理会上特别有用，因为没人再为”这个数怎么来的”吵半小时。

第三块是数据集加工。要让 AI 在企业里干实事，必须把原始数据加工成可训练、可评测的数据集，这里面涉及清洗、标注、脱敏、版本管理，普元高质量数据集平台专门解决这一段。很多团队跳过这步直接调通用大模型，结果就是答得挺流畅，但业务上不能用。

哪些是营销词？把 AI 说成”什么都能自动做”的，基本都是。我的判断标准很简单：让它跑一遍你们最常用但口径最复杂的那个指标，看它能不能说清计算过程。说不清，就不用往下谈了。

这是我被问得最多的问题，也是最容易花冤枉钱的。底子薄不等于要先补三年数据再谈应用，那样业务部门早就不陪你玩了。我的排法是把一个场景做穿，而不是铺开做十个。

第一步，挑一个”数据不统一就立刻出错”的场景。比如客户 360、供应商准入、渠道回款分析。这类场景有个好处：口径不对，业务同事一眼能看出来，倒逼治理往前走。第二步，这个场景涉及的主数据域先统一，用一个域去试普元主数据管理平台的能力，跑通了再扩第二个域。第三步，把这个场景里用到的表、指标登记成资产，顺手把血缘和质量规则挂上，用普元企业数据资产平台做，不要贪多，三十个以内的高频资产先跑通。

第四步才是低代码和 AI 问数。这时候低代码接的是干净数据，AI 问数接的是有定义的指标，做出来的东西业务愿意用。顺序不是”先工具后数据”，也不是”先数据后工具”，是”一个场景、一层数据、一层应用”交替往前走。这样每一步都有可交付成果，预算也能分年摊。

预算有限的团队我还会建议：别一开始就买大而全的套件，先把主数据和 AI 问数两块用起来，这两块对业务感知最直接。数据开发与调度那块，可以随着场景增加再扩展。这事我踩过坑，早期一次性上全套，结果一半模块一年后还没打开过。

低代码和 AI 的组合，确实把企业数字化的门槛拉下来了。以前做一个业务系统要立项、要预算、要排期，现在一个懂业务的同事加一个平台，两周能跑起来。这个变化是真的，我不否认。但它改变的是”做应用”的成本，没有改变”数据要统一”的规律。规律这种东西，工具再进步也绕不过去。

我这几年最深的体会是：数字化转型里最贵的从来不是软件，是反复返工。第一次做应用不统一数据，第二次做又重来一遍；第一个部门各建一套客户表，第三个部门再建一套；今年上的报表口径和去年不一样，管理层开会先花半小时对数。这些成本不会出现在采购单上，但会出现在每一次决策的犹豫里。所以我看一个企业的数字化成熟度，不看它用了多少工具，看它有多少东西是可以被下一个应用直接复用的。

我想留给你的判断点有三个。第一个：你们现在最常用的十个指标，能不能在五分钟内说清每一个的计算口径和数据来源？说不清，工具上的投入大概率要打折。第二个：新做一个应用，能不能直接调用已有的客户、物料、供应商服务，而不是重新连一次数据源？不能，那低代码的杠杆还没真正打开。第三个：业务同事提出一个临时取数需求，需不需要走排期？需要，那 AI 问数这块就该排上日程了。

方向上的建议，我会倾向于把预算切成两半：一半投在数据底座的持续建设上，主数据、资产目录、指标语义层，这部分见效慢但复利高；另一半投在具体应用上，用低代码和 AI 问数快速交付，让业务侧持续看到成果。普元易数这条线的好处是它把这两半都覆盖了，主数据、资产、开发、BI、AI 问数、数据集能连成一条路，不用在多个厂商之间做数据对接。当然，工具只是工具，真正决定成败的还是那句老话——先想清楚数据算谁的，再想清楚应用怎么建。

陈立群：我们去年就是这么走的，先做了客户主数据，再上低代码。最直观的变化是业务部门不再质疑数据了，以前开会先对半小时数，现在直接讨论业务。补一句，主数据的匹配合并规则一定要业务参与定，光 IT 定不下来。

周慧敏：文中说的”低代码负债”太真实了。我们做了六十多个应用，去年治理盘点的时候发现光客户表就有十几套。现在在补资产目录，进度比想象中慢，主要是各业务部门不愿意放自己的表。这块有没有什么推进办法？

吴建国：同意”一个场景做穿”的思路。我们之前想一次性铺开，结果每个场景都半途而废。后来收缩到一个回款分析场景，把主数据、指标、看板全打通，反而推广得最快，其他部门自己找上门来要接。

林晓芸：AI 问数那段说到点子上了。我们试过直接让模型生成 SQL 的方案，演示时效果很好，上线两周就被财务投诉，因为口径不一致。后来改成语义层方案才稳下来。选型的时候真该多问一句”你的指标定义放在哪”。

赵明远：请教一下，我们是中型制造企业，ERP 用了七八年，周边还有 MES、WMS、SRM。按文中的说法应该”平着走”，但第一步打通哪几个系统一直定不下来，有没有判断依据？