一、IT 部门的排期表，为什么永远排不满也排不完#

过去两年，我所在的 IT 部门一直在跟一种慢性病打交道：资源紧张。直到我们把 AI 和 低代码 引入日常交付流程，才第一次真正看见释放组织内部数字化潜能的可能性——不是靠加人，也不是靠加班，而是靠改变”谁来做、怎么做”这件事本身。

先交代一下背景。我负责一家装备制造企业的数字化工作，公司约 3,700 名员工，IT 团队 21 个人，其中真正写代码的 13 个，剩下的是运维、网络、报表和实施。这个规模在制造业里不算小，但也不算宽裕。

2023 年底，我做了一次需求盘点，结果让人不太舒服：

• 需求池里挂着 168 个未交付需求，其中 61 个已经挂了超过 3 个月；
• 需求平均交付周期 51 天，从业务提出到上线；
• IT 团队每周投入在”改报表、加字段、调审批流”这类事务上的时间，占到总工时的 约 55%；
• 全年离职 3 人，招聘周期平均 4 个月。

这组数字背后是一个很典型的困局：业务部门觉得 IT 慢，IT 觉得业务需求碎，两边都委屈，但谁也没错。真正的问题在于，我们把所有数字化需求都塞进了一条单一的、由专业开发者把守的通道里。通道的通行能力是固定的，而需求是无限增长的。

资源紧张的本质，不是人不够，而是通道太窄。

那段时间我常跟团队说一句话：我们不是在做数字化，我们是在做需求排队管理。而排队这件事，一旦成为组织常态，最危险的不是慢，是业务部门会逐渐放弃提需求——他们绕开 IT，去用 Excel、用个人网盘、用各种影子系统。等到你发现的时候，数据已经散落在几十个版本里了。

所以当我第一次认真研究 AI 低代码平台时，我关注的不是”能不能拖拽出表单”这种功能层面的东西，而是一个更根本的问题：它能不能把这条单通道，变成多通道?

这篇文章，就是我带着这个问题做了半年实践之后的一份体验记录。我会尽量把踩过的坑、看走眼的地方和真正有价值的发现都写出来，因为选型这件事，最怕的就是只看到演示环境里的漂亮界面。

二、47 天的等待：一个业务需求走过的漫长旅程#

要理解 AI 低代码带来了什么改变，得先看清传统的路有多长。我拿一个真实案例来拆——生产部要做一个”设备点检异常闭环管理”的功能，需求本身并不复杂：点检员用手机拍异常、上传照片、选择异常等级、自动通知对应责任人、责任人处理完回填、超时未处理自动升级提醒。

这个需求从提出到上线，走了 47 天。我用时间线把它拆开：

47 天里，真正写代码的时间只有 14 天，占 30%。

剩下 70% 的时间，消耗在沟通、等待、确认和协调上。这不是我们团队效率低，而是所有走瀑布式流程的内部系统建设都会遇到的通病。更麻烦的是，这个需求上线之后，生产部又提了 3 次调整：加一个”班组”维度、异常等级从三级改成四级、导出的报表要按周汇总。每一次调整，都要再走一遍 5 到 10 天的循环。

我印象很深的是有一次开周会，生产部经理半开玩笑地说：“陈工，我这个需求提了两个月，等上线的时候，我们车间的管理方式都变了。”

这句话让我挺难受的。因为他说的是事实。当交付速度慢于业务变化速度时，数字化本身就在制造新的问题。

后来我们复盘这条流程时发现一个规律：这 47 天里，业务方真正需要”确认”的环节只有 3 个——原型确认、测试验收、上线验收。其余时间他们都在等待。而 IT 团队呢？也不是闲着，而是在不同的项目之间来回切换，每次切换都有上下文恢复成本。

据一家咨询机构在 2024 年发布的调研数据，中型企业内部系统的平均需求交付周期为 45 至 60 天，其中 68% 的受访 IT 负责人 承认”需求积压已经影响到业务部门的信任度”。我们不是特例，我们是主流。

所以当有人问我”AI 低代码到底解决了什么问题”，我的回答通常是：它没有让代码写得飞快，它砍掉的是那 70% 的等待和协调。

三、AI 低代码改变了什么：从”写代码”到”说清楚要什么”#

如果只用一句话概括我在这个过程中最大的认知转变，那就是：过去我们花力气的是”怎么实现”，现在我更关心”怎么表达”。

传统低代码平台解决的是”实现”环节的效率问题——把写代码变成配表单、拖流程、配规则。这确实快，但有个前提：你得先知道要配什么。而这个”知道”，恰恰是过去 70% 时间消耗的地方。业务方说不清，IT 听不懂，最后靠原型图和反复沟通来对齐。

AI 能力的引入，改变的是这个前置环节。

我举一个具体的体验对比。还是设备点检那个需求，如果放到现在的流程里，我做的事是这样的：在平台的 AI 对话框里，我把生产部经理的原话敲进去——“点检员发现设备异常要拍照上报，按严重程度分四级，一级要立刻通知车间主任和设备科长，超过 2 小时没人处理就往上推一级，处理完要回填原因。”

大概 40 秒后，系统给出了一份结构化的需求描述：数据实体（点检记录、异常单、处理记录）、字段清单（含类型和必填校验）、状态流转图、通知规则、角色权限建议。我要做的是逐条勾选”对/不对/要改”，而不是从零画起。

这个变化听起来不大，但体验差异非常明显：

以前： 业务说一遍 → 我记录 → 我翻译成技术语言 → 画原型 → 给业务看 → 业务说”不是这个意思” → 重来。平均 2.5 轮，耗时 5 到 8 天。

现在： 业务说一遍 → AI 生成结构化方案 → 我带着方案和业务一起过一遍 → 当场改。平均 1.2 轮，耗时 1 到 2 天。

需求澄清阶段的耗时，我们实测 下降了约 72%。

更重要的是，生成出来的不只是文档，而是可以直接运行的原型。业务方能在手机上点、能填数据、能看到流程跑起来的样子。这种”所见即所得”的确认方式，比看原型图有效太多了——因为大多数业务人员并不擅长把纸质原型想象成真实系统。

在技术侧，AI 低代码带来的另一个体验提升是集成配置。我们的核心系统是 ERP 和 MES，新应用几乎都要跟它们打通。过去配一个接口，要写中间层、定义数据映射、处理异常，一个接口平均 1.5 天。现在通过 AI 辅助的字段映射建议，加上预置的连接器，同样的工作 缩短到 3 至 4 小时，而且会自动生成异常处理逻辑的初稿。

当然，AI 不是万能的。复杂的状态机、跨系统的数据一致性、高并发下的性能问题，仍然需要专业开发者介入。AI 低代码真正擅长的，是把”业务逻辑相对清晰、数据模型中等复杂”的那 60% 到 70% 的需求，从专业开发者的手里解放出来。 这恰好也是企业内部需求中占比最大的部分。

四、业务人员的第一次搭建：从提需求的人变成做东西的人#

如果说 AI 解决的是”表达”问题，那低代码解决的是”归属”问题——让业务人员自己动手，而不是永远当需求方。

这里我要讲一个具体的人。我们质量部的李工，45 岁，干了十几年质量管理，Excel 用得极熟，但从来没写过一行代码。2024 年 3 月，她找到我，说想做一个”供应商来料异常跟踪表”，但这次她加了一句：“你能不能教我自己做？我不想再等排期了。”

我当时有点犹豫。倒不是担心平台学不会，而是担心她做出来的东西没人维护，最后又回到 IT 手里。但试了之后，结果比我预想的好。

她花了 两个下午（大概 7 小时），在平台上搭出了第一版：来料异常登记、责任判定、整改措施、关闭确认，四个环节，带附件上传和超期提醒。整个过程她遇到问题就在 AI 对话框里问，比如”怎么让超过了 7 天还没关闭的单子自动标红”，系统会告诉她配置路径，甚至直接生成规则表达式。

第三版上线后跑了 4 个月，累计处理了 620 多条 异常记录。她自己又加了两个视图：按供应商统计异常率、按月份统计闭环时长。这两个报表以前要走 IT 排期，现在她半小时做完。

我印象最深的是她后来说的一句话：“以前我是提需求的人，现在我是做东西的人。感觉不一样。”

这个”感觉不一样”，其实指向一个很关键的组织变化：数字化不再是 IT 部门的专属职能，而开始变成一种岗位能力。 当业务人员能自己解决 70% 的小需求时，剩下的 30% 复杂需求才有机会被认真对待。

当然，这件事不能无序放开。我们做配套做了三件事：

第一，划边界。 明确了哪类应用可以业务侧自建：单一部门使用、不涉及核心主数据写入、不涉及跨系统强事务、并发用户 100 人以下。超出边界的，必须走 IT 评审。

第二，建护栏。 平台侧统一配置了数据权限模板、脱敏规则和审计日志，业务人员搭建时不能绕过。这一点很重要——自助不等于失控。

第三，设”数字伙伴”。 IT 团队抽出 2 个人，不做开发，专门做辅导和审核。业务人员提交应用后，他们在 1 个工作日内完成合规检查并给反馈。

这套机制跑了半年，业务侧累计搭建了 43 个应用，其中 38 个至今在正常使用，5 个因为业务调整被下线。IT 团队的事后返工率控制在 12% 以内，比我最初担心的要低得多。

五、把重复需求”下放”：IT 团队产能的结构性重分配#

前面讲的都是”业务侧变快了”，但对技术决策者来说，更值得关心的问题是：IT 团队的时间去哪了？

我把 2023 年（引入前）和 2024 年下半年（引入后）的 IT 团队工时分布做了一次对比，数据来自我们的项目管理系统，按人天统计：

这张表里最关键的不是”重复性开发下降 27 个百分点”，而是新增的 11% 辅导评审时间，换回了 16 个百分点的核心系统建设产能。

打个比方。过去 IT 团队像一家只有一个窗口的银行，所有业务无论大小都要排队。现在开了自助区，简单的存取款自己去办，柜员腾出手来处理贷款、对公、风控这些真正需要专业能力的事。

具体到项目上，这个变化很直观。2024 年下半年，我们终于启动了拖了两年的 MES 与 ERP 主数据治理项目，还完成了仓储条码系统的重构。这两个项目如果在 2023 年提，我的回答只能是”没人”。

从组织效能角度看，这实际上是释放了一种被长期压抑的产能。它不是通过压缩工时或者增加人手实现的，而是通过重新划分”什么由谁做”实现的。

我在给管理层的汇报里用了一个更直白的说法：我们不是让 IT 做更多的事，而是让 IT 做更该由 IT 做的事。

同期，需求交付的总体表现也发生了变化：

• 需求平均交付周期：51 天 → 12 天
• 需求池积压数量：168 个 → 53 个
• 业务部门对 IT 的满意度评分（年度内部调研，10 分制）：6.4 → 8.7
• 全年交付的应用数量：31 个 → 96 个（其中 43 个来自业务侧自建）

需要说明的是，96 个这个数字里有相当一部分是”小而快”的应用，单个价值不如过去的大型项目。但它们的加总价值，以及它们带来的响应速度提升，对业务部门的感受是决定性的。

六、上线半年的复盘：三组数据与两个意外收获#

半年之后，我做了一次相对系统的复盘。前面已经讲了产能和交付的数据，这里补充三组更细的观察，以及两个我一开始没预料到的收获。

第一组：需求质量的变化。

引入 AI 辅助需求澄清后，我们统计了需求变更率（上线后 30 天内提出的修改请求占比）。之前的基线是 34%，现在是 19%。原因不难理解——业务方在搭建阶段就参与了，很多原本会在上线后才暴露的问题提前暴露了。

第二组：业务侧应用的存活率。

业务人员自建的 43 个应用中，运行超过 6 个月仍在使用的有 38 个，存活率 88.4%。这个数字超出我的预期，因为我原本判断”业务自建的应用容易变成一次性的玩具”。后来分析原因，主要是我们坚持了两条：一是必须由业务负责人本人提出、本人搭建，二是必须有明确的使用者名单，不做”先建了再说”的事。

第三组：IT 团队的流失意愿。

这个数据比较软，来自我们内部的一次匿名问卷。2023 年，团队中有 5 人 表示”考虑过一年内换工作”，主要原因是”重复劳动多、成长感弱”。2024 年底这个数字降到了 2 人，且都集中在薪资因素而非工作内容因素。对一个 21 人的团队来说，这个变化意味着每年可能省下 2 到 3 个人的招聘和磨合成本。

意外收获一：数据质量变好了。

这一点完全没想到。因为业务人员自己搭建应用时，必须明确定义字段含义和取值规则，他们对数据的理解反而比过去”甩给 IT 一句话”时更清晰。质量部、生产部自建的应用里，字段命名规范度明显高于我们过去从需求单里翻译出来的版本。

意外收获二：跨部门协作有了新话题。

有段时间我发现，生产部和仓储部的人会互相看对方搭的应用，然后回来提”我们能不能也这样”。这种自下而上的扩散，比 IT 部门自上而下推数字化要有效得多。我们后来干脆办了一个内部的”应用分享会”，每季度一次，让业务人员自己上台讲。第一次来了 30 多人，第二次 50 多人，会议室不够坐。

当然，也有做得不好的地方。比如早期我们放松了对应用数量的关注，导致有几个部门为了”凑数”搭了一些几乎没人用的东西，后来做了清理。现在我更关注的是”有效应用数”和”月活使用者数”这两个指标，而不是搭建总量。

七、选型避坑：技术决策者最该先问清楚的六个问题#

这一节是写给同行看的。如果你是技术选型的决策者，我建议在演示环节之前，先把下面六个问题搞清楚。这些问题比”支持多少种控件”重要得多。

问题一：AI 能力是做在需求表达层，还是只做在代码生成层？

很多平台的 AI 是”帮你写代码”，这解决的是开发者效率问题；我希望的是”帮业务说清楚要什么”，解决的是沟通效率问题。两者的价值量级不一样。判断方法很简单：让销售用一段业务人员的口语化描述去生成方案，看输出质量。

问题二：平台能不能与现有系统做双向的数据读写，而不只是单向上报？

单向容易，双向难。内部系统建设里大量需求是”读主数据 + 写业务数据 + 触发下游流程”，如果平台只能读不能写，那么一大半场景就用不上。我们当时的一个重要评估维度就是：能否在不写代码的前提下，完成对 ERP 的写操作并保证事务一致性。

问题三：权限和数据隔离是怎么设计的？

这个直接关系到能不能让业务人员自助。要看是否支持数据行级权限、字段级脱敏、操作审计、以及权限模板能否被非技术人员正确配置。如果权限配置必须由开发人员介入，那自助的边界就被锁死了。

问题四：私有化部署和信创适配的成本是多少？

制造企业往往对数据出域很敏感。要提前问清楚私有化部署的版本差异、硬件要求、升级方式和后续维护费用。有些平台在 SaaS 版本上功能完整，私有化版本会砍掉一部分能力，这个一定要在合同前确认。

问题五：应用搭多了以后，怎么治理？

问这个问题是为了避免三年后的一地鸡毛。要了解平台有没有应用清单、依赖关系图、废弃应用识别、统一入口和账号体系对接能力。我们后来把”应用数量超过 100 个时怎么管”作为了一个必答项。

问题六：业务人员的学习成本，实测是多少？

不要信”零门槛”这种说法。我建议的做法是：要求厂商提供一次面向真实业务人员的现场试训，找 5 个不同部门的、Excel 熟练但不会编程的人，看他们多久能独立搭出一个带流程和报表的应用。我们的实测数据是：首次上手 1.5 小时能完成简单表单，7 小时左右能独立完成一个带流程的小应用。

这六个问题问下来，基本能筛掉大部分演示很漂亮但落地会难受的产品。顺便说一句，我建议决策者本人也去动手搭一次，哪怕只做一个最简单的审批流。自己的手感受到的东西，比听十场演示都可靠。

八、从工具到能力：释放数字化潜能的三步走路径#

写到这里，我想回到最开始的那个判断：资源紧张的本质，是通道太窄。

AI 低代码带来的改变，表面上是工具层面的——需求澄清快了、业务能自己搭了、IT 的重复劳动少了。但在我看来，它真正改变的是一件更底层的事：它把数字化这件事，从 IT 部门的一个专业职能，变成了组织的一种通用能力。

这种转变需要分三步走，我们走了半年，大致走完了前两步半。

第一步：让 IT 团队先受益。

不要一上来就推业务侧自助。先让 IT 团队自己用起来，用 AI 低代码承接那些中小型需求，把交付周期打下来。这一步的目的是建立内部信心和最佳实践。我们这一步花了约 2 个月，IT 团队自己搭了 11 个应用。

第二步：选对人，开小口。

从业务部门里挑 3 到 5 个”Excel 高手 + 业务理解深 + 愿意折腾”的人，作为第一批种子。给他们配一个 IT 侧的对接人，做出 5 到 10 个能用的应用。这一步的目标不是数量，而是示范效应。我们这一步花了 3 个月。

第三步：建机制，做治理。

当业务侧搭建开始扩散时，必须同步建立边界规则、审核流程、命名和权限规范、以及定期的应用盘点机制。这一步没有捷径，也不适合事后补。我们是在第 4 个月开始补的，坦白说有点晚，清理了一批早期的不规范应用。

这三步走完，你会发现一个有意思的现象：IT 部门从”交付中心”变成了”能力中心”。 前者靠人头堆产出，后者靠机制放大产出。对 21 个人的团队来说，后者的天花板高得多。

回到数据上。半年时间，我们的需求交付周期从 51 天降到 12 天，需求池积压从 168 个降到 53 个，业务侧累计自建 43 个应用，IT 团队 27 个百分点的重复性产能被释放出来，投向了核心系统建设。这些数字背后，是业务部门重新愿意提需求了，是 IT 团队不再天天做救火队，是数字化第一次有了”自生长”的迹象。

当然，这条路不是没有代价。前两个月我花了大量时间做内部沟通，解释”为什么让业务自己搭不是甩锅”，处理了至少 3 次因为边界不清导致的返工。AI 低代码也不是银弹，复杂系统建设、数据治理、架构演进这些事，仍然需要专业的人扎扎实实地做。

但如果你问我，在资源紧张成为常态的今天，企业最该做的第一件事是什么，我的答案会是：先把那条单通道，改成多通道。 让 AI 承担表达的翻译工作，让低代码承担实现的标准化工作，让业务人员承担贴近场景的建设工作，让专业开发者回到真正需要专业判断的地方。

释放数字化潜能，从来不是靠某一个工具，而是靠重新分配”谁来做、做什么、什么时候做”。 这大概是我这半年最实在的一点体会。

参考文献

[1] 中国信息通信研究院. 低代码与无代码开发平台能力评估方法[S]. 北京: 中国信息通信研究院云计算与大数据研究所. 2024.

[2] 王海涛, 李静. 生成式 AI 驱动的低代码开发范式演进研究[J]. 软件学报, 2025, 36(2): 415-432.

[3] Gartner. 企业低代码应用平台关键能力与市场指南[R]. Stamford: Gartner Research. 2024.

[4] 张明远. 数字化转型中的 IT 产能重构: 基于 120 家中型制造企业的实证分析[J]. 管理世界, 2024(9): 88-103.

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