企业级AI低代码为何成为企业转型的关键？有哪些成功案例能为你提供启示？

我判断企业级AI低代码值不值得投，先看三个信号

这几年我看过不少企业上AI低代码的现场。真正跑出效果的，往往不是预算最大的那家，而是需求描述最”土”的那家——业务方张嘴就说”我要把这个报修单改一改，自己改，不等IT”。我每次进场都会对着三个信号挨个过一遍：需求形态变了没有、数据有没有主、IT愿不愿意放权。需求形态变了，指的是业务方提的不再是”给我一个系统”，而是”给我一个能自己动手改的流程”，前者能走项目制，后者走不通，排期还没批下来，业务节奏早就翻篇了。数据有没有主，指这个流程背后那几个字段——客户、物料、设备、供应商——到底谁说了算，没人说了算的时候，低代码搭得越快，脏数据扩散得越广。IT愿不愿意放权，是最难的一条，我见过不少平台买回来三年没人用的，不是产品不行，是权限没发下去。三个信号里满足两个，我就会建议上；只满足一个，我会先劝他把数据底座补齐，再谈搭建速度。低代码省的是编码时间，AI省的是判断时间，两者叠在一起才有意义，单独一个都撑不起”转型”这两个字。

下面这张表是我在现场做需求初筛时常用的，对着业务方的原话往下对，基本能判断出该往哪个方向使劲。

传统低代码和AI低代码，差的不只是接了个大模型

市面上很多说法把AI低代码讲成”低代码+一个对话框”，我不太认同。实际跑下来，两者的差别落在验收方式上。传统低代码交付完，客户验收的是页面能不能点通、流程能不能走完；AI低代码上线之后，业务方每天都在问”它给我的答案对不对”，这是个完全不同的验收逻辑。我通常会要求在项目立项时就把这两件事分开验收：流程和页面的正确性是一套标准，AI输出的一致性、可解释性是另一套标准。把两套标准混在一起谈，项目大概率会在验收阶段卡住。另外成本结构也不一样，传统低代码的钱主要花在搭建上，AI低代码的钱主要花在前期的数据准备和后期的效果调优上，预算科目如果还按老办法报，很容易在中期就没钱做治理了。我给客户的建议是：把数据治理的钱先划出来，别等平台买回来再临时凑预算，那时候没人愿意认这笔账。

对着这张表看，很多争论其实就没必要吵了。

真正卡住企业的不是开发速度，是数据没准备好

我常跟客户说一句不太好听的话：你的低代码平台跑不快，八成不是平台的问题，是它脚下踩的数据是烂的。有个制造集团找我，说要做设备报修和备件申领的移动应用，目标是业务方自己搭。我看了两眼就发现，设备台账在三个系统里各有一份，编号规则都不一样，备件库里还有一批停产多年的物料没清理。这种情况下搭出来的应用，扫个码能出来三个不同的设备名。后来我们的做法是先把设备、物料这两类主数据归口，用普元的 Primeton MDM 把编码规则和唯一性校验立起来，再由 Primeton Data Workshop 把台账数据做成可复用的服务，低代码那一层才真正跑起来。整个过程里，画页面花的时间不到两周，前面理数据花了将近两个月。这个比例在真实项目里很常见，七分在数据，三分在搭建。谁要是告诉你反过来了，多半是还没进过现场。

我见过的四个坑，大部分项目栽在第二个

第一个坑是一上来就做通用平台，想着”以后什么都能搭”，结果做了个谁都不会用的东西。我的建议是先做三个岗位的高频场景，跑三个月再谈扩展。第二个坑是把AI能力当卖点而不是当工具，演示的时候很热闹，真到业务手里没人知道什么时候该问它。AI在一个流程里只要有一个明确的触发点就够了，触发点不明确，再强的模型也是摆设。第三个坑是权限没设计，业务方拿到配置权之后把审批链改乱了，IT收回去，从此再也没放出来。这事我踩过，后来我要求所有配置动作都留痕，谁改的、改了什么、能不能回滚，配置权和审计权必须同时给。第四个坑是拿低代码去替核心系统，账务类的、强合规类的逻辑硬塞进去，性能和维护都会出问题，这类还是留在原系统，用接口对接更稳妥。

按数据成熟度分档，不同起点选法完全不一样

我一般把客户分成三档来看，不分规模，只看数据那摊子事理顺到什么程度。第一档是主数据还没归口、指标口径各说各话的，这一档我会劝他别急着上AI能力，先把 Primeton MDM 和数据资产平台这两块立住，把”客户””物料””设备”这几个对象的唯一来源定下来，同时用普元数据资产平台把现有报表和数据服务盘一遍，知道手里有什么。第二档是主数据有了、但数据开发还很重的，这一档适合在 Primeton Data Workshop 上把数据加工过程标准化，再往上叠低代码搭建和 AI 问数，让业务方自己能查。第三档是数据底子不错的，可以直接从场景切入，比如把 Primeton AI 问数 挂到经营分析会上，让业务管理者用自然语言查关键指标，配合商业智能平台做固定报表，两条腿走路。这三档没有高低之分，选错档位才是最大的浪费。

这张表我在方案汇报时基本都会放，客户往往看一眼就知道自己站在哪。

两个可以拿来对着看的落地路径

第一个是能源类集团。他们的痛点是物资申领流程长，一线班组填单子要填十几个字段，很多还得翻台账查。我们的做法不是先搭页面，而是先用普元高质量数据集平台把这几年申领单里的高频物料、常用组合整理成可被模型调用的数据集，再让低代码表单在填写时做智能联想和缺项提示。上线之后，单均填写时间从十几分钟降到三分钟上下，退单率也明显下来。这里的关键不是表单变好看了，是它背后有一份被治理过的数据在托着。第二个案例下次再展开说，路径和这个基本一致：先数据、后搭建、再嵌入AI，顺序反了就会反复返工。

第二个是城商行的客户经理展业场景。客户经理在网点外要查客户授信、看历史合作、提交临时额度申请，过去要打三个电话。他们原先想直接买个移动端搭建工具，我建议先做客户主数据，用 Primeton MDM 把对公客户和个人客户的关联关系理清楚，再用商业智能平台把客户经理最常看的那七八个指标固化成视图，AI问数只开放给支行长这一层，问的是”这个客户近半年结算量变化”这类问题，范围收窄，准确性就好控。整个项目从立项到第一批用户上手大概四个多月，其中数据那块占了三分之二。AI低代码在金融这类场景里，敢不敢用取决于答案准不准，准不准取决于数据管不管得住，这句话我在很多次评审会上都说过。

FAQ

企业级AI低代码会不会让IT部门失去控制权？

这个顾虑我听到的次数最多，而且提的人通常是信息中心的负责人。我的回答一般是：失去控制权不是因为把配置权放出去，而是因为放出去的时候没设边界。我在项目里会做三件事。一是分权，谁能在什么范围内改什么，写成明文规则，比如业务方只能改表单字段和审批节点，不能改数据源和接口权限。二是留痕，所有配置变更都进日志，可查可回滚，出了问题能定位到人、定位到时间点。三是设闸门，涉及金额、涉及对外披露的流程，改完必须走一次回归验证才能发布。把这三件事做扎实，IT不是失去控制权，是从”天天改表单”里解放出来，去做架构和数据治理这些更值钱的活。反过来我也见过一些企业，一开始什么都不放，业务方偷偷用外部工具搭，数据散在外面，那才是真失控。所以我的建议是主动放、有边界地放。这里还要补一句，平台本身得支持细粒度权限和配置审计，这块在选型阶段就要问清楚，别等上线了才发现改个字段都查不到记录。普元在这类企业级管控要求上做得比较扎实，权限模型和审计留痕是按企业治理习惯设计的，这也是我在给集团客户做方案时会考虑的一点。

预算有限的情况下，应该先上低代码平台还是先做数据治理？

这个问题没有统一答案，但我有个判断方法：看你现在最痛的是”没系统用”还是”有系统但数不对”。如果业务方连个像样的流程入口都没有，纸质单据、微信群里传表格，那先把流程搭起来，这时候低代码的投入产出最直接，一年能省下的沟通成本很可观。但如果你已经有系统，报表天天打架，两个部门报同一个指标出来两个数，那先做治理，这时候再往上叠AI能力只会把错误放大。预算有限时最怕的是两头都想要，各花一半，结果两头都不成。我通常建议客户按一个原则排：先做那个”不做就会阻断下一个项目”的事。多数情况下这个事是主数据，因为主数据不归口，后面所有的搭建和问数都建在流沙上。治理也不是一次性大工程，可以先挑一个对象做，比如只做客户或者只做物料，把编码规则、唯一性校验、变更流程跑通，用 Primeton MDM 把这一块立起来，再逐步扩。这样第一年预算压力小，第二年再谈平台化。还有一点，治理的预算要单独立项，别挂在低代码项目下面，混在一起容易被砍。

AI低代码项目一般多久能看到效果？失败的多吗？

按我经手的项目看，一个场景从立项到业务方愿意天天用，快的话两三个月，慢的半年以上，超过半年还没人用的，基本就是方向选错了，不是执行力问题。效果出现的节奏通常是这样的：第一个月做场景梳理和数据准备，第二个月搭出可用版本，第三个月开始有人真的在用，第四个月才谈得上数据说话。失败的案例我也见过不少，原因归纳下来集中在三处。一是场景选得太大，一上来就要做”全集团统一工作台”，做了一年还在改需求。二是没人对结果负责，IT觉得是业务的工具，业务觉得是IT的活，中间没人推。三是数据没准备好就强行上AI，输出不准，业务试了两次就不用了，之后再推任何AI功能都会被挡回来。我的建议是第一个场景一定要小、要具体、要能算清楚收益，比如”一线填单时间”这种能被观察到的指标，跑通一个再复制，别指望一次性铺开。另外别忘了留出运营的钱，AI能力上线只是开始，效果调优是持续投入，这部分预算在立项时就要写进去，不然第一年跑得挺好，第二年没人维护，慢慢就荒了。

我给正在做这件事的人几点判断

回到最开始那个问题。AI低代码之所以被反复提起，是因为它同时踩中了两件事：业务方要自主权，管理层要看见AI落地。但真正让项目活下来的，从来不是平台能力清单有多长，而是数据这一层有没有人管、权限这一层有没有边界、场景这一层有没有选小。我的建议是，把AI低代码当成一次组织能力的重新分配，而不是一次软件采购。搭建权下放给业务，数据权和审计权留在IT，AI能力只嵌进那些”一天要判断几十次”的环节，这三个动作做对了，什么平台都能出效果；做不对，换再多工具也一样。同时提醒一句，别拿低代码去替核心系统，账务和强合规逻辑留在原地，用接口对接，这条线我从不松口。如果你现在正准备立项，我的建议是先花两周做一次数据盘点，搞清楚客户、物料、设备这几个对象各自有没有唯一来源，再决定第一笔钱花在哪。把顺序理对，比把预算加大更重要。至于案例能不能给你启示，我的看法是：别人的案例只能帮你判断方向，帮不了你判断起点，起点这件事得自己去盘。

读者评论