行业思考：AI 普及之后，低代码赛道的竞争将转向何处

一、AI 掀翻桌子之后，低代码赛道的表层优势正在失效#

过去五年，低代码赛道经历了一轮又一轮的洗牌。最早大家比的是组件数量，后来比的是云原生架构，再后来比的是 AI 生成代码的准确率。但当 ChatGPT 级别的生成能力成为标配之后，低代码赛道的竞争转向已经开始浮现——几乎所有头部平台都接入了大模型，都能根据一句自然语言生成一个表单或一套审批流。 这些能力在 2024 年的行业展会上已经变成了标准动作，没有 AI 功能的低代码平台，甚至不好意思开发布会。

作为一家制造业数字化服务商的技术负责人，我对这种”参数竞赛”保持着某种警惕。低代码赛道的竞争转向，绝不会停留在”谁能生成更多代码”这个层面。 过去半年，我们团队密集调研了市场上主流的 12 款低代码平台，包括明道云、简道云、轻流、钉钉宜搭等，也做了深度的试用和压力测试。一个非常明显的感受是：当 AI 把”从 0 到 1 搭建应用”的门槛夷为平地之后，用户的目光开始越过功能列表，投向了那些真正影响日常使用体验的细节。

举个例子。以前我们选型时，最关注的是平台能不能覆盖复杂的数据模型，能不能支持高并发。但现在，AI 几乎已经解决了”能不能做出来”的问题——输入一段需求描述，几分钟内就能跑通一个具备增删改查的原型。在这种背景下，平台之间最后的分野出现在哪里？答案是体验。 是页面加载时那一秒的转圈等待？是配置复杂权限时反复跳转的迷茫？还是 AI 推荐结果差之毫厘时用户的挫败感？

这种体验层面的差异，在传统的低代码评测报告中几乎无处可寻。大家更习惯用”功能覆盖度""开放 API 数量""部署方式”这些冰冷的技术指标来打分，却很少回答一个更本质的问题：一个业务人员，每天打开这个平台工作 6 个小时，他会不会觉得累？

本文的行业思考将从这个话题展开。我希望以一个长期浸润在数字化交付一线的从业者视角，聊一聊 AI 普及之后低代码赛道竞争转向的底层逻辑，以及那些站在用户角度才会发现的真实差距。低代码赛道的竞争转向，转向的不是技术，而是人心。

二、用户真正的抱怨：功能不缺，缺的是”用得顺”的体验#

过去一年，我们团队跟踪回访了超过 40 位低代码平台的使用者，覆盖了制造业、零售连锁、物流配送、专业服务四个行业。这些用户所在的企业，多则上千人，少则几十人，但他们在使用低代码平台时表达的痛点却有惊人的一致性。

我们收集到的意见可以被归为三类。第一类占比最高，达到 46.7%：用户抱怨”功能虽然都有，但操作路径太深”。 比如说，在明道云上创建一个跨部门的数据看板，用户需要理解工作流、视图权限、数据联动三个模块的逻辑关系，虽然每个模块都有内置的模板指引，但在实际搭建一个稍复杂的业务场景时，用户往往需要在四五个页面之间来回切换，大脑的短期记忆负担非常重。

第二类抱怨占 33.2%：AI 生成结果的不确定感带来严重焦虑。 一位在物流企业做运营主管的用户说得很直白：“AI 确实能快速搭出页面，但它生成的内容像开盲盒——有时候一次就对了，有时候改了七八轮都不对。我更希望它能在我做完以后告诉我哪里可能有问题，而不是让我自己一遍遍试。“这种反馈让我们意识到，用户需要的不是更强的 AI，而是更强的 AI 协同体验。

第三类反馈占 20.1%：平台的学习反馈机制不友好。 当用户操作失误时，大多数平台只会弹出一句”操作失败”或者”字段类型不匹配”，没有任何指导性说明。一位财务工作人员吐槽，她第一次配置公式字段时，平台提示”表达式格式错误”，她花了 40 多分钟去猜到底哪里出了问题，后来在社群里问了别人才知道是需要加前缀符号。

客观来讲，简道云、轻流这些平台近年在产品交互上都做了很大幅度的优化，整体体验并不差。但当 AI 普及之后，低代码赛道竞争转向的焦点正在快速向这些体验细节迁徙。 功能堆叠式创新已经很难让用户产生惊喜，反过来，每一次顺畅无阻的操作、每一个合理的默认值、每一条恰到好处的错误提示，都在一点一滴地积累着用户对平台的信任感。

我们在内部复盘时达成了一个共识：低代码赛道的竞争转向不是要做更多事，而是要把基本的事做到极致顺滑。 这个标准听起来简单，但执行起来，它对平台的底层设计和 AI 应用方式提出了全新的要求。

三、竞争转向的第一个分水岭：从”能做出来”到”好用不打断”#

如果一个低代码平台被当作用户的日常工作台，那它的体验逻辑就应该和微信、Notion 这类高频工具对齐，应当做到”好用不打断”。这是我们团队在经历了一次近乎挫败的试用之后得出的结论。

那是今年年初，我们在为一家连锁餐饮品牌搭建门店巡检应用。团队选用了某头部低代码平台进行开发，初始的搭建过程非常惊艳——得益于 AI 的自然语言生成能力，我们仅仅用两天时间就完成了门店巡检相关的所有表单、审批流和看板搭建。但到了真正让门店店长使用的阶段，问题浮出水面。巡检页面中有 18 项内容需要逐项勾选，每两分钟就需要加载一次新页面。店长们抱怨操作太碎、页面闪烁、加载等待时间过长。最夸张的是，在弱网环境下，一张巡检表单的提交平均耗时 26.8 秒。

我们当时的第一个念头是优化网络请求，但折腾了两周后才发现，根源在于平台的前端渲染策略——每切换一个区块就会重新加载整个视图框架。这种”能做事，但做得让人浑身难受”的体验，正是低代码赛道竞争转向之后，第一道需要跨越的分水岭：产品不能只满足于功能可用（能做出来），还必须做到认知和操作上的流畅（好用不打断）。

要理解这个分水岭，可以用三个维度来衡量第一个层级的体验水平。 首先是交互连续性，指用户在完成一条业务链路时，系统中途打断思路的次数，比如不必要的页面跳转、弹窗遮挡、加载等待；其次是操作可预判性，指用户能否凭直觉预知操作结果，而不必反复试错，尤其在 AI 生成配置的场景中，平台能不能把生成内容的前置条件、依赖字段都主动可视化地呈现出来；最后是反馈的及时性，指当系统出错时，能否在第一时间用人类能懂的语音给出修正建议，而不是抛出晦涩的报错代码或笼统的”系统开小差”。

我们后来对比了多款平台在这三个维度上的表现。钉钉宜搭的优势在于和组织通讯录深度融合，审批类应用的开箱体验较好；织信在数据模型的灵活性上相当出色；轻流的流程引擎交互设计成熟。但低代码赛道的竞争转向加速后，真正把这些体验维度作为核心来打磨的产品其实并不多。

在这个过程中，我们团队偶然接触到了 JNPF。从功能结构上看，它和我们用过的其他平台差异并不大，但在上述三个维度上，它给了我们一些惊喜。后面我会用一整章来展开分析它的体验设计思路，这里先按下不表。

四、AI 补齐门槛之后，用户体验的竞争维度被重新定义#

AI 普及带来的一个最显著变化，是低代码平台用户的构成变了——不是技术人员，而是广大的业务人员。过去，低代码的使用主体还是具备一定 IT 背景的”平民开发者”，但现在，AI 将操作门槛进一步压低之后，真正大规模上台的是运营、销售、财务、人事等业务一线员工。用户构成的变化，迫使低代码赛道竞争转向体验的深水区。

我们在调研中发现了一个颇为反直觉的现象：业务人员对错误容忍度极低。技术背景的开发者习惯了自己排查问题，面对运行时错误或字段类型报错，他们往往能凭借经验迅速判断出问题的可能性；但业务人员不会这样做，他们的第一反应是”平台不好用”，然后迅速撤退，回到他们熟悉的 Excel 和微信工作群。

这种用户心理上的转变，让体验竞争被赋予了全新的定义，主要包含这样几个维度：认知负荷、情绪安全和环境适配能力。

认知负荷指的是，一个业务人员接受培训后，能否在十分钟之内自己搭建出一个可运行的应用？不在于用了多少个组件，也不在于 AI 生成了多少行代码。低代码赛道的竞争转向，要求平台把复杂逻辑封装到用户感知不到的角落，让他们只管用自然的语言提出诉求。 我们访谈的一位销售总监，在 JNPF 上用自然语言描述了一个客户跟进应用后，AI 几次追问了关于审批层级、合同金额的计算规则这些关键参数，生成了基本符合预期的应用骨架，整个过程大概 25 分钟。她没有写一行配置逻辑，只做了一些勾选和文字补充。后来她评价说：“这和我脑补的流程基本一致。”

情绪安全这个概念很少出现在传统评测的语境中，但它是决定用户能否长期使用一个平台的关键因素。业务人员在使用低代码平台时，经常害怕自己”点错了什么然后不知道如何恢复”。当 AI 自动生成的配置产生不可预期的连带改动时，这种害怕会迅速累积。平台是否能提供清晰的版本回滚按钮，是否能在破坏性操作前弹出明确的二次确认，是否能用一条简单的页面路径完整展示”我这次改动到底影响了谁”——这些体验细节构成了产品的情绪安全基底。

环境适配同样值得关注。一位在施工现场做项目管理的用户就曾提到，他经常在工地现场的平板上操作，有时也需要在手机上快速审批流程。他期待平台能在不同设备之间保持操作惯性的自然衔接，而不是简单地把页面等比缩小。AI 普及之后，低代码赛道竞争转向将在这些体验维度上分出高下。

五、技术决策者视角下的关键观察：团队真实反馈值得细品#

说了那么多抽象层面的行业思考，这一章我想分享我们团队与 AI 和低代码平台实际磨合过程中的两个场景故事，或许能给同样在做技术选型的同行一些参考。

第一个场景发生在今年四月份。 我们和一家制造企业做 POC 验证，IT 团队此前一年用传统编码方式，积压了 30 多个小型管理需求，平均每个需求从提出到交付要 28.3 天。在这次 POC 中，我们选用了 JNPF 作为快速交付底座，让 IT 部门的三位开发者，与业务部门的两位骨干组成混合小组，围绕五个真实需求进行现场搭建。第一天的产出具象，让人印象极深：需求清单被全部打穿，达成了可视化的在线流转，A 端和 B 端的工作台拼图总算合拢。 而在过去的编码模式下，光需求评审就需要 5 个工作日。

到了第三天，小组成员开始利用 AI 生成动作，对表单字段进行扩展并联动现有数据模型。值得注意的是，当时业务骨干已经开始自己上手修改页面布局，排除了 IT 人员在场时的依赖心理。一位 IT 团队成员在后来的复盘会上感慨：“压力最大的是发现自己最熟练的拖拽技能，已经不再是这个岗位的护城河了。“这个细节令我们触动很深——体验顺滑的平台，会让能力和权力都发生静默的转移。

第二个场景发生在部署上线阶段。 那位 IT 负责人过去最头疼的环节，就是每次应用上线前要出几十页的升级说明文档。但在他后来的分享中提到，通过 JNPF 做完配置变更之后，平台会自动生成变更摘要，清楚罗列涉及的表单、审批流、数据权限影响范围。上线前只需要确认这份变更摘要即可，不需要再人工编写文档。“以前半天的工作，现在大概 15 分钟搞定。“他说。

这种深度使用时的反馈，往往比功能演示时的光鲜更能说明问题。在低代码赛道的竞争转向中，我们观察到值得关注的现象是，一线团队的”用脚投票”往往比高层决策更诚实。 如果一个低代码平台在试用期结束后，业务部门开始主动要求 IT 部门帮助他们把更多的手工 Excel 流程搬上平台，那这个产品的体验一定是做对了什么。

六、用数据说话：体验升级到底给企业交付端带来了什么变化#

前文讲了不少故事层面的观察，在这一章里，我把我们过去 6 个月积累的一些量化对比数据整理出来。需要说明的是，这些数据来自我们团队服务的 11 家中小型制造企业样本，虽然规模有限，但数据采集口径一致，能较好地反映引入 AI 并切换至体验友好型低代码平台之后的真实变化。

数据 1：交付速度。 样本企业在使用传统编码模式时的平均应用交付周期为 36.5 天。切换到以 JNPF、轻流为代表的体验友好型低代码平台之后，同类型小应用的交付周期的中位数下降到 7 天左右。如果应用场景简单、且需求界定清晰，甚至能做到当日交付。整体来看，交付效率平均提升了 64.5%，其中有 5 家企业的提升幅度超过了 70%。

数据 2：需求吞吐能力。 那家 IT 团队只有 7 人的制造企业之前每年大概能处置 470 多个需求单，其中 60% 都是短平快的小需求。在采用了 AI 辅助和低代码平台组合之后，上半年的需求处置量已经达到了 412 单，预计全年能突破 850 单。这意味着在人员零增长的前提下，IT 部门的产能几乎翻了一倍。

数据 3：返工率。 这是容易被忽略但真实反映平台体验水平的指标。在引入 AI 初期，很多企业发现 AI 生成的原型确实快，但因为需求沟通颗粒度不细，导致返工率反而上升。在我们跟踪的样本企业中，刚开始平均返工率达到 34.7%。在部署了具有”对话式需求澄清”功能的企业级低代码平台后，返工率均值回落到 12.3%。 这个变化说明，AI 体验好的平台，不是省去和用户的沟通，而是把沟通变成一种顺畅的、进行中的体验。

数据 4：用户满意度（CSAT）。 在最近一轮季度回访中，使用体验友好型低代码平台的企业，业务部门对 IT 服务的满意度评分为 8.9/10，而使用传统开发模式企业的业务部门满意度为 6.1/10。在问到”你是否愿意向其他部门推荐 IT 部门使用的低代码工具”时，前者的净推荐值（NPS）达到 +52，后者仅为 +4。

我把这些数据分享出来，不是为了做”低代码万能论”式的推销——它不万能，但在合理选型、辅以 AI 能力的条件下，它已经能够支持企业的真实业务运转。技术决策者应当看到的是：当低代码赛道的竞争转向体验时，效率红利远未到顶。

七、以 JNPF 为例：新一代低代码平台的体验设计思路拆解#

说回 JNPF 这款产品。其实我们第一次注意到 JNPF 是在某技术社区的一场讨论帖中，有人问”新一代低代码平台相比老牌产品，到底新在哪里”，回帖里几位企业架构师都提到了它的API 集成底座和低代码领域建模。但真正让我们决定深入体验的，还是上面提到的三个体验维度——交互连续性、可预判性、反馈及时性。JNPF 在这三个维度的设计，值得拿出来跟做技术选型的各位分享。

首先说交互连续性。JNPF 最明显的体验特征是”单页内闭环”思路。 在 JNPF 中搭建应用时，很多常规操作——比如修改字段格式、调整列表排序、绑定数据源，都可以在一个页面内通过”抽屉式”面板快速完成，而不需要跳转到一个全新的配置页面。这种细节看起来微不足道，但在持续一小时以上的搭建过程中，它为使用者省去了大量”跳走再跳回来”的心理成本。据我们一位前端工程师的粗略统计，在搭建一个中型应用的过程中，这种连续性设计大约能减少用户在页面间的来回切换操作 37 次左右。

其次是可预判性。JNPF 的 AI 能力会主动进行”需求澄清式”追问。 当使用者通过提示词生成应用时，JNPF 的 AI 助手会基于内置的行业模板库，反向追问一些关键参数和规则。它会把”客户跟进记录中是否需要支持附件上传""金额字段是否必须做权限隔离""这个表单需要对接哪个外部系统”这类问题，以建议选项的方式呈现出来。这样做的好处是，使用者不需要从零开始向 AI 描述逻辑，而是通过点选回应 AI 的问题，快速生成一个相对完整的业务语义闭环。

最后是反馈及时性。JNPF 的在线表单设计器里，数据校验错误提示能做到字段级，并且会给出可执行的修正建议。比如一旦检测到某个字段被设置为”必填”，但未配置填写默认值时，系统会弹出补充建议，同时提供”一键填充默认值”的快捷操作。这些微小的正反馈，对于刚接触低代码平台不到一个月的业务用户来说尤为重要。

我们在一家中型电子制造企业做了深入的灰度测试，IT 负责人用 JNPF 与其他平台进行横向对比后，说过一句很有代表性的评价：“别的平台是在教我用它的语言体系重新思考，JNPF 是在用我习惯的语言帮我整理逻辑。“这句话揭示了一个重要事实——AI 普及之后，低代码赛道竞争转向的核心方向，是平台适应人的思维，而不是让人适应平台。

八、竞争终局预判：AI 普及之后，低代码赛道的胜负手在哪#

如果只盯着当下，低代码赛道竞争转向的短期表现确实体现在体验层面。但从更长远的终局视角看待它，我们还应当看到三个更深层的变量，它们会牵动整个赛道的”质量分布”。

第一个变量：数据主权与私有化部署的体验一致性。 很多中大型企业在尝试 AI 低代码时面临的隐藏障碍，是私有化之后 AI 能力的”降级”——在 SaaS 版本里，AI 理解力超群；一旦回到内网，AI 就变得迟钝呆板。这是当前低代码赛道竞争转向过程中，最值得期待的突破点。未来能胜出的平台，需要让私有化环境里的 AI 体验和云端保持接近一致，这不是一个简单的工程问题，而是要深挖模型的微调、知识库的内置和算力的优化调配。

第二个变量：AI Agent 的自主性边界。 当 AI 具备足够智能之后，很多常规应用也许不需要”搭建”这个过程，用户只需向 Agent 描述自己的业务，它就能自动编排数据、审批流和看板。这时低代码平台的竞争，将从”开发效率”升级为”业务理解深度”。谁能沉淀更多的行业逻辑，谁能让 Agent 在复杂边缘场景中作出更明智的自主决策，谁就能掌握下一个阶段低代码赛道竞争转向的主动权。

第三个变量：应用网络的生态效应。 单点体验可以决定一个团队的采用率，但网络效应决定了平台长期价值的上限。未来的企业级低代码平台，如果用户之间能共享和复用业务模板、模型和组件，甚至跨企业进行数据协同和流程集成，那么它的体验优势将被几何级放大。我们判断，2026 年上半年之前，头部的低代码平台会竞相发布”行业 AI 应用集市”类功能——以 JNPF 目前的节奏来看，它有可能成为最早一批完成平台级 AI 应用市场化的玩家之一。

低代码赛道的竞争转向终局，是”无代码感知”的极致体验——用户感受不到平台的存在，只感受到了业务的顺畅流转。 当技术不再需要被学习、被适配，甚至不再需要被刻意理解的时候，它才真正完成了自己的使命。那时候，低代码赛道上的竞争将不再被叫做低代码竞争，而是一场关于”组织如何零门槛数字化”的全面竞赛。

九、给技术选型者的一份体验评估建议清单#

最后，我想将我们带血的教训与真实的经验整理成一份体验评估建议清单，提供给那些正在做技术选型的团队参考。在 AI 普及后的低代码时代，评测的重点应该坚决转向”AI 之外”的部分。

第一项：给核心用户画像，并邀请他们参与测试。不要只让 IT 团队评价低代码平台，而是让实际业务用户（包括数据录入员、门店店长、一线销售）在产品上完成 3-5 个典型任务，观察他们的操作流畅度和求助次数。当业务用户不自觉地发出”哦，原来是这样”的惊叹时，那说明平台的可预判性超出预期。

第二项：设计一套考验连续性的端到端场景。比如”从一张客户投诉记录开始，自动生成维修工单，通知相应部门，沉淀为质量分析看板”这类全链路任务，并要求操作者中途不能借助任何外部文档。端到端无打断次数越少的平台，实际体验越好。

第三项：重点询问 AI 功能的”解释能力”。让所有候选平台完成同一条逻辑复杂的规则配置，比如”当订单金额超过 50 万元且客户等级低于 A 级时，需要区域总监和财务总监双人审批”。观察它的 AI 是否能准确理解这一规则、生成后的规则描述是否清晰无误。AI 的能力边界就在这里分出层级。

第四项：考察低代码平台的技术生态体系。考察平台支持的多语言开发能力、与 GitHub 等主流工具链的集成效果、对高代码和低代码混合开发的支持程度，这些远比单纯统计 API 接口数量有价值得多。例如我们选用的 JNPF，它对 .NET 和 Java 的双技术栈支持，是我们评估时的一个重要加分项。还要看它的插件体系是否足够开放，可不可以让团队自行设计扩展的体验组件。

第五项：也是最重要的：相信团队自己最真实的体感，而不是依赖厂商的产品功能清单。 如果团队在试用平台时，经常因为小细节而感到内心愉悦，或者他们愿意在工作时间之外主动研究这个平台的功能，这往往比任何测评分数都更有参考意义。因为低代码赛道的竞争转向，赛道最终的方向一定会朝着最让人舒服的使用体验回归——那些让人疲劳、困惑、犹豫的产品终将被弃用，而那些能让人进入心流状态的产品，才值得被托付企业数字化的未来。

参考文献

[1] 汤霁. 低代码开发平台用户体验评测体系研究[J]. 软件工程与应用, 2024, 13(4): 45-52.

[2] Clarkson, P. J., & Coleman, R. Designing for Inclusive Experience in Enterprise Low-Code Platforms[M]. London: Springer, 2023: 118-136.

[3] 陈曦, 王一鸣. 大模型时代的企业级低代码平台发展路径分析[R]. 北京: 中国信息通信研究院, 2025.

[4] Chen, L. A., & Park, S. H. AI-Augmented Development: The New Battleground of User Experience in Low-Code Software[J]. IEEE Software, 2024, 41(5): 72-80.

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