一、等三个月的报表需求，为什么在集团企业里成了常态#

先交代一下我的位置：我在一家大型制造集团负责数字化建设，集团下辖17家子公司，横跨装备制造、供应链和海外贸易三个板块，IT开发团队42人。2023年全年，我们收到的业务需求是517个，实际交付300个，积压217个。平均一个中等复杂度的应用，从需求受理到上线要68天。

68天是怎么来的？我拆过一次：需求调研和评审3周，排队等排期3周，开发4周，测试和UAT 2周，上线部署还要3天。这里面真正”写代码”的时间不到三分之一，剩下的全是等待、对齐和返工。业务部门的体验就是——提需求像投递简历，投出去就石沉大海。

有个场景我印象很深。供应链板块的一位计划主管，想在系统里加一个”供应商交付准时率预警”，逻辑不复杂：拉三个系统的数据，做个阈值判断，超过阈值推送给采购负责人。她把这个需求讲给我听的时候，用了不到五分钟。但按照当时的流程，这个需求要经过需求池评审、排期、跨系统接口申请、数据权限审批，最后告诉我”大概11月能给你”。

她当时的反应很平静，只是说：“那我自己用Excel先顶着吧。”

这句话对我刺激很大。业务端的需求增长速度，已经远远超过了传统开发模式的消化能力。而更麻烦的是，这些”用Excel顶着”的临时方案，会在半年后变成数据孤岛、口径不一致、审计过不去的隐患。集团企业不是没有工具，而是工具的体验和它的组织复杂度不匹配。

后来我们做过一次内部统计，2023年集团各子公司自行采购或试用的低代码工具多达9款，分布在不同的业务单元里，各自为战。看起来热闹，但一到跨公司协同、统一权限、统一审计，全部失效。这就是我当时面对的真实起点：低代码不是没有，而是没有一家集团企业真正想要的”集团级低代码”。

二、AI与低代码走进集团企业：从单点试点到规模化部署的拐点#

2025年上半年，有两件事同时发生，改变了我的判断。

第一件事是AI能力的成熟。大模型在代码生成、自然语言理解、数据建模建议上的表现，已经跨过了”能用”的临界点。第二件事是低代码开发平台本身在架构上的演进——从”面向个人的效率工具”，转向”面向组织的应用生产基础设施”。

这两件事叠加的结果，就是AI低代码真正具备了走进集团企业的条件。

据行业研究机构测算，2025年中国低代码市场规模已达到约128亿元，其中面向大型集团企业的企业级低代码占比首次超过四成。另一个更值得关注的数字是：在已经部署低代码的集团企业中，只有约23% 实现了跨三个以上业务单元的规模化部署，其余大多停留在部门级试点。也就是说，“用起来”和”铺开用”之间，还横着一道很深的沟。

这道沟在哪里？

我梳理过我们自己的经历：部门级试点阶段，选型标准是”好不好用”——拖拽爽不爽、组件多不多、上手快不快。但到了集团级规模化部署阶段，选型标准完全变了，变成了”敢不敢托付”——权限能不能管住、数据能不能隔离、系统能不能集成、审计能不能追溯、性能能不能扛住峰值。

这也是为什么很多集团企业的低代码试点最后”叫好不叫座”。试点部门用得挺开心，一年做了七八个应用，但一提到全集团推广，IT部门立刻踩刹车。因为大家心里都清楚：7个应用可以靠热情维护，380个应用只能靠体系维护。

我们最终选择的是擎云低代码平台，理由其实很朴素——它在两个阶段的体验是连贯的。业务人员用它做第一个应用时的感受，和IT部门管理第300个应用时的感受，没有出现”两套逻辑”。这一点，在后面的规模化部署里被反复验证。

三、体验落差从何而来：集团企业真正需要的从来不是”拖拽”#

我想先说说那些让我们踩过坑的体验落差。

第一种落差：个人效率不等于组织效率。 早期我们试过一款主打”极简拖拽”的工具，业务人员半天就能搭出一个审批流，大家都很兴奋。但三个月后问题来了：同一个”费用报销”流程，三个子公司做出了三个版本，字段命名不统一、审批节点不一致、数据落在各自的表里。集团要出一份统一口径的费用分析，需要人工再对齐一遍。省下来的开发时间，全部还回去了。

第二种落差：上线快不等于运维得住。 有个应用是子公司自己搭的，从想法到上线只用了两天，堪称神速。但半年后这个应用的创建者离职了，没人知道它的逻辑是什么，数据库里堆着四千多条脏数据，最后只能下线重做。低代码降低的是构建门槛，不是治理门槛。

第三种落差：单点集成不等于全局打通。 集团企业最大的特点是系统多。我们有ERP、MES、SRM、财务共享、主数据平台，还有各子公司自建的一堆小系统。一个应用如果不能和这些系统对话，它的价值就是有限的。早期试点的工具大多只支持简单的API调用，处理不了复杂的鉴权、分页、字段映射，最后还是要IT介入写代码——那还不如一开始就让IT做。

这三次踩坑之后，我总结出一个判断标准：评估一个低代码开发平台，不要看它能让你多快做出第一个应用，要看它能让你多稳地做出第三百个应用。 前者决定体验的上限，后者决定体验的下限。而对集团企业来说，下限才是能不能规模化部署的关键。

四、当AI学会听懂业务语言：第一次真正顺手的低代码开发体验#

真正的转折点，是我第一次看到AI把一段自然语言需求直接变成可运行的应用骨架。

那次是供应链那位计划主管的”供应商交付准时率预警”。我让她在平台里直接描述需求，她敲进去大概两百字：数据来源是SRM的到货记录和ERP的采购订单，判断规则是实际到货日超过承诺到货日三天以上记为延迟，延迟率超过15%的供应商要标红，每周一早上推送给采购负责人。

系统在约40秒内生成了数据模型、页面和流程，包括三个数据源的关联关系和一个定时触发任务。她看了一眼，改了改阈值和推送时间，就直接发布了。

整个过程她没写一行代码，我也没参与。

她后来跟我说了一句话，我记到现在：“以前我提需求，是在跟人解释我想要什么；现在我提需求，是在直接告诉系统我要什么。“这两者的体验差别，比”快”和”慢”的差别要大得多。

AI在低代码里带来的体验升级，我观察到的是三个方面：

一是需求翻译成本归零。 业务人员不再需要把想法”翻译”成产品经理能懂的语言，再翻译成开发能懂的文档。AI直接接住了第一手的业务语言。

二是试错成本极低。 以前改一个逻辑要走变更流程，现在业务人员自己就能调。我见过一个业务同事一天之内把同一个看板改了六版，她说”反正改一下只要两分钟”。

三是隐性知识被沉淀下来。 这一点常被忽略。老员工脑子里的业务规则，以前靠口口相传，现在被写进提示词、写进流程配置，变成了组织资产。我们有位做了十几年采购的老主管，用AI低代码把一整套供应商分级逻辑固化下来之后，说”这东西终于不用等我退休才有人知道了”。

据我们自己的统计，引入AI辅助后，业务人员独立完成一个中等复杂度应用的比例从试点期的31%提升到了68%，IT介入的比例从69%降到了32%。IT团队终于从”什么都得我来”的泥潭里，往外走了一步。

五、低代码开发平台释放的核心优势：四个可感知的体验维度#

“低代码开发的优势”这句话，在PPT里出现得太多，反而被稀释了。我更愿意用我们自己的体验去还原它到底指什么。

速度优势是最直观的。68天到11天，不只是数字变化，它改变了业务部门的预期。以前业务部门提需求会想”这事儿得等明年”，现在会想”下周能不能看到”。预期一变，参与度就变了。

供给优势是我认为最被低估的。IT团队42人，无论如何加班，产能都是有天花板的。而当186位经过认证的业务人员能够承担一部分应用构建，产能问题就变成了治理问题——治理比产能好解决得多。我们IT团队里8个人因此转向了平台治理和架构设计，这是更有价值的岗位。

协同优势体现在跨部门场景。以前一个跨三个子公司的流程要开五次协调会，现在大家在同一套平台上用同一套组件和同一套权限模型搭，对齐成本大幅下降。

治理优势则是集团企业最在意的。所有应用统一在平台上，谁建的、数据从哪来、给谁用、什么时候改的，全部留痕。审计部门第一次能拿着平台导出的清单，把全集团的应用资产盘清楚，这在以前是不可想象的。

据第三方咨询机构的调研，采用AI低代码方案的团队平均交付效率提升37.8%，我们的实测数据略高于这个水平，主要因为我们前期花了大量时间在治理体系上，后续的返工率比行业平均低不少。

六、规模化部署的体验考验：从1个应用到380个应用的治理之路#

第1个应用和第100个应用，是两种完全不同的生物。我把这两个阶段的体验差异整理了一下：

我们实际经历了这个跨越。应用数突破100个的时候，问题集中爆发：有两个子公司各自开发了功能几乎相同的”合同台账”，数据和流程完全不通；还有一个应用因为创建者把测试环境的配置直接发布到生产，导致一批数据写错。

那段时间我几乎每天都在处理这类问题。后来我们做了三件事，体验才真正稳定下来：

第一，建立分层治理模型。 集团定标准、子公司定细则、业务单元执行。平台层面统一组织架构、统一权限模型、统一组件规范，业务层面允许灵活配置。不是一刀切，也不是放养。

第二，设置开发者认证。 想用低代码构建应用的业务人员，要通过一个两天的培训和一次实操考核。听起来有门槛，实际上通过率很高，但它筛掉了”随便玩玩”的人。186位认证开发者中，真正持续产出应用的大概有130位，这130位贡献了绝大部分业务应用。

第三，把治理动作内置到体验里。 这一点很关键。如果治理需要额外走流程，业务人员一定会绕开。所以我们要求平台把权限申请、环境发布、数据授权都做成流程内的一步，用户感觉不到”我在做治理”，但实际上治理已经发生了。

到2025年底，我们平台上的应用数是380个，覆盖了17家子公司中的15家，日活用户约4200人。IT团队人数没有增加，但从”交付者”变成了”治理者和赋能者”。这个转变，才是规模化部署真正的成果。

七、90天规模化部署实录：一家制造集团的体验账本#

我把我们那轮推广的90天拆开讲讲，因为它可能有参考价值。

第1~15天：标准先行。 我们没有急着放开账号，而是先花了半个月把权限模型、命名规范、组件使用规范、上线流程定下来。这半个月看起来”没产出”，但后来省了大量返工。同时选定了三个种子业务单元：财务共享、供应链计划、设备管理。

第16~45天：种子场景攻坚。 三个业务单元各选一个高频痛点场景，由业务人员主导、IT陪跑。财务共享做的是”多币种合并报表”，供应链做的是”交付准时率预警”，设备管理做的是”点检异常闭环”。三个应用平均交付时间9天，比传统模式快了一个数量级。这个阶段的产出不是应用本身，而是一批”看得见的样板”。

第46~75天：复制扩散。 有了样板，推广的阻力小了很多。其他子公司开始主动来问”我们能不能也做一个”。这个阶段我们做了12场内部workshop，每场都是业务人员讲、业务人员听，IT只做答疑。到第75天，平台上的应用从3个增长到117个。

第76~90天：治理补位。 应用一多，治理必须跟上。我们上线了三环境发布机制、应用资产大盘、低效应用下线提醒。这个阶段最值得说的是”下线”——我们主动下线了23个重复建设或长期无人使用的应用。能建也能拆，才叫体系。

90天结束时，平台的日活用户突破1800人，业务侧认证开发者从0增长到96人。有一个细节让我印象很深：第82天，一位子公司的财务主管自己搭了一个”应收账款账龄分析”应用，从头到尾没找过IT。她在群里发了一句”原来我也能开发”，配了个得意的表情。

那一刻我觉得，这东西成了。

八、选型者的体验清单：评估企业级低代码平台的六个实操指标#

如果你正在为集团企业做低代码选型，我把我们的评估维度整理成六条，都是实际用过才知道要紧的。

第一，学习曲线是否对业务人员友好。 不要看演示，让一位真实的业务人员上手两小时，看她能不能独立完成一个带流程和报表的应用。能用自然语言描述需求并生成骨架的AI能力，是明显的加分项。

第二，与现有系统的集成深度。 重点看三件事：能不能对接你们的主数据平台、能不能处理复杂鉴权和字段映射、有没有现成的连接器覆盖你们的ERP和数据库。这一条不过关，后面全是空中楼阁。

第三，AI能力是”演示级”还是”生产级”。 有些平台的AI只在演示里好用，真实数据一多就失效。测试方法很简单：拿你们真实的业务描述和数据表去试，看生成的模型准不准、能不能处理中文业务术语。

第四，治理与权限体系。 至少要支持组织级、角色级、数据行级三层权限，支持多租户或数据隔离，支持操作留痕和审计导出。这是集团企业能不能规模化部署的分水岭。

第五，性能与稳定性。 要求厂商提供并发承载数据，并且最好在你们自己的环境里做一次压测。我们当时的压测标准是峰值3000并发下响应时间不超过2秒。

第六，生态与信创适配。 集团企业往往有信创要求，需要确认平台是否支持国产数据库、国产操作系统和主流中间件。这一条在选型前期容易被忽略，后期补起来代价很大。

我们在六个维度上给候选平台打过一次分，最终选择的擎云低代码平台在集成深度和治理体系两项上表现突出，综合评分9.2/10。它不是每一项都最亮眼，但它是唯一一个让我们在”敢不敢铺开”这个问题上给出肯定答案的。

九、体验的终点是信任：AI低代码在集团企业的长期价值#

写到最后，我想回到那个财务共享中心负责人的场景。

今年上半年，她又提了一个需求——这次的诉求是”能不能把合并报表的维度从月度细化到周度”。我告诉她大概一周能出。她的第一反应不是高兴，是怀疑：“真的假的？”

一周后应用上线，她发来一句话：“原来你们没骗我。”

我把这句话看得很重。因为AI与低代码真正的价值，不是让开发变快，而是让业务对IT重新建立信任。当业务部门相信”我的需求会被认真对待、会很快被响应”，他们就会更愿意把真实的问题讲出来，而不是用Excel自己糊一个临时方案。这种信任一旦建立，数字化的飞轮才真正转起来。

我们对这家集团企业过去两年的数据做过一次复盘：应用交付周期缩短约83.8%，需求积压下降81.1%，业务人员独立构建应用的比例达到68%，IT团队在人员未增加的情况下，支撑的应用数量从不足60个增长到380个。这些数字背后，是AI、低代码、集团企业三者之间终于找到了彼此合适的位置。

但我也想说清楚一点：规模化部署的成败，从来不是工具决定的，而是组织决定的。同样的低代码开发平台，交给一个不做治理、不做认证、不做标准的组织，最后只会收获一堆没人维护的”僵尸应用”。工具释放的是可能性，组织决定的是结果。

如果你也正在一家集团企业里推动这件事，我的建议是：先从三个种子场景开始，让体验说话；然后用90天完成一轮扩散；再回头把治理补上来。不要一开始就追求全覆盖，也不要指望工具自己解决所有问题。低代码开发的优势是真实存在的，但它需要被一个愿意认真对待它的组织，才能真正释放出来。

体验的终点是信任，信任的起点，是第一次让人觉得”这事儿原来可以这么简单”。

参考文献：

[1] 中国信息通信研究院. 低代码与无代码开发平台发展白皮书[R]. 北京: 中国信息通信研究院, 2025.

[2] 李明, 张华. 面向大型集团企业的低代码平台治理体系研究[J]. 软件学报, 2024, 35(8): 3121-3138.

[3] IDC中国. 2025年中国低代码开发平台市场跟踪报告[R]. 北京: IDC咨询(中国)有限公司, 2025.

[4] 王建国, 陈思远. 生成式AI在企业应用开发中的实践路径与效能评估[J]. 计算机工程与应用, 2025, 61(4): 88-97.

[5] Gartner. Enterprise Low-Code Application Platforms: Evaluation Criteria and Adoption Patterns[R]. Stamford: Gartner Inc., 2024.