最近在ITPUB上看到不少关于AI的深度文章，从LangChain智能体到数据基础设施的演进，大家讨论得热火朝天。作为一个常年和底层硬件、工控协议打交道的程序员，我想从另一个视角聊聊AI的落地——不是在云端，而是在充满油污和噪声的车间里。

起因是前段时间的一次经历，让我对“AI落地”有了更清醒的认识。

1. 一个被“过度设计”的需求

朋友工厂里一条产线，用S7-1200 PLC通过Modbus轮询采集5台温控仪的数据。需求很简单：数据偶尔会因干扰“冻住”，希望做个智能监测，能自动判断是真故障还是瞬时干扰，最好还能提前预警。

团队里一个同事非常兴奋，立刻提出了一个方案：采集高频原始波形，用基于Transformer的时间序列异常检测模型来做预测性维护。概念很前卫，听起来也很“人工智能”。

2. 被现实“打脸”的落地过程

我们兴冲冲地尝试，但很快就被现实教育了：

• 算力鸿沟：S7-1200的CPU根本没有能力运行任何模型推理。

• 架构成本：若按照“边缘计算盒+云端训练”的经典架构，要把数据从PLC采集、转发、清洗、落库，再部署一个推理服务，整个链路投入对于一个仅5块仪表的小型监测点来说，简直是“大炮打蚊子”。

• 可靠性悖论：引入更多环节，不仅成本飙升，潜在的故障点也更多了。

3. 程序员式的“降维打击”解法

回归工程思维，我们重新思考了问题的本质：
我们到底需要多“智能”？我们的目标是 可靠地抓出数据异常，而不是发一篇论文。

最终，我们用一套极简的、扎根于现场工程的方法解决了问题：

第一步：物理与逻辑的“硬”抗干扰

• 物理层：检查RS485总线的偏置电阻和终端电阻，确保空闲态差分电压稳定在逻辑“1”。这是治本。

• 协议层：在PLC程序中，用严格的 状态机互锁逻辑代替简单的定时器轮询，彻底杜绝了总线上的请求冲突。

第二步：在PLC里嵌入“微智能”滤波
我们的“AI模型”只是一个非常简单的软件滤波器：连续两次采集的数据有效，且偏差小于5%，才被视为一个可信的读数；否则直接丢弃，等待下一次轮询。这段逻辑用梯形图写下来不到十个指令，运行在小小的S7-1200里完全绰绰有余。

第三步：简单规则，就是最可靠的专家系统
关于预警，我们放弃了对复杂模型的幻想。我们根据业务经验设定了几个明确的、由工艺工程师确认的物理阈值规则，比如“连续3次超时则触发报警”。这就是一个最朴素的、零成本的专家系统。

4. 写在最后：AI落地的“第一性原理”

这次经历让我深刻体会到，AI（尤其是工业AI）真正的力量，不在于模型的复杂度，而在于能否以 最小成本、最可靠的方式解决实际问题。

很多时候，最好的解决方案可能是:

一个工艺专家定义的简单规则。

一个嵌入在廉价微控制器里的移动平均算法。

一个经过良好接地和端接的RS485总线网络。

在追逐AI浪潮的同时，我们这些技术人需要时刻自省：我们是在创造真实价值，还是在满足自己的技术幻想？真正的智能化，往往始于对物理世界和工程约束的深刻敬畏。

所以，当你的PLC“哑”了时，先别急着上大模型。拿好你的螺丝刀和万用表，也许答案就在那里。