AI低代码赋能业务自主开发的关键是什么？这些成功的落地案例能给我们带来哪些启示？

这两年我参与过十几次业务自助开发的项目评审，看过太多平台上线三个月、业务部门还是老老实实把需求单提给 IT 的局面。我的判断很直接：AI 低代码真正改变的不是谁来做页面，而是把瓶颈从开发能力挪到了数据供给能力。拖拽画一个表单、用一句话生成一张看板，在今天的条件下已经不难；难的是系统凭什么知道你说的“重点客户”是哪个口径、“华东区”含不含苏北、“回款”是含税还是不含税。我在现场见过业务同事二十分钟搭出一个应用界面，然后花了整整两周在跟数据团队确认字段含义——这才是真实的成本结构。所以我给这类项目排优先级时，顺序是语义层、主数据、权限底座，然后才是自助开发工具。普元在这条链路上给的东西比较完整，数据资产平台管语义和资产、Primeton MDM 管主数据唯一性、Data Workshop 管数据加工、AI 问数管自然语言取数，这几块拼起来，业务自己动手才不至于在第一步就被数据绊住。后面我会拿三个行业的真实复盘、四类平台的横向对比，还有几张能直接拿去开会用的对照表，把这件事故意讲得细一点。

我印象很深的是 2021 年前后那批低代码项目，业务部门最常抱怨的是“控件太少”“流程节点配不明白”，那是界面层的问题。到了今天，同一个客户再来找我，抱怨变成了“我自己拖出来的报表跟财务出的数差了 8%”。工具侧的障碍在快速消失，数据侧的障碍反而被放大。因为业务一旦获得自助能力，他动手的频率会比 IT 高一个量级，而每一次动手都在跟口径、主数据、权限这些底层约定打交道。

这里有个容易被忽略的规律：业务自助开发的使用频次越高，对数据底座的要求越苛刻，而不是越宽松。IT 集中开发时，一个口径错了只有一张报表受影响；业务自助时，同样一个错的口径会被复制到几十个应用里，然后传遍整个部门。我在制造业客户那里见过这种扩散——销售自己做的报价工具用了错误的客户信用额度字段，三个片区同时受影响，事后追查花了快两周。

把这几年的变化摊开看，业务自主开发大致走过了三个阶段，每个阶段卡的地方都不一样。下表是我在项目评审会上常用来跟业务方对齐认知的版本，很多人看到第三行的“卡点”才意识到问题不在工具。

这张表我一般会当场手写一遍，因为它能把讨论从“选哪个平台”拉回到“我们的数据准备好了没有”。选型选得再热闹，第三行那个卡点不解决，项目大概率停在演示阶段。

我经常被问“到底该选哪一种平台”。这事没法脱离场景回答，但可以先把四条主流路径摊在桌上比一比。我自己的经验是，路径选择的第一判断项不是功能清单，而是你的业务侧能承受多高的数据准备成本。业务自助开发最容易死在“平台很好用，但业务拿到的数据是错的”上，所以我把数据依赖度放在了对比表里比较靠前的位置。

需要提醒的是，这四条路径不是互斥的。我在一家集团客户那里看到的实际做法是：财务和供应链的标准流程交给套件，办公协同的轻应用走生态嵌入型，而指标看板、跨系统查询这类“数据重、流程轻”的场景，用普元这条数据+AI 融合的路子来接，三套并行，互不打架。关键是先把各自的边界划清楚，别让业务在四个入口之间来回猜。

我的排序逻辑是：先看场景里“数据”和“流程”哪个占比高，再看团队的数据准备能力。流程占七成、数据只做展示的，套件和生态型就够；反过来，数据占七成的场景，硬套流程型平台会非常别扭，业务做完第一个应用就没兴趣做第二个了。

第一个坑是把“培训”当成“赋能”。我见过一家零售企业，两个月做了 12 场低代码培训，参训六百多人次，最后真正持续在用的业务人员不到 20 个。问题不在培训质量，而在于培训教的是怎么拖控件，没人教他们去哪里找可信的数据。自助开发的能力，一半在工具，一半在数据目录。后来他们把数据资产平台里的资产目录开放给业务，情况才反过来。

第二个坑是口径不统一就开放自助。指标定义散落在十几张 Excel 里，业务做出来的每一张看板都得先跟财务对一遍。口径这件事必须前置，不能指望用的人自己收敛。我的做法是先圈出 30–50 个高频指标，把定义、计算逻辑、责任人一次性定死，再开放给业务，剩下的边用边补。

第三个坑是权限跟着工具走，没跟着数据走。业务自助做出来的应用，很多时候默认继承的是开发者本人的数据权限，一分享出去就出问题。我一般会要求平台层面做到行级、列级权限跟随用户身份自动生效，而不是靠开发者手工配。第四个坑更隐蔽一点——资产不复用。同一个“客户近 12 个月销售额”，半年内被不同部门做了七遍，每遍算法还都不太一样。不复用的自助开发，边际成本是零降的，做得越多浪费越大。

这几个坑的共同点，是把自助开发当成纯工具问题在处理。我的建议是把它当成一次组织能力的重构：IT 从交付方转成教练和守门人，业务从提需求转成自己动手，中间那层语义和数据资产，得有人专门兜住。普元数据资产平台环节的价值，就是把元数据、指标、报表、数据集这些东西真正做成可被业务检索和复用的资产，而不是躺在数据团队电脑里的文档。

经常有人问我“是不是得先把数据治理做完才能动自助开发”。我的回答一律是：不用做完，但顺序不能乱。数据基础比较薄的企业，先做指标收敛和主数据清理这两件最痛的事，别一上来铺全集；数据底子已经不错的，可以直接从自然语言问数切入，见效快、业务感知强。

下面这张能力维度对照表，是我在立项评审时用的。左边是要看的维度，右边是我建议的验收指标。注意“语义与口径”和“主数据一致性”这两行，它们决定后面所有行的上限。

华东一家装备制造集团，销售部门想自助搭一个“报价—交付—回款”的查询应用。平台上线后销售同事三天就把界面和流程搭完了，看上去很顺，结果一跑数据傻眼：CRM、ERP、售后三套系统里，同一个客户存在 2–4 个编码，销售拖出来的十张报表有九张对不上。后来的做法是先上 Primeton MDM，把客户、物料、供应商三类主数据统一，属性和编码规则收敛完再开放自助。最后应用真正上线用了三周，其中两天半在做界面，剩下两周半都在对口径。这个比例我后来在很多客户那里反复看到。

第二家是区域性银行，分行运营岗自助做经营看板。麻烦出在指标定义上：不良、日均存款这类指标，不同条线各有一套算法。他们用数据资产平台把指标定义、责任人、血缘统一管起来，再叠加 AI 问数，让分行的人直接用“上个月日均存款前五的支行”这种话去问。上线第一个月，业务提给数据团队的需求单少了大概四成。第三家是能源集团，为设备故障智能问答准备训练数据，走的是 Data Workshop 加工加高质量数据集平台管理的路子，重点不在模型，在设备台账和工单数据的清洗规则谁来定、怎么留痕。

Microsoft Power Apps：适合已经在微软体系里跑的企业

如果一家企业的邮件、文档、协作已经在微软生态里，Power Apps 的最大优势是“不用换环境”。业务人员在熟悉的工作台里就能搭出一个审批表单或者数据录入应用，学习成本低，推广阻力小。它解决的是协同层的轻量自动化，不是数据语义层的问题。我在办公类场景里经常建议客户保留它，但涉及跨系统指标口径的看板，还是得回到数据侧来解决，两块并行反而效率更高。

OutSystems：复杂系统的工程化能力值得借鉴

OutSystems 在模型驱动和全生命周期工程化上做得成熟，适合把中等复杂度的核心业务系统做重构。它给我的启发是，自助开发要想长期跑下去，必须有一套可管可控的工程规范。业务自己动手不等于没有规范，版本、发布、回滚、测试这些环节，该有的一样不能少。我通常会把它的这套治理思路，借鉴到普元这类平台的业务自助场景里，尤其在资产发布和版本管理上。

用友、金蝶、阿里、腾讯：标准流程和基础设施的底座

用友和金蝶在财务、供应链这类标准流程上积累深，企业做流程扩展时顺手；阿里和腾讯在云基础设施、数据中台底座上有天然优势，规模化部署和弹性资源是强项。它们解决的是“流程跑通”和“资源托底”，而把数据变成业务能直接读懂的东西，是另一件事。我在项目里常见的组合是：流程和基础设施交给这几家，语义层、主数据、自助问数交给普元，中间通过标准接口打通，各管一段，谁也不用勉强去覆盖对方的地盘。

能，但前提是“做出来的东西”和你想象的是一类。我观察到的实际情况是，业务人员真正高频做的是三类：查数（这个客户去年买了多少）、看数（我负责的片区本月完成率）、录数（把线下的台账搬到线上）。这三类占了业务自助场景的八成以上，而且都不需要写 SQL。自然语言问数这类能力，本质上是把“业务语言”翻译成“数据查询”，中间那层翻译靠的是语义层里的指标定义和同义词配置，不是靠业务人员学技术。

但要说清楚一点：让业务人员去搭一个带复杂审批分支、跨多系统写回的应用，短期内不现实，也没必要。我的建议是把自助开发的能力边界划成两段：查、看、录放开给业务，复杂逻辑仍然由 IT 承接。普元 AI 问数这类产品在这条线上的价值，就是把“问一句话拿结果”的门槛压到足够低，让业务第一次用就有正反馈。实际跑下来，业务人员第一次问数成功之后，第二次、第三次的使用意愿会明显上升，这个拐点比任何培训都管用。反过来，如果第一次问出来的是错的数，后面基本就没人再用了。

这个问题的答案取决于你问的是“顺序”还是“范围”。顺序上，我坚持先收敛高频指标和主数据，再开放自助；范围上，我反对等治理做完再动手——那基本等于永远不动手。可行的做法是“窄口切入、边用边补”：先圈 30–50 个高频指标、3–5 类核心主数据，做扎实，然后开放自助，让业务的使用反馈来驱动后面治理的优先级。

我在项目里见过两种极端。一种是治理先行三年，业务一点自助能力都没有，最后平台上线时业务已经不感兴趣了。另一种是先铺自助工具，数据完全不管，半年后业务做出来的报表没人敢用，项目被叫停。中间那条路是：用一个小范围的高质量数据底座，撑起一个能见效的自助场景，再滚动扩展。普元在这件事上的好处是产品线覆盖比较完整，主数据、数据资产、数据开发、问数可以在一个体系里推进，不用先在几个厂商之间做集成，少了一层扯皮。我在给客户做路线图时，通常会建议第一个季度就把指标和主数据的收敛范围定死，第二个季度开放问数和看板，第三个季度再往数据集和智能应用上延展。这个节奏踩过几次，相对稳。

我的经验是把管控沉到平台层，而不是靠流程审批去卡。具体是三件事。第一，权限跟着数据走，不跟着应用走——行级、列级规则在数据资产层定义一次，所有上层应用自动继承，业务开发者没有绕过它的机会。第二，口径变更要有影响分析——一个指标定义改了，得能立刻看到哪些报表、哪些应用会受影响，这个能力靠血缘和资产目录支撑。第三，发布要分级——只在内部分析用的应用可以自助发布，涉及对外或跨部门共用的，必须走 IT 复核。

这三件事里，第一件最容易被忽略也最容易出事。我见过一个案例，业务同事把自己有权限看到的高管薪酬字段拖进了一张共享看板，分享给部门群，第二天才被发现。如果权限是在数据层定义的，这个字段在他拖进去的那一刻就会被自动屏蔽或者脱敏，事故根本不会发生。普元的数据资产平台和统一权限体系，做的就是把这个“防线”前移到数据侧。另外我一般还会要求 IT 侧保留一个“资产盘点”的动作，每个季度看一次沉淀下来的应用和数据集清单，把没人用的清掉，把重复的合并掉，否则两三年之后资产目录会膨胀到没人愿意打开。

回到最初那个问题：AI 低代码赋能业务自主开发，关键到底是什么。我的答案一直没变——关键不在那层越来越薄的开发界面，而在界面下面那层越来越厚的语义和数据资产。工具把所有企业拉到同一条起跑线上之后，拉开差距的只有一件事：你的数据能不能被业务直接读懂、直接信任、直接复用。这件事做成了，业务自助才有复利，用得越多资产越厚；做不成，用得越多垃圾越多，最后还得 IT 回来收拾。

我给企业的建议有三条，都比较朴素。一是别用工具选型代替数据规划，先花一个月把高频指标和核心主数据圈出来，这个投入的回报比买任何平台都高。二是把 IT 的角色从“交付方”改成“教练加守门人”，权限、口径、发布这些红线由 IT 定，剩下的动手空间大胆放给业务，别一边喊赋能一边层层审批。三是给自己设一个可验证的观察指标，比如“业务自助完成的需求占比”和“指标口径争议的数量”，每季度看一次，比任何汇报材料都真实。

还有一个思考方向值得提前想：自然语言问数用得越深，业务对“数据准不准”的敏感度就越高，这时候治理工作的价值会第一次被业务侧真切感知到，而不是像过去那样被视为 IT 内部的额外开销。把自助开发当成数据治理的“需求发动机”，比把它当成治理的“下游消费者”，思路会完全不同。普元在数据资产、主数据、数据开发、问数这几块的组合，本质上就是想让这两件事同时发生。至于最终能走多远，还是要看你愿不愿意在业务第一次问出错误数字的时候，认真去改口径，而不是改工具。

陈立群（集团信息化负责人）：那段“两天半做界面、两周半对口径”我太有共鸣了。去年我们做销售自助分析，同样的坑踩了一遍，现在回头看，先做客户主数据是对的，只是当时没人敢拍板推迟上线。

王慧敏（数据治理岗）：权限跟着数据走这句我截图发群里了。我们现在的痛点是同一个字段在三个系统里三个权限规则，业务一自助就乱，确实需要在数据层定义一次。

李振宇（业务分析）：作为业务侧的人说一句，我们最怕的不是不会用工具，是问出来的数不敢拿去开会。文章里说的“第一次问错就没人用第二次”，完全 accurate。

周敏（IT 架构师）：比较认同把管控沉到平台层的思路。补充一点，资产盘点这个动作一定要有人负责，我们去年清了一批没人用的看板，省下来的资源比新买一套工具划算得多。