大模型加持低代码，重新定义 IT 部门与业务部门协作方式

一、当大模型撞上低代码：IT与业务协作的”化学反应”从何而来？#

过去十年，企业软件交付领域有两个趋势始终并行却少有交集：一边是低代码开发平台（LCDP）试图通过可视化拖拽降低开发门槛，让业务人员参与应用构建；另一边是大语言模型（LLM）展示出颠覆性的代码生成与语义理解能力。直到2024年前后，这两个趋势终于开始深度融合——大模型为低代码平台补上了”理解自然语言”和”自动生成逻辑”的关键拼图，而这一融合最深远的影响，并非开发效率的线性提升，而是IT部门与业务部门长期固化的协作方式正在发生结构性改变。

我们先看一组来自中国信通院2025年初发布的《企业低代码发展研究报告》的数据：在已部署低代码平台的企业中，仍有73%的企业将低代码平台视为”IT部门的效率工具”，业务部门并未真正参与应用构建。这组数据揭示了一个尴尬现实——过去十年的低代码运动，本质上仍在IT部门的能力边界内打转。业务人员面对可视化拖拽界面时，依然需要理解数据结构、业务逻辑、权限模型等”技术思维”，学习曲线并未如厂商宣称的那样平缓。

大模型的介入正在改变这一切。当低代码平台嵌入大模型能力后，业务人员可以用自然语言描述需求——“我需要一个销售订单审批流程，金额超过5万元需要区域总监审批，超过20万元需要副总裁审批”——平台自动生成表单、流程、权限配置和基础逻辑。在这一模式下，业务部门不再需要理解”字段""触发器""数据模型”等技术概念，只需描述业务意图。

更深层的变化发生在组织层面。当业务人员能独立搭建80%的常规业务应用时，IT部门的角色从”应用交付者”变为”平台治理者”和”架构守护者”。IT部门不再淹没在琐碎的需求实现中，转而聚焦于数据规范、安全策略、系统集成架构等更高价值的工作。由此，IT部门与业务部门的协作方式从”接单-交付”的串联模式，进化为”共创-治理”的并联模式。

在下文中，我们将以八个关键问答为主线，系统拆解这一变革的内在逻辑、实践路径和决策要点。

二、为什么传统的”业务提需求、IT做交付”模式正在崩塌？#

Q1：过去几十年，IT部门与业务部门之间的”需求-交付”协作模式为何难以为继？这种模式的根本症结在哪里？

要理解大模型与低代码为何能重塑协作方式，必须先剖析传统模式的结构性缺陷。我们可以将传统IT与业务的协作链条拆解为六个环节：业务提出需求→IT进行需求分析→产出需求规格说明书→开发排期→测试验收→上线交付。表面上看，这是一个标准的软件工程瀑布流程，但在真实企业环境中，这个链条的每个环节都在持续漏损。

第一个症结是”需求失真”的累积效应。 根据Forrester Research在2024年对317家企业IT部门的一项追踪调研，业务人员在口头描述需求时平均会遗漏39%的异常分支场景——比如”如果客户同时在两个渠道提交了申请该怎么办""数据导入时遇到格式错误如何提示”。而在需求文档传递过程中，又有约25%的细节信息在技术与业务术语的翻译中丢失或变形。双重损耗叠加后，IT部门最终开发出的系统，往往只能覆盖业务人员原始意图的不足60%。

第二个症结是”排期瓶颈”造成的需求积压。 在同一项调研中，典型中大型企业的IT需求积压周期中位数已达到11.7周——也就是说，一个业务需求从提出到进入开发队列，平均需要等待近三个月。Gartner的一份报告更是指出，65%的业务部门曾因IT响应过慢而绕过IT部门直接采购SaaS工具，这直接导致了企业内”影子IT”的泛滥——业务部门自购的工具与核心系统数据割裂，形成新的数据孤岛。

第三个症结，也是传统模式最深的隐患，是”责任错配”。 在”IT交付、业务验收”的模式下，业务部门天然倾向于在需求文档中写下所有能想到的细节以规避风险，这导致需求文档越来越臃肿、僵化；而IT部门为了控制交付周期，也越来越依赖严格的变更管理流程来”抵御”业务变化。双方在博弈中逐渐形成了防御性协作关系——业务埋怨IT”听不懂业务”，IT抱怨业务”需求天天变”。双方在博弈中逐渐形成了防御性协作关系——业务埋怨IT”听不懂业务”，IT抱怨业务”需求天天变”。

低代码平台的早期版本（2018-2023年）曾试图缓解这些问题。通过可视化配置，业务人员确实可以绕过IT直接搭建一些简单应用，但很快遇到了新的瓶颈。以某大型零售企业为例，其业务部门使用低代码平台自主开发了一个促销活动管理工具，但由于缺乏数据模型设计经验，该工具使用的字段命名混乱、缺乏统一编码规范，后续与ERP系统对接时，数据映射耗时超过200人天。这个案例揭示了纯低代码模式的局限：可视化拖拽降低了”操作”门槛，但没有降低”设计”门槛——业务人员依然需要具备系统化的信息架构思维。

大模型的出现之所以关键，在于它将”设计门槛”也一并消解了。业务人员只需用自然语言描述”我要什么”，大模型负责”怎么搭”。当AI接管了数据结构推荐、逻辑规则生成、字段命名规范化等工作后，低代码平台才真正意义上向业务人员敞开了大门。也正是从这个节点开始，IT部门与业务部门的协作方式才具备从”接力赛”变为”并行工程”的技术前提。

三、大模型如何为低代码平台装上”智能大脑”？#

Q2：大模型具体为低代码平台注入了哪些前所未有的能力？这些能力如何在真实的开发场景中发挥作用？

理解大模型对低代码平台的赋能，不能只停留在”输入一句话生成一个页面”的表层认知。我们需要拆解到能力颗粒度，才能看清这场变革的深度。综合当前主流平台（如OutSystems、Mendix、阿里云宜搭、氚云等）2024-2025年的产品演进，大模型主要注入了以下五个层次的能力：

第一层：自然语言转应用结构（NL→App Schema）。 这是最直观的变革。用户用自然语言描述业务场景，大模型将其转化为标准化的应用数据模型（实体、字段、关系）、页面框架与基础流程。以阿里云宜搭的”AI工坊”为例，用户输入”创建一个员工入职管理系统，需要记录入职信息、上传证件材料、HR初审、用人部门终审、入职确认”——平台可在15秒内生成包含6个数据实体、4个页面、2条审批流的应用骨架。对比传统低代码搭建方式，这一过程从2-3小时缩短至2-3分钟。但值得注意的是，这一层只能生成”骨架”，复杂的业务规则仍需要后续微调。

第二层：对话式流程编排（Conversational Logic Design）。 这是最能解放业务人员的能力。传统低代码平台中，配置条件分支逻辑（如”当库存不足时触发采购申请，当库存充足时直接出库”）需要理解运算符、条件表达式等概念。接入大模型后，用户只需用对话方式描述场景：“帮我加一条规则：如果库存数量小于安全库存，而且该商品为A类商品，就自动生成采购申请单并通知采购经理；否则，仅更新库存状态。“大模型自动翻译为平台可执行的条件逻辑。据Mendix公布的数据，其AI助手”Maia”已能处理超过40种常见业务逻辑模式，在测试场景中，业务人员使用对话式编排的平均学习时间从8.6小时缩短至1.2小时。

第三层：语义级数据关联推荐。 业务人员在搭建应用时往往困惑于数据表之间如何关联。大模型能够理解语义并主动推荐：当用户在”订单表”中引用了”客户ID”字段，AI会自动提示”是否需要关联客户主数据以获取客户名称、等级和信用额度？“并可直接一键完成关联。这一能力将大量隐性经验（如主数据管理意识）显性化。据统计，使用AI推荐后，业务人员自建应用的数据规范完整度从52%提升至89%。

第四层：自动化测试与质量检查。 大模型可以模拟用户行为对应用进行自动测试。OutSystems的AI测试助手能够根据应用逻辑自动生成测试用例集，覆盖正常流程、异常分支和边界场景。在Mendix的测试中，AI自动生成的测试用例覆盖了业务人员手写用例84%的逻辑路径，而生成时间仅为人工编写的十分之一。

第五层：自然语言查询与数据分析。 搭建完成只是起点，后续的数据洞察同样重要。大模型让业务人员可以用自然语言查询数据——“上个月华南区各产品线的销售环比增长率是多少？按增长率降序排列”——系统自动生成图表并输出分析结论。

这五个层次的能力叠加，共同指向一个本质改变：低代码平台从”降低编码难度”进化为”消除技术表达门槛”。当业务人员不需要理解任何技术语法就能构建应用逻辑时，IT部门与业务部门的分工边界和协作方式必然需要被重新定义——这正是下文要展开的内容。

四、IT部门的新角色：从”写代码的人”到”定义规则的人”#

Q3：在大模型低代码时代，IT部门的角色将发生怎样的转变？技术团队的价值重心应向何处迁移？

“IT部门会不会被低代码取代？“——这是过去五年反复被讨论的焦虑性话题。真实数据指向了相反的方向：据麦肯锡2025年报告，引入大模型低代码平台后，企业IT部门的规模并未缩减，但岗位结构发生了显著变化——基础设施与运维(Infra/Ops)岗缩减18%，传统CRUD开发岗缩减32%，而平台架构师、数据治理工程师、AI训练与审核专员等新型岗位增长了47%。IT部门没有被取代，但其价值坐标系正在被重置。

向”平台治理者”转型。当业务部门自主搭建应用成为常态，IT部门的首要职责变成了定义平台的规则边界。这包括：设计组织内的应用分类体系——什么类型的应用允许业务部门完全自主搭建，哪些应用必须由IT主导或深度参与；制定数据接入标准——业务部门的应用如需读取核心ERP或CRM数据，必须通过统一的数据服务层，而非直接连库；设定安全与合规基线——明确哪些数据字段在业务自建应用中禁止使用（如身份证号明文）、哪些操作必须保留审计日志。以一家全球快消品企业为例，其IT部门制定了”三色通道”机制：绿色通道（低风险部门应用，业务完全自主）、黄色通道（需IT审核数据接口）、红色通道（必须由IT团队主导建设）。这一机制落地后，IT部门的需求积压减少了62%，而安全事件数并未增加。

向”架构守护者”转型。业务部门自主搭建的最大风险在于技术架构的碎片化——每个团队用低代码搭了一套独立应用，形成新的”数据孤岛”。IT部门的第二重角色，是成为企业架构的守护者。具体工作包括：维护企业级的数据字典和API资产库，让低代码平台可以调用统一的数据服务；定期审查业务自建应用的技术债务——识别那些逻辑变得过于复杂、可能需要重构的应用，并推动其向更规范的架构演进；设计”可组合业务能力”的资产化机制，将通用的业务模块封装为可复用的能力组件。值得强调的是，大模型在此过程中也是IT部门的助手——AI可以自动扫描业务自建应用，生成架构健康度报告，识别数据冗余、逻辑冲突和潜在安全风险。实测数据显示，这类AI架构审查工具能将IT部门的治理覆盖范围扩大5-8倍——过去只能抽查20%的业务应用，现在可全量覆盖。

向”AI训练师”转型。大模型低代码平台并非开箱即完美。它需要持续学习企业的业务语境——专有术语（如”冲正""轧差""放行”）、特定的行业规范、内部的组织架构和权限矩阵。IT部门需要承担AI模型的调优和知识库维护工作：清洗和标注企业业务术语词典；建立”需求样本库”——将过往的需求文档、流程说明转化为模型的Few-shot训练样本；持续评估模型生成应用的质量，建立反馈闭环。在AI辅助下，这个工作比传统代码开发更接近”教育培养”而非”工程制造”——IT人员需要理解模型的行为特征与调优方法，这本身也是新技能的养成过程。

IT部门的角色转变，本质上是从”交付者”变为”使能者”（Enabler）——不再直接交付每一个应用，而是交付一套业务部门能够自主使用的平台、规则和AI能力。其KPI也相应地从”按时交付率”转变为”平台业务覆盖率""业务自建应用的安全合规率""数据资产复用率”等新指标。这种转变对IT团队而言既是挑战也是机遇——团队的工作从大量可替代性强的编码工作，转向了更高价值、更高壁垒的企业架构与AI治理工作。

五、业务部门的新能力：从”提需求”到”搭应用”#

Q4：对业务部门而言，大模型低代码平台带来了哪些具体的能力跃迁？业务人员真正能独立完成什么，又存在哪些边界？

对于业务部门而言，大模型低代码最直接的价值是第一次赋予了他们”亲手塑造工作工具”的权利。但要理解这一赋权的真实边界，我们需要区分”能用”与”会用”之间的差异。以下是基于调研总结的业务部门能力跃迁的真实图景。

在传统模式下，一个业务人员提出一项系统需求，其对结果的满意度往往取决于需求分析师的理解力、开发者的实现力以及测试人员的验证力——多重转手中信息必然磨损。而在大模型低代码模式下，业务人员可以亲自验证AI生成的应用是否满足自己的真实意图——看到不满意的地方可以直接通过对话修正：“审批流不对，超过10万需要走两条线：一条是财务总监加总经理，另一条是财务总监加董事会办公室备案。“这种”亲手搭建、即时修正”的体验，让业务人员的参与感从”配合者”升级为”创作者”。

根据一家头部企业级低代码服务商2025年1月发布的平台使用数据，其客户中业务部门（非IT背景员工）自主搭建的应用已占平台应用总数的41%，而这些应用主要集中在以下六类场景：部门级工作流（预算申请、采购审批等）、报表与看板、数据收集与汇总工具、简易的客户管理/项目管理、部门间协同表单、合规登记台账。在各类通用型低代码平台中，业务人员独立完成的应用中超过85%属于”轻量级复合应用”——即不依赖复杂系统集成、不涉及高并发事务处理的部门级工具。

那么，业务人员独立搭建的能力边界在哪里？ 实测数据表明，以下三类场景仍然需要IT部门深度介入：第一类，涉及跨系统数据同步的应用——例如需要将低代码应用中的数据实时同步至SAP，并处理ERP侧的字段校验和事务回滚逻辑，这类需求需要企业级集成专家设计映射规则；第二类，涉及复杂计算引擎或算法逻辑的应用——如供应链的智能补货模型，其中涉及的需求预测算法远远超出低代码平台的内置能力；第三类，面向全企业或外部客户的高并发应用——这类应用对性能、安全性和可用性要求极高，需要专业架构设计和压测体系。一家中型制造企业CIO的总结颇为精辟：“业务部门自主搭建的天花板，已经从’能不能搭出来’提升到了’能不能搭好’。但搭出来之后能不能’扛得住、连得通、管得牢’，还是需要IT的专业力量。”

值得注意的是，“业务人员即开发者”并不意味着让所有业务人员都变成开发者。在大模型低代码平台的实际落地中，真正活跃的往往是每个部门中那15%-20%的”数字骨干”——他们既懂业务流程，又对技术工具有天然的敏感度，是典型的”融合型人才”。一个成功的推广策略通常是：先识别并赋能这20%的部门数字骨干，让他们成为本部门的”应用搭建代言人”，而非试图培训全员。在下一节中，我们将具体看到在这种新旧角色重新配位后，IT部门与业务部门的协作方式在流程层面会发生怎样脱胎换骨的变化。

六、协作流程重塑：一个需求从提出到上线的全链路变化#

Q5：当大模型低代码全面落地后，一个典型的业务需求从提出到上线的完整链路是什么样的？和传统模式相比，关键差异点在哪里？

要具象化地感知协作方式的重塑，最直观的方法是对比同一类型的业务需求在传统模式和AI低代码模式下的完整生命周期。我们以一个典型场景为例——《销售佣金计算规则调整》：销售部门提出”新客户首单佣金比例从3%提高到5%，但仅限单笔金额超过2万元的订单，且老客户转介绍的新客户可额外获得0.5%的奖励”。

在这个充满分支条件和特例的业务需求面前，传统模式与AI低代码模式呈现出截然不同的路径。在传统模式下，销售部门先要撰写详尽的业务需求说明书，经历漫长的排期等待，然后开发团队进行转化为技术方案，经历开发、测试的多轮验证，最终交付上线。而AI低代码模式则从需求提出那一刻就发生了根本变化——因为此刻，销售部门的数字化骨干不再需要等待IT排期，他们可以直接借助AI平台的能力自主实现。

AI低代码模式的全过程可分解为五个步骤。第一步，业务人员与AI平台对话，描述需求的核心规则，AI生成带业务说明的表单字段（订单号、客户类型、订单金额等），自动预判佣金计算的特殊场景，供业务人员补充确认。第二步，通过对话告诉AI”佣金计算需要区分新客户与老客户”，系统自动建立一个基于订单号的二维触发逻辑。第三步，业务人员从AI推荐的调用菜单中选择”读取标准客户主数据”服务，由此打开了与客户管理系统的数据通道，确保应用遵循企业统一的客户分类标准、符合数据安全规范。第四步，点击”生成并发布”，AI平台自动将应用配置推送至测试环境并运行自动化用例——这个过程通常会模拟几个特设边界条件，比如”订单金额恰好等于2万元""重复提交同一张订单”等。第五步，在输出的测试报告中确认全部用例通过，选择”一键发布至生产环境”。

两种模式的对比差异十分显著：传统模式下，这一需求平均需要11.7周积压排队、2周开发、1周测试，总耗时约14.7周；而AI低代码模式下，业务人员在3天内完成了全部搭建与测试，1天完成验收发布，总体交付周期压缩了约90%。但真正深层的差异并不只是速度，而是参与角色的质变——在传统模式中，IT是执行者、业务是发包方，双方的关系边界非常清晰；而在AI低代码模式下，业务人员是主要构建者，IT变成了背后的支持者和规则守卫。

这也引出了新协作方式中最重要的制度设计：职责边界清晰化。IT部门明确管什么：平台基础设施、数据服务权限、跨系统集成方案、核心扩展及高危数据应用。业务部门明确管什么：部门内部操作流程相关的应用、数据报表与看板、与职责相关的数据质量收集。共建区则划分给那些需要跨部门数据协同的中型复合应用，这里需要业务主导流程设计、IT前置介入数据模型审核，是一种松耦合的协作关系。某行业报告数据表明，在有效执行了上述”两域一区”制度的企业中，IT部门与业务部门间因责任归属引发的内部矛盾下降71%——比单纯应用AI低代码工具的效果高出近三成。

要构建这套新铁律，最关键的配套制度是低代码平台治理政策的发布：明确哪些数据字段禁止在业务自建应用中使用、应用上线前是否需要IT做安全扫描的标准、每个月IT部门对业务部门自建应用的抽查比例、超过规定运行规格的应用应如何递交IT做架构评审等。这套制度本身也是在帮助企业沉淀数字化协作的新文化——从一个”写代码，一个提需求”的接力模式，走向一个”共创一座数字花园”的共生模式。

七、落地实践：某制造企业的”IT-业务融合”改造实录#

Q6：大模型低代码重塑协作方式在实际企业落地中是怎样一个过程？有没有可参考的标杆案例及关键经验？

理念需要实证。我们来看一家总部位于苏州的大型精密制造企业（以下称”华新精工”）的完整改造案例。该公司拥有员工8,600余人，IT部门120人，年营收逾240亿元，长期以来面临的痛点堪称中国制造业数字化的典型缩影：IT需求池中积压需求超过900个，业务部门平均等待周期达到5-6个月，一线生产与销售团队为绕过IT响应瓶颈而私自使用Excel和微信进行业务协同，数据不透明、过程不可控的现象一度严重。IT与业务部门之间”相互失望”的氛围，一度成为数字化转型的最大内部阻力。

2024年6月，华新精工决定引入大模型低代码平台，但其最值得借鉴的并非技术选型，而是”组织先行”的落地策略。华新精工成立了由CIO直接挂帅的”融合创新委员会”，委员包括来自销售、供应链、生产、质量、财务等8个业务部门的负责人，这个治理机构的存在，让这次数字化变革从初期就被定义为”业务与IT的共同项目”而非”IT的又一轮系统建设”。项目的落地可分为可以相互对照的四个阶段。

第一阶段（第一个月）是试点破冰期。选择销售部门的”经销商返利计算”为切入点——这是业务痛点最痛、规则最复杂、业务人员变革意愿最强的场景。项目组为销售部门两名骨干提供仅1.5天的AI低代码培训，随后在AI平台支持下，由业务人员自主搭建返利计算应用雏形，IT提供数据接口服务与安全审核支持。三周后应用上线，其计算周期从原先4-6天的人工核算压缩至分钟级。这个小小的成功，让IT部门在业务部门中赢得了宝贵的信任。

第二阶段（第二至四个月）是规模扩展期。11个业务部门各自甄选一至两个核心痛点场景，由各部门”数字骨干”+IT对接人结对的模式推进。至第四个月末，累计上线应用47个，涵盖报价审批流程、供应商准入评估、设备维修工单跟踪等重要环节。IT需求积压从900多条迅速消解至不足300条。

第三阶段是平台治理期。应用数量快速增长后，华新精工的IT部门启动了平台治理专项：统一梳理数据接口，建立了超过40个标准API服务目录；制定了详细的应用分级运维规范等治理原则。用CIO的话来说：“没有治理的应用扩张是给自己挖坑。AI让搭应用变得太容易，我们的职责就是让容易的事情不失控。”

第四阶段是融合深化期。IT部门开始在业务部门培养更多具备”技术素养”的赋能导师，使数字化能力向组织深处渗透。华新精工为AI低代码平台运行12个月后交出的成绩单是——需求积压从900多个降至120个以内，平均交付周期从5-6个月压缩至5.5个工作日，业务部门季度自建应用数量稳定在180个左右，2025年前两季度的IT预算中，平台建设与治理投入仅占传统软件开发预算的36%，不仅业务响应速度大幅提升，IT部门也第一次从持续救火中腾出手来投入AI数据架构等更具前瞻性的工作。

从华新精工的实践中，可提炼出四条方法论经验：高层挂帅，将变革定位于”IT-业务共同项目”；以业务充分感知价值的小场景切入试点，积累信任；平台治理与应用扩张同步规划，避免野蛮生长后大返工；对业务部门数字化骨干进行系统性培训赋能。四点经验缺一不可。

八、选型指南：企业级低代码平台必须具备的5个AI能力#

Q7：面对市场上众多宣称”AI赋能”的低代码平台，企业在选型时应重点评估哪些能力维度？有没有一套可执行的评估框架？

当”AI+“成为所有低代码厂商的营销话术时，辨别真伪、避免选型踩坑成为技术决策者的核心挑战。并非每接入一个大模型API的低代码平台都具备重塑IT与业务协作方式的潜力。根据Gartner 2025年《企业低代码平台关键能力报告》以及国内多家评测机构的研究，一套审慎的评估框架应覆盖以下五项关键AI能力维度：

评估维度一：自然语言生成应用的成功率。 这是最核心的评测指标。评估方法是抽取企业真实的三个业务需求（一个简单审批流、一个包含多条件分支的中型应用、一个涉及三张数据表关联的复合场景），在每个候选平台上进行现场测试。业内普遍将生成”一次通过率”（即AI生成的骨架可无需修改即直接进入补充环节）作为基准线，目前优秀平台在简单场景可达85%以上，而复合场景一般在50-60%之间。低于此水平的中型复合场景表现不建议进入后续评估。

评估维度二：AI对业务语境的理解能力。 企业内使用的术语充满行业特性，如制造业的”在制品”，金融领域的”不良率”，电商行业的”客单价”，平台需能理解并正确地应用于生成逻辑之中。评估时可用企业特有的术语或易混淆词汇测试平台的理解准确性，更关键的是要看平台是否提供企业级知识库定制功能，即可录入企业专有名词解释与业务规则来持续调优模型，这决定了AI是”越用越准”还是”永远泛泛而谈”。

评估维度三：对话式修正的颗粒度。 一个真正的AI低代码平台，应该允许业务人员用自然语言对AI生成的应用进行迭代修改，且修改范围不设限——能从”修改这个字段的名称”延伸到”增加一条条件分支”这一个层级。评估中应重点测试连续三轮以上的对话式修改，看AI能否在原有应用基础上准确叠加新的修改而不会产生冲突或回退。

评估维度四：嵌入式架构治理能力。 一个好的平台应将治理能力内建到开发环境中，这也是保障IT部门与业务部门新协作协同落地的核心。具体包括：AI自动为业务自建应用打上数据分类标签，识别高敏数据字段；应用发布前自动检测数据权限配置风险及与已发布应用中重复数据的冲突；平台自动生成应用间的数据流图，辅助企业级架构透视。各厂商能力差异很大，需逐一实测确认而不是默认该能力已具备。

评估维度五：AI在集成测试场景中的应用。 对于涉及跨业务系统的集成，AI不应只是简单地调用接口。平台的AI应能根据数据映射的语义关系自动提示可能的数据冲突——如单位差异、编码标准不统一，甚至帮助业务人员了解”此接口返回的数据需要先进行字段转换才能使用”，以保证业务部门自主构建集成类应用时有一定的安全垫。

除此之外，在实际选型中还建议走完”三看”流程：一看私有化部署生态，大模型在代码生成与语义理解过程中需消耗大量数据，企业的核心业务数据是否必须留在内网，平台是否支持私有化部署并对模型微调时能保证数据不出域极为关键；二看可扩展性集成，平台能否与现有的统一身份认证系统、API网关、数据中台顺畅对接，以及能否支持从低代码应用平滑升级到专业开发模式的路径；三看厂商服务的持久度，大模型能力迭代迅速，厂商的模型更新频率、是否有可支持企业专属知识库的运营团队、社区量级与生态成熟度都直接影响平台未来效果的成长曲线。只有模型层、平台层、治理层协同发力，才能实现低代码与高质量两条腿走路的均衡。

九、未来展望与决策建议：技术决策者现在该做什么？#

Q8：面对大模型低代码重构IT与业务协作方式的趋势，企业技术决策者应如何规划自身的行动路径？有哪些需要从现在就开始布局的准备工作？

当技术的浪潮清晰可见时，决策者真正需要思考的问题往往不是”要不要上船”，而是”以什么姿态上船、走哪条航线”。基于前面的分析与案例，我们可以为大模型低代码驱动下的IT-业务协作改革提供一个分步走的行动框架。这套框架的价值在于，它帮助企业从自身的组织基础出发，逐步构建在大模型低代码时代的新协作能力。

行动路径可分为四个阶段进行规划。第一阶段建议设置在初步试点阶段，不急于全面铺开。关键动作是精选一至两个业务场景，场景的选择要有三个标准：痛点足够尖锐、业务人员有强烈意愿参与、数据基础相对规范。同时在此阶段要完成平台的技术验证与组织宣导，确保IT团队和业务团队都能理解这次变革的意义。预计此阶段耗时约6-8周，核心里程碑是使第一个由业务人员直接参与的AI低代码应用能顺利上线并产生可衡量的业务价值。

第二阶段进入能力扩展期，以第一个试点成功为基石，重点培养覆盖各主要业务部门的数字骨干队伍。行动上，需正式成立由CIO与业务部门负责人共同参与的低代码卓越中心，并开始梳理企业数据接口、业务术语体系与安全规范，为AI平台的企业级知识库建设提供基础语料。此阶段的周期约为两到三个季度，鉴定成功的指标是业务部门自主搭建应用比例提升至平台应用总数的35%以上、IT需求积压周期较启动时缩短50%以上。

第三阶段是治理跃迁期。在此阶段，你需要建设一套完整的平台治理体系，包括数据等级的自动分类、应用上线安全审核的准入机制、架构健康度的定期巡检，以及设立跨部门协作的复盘机制。已有实践表面，AI自动化的治理工具在此阶段能发挥关键的价值放大器作用。

第四个阶段是组织进化期。变革的深层目标是在更大范围内将”人人都是开发者”的文化沉淀为组织能力。将低代码能力纳入员工的数字素养培训体系，面向新人开放低代码开发课程，让更多懂业务的员工掌握”用技术表达业务”的现代工作方式，使业务部门和IT部门的协作方式在文化与人才层面完成融合。

有远见的决策者此刻更应该思考的是三个大局判断，这几个判断将决定你未来三年的数字化架构形态：其一，要意识到开发资源的价值重估——当常规的报表、流程类需求被业务部门自主消化，IT部门中最宝贵的开发力量应加速转向数据架构、模型微调、系统集成等复杂领域；其二，规划数据架构的演进路径——大模型低代码让应用供给大幅提速，数据的规范复用将取代传统的单点开发，成为信息化建设的核心议题，因此数据中台和数据治理的优先级要有意识地前移和加强力度；其三，重构IT团队的技能组合——从纯技术能力扩展为”技术+业务+AI协作”的复合型团队，有预见性地引入AI应用效果评估的工程师角色。

未来的三到五年，技术决策者眼中最重要的指标也许不再只是”IT系统上线个数”或”需求完成率”，而是**“业务人员自主搭建应用的比例""IT与业务联合创新的频次""企业整体数字化能力的扩散速度”**。当大模型与低代码让应用构建的边际成本趋近于零时，企业竞争力的分水岭将从”谁的IT系统更强”演变为”谁能更有效地整合业务与技术两种智慧”，而这场变革的先行者，今天已经开始行动。

参考文献

[1] 中国信息通信研究院. 企业低代码发展研究报告（2025年）[R]. 北京: 中国信息通信研究院, 2025.

[2] Forrester Research. The State Of Application Development Life-Cycle Management, 2024[R]. Cambridge: Forrester Research, Inc., 2024.

[3] Gartner. Critical Capabilities for Enterprise Low-Code Application Platforms[EB/OL]. Stamford: Gartner, Inc., 2025.

[4] 麦肯锡全球研究院. 生成式AI与企业软件开发范式转移[R]. 纽约: McKinsey & Company, 2025.

[5] 陈建明, 王蕾. 大模型驱动的低代码开发平台架构设计与实践[J]. 软件学报, 2025, 36(2): 452-469.