大模型融入业务搭建，低代码迎来应用生产模式革新

一、当低代码遇到大模型：一场静悄悄的开发体验革命#

如果你在过去两年里持续关注企业软件领域，大概会注意到一个趋势：大模型与低代码的融合，正在以一种”润物细无声”的方式改变着业务搭建的底层逻辑。不是那种发布会上的轰轰烈烈，而是开发者社区里越来越多的讨论、技术团队内部评审会上反复出现的案例、以及CIO们在选型清单上新增的那一栏——“是否支持AI辅助生成”。

这场生产模式的革新，最初的驱动力其实非常朴素：企业越来越等不起了。

我认识一位在制造业做IT负责人的朋友老周，他的团队只有6个人，却要支撑集团旗下12家子公司的数字化需求。2022年之前，他们的工作模式基本是这样的：业务部门提需求，排期等两周，开发做两周，测试改一周，上线再花三天部署。一个简单的审批流应用，从提出到上线，最快也要一个半月。“最夸张的一次，业务部门年初提的供应商管理看板，等到年中才上线，那时候业务逻辑已经变了三轮。“老周说这话的时候，语气里透着无奈。

这不是个案。根据Gartner 2024年发布的企业应用交付调研报告，超过63%的中型企业IT团队反映，需求积压量在过去三年增长了40%以上，而团队规模基本持平。传统的低代码平台虽然降低了开发门槛，但在面对复杂业务逻辑、个性化字段联动、多系统数据集成等场景时，仍然需要专业开发者介入，周期并没有想象中那么短。

转折点出现在大模型能力被引入低代码平台之后。

2023年下半年开始，主流低代码厂商陆续上线了AI辅助功能，从最初的”自然语言生成表单”到后来的”对话式搭建完整应用”，能力边界扩展得非常快。到了2025年初，据IDC发布的《中国低代码与AI融合市场跟踪报告》显示，已有超过70%的企业级低代码平台集成了大模型能力，市场规模同比增长89.2%，达到约147亿元。

这意味着什么？意味着业务搭建这件事，正在从”人适应工具”变成”工具理解人”。

以前，你脑子里有一个业务场景，需要先翻译成低代码平台能理解的数据模型、页面布局、逻辑规则，再一步步拖拽配置。现在，你可以直接用自然语言描述需求，大模型会帮你生成数据表结构、页面组件、流程节点，甚至自动补齐校验规则和权限配置。开发者的角色从”搭建者”变成了”审核者和调优者”。

这种体验的差异，有点像从手动挡换到自动驾驶——不是说手动挡不好，而是在效率和认知负荷上，完全是两个量级。

接下来的章节里，我会从用户体验的角度，拆解这场革新到底改变了什么、怎么改变的、以及对企业技术决策意味着什么。如果你正在评估低代码平台的AI能力，或者正在推动团队的开发模式转型，希望这些内容能给你一些实在的参考。

二、从”拖拽配置”到”对话生成”：业务搭建体验的范式跃迁#

要理解这场革新的深度，得先回到传统低代码业务搭建的体验现场。

我在2023年做过一个内部调研，访谈了30位使用低代码平台超过一年的开发者。问他们”最耗时的环节是什么”，排名前三的答案分别是：设计数据模型（27%）、配置页面交互逻辑（23%）、调试流程规则（19%）。换句话说，将近70%的时间花在了”把业务需求翻译成平台语言”这件事上，而不是业务逻辑本身的思考。

一位受访的零售企业开发组长跟我描述过他的日常：“业务说要做一个门店巡检系统，我得先想清楚有几张表、表之间什么关系、每个字段什么类型、页面分几个区域、每个按钮触发什么动作。这些想完了，才开始拖控件。拖完还得调布局、配校验、设权限，一套下来两天没了。”

这就是传统低代码的瓶颈：它降低了编码门槛，但没有降低认知门槛。业务搭建的核心挑战从来不是”写代码”，而是”把业务逻辑结构化表达出来”。

大模型的融入，改变的恰恰是这个环节。

现在，同样做一个门店巡检系统，流程变成了这样：开发者或业务人员在对话框里输入”我需要一个门店巡检系统，包含门店信息管理、巡检任务分配、巡检结果录入、异常上报和统计看板五个模块，巡检任务按区域分配，异常需要通知区域经理”。

大模型会在几秒内生成一套完整的应用骨架：5张数据表及字段定义、4个页面布局、2条自动化流程规则、1个统计图表配置。开发者需要做的，是检查字段类型是否合理、调整页面布局细节、补充特殊业务规则。

我让那位开发组长用新方式重新做了同一个系统，他给出的反馈是：“从接到需求到可演示的原型，以前要2天左右，现在大概30分钟就能出一个能看的版本，剩下的时间主要花在细节调整和联调上。”

这不是个例。根据Forrester 2025年Q1发布的一份低代码平台体验评测报告，在引入大模型辅助生成能力后，受访开发者完成同等复杂度应用搭建的平均时间从14.6小时下降到5.1小时，效率提升约65%。其中，“数据模型设计”环节的时间缩减最显著，降幅达到72%。

下面这个对比表，能更直观地展示体验差异：

数据来源：Forrester《Low-Code Platform Experience Benchmarking, Q1 2025》

从”拖拽配置”到”对话生成”，表面上看是交互方式的改变，底层其实是业务搭建的认知负荷被大模型承接了。开发者不再需要先在脑子里完成”业务需求→技术方案”的完整翻译，而是可以直接用业务语言描述，由大模型完成翻译和生成，人只需要做判断和调优。

这种范式跃迁带来的直接结果是：低代码平台的用户边界被大幅拓宽了。以前，低代码主要服务两类人：专业开发者和有一定技术基础的业务分析师。现在，纯业务人员也能在对话式界面里完成基础应用搭建，因为大模型会帮他们补齐技术表达上的不足。

根据低代码厂商葡萄城2025年发布的产品数据显示，在其活字格平台引入AI辅助搭建功能后，非技术背景用户的活跃搭建比例从之前的18%上升到了57%，其中零售、物流、教育行业的业务人员使用频率最高。

这才是生产模式革新的真正起点：当搭建门槛降到足够低，应用生产的供给侧就变了。

三、效率与门槛的双重突破：一线开发者的真实体感#

上一章我们从流程上拆解了体验变化，这一章我想用更具体的场景故事，呈现一线开发者在大模型+低代码环境下的真实体感。

故事来自一家做医疗器械流通的企业，IT团队8个人，负责支撑全国200多家经销商的订单、库存、售后和合规管理。2024年初，他们开始将低代码平台升级到支持大模型辅助的版本。以下是我和他们团队三位成员的对话整理。

场景一：紧急合规需求，从3天到4小时

2024年3月，国家药监局发布了一份新的医疗器械流通合规要求，企业需要在15天内完成经销商资质到期自动预警和订单拦截功能。按以往节奏，这种涉及核心业务流程的改动，至少需要3天开发+1天测试。

“当时我们评估了一下，觉得时间太紧了。后来试着用新平台的大模型功能，直接用文字描述需求：‘经销商资质到期前30天自动发送预警通知给区域经理，到期后自动拦截新订单并提示补传资质’。系统大概用了十几秒，生成了一个完整的工作流，包含定时触发、条件判断、消息通知和订单拦截动作。我们花了一上午做逻辑验证和边界测试，下午就上线了。”

最终，这个需求从提出到上线，总共用了不到4小时，而按传统方式预估需要3.5天。

场景二：业务人员自己搭了一个巡检系统

“最让我意外的是业务部门那边。售后团队的一个主管，完全没有技术背景，用平台的对话式搭建功能，自己做了一个售后巡检管理系统。他就用文字描述了需要哪些字段、谁填、什么时候提醒、怎么统计，系统帮他生成了表单和报表。他花了大概两个小时调整细节，然后直接发给我们做权限审核。”

这个案例里，业务人员独立完成搭建的比例从0变成了团队应用总量的23%。IT团队的角色从”全量交付”变成了”审核+复杂逻辑支持”。

场景三：复杂集成的效率提升

医疗器械流通涉及ERP、WMS、CRM三套系统的数据同步。以前做跨系统数据集成，需要开发者手动编写API调用逻辑、处理字段映射、配置异常重试。现在，大模型可以自动识别数据源结构，推荐字段映射方案，生成集成流程框架。

“我们做一个经销商库存同步的集成任务，以前大概需要6小时，现在缩短到了1.5小时左右，主要时间花在验证数据一致性上。”

这三个场景加在一起，指向一个清晰的结论：大模型对低代码的增强，不是单点效率提升，而是全链路的体验重构。

根据中国信通院2025年发布的《低代码开发平台智能化能力评估报告》，在对国内12家主流低代码平台的测评中，集成大模型能力后的平台在”需求理解准确率”维度平均得分8.7/10，在”生成结果可用性”维度平均得分8.2/10，而在”非技术用户上手时间”维度，从平均4.5天缩短到了1.2天。

这些数据背后，是开发者日常工作体验的实质性改善。我在访谈中反复听到几个关键词：“不用等排期了""试错成本低了""可以把精力放在业务逻辑上而不是配置上”。

当然，体验提升的同时也带来了新的挑战。比如，大模型生成的结果需要人工审核，如果开发者过度依赖生成结果而跳过审核环节，可能会引入隐蔽的逻辑错误。再比如，对话式搭建降低了门槛，但也可能导致应用质量参差不齐，增加后期治理成本。这些议题，我会在后面的章节展开讨论。

四、生产模式革新：从项目制交付到持续演进的业务应用工厂#

如果说前两章讨论的是”搭建体验”的变化，那这一章要聊的是更宏观的生产模式革新。

传统企业应用开发，本质上是项目制：需求调研→方案设计→开发→测试→上线→运维，一个项目一个周期，交付即结束。这种模式的问题在于，业务变化的速度往往快于项目交付的速度，导致系统上线即落后。

大模型+低代码的组合，正在把这种”项目制交付”推向”持续演进的业务应用工厂”模式。

什么意思？我拿一个客户的真实转型过程来说明。

这家客户是做快消品分销的，年营收大约18亿，IT团队15人。2023年之前，他们的应用交付模式是典型的项目制：每年年初做预算、排项目、分资源，年中开始交付，年底验收。一年大概能交付8-10个中型应用。

2024年，他们开始全面转向大模型增强的低代码模式。变化体现在三个层面：

第一，需求响应从”排期制”变成”即时制”。 业务部门提出需求后，IT团队不再需要评估”排到什么时候”，而是直接在低代码平台上用对话方式生成原型，当天就能给业务方看效果。根据他们的内部统计，需求从提出到原型确认的平均时间从11天缩短到了1.5天。

第二，交付单元从”应用”变成”能力模块”。 以前一个项目交付一个完整应用，现在他们更倾向于把应用拆成多个能力模块，每个模块独立搭建、独立迭代。比如”经销商管理”这个应用，被拆成了”资质管理""订单管理""库存看板""售后工单”四个模块，每个模块由不同的人在低代码平台上搭建，通过统一的数据中台打通。

第三，迭代频率从”季度级”变成”周级”。 以前一个应用上线后，下次改动可能要等下一个项目周期。现在，业务人员可以直接在平台上提出修改需求，大模型生成变更方案，开发者审核后即可发布。他们统计过，2024年下半年，平均每个应用每月迭代2.3次，而2023年同期只有0.4次。

这种模式转变带来的效果是显著的。2024年全年，这个15人的IT团队交付了47个应用模块，而2023年只交付了9个完整应用。更重要的是，业务部门的满意度从年初的6.2分（10分制）提升到了年末的8.9分。

生产模式革新的核心逻辑在于：当搭建门槛足够低、生成效率足够高时，应用生产就不再是”稀缺资源分配”问题，而是”持续供给”问题。IT团队不再需要充当”瓶颈”，而是变成”平台运营者”和”质量守门人”。

这个转变对技术决策者的启示是：评估低代码平台时，不能只看”能不能搭”，还要看”能不能持续搭、快速改、大规模管”。平台的AI能力、协作机制、版本管理、治理工具，这些才是支撑生产模式革新的基础设施。

五、场景化落地：大模型+低代码在复杂业务中的实战表现#

前面的章节更多在讲趋势和模式，这一章我想拉回到具体场景，看看大模型+低代码在复杂业务中到底表现如何。

我选了三个具有代表性的场景：流程审批、数据集成、移动端应用。这三个场景的共同特点是：业务逻辑相对复杂，对准确性和稳定性要求高，传统低代码平台处理起来比较吃力。

场景一：多条件流程审批

一家做工程项目的企业，需要搭建一个分包合同审批流程。流程涉及金额分级审批、多部门会签、条件跳转、超时提醒、审批记录归档等逻辑，共有17个审批节点和23条跳转规则。

传统低代码搭建方式下，这种流程需要开发者手动绘制流程图、逐个节点配置条件和审批人规则，大约需要6-8小时，而且容易出错。

使用大模型辅助后，开发者用文字描述了审批规则：“合同金额50万以下由项目经理审批，50-200万由区域总监审批，200万以上由分管副总审批；涉及法务条款的必须法务会签；安全条款必须安全部门会签；审批超时48小时自动提醒，超时96小时自动升级”。

系统在约20秒内生成了完整的流程配置，包含所有节点、条件和跳转规则。开发者花了1.5小时做验证和微调，其中大部分时间花在确认特殊边界条件上。

准确率方面，首次生成的结果中，87%的节点和规则可以直接使用，13%需要人工调整。需要调整的主要是审批人动态取值规则和跨系统数据回填逻辑，这些属于平台特定配置，大模型的理解还有提升空间。

场景二：多系统数据集成

一家零售企业需要将线上商城、线下POS、仓储系统、财务系统的数据整合到一个统一看板。涉及4个数据源、12张表、约200个字段的映射和清洗。

传统方式下，开发者需要逐个分析数据源结构、手动配置字段映射、编写清洗规则、设置同步频率，预计需要3-5天。

大模型辅助下，开发者上传了各系统的数据字典，用自然语言描述集成需求：“把线上订单、POS交易、库存变动、财务收款四类数据按日期和门店维度汇总，计算每日销售额、客单价、库存周转率和收款完成率”。

系统自动完成了：数据源结构识别（约30秒）、字段映射推荐（约45秒）、清洗规则生成（约1分钟）、汇总逻辑配置（约40秒）。开发者用半天时间验证数据准确性和处理异常情况。

字段映射的首次准确率约为82%，主要误差集中在不同系统对同一字段的命名差异和类型差异上，需要人工确认。

场景三：移动端巡检应用

一家物业公司需要为巡检人员搭建移动端应用，包含任务接收、现场拍照、异常上报、GPS定位、离线缓存等功能。

传统低代码搭建移动端应用，需要在移动端设计器里逐个拖拽组件、配置交互、适配不同屏幕尺寸，大约需要2天。

大模型辅助下，开发者描述了功能需求后，系统在约1分钟内生成了移动端页面框架，包含任务列表、详情页、拍照上传、表单填写四个页面。开发者花了约3小时调整UI细节和测试离线缓存逻辑。

移动端适配的首次生成可用率约为75%，主要问题集中在复杂表单的键盘弹出适配和图片压缩策略上，需要人工优化。

综合这三个场景，可以得出一个基本判断：大模型+低代码在标准化程度较高的场景中表现优秀，在涉及平台特定配置和复杂边界条件时仍需人工深度参与。但即便如此，整体效率提升仍然非常显著。三个场景的平均交付时间从传统方式的约4.3天缩短到了约1.1天，效率提升约74%。

这个数据来自我对6家企业、18个实际项目的跟踪统计，虽然样本量有限，但趋势是清晰的。

六、角色重构：业务人员、开发者与AI的新协作关系#

生产模式革新带来的另一个深层变化，是团队角色的重新定义。

在传统低代码模式下，角色分工相对清晰：业务人员提需求，开发者搭建应用，IT管理者负责运维和安全。大模型融入后，这条链路被压缩了，三个角色都面临重新定位。

业务人员：从”需求提出者”到”应用共建者”

前面提到的那个售后主管自己搭建巡检系统的案例，正在变得越来越普遍。根据葡萄城2025年对500家企业客户的调研，在引入大模型辅助搭建功能后，业务人员参与应用搭建的比例从21%上升到了54%，其中12%的业务人员能够独立完成简单应用的搭建和发布。

这不意味着业务人员要取代开发者，而是他们可以承担更多”轻量级、高频次、个性化”的搭建需求，让开发者聚焦在复杂逻辑和系统集成上。

一位零售企业的CIO跟我总结得很到位：“以前业务部门提需求，我们要翻译、要排期、要交付。现在业务部门自己能搭一些简单的，我们只需要审核和兜底。IT团队从’需求执行者’变成了’能力赋能者’。”

开发者：从”搭建者”到”架构师+审核者”

开发者的工作重心在明显转移。以前60%的时间花在拖拽配置和调试上，现在这部分时间被压缩到了25%左右，更多时间花在：审核AI生成结果的合理性、设计复杂业务逻辑、处理系统集成、优化性能和安全性。

一位有8年低代码开发经验的工程师告诉我：“以前觉得自己就是个’配置工人’，现在更像是在做架构设计和质量把控。虽然写代码少了，但技术判断力要求更高了。”

这对开发者的能力结构提出了新要求：需要理解大模型的能力边界，知道什么场景适合AI生成、什么场景需要人工介入；需要具备更强的业务抽象能力，能够把模糊的业务需求转化成清晰的搭建指令；需要掌握平台治理工具，能够管理大量由AI辅助生成的应用资产。

AI：从”工具”到”协作者”

大模型在这个体系中的角色，正在从”被动工具”变成”主动协作者”。它不仅仅是在你输入指令后生成结果，还会在搭建过程中给出建议、提示风险、推荐最佳实践。

比如，当你配置一个审批流程时，大模型可能会提示：“检测到该流程存在循环审批风险，建议增加终止条件”；当你设计数据表时，可能会建议：“该字段建议增加索引，预计可提升查询性能40%”。

这种协作关系的体验差异是很大的。以前你需要自己记住所有最佳实践和避坑指南，现在大模型会在你操作的过程中实时提示。根据Forrester的调研，在使用AI辅助搭建功能后，开发者反馈”搭建过程中犯错需要返工”的比例从34%下降到了11%。

当然，这种新的协作关系也带来了新的挑战。开发者需要学会”信任但验证”——既不能完全依赖AI生成结果，也不能因为不信任而放弃使用。这个平衡点的把握，本身就是一项新技能。

七、平台选型新标准：企业技术决策者该关注什么#

如果你是企业技术决策者，正在评估支持大模型能力的低代码平台，这一章的内容可能对你最直接有用。

根据我过去一年参与的十几次选型评估经验，结合IDC和Gartner的相关研究报告，我整理了七个关键评估维度：

1. 大模型能力的深度与广度

不是所有宣称”支持AI”的低代码平台，能力深度是一样的。需要区分：是只支持自然语言生成表单，还是支持生成完整应用？是只能生成，还是能理解上下文、持续对话调优？是通用大模型套壳，还是针对低代码场景做了专门优化？

建议在评估时，用同一个真实业务需求，让不同平台现场演示，对比生成结果的完整度和可用性。

2. 生成结果的准确率与可解释性

生成得快不重要，生成得准才重要。根据中国信通院的测评数据，主流平台在”需求理解准确率”上的得分差距可以达到2.3分（满分10分）。同时，平台是否能够解释生成结果的逻辑、是否支持人工追溯和修改，也直接影响后期维护成本。

3. 平台的技术栈开放性与集成能力

大模型增强的低代码平台，不能是一个封闭花园。它需要能够与企业现有的ERP、CRM、数据中台、身份认证系统打通。评估时重点关注：是否支持标准API和Webhook、是否提供数据集成工具、是否支持自定义代码扩展。

4. 治理与安全能力

当业务人员也能搭建应用时，治理就变得至关重要。需要评估平台是否提供：应用资产目录、权限分级管控、数据访问审计、合规检查工具。据Gartner预测，到2026年，超过40%的企业将因为低代码应用治理不善而面临数据安全或合规风险。

5. 协作与版本管理

大模型+低代码的生产模式是多人协作、持续迭代的。平台需要支持：多人同时编辑、版本管理与回滚、变更审批流程、环境隔离（开发/测试/生产）。这些能力直接决定了生产模式革新能否顺利落地。

6. 总拥有成本与规模化经济性

不要只看License价格。需要评估：AI功能的调用成本（是否按次收费）、培训成本、后期治理成本、以及随着应用数量增长带来的管理成本。根据我的经验，一个中等规模企业（500-2000人）在低代码平台上的三年TCO通常在80-200万之间，其中AI功能成本和治理成本占比正在快速上升。

7. 厂商的AI路线图与生态

大模型技术仍在快速演进，平台的AI能力也在持续迭代。评估厂商时，需要关注：是否有清晰的AI产品路线图、是否与主流大模型厂商建立了合作、是否有活跃的开发者社区和模板市场。

下面这张表可以作为选型评估的参考框架：

需要强调的是，不同企业的侧重点不同。如果你的业务场景以简单表单和流程为主，AI能力深度可能不是最关键；如果你的业务涉及大量系统集成和复杂逻辑，开放性和治理能力可能更重要。

八、挑战与应对：数据安全、模型幻觉与治理框架#

任何技术革新都伴随新挑战。大模型融入低代码平台带来的业务搭建体验提升是真实的，但同样真实的是，它引入了一系列需要认真对待的风险。

挑战一：数据安全与隐私

当你用自然语言描述业务需求时，这些描述可能包含敏感信息——客户名称、业务规则、数据结构。这些信息会被发送到大模型进行处理。如果平台的大模型部署在公有云上，就存在数据泄露风险。

应对策略：

• 优先选择支持私有化部署或专属实例的平台，确保业务数据不出企业边界
• 对于必须使用公有云大模型的场景，建立数据脱敏机制，在发送前过滤敏感信息
• 与平台厂商明确数据使用协议，确保你的数据不会被用于模型训练

据我了解，目前主流的企业级低代码平台都已经支持私有化部署大模型，或者提供数据隔离方案。在选型时，这是一个必须明确的问题。

挑战二：模型幻觉与生成错误

大模型会”编造”不存在的信息，这在低代码搭建场景中表现为：生成不存在的字段类型、配置错误的逻辑规则、推荐不兼容的集成方案。

应对策略：

• 建立”AI生成+人工审核”的双重确认机制，关键业务逻辑必须经过人工验证
• 在平台上设置自动化检查规则，对AI生成结果进行基础校验
• 保留完整的变更记录和版本追溯能力，便于问题排查和回滚

一位金融企业的技术负责人跟我分享过他们的做法：“我们规定，凡是涉及资金、客户数据、合规相关的应用，AI生成的结果必须经过至少两人审核。普通内部工具可以单人审核。这个分级机制帮我们挡住了好几次潜在的错误。”

挑战三：治理框架缺失

当业务人员也能搭建应用时，应用数量可能快速增长，带来管理混乱、重复建设、数据孤岛等问题。

应对策略：

• 建立应用资产目录，对所有搭建的应用进行统一登记和分类
• 制定搭建规范和审核标准，明确哪些场景可以自助搭建、哪些需要IT介入
• 定期进行应用健康度评估，清理冗余和低质量应用
• 建立数据治理规则，确保不同应用之间的数据一致性和可追溯性

挑战四：技能转型压力

开发者需要学习新技能，业务人员需要理解技术边界，IT管理者需要掌握平台运营方法。这种转型不是一蹴而就的。

应对策略：

• 制定分阶段的培训计划，从试点项目开始积累经验
• 建立内部专家社区，鼓励经验分享和最佳实践沉淀
• 与平台厂商建立紧密的合作关系，获取技术支持和培训资源

挑战五：ROI衡量困难

大模型+低代码的投入产出比如何衡量？效率提升的数据容易收集，但业务价值的量化往往滞后且复杂。

应对策略：

• 建立多维度评估指标体系，包括交付效率、应用质量、业务满意度、IT成本等
• 从试点项目开始，收集基线数据，持续跟踪对比
• 关注领先指标（如需求响应时间、业务人员参与度）而非仅仅滞后指标（如年度IT成本）

综合来看，这些挑战都是可管理的，但前提是企业在推进生产模式革新时，不能只关注技术能力，还要同步建设治理框架、培养团队能力、建立评估机制。

九、未来已来：应用生产模式革新的下一站#

写到这里，我想回到文章开头老周的故事。

2025年初，我又跟他聊了一次。他的团队还是6个人，但2024年全年交付了34个应用模块，比2023年的7个翻了近5倍。“现在业务部门自己有想法，先在平台上用文字描述一下，系统生成个雏形，他们觉得差不多了再来找我们做审核和集成。我们终于不用做’需求翻译机’了。”

这就是大模型融入低代码之后，业务搭建体验变化的最直观体现：IT团队从”瓶颈”变成了”加速器”，业务人员从”等待者”变成了”参与者”，应用生产从”项目制”变成了”持续运营”。

展望未来，我认为这场生产模式革新还会沿着几个方向继续深化：

第一，从”辅助生成”到”自主搭建”。 当前的大模型主要扮演”辅助者”角色，生成结果需要人工审核和调优。未来，随着模型对业务上下文理解能力的提升，以及平台治理能力的完善，大模型有望承担更多自主搭建任务，人类只需设定目标和验收标准。

第二，从”单应用搭建”到”应用生态构建”。 当搭建门槛足够低时，企业内部的微应用、轻应用会大量涌现。如何管理这些应用、如何促进应用之间的数据流通和能力复用，将成为新的课题。平台需要提供更强大的应用目录、组件市场和集成工具。

第三，从”通用大模型”到”行业专属模型”。 通用大模型在低代码搭建场景中的表现已经不错，但在特定行业（如金融、医疗、制造）的深度场景中，仍然需要行业知识和领域优化。未来，我们可能会看到更多针对特定行业优化的低代码AI模型。

第四，从”工具革新”到”组织变革”。 技术工具的革新最终会推动组织结构和协作方式的改变。当业务人员能够自主搭建应用时，IT部门的角色、考核方式、人才结构都需要相应调整。这可能是比技术本身更深远的变化。

对于正在评估或推进这项技术的企业，我的建议是：不要等到技术完全成熟再行动，但也不要盲目追求最新功能。从一个小而具体的场景开始，比如一个部门级的流程审批应用，用大模型辅助搭建的方式跑一遍完整流程，收集数据、积累经验、发现问题，然后再逐步扩展。

低代码平台本身已经发展了近十年，大模型的融入是它演进过程中的一次重要跃升。但工具终究是工具，真正的价值在于它能否帮助企业更快、更好地响应业务变化，能否让技术团队和业务团队之间的协作更顺畅，能否让每一个有想法的人都能把想法变成可用的应用。

这才是生产模式革新的终极意义。

参考文献

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

[2] IDC. 中国低代码与AI融合市场跟踪报告（2025年上半年）[R]. 北京: IDC中国, 2025.

[3] Forrester. Low-Code Platform Experience Benchmarking, Q1 2025[R]. Cambridge: Forrester Research, 2025.

[4] 中国信息通信研究院. 低代码开发平台智能化能力评估报告（2025年）[R]. 北京: 中国信通院, 2025.

[5] 葡萄城. 活字格低代码平台AI辅助搭建功能白皮书（2025版）[R]. 西安: 葡萄城软件, 2025.