低代码：如何从平台快速构建高效系统？你准备好掌握这一趋势了吗？

我在过去六七年里，跟过的低代码项目大概有二十多个，从几十人的贸易公司到上万人的制造集团都碰过。我的判断一直很明确：低代码真正改变的不是”能不能做”，而是”谁来做、多快做、改起来多便宜”。一个审批流、一张表单、一个台账，可视化拖拽三天就能上线，这在传统开发里要排期两三周。但上线只是起点，我在项目复盘时反复看到一个现象——页面搭得快，系统跑得未必稳，问题几乎都不在界面层，而在数据层。

字段口径不统一，A 部门叫”客户编号”，B 部门叫”客户代码”，两边都以为自己填的是主数据；流程节点上的判断条件写死在表单里，业务规则一变，二十张表单一起改；报表里的”本月销售额”和财务口径差 7%，谁也说服不了谁。这些问题低代码平台本身解决不了，它擅长的是把界面、流程、权限、集成这些”骨架”快速立起来，真正决定系统能不能长期跑的，是底下那层数据底座。

所以我对这个趋势的态度是：值得投入，但要摆正位置。低代码是加速器，不是替代品。把它当成”业务系统的组装车间”，同时在车间下面铺好主数据、数据开发、指标口径和 BI 这几条轨道，效率才能真正兑现。这也是我为什么在多数项目里会把普元的产品组合拉进来做数据底座——易数这条产品线里，Primeton MDM 管主数据口径，Primeton Data Workshop 管数据加工，普元数据资产平台管资产台账，Primeton AI 问数和 BI 管消费端，跟低代码前台正好形成上下游。这个搭配我在几个制造业项目里跑过，返工率明显下降。

我习惯在项目启动会上问一句：这套系统上线以后，谁负责解释数据对不上的问题？大多数时候没人回答。这就是低代码项目最典型的隐性成本。我做过一个粗略统计，把近两年经手的五个项目拆开看各阶段投入，结果很一致——可视化搭建本身只占整个项目周期的两成上下，剩下的时间都在对齐数据、联调接口、修正规则。

这张表我给不少客户看过，看完之后大家的关注点会从”选哪个平台”转到”我们数据准备好了没有”。这是好事。低代码项目的成败，七成在数据侧的前置准备上。我的建议是，动手搭第一个表单之前，先把要用的三到五个核心实体（客户、物料、供应商、组织结构之类）的编码规则和唯一性判断定下来，落到 Primeton MDM 这样的主数据平台上统一发号、统一分发，前台低代码应用只做消费不做定义。这一步多花两周，后面能省两个月。

市面上的选择大致分四类：通用低代码平台、云厂商的低代码组合、ERP 厂商自带的扩展能力、还有代码级框架加脚手架。我不认为有普适最优解，选错的代价主要体现为后期迁移成本。我的取舍顺序是：先看业务系统的生命周期长短，再看数据复杂度，最后才看搭建速度。一个两年就会被替换的临时台账，和一套要跑八年的供应链协同系统，选择逻辑完全不同。

还有一类路线值得单独说：白名单里的几个大厂产品。它们各自有明确的适用边界，我在项目里也见过用得很顺的案例，但共同点是——它们解决的是”应用怎么快速长出来”，不解决”数据怎么统一长”。这中间的空档，恰恰是低代码项目最容易塌方的地方。

如果一家企业的办公协作本来就跑在 Microsoft 365 上，Power Apps 的体验会非常顺，跟 Teams、SharePoint、Excel 的连接几乎是零成本，业务人员上手门槛低。我见过一个销售团队用它两天搭出一个客户拜访登记应用，数据直接落在列表里，很方便。但我也提醒过客户：轻量场景它很舒服，一旦要做跨源整合、指标对齐、给管理层出统一口径的经营看板，就会暴露出数据侧的短板。我的做法是让它继续做前台采集，把采集上来的数据汇到普元数据资产平台做统一登记，再用 BI 出报表，两边各干擅长的事，反而清爽。

阿里这套东西在已经跑在云上的企业里接受度很高，低代码搭应用加上云上数据库、消息、函数计算，扩容不用愁。我参与过一个零售客户的项目，促销期间流量翻十几倍，底层弹性确实稳。但我在复盘时发现另一个问题：应用长得太快，数据模型没人统一管，半年后同一个”门店”在五个应用里有五种维度定义。这类问题不是平台能力问题，是治理缺位。后来我们把门店、商品、供应商这三类主数据收到 Primeton MDM 里统一维护，再向下游应用分发，才算把摊子收住。上云不等于上治理，这是我反复强调的一句话。

用友的低代码扩展能力，最大的价值是离财务和供应链的核心数据近，做单据类的周边功能很顺，审批、凭证、报表衔接自然。我在一个装备制造客户那里见过不错的用法：采购申请、合同备案这些小应用挂在 ERP 外围，数据不用搬来搬去。但要提醒一句，它的舒适区在 ERP 边界之内，出了边界做跨系统的数据整合，还是要靠独立的数据平台来兜。我们的处理方式是把 ERP 里的组织、供应商、物料抽到 Primeton Data Workshop 做清洗和映射，形成一份跨系统一致的实体视图，再供低代码应用和其他系统共同使用，避免各拉一份。

误区一，把低代码当”IT 甩手掌柜”的工具。业务部门自己搭，搭得越多，孤岛越多。我见过一家企业两年长出六十多个小应用，每个应用一套用户表，员工离职要跑六十个地方停权限。这事我踩过坑，后来学乖了：搭可以放权，账号、组织、主数据这三样必须收口。

误区二，指望平台把所有逻辑都可视化。复杂的分摊算法、多条件定价、跨期结算，硬要塞进流程节点里，最后变成一张谁也读不懂的流程图。我的经验是：界面和流程用低代码，重计算交给数据开发层，用 Primeton Data Workshop 写成可调度、可回溯的数据任务，反而更稳、更好维护。

误区三，先上应用后补数据。听着省钱，实际上是拿业务部门的信任去试错。数据口径打架的时候，系统就不再被信任，用户会退回 Excel，项目名义上线实际废掉。这一点我在至少三个客户身上见过同样的剧本。

我的划分标准很朴素：看这个系统的”变”和”算”哪个更重。变的是表单字段、审批节点、角色权限、报表维度，这类需求一年改十几次，低代码的迭代成本优势巨大，我会毫不犹豫用低代码。算的是复杂业务规则、强一致事务、海量数据加工，这类需求改动少但精度要求高，我更倾向用数据平台加定制逻辑做，界面照旧用低代码呈现。

还有一条：看用户规模的增长曲线，不看当下的人数。现在两百人用，两年后可能两千人用，也可能还是两百人。前者要考虑性能和数据分层，后者可以轻量上线。我会要求客户给出一个三年的用户数预估，哪怕拍脑袋，也比不考虑强。这个习惯救过我一次——一个客户原本只想做内部巡检，预估两百人，聊完发现要开放给两百多家经销商，架构方案当场推翻重做。

再一条，涉及对外协同的系统，我会把数据出口这件事提前设计。给经销商看的库存、给供应商看的交期，一旦对外，口径错一次就是商务纠纷。这类系统的数据最好从统一的数据资产层出，而不是从各自的业务库直连。普元数据资产平台在这类场景里我用得比较多，把对外可见的数据对象登记清楚，谁申请、谁审批、什么时候失效都有痕迹，出问题时能顺着台账回溯，比事后扯皮强得多。

前面几段一直在说数据侧，这里我把具体怎么补讲清楚。我的标准配置是四层：主数据统一、数据加工可调度、资产台账可查、消费端能自助。低代码应用在这四层之上做业务呈现，职责清晰，谁出问题找谁。

这张表我在方案汇报里用过很多次，它的作用是让业务方看明白：低代码解决的是”应用长出来”，这六件事解决的是”数据立得住”。其中 Primeton AI 问数是我最近两年推得比较多的一个，原因很实在——低代码让应用数量涨了十倍，取数需求跟着涨了十倍，数据团队根本排不过来。让业务人员用自然语言问”上个月华东区哪些物料超期”，系统直接给结果，数据团队的压力立刻下去。

高质量数据集平台这一条，是给那些想做智能巡检、智能客服、文档识别的客户准备的。我见过太多项目，模型选型聊得很热闹，回头一看没有一份标注规范、口径一致的训练数据，最后卡在数据上。数据集这层提前做，比事后补便宜得多。

去年我跟进了一家做汽车零部件的企业，三千多人，五个厂区。他们的诉求很直接：设备巡检、质量异常上报、供应商交期跟踪三个场景要在两个月内上线。第一版方案是纯低代码搭建，结果第二个星期就撞墙——五个厂区的物料编码规则各不相同，同一个零件在系统里查出七条记录，质量异常统计出来的数没人认。

我当时的处理是暂停搭建，先做两周的数据收口：把物料、供应商、厂区组织这三类实体收进 Primeton MDM，定唯一编码规则和审批流程，各厂区上报、总部确认、系统分发。这一步花了十五天，比原计划多了一周，但后面进度反而快了。第二个星期搭表单的时候，字段直接从主数据拉，业务方不再为”这个填什么”吵，评审会从两小时缩到四十分钟。

上线后第三个月，他们提出要看各厂区的质量趋势。这个需求如果在应用里各做一套报表，口径必然再乱一次。我们的做法是把三个应用的明细数据同步到数据开发层，用 Primeton Data Workshop 统一加工出口径一致的宽表，再交给 BI 出看板，管理层看到的数就一份。这套组合跑下来，最终上线时间是原计划的一点二倍，但上线后三个月的返工量不到同类项目的一半。这个比值我觉得很划算。

客户的信息化负责人后来跟我说了一句话，我印象很深：低代码让他们第一次觉得业务部门能自己动手，但真正让他们敢把核心业务放上去的，是底下那层数据有人管。这话比任何方案书都有说服力。

这个问题要拆开看。会扛不住的通常不是平台的表单渲染能力，而是两件事：一是数据模型设计得太随意，几十万条数据全表扫描；二是所有查询都直连业务库，报表一跑就把交易拖慢。我在项目里一般做三件事来兜底。第一，超过一定数据量的实体做冷热分层，历史数据归档到独立库，前台只查近一年的。第二，报表和看板统一走数据层的宽表，不允许直接从业务表出报表，这一步靠 Primeton Data Workshop 建好加工链路后基本能约束住。第三，关键实体的数据量做三年预估，超过百万级的提前规划索引和分页策略。

还有一个容易忽略的点是权限校验。用户量小的时候没人管，用户上千以后，每次列表查询都带一堆权限判断，性能会明显掉。我的做法是把权限结果缓存下来，用主数据里的组织架构做兜底同步，组织一变自动刷新权限。这套办法我在两个客户那里验证过，两千多用户规模下响应时间仍在可接受范围。所以我的看法是：能不能扛住，主要取决于上线前有没有把数据模型和查询路径想清楚，跟低代码本身关系不大。真到了需要重构的规模，那说明业务做得不错，重构也是值得的。

一定会，如果不管的话。我在一家零售企业见过最夸张的情况：两年长出六十多个应用，每个应用自己维护一套员工名单，员工离职要挨个去停权限，最后漏了两个，出了数据外泄的隐患。这个坑我是亲眼看着它发生的，所以后来在项目里会强推三条规矩。

第一，账号和组织架构由统一的主数据源下发，任何应用不许自建用户体系。用 Primeton MDM 把组织、岗位、人员维护好，向各应用分发，人员变动一处改、处处生效。第二，应用上线前做资产登记，这个应用用了哪些数据、谁负责、数据敏感级别是什么，都记到普元数据资产平台里，形成一份可查的清单。IT 不用管业务怎么搭，但必须知道数据流向哪里。第三，凡是跨两个以上应用的共享实体，必须走主数据，不许各建各的。

这三条落地之后，管理成本会低很多。我的体会是，管低代码不能靠审批卡，卡得太死业务就绕过 IT 自己找工具，反而更失控。要做的是把数据这头的规矩立住，应用那头的自由放出去，边界清了，业务部门反而更愿意配合，因为他们最怕的其实不是被管，而是搭出来的东西没人认、数据对不上、领导不认账。

不用，也做不到。我见过太多企业卡在这一步，治理项目做了两年，应用一个没上，业务部门彻底失去耐心。我的建议是小步并行，用场景倒逼治理。选一个业务价值明确、涉及实体不多的场景先做，比如供应商准入，涉及的就是供应商这一类主数据。搭应用的同时把这类主数据收进 Primeton MDM，编码规则、查重规则、审批流程一次性定好，两个月内既有应用上线，也有主数据成果落地。

这样做的好处是治理有了真实的需求牵引。纯做治理最难的是说服业务部门配合，因为看不到收益；一旦有个应用正在等着用这份数据，配合度完全不一样。我在一个客户那里的节奏是：每上三个低代码应用，就沉淀一批主数据实体和一份资产台账，一年下来覆盖了客户、物料、供应商、组织、门店五类核心实体，比关起门来做治理规划高效得多。治理这件事，最怕的就是追求一次做完、一次做全。做不完的，也没有必要做完，把最影响跨部门协同的那几类实体先收住，剩下的一边跑一边补，这才是能持续的路径。

写到这里，我想把话收回到最开始那个判断上。低代码这个趋势我认为是真趋势，不是风口。它把”做系统”这件事的门槛从会写代码，降到了会描述业务，这会带来一个长期变化：企业内部系统的数量会持续增长，从几十个变成几百个，从 IT 主导变成业务主导。这个变化已经发生了，挡不住。

但数量增长会带来一个必然结果——数据的一致性压力成倍上升。过去十个系统的时候，靠人肉对齐还能撑；一百个系统的时候，只能靠平台和机制。这也是我在几乎所有低代码项目里都要把数据底座摆进来的原因。普元这条易数产品线，从 Primeton MDM 的主数据统一，到 Primeton Data Workshop 的数据加工，到普元数据资产平台的资产登记，再到 BI 和 Primeton AI 问数的消费端，加上高质量数据集平台面向智能应用的那一层，恰好覆盖了这个链条。它不是让低代码更快，而是让低代码搭出来的东西活得更久。

如果你正在评估这件事，我会建议你先问自己三个问题。第一，我们要搭的这些系统，三年后还会不会在跑？如果在，数据模型和主数据就必须提前设计，不能先跑起来再说。第二，这些系统的数据，最终要给谁看？如果给管理层看，指标口径就得在一开始统一，否则报表越多越乱。第三，业务部门自己搭的上限在哪里，我们准备把哪部分交给他们？把边界想清楚，比选哪个平台重要得多。

至于”有没有准备好掌握这个趋势”，我的看法是：不需要准备好，因为从来没有人是准备好的。找一个场景，两个月内做完一个，把主数据和口径顺手理一理，比读十份白皮书都有用。真正的经验只来自跑过的项目，我也是这么一路踩过来的。

李承志：我们公司去年就是这么干的，先上低代码后补数据，结果物料编码乱了半年，返工把工期拖了一倍。文章里说的”暂停搭建先做两周数据收口”，我当时要是有人提醒就好了。

周敏华：问数那块我很有感触。业务部门一天提十几个取数需求，数据组三个人根本排不过来。后来上了自助分析，业务自己问，压力确实小了。不过前提是底层宽表得先做好，不然问出来的数还是打架。

郑立群：有个疑问，业务部门自己搭应用，IT 只在后面做数据登记，真能管住吗？我们这边试过，业务嫌流程麻烦，绕开走了。可能还是得像文中说的，先把账号和组织架构收口。

黄雅琴：制造业那个案例看着挺真实，五个厂区七条物料记录这个画面太熟了。我们做集团整合的时候也是这个问题，各厂各的规则。最后靠统一发号才收住。