今年初，福建漳州一家肉制品加工厂的老板找到我。他说了句让我印象很深的话："我花了三年时间管产品质量，结果审核员翻了两页纸的记录就说我们不合规。"

这家厂做高温肉制品（火腿肠、午餐肉类），每天产量约8吨。食品安全标准高，HACCP审核一年两次。他们的问题不是产品质量不行——问题全出在记录上。杀菌温度记录是手写的，冷藏库的温湿度登记表也是手写的，而且经常补签、漏填。

审核员一看就摇头：温度记录曲线平滑得像教科书、签字笔迹好几个日期明显是同一支笔写的。这已经不是合规的问题了，是信任问题。

这篇文章记录我们怎么用边缘AI网关解决这个问题的整个过程——不是空谈方案，是做了什么、踩了什么坑、结果怎么样。

一、现场情况摸底

先花了两天在厂里转了一圈，搞清楚几个关键事实。

这个摸底很关键——后来很多方案设计决定都是从这里出发的。

二、方案设计

方案的方向很清楚：用传感器自动采集温度数据，边缘网关本地存储+处理，生成不可篡改的合规记录报表。

但具体拆解下来，每个环节都有坑。

采集层：温度传感器怎么装

杀菌釜测温——最麻烦的部分。老式杀菌釜用的是双金属温度计和机械温控表，没有任何电信号输出接口。新杀菌釜有PT100铂电阻温度传感器，但信号接在PLC里，PLC不联网。

我们决定给每个杀菌釜加装一套独立的温度采集方案：

这里有个我想当然的失误——一开始我以为老杀菌釜也能加PT100然后接线。但师傅告诉我：杀菌釜在121℃、0.2MPa压力下运行，如果密封口开孔加装传感器，一来影响灭菌效果验证，二来有安全隐患。最后选了无线探头插到已有的测温盲管里，算是最小改动方案。

边缘层：本地网关+数据不可篡改

在厂里的办公室放了一台边缘AI网关。它负责：

选择边缘网关而不是纯云方案的原因：一是这条漳州的厂网络不太稳定（运营商4G信号时好时坏），二是合规数据不能依赖云端——万一机房出问题连不上云，数据断了就麻烦了。边缘网关就算完全断网，也能独立运行并存储数据。

软件层：让记录真正"合规"

这是最花心思的部分。光采集数据还不够，要生成审核员认可的记录才叫合规。

我们做了几件事：

做这个软件的时候跟工厂的品质部反复确认了4版报表格式——第一版我以为好看就行，但品质主管说"审核员只认特定的表格结构，你改个列名他就不认了"。后来完全照着他拿来的纸质模板重新做了。

三、实施过程

第一周：硬件安装

无线温度探头安装比较顺利——杀菌釜的测温盲管本来就是用来插温度计的，把探头塞进去固定好就行，每个花了不到10分钟。

麻烦在新杀菌釜的PLC数据读取上。这个PLC是台达的，用的是自家的通讯协议，不是标准的Modbus。虽然有RS485口，但文档不全。最后找了设备厂家来帮忙开了PLC的通讯参数表，才把数据读出来。这里耽误了3天——教训是：做设备数据采集之前，先确定PLC型号和通讯协议，最好找厂家确认。

冷库传感器的安装出了一个小插曲。我们选了壁挂式温湿度传感器，用3M胶贴在墙面上。结果速冻库因为频繁开门关门，贴上去的传感器被滴水+低温弄得掉了两次。后来换成了不锈钢支架固定安装，用电钻打孔，稳了。

第二周：网络和系统调试

工厂车间没有网络覆盖，杀菌釜区域环境高温高湿。我们在更衣室旁边找了个相对干燥的角落放边缘网关，从那里拉网线到杀菌釜区域的协议转换器旁边。

LoRa无线探头和网关的通讯距离在车间里只有大约50米有效，距离远一点就丢包。我们调整了两次网关的位置，最终放在一个钢结构柱子旁边的高处，信号才覆盖全。

刚开始数据采集测试时，有几个探头每隔几分钟就断连一次。排查了半天，发现是网关的LoRa模块天线附近有一台大功率变频器——电磁干扰把信号吃掉了。把天线拉到距离变频器约3米的地方，问题解决。

第三周：报表模板和验收

和品质部来回确认报表格式，前面说了，改了4版。最折腾的是关于"杀菌开始时间"的定义——品质部觉得应该以杀菌釜关门时间算，操作工觉得应该以升温开始时间算，审核员实际上看的是保温阶段温度达到121℃的第一个时间点。用了三天协调了三方的认知，最终报表上三列全列出来了：关门时间、升温开始时间、保温开始时间。多一列总比少一列强。

验收那天，品质主管把系统生成的记录表和过去的手写记录表并排放在审核员面前，审核员看了两分钟，说了一句："这个就对了。"

四、实际效果

审计准备：从半天缩到10分钟
以前审核前要花4-5小时翻纸、补签、核对数据。现在直接在系统里选日期范围 → 导出PDF → 打印，10分钟搞定。
记录完整性：从约70%到100%
手写记录经常漏填（尤其是夜班），一个月可能缺十几条数据。自动化后每2分钟一条记录，连续无间断。最近一次市监局抽查，把过去3个月的记录调出来看了一遍，说"数据完整，没有问题"。
温度偏差发现：3次针对性的工艺调整
系统上线两周后，发现一号杀菌釜在保温阶段有持续约3分钟的温度波动（从121℃降到118.5℃又回升）。手动记录完全看不出这个问题（因为操作工只记录整点的温度），但连续监测暴露出来了。排查后确认是蒸汽管路减压阀故障，更换后解决。

还有一个意想不到的收获：冻库门没关严的情况以前靠人工巡检发现，但夜班的时候可能开了一夜都没人知道。系统上线后，速冻库温度曲线如果有半小时以上的持续上升段，自动触发告警。第一个月就抓了4次门没关严的情况。

五、遇到的问题和解决办法

1. 无线探头电池寿命问题

数据采集频率设的是2分钟一次，结果有一批探头用了不到两个月就没电了。联系厂家才发现这批探头的电池批次有问题——标称续航12个月，实际约2-3个月。最终换了供应商，数据频率调到5分钟一次（杀菌期间仍然1分钟一次），新探头用了近4个月还没换过电池。

2. 操作工对"机器取代填表"的抵触

刚开始系统上线后，操作工觉得"不填表了心里不踏实"，仍然继续手写记录。结果一个人要应付两种记录方式，反而增加了工作量。我们做了一次简短培训，告诉他们系统出错怎么办、怎么查看数据、怎么确认自己的班次记录完整。两周后大部分人接受了，但有个老员工坚持多写了三个星期的纸质备份——后来他自己对比发现机器记录比手写准确得多，才停下来。

3. 温度传感器漂移问题

用了两个多月后，一号冷库的两个传感器数据开始出现偏差：一个显示4.2℃，另一个显示2.8℃。相差1.4℃。送去校准发现一个传感器的误差已经超出±0.5℃的规格。经验教训：温度传感器需要定期校准，建议半年一次。我们在系统里加了校准提醒功能，到时间自动通知品质部。

踩坑总结：技术方案以外的非技术因素——人员习惯、审核惯例、设备老化——花的精力往往比技术本身多。做之前要有心理准备。

六、个人的思考

这个项目做完，我有几个感受比较深：

食品安全领域的数字化转型比一般工厂更敏感。涉及监管审核的环节，不是"好用"就行，还要满足认证体系和审核员的认知习惯。如果报表格式不符合GB标准，再好看的系统审核员也不认。

"不可篡改"不是一句口号，是系统设计的硬约束。数据库设计成只追加不修改，这个决定后来被证明非常重要。有一次审核员专门问"这个数据有没有可能改"，品质主管直接让他在服务器上SQL查了一遍——所有数据都是只读的，连管理员也改不了。审核员看了之后，在这个环节打了满分。

边缘计算在食品行业的场景可能比想象中大。食品厂大多位于郊区，网络条件一般，而且生产环境苛刻（高温、高湿、蒸汽、水洗）。纯云方案在这里不一定适合，本地边缘处理+自动同步可能更务实。

最难的部分不是技术，是"让人用起来"。操作工填表填了十几年，突然说不用填了，他有种失去控制的感觉。后来的处理方式是把自动记录的数据给操作工做一个确认签名的步骤——他看一眼数据没问题，点一下确认，既保持了参与感又不影响数据真实性。这个"让渡控制权"的过渡设计，比任何技术决策都重要。

七、给你的建议

如果你也在考虑给食品工厂做合规相关的数字化改造，几点个人经验：

  1. 先搞清楚当地食药监/市监局认可的记录格式——品质主管手里一定有模板，直接拿过来照着做，不要自己发明格式
  2. 传感器安装一定考虑现场环境——速冻库不是普通办公室，要考虑结露、冻融循环、蒸汽冲洗
  3. 数据不可篡改不是可选项是必选项——审核员会专门查这个，如果数据库设计允许修改，你的合规系统就失去了核心价值
  4. 给操作工留一个"确认签名"的步骤——别让他们觉得被取代了，要让他们感觉是自己在"掌控"自动化系统
  5. 温度传感器半年校准一次——便宜传感器的漂移率比你想象的大，送计量院做校准的费用值得花
  6. 千万别跳过"与审核员确认格式"这个步骤——系统做完了发现格式不对，改起来比一开始确认模板麻烦得多