不会写代码的工艺工程师,开始自己＂造＂软件了:低代码为什么先在车间火起来

车间里最缺的，往往不是设备，是"小软件"。

想给点检加个电子表单，IT部门排期排到三个月后；想让质量数据自动汇总成日报，外包报价六位数；想给交接班加个电子台账，最后还是回到纸质本子。工厂数字化走到今天，大系统（MES、ERP、WMS）该上的都上了，但车间里还有大量"不上不下"的小需求——它们单个不值一提，堆起来却是日常运营的大头。

这两年，解决这些需求的主角悄悄换了人：不再是IT部门，而是工艺工程师、设备主管、班组长自己。他们用的工具，就是低代码平台——用拖拽组件、配置参数代替写代码，几天就能搭出一个能用的车间应用。

一、低代码不是"简化版Excel"，而是车间应用工厂

很多人对低代码的印象还停留在"做OA审批表单的"。但在工业场景，新一代低代码平台的能力边界已经完全不同：

它能连设备——通过OPC UA、Modbus、MQTT等工业协议直接读PLC和仪表的数据；能做逻辑——超限报警、多级审批、跨表计算、定时任务都能配置出来；能出界面——手机端点检、车间大屏、管理端报表，同一套数据自动适配；还能留痕——每一条操作记录都有时间戳和操作人，天然满足追溯要求。

换句话说，低代码填的正是工业软件市场的"中间地带"：大系统管不了的碎片化需求，定制开发又养不起的那一块。

二、三类场景，低代码在车间已经跑通

场景1：设备点检与保养台账

某汽车零部件厂用低代码平台两周搭出点检应用：点检项按设备型号自动下发，工程师手机扫码填写，拍照留证；漏检自动推送班组长，点检数据直接沉淀给设备工程师分析保养周期。上线后点检执行率从勉强七成提到98%，而这套应用的搭建者是设备科的两位工程师——一行代码没写。

场景2：质量异常的闭环处理

质量问题最怕"提了没人管，管了没结果"。一家注塑厂用低代码搭了异常上报流程：检验员拍照上传不良品，系统自动带出批次、机台、班组信息，按异常等级路由到不同责任人，处理超时自动升级。三个月后回看，异常平均闭环时间从4.5天缩短到1.8天——改善的不是技术，是"每一单都有人认账"的机制。

场景3：车间能耗与班组考核日报

过去做一张车间日报，统计员每天早上要花一个多小时从三个系统里抄数。用低代码对接电表和产量数据后，日报自动生成，还能下钻到机台和班组。原来花在抄数上的人力，转去做能耗对比分析，反而找到了两台空压机的异常耗电。

三、三个真问题，想在前面就不会踩

问题1：搭得快，但"想清楚"不能快。低代码降低的是实现成本，不是需求梳理成本。见过的失败案例里，多数不是平台不行，而是搭应用的人自己没想清楚流程该长什么样，上线后改了七八版，用户失去耐心。正确姿势是：先把纸面流程走顺，再用低代码固化。

问题2：谁拥有这些应用？工程师调岗、离职之后，他搭的应用谁来维护？低代码平台"人人可搭"的另一面，是应用治理缺位的风险。建议一开始就立规矩：应用统一登记、关键应用双人了解、账号权限集中管理。

问题3：别让低代码变成"影子系统"。如果点检数据只在低代码应用里，而MES里是另一套，两本账迟早打架。低代码应该定位为大系统的"毛细血管"——该回写主系统的数据（如点检结论、异常工单）要有明确的接口约定，而不是各记各的。

四、落地三步走

第一步：选一个"两周能见效"的场景。点检、交接班、异常上报、能耗日报，都是好起点——痛点明确、用户就在现场、效果肉眼可见。别一上来就啃核心业务。

第二步：培养车间里的"平民开发者"。找两三位熟悉业务、愿意折腾的工程师，给他们几天培训和一个能随时提问的支援渠道。低代码推广的成败，取决于业务侧有没有自己的搭建者，而不是IT采购了多贵的平台。

第三步：三个月复盘一次，把好应用"转正"。跑得好的应用，评估是否需要升级为正式系统模块或接入主数据；跑不动的，果断下线。让低代码保持"试错田"的定位，而不是变成第二个遗留系统堆场。

结语

工厂数字化的下半场，比的不是谁上的系统更大，而是谁的"最后一公里"更通畅。低代码不会取代MES和ERP，但它让最懂现场的人第一次拥有了"自己动手解决问题"的能力。当工艺工程师开始自己造软件，数字化的种子才算真正落进了车间。

京城祥睿 · 工业数字化实战笔记 | 每周更新，关注获取更多行业洞察