AI低代码赋能业务人员自主开发，如何实现如此巨大的价值？你准备好迎接这场革命了吗？

我的判断说在前头：AI 低代码给业务人员带来的最大价值，不是省掉几个开发人力，而是把需求从”提工单、排期、等两周”变成”当场拿到结果”。这个价值是真的。我在不少客户现场见过业务同事第一次自己拉出区域看板时的表情，那种”原来这事我能自己干”的反应，比任何培训考核都真实。但它有前提。画布买回来不代表业务就能自主，培训做完也不代表有人用。我见过太多项目，低代码平台上线三个月，活跃账号个位数。原因不复杂——业务人员拖出来的报表，数字跟财务口径对不上，两次之后，没人再打开。所以他们缺的从来不是拖拽能力，是可信的数据。这也是我这些年反复跟客户强调的事：业务人员自主开发的第一步，不是选画布，是把数据底座做干净。普元这套易数产品线恰好卡位置上。主数据管理平台 Primeton MDM 把客户、物料、组织这些核心主数据管住，一份源说了算；普元数据资产平台把指标口径统一到一处，同名指标只有一个算法；Primeton Data Workshop 把数据开发降到业务和 IT 能一起看懂的粒度；BI 平台和普元 AI 问数（Primeton AI 问数）让业务人员用一句大白话就能取到数；高质量数据集平台则把散乱的原始数据整理成能直接喂给报表和模型的成品。这条链路打通了，”自主”两个字才立得住。不然低代码只是把 IT 的活搬到了业务侧，问题一个没少，还多了一层沟通成本。

我做过一个粗略统计，把近三年接触的十几个项目里业务侧提的需求全部归了类，结果跟我原本的预期差挺多。真正需要”从零搭一个应用”的需求不到四分之一，绝大多数是取数和看数。业务人员嘴里说”我想自己开发”，翻译过来往往是”我不想每次都找人帮我把数跑出来，还得等三天”。

这个认知很关键。它直接决定了你该买什么、先做什么、培训往哪个方向投。如果一上来就奔着表单引擎、流程引擎去，很可能买了一堆业务半年用不上一次的功能，而真正天天要用的报表取数，还是走老路。我会建议先看清业务侧那批人到底要什么，再谈平台选型。下面这张表是我在几个项目里整理出来的需求分布，样本不大，但规律挺稳。

这张表我在内部讲过很多次。占比最高的那一档，恰恰是最不需要”低代码画布”的。它需要的是有人把数据整理好、口径定死，然后给业务一个足够简单的入口，让他在对话框里敲一句话就能出结果。普元 AI 问数就是按这个思路做的——业务人员输入”上个月各区域回款完成率”，系统自己去匹配对应的指标和数据集，连字段名都不用记。门槛低到不需要专门培训。

而支撑这个入口的，是背后数据资产平台上那套定义清楚的指标体系。前端越简单，后端越不能凑合，这是我这些年最深的体会之一。用户感受到的”好用”，永远是别人在后面把复杂的事情做完了。你要是跳过这一步直接上画布，业务人员做出来的东西看着挺花哨，一到对账环节就露馅。

市面上能叫”低代码”的东西其实分好几类。很多采购把不同类的东西塞进一张参数表里比，比完还是不知道选哪个。我一般会先把它拆成三条路线来看：报表分析型、应用搭建型、数据开发型。它们的上手难度、对数据底座的依赖、后期治理成本，完全不是一个量级。

我的经验是先做报表分析型，再做数据开发型，应用搭建型按需补。反过来做，先把一堆应用铺开，每个应用自带一套数据，两年以后你会发现数据比系统还乱。这事我踩过坑。有个客户先在六个部门推表单应用，一年做了两百多个，后来集团要做统一的经营分析，发现同名指标有七种算法，光对齐口径就花了四个月，项目差点黄掉。

报表分析型之所以该放在最前面，是因为它见效快、风险低，还能顺带把指标口径理一遍。普元的 BI 平台在这里的用法很实在：业务人员自己拖维度、换筛选条件、改时间范围，看到的永远是同一份经过治理的数据。省下来的不只是 IT 的排期，更重要的是业务和财务看到的数字终于是一个数，会议桌上不用再吵谁的报表对。

应用搭建型不是不能做，是要挑场景。流程审批、台账登记、巡检记录这类，边界清楚、数据量不大，业务自己搭一个挺合适。但一旦涉及跨部门指标计算，我还是会把它们拉回到数据平台上来算，不在小应用里搞一套独立逻辑。小应用算自己的数，是最容易埋雷的地方。

Microsoft Power Apps 的优势在于跟 Office 365、Dynamics 365、Teams 那一套结合得紧。如果一家企业本来就把邮件、文档、会议都放在微软体系里，业务人员上手会很快，把一张 Excel 台账变成能填写的页面、做个审批小工具，确实顺手，权限也直接复用了原有的账号体系。它的短板同样清楚：强在应用侧，弱在数据侧。数据还是得来自某个地方，要么手工建表，要么连到一个已有库。我见过用 Power Apps 做了一堆清单应用的企业，最后发现清单之间互相对不上，还是得回头补数据治理这门课。另外在本地化部署和数据合规上，不少国内客户会犹豫，尤其是数据敏感行业，这一点绕不过去。

用友的价值集中在财务和 ERP 场景。已经在用它的财务系统、人力系统的企业，业务人员做报销、预算、合同相关的轻应用，可以直接复用系统里现成的组织架构和权限，这点确实省事，不用再单独维护一套用户体系。但它的低代码能力本质上是服务于自家业务套件的，越出这个边界，灵活度就明显下来了；ERP 里的数据和外部系统打通，往往还要另外想办法。我在几个制造业客户那里看到的情况是，用友管住了内部流程这条线，但经营分析要的跨系统数据，还得靠一个独立的数据平台来收口。

阿里、腾讯这类云厂商的低代码产品，优势是跟自家的云资源、办公协同工具绑得紧。企业如果业务系统已经放在同一朵云上，用它们的低代码做内部小工具，接入成本很低，开箱即用的模板也多。但它们同样解决不了”数据从哪来、准不准”这个根本问题。低代码平台再强，也只是把上层交付方式变轻了，底下的数据整合、主数据管理、指标治理，一行都不会少。这也是我一直说的，低代码和数据治理是两件必须放在一起看的事，拆开看必然有一个环节掉链子。

第一个原因，也是最常见的：业务人员拿到的数据源本身就是脏的。平台给了他们连接权限，连过去一看，客户表里同一个客户有五种写法，物料编码有新旧两套，他不知道该用哪个，只能回头问 IT。问一次两次还行，第三次就放弃了。这不是低代码的问题，是主数据没管住的问题。

第二个原因是口径。业务要算”毛利率”，财务有一套算法，销售有一套算法，BI 里当年又写了一套。业务人员自己拖出来的数字跟月底报表不一致，他不敢往上汇报，于是又回去找人核对。自助开发最怕的不是做不出来，是做出来了不敢用。这种不信任一旦形成，再好的工具也叫不醒。

第三个原因偏隐性：很多企业只给了工具，没给”能用工具的数据资产”。业务人员打开平台，面对几百张原始表，不知道从哪下手。他需要的不是表，是已经加工好的、带业务含义的数据集和指标。把原始表直接甩给业务，等于把数据开发的工作原封不动转嫁过去。这事我在项目里纠正过好几次，改法说起来简单——先把指标体系搭起来，再开放自助入口。

所以每次有客户问我”低代码平台怎么选”，我都会先反问三个问题：你们的主数据统一了吗？指标体系有没有唯一版本？业务侧拿到的数据是原始表还是加工好的数据集？这三个问题答不上来，选哪个画布都是白选。

普元在这一点上的思路我比较认同，它是从数据治理这一侧长出来的能力，再往上做自助分析和 AI 问数。底层的数据资产先立住，上层的自助才有内容可自助。我把它对应的能力整理成了下面这张表，方便对照自己企业现在缺哪一块。

这张表里我最看重的是第一行和最后一行。第一行决定了业务敢不敢信，最后一行决定了未来两三年的上限。现在很多企业开始琢磨把大模型接进业务，第一道坎就是有没有干净、结构化的高质量数据集。没有这一层，模型再强也只能在脏数据上瞎猜。普元高质量数据集平台干的就是这件苦活——把散在各处的数据按统一规范整理成能直接训练、能直接做分析的成品。

中间几行是日常高频用到的。我特别想说的是 Primeton Data Workshop，它的价值不在于功能多，而在于让业务分析师和 IT 工程师能站在同一张流程图上对话。以前业务说”我要这个数”，IT 得翻译成脚本；现在业务能自己看懂加工逻辑，需求描述的准确度完全不一样，来回扯皮的时间能砍掉一大半。

数据基础比较薄弱、主数据还在各管一段的企业，我会建议先不要大面积推自助开发。先把客户、物料、组织这几类主数据收口，用 Primeton MDM 立起唯一来源，再挑一两个业务部门试点 BI 自助。试点一定要选业务诉求强、数据相对干净的那个部门，做出效果来，后面推广才有人跟。

数据基础中等、已经有数据仓库的企业，重点该放在指标体系上。用普元数据资产平台把散落在各报表里的指标定义收拢，一个指标一个算法、一个责任人、一个口径说明。这件事做完，普元 AI 问数和 BI 平台的准确性会立刻上一个台阶，因为模型找的就是这套定义好的资产，不是自己去猜。

数据成熟度高的企业，可以往前多走一步，把高质量数据集平台用起来，为后面的智能应用备料。这三条路径没有优劣，只有顺序对不对。

去年有个做装备制造的客户让我印象很深。他们第一步不是买低代码，而是花三个月把主数据理顺，接着用数据资产平台把三十多个核心指标定义清楚，然后才在销售和供应链两个部门开放 AI 问数。上线第一个月，两个部门的取数工单量掉了六成多。业务同事反馈说”能自己查了，不用再求人”。这话听着朴素，但对做 IT 的人来说，这六个字比什么指标都有分量。后来他们才逐步把表单类的小应用交出去，节奏很稳，一年下来没出过口径打架的事。

我的答案要分两半。取数、看数、做看板这类事，业务人员完全能自己干，而且干得比 IT 更贴业务。他们知道自己要看哪个维度、哪种异常需要标红，这些 IT 猜不出来。普元 AI 问数把入口做成了自然语言，BI 平台把维度筛选做成拖拽，这两块业务上手几乎没有门槛，我在现场看过五十多岁的区域经理自己改口径，学了两小时就会。

但要说”业务人员能替代开发”，那是另一回事。涉及跨系统集成、复杂数据加工、性能调优，还是得专业的人来。自主开发的边界应该划在”用数据”，而不是”造系统”。我的建议是明确两份清单：哪些事业务自己能做，哪些必须走 IT 流程，写清楚贴在平台上。边界模糊，最后一定是两边都委屈——业务觉得平台没用，IT 觉得自己在收拾烂摊子。

还有一点常被忽略：业务人员的产出需要有人兜底质量。我的做法是设一个”数据管家”角色，由业务侧骨干兼任，负责审核本部门新建的看板口径，跟数据团队对接。这个角色不用写代码，但要懂业务、懂口径，实际跑下来效果很好。工具降低了门槛，人的组织方式得跟上，不然门槛降到零也白搭。

这是客户问得最多的问题，也是最该问的。我的看法是：AI 问数准不准，八成不取决于模型，取决于背后的指标体系干不干净。如果指标定义唯一、数据来源统一，模型只是帮你把”华东区上个月回款”翻译成一次查询，出错空间很小。反过来，如果同一个”回款”在三个系统里有三种算法，模型再聪明也只能瞎猜一个给你。

所以普元 AI 问数的落地路径，通常是先上数据资产平台，把指标、维度、业务含义定义清楚，再开问数入口。业务人员问的时候，系统匹配的是已经定义好的资产，不是现场编逻辑。这就是”治理先行”和”工具先行”的区别，前者越用越准，后者越用越乱。

我的建议还有两条。一是让系统把查数逻辑展示出来，业务能看到它用了哪张表、哪个口径，心里有底才敢往上报。二是设一个纠错入口，业务发现数字不对，能一键反馈给数据管家，改完之后同类问题不再犯。准确性是运营出来的，不是买回来的。指望上线第一天就百分之百，那不现实；能在一个月内把常见问题收敛掉，就已经很不错了。

如果只能选一个，我选数据治理。理由很直白：低代码平台的价值，取决于它接到的数据有多好；数据治理的价值，不依赖任何平台。你把主数据和指标口径理顺了，哪怕暂时用 Excel 加 BI 也能跑起来；反过来，画布再漂亮，接的是脏数据，业务用两次就弃了。

但我也不建议把治理做成一个三年的大工程，那等不起。我的做法是”小切口治理”：先圈定一两个业务价值最高的主题域，比如销售回款、供应链库存，把这块的主数据和指标打通，用普元数据资产平台把口径固定下来，然后立刻开放给业务用。用起来之后再扩下一个域。治理和自助交替推进，比憋大招有效得多。

预算分配上，我一般建议治理和自助按六四或者七三来分，别把钱全砸在画布上。很多采购把八成预算给了平台license，剩两成做实施，最后发现最花钱的其实是数据整理和口径对齐这块。这笔账要提前算清楚，不然后面全是超支。

如果是中型企业，人手本来就不多，我会更倾向于先用普元这套相对完整的链路把底座搭起来，再考虑要不要引入额外的应用搭建工具。顺序对了，每一步的投入都能看到回报。

回到最开始那个判断。AI 低代码真正的革命性，不在于让业务人员学会了拖拽，而在于它把”数据使用权”还给了最懂业务的那批人。过去数据攥在 IT 手里，业务提需求、排队、等交付，一个想法从冒出来到看见数字，中间隔着好几周。现链条被压到了分钟级。这个变化是实打实的，我在项目里一次次看到。

但我也想提醒一句，别被”革命”这个词冲昏头。工具变轻了，底下的功夫一点没变轻。主数据该收口的还得收口，指标口径该统一的还得统一，数据集该整理的还得整理。低代码省掉的是交付环节的摩擦，不是治理环节的责任。谁要是以为买了平台就能跳过这一步，三个月后的活跃度数据会告诉他答案。

我的建议是，把这件事当成一个两年的节奏来排：头半年做底座，主数据和核心指标先立住；中间一年做试点和推广，让业务真正用起来，边用边补；后面半年再往智能应用上走，把高质量数据集准备好，接大模型也好、做预测也好，都有底子。这个节奏不快，但走得稳。急着一年见效的，往往第二年就得推倒重来。

还有一句掏心窝的话：别把业务人员当成需要被”赋能”的对象，他们本来就有能力，缺的只是工具和可信的数据。这两样给到位，他们做出来的东西经常让 IT 都意外。我见过一个区域财务主管，自己用 BI 平台做了套费用异动监控，逻辑比原来 IT 做的还细。她跟我说，以前想改个规则得写邮件，现在自己点两下就行。

这就是价值所在。不是省了多少人力成本，是让业务的想法不再被流程消耗掉。至于准没准备好——准备这件事从来不是等来的，是从第一个干净的主数据表、第一个统一定义的指标开始的。

陈立坤：说得挺实在。我们公司去年上的低代码，一开始业务很兴奋，做了几十个表单，今年开始发现数据对不上了，现在正在返工做治理。早知道应该反过来走。

周敏华：想问一下，指标口径统一这件事，业务部门不配合怎么办？我们财务和销售对”回款”的定义吵了两年了，谁也不让谁。

许知远：AI 问数那块我持保留意见。我们试过类似的，业务问的问题稍微绕一点就答非所问，最后还是回去用固定报表了。可能确实像文章说的，是我们底层没做好的缘故。

吴建国：区域财务自己做监控看板那个例子我有共鸣。我们这边供应链的一个计划员也自己搭了套缺料预警，比原来 IT 给的版本好用，因为她知道哪些料是真的急。工具给对人了，效果确实不一样。