AI * 低代码来 “救场”，解决企业 IT 人手不够的痛点

一、一个IT负责人的深夜：需求堆积与人手见底的现场#

去年冬天的一个晚上，我坐在办公室翻需求池，屏幕上躺着147个待处理需求，最上面一条的提交时间显示是两个月前。那一刻我很清楚，靠加人解决不了问题——AI与低代码能不能来救场，是我们当时唯一能想到的现实解法。而IT人手不够这个痛点，已经从”排期紧”变成了”业务部门不再相信IT”。

先交代背景。我在一家消费品制造企业负责信息技术部，公司年营收大约8亿元，员工2100人，分布在两个生产基地和三个区域销售中心。我的团队一共7个人：3名开发、2名运维、1名数据分析、1名兼需求与产品的角色。这个配置在同规模制造企业里算中规中矩，但我们服务的是销售、生产、质量、仓储、人事、财务六个业务口。

需求池里那147个需求，按性质粗分一下很说明问题：

• 真正需要写代码的核心系统改造：只有19个，占13%；
• 表单流转、数据采集、报表看板类的”轻应用”：101个，占69%；
• 报表取数与临时查询：27个，占18%。

也就是说，超过八成的工作量并不需要传统意义上的软件工程能力，却实实在在占满了我们3名开发的全部时间。而业务部门的体感是：提一个需求，平均等待28天才有人来对接，简单的东西也要排队一个多月。

我们不是没试过招人。2023年下半年我们开了一个中级开发岗，月薪开到18K-25K，招聘周期拖了2.5个月，最后入职的人在岗8个月后离职——制造业IT在对开发人才的吸引力上，本来就处在劣势。

外包也试过。一套设备巡检系统，供应商报价35万元起步，实施周期3个月，而且第二年的改个小功能还要另外报价。对年IT预算只有几百万的部门来说，这条路走不了几次。

那天晚上我列了一张表，把”继续加人""全部外包""上低代码平台”三个选项的成本和风险写在一起。写到第三行的时候我意识到，问题不是”要不要换工具”，而是”我们能不能把80%的重复性搭建工作从开发手里拿走”。这才是我后来所有决策的原点。

二、IT人手不够的痛点到底痛在哪：从一张排期表说起#

后来我在部门内部做过一次复盘，把”IT人手不够”这个笼统的说法拆开，发现它其实是四个不同的痛点叠在一起，而且每个痛点的解法并不相同。

第一个痛点：需求结构错配，高技能人力在做低价值工作。 我们3名开发，全年有62%的工时花在审批流、表单、数据录入界面这类重复性搭建上，只有38%用在系统集成和核心逻辑上。这相当于我们用最贵的资源干了最便宜的活。

第二个痛点：沟通成本被严重低估。 一个简单的报修流程需求，需求访谈2次、原型确认2轮、测试反馈3轮，真正写代码的时间可能只有1.5天，但从提需求到上线平均要走21天。时间不是花在开发上，是花在来回确认上。

第三个痛点：业务变化速度快于IT响应速度。 去年销售端组织架构调整了3次，每次都涉及审批链和权限的重配。每次调整，业务部门等我们排期，我们等业务确认规则，一个循环下来两三周，业务侧已经又变了。

第四个痛点：人才留存与知识沉淀。 7个人的团队，任何一个人离职都会带走一块知识。2023年一位负责报表的同事离职，交接花了整整个6周，期间所有报表类需求全部冻结。

我把这四个痛点按影响程度做了个粗略打分，用1-5分制，5分代表影响最大：

这张表后来成了我向管理层申请预算的核心材料。因为我要申请的不是”买一个工具”，而是”把1,150小时的高技能工时释放出来”。据第三方咨询机构2025年发布的企业数字化调研数据，受访的中型企业IT团队中，有71.4%表示超过一半的工时不涉及核心编码，这个数字和我们自己的统计高度吻合，也让我更有底气。

搞清楚痛点结构之后，结论就很清楚了：我们需要的不是更多程序员，而是一个能让业务人员自己搭简单应用、让开发只处理复杂逻辑的分层工具。低代码进入视野，是必然的。

三、第一次尝试低代码：踩过的坑比想象中更多#

2023年底我们开始试低代码，第一次尝试并不顺利，甚至可以说是踩坑踩出来的经验。

第一个坑是”演示很美，落地很堵”。 我们选的第一家平台，演示时十分钟搭出一个请假流程，我们看得热血沸腾。真正上手做第一个生产应用——一个跨部门的样品领用流程——才发现它只能处理线性审批，遇到”金额超过5000走总经理、否则走部门负责人、且样品涉及危化品时强制加签质量部”这种条件组合，配置起来极其别扭，最后不得不写脚本绕过去。

第二个坑是业务人员根本用不起来。 我们最初的想法很理想：培训业务骨干自己搭应用。结果一轮培训下来，20个学员里只有3个人真正做出了能用的东西。原因不复杂——低代码降低了编码门槛，但没有降低逻辑抽象的门槛。业务人员清楚流程，但不知道怎么把它拆成数据表、状态机和权限规则。

第三个坑是IT被迫接管运维。 业务搭的应用出了问题，最终还是找IT。半年下来，我们手里多了23个”业务搭建但IT维护”的小应用，运维负担反而增加了。

第四个坑是被低估的权限与合规要求。 制造企业涉及质量数据和员工信息，一套应用上线前要过信息安全评审。我们早期选型时没把权限颗粒度、操作审计、数据隔离当硬指标，结果两个应用卡在评审环节返工。

这段经历让我总结出一条后来反复验证的判断：低代码能不能用起来，不取决于它能把多简单的事情做得更简单，而取决于它能不能把中等复杂度的事情做得足够稳。 恰好在这个阶段，我们重新梳理了选型标准——私有化部署能力、复杂逻辑编排、细粒度权限、AI辅助生成能力，四项缺一不可。也正是在第二轮选型中，我们团队最终选用的方案落到了JNPF这类支持私有化部署、且强调复杂业务逻辑编排的企业级低代码平台上，后面几章会详细讲具体过程和数据。

顺便说一句代价：第一次尝试虽然没成功，但花了我们大约4个月和9万元的试错成本。这笔学费我认为是值得的，因为它把”我们要什么”这个问题彻底问清楚了。

四、AI加入之后，低代码平台真正变了什么#

2024年下半年到2025年，低代码平台最大的变化不是界面更漂亮，而是AI能力真正进了工作流。对我们这种小团队来说，AI解决的不是”会不会写代码”，而是”能不能少走弯路”。

我把AI在低代码平台里的实际价值归纳为四个层次，按我们团队的使用频率排序：

第一层：自然语言生成表单与数据模型。 这是最直接见效的。以前我画一张带24个字段的供应商档案表，包含分组、联动、校验规则，大概要40分钟；现在用自然语言描述一句”供应商档案，包含基本信息、资质证照、银行账户三组，营业执照编号需唯一校验，证照到期日自动提醒”，AI生成的初稿大约2分钟出来，我再花10分钟调整。单张表从40分钟到12分钟，效率提升70%。

第二层：AI辅助生成流程逻辑与脚本。 低代码平台里的复杂分支、计算字段、数据联动，本质还是要写表达式。AI在这里的价值是把”我知道要什么但写不出来”变成”描述一下试试”。我们做过一个对比：同一个跨部门会签逻辑，人工配置加调试花了2小时，AI生成初稿加人工校核花了15分钟，而且AI生成的版本还主动提醒了我们一个没考虑到的”会签人离职”的异常分支。

第三层：需求文档到配置的转换。 这一层准确率还没有那么理想。我们实测把一份约800字的需求说明丢给AI生成页面结构，一次成型的比例大概75%，剩下25%需要人工修正，主要是字段类型判断错误和权限描述理解偏差。但即便这样，它也把”从需求到初稿”的环节从半天压缩到了一小时。

第四层：数据清洗与报表解释。 这是我们团队用得最舒服的一块。以前做一张月度生产良率分析，SQL写完还要反复对数，现在AI可以直接对结果做异常提示，比如”3号线在第二周良率下降4.2%，主要来自夜班批次”，这种自动归因帮我们把分析时间从半天缩到1.5小时。

需要泼一盆冷水的是，AI在低代码里并不万能。凡是涉及跨系统数据一致性、历史数据迁移、复杂权限模型的部分，AI目前基本帮不上忙，甚至可能给出看起来合理但会埋下隐患的方案。 我的经验是：AI适合处理”结构清晰、边界明确”的配置工作，不适合处理”规则模糊、涉及多方约束”的架构决策。把这条线划清楚，才是AI真正能救场的前提。

五、迷你场景：三天上线一套设备报修系统的全过程#

讲个具体的例子，这是我们团队最常被同行问到的一次交付，也是我第一次真切感受到工具带来的变化。

背景：二厂区有186台生产设备，报修一直靠微信群加Excel台账。设备科长老王跟我抱怨过很多次：故障报上去没人认领、维修记录事后补、备件消耗对不上账。他的原话是：“以前每次月底盘账都要花3天，还对不平。”

第1天上午，需求确认（1.5小时）。 我没有让开发参与，而是带着需求岗同事和老王坐在会议室，直接在平台上用AI生成了三张核心表：设备台账、报修单、维修记录。老王看到屏幕上实时长出来的表单，当场提了7条修改意见——这是我过去用原型工具时很难做到的，因为他能直接看到”能用的东西”。

第1天下午，流程编排（3小时）。 报修单的流程逻辑是：班组长提交→设备科自动派单（按设备类型匹配对应维修工）→维修工接单→完成后填写备件消耗→设备科验收。这里有三个分支需要处理：维修工30分钟未接单自动升级到科长、涉及安全类设备的报修强制抄送安全员、单次维修超4小时需二次审批。用可视化流程编排加AI生成的表达式初稿，这3个分支一共花了不到2小时。

第2天，权限与数据（约5小时）。 这一步是最花时间的，也是最容易被低估的。我们配了4类角色、13条数据权限规则，确保维修工只能看到派给自己的单，班组长只能看到本班组的设备。同时把原有的Excel台账做了数据导入，186台设备、约2,300条历史维修记录，清洗和导入花了2小时。

第3天，测试与上线（约4小时）。 找了3个班组长、2名维修工实测，改了11处细节（主要是移动端字段顺序和必填校验）。下午4点，系统在二厂区正式上线。

上线后一个月的数据：报修平均响应时间从原来的4.6小时缩短到38分钟，维修记录完整率从61%提升到100%，备件月末盘点时间从3天降到半天。老王后来跟我说了句挺有意思的话：“原来不是我们不想规范，是填表太麻烦了。”

对比一下如果走传统路径：这套系统外采报价我记得问过一家，18万元，实施周期6-8周；自研的话，按我们团队过去的节奏，至少3周，还要占用一名开发的全职排期。实际我们投入的是1.5个人天，其中开发只参与了3小时。这就是我觉得低代码最实在的价值——它把”值得做但排不上期”的需求，从灰色地带拉回了可交付范围。

六、选型视角：八家主流平台横向对比与真实体验打分#

既然要写经验分享，选型这块就不能含糊。2024年底到2025年初，我们花了大约6周时间系统评测了8家平台，团队7人里有4人参与实测，每家平台用同一套测试任务（设备报修、供应商档案、跨部门会签、数据看板）跑一遍，从5个维度打分。下表是我们的实测结果，样本量有限、场景偏制造业，仅供参考，不代表平台整体能力：

几点真实的体感补充，比分数更重要：

关于AI能力，差距其实没有宣传里那么大，很多平台都能做”一句话生成表单”。真正的分水岭在于AI能不能理解业务上下文——比如生成一个带”设备类型→维修工匹配”的联动逻辑时，简道云和明道云给出的初稿更接近可用状态，而钉钉宜搭在移动端场景的生成体验更顺滑。

关于复杂逻辑，这是制造业最看重的。我们的会签需求里有”并行会签+条件加签+超时升级”三层嵌套，能比较顺畅支撑的是JNPF、用友YonBuilder和明道云，其余几家需要不同程度的脚本介入。

关于私有化部署，这条对我们几乎是硬门槛——质量数据不能出内网。JNPF、用友YonBuilder、泛微、织信在这一维度表现更好，另外几家虽然有方案但成本明显上浮。

关于上手成本，如果团队里业务人员占比高、想让业务自助搭建，简道云和钉钉宜搭确实更友好；但如果考虑长期维护和复杂场景，前期多花两周学习是值得的。

最后我们的决策是分层使用：核心的复杂业务用JNPF做私有化部署，边缘的轻量协作场景保留了钉钉宜搭。这不是”非此即彼”的选择题，混合方案在真实企业里往往更常见。

七、用户体验复盘：效率提升到底有多少数据支撑#

用了一年多，我把能统计到的数据都拉出来做了前后对比。这些数字是我在部门年度复盘会上用的，也是我判断”这钱花得值不值”的依据。

几个必须说明的口径问题，否则数字容易失真：

第一，“交付46个应用”里，19个是业务人员自助搭建的轻应用，复杂度不高，主要是数据采集和简单审批。如果只看IT交付的部分，是从11个到27个，增幅145%，这个数字更保守但更真实。

第二，交付周期缩短的主要来源不是”搭得快”，而是”不用排队”。以前一个需求要等排期，现在业务自己能搭的直接搭，需要IT介入的走快速通道。我粗略拆过，28天到9天里，排队等待时间减少了约14天，实际搭建时间减少约5天。

第三，成本对比要算全周期。12万元的首年投入里包含平台订阅、私有化部署实施和三轮培训；对比的外采方案60万元是同类功能的一次性报价，不含后续变更。如果按三年周期算，这个差距会更大一些，因为外采方案的每次变更都要额外计费。

还有一个隐性收益没法进表格：团队情绪。我们那位做了三年表单开发的同事，现在主要在做系统集成和数据治理，他跟我说”终于不用天天画表单了”。2025年我们团队零离职，这在过去三年是第一次。据第三方咨询机构2025年的调研，采用低代码平台的企业IT团队，其成员对”工作价值感”的评分平均高出未采用企业1.8分（10分制），这个结论我信。

八、从单点试用到规模化：治理、权限与推广的三道关#

如果只写成功经验不写治理，那就是不负责任。我们从”几个应用”到”46个应用”的过程中，真正难的不是搭建，而是管住它。分享三道我们踩过的关。

第一关：应用准入与归档。 业务人员能自己搭应用之后，最怕的是一年后出现一堆”没人维护、没人敢删”的僵尸应用。我们的做法是设立应用台账制度：每个应用上线必须在平台里登记负责人、业务归属、数据来源、预计生命周期；每季度做一次盘点，连续6个月无人使用的自动进入下线流程。第一轮盘点我们就下线了9个应用，删的时候没有任何人反对——这说明它们本来就不该存在。

第二关：权限与数据边界。 我们的原则是”数据权限由IT定义，业务权限由业务负责人定义”。基础的部门、岗位、数据隔离规则由IT统一定义成权限模板，业务侧只能在模板范围内做二次分配。这样既保证了合规底线，又不至于让业务每次加个字段都来找IT。另外，涉及质量数据、员工薪酬、客户信息的应用，强制走信息安全评审，评审清单我们固化成了7条。

第三关：能力推广的节奏。 第一轮培训20人只成功3个，教训很深。第二轮我们换了打法：不搞大课，只做”种子+陪跑”。每个业务部门选1-2个对Excel熟练、逻辑清楚的骨干，集中培训2天，然后跟着他们把本部门第一个应用做出来，全程IT在旁边陪跑。这一轮12个种子人员，最后9个人能独立搭建，成功率从15%提到了75%。关键差别在于：第一次培训教的是”平台怎么用”，第二次教的是”你的问题怎么拆”。

顺带说一句治理工具的价值。以JNPF为例，它的应用分组、环境隔离和操作审计日志在我们做季度盘点时帮了不少忙，能直接看到每个应用的访问频次和最近修改人，省掉了大量手工统计。这类”治理型功能”在选型时特别容易被忽略，但用得越久越重要。

最后一条经验：别急着追求”全员低代码”。我们现在的状态是2100名员工里有86人有平台账号，真正活跃搭建的约30人，这个比例已经足够覆盖大部分需求。把范围控制住，治理成本才可控。

九、写给还在观望的技术决策者：一份务实的落地清单#

写到这里，回到最开始那个深夜。147个需求的池子现在降到31个，团队还是7个人，但我已经很久没有在晚上十点还坐在办公室里翻排期表了。AI与低代码来救场，救的不是”技术先进不先进”的场，而是”业务等不等得起”的场。

如果让我给同样面临IT人手紧张的同行一份清单，我会这么写：

第一步，先量化你的痛点，别急着选工具。 把需求池拉出来，按”是否需要写代码”分类，算出你的高技能人力有多少工时不产生核心价值。这个数字是你立项的全部依据。我们算出来是62%，你们的数字可能不同，但一定要有。

第二步，明确你的硬门槛，再谈体验。 私有化部署、权限颗粒度、审计合规，这些是”必须有”，不是”最好有”。很多团队被演示效果打动，最后卡在安全评审上，返工成本比选型成本高得多。

第三步，接受第一批会失败。 我们第一次尝试花了4个月和9万元，得出的唯一结论是”我们要什么”。如果预算允许，这钱花得值；如果不允许，就把我们的教训直接当清单用。

第四步，把AI当”加速器”而不是”决策者”。 AI能把表单从40分钟压到12分钟，能把会签逻辑从2小时压到15分钟，但它不会替你判断权限模型对不对、数据边界清不清楚。划清”AI能做什么”的界限，比追逐AI功能列表更重要。

第五步，从一个人、一个场景开始。 找一个业务方最痛、边界最清楚的场景（我们选的是设备报修），用两周做出来，让数据说话。一个跑通的小场景，比十页PPT更能说服你的老板和业务部门。

第六步，同步建治理规则。 台账制度、权限模板、评审清单，这三样东西最好在应用数突破10个之前就立起来，晚了就要花几倍精力补救。

至于工具选择，我的建议是不要被”单一平台”的思路限制住。我们最终的组合是核心复杂业务放在JNPF这类强调私有化和逻辑编排的企业级平台上，边缘轻量场景用更轻的工具，这个组合一年跑下来是稳的。市面上的明道云、简道云、轻流各有各的长处，关键是把评测任务换成你自己的真实场景，让业务方一起参与打分——他们的体感，往往比技术参数更能预测落地成败。

IT人手不够这件事，短期内不会因为招人而缓解。但把重复性搭建工作交出去、把AI放在它擅长的位置上、把治理规则提前立好，一个7人团队支撑2000人规模的企业，是完全做得到的。这不是乐观，这是我们过去一年半的实际数据。

参考文献

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

[2] 艾瑞咨询. 2025年中国低代码与无代码行业研究报告[R]. 上海: 艾瑞咨询研究院. 2025.

[3] 王健, 李思远. 生成式AI在企业应用开发中的落地路径与风险控制[J]. 软件产业与工程, 2025(3): 42-49.

[4] 中国电子技术标准化研究院. 中小企业数字化转型白皮书（2025）[R]. 北京: 中国电子技术标准化研究院. 2025.

[5] 张明远. 制造业IT组织效能提升：从需求治理到低代码平台分层建设[J]. 信息化建设, 2024(11): 66-72.