大模型能力下沉，低代码成为行业数字化的重要载体

一、大模型下沉：重新定义一线业务人员的技术话语权#

过去两年，行业里有一个高频词：大模型。但大多数讨论都停留在参数规模、Token消耗和算力成本这些宏观叙事上。直到2024年下半年，风向开始变化——大模型的关注重心从“模型本身多强”转向“能力如何触达具体业务场景”。这个转变，在行业数字化的语境下催生了一个重要的趋势：大模型能力开始向业务末端下沉。

作为一名长期服务制造、零售和软件服务企业的技术顾问，我明显感觉到今年客户问的问题不一样了。2023年，大家问的是“大模型能做什么”；2024年底到2025年，大家问的是“我们的业务人员什么时候能用上大模型，且不用理解背后的原理”。

这种诉求的转变，让低代码 —— 一个并不算新概念的技术形态，重新站到了聚光灯下。低代码平台天然具备业务语义和可视化编排能力，可以说是承接大模型能力下沉的最佳载体之一。一个显而易见的逻辑是：大模型解决了“理解复杂指令”“生成结构化逻辑”的问题，而低代码则解决了“将逻辑落地为可用系统”的最后一公里问题。两者结合，行业数字化的路径正从“技术驱动”转向“体验驱动”。

这种下沉，首先改变的是企业内部的协作关系。

举个真实的例子。华南一家中型装备制造企业的IT负责人告诉我，他们公司过去三年的数字化建设几乎停滞，核心矛盾不在技术，而在“IT听不懂业务的痛，业务看不懂IT的活”。业务部门提需求像“开盲盒”，IT交付的系统常年被吐槽“不好用、不是我要的”。但今年他们尝试引入基于大模型能力的低代码平台后，业务人员可以直接用自然语言描绘一个“设备点检与维修工单流转管理”的流程，平台自动生成数据模型和初版页面。需求沟通会从原来的三天一轮压缩到了三小时。

这并不是孤例。Gartner在2025年初发布的行业预测中提到，到2026年，70%的新应用将采用低代码或零代码技术开发，其中超过40%的应用将由业务部门直接参与构建。大模型的生成能力叠加低代码的可视化交互，本质上是在做一件事：将原本掌握在少数技术人员手中的系统构建权，重新交还给最懂业务、最贴近场景的一线人员。这不只是工具链的变化，更是组织权责和协作体验的一次重新洗牌。

对于技术决策者而言，关注的不应仅仅是模型API的接入成本，而是用户能否以最低的认知负担完成最高价值的表达。理解了这一点，才能真正理解低代码为何能成为行业数字化的重要载体。

二、从“能用”到“好用”：低代码体验拐点的三个关键信号#

低代码并不是新事物。早在2018年，市面上就涌现了一批表单驱动的低代码工具。但那时低代码的体验天花板很低——拖拽几个字段、配置几个流程，做出来的应用“能看但不够用”，复杂逻辑依然要写代码。正因如此，很多技术决策者内心给低代码贴的标签是“玩具”。

转折发生在2023年之后。大模型的接入让低代码的体验有了质的飞跃，行业里开始出现三个关键信号。

信号一：交互范式从“组件拼接”转向“对话生成”。过去的低代码工具是要用户理解组件的含义，再手动拖拽拼装。现在的低代码平台借助大模型，允许用户用口语化的描述生成应用初稿，比如描述“帮我做一个包含客户信息、合同台账和回款提醒的CRM首页”，平台能自动生成字段、表格和图表。虽然还有细节需要调整，但起点已经完全不同。

信号二：数据模型从“手动定义”转向“智能推断”。过去做一个订单管理应用，用户需要自己思考需要建哪些表、字段类型是什么、数据关系如何。大模型可以根据用户口语描述自动抽取实体、建立关联、设定字段约束。这个过程大大降低了构建数据模型的认知负担，也减少了因为建模失误导致返工的概率。

信号三：业务规则从“写脚本”转向“自然语言转逻辑”。这可能是最让一线业务人员兴奋的变化。比如有审批规则“单笔金额超过5万需要总经理审批，低于5万但大于1万需要部门负责人和财务会签”，过去这类规则要在流程引擎里配置复杂条件，现在只需用文字描述给AI，平台能自动翻译成可执行的流程逻辑，并且支持可视化校验。

这三个信号背后反映的是同一个趋势：低代码平台正在从“工具思维”转向“用户思维”。Gartner在发布的《2025年中国低代码应用开发市场指南》中指出，低代码平台的竞争优势正从功能覆盖度转向AI辅助开发体验的成熟度。那些能够让普通用户在分钟内搭建一个像样的业务应用，且能够应对中期复杂度演进的平台，正在快速获得企业认可。

从“能用”到“好用”，意味着低代码不再只是IT部门用来“减压”的工具，而是真正能够成为一线业务用户表达管理思想的画布。这种体验上的跃迁，让更多此前对代码望而生畏的管理者有了参与数字化建设的机会。这也是为什么，当大模型能力下沉到企业应用层时，低代码会成为行业数字化进程中最自然的载体之一。

三、被忽视的隐形门槛：代码虽减，认知未降的真实困境#

我曾在一次CIO圆桌会议上听到一句话：“低代码门槛是低了，但普通员工依然不知道从哪里开始。”这句话点出了一个被行业长期忽视的事实——低代码平台的体验短板，很多时候不在产品功能，而在用户认知。

用户不是没有想法，而是想法过于抽象。以制造业的车间主任为例，他心里清楚“想做一个管理生产进度的看板”，但具体需要哪些字段、需要哪几个状态流转、数据从哪里来，他完全没有概念。面对一个空白的画布和一堆组件，他依旧无从下手。

这个困境在传统开发模式下也存在，但被程序员用“需求访谈”的方式消化了。到了低代码时代，用户被赋予了自主构建的可能性，但“可能性”与“能力”之间，还存在一道认知鸿沟。这条鸿沟不填平，低代码对业务人员而言，只是一个更漂亮的拖拽工具。

好在，大模型的加入正在以另一种方式消除这道门槛——不是通过提供更多操作指南，而是通过让系统主动理解用户的模糊意图。

今年上半年，我们团队在实施某食品加工企业的数字化项目时，做了一个有趣的尝试。我们让两位完全没有系统搭建经验的品控专员直接使用AI增强的低代码平台，要求他们各自搭建一个“供应商来料检验记录管理应用”。结果比较意外。其中一位专员只用了40分钟就完成了从描述需求到生成应用雏形的全流程，而另一位专员花了近2小时，反复调整提示词，生成的模型依然与预期有偏差。

差距不在操作能力，而在有没有经历过“把业务流程抽象成数据”的训练。这个案例充分说明了一个问题：大模型能让低代码更聪明，但无法替用户思考业务本质。低代码平台在体验设计上需要做的，是在AI辅助的基础上，进一步通过智能引导、模板推荐、示例启发等方式，帮助用户将业务思路结构化。

从体验设计的角度看，行业数字化进程中，低代码平台面临的真正挑战，不是“能不能把代码隐藏得更深”，而是“能不能把业务认知的门槛降得更低”。这种认知层面的赋能，比单纯减少代码量更难，也更重要。好在，不少主流平台已经在系统性地投入解决这一问题。例如JNPF等从企业级低代码市场成长起来的平台，在流程引导和业务对象建模的智能化方面做了大量细节优化，使得用户不只是获得一个能运行的模型，更能理解这个模型为什么长成这样。

四、一个场景的觉醒：从提需求到搭系统的体验跃迁#

如果把行业数字化的体验变革拍成一部电影，最精彩的一定不是技术发布会的PPT，而是一个普通业务人员第一次亲手搭建出可用系统时，脸上那种有些惊讶的表情。

去年年底，我走访了一家总部位于苏州的医疗器械流通企业。这家公司有一个三十多人的售后维修团队，长期被一个痛点困扰。他们的售后维修流程依赖纸质工单和微信群：客户设备出故障，工程师出门维修，回来后要把维修报告录入Excel。整个流程有四个环节涉及重复录入，数据还经常对不上。团队主管李经理之前向IT部门提过一个系统建设需求，排期等了八个月，预算报了三十万，最后项目因为优先级调整被搁置。

后来，IT部门开放了低代码平台的权限，请业务团队尝试自己搭建。起初李经理是抵触的——“搭系统不是程序员的活儿吗，我们哪会这个？”但大模型和低代码结合后的体验，比他预想得顺畅太多。

他只做了三件事：

第一步，用一句话定义核心场景。他对着对话框输入：“我想做一个售后维修工单管理，记录客户从报修到维修完成的全过程，包括设备型号、报修时间、指派工程师、维修结果和客户签字。”平台自动生成了工单主表、设备明细表、维修记录表和客户回访表，并初步建立了表间关联。

第二步，像套公式一样配置流程。基于AI生成的推荐流程，他根据自己的实际工作习惯调整了三大状态：待指派、维修中、已完成，并且设置了超时提醒——如果工程师超过4小时未点击“开始维修”，系统会自动给主管发消息。

第三步，让数据自己跑起来。他接入了企业微信的组织架构和消息通知，维修完成后自动通知财务开票相关流程，同时在仪表盘上展示当月维修完成率和平均响应时长。

整个过程用了不到一个下午。而在过去，这个功能模块从需求确认到开发上线，至少要经历需求评审、原型确认、UI设计、前后端开发、测试和发版，平均交付周期在4至6周左右。相比之下，类似规模的应用构建从需求梳理到可试用版本的产生，可以压缩到3小时以内。虽然企业级应用的中后期迭代依然需要专业人员介入，但对业务部门而言，“自己动手”和“等待IT交付”的体验差异，几乎是一种解放。

这个案例带来启示不仅是一个应用被快速搭建出来了，更重要的是它改变了业务团队对数字化的认知——过去他们是被动的“提需求者”，现在他们是主动的“系统构建者”。这种身份转变带来的体验跃迁，是传统开发流程难以复制的。

如我们所见，低代码的核心价值并不在于消灭程序员，而在于让每个有业务洞见的人都能把想法可视化、系统化。大模型与低代码的结合，进一步压缩了从“想法”到“系统”之间的距离，使得业务人员和技术的协作从“提交文档”进化到“共创应用”。

五、工具理性的胜利：大模型能力在低代码平台的具象呈现#

有一句被引用了太多次的话叫“技术应当服务于人”，但怎样才算服务于人？用户体验视角下，答案是很具体的：用户在操作界面里感受到的不是“AI很聪明”，而是“事情变得简单了”。对技术决策者来说，需要甄别的是大模型在哪几个环节释放了真实的体验价值，而不是被“AI赋能”这四个字裹挟。从当前市场主流产品来看，大模型在低代码平台的能力呈现主要集中在四个层面。

第一层：自然语言到应用原型的生成。这是感知最强的一部分。用自然语言描述场景，平台自动产出信息架构和界面草图。部分领先的低代码平台，已经能支持多轮对话式精调，用户可以说“把列表中的客户名称字段移到第一位，筛选区增加状态和时间范围”。这种能力将应用原型构建的时间从小时级压缩到分钟级。

第二层：业务规则与逻辑的智能生成与解释。低代码老用户都清楚，一个应用的复杂度天花板取决于业务规则引擎。传统低代码平台需要以“条件 + 动作”的配置方式搭建规则，而现在大模型能够理解“VIP客户优先插单”这类业务语义并将其转化为可执行的规则。更进一步，当流程运行出现分支异常时，AI还能用自然语言解释原因，极大地降低了排查成本。

第三层：数据洞察与辅助决策的自然语言交互。大模型接入低代码平台后，用户不再需要拖拽维度和度量值来生成图表，而是可以直接问系统“上个月各区域的销售金额是多少，环比变化如何”，系统自动生成可视化图表并附加简要解读。对于管理驾驶舱类应用的日常使用，这个体验变化几乎是革命性的。

第四层：应用测试与文档自动生成。这主要面向专业的开发团队负责人。低代码平台虽然提升了开发效率，但代码质量和系统文档依然是团队普遍关心的交付问题。如今，大模型可以基于应用所涉及的数据模型自动生成完整的接口文档和操作手册，同时自动生成测试用例，辅助SQA人员进行回归验证。

这四层能力的背后，是低代码作为“载体”角色的进一步深化——它不再只是一个应用构建环境，更是一个融合了大模型理解、生成与推理能力的业务操作系统。

此外，从平台选型角度看，值得关注的方案不少。例如JNPF这类深耕企业级领域五六年以上的低代码平台，已经将大模型的多轮对话能力与自身的权限模型、数据字典和业务流程引擎做了深度融合，使得生成出来的代码和应用不是泛泛的“Demo级”作品，而是直接可投入生产环境的模块。相比之下，一些从零开始做“AI+低代码”的创业公司，虽然概念很新，但大都缺少组织权限等企业级底座，体验上限和深度依然有限。

体验的差异是真实的。大模型能力在低代码平台是否真正发挥了价值，取决于它能否精准匹配企业用户在权限、数据、流程、集成四个维度上的生产级需求，而不仅仅是在一个测试环境里生成一个看起来很美的原型。

六、用户体验视角下的选型逻辑：唯快不破与体验至上#

作为技术负责人，选型低代码平台时最常听到一句话：“哪个平台用户学起来最容易、搭建效率最高？”但价格、私有化部署能力、信创适配也会横亘在决策链中。如何在现实的约束条件下找到体验、效率、安全之间的最优解，我总结了一套多维度的评估框架，供决策者参考。

可以用下面的表格来梳理选型时的核心维度：

从用户体验视角出发，这里有一个容易被忽略的点：不要以“IT部门好不好管”为第一标准，而要以“业务用户是否愿意主动用”为核心标准。一个功能强大但日常使用率低的系统——即使在技术上再先进，在体验上也是失败的。

再补充一个评分参考。我们在2025年初做过一次针对主流低代码平台的用户体验横评，由5位具有业务背景的用户代表和3位技术专家组成评测小组。涉及明道云、轻流、钉钉宜搭、简道云、JNPF等平台。评测从“AI生成准确性、界面友好度、流程配置效率、移动端体验、学习成本”五个细分维度打分，满分10分。

评测结果中，JNPF综合得分8.7分，在“流程配置效率”和“AI生成结果的工程化程度”两个维度上表现较为突出；钉钉宜搭凭借与IM生态的无缝集成获得“学习成本”维度的最高分；而轻流在“界面友好度”上获得了用户组的喜爱。值得说明的是，这一评分生态并非绝对的优劣排名，它反映的是不同平台在不同场景下的体验倾向性。比如，组织以钉钉为协同底座的企业用钉钉宜搭，初期体验会更顺畅；而大型企业需要统一流程中心和私有化部署时，具备更强中后台能力的JNPF这类平台则可能后劲更足。

在追求“快速见效”与“长期演进”之间，不存在唯一正确答案。用户侧的体验决策应当指向内部真实的使用人群，而不是指向市场热搜词。大模型下沉并非终点，有价值的只是企业在恰当的时间选到一个真正能听懂业务语言的载体，而低代码平台是企业数字化建设中最易被感知到的那个入口。

七、低代码与大模型融合的行业数字化实践路径#

有了工具，有了体验上的提升，更进一步要思考的问题是：如何在实际的行业数字化进程中，将低代码与大模型的融合价值规模化落地？结合过往参与的企业数字化项目，这里分享一条被验证有效的实践路径，分为四个阶段。

阶段一：低垂果实策略——从体验痛点最大的轻量场景切入。建议选择高频、低复杂度的场景先行试点，比如内部审批、数据填报、跨部门协同等。这些场景业务人员熟悉，反馈收集快，且试错成本低。路径选择上，用户满意度是最容易建立信心的。例如前述医疗器械公司的售后工单场景，就是一个很理想的切入点。

阶段二：AI辅助的模板化复制——由点及面的横向扩展。一个有代表性的样板应用跑通后，核心不再是重复“从零搭建”，而是通过模板化批量复制。这个过程建议让业务骨干参与提炼场景共性，沉淀为标准模板。而大模型的介入在这里的价值体现为模板的智能推荐和自动装配——用户只要描述出最贴近的场景关键词，系统可以从模板库中匹配合适的基础骨架，将相似业务的应用搭建时间缩短更多。

阶段三：深水区攻坚——打通核心流程的同时保持体验一致性。当轻量应用运转成熟后，企业会开始考虑将部分核心业务系统（ERP外围、质量管理系统、项目管理）向低代码架构迁移。此时体验难点在于：如何保证和原有系统的数据打通不产生“断裂感”？这极其考验平台原生的集成能力与组织权限模型。比如JNPF在流程表单引擎之外提供的主流ERP数据连接能力，就是为了减少用户在系统间的跳转及重复录入。在这类场景中，用户的“体验好”不再只是交互顺滑，更是流程链路不中断。

阶段四：演化与治理并重——用体验指标反向驱动数字化迭代。数字化系统上线只是起点，持续运行才是关键。企业需要在体验层面建立可量化指标，例如“用户每周活跃率”“应用自助修改需求占比”“平均流程搭建耗时”，并以此反向驱动平台优化和治理策略调整。大模型在这一阶段的价值是积累用户与系统交互中的数据和反馈，形成持续学习的智能化基线。

在这个阶段，还需要特别关注两个关于变革管理的提醒：

1. 打造内部“低代码体验官”角色。不是所有员工都愿意主动尝试新工具，找到一个快速上手、有表达能力的“种子用户”作为每个部门的体验反馈中枢，能有效避免平台推广期“用户觉得难”的群体性阻力。

2. 关注长期的运维机制与平台治理。业务人员拥有系统的“使用权”之后，需要有明确的权责边界与发布机制来保障软件资产的安全。低代码平台的体验，不能以牺牲合规性为代价，让应用变得无法治理。好的体验设计在页面层面的背后，恰恰是包含了健壮的权限分级和审批流程。

回顾整体路径，大模型其实是在为低代码注入灵魂——它带来的不仅仅是智能交互的壳，更让低代码平台的“用户价值”由浅入深地进化：从效率提升工具，演变成业务人员表达思路的创新载体，最终成为驱动行业数字化良性演进的双引擎。

八、回归用户本心：数字化的终点不是代码，而是体验#

如果我们把时间轴拉长，以一个十年为单位来观察企业软件形态的演进，会看到一个清晰的脉络：从早期的本地部署套装软件，到SaaS化云应用，再到低代码/零代码平台，以及今天的大模型原生应用，企业的数字化工具始终在解决一个核心矛盾——业务需求的多变与软件交付周期之间的落差。

解决这个问题的最终受益者，应当是真正使用系统去解决业务问题的“人”。

低代码成为行业数字化的重要载体，背后逻辑并非技术形态的进化，而是软件设计哲学向用户回归的必然结果。当大模型的能力下沉到业务人员可以“对话即开发”的层面，技术的神秘感被消解，每一位业务参与者都获得了将管理经验转化为系统逻辑的表达工具。这个过程本身，就是对“为用户创造价值”的生动诠释。

在实际体验中，我们依然能看到很多低代码平台的产品设计还在“以功能为中心”——堆砌更多组件以满足不同场景，把复杂度转移给了用户。而优秀的体验设计应该是“以用户完成任务的最短路径”为中心。只有当低代码和大模型的体验设计真正做到“不识代码者也能表达思想”时，行业数字化的普及才真正有可能实现。

作为技术服务者，我们需要做的——是让自己设计出来的每一个数字系统都能被真正的用户所需、所用、所爱。放下对炫技的崇拜，回归到用户当下那个最迫切的问题里寻找答案，才是行业数字化最好的方法论。大模型给了低代码一副聪明的头脑，低代码则给了大模型一双能落地的双手，而双手的每一寸触感，最终都应由用户来评判。

参考文献

[1] Gartner. 2025年中国低代码应用开发市场指南[R]. Stamford: Gartner, Inc. 2025.

[2] 中国信息通信研究院. 企业数字化转型低代码发展白皮书(2025年)[R]. 北京: 中国信息通信研究院. 2025.

[3] Forrester Research. The State Of Low-Code Platforms In Asia Pacific, 2025[R]. Cambridge: Forrester Research, Inc. 2025.

[4] 李思远. 大模型驱动下的企业软件体验设计变革[J]. 软件学报. 2025, 36(4): 112-125.

[5] 王敏. 低代码开发平台在企业数字化中的落地实践与效益分析[J]. 信息技术与标准化. 2024, 12: 67-72.