夜雨聆风
上一篇我们讲到一个判断：
很多工厂不是不会用 AI。而是 AI 根本进不了现场。
那接下来，问题就来了。
如果把 OpenClaw 这种“开始会干活的 AI”放进工厂，它到底能干什么？
能干的事，其实不少。
查设备异常。
自动生成班报日报。
回答车间数据问题。
跨系统发通知、建工单、做协同。
听起来都很近。但真正做起来，很多企业很快就会发现：
用起来总是差点意思。
这不是 AI 能力不行。而是底下没有东西给它用。
这是很多人最先提出的场景。
尤其是我们跟EAM（设备资产管理）企业合作了很长时间，也大致了解到他们客户的一些痛点。
但是这个场景看起来最容易，实际最吃数据。
设想的场景就是客户一句话问AI：
“帮我看看 3 号机今天为什么停了两次。”
设想中，AI 会去查状态、查报警、看前后变化、对比历史，再把结果发给责任人。
但现实里，很多企业卡在第一步。
状态采得不全（甚至没采集）；报警有记录，但没有前后的记录；停机到底是故障、等料、换模还是调机，系统分不清；历史异常也没有统一分类。
所以问题不是 AI 不会查。而是它没什么数据可查。
没有完整状态，没有事件上下文，异常追查就很难成立。
这个场景就是上一篇遇到的客户提出的场景。
这个场景确实能释放很多的人力。
但是日报AI不是写不出来，而是底稿不可信。
一般的流程：AI 调取产量、调取停机、算达成率、自动生成日报，看上去很顺。
但很多企业最后会遇到一个问题：
报表发出来了，没人真信。
为什么？
因为底下的数据根本就不统一。
设备获取到的产量是一个数。MES 报工是一个数。人工登记又是一个数。
再加上班次边界不一致，开机不等于有效生产，人工停机说明又没接进去，
最后 AI 只是把这些不一致的数据，更快地整理成了一篇文章。
所以自动日报真正难的，不是让 AI 写。而是先把数据来源做准。
数据不可信，日报就只能“像”，不能真用。
这个场景我看业内很多的企业都有类似的解决方案。
也许他们觉得，工厂 AI 最简单的形态就是问答。
于是在原有的软件中加个聊天框就敢叫引入AI了。
设想很美好：
“今天哪条线掉产最多？”“哪几台设备待机超时？”“最近哪类报警最多？”
然后AI就能在聊天框里快速地输出想要的结果。
但这个场景真正难的，不是聊天。而是语义。
什么叫待机？什么叫掉产？什么叫有效生产？什么叫异常周期？
这些概念如果企业自己都没有统一，AI 就很容易答偏。
所以车间问答不是“给数据包一层聊天框”。而是要先把现场语言，整理成统一的数据语言。
没有语义层，问答看起来聪明，答深一点就开始飘。
这也是最让人兴奋的场景。
也是当前龙虾（OpenClaw）想要实现的场景。
设备异常了，自动通知。工单超时了，自动提醒。日报生成后，自动分发。质量异常了，自动回查设备参数。
这时候，AI 已经不只是“回答”，而是开始“做事”。
但这类场景最容易踩坑。
因为一旦走到协同，问题就变成：
系统接没接通？接口能不能调？权限边界清不清？执行能不能审计？
所以很多企业会发现：
发消息可以。真到建工单、推进流程、跨系统联动时，就开始卡。
不是没有 AI。而是没有一套可调用、可管控的系统底座。
因为上面这些场景，最后都依赖同一层东西：
设备数据能不能稳定接入。状态能不能识别清楚。口径能不能统一。事件能不能追溯。
这些东西，以前大家觉得是基础。现在再看，它们其实是 AI 落地的前提。
没有这层底座，OpenClaw 再强，也只能停在“能演示”。
所以这篇文章想说的，其实就一句话：
很多制造业 AI 场景，不是想不到，也不是做不出。而是底下那层数据底座还没准备好。
OpenClaw 让大家看到了一个新方向：
AI 不只是会说，它开始有机会参与工作。
但也正因为这样，数据入口的重要性，被放大了。
谁先把设备、状态、工艺、异常、工单这些数据整理成 AI 能接得住的底座，谁的 AI 才更有机会不是演示，而是真正进现场。
往期回顾
往期推荐
想要了解更多数据采集知识
右下角，点击
和
让更多企业了解数据采集
点击下方头像 关注聆机智能
让数采变得更简单
