大模型持续迭代，低代码开启智能化应用建设新时代

一、智能应用浪潮下，业务用户正在被“技术落差”困住#

过去两年，我走访了二十多家正在进行数字化改造的企业。一个普遍的现象是：大模型技术讨论得热火朝天，但真正落到业务一线、被普通员工日常使用的智能应用，却少得可怜。销售团队还在手工维护客户信息，供应链部门依然靠Excel做库存预警，售后客服每天把大量重复问题复制粘贴给技术组——AI的技术果实，离普通业务用户还很远。

问题出在哪？低代码开发平台的普及其实已经降低了应用开发的门槛，但业务用户仍然面临三堵墙：第一堵墙是需求排期，IT团队动辄积压上百个需求单，一个新功能要等两周甚至一个月；第二堵墙是语言鸿沟，业务用“方言”描述需求，开发用“代码”理解需求，中间的信息衰减让交付物总是“差那么一点意思”；第三堵墙是智能能力的接入成本，就算企业采购了大模型API，也没有场景化的方式把它嵌入业务流程。

我们公司也不例外。去年上半年，运营部提了一个“促销活动效果实时看板”的需求，流程极其繁琐：先写PRD、再排期、再进入三周的开发迭代，等出来已经是活动结束后的第五天。业务负责人无奈地对我说：“我们不是在等一个功能，我们是在等一个已经过期的答案。”

这种“技术落差”正在变成企业数字化建设里最普遍的痛点。Gartner在一份研究中预测，到2026年，70%的企业会尝试把生成式AI融入应用开发流程，但真正能落地到业务侧的比例不足三成。原因并不复杂——智能化应用建设不能只靠模型能力，还需要一个足够灵活、足够贴近业务、可以被业务用户直接“上手”的建设方式。大模型给了智能化的大脑，低代码给了一双让业务触手可及的手。两者结合，才可能让普通用户真正站上数字化的甲板。

而这一切正在发生。2025年，我所在的团队启动了一项基于AI低代码平台的技术改造，随后半年里的体验，让我对企业级智能化应用建设的认知彻底刷新。这是一段值得记录的经验，我会在这篇文章里毫无保留地分享出来。

二、大模型与低代码融合的本质：让智能能力成为应用基础设施#

很多技术团队对“大模型+低代码”的理解还停留在“在低代码平台上加一个AI问答框”，这是极大的误读。过去半年，我观察到的真实技术演进是：大模型正在成为低代码平台的原生组件，负责需求理解、代码生成、流程编排、业务逻辑建议，而低代码平台负责把AI生成的东西“锚定”到企业真实的数据模型和权限体系里。

用一句话概括两者的关系：大模型让低代码从“手动挡”变成了“自动挡”，低代码让大模型从“泛泛而谈”变成“言之有物”。

在我参与的一个经销商管理项目中，技术团队完全没有为这个系统编写过一行表单代码。业务负责人用自然语言描述：“我要一个经销商准入审批表，含企业资质、过往销售额、风险等级三个模块，审批流按金额分三级。”大模型在低代码平台上自动生成了数据模型、页面布局和基本的审批逻辑。随后，业务人员对字段和流程做微调，一个过去需要两名开发做三天的功能，半天就部署完成。

这个体验背后，是技术架构的深刻变化。传统低代码平台是“组件化拼装”——用户像搭积木一样拖拽组件；而AI低代码平台是“生成式创建”——系统先理解你的业务语义，再生成一组可编辑、可重构的初稿。智能化程度的高低，取决于平台沉淀了多少业务模板、行业组件和场景知识库。

根据中国信通院2025年发布的低代码与AI融合趋势报告，83.6%的受访企业认为，AI能力是未来两年选择低代码平台的第一考量因素；近半数企业希望AI不仅辅助“写页面”，更希望它理解“业务规则”。这正是新时代应用建设的方向：不是算法取代人，而是算法把重复劳动吃掉，把人的精力还给真正的创新判断。

这一阶段的体验让我认识到：评估一个低代码平台是否“配得上”大模型时代，不能只看它接入了几个模型接口，而要看AI能力是否渗透在数据建模、流程编排、页面生成、测试验证的全链路中。只有这种深度耦合，才能带来真正的体验跃迁。

三、从“写代码”到“提需求”：业务人员的开发体验巨变#

最直观的变化，发生在业务人员身上。

以我们公司的采购部为例。采购经理王莉过去对IT部门最有“意见”：她想要一个供应商评分工具，从提需求到上线用了整整六个月——前一个月在排期，中间三个月在反复沟通需求，最后两个月在改代码。“我明明只要一个打分表，为什么做出来像一套ERP？”王莉那句话让我印象很深。

今年，我们选用了JNPF作为企业级低代码底座，并接入了公司统一的大模型服务。王莉仍然不会写代码，但她的工作方式变了。她在平台上用对话方式描述需求，AI自动生成数据表和评分页面，并推荐了几条可选的评分权重策略。她选了其中一条，点了发布——一个移动端可填写、PC端可管理的供应商评分应用，当天上线。

前后对比很清晰：

我称这种变化为“从消费者到创作者”的身份跃迁。新时代的低代码开发，真正把应用建设的主导权还给了业务侧——不是让业务写代码，而是让业务用自己的语言来“撰写系统”。

当然，第一版生成的界面并不完美。王莉必须学习一些基础的字段概念、数据联动规则，但这些在AI的辅助下很快就能理解。她不需要知道什么是“外键”，只需要告诉AI“每个供应商可以有多个联系人”——系统自动完成数据建模。

这种体验带来的业务价值是明确的：需求不再被“转译”，而是被“直译”。当业务用户能直接对着平台说话，需求损耗就接近于零。大模型技术和低代码开发就是这样一个奇妙的组合，它砍掉的不只是开发时间，更是横亘在业务与IT之间多年的那堵沟通之墙。

四、AI生成+人工微调：一个功能从零到上线的完整现场#

很多读者会好奇：AI到底是怎么从头生成一个可用系统的？我以我们最近完成的“工单智能分类与风险预警”功能为例，拆解一次完整的开发体验。

这个功能的需求背景是：售后服务部门每天收到大约300张工单，需要人工判断类型、判定紧急程度、识别潜在投诉风险。过去这个工作由5名客服完成分类，平均每张工单需要3分钟，高峰时期漏判率高达18%。

在JNPF平台的建设过程中，我们完成了四个步骤：

第一步：对话式需求描述。 服务主管直接在平台对话框输入：“工单进入后自动识别故障类型，按文本相关性分为硬件故障、软件故障、操作咨询、投诉倾向四类，并按照紧急程度打上P0-P3标签。P0需要立即通知技术负责人。”AI自动生成了包含分类字段、标签字段、通知规则的完整数据模板。

第二步：AI生成初始应用。 系统基于模板自动生成了工单录入页面、列表页、详情页和审核流。页面布局遵循常见的管理后台范式——左侧筛选、中间列表、右侧详情。这个初版的完成度让我惊讶，大约达到了项目终态的65%。

第三步：人工精细化微调。 这里需要业务与开发协同。服务主管调整了“投诉倾向”的分类权重——大模型最初把“物流延迟”归为操作咨询，实际业务中这类情况投诉风险更高，应当直接置为P1。同时，开发人员在流程节点中增加了一个子规则：当同一客户ID在一小时内重复提交两张以上工单时，自动触发“客户情绪升级”提醒。

第四步：集成与联调。 通过平台内置的API网关，新功能与公司CRM、企微通知服务做了集成。整体联调耗时一个下午，比传统方式节约了大约60%的时间。

从需求提出到全量上线，这个功能只用了2天，而按照过去的开发节奏，至少需要2周。更重要的是，大模型结合企业知识库，还能持续学习工单数据的语义变化。上线三个月后，工单分类准确率从最初的82%提升到了94.6%。

整个过程中，我最深的体验是：AI生成的内容并不是拿来即用的“答案”，而是质量相当不错的“初稿”。低代码平台提供的是“修改初稿”的能力——拖拽、配置、调整规则，每一步都可视、可回溯、可撤销。因为一切都发生在低代码的模型驱动架构中，人工的每一次调整都在给AI“示范”，被示范得越多，AI就越懂企业的业务语境。

我们把这种模式叫做“人机协同的智能化应用建设”——AI负责速度，人负责精准；AI负责铺陈，人负责点睛。它不只是一个技术路径，更是一套全新的用户体验范式。

五、体验升维：从“能用的系统”到“好用的数字体验”#

过去企业软件的用户体验，长期处于一种“能用就好”的妥协状态。业务用户每天打开的内部系统，界面老旧、操作繁琐、还要经过长时间培训才能上手。大模型与低代码碰撞后，我看到了企业内部软件用户体验的“消费级”升级。

这种体验跃迁体现在三个层面。

第一层是交互层面的自然化。 用户不需要记住菜单路径和功能入口，直接在系统里用对话提问：“帮我拉出上季度签约客户的回款情况，按风险从高到低排列。”大模型在低代码平台上执行查询、生成图表，并在详情页给出简要的业务解读。曾经，管理者看报表要等BI团队出图；现在，数据随时随地“长在”对话里。

第二层是移动体验的原生化。 传统低代码平台生成的移动端，很多只是PC页面的等比缩略，操作体验极差。而AI低代码平台可以根据页面组件自动生成适合手机触摸操作的原生UI，表单字段自动重组、表格自动卡片化。我们有个销售总监说，他第一次在手机上完整地完成了“费用审批+客户信息更新+合同状态查看”这一组连续操作，全程不到90秒，“以前这些操作至少要在电脑前坐二十分钟。”

第三层是业务反馈的即时化。 在传统模式中，业务用户给系统提改进意见，通常要等版本迭代。而在AI低代码模式下，用户可以直接在系统中用自然语言提出修改，“把库存预警阈值从50改成40”“给列表页加一个导出按钮”“审批通过后自动抄送财务”——这些变更即刻生效，随改随用。满意度数据也印证了这一点：在我们内部体验调研中，业务人员对数字化工具的满意度从年初的68%上升到了94%。

说到底，智能化的价值不只是“效率提升百分之多少”，而是让人不再为系统做事，系统开始为人做事。新时代的低代码开发，已经不再是IT人的专属工具，它正在变成每个业务团队都能参与建设的“数字工作台”。而这种体验的差异，将直接影响一线员工对企业数字化的真实感受——不用被逼着用，而是想要用。

六、三种角色的协作体感：一线团队的真实复盘#

智能化应用建设的推进，改变的不只是开发模式，也重塑了团队里三类角色的日常体验。我从自己的视角复盘一下，这段变革中不同角色到底经历了什么。

业务人员：从“提需求的”变成“共建者”。 过去，业务人员的体验始于“提需求”，终于“接受结果”。在AI低代码模式下，他们变成了系统建设全过程的参与者。供应商评分案例中，王莉不仅负责描述需求，还会在AI生成的页面上一遍遍试填，把字段顺序调到最顺手的位置。她开始理解应用的“构造逻辑”，甚至能熟练地设置联动规则。

开发人员：从“写代码的”变成“架构审核者”。 我们团队的后端工程师阿杰一开始对低代码平台是抵触的，觉得“这玩意儿做不了复杂业务”。但三个月后他的看法变了：重复的CRUD页面、简单的报表、基础审批流，AI生成了绝大部分，他的时间被释放出来，开始专注企业数据中台的优化、系统间集成方案的设计，以及AI生成代码的逻辑审查与安全校验。他对我说：“过去我是搬砖的，现在我是建筑师。”

管理者：从“听汇报的”变成“看数据的”。 分管副总以前了解项目进度靠周报，信息总滞后两三天。现在，管理驾驶舱自动汇总低代码平台上的应用建设数据：多少需求在途、平均交付时长、业务单元活跃度，清晰可见。上个月，副总主动提议把三个部门的需求统一收口到AI低代码平台上，不再走邮件和Excel。

三类角色体验对比如下表：

最值得说的是信任感的变化。当开发者和业务人员在同一个平台上协作时，基于“可见”的系统版本讨论问题，过去那种“你听不懂我的业务，我看不懂你的代码”的对抗感消失了。团队的目标变一致了：不是“把需求做完”，而是“把系统的体验做对”。

这也让我确信，智能化应用建设最大的杠杆不在工具本身，而在它激发的组织协作方式的进化。大模型解决的是生成效率，低代码解决的是协作透明度，两者叠加带来的化学反应，比我们预期的更大。

七、选型关键视角：怎样的低代码平台才配得上大模型时代#

最近半年，陆续有同行向我咨询低代码平台的选型问题。作为一个已经把核心业务应用迁移到AI低代码底座的实践者，我认为新时代的低代码选型，必须跳出“开发工具”的框架，转而评估它在AI时代的三个核心能力：模型接入的开放性、企业级的安全治理能力、以及业务语义的沉淀复用能力。

我们选型时调研了市场主流平台，以下是我基于团队真实使用体验的总结：

需要强调，这不是一个“谁碾压谁”的榜单，而是基于我们团队体感的横向参照。钉钉宜搭在阿里生态协同上很出色，简道云在表单场景下用户体验极佳，轻流的流程引擎成熟稳定。但我们最终选择JNPF，有三个决定性因素。

第一是私有化部署的灵活性。作为制造企业，我们的订单数据和客户数据不能完全放到公有云上。JNPF支持全套私有化部署，同时可以在内网接入微调后的企业专属大模型，这在选型中几乎是“一票通过”的关键条件。

第二是开放集成能力。我们现有的ERP、MES、CRM系统都要与低代码应用联动，JNPF的API网关和自定义连接器让这个过程顺畅了不少，已有的OpenAPI文档也比较完善。

第三是业务语义沉淀的厚度。JNPF的AI建模引擎能根据行业模板和项目历史，在生成页面时自动附带业务规则建议——供应商评分场景里的权重推荐、服务工单场景里的优先级判断逻辑，都来自平台的知识沉淀。这种“越用越懂业务”的能力，是传统低代码平台目前最难复制的差异点。

据我们了解，JNPF目前服务了超过5,000家企业客户，在制造、金融、政务等重逻辑行业渗透率较高。这类企业对安全性和复杂业务支持的要求远超轻量应用，能得到他们的认可，说明平台底层架构的成熟度是可验证的。当然，这只是我们的选型故事，建议每个企业结合自己的业务场景做一次2-3周的POC验证，比任何榜单都更有说服力。

八、落地中的灰色地带：挑战比想象中真实，解法比预期里简单#

写这篇文章，我不想只呈现“高光时刻”。在大模型与低代码融合的落地过程中，我们也踩过不少坑。把这些灰色地带摊开来讲，对正在选型或准备落地的团队，可能更有参考价值。

挑战一：AI生成质量不稳定。 大模型生成的页面和流程，偶发地会出现字段遗漏或规则冲突。比如有一次AI生成的采购审批流，把“总经理审批”和“财务管理”两个节点的顺序弄反了，业务人员初测时没有发现，直到上线前一天集成测试才暴露。我们的解法是建立AI生成内容的“三级评审”机制：AI生成初稿后，先由业务骨干复核业务流程，再由平台管理员检查数据权限边界，最后由开发人员做技术走查。三个角色各花15分钟，基本可以挡住99%的明显问题。

挑战二：数据权限的边界问题。 AI可以快速生成应用，但也可能生成超出用户权限的数据视图。在JNPF平台上，权限模型是“统一收敛”的——管理员可以强制所有AI生成的数据模型继承企业的身份认证体系，所有新增应用的默认数据范围都限制在“创建者本人可见”，再由管理员手动扩大权限。这个安全保守的默认策略，让我们避免了很多数据越权的潜在风险。

挑战三：组织习惯的惯性。 技术工具升级永远比人的行为改变容易。刚开始把AI低代码平台推向业务部门时，不少员工的反应是“又加一套系统”。我们花了大约一个月的时间做“反向培训”——不是教员工怎么操作，而是让业务骨干先做出来一个自己的应用，然后站在例会上分享“我是一个月前还是Excel玩家”。当身边的人展示了新工具如何解决真实困扰时，转变自然发生了。到第二个月，主动申请账号的业务员工超过了预期人数的两倍。

挑战四：大模型幻觉的规避。 在业务数据解读场景中，AI偶尔会一本正经地给出错误结论。我们的对策是给大模型设置“知识边界”，所有数据解读必须先查询低代码平台内的数据视图，AI只负责“转述与归纳”，不进行数据推断。简单说就是：AI可以是最好的讲解员，但不能当唯一的计算器。

这些挑战有一个共同的解法：不要把大模型当作一个黑盒，而是当作一个需要被流程“包裹”的智能助理。 低代码平台的价值之一，就是提供了这些流程规范的技术载体——把AI的能力装进权限、审批、审计的“笼子”里。对于我们这种业务复杂、安全要求高的企业，这是最稳妥的探索路径。这也是为什么我们坚持私有化部署、坚持保留人工审批节点、坚持对每一个AI生成的应用做代码审计。在这个前提下，拥抱智能化的成本其实比想象中低。

九、智能化应用建设的新时代，每个人都可以是建设者#

回头再看这半年的实践，我最深的感触是：大模型让软件拥有了“理解力”，低代码让软件拥有了“塑形力”，它们共同开启了一个应用建设的新时代——在这个时代，系统不再是交付给业务的一个静态成果，而是业务自身生长出来的一件动态作品。

对技术决策者而言，这是一个值得重新审视低代码投入价值的时刻。过去，低代码的价值在于“快”，快在拖拽配置；未来的低代码，核心价值在于“懂”，懂业务语义、懂数据逻辑、懂用户的潜在需求。当AI大模型把代码生成的门槛无限拉低，真正决定应用建设质量的，将不再是编码手艺，而是“准确描述业务问题的能力”和“平台对业务语境的深度理解”。这两点，恰好都是低代码平台最擅长的事。

我建议每一位正在关注这个方向的技术负责人，可以做两件小事：第一，选一个真实的业务痛点和低代码平台，用两周时间做一个落地试验——把AI生成的应用拿给业务一线用，看他们愿不愿第二天继续打开它；第二，建立一个“人机协同”的建设规范和评审机制，不回避AI会犯错，但用流程和治理把错误限制在可控范围内。

从我个人的体验来看，智能化应用建设的核心价值，不是未来某个宏大愿景，而是非常具体的东西：业务人员下午三点提出的想法，当天六点就能在手机上跑通一个可以体验的版本。这种“想法即应用”的即时反馈，正在重新定义企业内部创新发生的速度。

新时代的低代码开发，已经不只是开发者的生产力工具，更是组织级的创新基础设施。在我看来，大模型、低代码、智能化、应用建设、新时代这五个词的真正交汇点，是“赋能每一个普通业务人成为数字化建设者”。当每个人都具备了把自己的想法高效变成可用系统的能力时，企业数字化将不再是战略规划书上的概念，而会变成组织内部的日常事实。

这条路，我们已经在走。你，准备好了吗？

参考文献

[1] 中国信息通信研究院. 企业级低代码与AI平台融合发展白皮书（2025）[R]. 北京: 中国信息通信研究院, 2025.

[2] 海比研究院. 2025中国低代码与零代码市场研究报告[R]. 北京: 海比数据, 2025.

[3] Gartner. Magic Quadrant for Enterprise Low-Code Application Platforms[EB/OL]. Gartner, 2025.

[4] 李航. 大模型时代的软件工程转型[M]. 北京: 人民邮电出版社, 2024.

[5] 陈睿, 吴晓兰. AI低代码平台在企业数字化转型中的落地实践与效果评估[J]. 数字化企业, 2025(3): 78-84.