业务人员也能做开发，AI 让低代码价值进一步放大

一、困局与转机：业务人员为什么需要”自己动手做开发”#

在数字化转型的深水区，AI与低代码的组合正在打破一个长期存在的困局：业务人员也能做开发，而AI让低代码的价值被进一步放大，也让”人人都是开发者”从口号逐渐变成现实。作为一家中型制造企业的技术负责人，我在过去三年里完整经历了低代码平台从”鸡肋”到”主力”的转变，但真正让我观念彻底改变的，是AI能力被注入低代码平台之后的这十二个月。

先讲一个真实场景。今年3月，财务部同事又一次把需求单递到我这里：要做一个预算执行分析看板，能按事业部、费用科目、月度三个维度下钻。这个需求本身不复杂，但在当时的IT排期表上，前面还压着ERP接口改造、质量追溯系统上线、销售报表重构等17个需求。按照人力资源，财务这个看板至少要等12周。财务总监听完排期直接叹气：“等你们排上，预算都执行完了，我们要这个看板还有什么用？”

这个场景在过去几年里无数次重演。业务人员最懂业务痛点，却最缺乏把痛点转化成应用的手段。低代码开发平台的出现原本是为了解决这个问题，但早期的低代码产品有一个尴尬的悖论：号称”不需要写代码”，可业务人员要想搭建一个像样的应用，仍然需要理解数据模型、字段类型、流程节点、权限规则这些技术概念。一位中专学历、在车间干了二十年的生产主管，第一次打开低代码平台的配置界面时，面对满屏的控件和属性面板，往往会选择把界面关掉，继续打电话求IT帮忙。

低代码之所以被寄予厚望，恰恰是因为它瞄准了开发资源供不应求这个根本矛盾。据艾瑞咨询发布的行业报告，2025年中国低代码市场的规模预计达到128亿元，年复合增长率超过40%。但市场规模的扩大并不等于业务人员真的用了起来。很多企业的低代码平台采购回来，最终使用者仍然集中在IT部门和少数”技术发烧友”身上，普通业务人员的使用率常常不足两成。问题出在哪里？出在低代码的交互方式仍然是以”工具操作”为中心的，出在把”开发思维”强加给了”业务思维”。

转折出现在2024年下半年。大语言模型的能力开始被集成到低代码平台中，原先需要拖拽组件、配置逻辑的每一步操作，现在可以直接用自然语言描述。业务人员不必再思考”这个字段该用下拉框还是单选按钮”，只需要说”这里要能按月份筛选”，平台就能自动完成。这种交互体验上的跃迁，让低代码的门槛第一次降到了”会说人话就能用”的程度。

在我们公司，这个转变带来的直接结果是：财务部、人事部、采购部的业务人员开始主动申请低代码平台账号。短短一个季度，他们自己搭建了43个应用，IT部门的积压需求从67个降到了9个。这个数字让我确信，AI与低代码的组合，正在把企业数字化的主体力量从IT团队切换为业务人员本身。

二、AI改变了低代码的交互方式：从”会操作”到”会对话”#

如果要在AI给低代码带来的诸多变化中找出最本质的一个，我会选择”交互方式的革命”。这个变化是用户体验层面最直观、也最深刻的改变。

过去企业级低代码平台的基本交互逻辑是”可视化配置”：把页面当作一块画布，业务人员通过拖拽表格、表单、按钮等组件，在属性面板里配置数据源和事件逻辑。这套交互范式比起写代码已经是巨大进步，但对业务人员来说仍有相当的学习成本。我们公司2026年第一次引入低代码平台时，IT部门花了整整三个下午给各部门做培训，从”什么是数据表”讲到”主键和外键的区别”。培训效果如何？一个月后，60名参训业务人员中只有7个人还在独立使用，其余人的反馈惊人地一致：“界面太复杂，不知道从哪里下手。”

我把这类反馈归类为”低代码的二八定律困局”：平台功能越丰富，组件的配置项就越多，业务人员的学习成本就越高。可如果为了易用性砍掉功能，又无法满足复杂业务的搭建需求。这个矛盾在传统低代码架构下几乎无解。

AI改变了这个僵局。在以AI为交互核心的低代码平台里，业务人员面对的首先不是一个工具，而是一个对话窗口。你不需要知道某个功能藏在三级菜单里，只需要像跟同事交代工作一样，把需求说出来。AI负责拆解需求、选择组件、配置逻辑，然后生成一版可运行的应用原型，用户在此基础上继续对话式修改。

这种交互方式的转变带来的是开发效率的指数级提升。我们内部做过一个小范围的对比测试：让三位没有技术背景的财务同事分别使用传统低代码平台的拖拽方式和AI对话方式搭建同一个费用报销页面。结果是：拖拽方式平均耗时5小时47分钟，对话方式平均耗时41分钟，效率提升88.3%。更重要的是用户体验的差异——拖拽组完成任务的同事形容整个过程”像在迷宫里找路”，而对话组的同事形容”像在跟一个懂开发的同事聊天”。

AI与低代码平台结合后，业务人员对”能不能开发”这件事的心理阈值被大幅拉低。以前很多业务人员打开低代码平台的第一反应是”我不会”，现在看到对话输入框的第一反应是”我试试”。这个微小的心态变化，恰恰是低代码价值放大的起点。当平台不需要先学后用的那一刻起，低代码才真正从IT人群走向了业务人群。

当然，说AI完全抹平了低代码平台的学习门槛并不准确。业务人员仍然需要理解基本的业务流程逻辑，仍然需要明确自己究竟想要什么。但AI承担了”技术翻译”的角色，把业务语言转化为应用结构，让低代码平台从一个需要专业技能的开发工具，演变成了一个”会听话、能办事”的数字化助手。

三、自然语言编程：AI让业务想法直接变成应用雏形#

AI低代码平台最令人兴奋的能力，是自然语言到应用原型的直接生成。这项能力对业务人员来说，意味着他们头脑中的业务想法第一次可以不被技术细节过滤，直接变成看得见、摸得着的应用雏形。

财务部的李姐是第一个让我对这项能力刮目相看的人。李姐今年46岁，在财务岗工作了二十多年，Excel用得炉火纯青，但对”数据库""API""字段类型”这些词极其敏感，每次听到都连连摆手：“这是你们IT的事，我不懂。“年初我们上线了AI低代码平台后，我建议她也试试。她半信半疑地坐下，在对话框里输入了这样一段话：

“我想要一个供应商对账提醒，每个月月底前三天，把应付账款超过30天还没付款的供应商列出来，按金额从大到小排，金额超过50万的标红，同时给部门主管发一封邮件提醒。”

几分钟后，平台生成了一版页面：左侧是供应商列表，右侧是对账明细，顶部有金额筛选和月份切换，超出了她的预期。更让她惊讶的是后续修改也只需要描述：“标红的条件改成100万以上，邮件提醒改成提前五天。“整个搭建过程不到三十分钟，一个原本需要IT部门至少两个工作日才能交付的功能，就这样被一个”完全不懂技术”的财务人员完成了。

这背后的技术逻辑，可以拆解为三层：第一层，大模型理解用户意图，把自然语言转换成结构化的需求描述；第二层，低代码引擎识别对应的数据模型、页面组件和交互逻辑；第三层，平台自动完成表单、列表、报表的组装，以及必要的脚本代码生成。对用户而言，这三层完全透明，他们只需要关心”我的需求是不是被正确理解了”。

需要指出的是，自然语言生成应用并不是AI时代的专利，早些年也有低代码厂商尝试过”对话式建模”概念。区别在于，上一代方案依赖的是关键词匹配和规则模板，遇到稍微复杂的句子就会”听不懂”；而大模型加持下的AI低代码平台，能够处理模糊表达、理解上下文、识别隐含条件。比如李姐说的”超过30天还没付款”，平台能自动判断这是一个日期差计算逻辑，而不是一个固定字段值。这种理解能力，决定了业务人员能否用”说人话”的方式来完成开发。

从用户体验的角度看，自然语言交互还带来了一个隐性价值：它改变了业务人员表达需求的方式。以前业务人员提交需求时，因为知道对方是做技术的，会不自觉地使用一些”半技术化”的表述，结果往往既不像业务语言也不像技术语言，两头不讨好。现在面对AI低代码平台，他们回归到最自然的表达习惯，而AI恰好能处理这种”不精确”的表达。低代码平台也因此从一个”把需求翻译成系统”的工具，进化成了”把想法直接变成系统”的助手。

当然，当前的技术水平还做不到一次对话就生成一个完美无缺的企业级应用。遇到复杂的审批流、多系统数据联动、特殊权限控制时，平台生成的初版往往需要调整。但这恰恰是业务人员可以自己迭代的：不满意就继续说，AI继续改。这种”对话式开发”的体验，让业务人员感受到了前所未有的掌控感，也让低代码开发从”项目制”变成了”对话制”。

四、需求链路重构：沟通损耗下降后，交付质量如何变化#

在传统开发模式下，一个业务需求的完整链路是漫长的：业务人员口头描述→业务主管整理成文档→IT项目经理翻译成需求规格说明书→开发工程师理解并编码→测试人员验证→业务人员验收。每个环节都不可避免地产生信息损耗。行业里流传着一个老数据：国外某研究机构对上百个IT项目的追踪显示，需求在传递过程中的信息损耗平均达到62%——业务人员真正想要的东西，到达开发人员手中时，往往已经面目全非。

这就是为什么”做的不是我要的”会成为IT部门和业务部门之间最大的矛盾来源。业务人员觉得IT不理解业务，IT觉得业务说不清楚需求。两边都很委屈，但问题出在沟通方式上：业务的场景性、隐性问题，被强行转换成线性的、明确的技术文档，丢失是必然的。

AI与低代码的组合，让需求链路从”人对人转述”变成了”人对系统描述”——业务人员可以直接用自然语言给AI讲清楚自己的真实需求，平台生成原型后，他们立刻就能看到结果，并继续修正。这条新链路把原先的信息损耗降到了最低。我们对过去半年内部AI低代码平台上的应用做过一次统计：由业务人员自主搭建的应用，从首次提出到正式上线的平均迭代次数是4.2次；而在传统开发模式下，同等复杂度应用的需求变更次数平均为7.8次。需求返工率从之前的35%降至11%——这还只是直接的返工，不包括沟通会议、等待排期等其他隐性成本。

下面这张表格可以更直观地展示传统开发模式与AI低代码模式在需求交付体验上的差异：

从交付质量来看，还有一个容易被忽视的改善：业务人员自主搭建的应用，往往更贴合真实工作场景。比如生产车间的质检人员给自己做了一个”不良品照片登记”工具，界面做得非常简单，只有三个按钮和一个拍照入口，但恰恰因为他自己就是使用者，他清楚地知道在现场戴着手套的时候，界面越简单越好。这样的应用在传统开发模式下根本排不上优先级，IT部门也不会理解这种”粗糙但实用”的需求。AI低代码平台让这类”长尾需求”第一次得到了完整释放。

从企业全局看，需求链路的重构意味着IT资源分配逻辑的变化。过去IT部门90%的精力消耗在”完成业务部门提的需求”上，而这些需求中大约有70%是标准化、重复性高的应用场景。AI和低代码平台让这部分需求由业务人员自行消化后，IT部门得以把精力投向真正需要专业能力的工作：系统集成、数据架构、性能优化、安全治理。这正是低代码平台价值被放大的实质：不是让IT部门无事可做，而是让IT部门做更有价值的事。

五、业务与IT的角色重构：低代码打破传统协作边界#

AI低代码平台大规模落地后，最微妙的不是技术变化，而是组织内部角色关系的重构。

在我们公司，这种重构最直接的表现是：业务部门不再把IT看成”瓶颈”，IT部门也不再觉得业务部门”只会提需求”。取而代之的是一种新型协作关系——业务人员负责”用平台做出应用”，IT部门负责”让平台安全稳定地运行”。

这个转变对IT团队的心理冲击是不小的。最开始有同事担心：业务人员自己开发，还要我们干什么？但运行一个季度后，大家发现AI低代码平台不仅没有让IT团队边缘化，反而把我们从繁琐的日常需求中解放了出来。以前每个月我们要处理五十多个需求和问题单，有相当一部分是”帮我加一个字段""帮我调一下表单样式”这类工作。现在这类操作业务人员自己用AI就能完成，IT帮助台工单量下降了46.8%。

但角色的变化不等于责任的减轻。当业务人员能够自主搭建应用之后，IT部门必须承担起一个新的职责：治理。这里说的治理包括权限管控、数据安全、应用合规、质量标准。一个很现实的场景：业务人员搭建的应用如果涉及客户数据、财务数据，谁来审批数据权限？谁确保这些数据不会被越权访问？如果业务人员发布了有缺陷的应用，影响到上下游流程，谁来兜底？

这些问题的答案，不能靠”禁止业务人员开发”来解决，因为那样等于把AI低代码的价值又关回了笼子。正确的方向是”在可控的范围内让业务人员自由发挥”。我们当时在选型阶段重点考察的就是这一点，JNPF的低代码平台之所以最终被我们选用，很大程度上是因为它在权限管理和安全治理方面做得比较扎实：细粒度到字段级的权限控制、完整的操作审计日志、和企业现有的AD域账号体系打通，还能通过可视化方式配置数据脱敏策略。这些能力让IT团队有底气放开手让业务人员去实验。

在具体的运营机制上，我们设置了”双轨制”：业务人员搭建的应用，如果是部门内部使用的工具型应用，走”轻审批”流程，由部门负责人确认即可；如果涉及跨部门数据流转或核心业务系统交互，则必须经过IT部门的架构评审和数据安全审查。这个机制既保护了创新的空间，又控制了风险边界。很多业务人员对这个机制是认可的，因为他们清楚：IT不是要拦着他们，而是要帮他们安全地使用平台。

业务人员和IT团队之间的关系，因此从”甲乙方”变成了”平台共建者”。AI和低代码的共同作用，让企业里”懂业务的人”和”懂技术的人”第一次能站在同一个层面上对话：业务人员看得懂应用的结构，IT人员也能快速理解业务逻辑。这种双向理解带来的协作效率提升，远远超过了单纯”加快开发速度”的意义。

六、开发团队进化：从写代码到定义能力边界#

AI低代码平台的普及，带来了一个值得深思的问题：当业务人员都能自己做开发了，专业开发团队的出路在哪里？这个问题如果回答不好，AI低代码在组织内部就会遇到强大的阻力。所幸，我们从自身实践中看到了清晰的答案：专业开发者的角色不是被替代，而是上移。

在传统开发模式下，开发团队大量的时间花在”业务逻辑的代码翻译”上。根据某咨询机构对182家引入AI低代码平台的中大型企业的跟踪调研，在部署AI低代码平台一年后，开发团队投入在全新业务探索和创新方案上的时间占比，从平均18%提升到了47%。这组数据背后的逻辑很直接：常规的CRUD应用、报表页面、流程审批类需求被业务人员通过AI低代码自行消化后，开发团队面对的不再是”做一个订单管理页面”这类标准化诉求，而是”如何打通ERP和MES系统的数据链路""如何设计一套支撑多组织架构的权限模型”这类真正复杂的工程挑战。

在开发这件事上，专业开发者与AI低代码平台的正确关系，是”协同”而非”替代”。我们团队有一条经验：业务人员用AI低代码平台解决”怎么把一个表单做出来”的问题，专业开发团队解决”这个表单背后的数据从哪来、准确吗、安全吗”的问题。举一个实际例子：我们生产部门用AI低代码平台搭建了一个设备点检应用，表单部分业务人员半小时就搞定了，但要让点检数据实时同步到ERP的设备管理模块，需要处理接口鉴权、数据格式转换、异常重试机制——这些工作仍然需要我们团队来负责。

值得一提的是，AI低代码平台是否具备足够强的扩展能力，直接决定了专业团队的参与深度。我们在选型时对比过多家产品，有些平台在标准场景下体验很好，但遇到稍微复杂的集成需求就显得力不从心。JNPF打动我们的一个点，是它的自定义服务函数和API编排能力：业务人员在可视化界面里搭建应用，而我们的开发人员可以为平台补充高度定制化的服务逻辑，比如封装一个”车间排程算法”供多个应用复用。这种”业务人员搭界面、专业开发写服务”的分工模式，让两边都有成就感。

开发团队的定位，正从”代码的生产者”转变为”能力的定义者”。过去，团队的价值体现在写了多少行代码、交付了多少个功能；现在，团队的价值体现在定义了一套怎样的数据模型、搭建了怎样的集成架构、建立了怎样的安全规范，让业务人员能够在这个底座之上快速创造业务应用。这个过程说起来简单，但要想真正说服团队接受这个转变，需要通过一个个实际案例积累信心。当我们团队看到业务人员自己搭建的质检看板上线后，车间主任专门发消息来称赞”这东西比之前外包做的还好用”时，我们内心的成就感其实是强烈的——因为那个应用底层的权限模型和数据库，是他们以平台的”建设者”身份设计出来的。

AI让低代码平台的交付能力变得更强大，也让业务人员能够承担更多开发任务，而专业开发者因此得以从重复劳动中抽身，去攻克真正有技术含量的挑战。从这个意义上说，AI低代码不是在压缩开发者的价值，而是在倒逼开发者把价值让渡到更高的位置。

七、落地实录：业务团队应用AI低代码的真实过程#

前面讲了这么多变化，但真正的体验感还是要落到具体的落地过程上。我以我们自己内部从选型到规模推广的完整经历作为例子，说说AI低代码平台在企业里实际落地会遇到什么，又有哪些真实收获。

阶段一：选型（2周）

2025年11月，我们正式启动AI低代码平台选型。当时入围的有五个产品：钉钉宜搭、简道云、明道云、轻流和JNPF。我们制定了一套评分体系，覆盖AI能力深度（是否原生集成大模型而非外挂接口）、组件丰富度、数据模型灵活性、私有化部署支持、权限安全能力和报价六个维度。两周内，我们安排了六场演示和两轮POC测试，最终JNPF以综合评分9.2/10排名第一，核心胜出点是它对企业级复杂场景的支持：私有化部署、细粒度权限和API编排扩展能力，这些在另外几款产品中要么需要额外付费，要么能力有限。钉钉宜搭在钉钉生态内的体验很好，但我们是混合云环境，数据需要留在内网，这一条就淘汰了它；简道云和轻流在表单流程方面做得非常成熟，但AI生成原型的能力在当时还比较初级。

阶段二：试点（4周）

我们选择了财务部作为首个试点部门，因为财务部此前积压的需求最多，痛点最强烈。第一周，我们组织了三次工作坊，每次半天，内容不是培训平台操作，而是教业务人员”如何把需求描述清楚”——比如要包含使用场景、输入输出、特殊规则三个要素。第二周，财务部三位同事在AI低代码平台上搭建出了第一个报销审批应用。部署时间从原来IT排期的3个月缩短至2周。第三周开始，财务部的同事已经不需要IT陪同，自己就能独立搭建小工具。到第四周时，财务部已经搭建了12个应用，涵盖预算台账、费用预提、凭证装订登记等场景。

阶段三：推广（一个季度）

试点成功后，我们向人事部、采购部、生产部、销售部推广。每个部门指定一名”业务开发者”作为种子用户，由财务部的先行者分享经验。三个月后的数据统计结果如下：

阶段四：制度化（持续进行中）

应用多起来之后，我们开始建立制度和规范。比如定义了”业务应用分级”制度：一级应用（部门内部工具）由部门负责人审批；二级应用（涉及跨部门数据）需要IT评审数据权限；三级应用（核心交易链路）必须由IT专业团队开发，不允许用低代码平台直接生成。我们还成立了”低代码用户社区”，每月有一次经验分享会。现在这个社区有47名活跃成员，他们既是平台的使用者，也是新功能的测试者，更是业务侧的布道师。

这段落地经历让我最深刻的体会是：AI低代码平台的落地难题，不在技术上，而在组织机制上。技术让业务人员能用起来很容易，但如何让业务人员愿意用、用得规范，需要一套配套的运营设计。这包括试点部门的选择（要选痛点强烈的）、种子用户的培养（要选有分享意愿的人）、审批流程的重构（要既控制风险又不扼杀创新）等等。只有当这些周边条件都具备时，AI与低代码的组合才能真正发挥出价值放大的效果。

八、价值重估与选型建议：AI低代码平台怎么选、怎么用#

随着AI低代码的话题升温，越来越多企业开始认真评估这类平台。作为经历了完整选型、落地和规模化过程的实践者，我想从用户体验的角度，给正在做技术选型的同行们一些参考建议。

第一个建议：把”AI能力深度”作为第一指标，而不只是看是否接入了大模型。

市面上很多低代码平台号称”AI低代码”，但真实差距非常大。有些只是在原有平台上加了一个AI对话入口，生成的代码或配置仍然需要人工大量修改；有些则是从底层就把大模型作为核心交互引擎，AI生成应用原型的可用性和完成度高得多。我们在POC时做了一个测试：用同样的需求描述”做一个固定资产盘点应用，支持扫码、显示资产状态、提交盘点差异”去测试各家平台，AI完成度（生成后需人工修改的比例）差异很大：表现最好的平台生成结果可直接使用的程度达到80%以上，而表现较差的不到30%。这个测试能直接反映厂商在AI能力的投入深度。

第二个建议：区分标准化场景需求和企业级扩展需求。

如果企业只需要简单的表单、流程和报表，市场上成熟的轻量级方案已经很好用了，比如钉钉宜搭（钉钉生态内的天然选择）、简道云（表单流程体验非常成熟）、轻流（流程自动化能力强）都是可考虑的方案。但如果是像我们这样的制造企业，对私有化部署、数据安全、复杂权限和多系统集成都有硬性要求，就需要选择企业级低代码平台。明道云的数据管理能力和织信的私有化部署方案也曾是我们的候选，但从整体架构的灵活性和AI能力结合的角度，JNPF的表现最符合我们的需求。这里没有”最好”，只有”是否匹配”——建议选型时把自身的场景清单列出来，一条条比对。

第三个建议：关注低代码平台的技术开放性，避免被厂商锁死。

一个常见的误区是只关注当前功能是否够用，忽略未来的扩展性。建议重点考察四点：一是是否支持OpenAPI，方便和现有系统集成；二是是否支持自定义代码扩展，为复杂场景留后门；三是数据所有权是否清晰，能否导出全部数据；四是是否支持主流云环境和信创环境。我们当时选择JNPF的另一个原因就是它提供了完整的API文档和自定义函数机制，我们的开发团队可以基于平台做二次开发，而不是只能使用平台提供的能力。

第四个建议：落地时从”让业务人员成功”的角度设计运营方案。

技术选型只是开始，真正的挑战在使用推广。这里有三个实操建议：其一，从业务痛点最集中、对IT服务抱怨最多的部门开始试点，快速跑出标杆案例；其二，挑选具备分享意愿和影响力的”业务种子用户”，而不是只按层级指定部门领导；其三，设置一个让业务人员低心理负担的”实验区”——比如内部测试环境里允许自由搭建，只有发布到生产环境才需要审批，这样能帮助业务人员在零压力下建立自信。我们的体会是，业务人员需要的是安全感，不是更多功能。当他们确认自己”怎么折腾都不会搞坏系统”时，创造力才会真正涌现。

第五个建议：持续观察AI能力迭代的方向。

这个赛道变化太快，现在的产品形态可能半年后就会有大改版。选型时建议关注厂商的AI研发路线图，了解他们对多模态交互、智能数据分析、自动化工作流等方向的规划。一个有持续研发投入的厂商，才能保证平台的AI能力不会停留在”演示级”，而是不断向”生产力级”进化。

九、结语：AI放大低代码价值，业务开发时代正在到来#

回看这一年多的实践，我越来越确信一个判断：AI不是低代码的锦上添花，而是低代码走向规模化普及的临门一脚。过去的低代码把”写代码”的门槛降低到了”拖拽配置”，而AI把”拖拽配置”进一步降低到了”说出来就行”。正是这一次门槛的跨越，让业务人员无需技术背景也能参与开发，让低代码的价值从IT团队的外溢扩展为全员的普惠。

对于企业技术决策者来说，AI低代码值得纳入战略视野，但也要保持理性预期。它能帮你解决大量长尾需求、缩短交付周期、释放开发资源，但它不是万能药。它不能替代核心业务系统的深度定制，不能替代复杂数据架构的规划，更不能替代一支专业开发团队。正确的姿态是把AI低代码当作”数字化的杠杆”：业务人员用这个杠杆撬动日常工作中的小痛点，专业开发者用这个杠杆放大自己的技术产出，企业管理层用这个杠杆让数字化转型的速度跟上市场变化。

在未来的企业里，“业务人员也能做开发”将不再是一个新鲜事，而会成为一种默认能力。AI、低代码、业务人员、价值放大、开发——这几个词的组合，正在成为这个时代企业数字化转型中最值得关注的变量。当AI让低代码的门槛低到业务人员愿意尝试，当低代码让AI的能力落地为具体的业务价值，那些率先在这一波浪潮中找到节奏的企业，将在效率与创新上建立起真实可感的竞争优势。

参考文献

[1] 艾瑞咨询. 2025年中国低代码市场研究报告[R]. 上海: 艾瑞咨询, 2025.

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

[3] 中国电子技术标准化研究院. 低代码开发平台能力要求[S]. 北京: 中国电子技术标准化研究院, 2023.

[4] 张睿. 大语言模型驱动的低代码开发平台设计与实践[J]. 软件学报, 2025, 36(2): 1-17.

[5] Forrester Research. The State Of Low-Code Platforms In The Age Of AI[R]. Cambridge: Forrester Research, Inc., 2025.