视觉 SOP 回写 MES：字段怎么设计才有分析价值

视觉系统回写 MES 的字段设计，有一个很朴素的自检方法：假设三个月后客户退回一批产品，只靠这套字段，能不能定位到是哪一班、哪个工位、哪一个判定项、当时的图像是什么样。如果做不到，说明字段太少，这套系统就退化成了一个只会亮红灯的装置，事后完全无法用来做工艺改善。反过来，字段也不是越多越好——每一列都要有人维护、有地方存、有人看，堆了没人用的字段，只会让数据库膨胀、让后来接手的人不敢动。设计的核心是先把「谁、什么时候、在哪里、判什么、判成什么、依据是什么」这六个问题回答清楚。

六个问题对应六组字段

最容易漏的是最后两行。「阈值版本」和「模型版本」看起来是内部实现细节，一旦系统调过参数，历史判定就再也无法复现——三个月后有人拿着当时的图像问「为什么这张判合格」，没人答得上来。图像索引同样如此：不是要求把每一张图都永久保存，而是要求至少保留一段时间内可回溯的窗口，超期之后再按策略清理。保留周期怎么定，要结合产品的追溯要求和存储成本一起看，这一点在生产追溯怎么建里有更细的讨论。

追溯粒度：单件、批次还是工单

粒度选择不是技术先进性问题，而是「产品本身可不可标识」的问题。单件级追溯的前提是每一件产品在身上或载具上有一个唯一标识——序列号、条码、RFID，或者至少是一个能稳定读出的位置关系。如果来料是一筐散件、上料时没有任何标识，那么所谓单件级追溯只能靠时序推算，一旦出现漏拍或重复触发，数据就错位了。这种场景下更诚实的选择是批次级或工单级追溯：记录「这一批里报警了几次、分别在什么时刻」，虽然定位不到具体是哪一件，但足够支撑工艺改善和趋势分析。

• 单件级：适用于有唯一标识、且单件价值高（如半导体、医疗器械）的场景，能直接回答「哪一件有问题」。
• 批次级：适用于来料无标识但按批次流转的场景，回答的是「哪一批的参数可能漂了」。
• 工单级：适用于品种多、批量小的场景，回答的是「这个工单的整体表现如何」，常与首件确认配合使用。
• 混合使用：实践中常见做法是工单级为主、关键工位做到单件级，兼顾成本与可用性。

回写和节拍冲突时，先保谁

在节拍紧的工位上，回写本身也会成为负担：如果每判一件都要同步等 MES 返回确认，网络稍有波动就会拖住产线。合理的分层是——判定结论、时刻、工位、判定项这几个关键字段在本地落盘，先保证不丢；再异步推送给 MES，允许延迟。图像这类大对象更不能走同步通道，通常是本地留存加索引，MES 侧只存索引。这个顺序不能反：如果先追求实时同步而放弃了本地落盘，一旦网络中断，那一段时间的记录就永久缺失，而缺失的记录在追溯时是无法补救的。关于 MES 侧接口怎么对接、由谁主导，可以参考与 MES 厂商的对接。

哪些字段其实可以不要

反过来也要敢于砍字段。常见的冗余有三类：一是把整段图像或大量原始数据直接塞进 MES 表，MES 并不是为存大对象设计的，结果是数据库迅速膨胀、查询变慢；二是回写可以由 MES 自己推算出来的派生指标，比如根据时刻与班次表算出的班次，重复存一份只会带来不一致；三是回写「系统健康度」这类运维指标，它们属于设备管理范畴，混进生产数据里会干扰工艺分析。一个实用的判断标准是：这个字段会不会被工艺或品质部门拿去做分析？如果答案是不会，它大概率不该出现在生产追溯表里。