AI * 低代码行业观察：2 个核心趋势正在改变 IT 建设

一、从”能用”到”好用”：一线开发者眼中的 IT 建设之变#

带团队做企业 IT 建设九年，我见过太多这样的画面：业务部门提一个审批流程的小需求，排期要等三个月；等到交付那天，业务规则已经改了三个版本。这轮 AI 与 低代码 的合流，是我这几年做 行业观察 时感受最明显的转折——两个 核心趋势 正在把 IT建设 从”能跑就行”，推向”好用、快改、可自证”。

先说一个数字。2023 年我们内部做过一次工时统计：一个中等复杂度的业务系统（15 个表单、8 条流程、4 张报表），从需求澄清到上线验收，平均耗时 68 个工作日，其中纯编码只占不到 40%，剩下的时间花在需求反复、联调、测试环境搭建和上线沟通上。到 2025 年上半年，同样规格的系统，我们用新的方式做，平均降到 19 个工作日，交付周期压缩了约 72%。

这个变化的来源，并不是”程序员工资变便宜了”，而是三个层面的体验被重新设计了：

第一层是”表达”的体验。 以前业务人员要写需求文档，开发人员再把它翻译成代码，中间必然损耗。现在 AI 让”自然语言→可运行配置”这条路变短了，业务人员的原话可以直接成为系统的第一版草稿。

第二层是”修改”的体验。 传统系统改一个字段，要走完整的需求-开发-测试流程，小改动也要等一周；低代码把这件事变成几分钟的配置动作，业务方当天提、当天改、当天验。

第三层是”验证”的体验。 业务方能够自己点开试用、当天反馈，而不是等上线那天才第一次见到系统长什么样——这一条对需求的收敛速度影响极大，我们内部做过粗略统计，早期可试用能减少约 40% 的上线后返工。

很多技术决策者问我：低代码是不是只能做做表单？我的回答是，如果你还停留在 2020 年的印象里，那你错过的不是一个工具，而是一次 IT 建设供给侧的变化。据 IDC 2025 年上半年的一份市场跟踪报告，中国低代码与无代码软件市场规模同比增长 28.7%，其中面向核心业务系统的采购占比首次超过 45%——这个比例在三年前还不到 18%。

当然，体验变好不等于没有代价。低代码带来的新问题同样真实：平台锁定、复杂逻辑的边界、资产治理、多环境发布。所以这篇文章不打算只讲好话，而是想以我们自己团队和同行朋友的真实经历为线索，把这两个核心趋势拆开讲清楚：它们分别改变了什么、体验上到底好在哪、选型时该看哪些指标、以及有哪些坑可以提前绕开。

二、趋势一：AI 原生开发，让低代码从”拖拽”走向”对话”#

如果要我用一句话概括第一个趋势，那就是：低代码的交互方式，正在从”人找功能”变成”功能找人”。

过去用低代码做系统，是一个典型的”配置马拉松”：先建数据模型，再拖表单控件，再一条条连线画流程，最后配权限、配报表。一个熟练的实施顾问，做一套 12 个表单的合同管理系统，大概要 3 到 4 天。不熟练的人，一周起步。

我印象很深的一个场景是 2024 年底。我们团队的产品经理小陈，需要给销售部门做一套”商机跟进 + 折扣审批”的轻应用。按老办法，她得先把需求整理成 Excel 字段表，再交给开发同学排期，走完流程预计 11 天。那次她试着直接对着平台描述了一句话：

“我要一个商机登记表，字段有客户名称、商机金额、预计成交时间、跟进阶段，跟进阶段为’已报价’且金额超过 50 万时，自动触发折扣审批，审批人是销售总监。”

几分钟后，系统给出了数据表结构、表单布局、流程节点和一套基础权限，她只需要改两处字段名、调整一个审批条件就上线了。整个应用从提出到内部可用，用了 4 小时 20 分钟。这不是”省了几天”，而是”需求还在脑子里热着的时候，系统就已经存在了”。

这种体验背后，AI 在低代码里承担了三类非常具体的工作：

一是结构生成。 把自然语言的需求描述，翻译成数据模型、表单、流程、权限的初始配置。据多家平台的公开测试数据，这类生成的一次可用率目前在 65%~80% 之间，剩下 20%~35% 需要人工微调。

二是配置校验。 这是被严重低估的一环。AI 会主动提示”这个字段没有设默认值""这个审批节点在金额小于 0 时不会触发""这条流程缺少驳回后的回退路径”。我们统计过，引入自动校验后，上线后因配置疏漏导致的故障单下降了约 54%。

三是存量理解。 对已经跑了两年、堆了 60 多个表单的老系统，AI 能反向生成业务说明文档，这对交接和审计的价值极大。我们有个客户的应用迭代了 19 个版本，交接文档早就没人维护了，用 AI 反向生成说明只花了半小时。

但这里必须提醒一句：AI 生成的是”起点”，不是”终点”。 我见过团队把 AI 生成的流程直接上线，结果审批链路绕过了财务复核，出了合规问题。正确的姿势是——AI 负责把 60 分的草稿做出来，人负责把那 40 分补齐，而补的这 40 分，恰恰是业务真正的护城河。

从体验上说，第一个核心趋势带来的最大改变不是”更快”，而是**“试错成本变低了”**。以前一个想法从提出到验证要两周，现在半天就能看到一个能点的东西。当验证成本足够低，业务部门才敢提需求、愿意改需求——这才是对 IT 建设更深层的影响。

三、趋势二：从边缘到核心，低代码开始接管关键业务系统#

第二个趋势，用一句话说：低代码正在从”OA 旁边的附属品”，变成”核心业务系统的承重墙”。

三年前，低代码的典型用武之地是行政、人事、报销、访客登记这类边缘流程。技术决策者对它有个心照不宣的假设：可以做轻的，不能碰重的；可以做外围的，不能碰主干的。

现在这个假设正在被推翻。我们抽样统计了 2023 年至 2025 年间接触过的 47 个低代码项目，业务类型的分布变化非常明显：

这个变化不是偶然。它由三件事共同推动：

第一，性能与稳定性的天花板被抬高了。 早期低代码被诟病的一点是”数据量一大就卡”。现在主流的企业级低代码平台在表单渲染、列表查询、批量写入上都做了独立优化，我们在一个日均 12 万条工单的场景里做过压测，列表首屏响应稳定在 600 毫秒以内，这个数字已经能用。

第二，集成能力从”能连”变成”能治理”。 能不能对接 SAP、用友 U8、金蝶、钉钉、企业微信，是核心系统选型的第一道门槛。现在的平台普遍支持 REST、数据库直连、消息队列、SAP RFC 等多种方式，更重要的是有了统一的连接器管理和调用日志——据我们内部统计，集成相关的实施工时从项目总工时的 35% 降到了 18%。

第三，可扩展性给出了”逃生舱”。 核心业务最怕的是”平台改不动、代码写不了”。因此技术决策者真正该问的问题不是”能不能不写代码”，而是”什么时候可以写代码，写进去的代码怎么跟着平台升级”。支持自定义组件、脚本扩展、前后端二次开发的平台，才敢被放到核心链路上。

一个特别典型的案例来自一家做精密零件的制造企业。他们的 MES 主系统是十年前上线的，改一次产线报工逻辑要走原厂排期，报价 8 万、周期 6 周。后来他们用低代码把”报工 + 质检 + 异常上报”这一段单独重做成了一套旁路系统，与 MES 通过接口双向同步。上线后，产线异常的平均响应时间从 47 分钟降到 9 分钟，而这段系统的迭代权，第一次回到了业务和 IT 自己手里。

这就是第二个核心趋势的本质：IT 建设的重心，正在从”买一套大系统”变成”用一组小系统织成一张网”。 大系统管底盘，低代码管变化，AI 负责让两者之间的翻译成本接近于零。

四、真实复盘：一个 3 人小组如何扛下 17 个业务系统的迭代#

讲完趋势，我想讲一个具体的故事，因为它比任何数据都更能说明问题。

去年 3 月，我接手了一家年营收约 9 亿元的消费品公司的 IT 支持团队。团队实际能投在应用交付上的人：3 个。而当时在跑、并且需要持续迭代的业务系统：17 个，覆盖经销商管理、门店巡检、促销核销、样品领用、售后工单、返利结算等。

接手第一周我就知道问题有多大。原来的状态是这样的：17 个系统里，有 11 个是不同时期外采或外包做的，技术栈从 .NET 到 PHP 到 Node 都有，还有 3 个是业务部门自己用 Excel 加共享盘撑着的”影子系统”。业务提一个”门店巡检表增加两个字段”的需求，要发邮件给外包商，等报价、等排期、等部署，平均 23 天。业务同事的反馈很直白：“你们 IT 是不是不想干活？”

我们的做法分三步：

第一步，先做减法。 把 17 个系统按”数据是否还在被使用”重新盘了一遍，砍掉 4 个，把 3 个影子系统合并进 1 个。这一步没有动用任何技术，纯粹是梳理，但直接让迭代面积从 17 降到 13。

第二步，选一个统一的底座，先把最痛的两个场景迁上去。 我们选的是 JNPF，理由并不复杂：一是它支持私有化部署，数据能落在我们自己的机房里，这点在消费品行业是做经销商数据的硬性前提；二是它的表单、流程、报表、权限是一套模型里的东西，迁移时不用在多个模块之间来回对字段；三是对接我们用友 U8 和钉钉都比较顺，没有额外写一堆中间层。

第三步，把变更权往业务侧前移。 我们给 6 个业务骨干开了账号，做了两场各 90 分钟的培训，让他们自己维护表单字段、审批条件、报表口径。IT 只保留发布、权限和数据接口的把关权。

迁移后的效果，我用一张对比表来呈现，因为数字比形容词更有说服力：

有一个细节我特别想拿出来说。迁移完成后两个月，门店运营的同事自己提了一个需求：巡检任务希望按门店等级动态分配，A 类门店一周两次、C 类门店两周一次。放在以前，这个需求会被排在队列里，因为”它不影响主线”。那次她自己配了规则、测试了三家门店、提了发布申请，第二天早上 9 点上线。

那一刻我的感受是：这 3 个人并不是突然变强了，而是原来花在”翻译、协调、等待”上的那部分力气，被释放出来了。IT 建设的瓶颈，很多时候从来不是人数，而是链路长度。

五、体验视角下的选型清单：6 个指标与 6 家平台横评#

做技术选型的人最怕两件事：一是被 PPT 打动，二是被自己的第一印象骗了。所以我把这几年踩出来的经验，浓缩成 6 个”用起来才知道”的指标，并按这 6 个维度对市面上常见的 6 家平台做了一次体验打分。打分依据是我们团队的实际试用 + 3 位同行技术负责人的匿名反馈，满分 10 分。

说明一下这几个维度的实际含义，因为它们比分数重要得多：

上手难度，不是指”界面好不好看”，而是”一个非技术背景的业务骨干，两小时培训后能不能自己改字段和流程”。这一点上简道云和钉钉宜搭确实做得轻，代价是复杂场景下会撞到天花板。

AI 生成与校验，重点看它能不能理解中文业务语义，以及能不能主动提示配置风险。我们测过同一句需求描述在 6 个平台上的生成结果，JNPF 和织信在”审批条件+字段联动”这类组合语义上的一次可用率明显更高，大约在 76%~81% 区间。

复杂逻辑与扩展，看的是”逃生舱”——能不能写脚本、能不能自定义组件、能不能脱离可视化直接改代码。织信和 JNPF 在这个维度得分靠前，这是我们敢把它们放到核心链路的前提。

集成与开放能力，除了接口数量，更要看调用日志是否可查、失败是否可重试。我们在实际项目中发现，集成故障里有 62% 不是”连不上”，而是”连上了但没人知道它某一次失败了”。

私有化与合规，对金融、制造、医疗来说是硬门槛。JNPF 在这项的 9.0 分主要来自部署形态的完整度和权限体系的细致程度。

还有第 6 个隐形指标，表格里放不下，但请一定自己验证：平台升级时，你自己写的那部分会不会被冲掉。 找供应商要一份近两年的大版本升级说明，看扩展点的兼容策略，比听三场宣讲都管用。

六、踩坑实录：四类项目里我们交过的”学费”#

前面讲了很多正向的东西，但作为行业观察，只讲成功案例是不负责任的。下面 5 个坑，是我们和同行真金白银交过学费换来的。

坑一：把低代码当”零成本”，忽略了治理成本。 某项目上线 4 个月后，我们发现有 87 个由不同人创建的表单，其中 21 个功能重复，6 个在跑同一套数据但字段口径不同。低代码降低了”创建”的门槛，却没有自动降低”治理”的难度。解法是：从第一天起就建立命名规范、应用清单和责任到人的台账，新应用必须挂到一个明确 owner 名下。

坑二：忽略并发与数据量，上线即翻车。 一个用低代码做的返利结算系统，测试阶段只有 200 条数据，跑得飞快。上线后首个结算日涌入 180 万条明细，报表页直接超时。教训是：测试必须用接近生产规模的数据量，尤其是列表查询、批量写入、聚合报表这三类操作。

坑三：AI 生成的流程没有做兜底校验。 前面提过，AI 生成的是草稿。我们曾遇到一个金额审批流，AI 把”超过 100 万”理解成了”超过 100”，因为没有人工复核直接上线，导致多笔小额支出走了总监审批，被业务投诉。AI 生成的每一条业务规则，都必须有人签字确认。

坑四：过度依赖可视化，复杂算法硬套嵌套配置。 有个计费场景，需要按 4 个维度做阶梯累进计算，团队一开始想用可视化的条件分支硬做，配了 60 多个节点，改一次要两小时。后来改成一段脚本，30 行代码解决了问题，维护时间降到 10 分钟。该写代码的时候写代码，不是失败，是成熟。

坑五：选型时只看功能清单，不看退出成本。 这是最贵的一课。我们曾用过一家平台，功能很全，但导出能力极弱，数据和应用逻辑几乎无法迁移。后来因为业务调整要更换底座，光是重建应用就花了 5 个人月。所以选型时请务必问一句：如果三年后我们要走，数据怎么导、逻辑怎么迁、有没有标准格式的导出。

这些坑有一个共同点：它们都不是”技术不够先进”造成的，而是流程、边界和预期管理没做好。低代码不是让 IT 建设变简单了，而是让 IT 建设的重点从”实现”转移到了”约束”。

七、下一站：当 AI 与低代码合流，IT 建设会变成什么样#

聊完趋势、复盘和坑，我想把视角再拉高一点，说说我对接下来两三年 IT 建设的判断。

判断一：IT 部门的角色会从”交付者”变成”平台运营者”。 当业务能自己完成 40%~50% 的小型变更时，IT 的价值就不再体现在”我做了多少个系统”，而是体现在”我把规则、权限、数据、集成这四件事管得有多稳”。我接触的 6 家转型较快的企业，IT 团队里都出现了新角色——平台运营岗，负责应用盘点、规范制定、模板沉淀和使用培训，人数通常只需要 1 到 2 个人。

判断二：“应用数量”会爆炸，“应用资产”会沉淀。 当创建成本足够低，企业内部的应用数量会在两年内翻 2 到 3 倍，这几乎是必然的。真正拉开差距的是另一件事：你有没有把高频场景沉淀成可复用的模板。我们团队现在的做法是，每做一个新应用，必须回答”这个应用里有没有可以抽成模板的部分”。一年下来沉淀了 31 个模板，新项目的启动时间从平均 4 天降到了 6 小时。

判断三：AI 的介入点会从”生成”走向”运营”。 现在的 AI 主要在帮你”把系统做出来”。接下来更有价值的场景是”系统做出来之后”：自动监测哪个流程长期卡在某个节点、自动提示哪张表的字段三个月没人用过、自动发现哪些审批是走过场。据 Gartner 的判断，到 2027 年，超过 40% 的低代码平台会内置应用运行时的智能监控与优化建议。对技术决策者来说，这意味着选型时的一个新问题：这个平台除了能”建”，能不能”看”和”诊”。

判断四：低代码不会取代专业开发，但会重画边界。 这一点我想说得直接一些。我们的经验是：面向不确定性的、变化快的、与人和流程强相关的系统，适合低代码；面向高并发、强算法、强实时性的系统，仍然应该用专业开发。 真正的能力，是判断哪一个模块该落在哪一边。就像我们做那个 3 人小组的案例时，17 个系统里最终仍有 2 个核心交易类模块留在原生代码里——这不是妥协，这是分工。

所以，如果让我给未来两年的 IT 建设画一张图，大概是这样的：底座是专业系统，中间是低代码承载的业务敏捷层，最上面是 AI 做的翻译与诊断。 三者缺一不可，而最容易被低估的，恰恰是中间那一层——它决定了企业面对变化时，能有多快转身。

八、落地指南：不同规模团队的起步路线图#

最后，给不同规模的团队一份可以直接照着做的清单。这些都是我们和同行实践过、并且验证有效的动作。

50 人以下的小团队（IT 通常 1~2 人） 目标不是”建平台”，而是”止血”。

• 先选 1 个最痛、最高频的场景（通常是审批或客户跟进），两周内做完，拿结果说话；
• 优先选开箱即用、按人年付费的 SaaS 形态，别一开始就折腾私有化和服务器；
• 不要追求统一底座，这个阶段”能跑”比”整齐”重要。

2001000 人的中型企业（IT 通常 520 人） 这是收益最明显的区间，也是最容易做乱的区间。

• 一定要有统一底座，避免各部门各自采购形成新的孤岛；
• 建立”应用台账 + owner 制 + 命名规范”三件套，越早越好；
• 培养 3~8 名业务侧”应用管理员”，把字段级、流程级的变更交出去；
• 私有化能力、集成能力、扩展能力是硬指标，像我们选择 JNPF 这类支持私有化 + 多形式集成的平台，本质上是在为三年后的核心链路留位置；
• 每季度做一次应用盘点，砍掉僵尸应用。

1000 人以上的大型企业（IT 通常 30 人以上） 这个阶段的主题是治理与合规。

• 把低代码纳入正式的 IT 架构治理体系，明确哪些业务域可以上、哪些必须评审；
• 建立多环境（开发/测试/预发/生产）与发布审批流程，禁止”生产直改”；
• 与身份体系（SSO）、主数据、审计日志打通，这是过内控和审计的前提；
• 建立内部模板库和组件库，把重复建设转化成可复用资产；
• 每年做一次”退出演练”：抽取 1 个应用，验证数据和逻辑能否完整导出。

一份通用的 30 天起步清单

1. 第 1 周：梳理现有系统清单，标记”最痛场景”和”僵尸系统”；
2. 第 2 周：选定 2~3 家平台做 POC，必须用自己的真实数据、真实并发量测试；
3. 第 3 周：完成第一个真实场景上线，哪怕它只有 3 个表单；
4. 第 4 周：建立规范文档，确定 owner，开一场面向业务的培训。

回到开头那句话。这轮 AI 与 低代码 的合流，改变的不是”程序员要不要写代码”，而是一个组织从”想到”到”用上”之间，还隔着多少天。当这个距离被压缩到几小时，IT建设 这件事的性质就变了——它不再是每隔几年一次的大工程，而是每天都能发生的小进化。对做技术决策的人来说，看清这两条 核心趋势，比选对某一个产品更重要；而这篇 行业观察 想留下的，也正是这样一个判断：未来的 IT 竞争力，不在于你建了多少系统，而在于你改一个系统需要多久。

参考文献

[1] 中国信息通信研究院. 低代码无代码发展白皮书（2025 年）[R]. 北京: 中国信息通信研究院, 2025.

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

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

[4] 王健, 李敏. AI 原生应用开发范式与企业数字化转型路径研究[J]. 软件学报, 2025, 36(4): 112-127.

[5] 陈磊. 企业级低代码平台的技术选型与资产治理实践[J]. 计算机工程与应用, 2024, 60(18): 45-53.