数字化内卷时代，低代码凭什么成为企业香饽饽？

一、从“需求排队三个月”说起：数字化内卷的真实体感#

去年10月的一次周会上，销售总监把一张截图投到大屏上：他的一个客户报价审批，在OA里卡了四天。不是审批人不批，是流程节点配置有误，要改一行代码——而这一行代码，排在我们开发排期的第37位。

那一刻我挺难堪的。我们信息化团队12个人，那年交付了68个需求，需求池里还积压着83个，平均交付周期47天，最长的等了将近三个月。这就是我理解的数字化内卷：投入在增加，系统越建越多，产出却越来越边际化，业务方的抱怨反而越来越具体。

内卷这个词这两年快被说烂了，但放在企业IT这个场景里，它有一个非常具体的形状：

• 需求侧在膨胀。业务部门尝到了数字化的甜头，提需求的速度远超交付速度，我们内部戏称“需求通胀”。
• 供给侧在打转。开发资源就那么多，80%的时间花在流程表单、审批流、数据看板这类重复度极高的应用上，真正涉及核心系统的架构改造，反而没人手。
• 价值感知在稀释。交付一个需求，业务方满意度只维持两周，因为两周后他们的业务又变了，系统跟不上。

我算过一笔账：那一年外包费用花了约190万元，交付的应用里有超过六成是表单+流程+报表的组合，技术含量不高，但极其耗人。团队里有经验的开发整天在做“搬砖活”，走了两个人，招聘周期平均4个月。

真正让我下决心改变的，是一次用户访谈。设备部的一位老师傅跟我说：“你们做的那个巡检系统，我在车间里用手机点开要等七八秒，还不如我那张纸质表快。我填完纸质表拍照发群里，班长汇总，也挺好。”

他说得没错。从用户视角看，一个不好用的系统，比没有系统更糟——它增加了一层负担，却没有减少任何工作量。这就是内卷在用户体验层面的终极表现：所有人都在忙，但没有人的体验变好了。

到了年底复盘，我给管理层写了一句结论：我们不是在建设数字化，我们是在维持一个不断漏水的数字化。要么换打法，要么加人——加人这条路，显然走不通。

二、一次彻夜的技术选型会：我们到底需要什么样的工具#

决定引入低代码平台，是在2024年12月的一次长达六小时的选型会上定下来的。参会的有我、两位资深开发、两位业务骨干，还有财务和IT安全的人。

会前我发了一份需求清单，会后被改了四版。最终收敛成六条硬性标准，我至今觉得这份清单比很多厂商的白皮书都实用：

1. 业务人员能不能自己改。这是核心诉求。我们要的不是把开发工作从Java换成拖拽，而是让业务方在需求变更时，不必再排期等我们。
2. 复杂流程能不能扛住。我们有多层级的合同评审、跨部门会签、带条件分支的采购审批，简单线性流程撑不住。
3. 能不能私有化部署。制造企业的生产数据、客户数据不上公有云，这是红线，没有商量余地。
4. 能不能连上老系统。我们有用了十年的ERP和一套自研MES，数据必须能打通，不能变成又一个孤岛。
5. 学习成本有多高。我们做过测算，如果业务人员上手需要超过三天培训，推广基本会失败——大家都很忙，没人愿意为工具额外付出。
6. 三年总拥有成本。不只看授权费，还要看实施、培训、后续维护和迁移成本。

这六条一摆出来，市面上很多“轻量级”产品就被筛掉了。有些平台拖拽体验极好，但流程引擎只能做串行审批，遇到条件分支就要写脚本；有些平台功能极全，但首次部署需要六周，学习曲线陡到业务人员直接放弃。

那天会议开到凌晨一点，最后的结论是：不追求功能最全，追求业务能自助。我们需要的不是一个更快的开发工具，而是一个让业务方从“提需求的人”变成“做应用的人”的载体。

后来我常跟同行说，选型会上最重要的不是问“你支持什么功能”，而是问“我们的业务人员能不能在没人教的情况下做出第一个应用”。前一个问题厂商都能答得很好，后一个问题得自己去看、去试、去让真实用户上手。

这个判断标准，直接决定了我们后面的测试方法——不是看演示，是拿真实场景做实测。

三、剥开概念看体验：低代码平台究竟在帮用户做什么#

坦白说，最初我对低代码是有偏见的。前几年接触过的产品，大多是“表单设计器+简单流程”，宣传时说得天花乱坠，真用起来，稍微复杂一点的需求就要写JS，最后还是开发兜底。

真正让我改变看法的，是从用户视角重新拆解了这件事：低代码到底替用户省掉了什么？

第一层，省掉的是“翻译成本”。 传统模式下，业务方说“我要一个能自动汇总各车间日报的看板”，需求分析师翻译成文档，开发翻译成数据模型和接口，中间任何一次理解偏差，都要返工。低代码把这三层压成一层：业务人员自己拖一个表格组件、连一个数据源、配一个汇总规则，所见即所得。我们做过统计，需求理解偏差导致的返工，占原来开发工时的约23%，这一块几乎被消除了。

第二层，省掉的是“等待成本”。 以前一个简单应用从提需求到上线平均21天，其中真正编码可能只有3天，其余时间都在排队、评审、测试排队。低代码平台把评审和测试的环节前置到了搭建过程里，业务方自己测、自己改，平均交付周期压到了5天左右。

第三层，省掉的是“试错成本”。 这一点最容易被忽略。以前业务方提需求是“一锤子买卖”，因为改一次成本太高，所以提需求时格外谨慎，宁可多要几个功能。低代码环境下，改一个字段、加一个审批节点，几分钟的事，业务方反而愿意先上线再迭代。我们内部把这种模式叫“小步试错”，试点部门的需求变更频率提高了3倍，但返工率下降了——因为改动都是小改，不是推倒重来。

这里要澄清一个常见误解：低代码不是让程序员失业，而是把程序员从重复劳动里解放出来。我们团队那位写了八年的Java工程师，现在主要做两件事——给低代码平台做数据接口和权限体系，以及处理那些确实需要编码的复杂逻辑。他自己的评价是：“以前是天天砌砖，现在是画图纸加偶尔搬重物。”

对企业来说，这才是低代码真正的价值：它改变的不是开发速度，而是需求流转的组织方式。当业务方有了自己动手的能力，IT部门的角色从“承接方”变成了“赋能方”，整个数字化的节奏就不一样了。

四、第一小时的印象：从注册到跑起第一个应用#

我一直认为，评价一个平台好不好，不看演示，看第一小时。

我们做了一轮小范围实测，规则很简单：找三位完全没有开发背景的业务同事（一位HR、一位采购、一位车间主管），每人一个真实小需求，看他们能多快跑出第一个可用应用。整个过程我只在旁边记录，不插手。

HR同事的需求：员工入职信息登记+自动通知IT开通账号。她的耗时是1小时20分钟——前40分钟在理解数据表怎么建，后面就顺了。她做的第一个版本漏了“试用期时长”字段，自己发现后加了两分钟改好。她的原话：“比Excel的透视表简单。”

采购同事的需求：供应商准入申请，要带三种不同分支（新供应商、老供应商新增品类、临时供应商）。这个稍微复杂，她用了2小时50分钟，中间卡在条件分支的配置上，看了平台自带的引导视频后解决。

车间主管的需求：设备点检记录，移动端填报，异常自动推送给维修组。他用了1小时45分钟，最惊喜的是移动端预览直接生成，不用单独适配。

三个应用，平均耗时不到2小时，全部在当天下午跑通了真实数据。这个结果超出了我的预期——我原本以为至少要两天培训。

当然，第一小时的美好不代表后面都顺利。真正上线时遇到的权限体系、数据量、并发问题，是另一回事，后面章节会讲。但**“能不能自己跑起来”这个门槛，决定了业务方愿不愿意继续用**。

这里补充一个细节，也是我们后来选型的关键依据：我们发现，那些上手快的平台，共同点是把“数据表”作为第一入口，而不是把“表单”或“流程”放第一。因为业务人员脑子里想的是“我要记哪些信息”，而不是“我要画什么流程”。这个交互设计的差异，直接决定了学习曲线。

试完三家平台之后，我们内部有个共识：第一小时的体验，比功能清单长十倍重要。

五、三个场景实测：工单、合同与设备巡检的落地细节#

试点跑了三个月，三个场景最有代表性。我把它们的过程和数据完整记下来，因为它们基本覆盖了制造企业最常见的三类需求。

六、五个维度的横向对比：我们打分的依据是什么#

试点期间我们同步对比了六个平台，评分依据全部来自我们自己的实测，不是厂商宣传。评分维度权重按我们的实际需求设定：上手体验30%、流程能力25%、数据集成20%、私有化部署15%、总成本10%。

需要说明的是，这个评分只代表我们这家制造企业的场景权重。如果是纯互联网团队，钉钉宜搭的分数会更高；如果是流程极简的零售场景，简道云可能更合适。没有最好的平台，只有最匹配的场景——这句话我在选型会上说了三遍。

还有一点值得提醒：很多对比表喜欢比“组件数量”“模板数量”，这个指标在实际使用中参考价值很低。我们统计过，试点期间用到的组件不超过18个，绝大多数需求是表单、列表、流程、报表这四五种的基础组合。真正拉开体验差距的，是改需求的灵活度和出问题时的排查效率，而不是功能有多少。

七、踩过的四个坑：低代码不是万能药的清醒认知#

写了这么多好处，必须说说坑。如果只讲好话，这篇记录就没有价值了。

坑一：把低代码当成“什么都能做”。

我们一开始想把一套带复杂排产算法的生产计划系统也用低代码搭，试了两周放弃了。低代码擅长的是数据采集、流程流转、报表呈现，涉及复杂算法、高并发、实时计算的场景，还是得回到代码。我们最后的划分原则是：流程表单类走低代码，核心算法类走自研，边界清清楚楚。

坑二：忽视了治理，应用野蛮生长。

三个月里业务方自发搭了23个应用，听起来很美，但我很快发现：同一个“客户名称”字段，在不同应用里有四种写法；三个人各建了一张“员工信息表”。这就是典型的应用碎片化。后来我们成立了小组，专门做数据字典统一和 app 目录管理，才算把局面稳住。低代码降低了建设门槛，也降低了混乱的门槛。

坑三：权限体系想当然。

第一次上线后，出现了一个部门的审批数据被另一个部门看到的情况。原因是业务方搭建时没意识到角色权限的继承关系，默认给了“全员可见”。我们后来补了一套权限模板，并且规定凡是涉及人事、财务、客户数据的应用，必须IT复核后才能发布。这条规矩到现在还在执行。

坑四：高估了业务方的持续热情。

试点期大家热情高涨，三个月后热度明显下降，因为搭建只是开始，维护和迭代才是长跑。我们的对策是每个部门培养一到两名“公民开发者”，给他们额外的激励和培训通道，让这件事有主。目前六个部门共有9名这样的骨干，撑起了日常迭代的七成工作量。

这四个坑，我觉得比任何功能清单都更有参考价值。低代码让企业数字化的门槛降下来了，但门槛降低不等于不需要方法——治理、边界、角色，一个都不能少。

八、算一笔投入产出的账：企业为什么愿意持续买单#

管理层最终批预算，靠的不是满意度评分，是一张表。

第一年投入：平台授权（约120个账号）+ 私有化部署实施 + 培训 + 内部人力投入，合计约48万元。

对照的替代方案：同样的需求如果走外包，按我们历史单价估算约180万元；如果走自研，需要增加3名开发，年人力成本约75万元，且交付周期不可控。

一年的实际产出：完成应用86个（含试点23个+后续63个），替代人工工时约4,200小时，简单应用平均交付周期从21天降至5.5天，需求满足率从41%升至78%。

按这个口径测算，投入回收周期约10个月。

这还没算那些不好量化的部分：业务方不再需要提前三个月排队，IT团队终于腾出手做ERP升级和数据中台，那位Java工程师说他“终于感觉自己像个工程师了”。

有一组行业数据可以对照：据某咨询机构2024年对国内200余家中型企业的调研，引入低代码平台后，简单业务应用的交付周期平均缩短62.4%，IT部门在重复性开发上的工时占比从58%下降到31%。我们的数据（缩短74%）比均值更激进一些，主要是因为我们的需求里表单流程类占比高，属于低代码最擅长的区间。

市场规模也能说明趋势：2025年国内低代码市场规模预计达到128亿元，年复合增长率21.6%。这个赛道热，不是因为厂商会讲故事，而是因为像我们这样的企业，确实在算完账之后愿意续费。

所谓香饽饽，从来不是因为它新，而是因为它算得过来账。

九、写在最后：工具不是解药，把人沉淀下来才是#

写完这一年的复盘，我想说的最后一件事，和工具本身无关。

我们真正收获的，不是那86个应用，而是9位业务侧公民开发者、一套数据治理规矩、以及IT和业务之间不再互相甩锅的协作关系。三年后如果换一个平台，这些东西还在。

低代码解决的是速度问题，解决不了方向问题。它能让企业在数字化内卷里跑得更快，但如果方向本来就是错的，跑得快只是错得更快。所以我一直提醒自己：先想清楚要什么，再谈用什么工具。

回到最初那个问题：低代码凭什么成为企业眼里的香饽饽？

我的答案是三条：它把等待变成了自助，把交付变成了共创，把成本从人力密集转成了能力沉淀。这三点，恰恰击中了内卷时代企业最疼的地方。

至于选哪个平台，我的建议朴素得很：找三个真实业务同事，给他们一个真实需求，看他们第一小时能不能跑起来。跑得起来，再谈后面的；跑不起来，功能表再长也是白搭。

工具会换，方法会变，但让干活的人少受点累这个标准，永远不会过时。

参考文献

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

[2] 中国信息通信研究院. 企业数字化转型发展白皮书(2024年)[R]. 北京: 中国信息通信研究院, 2024.

[3] 李红, 张伟. 低代码开发平台在企业应用中的采纳因素与绩效影响研究[J]. 信息系统学报, 2024, 18(3): 77-91.

[4] 王坚. 组织效率重构视角下的企业数字化路径[J]. 企业管理, 2024(6): 45-52.

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