AI 能力全面渗透，低代码开发平台将打破 IT 资源不足的长期困局

一、需求排队三个月：IT资源不足的困局每天都在发生#

我在一家年营收 30 亿左右的装备制造集团做信息化负责人，团队满编 14 人，其中真正能写代码的 9 个。听起来不算太少，但我们要支撑的是 6 个事业部、23 家分子公司、4000 多名员工。

先说一个我印象最深的场景。2023 年 9 月，供应链中心提了一个”供应商月度考评线上化”的需求，从提交到排期，等了 87 天。为什么？因为当时手上压着 MES 对接、财务共享接口改造、两个 OA 流程重构，每一个都是”老板点名”的优先级。那位供应链的经理每隔两周来问一次，最后一次他站在我工位旁边说：“我不是催你，我是真的每个月要花两天时间手工汇总 300 多家供应商的数据。”

这种感觉很难受。不是我们不想做，是IT资源就这么多，而业务的需求永远在涨。

我后来做过一次统计，我们团队 2023 年全年受理需求 386 个，实际交付 211 个，交付率 54.7%。没交付的里面，有 62% 属于”表格收集、流程审批、数据看板”这类相对标准化的场景——说白了，不是做不了，是没人力做。

这就是困局的本质：不是技术难题，是产能错配。高价值的技术人力被大量低复杂度、高重复度的需求占满，真正需要架构能力的项目反而被拖延。

更麻烦的是业务侧的体验。他们看到的是”提了需求没人理”，于是开始自己想办法——用 Excel 飞来飞去，用微信群做审批留痕，用共享盘当数据库。等到数据乱了、审计来了、合规过不去，又回头找 IT 收拾。我们内部管这叫”影子系统债”，每年清理这些债务大概要额外消耗 1.5 个人力。

2024 年初，我开始认真考虑低代码。当时的判断很朴素：如果能把那 62% 的标准化需求从技术团队手里分流出去，哪怕只分流一半，我们也能把交付率拉回 80% 以上。但试了两个平台之后，业务同事的反馈并不好——「拖拽是挺简单，但我不知道从哪开始拖」。低门槛的门槛，其实卡在”设计”这一步。

直到 2024 年下半年，AI 开始大规模进入这个领域，事情才起了变化。

二、AI 渗透低代码平台：开发体验发生的三个真实变化#

我不想讲技术原理，只讲我在实际使用中感受到的三个变化，这三个变化直接决定了业务同事愿不愿意用。

变化一：从”拖拽配置”到”描述即生成”

以前搭一个应用，第一步是画数据模型。业务同事往往在这一步就卡住了——他们能说清楚”我要管供应商”，但说不清”供应商需要几个字段、字段之间什么关系”。

现在不一样了。我在内部推广的平台上，业务同事可以直接输入一段话：“我要做一个供应商月度考评表，包含供应商名称、所属品类、交付及时率、质量合格率、配合度评分，评分由采购员和质检员分别填写，最后自动算总分并排名。”

系统会在十几秒内生成数据表结构、表单页面和一个基础列表视图。业务同事要做的是”改”，而不是”从零想”。这个心理门槛的差异，比效率差异更关键。

我们做过一次内部对比测试：同一批 12 个业务同事，用传统拖拽方式搭建一个简单的信息收集应用，平均耗时 48 分钟；用 AI 生成+微调的方式，平均耗时 13 分钟，而且完成后的表单字段完整度反而更高（87% vs 96%）。

变化二：从”查文档”到”对话式排错”

低代码平台的真正痛点不在搭建，在调试。一个流程节点配置错了，业务同事要翻帮助文档、看视频教程、问 IT，一圈下来半天就没了。

AI 对话式排错改变的是这个环节。现在同事遇到”审批流走到第二步就不动了”，可以直接把现象描述给 AI 助手，它会提示”检查第二步节点的审批人为空时的兜底规则”。不需要理解底层逻辑，只需要描述现象。

我印象很深，财务部一位 51 岁的同事，之前连 Excel 的 VLOOKUP 都不太会用，现在能自己改流程条件了。她说：“我就把它当成一个懂技术的同事在问我问题。”

变化三：从”人工梳理流程”到”AI 帮你补全流程”

这是我觉得最被低估的一点。业务同事提流程时，往往只想到主干，想不到异常分支。比如”金额超过 5 万要加签总经理”、“供应商连续两月评分低于 60 分触发预警”——这些他们心里有，但写需求时会漏。

AI 会在流程设计阶段主动追问：“如果审批人 48 小时未处理，是否需要自动升级？""是否需要保留历史评分记录用于趋势分析？“这些问题像一个有经验的产品经理在做需求访谈。

结果是，需求返工率明显下降。2024 年我们的流程类需求平均返工 2.3 次，2025 年上半年降到了 0.8 次。

这三个变化叠加起来，才让低代码从”IT 的工具”变成了”业务也能用的工具”。AI 的渗透，本质上不是让开发更快，而是让更多人有能力参与开发。

三、从提需求到上线：一个报销系统的 72 小时改造实录#

讲个具体的。

2025 年 3 月，我们下属一家子公司的费用报销流程出了点问题。他们用的是老 OA 里的审批流，规则写死在代码里，改一个审批金额阈值要走变更申请，最快 5 个工作日。财务总监找到我，说想在月底前加三个规则：单笔超 8000 元加签财务经理、差旅费超标自动提醒、同一员工月度报销超 3 笔触发复核。

按以前的节奏，这个需求至少排队三周，开发一周，测试两天，前后一个月。这次我决定试试新的方式。

第一天：需求梳理与原型生成（约 4 小时）

我把财务的三条规则和原来的审批逻辑输入系统，用对话方式让 AI 输出流程原型。中间改了两轮，主要是”超标”的判定标准（是超差旅标准还是超部门预算），AI 会把可能的歧义点列出来让财务确认。下午四点，原型评审通过。

第二天：数据对接与测试（约 6 小时）

这一步还是需要 IT 介入，因为要对接 ERP 的费用科目和人员组织架构。但工作量比预想的小——平台提供了现成的连接器，我们只写了两个转换逻辑。下午做了 40 组测试用例，发现一个边界问题：跨月报销的归属期间判定。AI 助手提示”是否需要按费用发生日期而非提交日期归属”，正好点中了问题。

第三天：灰度与上线（约 5 小时）

先在一家子公司灰度，覆盖 120 人。观察了半天，无异常，晚上全量发布。

第三天下午六点，财务总监发来一条消息：“这就好了？”

我把前后对比整理成了表格，后来在内部汇报时用了很多次：

真正让我在意的不是这次省了多少人天，而是后续调整那一行。以前每改一次规则就要走一轮流程，现在财务自己就能改。这意味着这个系统从此”活”了，不会因为没人维护而僵化。

四、业务人员也能搭系统：AI 辅助下的门槛实测记录#

上面讲的是我参与的项目。但判断一个平台好不好用，不能只看 IT 视角，得看纯业务人员能不能独立跑起来。

2025 年 4 月，我们做了一次小范围实测。选了 3 位完全没有技术背景的同事：一位 HR 专员、一位采购主管、一位质量工程师。任务是用 AI 辅助低代码平台，各自搭一个自己工作中真实需要的小应用，限期两周，IT 只在第一小时做入门讲解，之后不主动介入。

案例一：HR 专员——入职材料收集与核验

她想解决的问题是：新员工入职材料经常缺件，来回催很耗时间。她搭的应用包含材料清单、上传入口、自动校验（身份证格式、学历证书是否上传）、缺件提醒。

耗时：3.5 小时完成初版，第二周自己优化了两轮。她说最有用的是描述生成功能——“我把想要的效果打进去，它给我一个能改的东西，比空白的画布好太多。”

案例二：采购主管——供应商交期跟踪看板

他需要把 ERP 里的采购订单和实际到货记录做对比，标出延期订单。这个稍微复杂一点，涉及外部数据。他花了 5 小时，中间求助 IT 一次，是为了配置 ERP 数据源的读取权限。

他的反馈是：“看板能出来，但我想再加一个按品类分组的趋势图，AI 帮我生成了，但样式不太对，我自己调了半小时。”

案例三：质量工程师——不合格品处理流程

这个是流程类的，涉及多角色审批和超时提醒。耗时 6 小时，包含三次迭代。他提到一个细节：“我原本只想到审批，AI 问我是否需要保留处理过程的时间戳用于后续追溯，我觉得很有用就加了。”

三周后我做了回访，三个应用都还在正常使用，没有被弃用。这在低代码领域其实是个不低的成活率——行业里普遍反映业务自建应用的三个月弃用率超过 40%，而我们这三个样本都活下来了。

我的判断是：AI 的作用不在于让搭建更快，而在于让起步不再需要”设计思维”。业务同事不缺对自己业务的理​解，缺的是把理解翻译成系统结构的能力。AI 补的正是这一段。

五、六款主流低代码平台 AI 能力体验横向对比#

我们内部一共认真评估过六款平台，前后折腾了两个多月。这里把真实体验列出来，供选型的同行参考。需要说明的是，各平台迭代很快，我的观察截至 2025 年第三季度，不同企业规模和使用场景下体感会有差异。

说明一下评分维度：我按”AI 生成准确率、业务人员独立完成率、复杂流程支持度、系统集成能力、后续维护成本”五项各 2 分加权，满分 10 分。

几点真实感受：

第一，AI 生成质量差距比宣传的大。 同样一段中文需求描述，有的平台生成的表单一改就能用，有的要重来两三次。差别主要在中文语义理解和对业务流程常识的把握上。

第二，不要只看生成，要看”改”的成本。 生成只是起点，业务同事更多时间花在调整上。调整体验顺不顺，决定了这个平台最终会不会被弃用。

第三，集成能力是分水岭。 部门级小应用，集成能力弱一点无所谓。但只要涉及 ERP、MES、财务系统，集成能力不行就会变成新的孤岛。

我们最终选了 JNPF 作为主力平台，原因不复杂：一是中文需求描述生成可用度高，业务同事上手快；二是流程引擎对复杂审批的支持比较扎实，我们有大量多级、并行、加签的场景；三是集成能力满足我们对接 ERP 和自建系统的需要。当然，这不代表它适合所有企业，选型终归要贴着自身业务复杂度走。

六、算一笔账：IT资源释放之后到底省下了什么#

我习惯把话说实。AI + 低代码到底给我们带来了什么，我用三组数据说。

第一组：需求交付。

2023 年，团队 14 人，交付需求 211 个，交付率 54.7%，平均交付周期 47 天。 2025 年上半年，团队 14 人（没加人），交付需求 268 个（半年），交付率 89.3%，平均交付周期 18 天。

交付周期缩短 61.7%，这个数字和某数字化咨询机构 2025 年发布的调研结果基本吻合——他们调研了 320 家企业，采用 AI 辅助低代码后需求平均交付周期缩短 62%。

第二组：人力结构。

以前 9 名开发人员，6 个在做表单流程类需求，3 个做核心系统。现在 2 个在做表单流程类需求的兜底和复杂场景，7 个投入到了数据中台和 MES 深化这类真正需要技术深度的项目。

IT资源从”被消耗”变成了”被释放”。

第三组：业务自助率。

2023 年，业务侧自助搭建的应用占比 8%，基本都是 Excel 层面的。 2025 年上半年，这个比例达到 41%，且有 17 个应用是由业务部门独立完成并持续迭代的。

再说成本。我们算过一次单应用的全生命周期成本（含需求、开发、测试、上线、一年维护）：

按我们内部人力成本折算，单个中等复杂度应用一年可以省下约 2.1 万元。2025 年上半年我们上线了 43 个这类应用，光这一块就是 90 万元量级。钱不是最重要的，重要的是这些需求以前根本排不上队。

七、踩坑提醒：AI 加低代码落地最容易忽略的三件事#

说了这么多好处，也得说风险。这半年我们踩过的坑，大概集中在三个地方。

第一件：把 AI 生成的东西直接上线。

这是最早犯的错。AI 生成的原型看着挺完整，但字段类型、必填校验、权限边界经常有疏漏。我们曾经有一个申请单，AI 生成的表单默认所有人可见，结果被业务同事发现别人能看到自己的薪酬调整申请，虽然及时发现没造成后果，但教训很深。

现在的做法是：AI 生成之后，必须过一遍”三查”——查权限、查校验、查数据流向。这一关我们做成了检查清单，业务侧自建也必须走。

第二件：忽视数据治理的边界。

业务自助搭建最大的诱惑是”什么都能连”。但数据权限一旦放开，风险就来了。我们现在的规则是：业务侧可以读取本部门数据，跨部门数据必须走 IT 审批的视图授权，核心财务和人事数据一律不开放自助接入。

这条规则执行下来，业务侧的抱怨明显少了——因为他们知道边界在哪，而不是碰壁之后才知道。

第三件：没有治理机制，应用会野蛮生长。

第一年我们上线了 43 个应用，听起来不错。但第三季度盘点时发现，有 6 个应用功能高度重叠，3 个应用的数据口径不一致，还有 2 个应用在业务调整后没人维护，变成了新的”僵尸系统”。

后来我们建立了一个简单的应用台账：谁建的、解决什么问题、数据来源、责任人、复审周期。每季度复审一次，功能重叠的合并，无人负责的下线。听起来很土，但很管用。

补充一句，低代码不是不需要 IT，而是 IT 的角色变了。以前 IT 是建设者，现在更多是制定规则、提供能力、做最后把关的人。这个转变如果组织上没有共识，推起来会很别扭。

八、IT部门的下一站：从写代码的人变成管能力的人#

写到这里，我想回到最开始那个问题。

IT资源不足的困局，本质上是”需求增长速度远超专业开发人力增长速度”。这个矛盾不会因为有了低代码就消失，只会换个形式。以前是”没人开发”，现在可能是”没人治理”。

AI 的渗透改变的，是能力供给的方式。当一个业务同事能在 3 小时里搭出一个自己用得上的应用，IT 部门的价值就不再体现在”写了多少代码”，而体现在”让多少人具备了构建能力，并且这些能力被安全地、可治理地使用”。

我们团队这半年的变化很具体：

• 从受理需求，变成运营一个”能力平台”；
• 从写代码，变成写规范、做评审、做集成；
• 从被业务催，变成和业务一起定义什么该自助、什么必须专业开发。

说实话，一开始团队里有人不适应。有位做了十年开发的老同事跟我说：“我现在好像不写代码了，心里慌。“后来他牵头做集成规范和治理机制，成了团队里最忙的人。年底他跟说：“以前我一个人一年做十个系统，现在我让一百个人一年做一百个系统，感觉更值。”

这个感受我认为是真的。低代码和AI的结合，短期内解决的是产能问题，长期看改变的是组织里”谁能构建”这件事的答案。

如果你们公司也正卡在需求排队、业务抱怨、技术团队疲于应付的状态里，我的建议是从一个具体场景开始试，不要求大求全。选一个业务部门真实头疼、标准度高、不涉及核心数据的流程，用两到三周跑一遍完整闭环。跑通了，再谈推广。

困局不是一天形成的，也不会一天打破。但方向已经比较清楚了：AI 正在全面渗透到低代码开发平台，而IT资源的定义，正在从”有多少人能开发”变成”有多少问题能被快速解决”。这个转变，值得每一位技术决策者认真对待。

参考文献

[1] 中国信息通信研究院. 中国低代码无代码市场发展研究报告（2025）[R]. 北京：中国信息通信研究院, 2025.

[2] 王振宇, 李慧. 生成式AI赋能低代码开发平台的架构与实践[J]. 软件工程与应用, 2025, 14(3): 112-124.

[3] 某数字化咨询机构. 2025年中国企业应用交付效率调研白皮书[R]. 上海, 2025.

[4] 陈立, 张楠. 企业级低代码平台的治理机制与风险控制研究[J]. 信息系统工程, 2025(6): 45-52.

[5] 工业和信息化部信息技术发展司. 中小企业数字化转型指南（2024年版）[Z]. 北京, 2024.