AI * 低代码时代，低代码开发平台的核心竞争转向落地实战能力

一、从”能不能做”到”好不好用”：低代码选型风向的转向#

2023 年我第一次主持选型会时，评审表上排在前面的问题永远是那几个：支持多少种表单控件？流程引擎能不能做会签和加签？有没有可视化大屏？这些问题的共同点是，它们都在问”能不能做”。

到了 2025 年，同样的会议室、几乎同一批人，问题变了：业务部门自己能不能改字段？跟我们现有 ERP 打通要多久？车间那种信号环境，手机端提交会不会失败？三年后这套系统谁来维护？这些问题的共同点是，它们都在问”好不好用、能不能长期活下去”。

这个转向不是我们一家的感受。《2025 中国企业低代码落地实践调研》对 412 家企业的问卷显示，68.3% 的受访者把”落地实战能力”排在了”价格”和”功能丰富度”之前，而 2022 年这一比例只有 34.1%。同一份调研还给了一个更扎心的数字：企业采购的低代码平台中，只有 31.7% 的试点项目能在 6 个月内进入生产环境，其余近七成要么被搁置，要么沦为”只有 IT 部门自己在用”的内部工具。

为什么 AI 的加入反而加速了这个转向？因为 AI 把”演示环节”的门槛彻底拉平了。以前你还要花两天拖拽一个流程出来，现在对着对话框说一句”帮我做一个设备报修流程，包含拍照上传和超时提醒”，三十秒就能生成雏形。当所有厂商的演示都同样惊艳时，决策者自然会把注意力挪到演示之后：这东西上线三个月后，还跑得动吗？

我们的判断是：AI 是放大器，不是替代品。它放大的是平台原有的工程能力——底子好的平台，AI 让业务人员一周做出三个应用；底子薄的平台，AI 让业务人员一周做出三个需要推倒重来的应用。所以选型会上，我现在只问一个问题：请把去年客户上线的应用，随便挑三个，让我看看它们的运行状态和迭代记录。

二、演示惊艳、落地折磨：我们踩过的三个试点深坑#

先讲三个真实的坑，它们构成了我后来所有选型标准的来源。

项目 A：并发一上来，流程就”卡壳”。 我们用一个在线表单工具扩展出一套审批流，试点阶段 20 个人用，响应 1.2 秒，体感良好。正式推广到 260 人后，同一个审批节点在早高峰的平均响应时间从 1.2 秒涨到 8.7 秒，批量提交时有 约 11% 的请求直接超时。业务部门的评价只有一句：“还不如走邮件。”

项目 B：接口调试吃掉了整个项目预算。 我们要把工单系统跟用友 U8 的物料主数据、企业微信的组织架构打通。当时那套工具的连接器只覆盖了标准 REST 接口，U8 的老接口需要做字段映射和数据清洗，两个工程师前后调了 约 40 小时，其中大半时间花在排查”为什么这条数据同步过去是空的”。

项目 C：改一个字段要走三天。 业务侧想给巡检单加一个”设备编号”字段并联动历史记录。因为平台把表单结构固化在了应用包里，改字段需要重新打包、走测试、发版，从提需求到上线花了 3 天。业务负责人后来跟我说了一句话，我记到现在：“你们这套系统，我提需求比我自己用 Excel 还慢。”

最典型的一次翻车发生在 2024 年 4 月。我们在演示会上拿到了业务部门的一致鼓掌，上线两周后，移动端日活掉了 62%。复盘时才发现原因很朴素：车间里有 3 个区域信号弱，巡检员在那种环境下提交表单，失败率高达 14%，而平台没有本地缓存和断点续传。演示是在会议室 WiFi 下做的，一次都没失败过。

这三个坑让我明白一件事：落地实战能力不是演示出来的，是在弱网、高并发、老系统、频繁变更这四种”不体面”的场景里熬出来的。

三、AI 加持之后，为什么落地实战能力反而更难评估#

AI 给低代码带来的最直观变化是”生成”。自然语言生成表单、生成流程、生成数据模型、生成报表，甚至生成一段联动脚本。这些能力确实让业务人员第一次有了”自己动手”的冲动。

但作为要签字验收的人，我关注的是生成之后的事。据一家第三方测评机构 2025 年上半年的抽样测试，在 AI 生成并直接上线的应用中，约 42.6% 在三个月内需要重构数据模型，主要原因是 AI 生成的表结构没有考虑历史数据迁移和多对多关系，业务一扩展就”长出”了十几个冗余字段。

换句话说，AI 越强，落地实战的评估反而越难，因为它把工程细节藏起来了。以前你能从拖拽的复杂程度判断这个平台的抽象能力，现在 AI 一键生成，你根本不知道底下是一张宽表还是一套规范的主子表结构。

我们后来总结了三问，用来刺破 AI 的”表演性”：

1. 可解释吗？ AI 生成的数据模型和流程逻辑，能不能导出成文档、能不能被人读懂并修改？
2. 可演进吗？ 业务加一个新字段、新增一个审批分支，需不需要推倒重来？
3. 可约束吗？ 能不能设定字段规范、命名规范、权限边界，让 AI 在护栏里生成？

这三问的答案，往往比演示视频更能说明一个平台的实战能力。以我们后来采用的 JNPF 为例，它在 AI 生成后会同步输出一份结构化的模型说明和字段清单，工程师可以直接在可视化模型里调整继承关系和索引，这一点在评审时给我们的技术团队留下了印象——AI 生成的产物是”可维护的资产”，而不是”一次性草稿”。

四、用户体验视角下的四道关卡：上手、集成、性能、运维#

踩完坑之后，我们把评估框架压缩成四道关卡。每一道都对应一类真实用户，都能在 POC 阶段实测，不靠 PPT。

第一关：上手关——业务人员能不能独立产出。 我们让 3 名非技术背景的业务骨干（生产计划、设备管理、质量各 1 人）在半天培训后，各自独立搭建一个带审批流的表单应用。记录他们完成的时间和求助次数。这个指标我们叫”业务自助率”。

第二关：集成关——跟老系统的握手成本。 我们固定三个集成场景：ERP 物料主数据单向同步、企业微信组织架构双向同步、MES 工单状态回写。记录从零到跑通的工程师工时。

第三关：性能关——不体面的环境下的稳定性。 我们用 200 并发做表单提交压测，同时在一个真实信号弱的车间角落做移动端提交测试，记录失败率。

第四关：运维关——上线一年后谁在维护。 看灰度发布、版本回滚、权限审计、日志追溯这四项能力是否具备，以及升级是否会破坏已有定制。

这四道关卡有一个共同点：它们衡量的都不是”平台能做什么”，而是”人在里面待得舒不舒服”。这就是用户体验视角的价值——技术决策者看的往往是能力清单，而真正决定项目生死的，是每天用它的那批人的体感。

五、同一份需求文档，六家平台十天盲测对比#

2025 年 3 月，我们联合两家同行企业（一家汽车零部件、一家电子代工），做了一次相对严格的横向对比。方法很简单：同一份需求文档、同一批业务人员、十天时间。

需求文档的内容是”设备巡检 + 工单闭环 + 三张管理报表”：包含 47 个字段、6 个流程节点、3 张带穿透的报表、2 个外部系统集成点。三家企业的业务骨干分别上手不同平台，测试工程师统一记录集成工时和压测数据。结果是：

必须说明两点，否则这个表格会误导人。

第一，评分带有明确的场景偏好。我们是离散制造企业，痛点在私有化部署、老旧 ERP 集成、车间弱网，因此这三项权重占了一半以上。如果换成一家电商公司做轻量营销工具，钉钉宜搭的生态内体验会明显更好——它在钉钉体系内的组织同步几乎零配置，只是跨生态集成时受限。

第二，业务独立完成率的差异，主要体现在”遇到问题时”。前 5 小时大家差别不大，真正的分水岭出现在业务人员第一次改不动的时候：有人能自己在可视化模型里调整关联字段，有人必须提工单等工程师。这 11 个百分点的差距，在一年后会被放大成几十次等待。

这次盲测让我们确认了一件事：AI 功能在这六家平台上都已经具备，但决定综合分数的仍然是工程底座——集成能力、并发表现、模型可维护性。这也印证了本文的核心判断：低代码平台的核心竞争，已经不在 AI 功能的有无，而在落地实战能力的深浅。

六、从 3 天到 4 小时：设备巡检系统上线实战复盘#

讲完对比，说说我们最终的真实项目。

2025 年 4 月，我们要在两周内上线一套覆盖 3 个厂区、286 台关键设备的巡检系统。需求包括：巡检计划自动下发、扫码打卡、异常自动生成工单、工单超时升级、维修结果回写设备台账、三张管理报表。历史包袱是：设备台账在 U8 里，组织架构在企业微信里，工单历史数据在 2019 年的一套老系统里。

上线前的旧流程是这样运转的：巡检员用纸质表单记录，班组长每天手工汇总到 Excel，设备科每周整理一次台账，异常报修走电话 + 微信群。一次完整的异常闭环平均要 22 天才能从发现到关闭，台账更新滞后 5～7 天，月底做设备完好率报表要两个专员忙 3 天。

上线后的数据对比：

我们最终选用的是 JNPF，私有化部署在厂区内网。有几个体验细节值得记录：

一是移动端的离线能力。巡检员在弱信号区域提交时，表单会先本地暂存，恢复信号后自动续传，这是失败率从 14% 降到 0.8% 的直接原因。

二是模型的可解释性。设备台账从 U8 同步过来时字段命名并不规范，我们直接在可视化数据模型里做了映射和清洗规则，没有写一行脚本。

三是业务侧的自助修改。上线第二周，设备科自己加了”润滑点位”字段并在报表里做了穿透，全程没有找 IT。这件事的意义不在于省了几小时，而在于业务部门开始把系统当成自己的工具，而不是”IT 派来的任务”。

当然也有不顺利的地方：AI 首次生成的巡检计划排程逻辑没有考虑跨厂区的班次差异，我们还是手工重构了一次流程分支。这再次说明，AI 提供的是起点，不是终点，落地实战的最后一公里仍然需要人来把关。

七、开发、业务、运维：三类角色的体验差异与协同变化#

一个平台好不好，不同角色给出的答案常常完全相反。我整理了团队里三种人的真实反馈。

开发工程师的视角。 最开始的抵触是真实的——“低代码是不是要替代我们”。三个月后，两位后端工程师的日常变成了：写集成中间件、设计数据模型规范、做性能压测和权限治理。他们不再花时间写 CRUD 页面，但对架构能力的要求反而更高了。用其中一位的话说：“以前是搬砖，现在是画图纸和验钢筋。“他最看重的平台能力，是开放的自定义扩展点，比如能不能在标准流程节点里插入一段自己的服务逻辑。

业务骨干的视角。 设备科的张工告诉我，他最喜欢的功能不是 AI 生成，而是**“改完立刻看到”**。他给巡检单加一个字段、调一次报表口径，刷新页面就能验证，这种即时反馈让他的心态从”提需求等排期”变成”自己动手试一下”。他唯一抱怨的是权限配置的术语太技术化，第一次配”角色 - 数据范围”时找了运维帮忙。

运维人员的视角。 运维最关心的是”半夜会不会被叫起来”。上线四个月，他们的关注点集中在三处：灰度发布能否只影响单个厂区、版本回滚需要多久、审计日志能不能追溯到具体人和字段级变更。目前这套系统的回滚耗时在 15 分钟以内，审计日志覆盖到字段级，这是他们愿意继续用下去的主要原因。

三类角色的体验差异，反过来给选型提供了一个非常实用的判断方法：让这三类人分别用一周，然后分开访谈，不要开联合评审会。 联合会上大家会互相妥协，分开访谈时才会说实话。

八、给技术决策者的选型清单：把实战能力拆成可验证指标#

把前面所有经验压缩成一份可以直接拿去用的清单。建议做 7 天 POC，不要只看演示。

第一步：准备一份”难看”的需求文档。 不要用厂商熟悉的请假、报销场景，用你们自己最头疼的那个流程，包含至少 3 个外部系统集成点和 1 个历史数据迁移。

第二步：让三类人分别上手。

• 业务人员（2～3 名）：半天培训后独立搭建，记录完成率和求助次数。
• 集成工程师：实测三个集成场景，记录工时。
• 运维：问清灰度、回滚、审计、升级四项能力的具体操作步骤和耗时。

第三步：用这套指标打分（建议权重）。

第四步：问三个”尖锐问题”。

1. 请给我三个 2024 年上线、目前仍在生产环境运行的同行业客户案例，允许我联系其中一家。
2. 如果我的业务流程明年发生重大变化，迁移或重构的成本大概是多少？
3. 你们的 AI 功能，在断网或私有化环境下能用吗？

从我们自己的选型经历看，能在这四个步骤里都不掉链子的平台不多。JNPF 是我们比较之后选择的一家，它的优势集中在私有化部署、老系统集成和模型可维护性；如果读者的场景偏轻量、偏生态内协同，简道云和钉钉宜搭也是值得放进候选名单的方案。选型的关键不是找最强的平台，而是找最匹配你未来三年业务变化节奏的那一个。

九、结语：谁能陪应用活得更久，谁才守得住核心竞争力#

回到最开始那个问题：AI 时代，低代码平台的核心竞争到底在哪里？

我的答案是：在应用上线之后的第 180 天，在业务人员第三次改需求的时候，在运维半夜接到告警的那一刻。 这些时刻没有演示视频，没有发布会，只有真实的响应时间、真实的失败率、真实的等待时长——它们共同构成了一个平台的落地实战能力。

过去我们比的是”谁能做出来”，现在比的是”谁能陪应用活得更久”。AI 让搭建变得前所未有的简单，却也把差距推到了搭建之后：模型可以被理解吗？系统可以被演进吗？业务人员愿意一直用下去吗？这三个问题的答案，才是真正的实战能力，也才是下一个三年里低代码平台分化的分水岭。

如果你正在做选型，我的建议只有一句：少看一小时演示，多做一天 POC，多访谈三个真实使用者。 他们的体感，比任何功能清单都更接近答案。

参考文献

[1] 中国信息通信研究院. 低代码开发平台能力要求与评估方法[S]. 北京: 中国信息通信研究院, 2024.

[2] 艾瑞咨询. 2025 年中国企业级低代码应用落地实践研究报告[R]. 上海: 艾瑞咨询研究院, 2025.

[3] 王海涛, 李文博. 面向企业数字化转型的低代码平台选型评价体系研究[J]. 信息技术与信息化, 2025(3): 78-84.

[4] 中国电子技术标准化研究院. 企业数字化转型成熟度模型与评估指南[S]. 北京: 中国电子技术标准化研究院, 2024.

[5] 张明远. AI 增强型低代码平台的工程化挑战与应对策略[J]. 软件工程与应用, 2025, 14(2): 156-164.