ARTICLE · 1197435
工信部部署“人工智能+软件”:MES厂商下一步,不能只给系统加个聊天框
最近和做工业软件的朋友交流，聊到一个挺有意思的话题。
现在大家都在谈AI，MES要不要加AI？设备管理系统要不要加AI？甚至原来做个统计报表的功能，也开始考虑能不能接入大模型。
从技术实现上看，给现有系统增加一个聊天窗口，调用大模型接口，并不算特别困难。
但客户用了以后，会发现一个问题：
如果AI只能回答一些通用问题，那他为什么不直接打开豆包或者其他AI工具？
这是我觉得工业软件厂商现在特别需要考虑的事情。
2026年9月，工业和信息化部发布了《“人工智能+软件”专项行动实施方案》。
文件谈到软件企业生产方式变革、传统软件产品智能化升级、智能体软件等方向，也明确涉及工业软件。
其中，工业软件的智能化升级强调场景牵引、知识复用和平台集成。
我觉得，这几个词在制造业软件现场，就很有现实意义。
先看一个普通的生产场景。
车间主管早上打开MES，发现昨天某条产线的产量达成率只有83%。
过去，他可能需要分别打开生产日报、设备停机记录、质量报表和工单执行记录。
如果系统提供了AI，他自然会想直接问一句：
“昨天这条线为什么没完成计划？”
这个问题看起来像普通的问答，实际却涉及好几套数据。
首先要知道昨天的生产计划是什么，实际完成了多少。
然后确认是哪些工单、哪些设备影响了进度。
如果设备有停机记录，还要知道停了多久、停机原因是什么。
如果设备没有异常，但实际良品数量偏低，就得继续看报废、返工或者物料供应情况。
只有把这些数据联系起来，AI才有可能给出有根据的分析。
如果MES只是把用户的问题转给通用大模型，而没有提供这些业务数据，模型最多只能给出一套生产管理建议。
所以AI发挥不了什么作用。
我以前做设备数据采集项目时，经常遇到一个现象。
客户已经上线MES，也有设备联网平台，但两边的数据很难直接关联。
MES知道工单号、产品编码、计划数量和报工结果。
设备采集平台知道PLC状态、生产循环、报警和运行时间。
可如果缺少设备编码、工单关联和统一的时间口径，就很难回答：
某张工单在某台设备上生产时，到底出现过哪些异常？
过去这种问题主要影响报表和追溯。
到了AI应用阶段，它会直接影响模型有没有足够的上下文。
工业软件真正有价值的，不只有数据库里的数据，还有多年实施过程中形成的业务规则。
比如工单怎样流转，产品和工艺路线怎么对应，设备出现异常后谁负责处理，质量判定结果怎样回写。
如果这些关系能以清晰的接口、数据模型和业务规则提供给AI，才有机会形成真正适合制造业使用的能力。
这对原来就深耕某个细分行业的MES厂商，反而可能是一种优势。
他们知道哪些数据可信，哪些需要人工确认，也知道很多现场规则不能只凭一条数据库记录就判断。
工信部这次提出发展智能体软件。
这个方向很值得工业软件厂商关注，但我认为落地时不能一下子把目标定得太高。
还是拿设备停机分析举例。
最开始，AI可以根据已有数据回答：
“昨天3号设备累计停机多长时间？”
再进一步，能够结合停机记录和维修工单，整理异常摘要，并标明数据来源。
然后可以帮助设备主管生成待确认的维修记录、停机原因补录清单或者周报。
如果要进入工单创建、排程调整、参数下发等操作，就必须增加更严格的权限、审批和审计机制。
特别是涉及PLC写入、设备控制的场景，不能因为AI能理解自然语言，就允许它直接执行。
模型可能给错建议，数据可能不完整，用户的提问也可能存在歧义。
所以在我看来，工业AI需要按照风险逐步开放能力。
先把查询做好，再做分析与辅助处理，最后才考虑受控的业务执行。
这条路径也更适合大多数中小型工业软件公司。
如果是一家已经有一定客户基础的MES服务商，我觉得可以先从现有客户最常问、最难回答的业务问题入手。
比如生产进度为什么延误、设备停机为什么增加、质量异常与哪些生产条件有关。
确定问题以后，再检查现有系统能不能提供足够的数据。
这里特别容易发现几个短板。
第一，设备数据接入不完整。
很多MES只能获得人工报工结果，设备运行、报警、节拍没有形成稳定的数据来源。
第二，业务数据口径不统一。
比如设备循环计数、完工数量、良品数量混在一起，AI很难判断哪个才符合用户的问题。
第三，历史记录缺少结构化信息。
维修记录虽然有，却只有“已处理”“恢复正常”等简单描述。模型无法从中得到真正有用的故障经验。
第四，系统接口和权限设计不足。
AI要查询或操作业务数据，需要经过有权限控制的业务接口，而不是直接拿一个高权限数据库账号随意执行查询。
这些工作过去属于系统集成和数据治理。
今天如果希望AI真正进入工业软件，就更绕不过去了。
我之前也陷入了误区，觉得工业AI，就得有自己的大模型，或者先搭建一套非常复杂的平台。
在坑里摸爬滚打了一段时间，现在觉得没必要急着走这一步了。
对于资源有限的工业软件公司，可以先使用成熟模型，把精力放在自己的行业能力上。
比如已有系统的业务接口、设备数据、工艺知识、历史维修记录，以及针对具体场景的测试方法。
选一个问题明确、结果容易验证的场景，先跑通。
模型可以更换，但这些现场经验和业务能力，是需要长期积累的。
真正难复制的，往往也在这里。而打出门槛和竞争力的，也在这里。
工信部这次推动“人工智能+软件”，对于MES、EAM和工业互联网平台厂商来说，是一个值得认真研究的方向。
但我不觉得每一家工业软件公司都需要马上做出一个无所不能的AI助手。
例如我们现在在研发中的，也只是基于设备数据做的特定场景的AI助手，不回去碰上层的业务关系。
因为在制造业现场，用户首先需要的还是系统能准确理解业务问题，拿出有依据的数据，并真正减少一些重复劳动。
如果连昨天的设备停机时间、产量口径和工单关系都还没搞清楚，给系统增加一个再聪明的聊天窗口，也很难改变使用效果。
这轮变化里，谁更了解现场、谁能把业务数据整理清楚、谁能把AI安全地接入实际流程，可能比谁先做出漂亮的演示更重要。
对于正在做MES和工业软件的同行，我也很想知道：你们现在给系统增加AI功能时，客户最愿意实际使用的是哪一种？
