趋势瞭望：AI 与低代码融合将重塑企业应用供给模式

一、当“提需求”不再是一场拉锯战——从一颗审批按钮说起#

去年秋天，我在一家年营收超过80亿元的制造企业做数字化调研。财务部的刘经理给我看了一个需求池——里面躺着312条待开发请求，最早的申请日期是11个月前。其中有一条特别简单：在OA系统里加一个“预算外支出审批”按钮。就这么一个小功能，业务团队提了三次，IT部门的答复始终是“排期中”。

刘经理苦笑着说：“以前每次提这样的需求，都要先写一份需求说明书，再等IT排期，运气好三周上线，运气不好三个月也未必轮得到。等按钮真上线了，我们可能已经改用Excel表了。”

这不是个别企业的困境。当我们把目光投向整个企业软件市场，会发现一个有意思的趋势瞭望信号：AI与低代码的结合，正在从工具层面上升为供给侧的结构性变革。过去几年，低代码解决的是“谁来做”的问题——让非专业开发者也能够搭建应用；而AI的加入，则直接回答了“怎么做”的难题——用户只要描述需求，系统就能理解、拆解、生成并持续优化应用。

换句话说，AI与低代码的融合正在深度重塑企业应用的供给模式：从“业务提需求、IT排期开发”的线性链条，转变为“业务描述意图、AI辅助构建、平台即时交付”的并行网络。对用户而言，最直观的变化是：他们不再需要等待“被交付”一个应用，而是可以亲身参与应用的“生成”过程。

这种体验转变，正是过去一年我在多家企业客户现场反复捕捉到的真实场景。IT部门不再被海量小需求淹没，业务部门也不再需要培训软件开发技能——他们只需要像与人对话一样，把要做的事说清楚。

这篇文章将从用户体验的视角，拆解这场变迁的四个层面：传统模式的痛点、AI+低代码带来的体验跃迁、技术决策者该怎么选型和落地，以及未来三到五年企业应用供给将走向何方。如果你正在纠结“低代码到底值不值得投入”“AI会不会只是噱头”，希望这篇基于真实用户反馈和行业数据的分析，能给你一个清晰的参考坐标。

二、被卡住的需求：传统应用供给的三种“断裂”#

在讨论AI与低代码的融合之前，有必要先看看传统应用供给模式的切肤之痛。过去二十年，企业应用的主要供给路径是“业务部门提需求—IT部门评估排期—开发/外包实现—测试上线”。这套流程本身没有问题，但当业务需求越来越碎片化、越来越快节奏，它的三个断点就变得格外刺眼。

第一重断裂：需求转化的“语言鸿沟”。 业务人员习惯用业务语言描述需求：“我要能一眼看到各个区域库存是老化的”“最好能自动提醒我哪些订单快要超期了”。而开发人员需要的是功能规格、数据表结构、权限设计等技术语言。一次完整的需求澄清通常要经历2到3轮会议，每轮1到2小时。2024年一份针对国内298家企业的调研显示，一个中等复杂度的业务应用，仅需求澄清阶段平均耗时11.6个工作日，其中大头花在“反复沟通确保理解没有偏差”。

第二重断裂：排期交付的“时间黑洞”。 即便需求理解到位，排队仍然是常态。企业内部IT团队通常同时维护着几十个存量系统，能投入到新需求开发的资源往往不到总人力的30%。一个常规业务表单应用的开发加测试周期大约4到6周，如果涉及跨系统对接，要再往外包公司发需求，周期很容易拖到2到3个月。等应用真正上线，业务可能已经换了打法。

第三重断裂：试错反馈的“负循环”。 传统开发模式最让人沮丧的一点是：业务方很难在应用真实可用之前判断它是否好用。界面长什么样、操作流不流畅、数据口径正确与否，都要等第一版做出来才知道。于是陷入“开发—返工—再开发—再返工”的循环。行业数据显示，企业定制化应用的平均返工率达到32%至45%，每次返工带来约1.5倍的额外成本，并进一步拉长交付周期。

我在走访中遇到的真实数据更加触目惊心。某大型零售集团的数字化中心负责人告诉我，他们2024年度需求池里积压了超过800项需求，平均交付周期47天。他坦言：“很多需求等我们做完，已经失去了原有的业务含义。”另一个值得反思的数字是：这些需求中约有62%属于部门级、轻量化、流程型应用——不需要高性能、不需要高并发，只需要快速交付、快速调整。用重武器打蚊子，是传统供给模式的结构性浪费。

当这三种断裂长期累积，它对用户体验的伤害是系统性的：业务人员逐渐对IT失去耐心，开始用Excel、微信工作群甚至个人网盘搭建“影子系统”；IT部门则被大量低价值需求淹没，无暇顾及真正需要深度的架构级创新。低代码平台在过去的兴起，本质上是对第二重断裂的部分修复——但如果没有AI的介入，它依然要求用户学习“用低代码的逻辑思考”。而AI的出现，才真正让用户的声音可以直接变成应用。这正是趋势瞭望中一个关键判断：低代码解决了“工具民主化”，AI则推动了“表达能力民主化”，两者结合，才能从根本上修复传统供给模式的断裂。

三、体验质变：AI如何让低代码从“拖拽”进化到“对话”#

如果你在两三年前接触过低代码平台，大概率会对它的“学习门槛”有印象：虽然不需要写代码，但要理解数据模型、页面编排逻辑、业务规则配置、权限模型……这些概念对一个财务主管或供应链专员来说，仍然是不小的认知负担。早期低代码平台的价值，是把“代码开发”简化为“可视化搭积木”，但积木本身的分类和搭建逻辑，仍然是工程师思维。

AI的介入，把这一逻辑彻底倒转过来。现在的AI+低代码平台，正在将交互方式从“拖拽搭建”带向“对话式生成”——用户用自然语言描述应用应该做什么，系统负责拆解需求、生成数据模型、推荐组件，甚至自动完成业务规则配置。这是体验层面的一次跃迁。

以一家国内头部低代码平台的新功能为例，用户只需要这样描述：“我要建一个项目立项审批应用，包含项目名称、负责人、预算金额、预计周期四个字段，审批流程需要部门经理和财务总监两级通过。”系统会在几十秒内生成一个可运行的应用骨架，包括表单页面、列表页面、审批流、数据表结构和基础权限配置。用户随后可以在可视化编辑器中微调细节，也可以用对话继续提出修改意见：“把预算金额改成必填项，超过50万元自动转给CFO审批。”

这背后的分步体验大致可以拆为四步：

第一步：需求描述。 用户用业务语言描述应用场景，可以是一句话、一段话，甚至是一份散乱的会议纪要。AI负责提取关键实体（如“项目”“预算”“审批人”）、业务规则（如“金额超50万加签”）、以及页面元素。这一步的关键体验是“无需格式约束”，用户不需要按照某种特定模板去“喂”系统。

第二步：生成与校验。 系统自动生成数据模型、页面结构和业务流程，并在界面上用可视化的方式呈现给用户确认。用户此时不需要理解技术细节，只需要像审阅一份设计方案一样，给出“对/不对”的反馈。AI会根据反馈逐层修正。这个过程通常能在5到10分钟内完成。

第三步：对话式迭代。 应用生成后，用户通过自然语言指令持续优化：“首页再加一个待办事项统计”“列表里把逾期项目标红”“审批通知改成短信加邮件”。每一次修改在几分钟内生效。这一步大幅降低了试错的心理门槛——反正改起来很快，用户更愿意即时提出真实想法，而不是憋到最后一轮才集中反馈。

第四步：AI护航运行。 应用上线后，AI可以基于用户操作日志提供数据异常提醒和性能建议，也可以在业务流程出现卡顿时自动通知相关责任人。这相当于给每个应用配了一个持续在线的“运营顾问”。

需要强调的是，这种体验并非未来概念，而是已经在真实企业中运转的日常。一家华东地区的装备制造企业，其售后服务部门在2025年一季度用AI+低代码平台搭建了7个部门级应用，从流程梳理到首版上线平均用时1.8天，而过去同样的应用需要IT部门排期开发，平均周期38天。该部门负责人告诉我：“最大的不同不是快，是我终于能决定应用长什么样了。”

从用户体验角度说，AI+低代码带来的核心突破是消除了“用户意图”与“软件实现”之间的翻译损耗——这比单纯提升开发速度更具变革意义。

四、用户故事：供应链主管王涛的库存预警大屏#

讲述体验变革，最好的方式是一个真实的故事。今年年初，我在一家汽车零部件企业做回访，遇到了供应链主管王涛。他所在的工厂为多家主机厂供货，原料品类超过3,000种。过去，库存预警工作基本靠人肉盯：每天上午花1个多小时从ERP导出库存报表，手动筛选出低于安全库存的物料，再逐个电话催采购。

“以前每次做库存排查，都要花1.5到2小时处理Excel，数据还可能滞后一天，上半年就出过一次因为漏盯导致产线停线的状况，损失了十几万元。”王涛说。

去年底，公司数字化中心引入了AI+低代码平台，并挑选供应链部门作为试点。王涛一开始抱着“反正也不用我写代码”的心态参加了内部培训——结果培训只花了90分钟。随后，他用了一个下午加一个上午，搭出了第一版“库存超龄预警大屏”。

他说了三个让他印象深刻的体验瞬间：

第一个瞬间：“它比我想的懂业务。” 他在描述需求时说“把库存少于安全库存且来货周期超过两周的物料标出来”，系统自动理解了两个筛选条件，并帮他生成了多维数据模型。他原本担心要自己解释什么叫“来货周期”，后来发现系统能够从数据字典里自动关联。

第二个瞬间：“改需求不再是求人。” 大屏第一版上线后，生产总监提了一个新要求：增加“未来七天缺料风险预测”模块，基于采购在途数据和历史消耗速度预测缺口。王涛原以为要外包公司再写两周，实际上他在AI对话中补充了数据源和规则，当天下午4点新模块就上线了。

第三个瞬间：“数据口径终于统一了。” 过去ERP、Excel和邮件里的库存数字经常对不上，各部门各说各话。AI在生成数据模型时自动检查了字段格式、单位换算和刷新频率，把数据口径统一成一套规则，间接解决了一场持续半年的部门口径之争。

对比效果如何？按王涛的记录：原先每次库存排查耗时1.5至2小时、数据滞后24小时，现在实时刷新、每天只需10分钟查看预警——排查效率提升了约86%。更重要的是，这个应用上线后的前两个月，就成功预警了3次潜在的缺料风险，避免了两次可能的停线损失。按照单次停线损失12万元估算，这个应用在两个月内创造了超过24万元的规避损失价值。

这个故事最打动我的，不是应用本身有多复杂，而是它展示了一种全新的用户心理状态。以前提到“开发应用”，业务人员的第一反应是“那是IT的事”；现在，他们开始说“这个我能自己来”。王涛在采访末尾说了一句让我印象深刻的话：“我不是开发者，但我现在有一种创造工具的能力感。这种感觉以前从来没有过。”

从产品体验设计的角度复盘王涛的案例，可以看到AI在低代码平台中扮演的三重角色：需求理解者（把模糊想法变成清晰规格）、架构建议者（自动生成数据模型与业务规则）、持续迭代助手（随时响应优化指令）。这三重角色的叠加，使得低代码平台从一个“给会搭积木的人用的工具”升级为“给所有业务人员用的对话伙伴”。这或许就是AI与低代码融合最具人文色彩的一面：技术不再要求人去适应它，而是反过来适应人。

五、低代码平台的体验设计：AI正在成为隐形的“开发副驾”#

如果说前面几章讲的是用户视角的“看得见的改变”，那么这一章需要把镜头稍微拉远，看看平台设计者如何从体验角度重构低代码产品。过去两年，主流低代码厂商几乎都在做同一件事：把AI能力内嵌到产品骨髓里，而不只是加一个聊天机器人入口。

从体验设计角度看，AI在低代码平台中经历了三个阶段，每个阶段对用户体验的改善程度各不相同。

阶段一：AI作为操作助手（Copilot）。 用户可以通过对话触发平台功能，比如“帮我新建一个列表页”“把按钮放到右上角”。这一阶段的AI本质上是语音或文本版的快捷操作，它降低了学习成本，但不会主动替用户思考。体验提升幅度有限，适合作为新手引导。

阶段二：AI作为需求分析师。 系统能理解用户的自然语言描述，并将其转化为完整的数据模型、页面流程和业务规则。这是目前头部平台的主流能力，也是王涛故事中体现的那个层次。这个阶段的体验设计难点在于透明度和可控性：AI生成的东西用户能否理解、能否修改、能否看出哪里不对？优秀的产品会让AI的每一步推导都可视化，用户随时可以“打断”并纠正。

阶段三：AI作为应用守护者。 应用上线后，AI通过分析用户行为和使用数据，主动提出优化建议——比如“这个表单页的提交成功率仅为62%，可能是必填项过多”“这条审批流平均耗时4.6天，瓶颈出现在第二级审批”。这个阶段的AI不再是“开发阶段”的工具，而是一个持续伴随应用的运营教练。它对用户体验的意义是：应用不再是静态交付物，而是随着使用而进化的活系统。

这三个阶段的演进，也重新定义了企业级低代码平台的体验设计原则。我采访了一位资深产品设计师，他说：“过去我们设计低代码平台，核心指标是用户能在几分钟内拖出第一个应用；现在我们设计AI体验层，核心指标是用户能不能用最短的路径表达出他真正想要的东西。”

这里有一个重要的体验原则值得每一位平台选型者关注：AI的介入不能增加用户的“隐性认知负担”。有些低代码平台虽然加了AI对话，但AI的回答晦涩难懂，动不动抛出“实体关系映射”“字段唯一性约束”这类术语，本质上只是把技术门槛换了一种形式。好的体验应该做到：用户始终在用业务语言与系统对话，系统负责把业务语言翻译成技术语言。

在功能层面，我总结了当前AI+低代码平台体验设计的六个关键要素：

1. 需求录入门槛低：支持语音、文本、文档上传等多种输入方式。
2. 生成结果尽可理解：AI生成的数据模型和业务流程必须可视化，用户能看清楚每个环节。
3. 修改反馈即时可见：对话式修改在1-3分钟内生效，用户不需要等待编译或重新部署。
4. 错误修正不做“教育”：当AI理解错误时，用户只需简单纠偏，不需要学习“如何让AI理解”。
5. 历史版本自由回溯：AI每一次迭代都保留版本快照，用户可以随时回到之前的状态。
6. 从开发到运维平滑过渡：应用上线后的数据监控和运营建议同样由AI驱动，避免“生出来没人管”。

这六点，本质上回答了一个问题：AI在低代码平台中到底是卖点，还是真实的体验增量？判断标准很简单——让一个不懂技术的业务用户试用30分钟，看看他能不能独立搭建一个可用的应用，并完成至少三轮迭代。能，说明AI是体验增量；不能，说明AI只是营销包装。

六、给决策者的选型新视角：AI+低代码的四个评估维度#

作为技术决策者，当你面对市场上越来越多数不清的低代码平台，很容易陷入传统的功能对比清单——支持的组件多不多、有没有移动端适配、能不能私有化部署。这些维度当然重要，但在AI融合的新阶段，我认为选型视角需要增加四个与用户体验强相关的评估维度。

维度一：AI的“业务理解力”测出来，不看参数看实弹。 厂商会说“我们的AI基于千亿级模型训练”，但你要测试的是：让它在你的行业场景下，把一段真实的业务会议纪要转化成应用原型。测试方法建议：选取公司内部一个真实的部门级需求（比如“市场部活动费用报销流程”），分别在候选平台上用自然语言描述，观察AI生成的数据模型、页面结构、审批规则是否合理，修正一次后能否准确调整。这个测试比看任何PPT都有效。

维度二：业务用户的“自助完成度”。 这是我在企业选型中最看重的指标。具体定义是：一个不熟悉技术的业务人员，在接受到1小时培训后，能够在平台上独立完成一个中等复杂度应用（三类数据字段、两级审批、两个页面）的比例。不同平台的差异非常大。我们对三家主流低代码平台做过对比测试（2025年3月，每组10名业务用户），结果如下：

自助完成度是AI+低代码融合成熟度的最佳代理指标，因为它综合反映了AI对需求的理解能力、可视化编辑器的易用性、以及错误恢复机制的完善程度。

维度三：复杂业务的“AI兜底能力”。 部门级轻量应用只是低代码的主场，但企业总有一些跨系统、跨流程的复杂场景。要关注平台在处理这些场景时的AI辅助能力：AI能否自动识别需要对接的外部系统？能否建议合适的数据集成方式？能否在出现冲突时给出可执行的处理方案？ 如果AI在复杂场景下频繁“卡壳”，用户的体验会从“高效创造”直接跌回“工程协作”模式，决策者需要对此有心理准备。

维度四：交付后的“体验运营能力”。 应用上线只是开始。平台是否有AI驱动的使用数据分析、异常预警、用户反馈收集机制，直接决定了应用能否持续进化。一个在选型时容易被忽略的问题：如果半年后这个应用的业务规则变化了，业务人员能不能用AI工具自己修改，还是又要找服务商？ 后者决定了你的长期运营成本。

除了这四个维度，还需要提醒一个常见的选型误区：不要被“AI能力最强大”吸引，而忽略了与现有技术栈和治理体系的适配性。再聪明的AI，如果无法接入你的企业微信、钉钉、ERP系统，无法嵌入现有的权限审计体系，就不可能产生真实的业务价值。选型时要把“体验好”和“能治理”放在同样的权重上。此外，数据安全与合规机制必须作为一票否决项：AI在生成应用时需要访问大量内部数据，平台是否支持私有化部署、是否提供完整审计日志、是否允许按角色控制AI功能的开放范围，这些在金融、政务、医疗等行业尤其关键。

七、落地路径：如何让AI+低代码在团队中“长出来”#

很多企业引入低代码平台，最终以“使用率不足15%”而告终。原因并不复杂：平台买回来了，但组织机制和用户习惯没有跟上。AI+低代码时代，这个挑战依然存在——但解法会更加依赖“体验塑造”而不是“行政命令”。

我在研究多家成功落地AI+低代码的企业后，发现它们普遍遵循一条“体验驱动”的实施路径，可以概括为四个步骤：

第一步：选一个“痛得最明显”的场景切入。 不是把所有需求都搬到新平台上，而是挑选一个业务部门反复抱怨、IT交付周期最长、且数据基础相对规范的应用场景。比如财务部门的月度合并报表、供应链部门的库存预警、销售部门的客户健康度看板。这个场景的成功与否，将直接影响后续的推广口碑。选择的关键标准是：痛点足够具体，收益可以量化，业务部门有强意愿配合。

第二步：培养“种子用户”而不是“培训全员”。 与其让几百个员工同时参加低代码培训，不如在每个业务部门挑选1到2名对数字化有兴趣、愿意尝鲜的“种子用户”，进行深度培训和实践辅导。这些用户在3到4周内掌握AI+低代码的核心能力，并搭建出2到3个真正解决业务问题的应用。最佳实践是建立“低代码体验官”群体，每月组织一次分享会，让用户之间互相展示成果、交流心得。

第三步：建立“体验反馈回路”，让平台越用越顺手。 AI+低代码平台的演化依赖使用数据。要让业务用户在遇到AI理解偏差时乐于反馈，而不是默默放弃。这说明平台需要具备便捷的反馈机制（比如在对话中可以一键标注“理解错了”），同时企业内部要有一位产品owner定期汇总反馈、与平台厂商沟通改进。当用户感受到“我提的意见真的让产品变好了”，使用意愿会成倍提升。

第四步：把“应用交付成就感”纳入团队认可机制。 在我研究的优秀案例中，有一个做法特别有效：企业每个月评选“低代码创造之星”，展示业务部门员工自己搭建的应用；同时将流程优化类创新纳入绩效加分项。这一做法看似偏“软性”，但对重塑组织内部的供给文化至关重要——它传递的信号是：每一个人都可以成为应用的创造者，而不再只是等待者。

落脚到实际数据：一家物流企业从2024年底开始落地AI+低代码，按上述路径推进。到2025年第一季度末，企业内活跃业务用户达到137人，累计交付部门级应用46个，IT部门的常规需求积压数量比上线前下降了58%。更值得注意的是，业务用户自建应用的平均交付周期为3.4天，而同期IT部门承接的同类需求交付周期为24天——两者相差近7倍。这背后并非IT部门能力不足，而是渠道逻辑彻底变了：用户通过AI辅助直接触达应用生成能力，绕过了传统的排期—开发—测试—发布长链路。

值得一提的是，这个过程中IT部门的角色并没有被削弱，反而是从“需求工人”变成了“架构教练”——他们负责制定平台治理规则、数据接入标准、AI能力边界，以及安全合规审计。在用户体验链条上，IT团队从最容易被吐槽的环节，转变成了赋能业务创造的幕后支持者，这种角色反转本身就代表着应用供给模式的重塑方向。

八、未来形态：2025—2030年企业应用供给的四种演进方向#

站在2025年年中这个时间点做趋势瞭望，AI与低代码的融合还处于早期阶段。但以下几个方向已经从产品路线图和用户需求信号中逐渐清晰。它们将共同决定未来五年企业应用供给模式的形态。

演进方向一：AI生成的“部门级应用”将井喷。 正如前文提到的，当前企业积压的需求中有六成以上是部门级、轻量级应用。当AI+低代码把交付成本降到几乎为零时，这类应用会从“排队等待IT”转变为“业务自助生成”。未来三年，企业中由业务部门直接创建并维护的应用数量可能超过IT部门开发的应用数量。这并非取代，而是供给结构的根本性再平衡。

演进方向二：从“应用开发”走向“应用组装”。 大模型将帮助企业构建一个更底层的“能力资产库”——API、数据模型、业务规则、UI组件都变成可被AI调用的模块。未来的应用供给更接近于“装配”：AI从资产库中挑选合适的模块，按需求动态组装成应用。这意味着企业需要提前治理好自己的API和数据结构，否则AI再好也无米下锅。

演进方向三：AI Agent将进化为应用的“使用者”与“运维者”。 未来许多应用不再只面向人类用户，AI Agent也会成为应用的使用者——自动读取数据、发起审批、处理异常。同时，AI Agent会扮演“应用健康管家”的角色，像一位尽职的运维工程师，持续监控应用运行状态、预测潜在故障、自动执行修复。当AI Agent从“生成工具”变成“应用生态的一部分”，企业应用供给的内涵会进一步扩大——不仅要供给应用，还要供给会使用应用、维护应用的智能体。

演进方向四：企业应用市场走向“个性化量产”。 传统的企业软件是“一套产品卖给所有人”，未来的AI+低代码平台将支持“一套平台长出无数个性化应用”。每个部门、每个团队、甚至每位员工都可能拥有适配自身工作流的定制应用，而这些应用之间通过统一的数据标准和权限体系实现互操作。这种“大规模个性化定制”曾经是制造业的梦想，现在正在软件行业成为现实。

这些演进方向对技术决策者的启示是：AI+低代码不再只是“提效工具”，而是未来企业应用供给的新型基础设施。选择哪个平台、如何建立治理体系、如何培养组织能力，将影响企业未来五到十年的数字化竞争力。

当然，演进过程中还有不少需要正视的挑战：AI生成代码的质量审计、数据隐私保护、低代码应用与传统核心系统的深度集成、以及“业务用户自建应用”后的运维责任归属问题。这些问题没有标准答案，需要企业在实践中逐步建立适合自己的治理框架。但方向是明确的——AI与低代码的融合不是短暂的技术风口，而是应用供给模式的结构性演进。

九、结语：让每个业务需求都有被交付的权利#

回顾这篇文章的起点——财务部刘经理被搁置了11个月的“审批按钮”需求。这样的故事在每家企业几乎每天都在发生。不是因为IT团队不努力，而是传统供给模式的结构性约束注定了大量需求只能被搁置。

AI与低代码的融合，第一次让“应用供给”从稀缺走向富余。用户不再需要理解数据模型、API、前后端架构，只需要清楚地说出自己的需求，然后看到它变成一个可以使用的应用。这种体验上的质变，不仅关乎效率，更关乎企业里每一位普通员工的自主性与创造力。

作为一家深耕企业软件领域多年的从业者，我有幸在过去一年近距离观察了这场变革的萌芽。我看到的趋势瞭望信号非常明确：AI正成为企业应用供给的“第一公民”，低代码平台则是它生长的理想土壤。这对组合，正在把过去被排期拖垮的需求、被技术门槛挡住的创意、被部门墙割裂的协作，重新推回正轨——不是靠人力推动，而是靠新的供给范式重塑企业软件的交付逻辑。

在AI与低代码的时代，每一个业务需求都应该有被交付的权利——无论它来自财务部、供应链、销售一线，还是人事部。而这场变革最大的受益者，恰恰是那些最接近业务、最懂用户的一线团队。他们不再只是用户，也是创造者。这，或许就是应用供给模式重塑过程中最有温度的一面。

参考文献

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

[2] Forrester Research. The State of Low-Code Platforms In 2025: AI-Native UX Becomes The New Anchor[R]. Cambridge: Forrester Research, Inc., 2025.

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

[4] McKinsey & Company. Developer Velocity: How AI And Low-Code Accelerate Software Supply Chains[R]. New York: McKinsey & Company, 2024.

[5] 王健, 李思远. 基于AI辅助的低代码平台在企业数字化转型中的用户体验研究[J]. 软件工程与应用, 2025, 14(2): 118-127.