这两年，制造业客户问得最多的问题之一，就是AI到底怎么在工厂里落地？模型接进去以后，工厂的生产流程真的发生了变化吗？

大模型、Agent越来越热，几乎每家制造企业都在看，也有不少企业已经做过第一轮尝试。接个大模型，做个知识库，找几个业务场景跑一下POC，再做几个Agent。演示的时候，效果通常都不错。

但真正到了车间，问题就来了。工程师不会因为多了一个对话框，就少看几张趋势图；设备异常了，还是要自己翻历史数据；模型给了一个判断，最后还是得找工艺、设备、自控几拨人确认到底能不能调。Demo跑通了，生产流程却没变。这也是现在制造业AI落地比较普遍的一个尴尬。

从2026年Gartner、Deloitte、MIT NANDA、McKinsey等机构陆续发布的企业AI研究来看，大家看到的情况其实很接近：企业对GenAI和AI Agent的投入热情很高，但从POC真正进入生产环境，依然有很长一段路要走。不少项目演示完，就放在角落里吃灰了。

问题已经不只是模型够不够聪明。到了制造现场，数据、设备、软件、工艺、控制、安全，任何一个环节没接上，AI最后都可能停在能回答问题，却很难真正干活。

我们这几年在设备工程现场做项目，对这一点感受尤其深。如果把今天的大模型比作一列性能很好的高铁，很多企业现在其实已经把车买回来了。但轨道、信号、调度、制动和安全边界没有准备好，高铁依然跑不起来。

制造业 AI 也是如此。模型能力正在快速提升，真正缺的是让模型进入工业现场的工程系统。这也是格创东智PreMaint设备智能工程（以下简称格创东智EES）一直在解决的问题。

过去一段时间，我们和不少制造企业落地AI，也看过一些已经做过POC的项目。很多问题看起来不同，最后往往都绕不开下面三个坑。别人花钱买的教训，可以变成你的经验。

坑一：先找AI 场景，没对上业务痛点

这是最容易踩的坑。老板觉得AI很重要，IT部门开始研究大模型，接下来就会问：我们工厂有哪些场景能上AI？

然后大家去车间找场景：班报能不能让AI写？设备故障能不能让大模型判断？工艺参数能不能直接让AI调？这些都能做，但问题是：做完以后，到底改变了什么？

我们判断一个制造业AI场景值不值得做，通常不会先看模型，而是先看现场。比如一个烘箱水分控制场景，现场真正头疼的是：水分有波动，化验结果回来得慢，参数怎么调很依赖班长经验。

那这个项目的目标就很清楚。不是做一个懂烘箱的大模型，而是想办法把水分控制得更稳。于是往下拆：

l过程量能不能实时拿到？

l哪些变量跟水分相关？

l能不能通过历史数据建立软测量模型？

l模型给出预测以后，建议设定怎么进入控制？

l什么条件下允许调，什么条件下必须退回人工？

做到最后你会发现，这件事情里确实用了AI，但用户真正买单的不是AI。他买单的是水分更稳了，人工调节少了，经验不再只装在老师傅脑子里。这也是格创东智EES选择AI场景的基本逻辑。

我们内部经常用三个问题判断一个场景：谁在痛？每天在重复做什么？最后能改善哪个指标？这三个问题说不清楚，模型先别急着上。

制造业最终认的还是良率、停机、波动、能耗、误报和工时。AI只是解决这些问题的新工具。

坑二：大模型接上了，工业软件却不具备AI 能力

这个问题比第一个更普遍。很多企业现在已经把大模型接进系统了。设备系统有接口，数据中台也有数据，再加一个对话入口，看起来AI能力就有了。但工程师真正用几天，很快就会发现问题。

比如他说：帮我看看3号搬运机器人的扭矩是不是有异常。AI可能知道3号机器人是谁，也能把相关数据查出来。但再往下一步呢？

l它能不能自动找到这台机器人的历史正常波形？

l能不能选样本？

l能不能调用模型训练？

l训练完以后能不能跟正常动作比？

l发现异常以后，能不能进入监视流程？

如果这些事情还是需要工程师一个页面一个页面点，那么这个AI本质上只是把原来的软件多加了一个聊天入口。这也是格创东智EES的设计原则：不是给设备软件外挂一个AI，而是先把设备工程本身改造成AI能用的软件。

我们把这件事情叫做AI原生五化。

1.接口化——让AI 有手。采集、监控、告警、诊断、报告、模型训练，这些原来需要人在页面上操作的功能，要先变成Agent可以调用的能力。人能点，不代表AI能调。这一步不做，Agent就没有手。

2.语义化——让AI看得懂。工业现场有大量测点编码、设备编码、变量名。工程师看到TC-01-04可能知道是什么意思，大模型不知道。EES把设备、部件、测点、异常、工况之间的关系组织起来。当工程师说3号搬运机器人最近是不是不太对，系统要知道去哪里找数据、看什么数据、跟谁比较。这相当于让Agent开始看得懂工厂。

3.事件化——让AI主动发现问题。传统软件大部分是人在找系统。设备报警了，人打开页面；趋势不对了，人再去查历史。Agent真正进现场以后，应该反过来。状态发生变化，事件主动进入流程，再判断接下来该查什么、算什么、通知谁。

4.自动化——让AI执行重复工程动作。制造现场其实有大量重复的工程动作。选样本、训练、比对、发布、监视，很多步骤并不需要工程师每次从头做一遍。这些动作如果能够被标准化、编排起来，Agent才有机会真正接手其中一部分工作。

5.安全可控——让AI知道什么能做、什么不能做。这一条在制造业尤其重要。办公场景里，AI答错一句话，最多重新生成。设备现场不一样。涉及参数修改、控制指令，就必须知道谁允许操作、当前联锁状态是什么、设备是不是在自动模式、出了问题怎么退回去。EES里的AI能力从一开始就不是想调什么就调什么。能读什么、能做什么、什么情况下能写、谁来确认，每一步都有边界。

这五件事情做完，AI在设备工程里的角色才开始发生变化。

拿搬运机器人来说。过去做异常检测，需要工程师把扭矩波形找出来，选正常样本，选择底层模型，配置参数，训练，再看效果，最后发布。如果现场有几十台、几百台同类设备，这里面有大量重复工作。在EES里，我们把这套模型工程能力放进了设备工程底座。

每个动作节拍的扭矩波形进来以后，系统可以判断它像不像正常动作，给出一个异常得分。

而选样本、训练、比对、上线这些重复流程，可以继续交给Agent执行。这样才能做到一机一训，一机一模。

Agent真正省掉的，不是工程师打几个字的时间，而是背后那些每天都在重复发生的工程操作。这也是我们理解的设备智能。

坑三：工业数据都有，却没把数据变成AI “可执行的上下文”

很多工厂第一次聊AI时都会说：我们的数据已经采了很多年了。这句话通常没错。但有数据和AI能用数据，中间还差很远。

实时量在一个系统，报警在另一个系统，配方又在MES里；早几年上的设备是一套协议，后来买的产线又是另一套。做一次完整判断，经常是：先去A系统看趋势，再去B系统查报警，找不到配方，再打电话问现场。人都是这么干活的，Agent自然也跑不起来。

EES做的另一件事情，就是把这些原来散落的设备工程能力往一个底座上收：采集进统一测点；设备状态、报警、配方、工况之间建立上下文；监测、诊断和模型工程用同一套设备语义。这样Agent拿到的不再只是一个数字，而是知道：这是哪台设备、哪个部件、什么工况下的什么变化。

再往下一步，就是很多AI项目最容易忽略的写：AI看见问题是一回事。让AI参与调节，是完全不同的一回事。在EES里，控制命令必须经过统一的智控通道。联锁状态要看得见，自动/手动状态要看得见，权限要管得住，模型发布也要有门禁。

比如一个软测量模型，可以先只读进入控制环路。它可以判断，可以给建议，但不能因为模型觉得阀门应该开大一点，就绕过原来的控制体系直接写阀。只有这条链路是完整的，AI才有可能从：我觉得这里有问题，慢慢走到：我已经完成诊断，这是建议动作，在满足这些条件后可以执行。到这一步，AI才算真正开始进入生产流程。

三个坑，总结出来的经验，说到底就对应三句话：

应对策略

o场景，先痛点后模型；

o系统，先五化后对话；

o通路，先打通再谈自动化。

做了这么多年制造现场以后，我们越来越确定一件事：制造业不缺一个更聪明的聊天机器人，真正缺的是一个能够让AI进入设备工程的载体。AI要知道现场发生了什么；要理解设备和测点；要能调用监测、诊断、模型训练这些已有能力；需要的时候，还要能够在权限和联锁范围内参与下一步动作。

我们把PreMaint做成了一个设备智能工程底座：从设备、采集、监控、诊断，到寻优、模型工程，再到Agent协同，尽可能放到同一套设备工程体系里。

这也是为什么我们没有把Agent单独做成一个AI功能。如果下面的设备数据、软件能力、模型工程和控制链路没有准备好，Agent再聪明，到了现场也只能聊天。

制造业AI真正要解决的，是让设备从过去的有数据、能监控，继续往前走到看得懂、查得到、可诊断，该调节的时候调得动。

100 个免费使用名额仍在开放，优先老客户和已走过AI试点、希望进一步推动AI嵌进一线而不是停在对话窗的企业。

责任编辑：kj005

文章投诉热线:157 3889 8464  投诉邮箱:7983347 16@qq.com