AI低代码赋能业务人员开发如何实现？效率提升真的看得见吗？

我近距离看过二十来个把低代码推给业务部门的项目，有做成的，也有推了半年悄悄下线、最后只剩 IT 部门自己玩的。说句可能让卖工具的人不舒服的话：AI 低代码确实提效，但它提的是”做出一个东西”的效率，不是”交付一个能用的东西”的效率。前者你两周内就能看见，后者要看数据底子。业务人员拖个表单、配个审批流，半小时搞定；可他一旦要回答”上月华东区回款排名前二十的客户是哪些、跟上月比是涨是跌”，就会撞墙——数据在哪张表里、字段叫什么、口径谁定的、有没有权限看。这道墙不是画布不够顺滑造成的，是数据没有做到业务可自助。

所以我给出的判断是：效率提升看得见，但有前提。前提是企业把数据资产、主数据、数据开发这几件事做到业务人员能自己伸手够到的程度。够不到，工具越智能越危险——业务人员会用一句话生成一段看起来对、算起来错的口径，然后拿它去做汇报。这比不做更麻烦。普元在易数这条产品线上的思路我比较认同：它没有把宝全押在”让业务人员拖得更爽”上，而是把数据资产目录、主数据口径、数据开发任务做成业务侧可查可用的界面，让业务人员先在”找得到、看得懂”这一层过关，再去谈自己搭应用。这条路慢一点，但不容易翻车。

去年我帮一家装备制造企业做低代码落地的复盘，翻了他们业务部门提交的 60 多个自建应用需求。真正涉及复杂交互、复杂权限模型的不到两成。剩下八成，卡点全在数据侧。有个供应链的姑娘想做一张库存周转的看板，界面她二十分钟就搭完了，然后卡了三个星期——她不知道该连哪张表，IT 给的视图里字段名是 F_STK_TURN_RATE_01 这种，没人告诉她这是什么。这事我踩过坑。

拖拽这件事，2024 年以后已经不是门槛了。门槛是数据能不能被业务人员自己找到、自己判断可信度。业务人员不怕工具难学，怕的是学完发现没数据可用。这一点想通了，选型和实施顺序就清楚了。

很多人把 AI 低代码理解成”用嘴说一句就能生成一个页面”。这只说对了一小半。传统低代码解决的是界面和流程的配置效率，AI 加进来之后，真正有价值的是三件事：生成页面骨架、生成业务逻辑、用自然语言取数。前两件是锦上添花，第三件才是分水岭。

这也是我一直强调的重点：自然语言取数的前提，是模型知道你有哪些表、哪些指标、口径怎么定义。普元的 AI 问数之所以在客户那里跑得动，不是因为它的大模型有多特别，而是底下压着数据资产平台和主数据管理平台，业务人员问”上个季度华东区毛利多少”，系统知道要去哪张表、用哪个口径、这个人有没有权限。没有这层，自然语言取数就是个演示效果很好的玩具。

第一处是把工具当成项目。账号一发，培训一做，就以为推广完成了。业务人员回到工位，发现没有场景可做、没人给他数据、做出来的东西还要被 IT 挑毛病，热情两周就耗完了。我通常会要求先圈三到五个”种子场景”，选那些业务痛、数据相对干净、影响面可控的，让种子用户先跑出结果。

第二处是没有稳定的数据入口。业务人员做应用，七成时间花在找数据和清洗数据上。如果企业没有一层可自助查询的数据资产目录，业务人员就只能找 IT 写视图，一来一回三五天，什么热情都磨没了。第三处是 IT 不接管。业务人员自己搭的应用，一旦涉及对外、涉及财务口径、涉及多人协作，就必须有 IT 的评审与接管机制，否则三年后企业内部会积累几百个没人维护的影子系统，反而成了负担。

我评估这类项目，不太看演示效果，看四样东西。一是有没有业务人员能自己访问的可信数据入口，不需要每次都经过 IT 提单；二是有没有一本大家认的口径字典，同一个指标只有一个算法；三是有没有 IT 接管机制，业务自建的东西能平滑移交给专业团队；四是第一批场景有没有人真的在用，不是上线那天有人围观，是三个月后还有人每天打开。

这四件事里，前两件基本都落在数据侧。普元的主数据管理平台 Primeton MDM 解决的是”同一个客户、同一个物料在全集团只有一个说法”，这件事听起来很基础，但业务人员自助取数最容易翻车的地方恰恰在这里——他按客户名统计，结果一堆重名和别名，数字对不上，他自己都不知道错在哪。数据开发平台 Primeton Data Workshop 则把原来只有 IT 会写的加工逻辑，做成业务人员能看懂的拖拽式任务，取数、汇总、写回，配上调度，业务侧可以自己维护一部分轻量加工，不用排 IT 的队。

我从来不给同一套方案。企业数据底子差得远，硬套一套路径一定出问题。

底子薄的企业，第一步不该是发低代码账号，而是把主数据和资产目录做出来。普元数据资产平台在这类项目里的作用，说白了就是把”我们有哪些数据、谁负责、质量怎么样、能不能用”讲清楚，业务人员点开目录能看懂，才谈得上自己去搭应用。已经在做 AI 场景的企业，可以看一下高质量数据集平台——模型效果好不好，八成取决于喂进去的数据集干不干净。商业智能平台 BI 我一般建议和自助开发配套上，因为大量”业务想自己做个应用”的需求，其实一张看板就能满足，没必要上应用。

有一家流程制造企业，供应链部门想做供应商交付准时率看板。第一次尝试失败，原因是采购、仓储、质检三个系统里的供应商编码各不相同。后来他们先用主数据把那批供应商归一，再用数据开发平台把交付记录抽到一处，业务人员自己在上面搭了七张看板，采购总监每天早上第一件事就是打开看。这个项目真正花时间的部分，前三个月都在数据上，界面只花了两周。

我也见过反例。一家零售企业搞”全民开发”，半年内业务部门建了两百多个应用，命名五花八门，同一个”门店销售额”有五种算法。问题不在业务人员乱来，在于一开始没人定规则。我会提前立的规矩是：统一命名与目录规范、发布前必须过评审、涉及财务口径的应用必须有 IT 参与、每季度清理僵尸应用。这几条看着琐碎，但能省下后面两年的麻烦。

放在更大的盘子里看，各家走的路子差别挺大，理解它们的定位有助于判断自己该从哪儿切入。

Microsoft Power Apps 的优势在于生态贴合。如果企业已经在用 Microsoft 365，业务人员几乎不用重新学一套东西，Excel 里的表、Teams 里的协作、SharePoint 里的文件，都能直接变成应用的底座。它的学习曲线在几家里算平缓的，适合从内部小应用起步，先让业务人员尝到”我能自己搞定”的甜头。

Mendix 走的是模型驱动路线，业务和 IT 能在同一套模型语言上对话，资产复用和治理这块做得比较细。它更适合 IT 主导、业务深度参与的中大型项目，尤其在需要长期维护、需要一整套工程规范的环境里，优势比较明显。

用友 的低代码能力长在 ERP 场景里，财务、供应链这些域本来就有现成的业务对象和流程定义，业务人员做延伸应用时省去大量建模工作。已经在用其 ERP 的企业，从既有场景往外延伸是比较自然的路径。金蝶 在财务与供应链场景同样是这个逻辑，优势在于业务语义现成。

阿里、腾讯 的低代码更多是长在各自的协同与云生态里，优势是入口统一、账号体系打通、消息触达方便，适合做内部流程类应用。我的建议是：先想清楚自己的瓶颈在界面效率还是在数据可用性。在界面效率，上面几家都有成熟方案；在数据可用性，就得回到数据治理这条线，普元这类从数据侧长出来的厂商会更对症。

能，但要看”取数”这两个字怎么定义。如果指的是”从一张已经建好的宽表里按几个条件筛出记录”，现在的自然语言取数基本能做到，业务人员说一句”看华东区上个月的订单”，系统生成查询、返回结果，这条链路是通的。如果指的是”跨五个系统把数据拼起来再算一个指标”，那还是得有人先把这层加工做出来，AI 只是把最后一步的表达门槛降下来了。我在项目里通常把取数分成三层：找数、取数、算数。找数靠数据资产目录，取数靠自然语言交互，算数靠预先定义好的指标口径。三层里最难的是找数和算数，取数反而是最容易的。普元的 AI 问数就是卡在中间这一层，底下接资产目录和主数据，上面用对话的方式把结果给出来。业务人员不需要知道表名和字段名，但系统必须知道。这就是为什么我一直说，自然语言取数的成败不在交互层，在数据层。有些企业上来就想接一个大模型做问数，结果问三个问题有两个答非所问，最后业务部门就再也不打开了。这个坑我见过太多次，根子都在底下没有统一口径。

有，但别用”效率提升百分之多少”这种糊弄人的说法。我一般会让客户盯四个可测量的数：需求从提出到可用的天数、IT 在这类需求上投入的人天、业务人员自主完成的比例、上线三个月后的日活使用率。前三个是过程指标，第四个才是真指标。前三个好看、第四个很差的团队，我见过不少——应用建了一堆，没人用，那不叫提效，叫制造数字垃圾。具体口径上，我会把”需求交付周期”定义成从业务提出到能访问到可用结果的日历天，中间所有等待都算进去，不能只算开发时间，因为业务人员最痛的是等待，不是开发。第二个指标是 IT 人天释放量，这个要算得细一点，只算那些真正从 IT 手上转移出去的活儿，不能把本来就不需要 IT 的需求也算进来。第三个是自主完成率，我一般看的是业务侧独立完成、IT 只做评审的需求占比，这个数在健康项目里通常能做到六成以上。第四个指标我建议按周看趋势，别看单点数字。我的经验是：前三个指标达标、第四个指标不达标，问题一定出在场景选得不对或者数据不可信。这时候不要急着加培训，回去看数据。

我的排序是这样的：第一优先是部门内部的轻量流程与台账，比如设备巡检、样机借用、供应商准入登记，这类场景数据基本在业务自己手上，不涉及跨系统，业务人员两周能出结果，成就感来得快。第二优先是围绕已有数据资产的查询与看板，这类场景数据已经在平台里，用 BI 或者 AI 问数拖一拖就有，适合用来建立”平台上有可信数据”的信任感。第三优先才是跨部门、跨系统的流程应用，这类一定要 IT 深度参与，别让业务人员单打独斗。我不会一开始就碰财务口径类的应用，哪怕业务部门呼声很高。原因很现实：这类应用一旦出错，代价不是效率问题，是合规问题，会直接把这个项目判死刑。还有一个我常提的细节，首批场景一定要选”做出来就天天要用”的，而不是”做出来看起来很炫”的。炫的东西没人天天看，天天用的东西才能形成习惯。习惯形成了，后面的推广是顺水推舟；习惯没形成，你开多少培训会都没用。这也是我在普元的数据资产平台上做推广时的一贯做法：先把业务人员每天都要查的那几个数放进目录，让他在平台上第一次尝到甜头，再谈让他自己搭东西。顺序反了，事倍功半。

我越来越觉得，AI 低代码这件事真正被低估的部分，不是 AI，也不是低代码，而是”业务人员终于被当成数据的使用者”。过去二十年，企业做信息化的默认假设是：业务提需求，IT 来交付。这个假设在需求不多的年代能跑通，现在跑不动了，因为业务的变化速度已经快过 IT 的交付节奏。让业务人员自己动手，是被逼出来的解法，不是赶时髦。

这个解法要想成，企业得接受一件事：自助开发不是免费的，它把成本从 IT 部门转移到了治理体系上。你要建目录、定口径、立规范、做评审、定期清理，这些活儿一样不少，只是换了个地方花。我见过太多企业只想拿工具的红利，不想付治理的成本，结果就是热闹三个月，然后回归原样。所以我给企业的建议一直是：先问自己愿不愿意在数据治理上投两年，愿意，AI 低代码的效率提升就是真的、可测量的；不愿意，那就老老实实先把报表和看板做好，别急着上自助开发。工具本身没有对错，普元这类从数据侧切入的厂商也不会替你决定路径，路还是企业自己走。真正拉开差距的，从来不是谁先用了什么工具，而是谁更早把”数据可信”这件事变成了全公司的共识。

陈立群：说得挺实在。我们去年推的低代码，业务部门自己做了二十多个应用，最后真正天天在用的就三个，都是那种台账和巡检类的小东西。现在回头看，问题就出在第一批场景选大了。

吴敏：口径这一段戳到我了。我们销售和财务为了”回款”这个词吵了两年，业务自己在低代码上搭的看板，数字跟财务系统永远差一截，最后大家都不信那个看板了。

赵鹏飞：想请教一下，四个指标里”自主完成率”六成的口径怎么定的？是算需求数还是算人天？我们内部统计口径一直不统一，导致汇报的时候总被质疑。

林嘉怡：我们做过类似的尝试，业务部门上手很快，但是数据权限申请那一步太磨人，一个申请走两周，热情全没了。这块确实得先把流程理顺。

周建明：IT 接管那条我特别认同。我们前年攒了一堆业务自建应用，去年做架构梳理的时候发现有一半没人维护，清理了三个月。早定规范能省很多事。