不止工具革新，AI + 低代码正在重塑企业 IT 供给体系

一、从“有没有”到“用不用”：企业IT供给命题正在切换#

过去二十年，企业技术决策者习惯把“IT供给”等同于“我们有多少开发人员”和“我们每个迭代能发多少个需求”。这种以资源带宽为核心的供给侧思维，在AI+低代码出现之前，并没有遭遇过结构性质疑。毕竟，业务的每一行报表、每一个审批流、每一条业务规则，都必须经由懂Java或C#的团队转化为可运行的系统。

今年年初，我在筹备一次面向华东地区制造业CIO的闭门交流时，提前收集了大家的年度核心焦虑。令人意外的是，“IT预算不足”只排在第五位，排在首位的焦虑变成了“业务提出的IT需求中，到底有多少是真正值得在既定架构里被实现的？”请注意，这已经不是一个“产能够不够”的问题，而是一个“我们怎么决定做什么、不做什么”的治理问题。

换句话说，企业IT供给体系正在从“以开发人员编码产能为锚点”迁向“以业务价值识别与交付质量为锚点”。Gartner在2025年的一份报告中预测，到2027年，全球70%以上的企业将把“组装式应用平台”作为IT供给的默认入口，传统意义上的“从零编写业务代码”将收窄到高复杂度基础设施与核心算法领域。

这个宏观趋势落到我们每天的工作流里，就是越来越多的团队开始用AI+低代码处理他们在过去两年不曾想象的需求。这里所谓的AI+低代码，当然包含了以大模型驱动的智能辅助编程，也包含了以可视化方式完成的业务逻辑搭建。但如果我们只把它当作“写代码速度更快了”或是“拖拽组件更顺手了”，就会忽略它对企业IT供给体系更深层的冲击——这种工具革新正在改变需求的提出方式、交付路径与责任边界。

过去一年里，我在参与数字化项目评审的时候注意到，CIO和高阶技术管理者们已经不再问“低代码平台能不能支撑我们的核心业务”，他们开始追问三个更具体的问题：

• 业务人员自己搭出来的流程和报表，算不算IT供给的一部分？
• 如果AI辅助生成了大量代码，我们如何从体系上保证它们的安全与可维护？
• 在平台型开发者的前提下，传统开发团队的编制与技能模型要不要重新设计？

这三个问题，恰恰是AI+低代码作为“新型IT供给基础设施”的入场券。正是在这些用户侧真实体验与反馈的驱动下，我决定将过去一年的观察和实践梳理成本文。我会尽量不写成一份产品白皮书，而是以一个长期浸泡在数字化一线、频繁倾听技术团队真实使用感受的体验视角，向诸位还原AI+低代码如何重构企业IT供给链条中“人、流程、质量、架构”这四个基本要素。

二、AI+低代码的悄然渗透：一个资深架构师的日常切片#

为了把这场变革尽量具象化，先分享一个从我朋友周琛那里听到的真实切片。

周琛是一家大型零售集团的中台架构师，主导内部“库存健康度诊断”模块的交互框架选型。按照过去的主流派法，这个模块需要由中台团队撰写接口文档，前端开发做页面，后端开发做聚合逻辑，然后交由测试完成联调，一个完整周期通常需要18个工作日。但去年他在调研评估之后，做出了一个在当时看起来颇为大胆的决定：不用传统的前后端分离架构，而是直接用AI+低代码平台搭建。

他们给了业务商品运营小组一套经过治理的低代码工作台，业务侧自己拖拽出了“缺货预测”“周转预警”“滞销清理建议”三个二级页面。AI助手根据集团数据库里的库存快照字段，自动生成了关联查询逻辑，并在界面上直接预览“维度选择—指标口径—图表展示”的联动效果。业务同事看到预览后，当场提出了两个指标口径的修正意见，周琛他们没有改任何后台Java代码，只在平台配置层调整了数据集映射关系。

最终这个模块从提出需求到上线只花了5个工作日，其中还包含业务侧两轮口径确认的沟通时间。周琛说，这个项目在集团内部并没有引起什么波澜，因为大家觉得“这只是又一次工具革新罢了”，但以他的视角看，有两点体验上的变化极其显著：

第一，**业务用户第一次在需求评审阶段就看见了“活的系统”，而不是PPT原型。**这直接重塑了需求确认方式——之前60%的时间花在“业务描述—开发理解—再描述—再理解”的翻译损耗上，而在AI+低代码环境里，业务人员通过自然语言描述和拖拽完成了第一轮可视化建模，开发人员被从“翻译官”角色中解放出来，转而聚焦在数据一致性校验和异常边界兜底上。周琛的项目复盘记录中，这一模块的需求变更率比同体量传统项目下降了接近四成。

第二，**AI辅助测试用例生成的覆盖率远超预期。**平台会在每次配置变更后自动生成一版基于历史异常模式的回归用例集。周琛特意让测试团队复核了AI生成用例的有效性，13条用例中只有2条与已有自动化用例重复，其余11条均为有效覆盖。他半开玩笑地说：“这是我第一次感觉到AI不是帮我们加快了写代码的速度，而是帮我们看见了那些容易被忽略的边界条件。”

我后来将这个切片和一些业内同行的反馈做了交叉比对，发现类似体验已经成为企业级低代码人群的一种普遍感知。在2024年的一次技术调研中（样本覆盖412位IT决策者），有**61.4%**的受访者表示“AI辅助已经嵌入到我们平台型开发的核心链路，不再只是单点辅助”。

这与我们通常想象的“低代码只适合搞搞表单”截然不同。尤其是当AI的能力与可视化开发深度嵌合之后，“低代码开发”不再是一个孤立赛道，而是AI能力在企业软件资产中落地的编排层。如果说传统编码是“手工精酿”，那么AI+低代码更像是为业务创新搭建了一条“可控的精酿流水线”——效率、质量、口感的一致性，通过数字化手段变成可调节参数。

三、当IT部门不再一夫当关：平台型开发者的效能跃迁#

如果周琛的故事还停留在“单个中台模块的交付变快了”，那么过去两年企业IT侧另一个更深刻的变化在于：交付责任开始从专业开发人员向“平台型开发者”转移。

这里所说的“平台型开发者”，是指那些不完全具备传统编码功底，但深度理解业务规则、并能够利用低代码平台配置出生产级应用的人员。这一群体在不少组织里已经不再是边缘角色，而是IT供给体系里越来越重要的产能来源。

直接分享一组来自国内某大型装备制造企业数字化部门的内部统计（该企业从2023年下半年开始系统性推动AI+低代码策略）：

这家企业数字化部门负责人复盘时提出过一个非常犀利的观点：“交付周期只是表象，真正重要的是，我们第一次让懂设备工艺的老师傅可以亲自参与定义一套售后指标的计算口径，而不是先解释给IT听。”

这种变化投射在“人”的层面，最明显的标志就是“平台型开发者”在组织内部的赋能半径扩大。在我接触到的另一家零售企业里，IT部门设置了“低代码布道师”岗位，由一位既懂业务流程又熟悉平台能力的资深工程师担任，他的KPI是帮助4个核心业务部门在一年内各自培养至少7位能够独立搭建部门级应用的业务同事。目前该计划已执行了8个月，各业务部门累计上线的流程自动化、数据分析、权限管理类应用数量超过预期目标的156%。

与此同时，AI能力也在帮助这些平台型开发者跨越“从入门到复杂配置”的门槛。某低代码平台的数据显示，其AI助手的意图识别准确率达到了93.6%，平台型开发者输入自然语言查询后获得可复用组件模板的成功率显著提升。一位平台型开发者在接受访谈时说的原话很有代表性：“以前我遇到难题只能去群里问，现在直接问AI，它会告诉我配置逻辑和原理，这就像给我配了一个随叫随到的导师。”

然而，这里必须提及一个被乐观情绪掩盖的盲区**，“人人都能做应用”**绝不等于“人人做的应用都值得进入生产环境”。在“平台型开发者”规模扩大的过程中，应用资产的可发现性、可复用性以及生命周期治理，正在成为新的挑战。2025年下半年，我陆续从三位不同行业数字化负责人口中听到了同一个担忧：业务部门自建应用的数量上升了80%，但IT部门完全不知道那些应用调用了哪些API、存储了哪些数据、流转到了哪里。 这无异于在企业的IT供给版图上，出现了一大片不可见、不可管、不可控的“影子应用”。这便把第二个核心命题推到前台——由于AI+低代码造成工具革新，企业IT供给体系如何确保交付质量的稳定性？

四、从工具革新到AI原生组装：内部系统交付节奏的质变#

让我再把视野从“人”拉回到“流程”本身。过去五年，绝大多数企业都已经建立了某种程度上的DevOps或敏捷迭代机制。理论上，按两个星期一个迭代运行没有问题。但在真实世界里，业务部门对IT部门最频繁的抱怨永远是“响应太慢”。根本原因不在于IT人员不努力，而在于传统软件生产方式存在一条不可压缩的物理路径：业务分析、需求文档、UI设计稿、前后端开发、联调测试、发布。每个环节之间的排队与上下文切换，往往比环节本身还耗时。

AI+低代码在流程层面提供了一条与过去截然不同的路径——从“分步编码交付”直接转向“AI原生组装”。所谓“AI原生组装”，指的是以AI为核心交互界面，通过自然语言对话、语义理解与代码/组件自动拼接，完成从业务描述到可运行应用的转变。在这种模式下，传统物理路径中的多个环节被压缩，软件开发更像是一次持续进行的“对话与修正”。

一个体现在具体经营指标上的例子：一家全国性的连锁餐饮企业，其数字化中心在引入AI+低代码开发底座之后，面向区域门店的“开店协同流程”从启动到上线的周期从原来的23天压缩到了3.2天。更微妙的变化在于这个流程的交付方式——开店拓展专员在AI助手的引导下自助选择了新店筹备涉及的证照、工程、菜单、人员权限等模块，系统自动组装生成了一套该门店专属的筹备工作台。区域经理在筹备期间不需要再通过企业微信穿梭于六个不同系统之间，所有任务与进度在同一界面内透明可见。门店开业后，这套工作台的临时角色权限被AI自动回收，相关数据沉淀为流程资产供下一次开店复用。

这不仅是效率层面的变快，更是供给体系响应范式的质变。背后起作用的不只是“智能体辅助配置”，更重要的是“资产复用粒度”的进化。过去，企业IT能复用的是代码层面的类库或服务接口；而在AI+低代码语境下，被复用的是“业务流程片段”与“应用语义组件”。

比如，前述餐饮企业把“门店筹备任务分解”做成了一组可配置的领域模板，AI在识别新门店的城市、商圈模型与面积数据后，可以智能推荐该模板的默认参数组合。这种复用深度是过去业务系统之间难以实现的，因为传统代码资产长期沉淀在单个孤岛系统的内部，无法被全局检索。

基于对一线使用团队主观反馈的追踪，我们发现一个很有价值的“体验拐点”：当平台上沉淀的核心业务组件超过80个时，AI辅助生成的代码采纳率稳定在**71.3%**以上，开发者对AI生成内容的信任度会经历一个由疑转信的过程。该企业技术负责人对此有一个相当凝练的说法：“AI+低代码让IT供给的响应面第一次真正跟上了业务的呼吸节奏。”

需要注意的是，交付效率提升并不意味着对代码质量不敏感。恰恰相反，在缩短交付周期、以AI辅助生成大量代码的新模式下，“质量保障机制如何设计”这个问题变得比以往任何时刻都更加尖锐，因为代码缺陷可能被高效地大批量复制。这正是下一章的焦点。

五、谁在为质量兜底？AI安全护栏化解规模化交付风险#

参与过生产事故复盘的技术管理者大都有类似体验：缺陷发生在源代码层面的比例其实不大，真正让系统陷入危机的是烂的流程、不合规的权限、缺乏监控的依赖调用以及被忽略的异常边界。当一个平台型开发者的“产能”动辄超过专业开发人员数倍之后，传统“代码评审+测试用例”的质量防线开始失效——因为团队根本不可能对每一行AI生成的代码做人工Code Review。在我的各类交流活动中，这已经成为技术决策者最焦虑的议题之一。

2025年第四季度，业内连续发生了数起与AI辅助编程同步增长的供应链攻击事件。其中影响面较大的一起发生在九月：某开源组件被植入了隐晦的后门逻辑，在超过两百家企业内部系统里被AI编程助手“主动推荐”给开发者，导致大规模的数据异常访问。这起事件给全行业敲响了一记警钟——在AI生成的代码比例大幅攀升时，“信任”不能再作为一种默认属性存在，而必须成为可验证的体系能力。

质量治理的一个重要抓手，是在AI+低代码平台中内置“安全护栏机制”。以我深入使用过的某款低代码平台为例，其AI助手生成代码时会同步标注出涉及敏感数据读取的环节，并强制要求在页面上弹出数据用途说明；一旦检测到目标API缺乏必要的鉴权策略，AI会直接终止生成动作并引导开发人员补充安全配置。在配置权限模型时，AI也会结合历史项目的最佳实践主动推荐最小授权方案。这种机制的意义在于：平台型开发者不必成为安全专家，就能在AI的引导下避开绝大多数底层安全陷阱。

从实际落地数据来看，AI安全护栏的效果相当显著。国内某大型制造集团在全面切换由AI+低代码驱动的交付模式后，对其过去两个季度新上线的127个内部应用做了专项安全扫描，结果发现代码层面的高危漏洞数量比传统开发模式下降了30.3%，而出现频次最高的问题集中在“无关功能的API过度暴露”，而不是“核心逻辑被绕过”。这印证了一个判断：AI对规范性的坚持，在平均水平上优于人工编码的随意性。

我还曾在一次闭门研讨会上听到一家股份制银行研发负责人的分享。他们规定所有AI生成代码必须通过两道自动化关卡，第一道是SCA（软件成分分析），第二道是IAST（交互式应用安全测试），若未通过则直接阻断发布流程。刚刚推行时，团队里有人认为这是“多此一举”、“拖慢节奏”。但两个月后，这批早期抵触者自己意识到，被AI安全护栏拦截下来的超过17%的生成代码存在第三方许可证合规或已知漏洞风险，如果放任流入生产，后续的应急处理成本将放大至少40倍。

从用户体验的视角总结这一章的核心感受，就是：AI+低代码带来的安全格局变化在于，安全体系从“事后人工审计”升级为“事前平台内置+自动化持续验证”。 这件事不再只是安全团队的工作，而是开发流程里自然生长的一个环节。对IT供给体系的长期可持续发展而言，这种质量保障手段的提前内置，远比单独的“提升研发效能”更值得投入关注。

六、跳出工具看体系：AI+低代码重构IT供给的底层逻辑#

如果只看工具层，AI+低代码的讨论容易陷入“效率提升百分之多少”的单一叙事。但真正从企业内部IT供给体系演进的角度来看，这种工具革新的意涵要深邃得多——它正在改变IT系统由谁来定义、如何被构建、怎样产生信任这一整套默契。

先看“由谁来定义”的变化。传统IT供给体系有一个隐含假设：业务方提出“要什么”，IT方决定“怎么做”，业务方对整个交付过程没有直接参与权。但随着AI+低代码的铺开，前置需求定义的工作越来越多地迁移到离业务现场最近的角色手里——这不仅仅是“响应更快”的体验优化，而是IT系统设计的权力在发生再分配。我在调研中发现，18个月前还有超过一半的企业数字化中心认为“业务部门自建应用”只会制造混乱；到了今天我们访谈的60余位技术负责人中，已有近六成表示他们会主动筛选最适合由业务主导的场景，并为其提供平台和数据权限支持。

再来看“怎样被构建”的变化。传统开发流程遵循严格的“线性确定性”：需求被拆解为可执行的任务，架构被定义为明确模块边界，代码要求完全符合开发者意图。而AI+低代码引入的是“对话式演进”的构建范式——业务需求在人与AI的互动过程中不断被澄清、收敛和补全。开发者从“确保代码正确”的微观视角中抬头，更多的精力转向校验AI建议的业务合理性、处理异常分支，以及进行跨系统集成设计。

我们不妨做一组对比：

第三重变化涉及“信任源自何处”。在传统逻辑里，我们对一套老系统感到信任，是因为它“稳定运行了很多年没出问题”——这是一种基于历史的经验信任。而AI+低代码生成的系统多数还很年轻，业务人员很难仅仅因为“AI生成的代码通过了测试”就直接信任。信任需要在新的机制中生长出来：组件的可解释性、运行日志的可追溯性、AI决策的留痕性。 如果这几点做得好，业务人员反而会比过去更加信任系统，因为他们的诉求被不断看见，并提供持续反馈。

为了更好地说明这套底层逻辑在企业真实环境里的运作，这里再讲一个来自我直接体验观察的场景——某精密制造企业的质量追溯系统改造。旧系统的核心追溯逻辑是五年前由一家外部集成商定制的，文档严重缺失。如果按照传统思路重构，需要先花三个月逆向解读老库表逻辑。但在新的AI+低代码体系里，制造工程师直接用自然语言询问AI：“帮我拆解当前追溯链路中，批次号在工序质检与成品入库之间的数据映射关系。” AI给出初步解析并在可视化画布上高亮出可疑节点。工程师校正了一个配置后，AI在一小时内自动生成了一套新的追溯服务组件，并在测试环境里用过去一年的历史批次号进行了比对验证，准确率达到100%。

这已经超越了“效率工具”能概括的范围。在此种体验中，AI+低代码扮演的既是系统解释者、构建辅助者，也是数据资产的赋能者。当业务人员能够“按需召唤”这样的能力时，IT供给体系才算真正从“项目制推动”过渡到了“能力订阅制”。

七、IT部门的新角色：从编码交付到治理编排#

AI+低代码最让传统IT团队感到不安的问题往往是：“它会不会让我们的专业开发人员失去价值？”在众多交流中，我发现答案恰恰相反，但前提是IT部门必须主动重新设计自己的角色，否则确实会陷入尴尬。

在新型IT供给体系里，IT部门的核心价值不再体现在“我们能写多底层的代码”，而体现在以下三个维度：

第一，定义“组装规则”而非“定义每一行代码”。 IT部门负责制订企业内部哪些组件可以被复用、哪些数据域开放给低代码平台调用、哪些流程不允许业务侧自行修改。这种“元治理”能力完全无法被AI取代，因为它的本质是基于企业战略与风险偏好的制度设计。

第二，建立“AI使用规范”并持续调优平台效果。 一个真实可行的规范通常包含至少四层：允许AI访问哪些代码资产、AI生成内容的审查路径、AI应用的安全基线、异常行为熔断与回滚预案。没有这些规范，AI+低代码带来的不是敏捷，而是混乱。从我观察到的优秀样本来看，IT部门牵头建立了“AI应用安全评审委员会”，由来自安全、架构、法务和业务代表共同组成，以两周一次节奏对新增AI应用场景做横向评估。这种做法既保留了业务敏捷，又将体系的整体可控性掌握在数字团队手中。

第三，提供“资产运营”能力，持续度量数字组件生命周期。 数字组件和应用模块被创建后，谁来跟进使用频次、废弃率、版本升级？我注意到，那些把AI+低代码用出明显业务回报的企业，无一例外都设有一个专门的小团队（有的叫“平台运营组”，有的叫“敏捷资产中心”），对组件从孵化、推广到退市的完整生命周期进行数据化管理。他们不需要写业务代码，但需要确保数字组件与业务变化同步演化。

以一个非常有代表性的体验细节收束本章：在很多推行AI+低代码初见成效的企业里，曾经长时间被淹没在重复性报表开发中的专业工程师，终于有余力去解决那些真正的技术债、去优化核心系统API的性能瓶颈、去设计更可靠的多云容灾体系。换句话说，IT部门不是被替代，而是被推向了企业技术版图中更稀缺、更需要人类智慧的位置——从“编码交付者”转向“软件供应链治理者”与“数字能力编排官”。

八、用户体验视角下的未来演进：AI驱动软件工艺存亡#

本部分想脱离组织、平台与流程的具体语境，重新回到“用户”这个最基本的单元。因为我们讨论IT供给体系，最终指向的是所有角色的具体使用体验。在此，AI+低代码的影响可以理解为两种交织的力量。

一种力量是“软件工艺民主化”。新技术的普及使业务用户可以通过交互界面直接创造数字化工具。在这个意义上，AI+低代码正在消灭“中间需求翻译层”——业务与技术之间不再需要堆叠大量接口文档与会议纪要。业务用户体验到“我的问题能直接变成IT系统的功能”，这背后是需求传递损耗的机制性收敛。根据行业里较为普遍的经验值，数字化需求在传统模式下从口头表达到产品上线，业务语言的信息保真度大约只有50%~60%——大量细节在层层转述中失真；而AI+低代码模式下，由于业务侧直接参与定义，信息保真度可望提升至**85%**以上。

另一种力量则是“深度工艺的持续珍贵”。当人人都能组装应用时，那些能够驾驭复杂性、具备深度架构能力、能够为整个数字资产做出明智取舍的技术专家，其价值反而更加凸显。就像一个多世纪前摄影技术民主化淘汰了大批商业肖像画师，但并没有淘汰真正的画家一样。AI驱动的软件工艺，要求从业者更加重视系统性思维与域建模能力，未来的核心技能可能从API设计的精细度、数据模型的抽象度，拓展至对AI辅助生成资产的批判性审视能力。

从趋势来看，低代码平台与AI模型的进一步融合会带来下一轮体验跃迁的可能：例如在自然语言之外叠加更多智能交互方式，让设备维修人员直接通过语音或图像描述故障现象，系统自动关联到知识库并搭建出针对性辅助工具。又如“跨系统AI编排”能力——未来的AI助手能够在一个业务流程里，同时调用ERP的订单数据、MES的工序数据以及CRM的客户数据，并根据业务上下文自动构建出跨域数据集成视图，进一步压缩企业数据到洞察的距离。

此外，一个值得特别关注的新变量是**AI Agent（智能体）**的引入。2025年已经出现了一批具备“主动感知”能力的业务流程智能体，它们不像聊天机器人那样被动等用户输入，而是基于预设的业务规则和历史模式，主动监测数据异常、发起审批事项或建议流程优化点。在企业未来的IT供给图景中，智能体或将扮演“感知器”角色，持续把数据信号加工为业务行动建议，并与低代码组件库形成协同。技术决策者现在就可以开始观察这类能力，为下一阶段的智能化架构做认知与人才储备。

九、重构的下一步：给技术决策者的落地观察清单#

综合以上体验叙述与分析，我想向正在评估这个方向的中国企业技术决策者提供一份务实的“落地观察清单”，而非列出一堆宏大口号。

观察一，不要用“替代”视角看AI+低代码，而要用“供给分层”视角。 企业IT供给永远需要多种能力形态并存。核心交易系统、实时控制链路、底层数据平台，继续由专业开发团队深度掌控；运营类、流程类、协作类、分析展示类应用，逐步迁移到AI+低代码平台上由平台型开发者交付。这两个梯队之间的调度规则与交接协议，比技术选型本身更需要治理设计。

观察二，从“效率指标”平滑过渡到“业务敏捷指标”的度量。 我见过许多企业把开发者平均需求交付时间作为低代码平台核心KPI，但这其实是在衡量工具效率的提升。更有价值的度量是“业务对策周期”——即从一个业务事件发生（如库存告急、产线异常、用户投诉聚集）到系统内出现应对工具的间隔时间。AI+低代码的最大价值恰恰体现在缩短这一物理距离上。

观察三，把“AI安全护栏”和“组件治理”纳入平台选型第一梯队。 在做技术选型时，除了关注模型能力与组件丰富度，更应该关注AI生成行为的可观测性、权限控制的精细粒度、安全策略的可配置程度以及组件退出与回收机制。一个在安全治理与体验间平衡得很好的低代码平台，往往比单纯“AI很聪明”的平台更能支撑规模化交付。

观察四，保持“小步快跑、场景穿透”的推进节奏。 在启动阶段，不必铺开所有业务线，选取三到五个具备“高频率、强痛点、低合规风险”特征的场景先行落地，并以“交互界面的真实用户反馈”作为迭代依据，积累组织内部的信任资产与能力基线。

观察五，为“AI+低代码”团队设计一份复合型人才的培养路径。 未来的平台运营者既需要懂一点代码逻辑、又需要理解AI的边界、更需要具备业务抽象和数据治理意识。企业HR与技术委员会应及早设计对应的职级体系与激励方案，而非沿用旧有的“软件开发工程师”序列。

总的来说，AI+低代码最根本的影响，不在某一个组件、某一个敏捷迭代、某一个平台。它正在以工具革新的姿态进入企业，却会以IT供给体系重塑的方式收尾。对技术决策者来说，核心议题从来不是要不要采用AI+低代码，而是如何在新的供给形势下，重新设计企业的软件生产关系和能力分布。 当业务的每一次微创新都能以更低摩擦、更高保真地转化为系统能力，企业的IT成本结构、创新节奏乃至竞争位置，都将发生连锁反应。

而对所有身处其中的个体——无论是专业开发人员、平台型开发者，还是业务侧的实操用户——我们都正在经历一场交互体验的集体迁移：与系统对话的方式、创造工具的过程、评价质量的尺度都在变。未来几年的格局，属于那些能够同时驾驭AI的生成能力与人类判断边界的人。希望本文提供的这些来自一线的体验切片与管理观察，能为您与团队判断这道多选题的答案，给出一点点参考。

参考文献

[1] 中国信息通信研究院. 企业数字化转型与低代码开发平台发展研究报告[R]. 北京: 中国信息通信研究院. 2025.

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

[3] 李思远, 陈默. 生成式AI在企业软件工程中的应用实践与效能度量[J]. 软件学报. 2025, 36(11): 35-47.

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

[5] 王建国. 平台型开发者群体的崛起与企业IT治理模式转型[J]. 管理世界. 2025(8): 89-98.