一、从一个”需求排期表”说起：为什么转型需要新支点#

对恒睿精密制造的IT总监陈立来说，转型这件事在2024年之前一直卡在同一个地方：业务想要的东西太多，IT给得太慢。低代码平台的出现提供了一个新支点，而AI的加入，才真正让这个支点开始释放价值。

那是一个周五的下午，会议室白板上贴满了彩色便签，每一张代表一个待排期的需求。最上面一行写着”编号73”——这是当年累积的第73个需求，按当时的速度，最快也要排到三个月以后。

这不是恒睿一家的问题。恒睿精密制造做消费电子零部件，年营收约12亿元，员工1800人，IT团队14人，其中真正写代码的应用开发只有5个人。这5个人要支撑销售、采购、生产、仓储、财务、人力六个业务域的几乎所有系统需求。

“最难受的不是加班，“陈立后来回忆，“是业务同事看着你的眼神。他们不是不理解IT的难处，是等不起。”

当时的痛点非常具体：

• 需求排队时间长。一个供应商对账的小模块，走完需求评审、排期、开发、测试、上线，标准周期是45个工作日。
• 变更成本高。业务提了需求之后想调整字段，要走变更流程，等于重新排队。
• 反馈闭环慢。业务人员看不到进度，开发人员也不清楚业务真正的使用场景，双方靠文档和会议来对齐。
• 长尾需求被牺牲。真正重要的核心系统改造排不上，那些”只用三个月但确实需要”的小工具，干脆就不做了。

据中国信息通信研究院2025年发布的调研数据，国内中型企业IT部门的平均需求积压率约为 38.6%，也就是每10个提出的需求里有近4个长期得不到响应。这个数字背后，是大量被浪费的业务机会。

陈立算过一笔账：如果这73个需求里有一半能早点上线，按业务部门自己的估算，一年能省下的人力成本和沟通成本大约在 420万元 左右。

所以当团队提出”引入低代码平台、让业务人员也参与搭建”时，陈立是同意的，但他心里有疑虑：拖拽式开发听起来很美，真到了复杂场景能扛住吗？业务同事学得会吗？做出来的东西能不能接进现有系统？

2024年春天，恒睿开始试点。半年之后，他们又加上了平台的AI能力。陈立说，正是这次叠加，让整件事的性质变了——从”IT多了一个工具”，变成”整个组织换了一种工作方式”。

二、AI走进低代码：一线用户感知到的三重体验跃迁#

如果用一句话概括AI给低代码带来的变化，那就是：它把”会用工具”的门槛，降到了”会说需求”的门槛。

在恒睿的试点里，一线用户感知到的变化集中在三个层面，我把它叫做”三重跃迁”。

第一重：从”拖拽积木”到”说出想法”。

传统低代码的核心交互是拖拽：从组件库里拖一个表单、拖一个表格、拖一条流程线，再配置字段、设置校验、绑定数据源。对于有一定逻辑思维的业务人员，学会基本操作不难，但要搭出一个能用的应用，仍然需要理解”数据结构""主外键关系""流程节点”这些概念。

AI介入之后，入口变了。用户可以直接写一段话，“我要做一个供应商月度对账表，按月汇总每个供应商的采购金额、退货金额和应付余额，能导出Excel，财务和采购主管都能看”。平台会先生成数据模型建议，再生成页面和权限，用户只需要确认和微调。

第二重：从”改一处动一片”到”改哪里说清楚”。

有过低代码使用经验的人都知道，最难的不是从零搭，而是改。一个字段类型从文本改成枚举，可能牵动五六个页面、两条流程和一个报表。传统做法是逐个去找、逐个去改。

AI的做法是：用户描述”把供应商等级从文本改成下拉选择，选项是A/B/C三档，并且所有已填写的记录默认设为B”，平台会自动列出受影响的页面和流程，逐个执行并给出变更清单。据平台方提供的数据，这类变更的平均处理时间从原来的2.5小时缩短到11分钟。

第三重：从”上线即终点”到”运行中持续优化”。

这是最容易被忽视的一层。很多低代码项目的问题不在搭建，而在上线后的维护：字段填错率高、流程卡在某个人那里没人知道、某个页面加载慢。AI可以在运行期做数据质量提醒、异常流程预警和性能瓶颈定位。

恒睿上线半年后的统计显示，带AI辅助的应用，上线后缺陷率比纯人工搭建的低 62%，运维工单量下降 41%。

下面这张表是恒睿在不同阶段的体验对比：

对普通使用者来说，这些数字意味着什么？意味着当业务同事提出一个”临时想看看”的需求时，IT不用再说”下周给你排期”，而是可以回答”你先自己试着搭一个，我下午帮你看看”。

三、从”能拖拽”到”懂业务”：AI如何理解人的真实意图#

说一个恒睿的真实小故事。

采购部的周敏负责供应商管理，2024年6月她遇到一个麻烦：每月对账要花两天时间，原因是对账数据分散在ERP、邮件和一个Excel台账里。她把需求提给IT，得到的回复是”排在8月”。

试点低代码平台之后，IT给了她一个账号，说”你先试试，实在不行我们再上”。

周敏没用过任何开发工具。她在AI对话框里敲了一段话：

“我要一个供应商对账工具。每周一自动从ERP拉取上周的采购收货记录，按供应商汇总金额，和我上传的对账单做比对，差异超过500元的标红。采购员只能看自己负责的供应商，财务和采购主管能看全部。对比结果能导出。”

她后来描述当时的感觉：“我以为它会给我一堆报错，结果它先问我，‘你希望差异判定按含税金额还是不含税金额？‘——这个问题问得比我自己想得还细。”

这就是”懂业务”和”能拖拽”的分水岭。

传统低代码擅长的是”表达”——你有清晰的想法，它帮你快速实现。AI加持之后，平台开始承担一部分”理解”的工作：它会把模糊的自然语言拆解成数据实体、字段类型、权限角色、流程节点和校验规则，并在关键的分歧点上主动向用户确认。

具体来说，AI在需求理解上有四个动作：

1. 实体识别：把”供应商""对账单""采购记录”识别为数据对象，并推断它们之间的关联关系。
2. 规则抽取：把”差异超过500元标红""只能看自己负责的”转成可执行的校验与权限规则。
3. 歧义澄清：遇到没说清楚的地方主动提问，而不是自作主张。
4. 上下文补全：结合企业已有的数据字典和历史应用，复用已有字段命名和分类标准，避免出现”同一个客户在五个系统里有四种叫法”。

周敏最终用两个下午搭完了这个工具。她自己的估算是，每月节省对账工时约14小时，一年下来接近170小时。而IT团队总共只投入了大概3小时做最终审核和发布。

陈立对这个结果的评价挺克制：“它没有让采购部变成开发部门，但它让采购部第一次有能力把’我想要什么’说清楚，并且立刻看到结果。“

四、45天到9天：一个需求交付周期的完整复盘#

如果说前面讲的是体验，这一节我们看流程。

恒睿在2024年下半年调整了需求交付流程，并用一组数据跟踪了半年。下面是一个典型中等复杂度需求（跨两个业务域、涉及三个角色、含审批流）的完整复盘。

改造前的流程（平均45个工作日）：

1. 业务提需求 → 需求评审会（3天）
2. 需求文档撰写与确认（5天）
3. 排期等待（平均12天）
4. 开发（10天）
5. 测试（7天）
6. UAT与修复（5天）
7. 上线与观察（3天）

改造后的流程（平均9个工作日）：

1. 业务人员用AI生成原型，与IT共同确认（1天）
2. IT评估集成点与数据安全（1天）
3. 业务人员主体搭建 + AI辅助生成（2天）
4. IT做代码级审核与接口联调（2天）
5. 自动化测试 + AI回归检查（1天）
6. UAT与微调（1天）
7. 上线与观察（1天）

看起来只是把每个环节压缩了，但真正的变化在于责任主体的转移：过去业务和IT之间是”提需求—实现”的交接关系，现在变成了”业务主搭、IT把关”的协作关系。

陈立总结了三个关键经验：

第一，先划清楚什么该让业务做，什么必须IT做。

恒睿定了一条线：涉及核心交易数据写入、跨系统主数据变更、对外接口开放的需求，必须由IT主导；纯表单、纯查询、纯内部流程的需求，业务可以自主搭建，IT只做上线前审核。

第二，把”评审”改成”共创”。

以前的需求评审会，业务讲、IT记、会后写文档。现在改成”现场生成原型”：业务描述需求，AI实时生成页面，双方当场看着原型讨论。恒睿统计，采用这种方式后，需求返工率从31%降到9%。

第三，用AI守住质量下限。

业务人员搭的应用，最容易出问题的地方是数据校验和权限边界。恒睿的做法是开启平台的AI审查功能，在发布前自动检查：是否有未设校验的必填项、是否有越权的数据可见范围、是否有潜在的性能问题（比如一次加载上万条记录）。这套检查上线后，拦截了约 76% 的低级错误。

半年下来，恒睿的需求平均交付周期从 45个工作日降到9个工作日，积压需求从73个降到11个。陈立说，剩下的11个基本都是需要深度改造的老系统对接，本来就不该指望低代码解决。

五、遗留系统焕新：那些没人愿意碰的老系统怎么办#

几乎每家中型企业都有几个”没人愿意碰”的老系统：可能是十年前外包做的MES模块，可能是某个已经没人维护的报表工具，也可能是业务部门自己用Access攒出来的台账。

这些系统的共同特点是：业务离不开，IT不想动。

恒睿也有一堆。最典型的是一个2016年上线的生产报工系统，界面老旧，只能在IE里跑，数据库字段命名用的是拼音缩写，谁也说不清某个字段到底是什么意思。但车间每天都在用，改不动。

过去的做法只有两条路：要么整体替换，投入大、周期长、风险高；要么维持现状，忍受它。

AI+低代码给出的第三条路是**“外挂式焕新”**：不动老系统的核心，在它外面套一层新界面和新逻辑。

具体步骤是这样的：

第一步：用AI解析老系统的数据结构。

恒睿把老系统的表结构导出，交给平台的AI做解析。AI会基于字段名、数据分布和样本值，推测每个字段的业务含义，并给出一份”可读版数据字典”。这一步原本需要开发人员花2-3天人工梳理，现在压缩到半天。

第二步：搭建新的交互层。

车间主任想要的是”手机上就能看当天各产线的报工进度，异常的直接标出来”。这部分用低代码搭建，读的是老系统的数据，写回也走老系统的接口，业务逻辑不变。

第三步：灰度切换。

新界面先给一个车间试用两周，没问题再推广。老系统继续保留，作为回退方案。

这个报工看板项目，从立项到全厂推广用了 16个工作日，投入2名IT人员和1名车间业务骨干。如果走整体替换的路子，陈立估计至少要6个月、预算在80万元以上。

“以前我们讨论老系统改造，第一反应是’多少钱、多长时间’。现在第一反应是’能不能先做个外壳试试’。“陈立说，这个心态的变化，比省下的钱更有价值。

需要提醒的是，外挂式焕新并不适用于所有场景。如果老系统的核心逻辑本身就错了，或者性能已经无法支撑业务量，那还是得做替换。判断标准很简单：问题是出在”用起来不舒服”，还是出在”算得不对、跑不动”。前者适合外挂，后者必须重构。

六、同一张桌子：产品、开发、业务协作方式的重构#

技术工具改变的是效率，协作方式改变的是组织的上限。

恒睿在推行AI+低代码的过程中，最大的阻力其实不在技术，而在角色认知。开发人员一开始的抵触很直接：“让业务自己搭，那要我们干嘛？”

半年之后，这5名开发人员的回答变了：“我们现在做的是以前没时间做的事。”

变化发生在三个方面。

第一，开发人员的角色从”实现者”变成”架构师和守门人”。

过去他们80%的时间在写增删改查，现在这部分工作大部分被业务人员和AI承担了。他们腾出来的时间用在三件事上：设计集成架构、制定数据标准和审核业务搭建的应用。

恒睿的开发组长徐鹏说：“以前我最怕业务说’随便做个小工具’，因为我知道那个’随便’最后会变成我的加班。现在我可以直接说，这个你自己搭，我给你一个数据视图，搭完我帮你审一遍。”

第二，业务人员从”提需求的人”变成”对结果负责的人”。

这个转变比想象中重要。周敏做供应商对账工具的时候，主动去梳理了对账规则里的三种例外情况——这些细节在过去的需求文档里从来不会写，因为写文档的人不承担使用后果。

第三，三方开始用同一套语言沟通。

以前开会，业务说”我想要一个能看数据的页面”，开发说”你要的是列表页还是仪表盘”，来回好几轮。现在直接在平台上生成一个原型，指着说”这里改一下”。

恒睿内部做过一次匿名调研，让业务和IT两个团队分别给协作效率打分（满分10分）：

• 2023年：IT打 5.6分，业务打 4.8分
• 2025年上半年：IT打 8.4分，业务打 8.9分

陈立提醒说，这个分数不代表矛盾消失了。“业务现在会跑来跟我说，‘这个我自己搭了，你帮我看下权限对不对’。这种对话以前是不会有的，因为以前他们根本不知道权限是什么。现在他们知道了，这是好事，但也意味着IT要花时间做解释和培训。“

七、规模化之后的隐忧：治理、安全与可控性#

试点阶段一切都很美好，一旦铺开到全公司，问题就来了。

恒睿在2025年初把平台推广到全部六个业务域，用户数从40人涨到310人。三个月内，平台上出现了 460多个应用。这时候陈立开始睡不好觉了。

他担心的三件事，也是几乎所有技术决策者在规模化阶段都会遇到的：

第一，权限与数据边界。

业务人员搭建应用时，最容易犯的错是”把该隐藏的字段暴露出去了”。比如一个成本查询页面，本来只应该给到经理级，结果权限设置成了”所有登录用户可见”。

恒睿的应对是把权限管理从应用层上收到平台层，用统一的角色中心来管理。AI在应用发布前会做一次权限扫描，对”高敏感字段 + 大范围可见”的组合强制拦截，必须由IT人工确认才能发布。

第二，应用生命周期管理。

460个应用里，有多少是真正在用的？恒睿做了一次盘点，发现有 17% 的应用超过60天无人访问，其中有相当一部分是”搭了一半就放弃了”的。

他们后来建立了三条规则：应用必须指定负责人；连续90天无人访问的自动归档；关键应用必须配置监控和告警。

第三，平台的可靠性与可迁移性。

这是最容易被低估的风险。业务把重要流程跑在低代码平台上，一旦平台出问题，业务就停了。

恒睿的做法包括：核心数据保留在自有数据库中，不存到平台的私有存储；关键应用的重要流程保留日志导出能力；在合同里明确数据导出格式和迁移支持条款。

据一份2025年的行业调研，在规模化使用低代码的企业中，约有 44% 曾因治理缺失而出现过数据可见范围失控的问题。 这个比例不低，值得警惕。

陈立的建议很朴素：“试点的时候看的是能不能做出来，规模化的时候看的是能不能管得住。这两件事需要的能力完全不一样，最好在推广之前就把治理规则定下来，而不是出了问题再补。“

八、算一笔账：低代码+AI究竟释放了多少价值#

技术决策者最终要回答的问题是：值不值得。

恒睿做了一份三年期的成本效益测算，把传统开发、纯低代码、AI+低代码三种模式放在一起比较。

从表格看，AI+低代码的三年综合成本比传统开发低约 34%，比纯低代码低约 11%。这个差距不算惊人，因为平台费用本身抵消了一部分人力节省。

真正拉开差距的是”可交付需求数”：从约120个到约410个，是3.4倍的差距。

这个差距的意义不在于”IT做了更多活”，而在于那些原本因为成本太高而被放弃的需求，现在有机会被满足。恒睿在这三年里多做的近300个需求，大部分是以前根本不会立项的”小工具”——设备点检表、员工技能矩阵、客户拜访记录、样品借还登记。

陈立认为，这些”小需求”的价值很难直接算成钱，但它们决定了数字化能不能真正渗透到日常工作中。“转型如果只做了几个大系统，那是信息化；只有渗透到每个岗位的日常操作里，才叫转型。”

另外两个不容易量化的收益：

• 业务响应速度。市场变化的时候，业务可以自己快速调整工具，不用等IT排期。恒睿的销售部门在2025年调整过三次报价审批流程，全部由业务侧自主完成。
• 人才结构优化。IT团队没有再扩编，但交付能力提升了。开发人员的工作内容从重复编码转向架构设计和数据治理，人员流失率从18%降到7%。

九、选型避坑：技术决策者必须追问的六个问题#

如果你正在评估AI+低代码平台，下面这六个问题建议在POC阶段就当面问清楚。

问题一：AI生成的结果，可解释吗？

有些平台的AI是”黑箱”：你描述需求，它生成页面，但生成的逻辑是什么、数据怎么存、权限怎么设，说不清楚。这在试点时没关系，在规模化时会成为灾难。

判断方法：让供应商现场演示一个中等复杂度的需求，要求它输出生成的数据模型和权限规则，看看能不能被人读懂和修改。

问题二：AI生成的应用，能不能脱离AI维护？

这是一个很实际的问题。AI生成的应用，如果后续修改必须依赖AI，那当AI理解错的时候，用户就没有退路。

判断方法：问清楚生成后的应用是否以标准模型、标准流程、标准代码的形式存在，能否人工直接编辑。

问题三：和企业现有系统的集成能力有多深？

低代码平台的价值很大程度上取决于它能不能接进现有系统。要问清楚：支持哪些数据源、支持哪些接口协议、有没有现成的ERP/CRM/MES连接器、双向同步怎么做、失败重试机制是什么。

问题四：权限模型能不能支撑复杂组织？

简单平台通常只有”管理员/普通用户”两级权限，这在多部门、多层级的企业里根本不够用。要问清楚：是否支持组织架构同步、是否支持字段级权限、是否支持数据行级权限、权限变更是否留痕。

问题五：数据存在哪里，能不能带走？

这关系到长期风险。要明确：业务数据存在平台数据库还是企业自有数据库；合同终止时数据以什么格式导出；应用配置能否导出为可迁移的格式。

问题六：规模化之后的成本曲线是什么样？

低代码平台常见的定价模式是按用户数、按应用数或按资源消耗。试点阶段几十个用户很便宜，铺开到几百人可能就不是一个数量级了。要提前把三年的人员规模规划拿出来，让供应商给出对应的报价区间。

陈立的最后一句建议是：“不要指望一个平台解决所有问题。想清楚哪些场景必须用它、哪些场景不该用它，比选哪个平台更重要。”

回到开头。

恒睿的故事没有惊天动地的转折，它只是把一件件小事做得更快了一点：需求从45天到9天，表单从2周到4小时，老系统从”不敢动”到”先套个壳试试”。

但正是这些看起来不起眼的变化，构成了转型的真实质地。低代码提供了新支点，AI让它释放价值的方式从”省人力”变成了”扩能力”——让更多人有能力把想法变成可用的东西。

如果你所在的企业也卡在”需求永远排不完”的循环里，不妨从一个小场景开始试：找一个业务同事，给他一个账号，让他描述一个他真正需要的小工具，看看会发生什么。

很多时候，转型的起点并不宏大，它只是某个人第一次发现，自己不用再等三个月了。