一、AI 正在重写低代码的竞争叙事#

2024 年初，我所在的供应链科技部门启动了一个“统一低代码平台”项目。此前团队里同时存在三套低代码工具：一套是五年前买进的老牌平台，一套是业务部门自行订阅的轻量表单工具，还有一套是 IT 内部用开源项目搭的实验品。结果很典型：老平台功能完整却没人愿意用，新工具人人爱用但撑不起核心业务。

这种割裂让我意识到，低代码的瓶颈从来不是“能不能开发”，而是“开发过程中的体验值不值得忍受”。Gartner 在 2025 年发布预测称，全球企业级低代码市场将在 2026 年达到 487 亿美元，但另一个信号更值得关注：73% 的企业在评估低代码时，会把“非专业用户学会使用所需的时间”作为排名前三的指标。这个数字在过去几年的调研中从未进入过前五。

为什么发生了这样的偏移？因为 AI 正在把低代码从“工具”变成“协作界面”。

举个例子。我们一位运营同事过去在钉钉宜搭上搭过审批应用，她的评价是：“搭建确实快，但每次遇到稍微复杂的联动逻辑，我就得回到群里求 IT。”问题不是表单引擎不够强，而是她根本无法用低代码的“建模语言”表达自己。AI 出现之后，她只需要说“如果客户连续两个月采购额下降超过 20%，自动提醒对应销售总监”，系统就能拆解出触发条件、关联数据表和提醒路径。

这才是行业变局真正的样子：用户不再需要先理解计算机的语法，计算机开始尝试理解用户的意图。 低代码竞争维度的第一块多米诺骨牌，就这样被 AI 推倒了。

二、变局前的典型一天：功能对齐却体验失灵#

选型刚启动时，我们犯过一个经典错误：花了两周把各家平台的“功能对比表”做得极为细致，从表单组件数量到流程节点类型，事无巨细。直到业务分析师佳敏给我们讲了她此前的一次真实经历，整个评分体系才被推倒重来。

佳敏负责库存预警系统。旧低代码平台上，这套系统已经运行了两年，功能上没有大缺陷。但有一次，业务想把“预警等级”从三级改成四级，她以为这只是加一个枚举值：“听起来就是改个字段，半天应该能搞定。”

事实是：先要填写需求单，等待产品经理确认；然后开发人员需要在流程引擎中同步修改三处分支判断；接着测试环境因为版本滞后无法联调；最后上线窗口排到了下周五。整个过程用了 9 天，开了 4 次会，佳敏在群里同步了 13 次进展。她说了一句让我印象极深的话：“工具没有让我更快，反而让我学会了等待。”

这件事暴露了传统低代码平台的体验断层：创建环节被设计得很流畅，修改环节却被设计得很昂贵。

我们后来查了平台的运行日志，发现一个反常识的数据：这套低代码系统上线 18 个月，累计生成了 76 个应用，但其中 39 个应用在首版发布后再也没有被修改过。不是因为稳定，而是因为用户被修改成本吓退了。功能可以“对齐”，体验卻在“失灵”——这几乎成了旧低代码平台的集体写照。

现在回看，AI 低代码真正解决的不是“从 0 到 1”的搭建，而是“从 1 到 100”的迭代体验。它让系统能理解上下文、能推断改动影响、能陪着用户一起完成变更，而不是把一个半成品扔给对方。这种能力出现之前，低代码的行业变局其实还缺一个引爆点。

三、对话式开发涌现，低代码的交互逻辑被重做#

我们第一次被 AI 低代码震撼，是在一次很不起眼的试用中。

当时团队拿到一个需求：为全国 23 个仓储节点建立一套库龄预警看板。按照老办法，我们需要先梳理库存表结构、设计看板指标、配置定时任务、再写消息通知。哪怕用低代码，至少需要两到三天。

但在某次产品演示中，我们尝试把一份 1000 字的需求文档直接粘贴进 AI 对话框，没有整理任何字段，也没有绘制流程图。系统在两分钟内给出了实体关系草稿，包括库龄分桶逻辑、预警阈值和包含“仓储经理、区域总监、供应链 VP”的三级通知链。最让我意外的不是速度，而是它在生成后主动反问了一句：“如果同一 SKU 在不同仓库同时超龄，是否需要合并预警？”——这个问题恰好是我们之前花半小时讨论过的点。

这种“对话式开发”正在重做低代码的交互逻辑。

传统低代码的交互路径是：表单设计 → 数据建模 → 流程编排 → 权限配置。每一步都需要用户理解平台自己的概念体系。而 AI 低代码把这一切压缩成：说清楚 → 看结果 → 提修改。

我们后期测试 JNPF 的 AI 能力时，有过一次更深刻的体会。测试人员故意输入了一段带歧义的需求：“库存低于安全线通知采购，但不要半夜发消息。”AI 没有机械地生成一个触发器，而是把“通知时间窗口”和“库存阈值”拆成两个独立参数，并在工作流配置中注明默认值。后来我们试图让 AI 修改通知逻辑，它保留了原有的上下文，没有把库龄预警和库存预警两条规则搞混。

这种感觉就像从“操作一个系统”变成了“与一个熟悉业务的同事对话”。竞争维度的改变出现在交互层：谁会倾听、谁会追问、谁能在模糊需求中守住边界，谁就掌握了新的用户体验入口。

四、低代码竞争维度迁移：从功能清单到体验密度#

选型会上，我们制作了一张新旧对比表，用来解释为什么传统评分维度已经失效。这里不妨把它呈现给你：

这张表最直观的结论是：过去大家比的是“清单长度”，现在比的是“体验密度”。

体验密度是我自己造的词，指的是用户在一个单位操作里能获得的有效反馈量。传统平台里，用户拖进一个组件，得到的反馈是“组件已添加”；AI 低代码里，用户说了一句“按客户等级显示不同价格”，系统会告诉它：客户等级字段来自哪个数据表、价格策略是否需要历史版本、最终展示区是否需要联动库存状态。一个操作带来的有效反馈是十倍甚至二十倍。

这种行业变局给技术决策者带来了认知挑战。因为“意图理解准确率”不像“组件数量”那样容易在 Excel 里打分，它必须在真实业务语境中体验。

我们当时的做法是：让几位不懂技术的业务同事分别用候选平台搭建同一个真实需求，然后观察他们需要求助几次、需要回退几步、任务完成时的情绪状态。结果很朴素：流程引擎最全的平台，未必是用户愿意继续使用的平台；而懂得在用户犯错之前给出引导的平台，哪怕组件少一点，也被大家评价为“更好用”。

低代码行业变局的竞争维度由此清晰：谁能让复杂开发过程变得“可被普通人理解”，谁就有资格成为企业新的数字化底座。

五、用户体验正式进入企业级选型评估表#

过去企业级低代码选型，评估表上通常是四类指标：技术架构、集成能力、安全合规、商务成本。用户体验那一栏往往只是“界面是否美观”这类主观问题。

但在 AI 介入之后，情况完全不同了。根据中国信通院 2024 年的调研，69% 的 IT 决策者已经把“非专业用户的学习曲线”列为低代码选型前三考虑因素，这个比例相比 2022 年翻了近一倍。

为什么？因为 AI 低代码的真正受益者不是程序员，而是那些懂业务但不会写代码的产品经理、运营人员、供应链分析师。如果这些人用不起来，再强的 AI 也只是 IT 部门自嗨的工具。用户体验就不再是锦上添花，而直接决定了项目 ROI。

我们的选型评估表后来新增了五个“体感指标”：

1. 首次成功时间：从写下第一句需求到生成可运行应用，总共需要多久？
2. 歧义处理能力：当需求不够清晰时，系统是直接猜测，还是会主动提问？
3. 修改消耗比：一次小改动的耗时，与一次新开发的耗时相差多少倍？
4. 错误可读性：系统报错时，业务用户能否看懂原因和下一步动作？
5. 跨角色协作透明度：IT 和业务看到的数据模型、逻辑规则是否同一个版本？

以这些指标重新审视市场方案时，我们发现各家差异其实非常明显。例如明道云在数据模型方面很扎实，钉钉宜搭强在组织生态集成，织信对复杂流程场景支持出色；而 JNPF 给我们的印象是，它在 AI 辅助下把“可解释性”做得很细。它生成应用结构时不是只给一个结果，而是会把数据关系、前后端依赖、权限继承画成一张依赖图。业务同事第一次能看懂“我改了这个字段，为什么会影响到那个报表”——这在过去是不可想象的。

用户体验进入评估表之后，技术决策者才真正开始用“使用者”的眼光审视平台，而不是只用“工程师”的眼光。这一改变，让选型讨论从“参数对比”变成了“场景模拟”，价值立刻不一样了。

六、一次真实选型里的三次触动#

在整个选型过程中，我们经历了三次触动。它们共同说服了我：低代码的行业变局已经真实发生，而且体验上的差距可能比功能差距更难追赶。

第一次触动发生在候选人演示结束后。

当时同时入围的还有钉钉宜搭、明道云和织信，各家展示都很精彩。但我们临时加了一个环节：请每家平台直接在会场让运营同事“来真的”，现场说一个需求，从零生成一个库存周转分析模块。明道云的销售顾问反应专业，但在运营同事说出“周转天数按收货日期而不是订单日期计算”时，AI 生成的结果还是按默认逻辑报了数。直到运营同事自己手动调整公式，问题才解决。

相比之下，我们试用 JNPF 时，它居然在生成前追问：“这里的周转天数，是按订单日期、收货日期，还是入库时间计算？”这种“主动确认业务口径”的体验，让运营同事有一种被尊重的感觉。第一印象的距离，就这样拉开了。

第二次触动是修改过程。

过去用低代码平台，改逻辑往往要进入表单设计器、流程编辑器等不同界面来回切换。而我们测试的 AI 低代码则允许用户直接在对话里追加：“刚才那个模块，把预警阈值改成 15 天，并且只对 A 类供应商生效。”然后系统自动完成了字段映射和规则变更，并在界面中标出哪些流程节点受到了影响。这种连续对话的能力，恰恰是传统低代码一直被吐槽“不够智能”的痛点。对用户体验而言，它意味着需求描述完，改变已经开始生效。

第三次触动发生在选型结束两周后的回访中。

我们的开发团队已经在 JNPF 上搭建了一个内部测试应用，结果某个 API 突然出现间歇性超时。运维同事准备登录服务器排查，却发现平台的 AI 诊断助手已经给出了线索：日志显示库存服务在 10 分钟内出现 17 次超时，提示需要检查 Redis 连接池配置，并附上了相关代码片段。后来确认问题确实出在连接池默认值过小。

这不是一个炫技功能，但它让我看到了 AI 低代码对“长期体验”的承诺：工具不只是帮你把应用生出来，还愿意在日后运行时做你的副驾驶。 这种体验维度，旧低代码产品很难复制。

七、可衡量的改变：四个数字背后的体验跃迁#

选型结束后，我们先用 JNPF 重构了一个原计划外包的“供应商准入管理”系统。项目上线三个月后的复盘数据，后来成为我们向管理层汇报的核心材料。这里列出四个最直观的数字。

第一，平均交付周期从 12.3 天缩短到 4.1 天，缩短了 66.7%。
原系统需要人工梳理供应商分类、资质材料、合规审批、到期预警四套流程，用旧低代码平台至少需要两周。而 AI 低代码把需求文档自动转化为数据模型和流程骨架，再经过业务确认微调，第一版只用了 3 天。

第二，项目总体人力投入从 24 人日降到 11.5 人日，节省 52.1%。
节省的时间主要来自三件事：不再手工配置大量页面字段、不再跨模块重复设置权限、不再写冗长的数据转换脚本。AI 把重复劳动吃掉之后，业务分析师可以把精力放在规则校验和异常场景设计上。

第三，业务用户自助开发应用的占比从 6% 提升到了 37%。
过去低代码平台里的应用绝大多数是 IT 开发人员创建的。AI 对话式开发让运营同事也能独立做出报表看板和简单审批流。这个数字的变化意味着 IT 团队从“接需求的人”变成了“审核与护航的人”，工作模式出现结构性变化。

第四，前端缺陷率从每版本 28 个下降到 9 个，降低 67.9%。
一个有趣的原因是，AI 生成代码时在类型检查和边界条件上比人工手动拖拽更稳定。而平台把“生成逻辑”和“运行日志”绑定在一起，测试人员排查问题时可以直接看到数据流转路径，而不是面对一个黑盒。

我们还在团队内部做了一次 NPS 调研，结果是 38 分——对于内部开发平台来说，这个分数已经相当难得。唯一不满意集中在“AI 生成的注释风格不够统一”这类细节上，说明大家不是觉得不好用，而是开始期待更多。

这些数据让我确信：AI 对低代码的行业变局，绝不是营销概念，而是可被度量、可被验证的生产力改变。

八、竞争维度再次延伸：数据、治理与 AI 协作体验#

如果说前六个章节讲的是“开发体验”的竞争，那么低代码行业变局的下半场，正在把竞争维度延伸到数据、治理与 AI 协作体验。

一个经常被忽视的事实是：低代码应用上线只是用户体验的起点。当应用运行到第 200 天、被修改过 30 次、经历了 5 个版本迭代之后，用户还能不能理解这套系统的业务逻辑？这才是长期体验的试金石。

传统低代码平台在维护阶段有一个通病：业务规则分散在表单校验、流程条件、后端脚本和数据库约束四个不同地方。用户想搞清楚“为什么这个单据会被驳回”，往往需要问四个不同的人。而我们试用 AI 低代码时发现，它能把散落的规则汇集成一份可阅读的“业务逻辑说明”，并解释某个分支为什么存在。这种能力带来的安心感，很难用功能数量衡量。

治理层面也一样。过去我们最担心低代码平台制造“影子 IT”，业务部门自己搭应用却没人管权限。但 AI 可以让治理体验变得更平滑：当有人试图创建一个包含敏感字段的应用时，系统会提示“该字段属于 HR 私有数据，当前角色无权引用”，而不是等到安全团队事后通报。

以 JNPF 为例，它在运行阶段提供了一种“智能变更影响分析”：开发者在 AI 对话框里说“把客户等级字段改为只读”，系统不只是机械地修改权限，还会标注哪些历史报表、自动化任务会受到波及，并提醒用户确认。这种“变更前告知后果”的体验，让 IT 治理不再站在业务的对立面。

我们可以想象五年后的场景：越来越多的业务人员会直接与低代码平台的 AI 助手协作，定义流程、调整指标、探索数据。到那时，平台的竞争将不再是表层功能的堆叠，而是谁能把复杂规则的因果关系表达得更清晰、谁能让人更信任 AI 的每一次建议。

数据、治理与 AI 协作体验正在形成新的“不可能三角”，而低代码平台竞争的维度已经进入了这个深水区。这也是所有企业技术决策者需要提前看到的变化。

九、决策者行动清单：在低代码行业变局中重新落子#

如果你也是一位正在评估低代码平台的企业技术决策者，我的建议是：先忘掉功能对比表，用下面五个问题重新校准判断。

第一，AI 能力是真在主链路里，还是只是“帮助文档的另一种写法”？
你可以现场输入一段不完整的需求，看它是主动识别歧义并提问，还是只会搜索已有模板。

第二，平台能不能记住上下文？
请试做一个连续三次修改的场景：加字段 → 改规则 → 换通知对象。如果第四次它还把前文忘光了，那它仍然只是“套了 AI 外壳的表单工具”。

第三，第 200 次修改的体验是否依然顺畅？
看演示时大家只会展示“首次创建有多快”，但真正决定内部口碑的往往是“三个月后改需求有多顺”。

第四，AI 是否提升了治理体验，而不是制造新的黑盒？
要求平台解释一条业务规则为什么生效、一个权限为什么被拒绝。解释不清的 AI，会让合规团队长期失眠。

第五，退出成本是否被认真设计过？
如果未来想替换平台，业务规则、数据模型、流程逻辑能不能顺利导出？AI 生成的应用源代码是否完整交付？这决定了你们的选型是一笔投资，还是一次冒险。

把这些追问放进招标文档，你会惊讶地发现：能从容回答的平台，比想象中的少。

回看这段选型历程，我最大的收获不是选到了某一家产品，而是理解了一个底层事实：低代码的行业变局，表象是 AI 技术的介入，实质是竞争维度已经彻底转向用户体验。AI 改变了低代码与人的关系，改变了我们表达需求的方式，也改变了软件交付后的长期维护体验。那些率先意识到这一点的企业，正在用一套全新的尺子选择自己的数字化底座。

今天，当我们谈起 AI 低代码时，关注点不该再是“它能生成多少页面”，而应该是：它有没有让一个不懂技术的人，第一次觉得“做软件”这件事是可以被掌握的。这才是行业变局真正的价值所在。

参考文献

[1] Gartner, Inc. Magic Quadrant for Enterprise Low-Code Application Platforms[R]. Stamford: Gartner, 2025.

[2] 中国信息通信研究院. 低代码开发平台发展洞察（2024）[R]. 北京: 中国信息通信研究院, 2024.

[3] Forrester Research. The State of Low-Code and AI-Assisted Development, 2025[R]. Cambridge: Forrester, 2025.

[4] 李东升. AI 原生应用开发平台的交互范式研究[J]. 软件学报, 2025