7个被问爆的SOP检测问题，我把坑都替你踩了

摘要：CSDN私信、公众号评论区问得最多的7个问题，一次性讲透。YAML和代码怎么配合、相似动作怎么区分、一个摄像头能不能拍多个工位、多人同画面怎么办、误报率怎么调、AR眼镜能不能做、小零件检测不到怎么办——看完这篇，你对SOP检测的常见问题怎么处理基本就有数了。

关于作者

我接触视觉整整10年。

机器视觉、烟草、煤矿等行业都有深度开发经验。从硬件选型、算法开发、模型训练，到上位机开发及部署，都在一线磨过。

之前是多家公司人工智能团队的技术负责人。现在自己创业了，还在继续做视觉落地这件事。

作者说

做SOP行为检测，不少同学最大的困扰就是——理论看起来简单，落地却容易踩坑。

上两篇SOP文章发出去后，评论区和私信都在问：配置怎么改？动作怎么区分？摄像头一拖多工位行不行？

说真的，看到这些问题的时候我挺高兴的。不是因为有人问——是因为问的问题越来越专业了。最早的时候大家问的是「YOLO能做这个吗」，现在问的是「时序建模用什么方案」「状态机怎么处理并行操作」。说明这个方向确实有人在认真做，不是看看热闹就走了。

今天，我把这7个高频问题一次性讲清楚，帮你少走弯路。

---

问题1：YAML配置和代码怎么配合？怎么做到改配置不改代码？

这个是被问最多的，CSDN私信原文：

「老哥能分享一下sop的yaml这个是和代码怎么配合的嘛，有点没看目标是怎么通过不变代码通过修改配置改变sop的」

一句话回答：YAML定义「做什么」，代码只负责「怎么跑」。

说直白点，YAML里写的是业务逻辑，比如「第1步检测戴安全帽，第2步检测拿工具，超时5秒报警」。代码只做一件事，读取YAML，然后跑检测。

中间连接它们的东西叫状态机。你可以理解成一个裁判，YAML是规则手册，代码是裁判的眼睛（YOLO负责检测目标和空间关系），状态机就是裁判的大脑——每帧画面进来，看一眼当前画面里有什么，跟规则手册对一对，对上了进下一步，对不上就等，等太久就吹哨。

先说明一点。 之前SOP系列的第二篇文章（工业视觉踩坑实录十三，以下简称第二篇）里我详细写过，状态机在简单场景下很好用，但上真实产线之后碰了一堆壁。并行操作、可选步骤、条件触发，这些东西把我的YAML配置从30行撑到了200行，状态机的表达能力根本不够用。后来我做了个大重构，把整个检测逻辑从「状态机驱动」改成了「事件驱动」，用动态时间规整来做事件序列匹配。

这篇答疑里我先用状态机的框架来解释基本原理，因为这是最容易理解的入门方式。

用一个最简单的例子说明。

YAML里写的是（业务逻辑）：

steps:
  - id: 1
    name: "佩戴安全帽"
    type: "wear_safety"
    detection:
      object: "helmet"     # 检测什么物体
      action: "wear"        # 检测什么动作
    timeout: 5              # 超时多少秒报警

代码里做的是（检测能力）：

1. 读取YAML → 知道第1步要检测helmet的wear动作
2. 每帧跑YOLO检测 → 画面里有没有helmet？手在不在helmet附近？
3. 状态机匹配 → 对上了就进下一步，超时就报警

换一个SOP流程，代码零改动。

• 耳机装配：打开耳机仓 → 放左耳机 → 放右耳机 → 关闭耳机仓
• 安全检查：戴安全帽 → 戴手套 → 确认安全标识
• 焊接工序：取焊枪 → 靠近焊点 → 焊接 → 放回焊枪
• 电子厂SOP：取零件 → 对准工位 → 插入 → 压合 → 检查

这四个完全不同的流程，代码一个字都不用改，只需要写四个不同的YAML文件。

状态机的运转原理（入门版）

整个检测流程就是一个状态机，每个步骤有4种状态：

PENDING（等待）→ IN_PROGRESS（进行中）→ COMPLETED（完成）
                     ↓
                  TIMEOUT（超时报错）

每一帧画面进来，状态机只做三件事：

1. 检测：当前画面里有什么物体、什么动作？
2. 匹配：跟YAML里当前步骤的要求对不对得上？
3. 转移：对上了进下一步，对不上就等，超时就报警

7种步骤类型

YAML的type字段支持7种步骤类型，覆盖绝大部分工厂场景：

type	含义	典型场景
enter_zone	进入区域	工人进入工作区
exit_zone	离开区域	工人离开危险区域
pickup_object	拿取物体	从工具架拿工具
return_object	归还物体	工具放回工具架
approach_object	靠近物体	靠近设备准备操作
operate_object	操作设备	按按钮、拧螺丝
object_state	物体状态变化	耳机仓打开/关闭

状态机核心代码（简化版）

看懂这段代码就理解了整个系统的工作原理：

class SOPStateMachine:
    def __init__(self, sop_config):
        self.steps = sop_config.get('steps', [])
        self.current_step_index = 0
    
    def process_frame(self, detection_result):
        """每帧调用一次"""
        current_actions = self._extract_actions(detection_result)
        current_step = self.steps[self.current_step_index]
        
        # 匹配当前步骤的要求
        if self._match_action(current_actions, current_step):
            # 匹配成功 → 进入下一步
            self.current_step_index += 1
        
        # 检查超时
        if self._is_timeout(current_step):
            self._report_violation("timeout")

就这么简单。所有的复杂性都在_extract_actions（怎么从画面提取动作）里，状态机本身不超过200行代码。

但这是入门版。 状态机在简单场景下很好用，但上真实产线之后你会发现，它解决的是「理想流程」的问题，而工厂里没有理想流程。

从状态机到事件驱动，我踩的一个关键坑

第二篇文章里我写了状态机的三个具体痛点（并行操作、可选步骤、条件触发），不重复了。这里想聊聊重构过程中一个容易被忽略的更底层的问题：事件切分。

状态机假设动作是离散的——步骤A做完，步骤B开始，边界清晰。但真实工厂里的动作是连续的、重叠的、模糊边界的。工人一边拿工具一边转身，同时还在看设备，你很难定义「动作A结束」和「动作B开始」的精确时刻。

这其实是工业行为检测最难的问题之一，比模型架构选择难得多。后面不管用状态机还是事件驱动还是时序动作分割，都得先解决「怎么切分」这个问题。

另一个容易被忽略的决策点是匹配策略到底该怎么选。状态机的匹配逻辑是严格顺序的——步骤1完成才能检测步骤2，步骤2完成才能检测步骤3。这个逻辑在YAML里写起来很干净，但产线上工人不是这么工作的。

重构的时候我对比过三种匹配策略：

严格序列匹配。 就是状态机的做法，一步一步来。好处是逻辑清晰，坏处是容错率为零。工人多做一个动作、少做一个动作、或者顺序颠倒一个，整个流程就断了。

全局序列匹配。 把整段操作录像当成一个序列，跟SOP模板做整体匹配。好处是能看到全局，坏处是计算量大，而且一旦中间出错了，后面的匹配全部受影响，误差会累积。

滑动窗口匹配。 这是最后采用的方案。维护一个固定长度的滑动窗口（比如最近30帧），在这个窗口内做局部匹配。窗口滑过去，匹配结果就出来了。好处是误差不会跨窗口累积，坏处是窗口边界可能有动作被切断。

三种策略各有利弊，没有银弹。我的建议是先从严格序列匹配开始，快速验证流程能不能跑通。等上了产线碰壁了，再根据你的具体痛点选择升级方向。

设计原则只有一个：你的架构要有退路。 状态机能跑通就先用状态机，但代码层面要留好扩展接口，后面换成事件驱动的时候改动最小。

---

问题2：两个相似的动作怎么区分？YOLO没有上下文怎么办？

这个问题来自公众号私信，问得很专业：

「两个相似的动作怎么检测，YOLO本身无上下文，用LSTM？还是时序？具体怎么实现。」

这个问题问到了工业视觉行为检测的核心痛点。能问出这个问题的，说明是真做过或者认真研究过的。

先说结论：单帧YOLO确实分不了，必须引入时序建模。但不需要上LSTM那么重的东西，轻量级的时序方案就够了。

为什么YOLO分不了

YOLO是目标检测模型，它只看当前这一帧。给你一张图片，它能告诉你「画面里有一个人，手在螺丝刀附近」。但它不知道这个人是在拧螺丝还是在松螺丝，也不知道他是刚拿起来还是准备放下。

因为这两个动作在单帧画面里看起来一模一样——都是「人+手+工具」的空间关系。

举个例子，「拧紧螺丝」和「检查螺丝」，在某一帧看起来可能都是手在螺丝附近停留。区别在于前面发生了什么（有没有拿螺丝刀、有没有靠近螺丝）以及后面会发生什么（有没有拧的动作、会不会放下工具）。这个「前后发生了什么」，就是时序上下文。

几种时序方案的对比

我调研和实践过三种方案，从轻到重排列：

方案A：滑动窗口+特征统计（最轻量）

不做任何深度学习时序建模，纯粹用统计。维护一个过去N帧的滑动窗口，统计手部关键点的位移轨迹、速度变化、停留时间。然后定义规则：

• 拧螺丝 = 手在工具附近 + 持续停留>3秒 + 手部有微小往复运动
• 拿工具 = 手从远处靠近工具 + 速度先增后减
• 放工具 = 手从工具附近离开 + 速度渐增

这个方案的好处是零训练成本，改个阈值就能用。缺点是只适合动作差异较大的场景，如果两个动作真的很像，统计特征会重叠。

方案B：时序动作分割（我们实际用的方案）

在姿态估计之后加一层时序动作分割模型。输入是过去T帧的关键点序列，输出是每个时间步的动作类别。

具体实现上，backbone用的是1D卷积+时序池化来提取时序特征。为什么选1D卷积而不是LSTM？这个选择参考了学术界MS-TCN（Multi-Stage Temporal Convolutional Network）的思路，用膨胀1D卷积做多尺度时序建模。1D卷积可以并行处理整个时间窗口，推理速度快，而且不存在LSTM那种长序列遗忘的问题。具体快多少取决于序列长度、hidden size和硬件平台，不能简单给一个倍数。但在我们的边缘工控机场景下，TCN类结构的延迟确实明显低于LSTM，主要原因是并行度高、TensorRT优化友好、延迟更稳定。

当然具体到我们系统的网络结构、参数量、训练数据集这些细节，就涉及到具体的模型方案了，以后有机会再展开聊。

方案C：Transformer时序模型（最重，目前还在实验）

用Temporal Transformer做动作分割，类似MS-G3D或TASFormer这类模型。表达能力最强，能捕捉长距离的时序依赖。但推理成本也最高，在我们的工控机上跑不动，需要GPU。

适合对精度要求极高的场景，比如高端制造业的精密装配检测。目前还在实验室阶段，没有上产线。

光流作为补充信号

除了关键点时序，我们还用了光流作为辅助信号。

光流能捕捉像素级的运动方向和速度。比如「拧螺丝」和「检查螺丝」，关键点可能差不多，但光流图不一样——拧螺丝时手部有明显的旋转运动，检查时手基本静止。把光流的运动方向直方图作为额外特征拼接到时序特征里，区分度能提升不少。不过这块实现起来有些复杂，所以也可以把光流单独作为约束条件。

计算开销也不大，OpenCV的光流（Lucas-Kanade）在CPU上就能实时跑，一帧几毫秒。

但光流在工业现场有一个现实问题需要注意。 光流对粉尘、震动、频闪、运动模糊非常敏感，尤其在煤矿、焊接、机加工这些环境恶劣的场景，光流很容易算出来全是噪声。所以实际项目里很多团队最后会降级成关键点轨迹或者直接用pose velocity，而不是长期依赖dense optical flow。如果你的场景比较干净（电子厂装配这类），光流没问题。如果环境恶劣，光流可能反而帮倒忙。

实际落地建议

如果你的场景里动作差异大（比如拿工具vs放工具），方案A的滑动窗口就够了，零成本。

如果动作相似度高（比如拧螺丝vs松螺丝），用方案B的时序动作分割，1D卷积就够了，不需要LSTM。

如果还有光流可以加的，加上光流特征，相当于多了一个维度的判别信号。

Transformer留给以后算力不是瓶颈的时候再说。

---

问题3：一个摄像头能不能同时检测多个工位？

这个问题很多工厂老板问过，因为直接关系到成本：

「能不能一个摄像头拍两个甚至三个工位？这样能省不少钱。」

答案：技术上可以，但强烈不推荐。除非你的工位布局满足特定条件。

技术上怎么实现

实现原理很简单，在画面里划分多个检测区域（ROI），每个区域对应一个工位。系统对每个区域独立做检测和状态跟踪。YAML配置大概长这样：

cameras:
  - id: cam_1
    source: 0  # USB摄像头
    zones:
      - id: workstation_1
        polygon: [[50,100], [400,100], [400,600], [50,600]]
        sop_file: sop_line1.yaml
      - id: workstation_2
        polygon: [[450,100], [800,100], [800,600], [450,600]]
        sop_file: sop_line2.yaml

一个摄像头画面，左右各划一个区域，各跑各的SOP检测。代码上就是把每一帧先裁剪，然后分别送进检测流水线。

看起来很美好。但实际上坑很多。

坑在哪里

第一个坑：遮挡。

两个工位并排放，工人如果身体胖一点、动作幅度大一点，手就会伸到隔壁工位的区域里。隔壁工位的检测就会报「有人进入了操作区」，但这个人不是在这个工位操作的。这种误报很难通过算法消除，因为你无法判断「这双手属于哪个工位的工人」。

第二个坑：距离和角度。

一个摄像头要覆盖两个工位，要么装得高、要么装得远。装高了俯拍角度大，手部动作看不清，姿态估计精度下降。装远了分辨率不够，YOLO对小目标的检测能力会打折。我们实测过，一个摄像头覆盖两个工位时，关键点检测精度比单工位低15%-20%。

第三个坑：光线不均匀。

两个工位的光照条件可能不一样，一个靠窗一个靠墙。如果只用一个摄像头，曝光参数只能设一个值。要么靠窗的那个过曝，要么靠墙的那个太暗。两个工位的检测精度不可能同时达到最优。

第四个坑：性能。

一个画面里要检测的目标数量翻倍。原本一个工位检测3-5个目标，两个工位就是6-10个。多工位会增加检测目标数量、ROI裁剪和后处理开销，加上如果每个区域还要单独跑姿态估计或光流计算，整体延迟会明显上升。

什么情况下可以一拖二

只有一种情况我推荐一拖二：两个工位完全相同、工人动作高度标准化、工位之间有物理隔板。

比如电子产品装配线，两个工位都是插拔同一个型号的连接器，中间有隔板挡住互相的视线。这种场景下一拖二是可行的，因为动作模板一样，遮挡风险低。

什么时候绝对不要一拖二

以下情况，老老实实一个摄像头对一个工位：

1. 动作差异大：两个工位做完全不同的SOP，时序模型会更混乱
2. 工人会交叉走动：比如需要到公共区域取物料
3. 对检测精度要求高：比如医疗器械装配，漏检一个步骤可能影响产品安全
4. 工位间距小：工人身体会进入隔壁区域

成本算一笔账

很多人想一拖二是因为觉得能省钱。但算一下实际成本：

• USB摄像头一个
• 摄像头支架一个
• 一拖二多出来的开发调试成本：至少多花2-3天

为了省点点摄像头钱，多花2-3天调试，而且上线之后误报率还更高，这笔账怎么算都不划算。

结论就是：一个摄像头对一个工位，别省这个钱。

---

问题4：多人同时在画面里怎么办？

「我们一条线上有3个工人同时操作，系统会不会搞混？」

这个问题跟第三个问题（一个摄像头拍多个工位）本质上是一样的——核心挑战都是「画面里有多个目标，怎么分辨谁是谁」。

第三个问题讲的是空间维度的分离（多工位），这个问题讲的是人维度的分离（多人）。解法思路完全一样：能物理隔离就物理隔离，别硬上算法。

为什么多人追踪难

目标检测能告诉你「画面里有3个人」，但很难持续追踪「第1个人做了什么，第2个人做了什么」。工人互相遮挡、走位交叉的时候，追踪容易断裂。

这跟问题2（相似动作区分）的技术挑战其实是一脉相承的。问题2需要区分「同一时间两个相似的动作」，用时间维度解决。这个问题需要区分「同一时间不同人做的动作」，用空间维度解决。本质上都是单帧信息不够，需要额外的上下文。

推荐方案

首选：物理隔离。 一个摄像头对准一个工位，一个人在一个画面里。硬件成本极低，可靠性最高。

备选：区域划分。 如果必须两个人配合操作，在画面里划分区域，每个人固定在自己的区域里操作。跟问题3里一拖多工位的ROI划分是同一个思路。

zones:
  worker_1_area:
    polygon: [[100,100], [400,100], [400,500], [100,500]]
  worker_2_area:
    polygon: [[450,100], [750,100], [750,500], [450,500]]

最后手段：追踪ID绑定。 用DeepSORT等追踪算法给每个人分配ID，步骤状态跟ID绑定。技术难度最高，目前还在优化中。

务实建议

第一步先确认能不能调整工位布局。大部分情况下调整布局的成本远低于开发多人追踪算法的成本。花了大半年搞多人追踪，最后发现调整一下工位布局就好了——这种弯路我见过不止一次。

---

问题5：误报率高不高？能不能调到0误报？

「如果系统老是误报，工人会觉得很烦，最后干脆关掉。你们的误报率怎么样？」

真话：做不到0误报，但可以做到「工人不烦」。

任何一个跟你说误报率能做到0的，要么没真正上过线，要么在骗你。

先理解两个指标

• 漏报：该报警的时候没报（比如工人跳了步骤系统没发现）→ 危险
• 误报：不该报警的时候报了（比如工人正常操作系统说是违规）→ 烦人

这两个指标是矛盾的，调低误报往往调高漏报，反之亦然。

实际策略：看场景

安全类场景（戴安全帽、不进入危险区域）：宁可误报，不可漏报。 漏了一次可能出事故，多报几次最多工人烦一下。

质量类场景（装配步骤、操作规范）：平衡两者。 在固定工位、动作标准化、单人操作的场景下，我们的目标是误报率低于5%，漏报率低于1%。如果场景复杂度更高（多人协作、强遮挡、非标动作），这个指标需要根据实际情况调整。

降低误报的三个关键参数

YAML里的三个参数可以精细调整：

1. 距离阈值（proximity_threshold）

detection:
  object: "tool"
  proximity_threshold: 50  # 像素

手距离工具多少像素算「接近」？50像素太灵敏（路过就算），80像素更稳定。这个值要根据摄像头距离和画面分辨率来调。

2. 持续时间（duration_min）

detection:
  action: "touch"
  duration_min: 3  # 秒

触碰设备不到3秒不算「操作」。这个参数能有效过滤「手碰了一下就走」的情况。

3. 超时时间（timeout）

timeout: 30  # 秒

给工人足够的操作时间。如果步骤实际需要20秒，超时设15秒就会误报。建议设为实际时间的1.5-2倍。

报错了怎么办？

系统会自动保存违规发生前5秒的视频片段。你可以回看这个片段，判断是真的违规还是误报。如果误报，调一下上面三个参数就行。

最重要的一点：上线前一定要用真实工人的操作视频跑一遍。 实验室里怎么调都不如现场数据有说服力。

---

问题6：AR/MR眼镜能做SOP行为检测吗？不是比摄像头更好？

「有没有做过AR眼镜+SOP行为检测？感觉比固定摄像头灵活多了。」

这个问题问得很好，因为我之前在烟草行业确实用过Meta Quest 3做过MR眼镜的应用，也一直关注这个方向。

先说结论：能做，但目前不划算

为什么理论上更好？

AR/MR眼镜相比固定摄像头，有两个天然优势：

第一人称视角（最核心的优势）。 固定摄像头拍的是第三人称，如果工人侧身、被遮挡、或者手伸进机器内部，摄像头就拍不到了。而眼镜戴在工人头上，他的视线就是镜头视角——看哪里拍哪里，不存在遮挡问题。

解放双手。 摄像头方案需要工人面对镜头操作，眼镜方案工人可以自由移动，不需要调整工位布局。

为什么实际落地难？

先说技术层面。

续航是最大的坑。 我在烟草用Meta Quest 3的时候，满电实际使用时间不到2小时。工厂一个班次8-12小时，中间要换好几次电。而且充电的时候工人就没法戴，等于这段时间没在检测。

工人抵触情绪严重。 一个重达500多克的东西绑在头上，8小时戴下来脖子和太阳穴都疼。加上眼镜会录像，工人觉得你在监视他。

2026年4月印度工厂事件就是一个典型案例——印度服装和电子工厂的工人被要求头戴摄像头记录操作动作，视频在网上疯传，全球讨论。争议核心：这些工人到底是在工作，还是在训练取代自己的AI？ WION、India Today、Reddit等主流媒体都报道了这件事，评论区一边倒地批评企业「让工人亲手训练自己的替代者」。

成本高。 工业级AR眼镜（HoloLens 2已停产，继任者Singray G2单台约2-3万人民币），对比USB摄像头，差了数百倍。一个8工位的车间，摄像头方案和眼镜方案的硬件成本差距非常悬殊。

主流AR/MR眼镜对比

设备	类型	价格	续航	适合场景
Meta Quest 3	消费级MR	~3000元	2小时	试用/Demo
HoloLens 2	工业级AR	~2.5万	3小时	已停产
Singray G2	工业级AR	~2-3万	热插拔电池	HoloLens替代者
RealWear Navigator	工业级AR	~1.5万	8小时	巡检/维修指导
Vuzix M4000	工业级AR	~2万	4小时	物流仓储

我的判断

AR/MR眼镜+行为检测，是3-5年后的事，不是今天的事。

三个需要突破的点：

1. 重量：降到200克以下（目前最轻也要400克+）
2. 续航：做到一个班次不充电（目前最长8小时但性能有限）
3. 成本：单台降到5000元以内（目前工业级2万起步）

今天该怎么做？

如果你已经有MR眼镜（比如我之前在烟草用的Quest 3），可以用来做远程专家指导——现场工人戴着眼镜，远程专家看到第一人称视角，实时标注指导。这个场景已经成熟了，微软Dynamics 365 Guides和frontline.io都在做。

但如果是SOP行为合规检测（判断工人有没有按流程操作），今天还是固定摄像头方案更务实。

什么情况下值得用眼镜？

三种场景下，眼镜方案确实比摄像头更好：

1. 移动巡检：工人需要在车间走动检查多个设备（电力、石油化工）
2. 精密装配：工人需要低头看小零件，固定摄像头拍不到（电子厂、手表装配）
3. 远程指导：现场工人+远程专家的协作模式（新员工培训、疑难故障处理）

这三个场景的共同特点是：工人不是固定在一个工位上，固定摄像头覆盖不了。

烟草MR眼镜的实战经验

我在烟草行业用Meta Quest 3做过MR应用，核心经验就一句话：眼镜最适合做「辅助」，不适合做「监控」。

用眼镜给工人显示「下一步操作什么」（装配指导），工人不抵触，甚至觉得方便。但用眼镜记录工人「有没有按流程操作」（行为检测），工人第一反应是「你在监视我」。

技术问题可以解决，信任问题才是最大的障碍。

---

问题7：零件太小检测不到怎么办？状态机怎么判断？

「我们产线上有些零件特别小，比如螺丝、垫片、小插头，摄像头根本拍不清楚，这种怎么检测？检测不到的话状态机是不是就一直卡住？」

这个问题太真实了，基本每个做电子产品装配线的人都会碰到。

先说结论：别死磕视觉，换检测思路。

为什么小零件检测难

小零件检测不是模型不够强的问题，是物理限制。一个M2螺丝，直径不到2mm，你要在摄像头画面里清晰地拍到它，要么摄像头贴得特别近（那就看不到操作工人的手了），要么用高分辨率镜头（成本上去了，视野又窄了）。

更头疼的是遮挡。工人拿螺丝的时候，手指会挡住螺丝。插插头的时候，手掌会盖住插针。你想检测的目标，大部分时间都在工人手里藏着。

调了半天阈值也没用，物理问题不是算法能解决的。

四条实际可用的思路

思路一：加装特写相机

最直接的解法。主摄像头拍全景和人的动作，特写相机专门盯着零件区域。两个摄像头各干各的，特写相机只负责判断小零件有没有、在不在正确位置。

好处是特写相机可以离得很近，分辨率和视野都只为小零件服务，检测精度能拉满。成本也不高，一个USB摄像头加支架，几百块钱的事。

坏处是多了一个视频源，系统要同时处理两路画面。不过小零件检测本身不复杂（背景差分就能搞定），算力开销不大。

YAML里可以这样配：

cameras:
  - id: cam_main
    source: 0
    # 主摄像头，拍全景和人的动作
  - id: cam_macro
    source: 1
    # 特写相机，专门盯零件区域
    zones:
      - id: screw_tray
        sop_file: sop_part_check.yaml

主摄像头跑SOP流程，特写摄像头跑零件有无检测，两路结果汇总给状态机就行。

思路二：不检测零件本身，检测动作结果

这条思路适合不想加额外硬件的场景。与其问「螺丝有没有被拿起来」，不如问「螺丝现在在哪里」。如果螺丝原来在料盘上，现在不在了，那就说明工人拿了。

具体做法是给料盘区域做一个简单的有无检测，料盘上的螺丝位置是固定的，用背景差分或者简单的像素比对就能判断。不需要跑什么复杂模型。

思路三：用传感器做辅助判断

视觉搞不定的，传感器可以补。常见的搭配：

• 光电传感器检测小零件有没有被取走（几块钱一个，精度比视觉高）
• 称重传感器判断装配前后的重量变化（螺丝有没有拧上去，一称就知道）
• 限位开关判断有没有插到位

这些传感器信号可以跟状态机对接。YAML里加一个sensor类型的步骤，状态机不只看视觉输出，还看传感器信号。

思路四：放宽状态机的判断条件

如果既不想加传感器，又检测不到零件，还有一个折中方案：状态机不要求「检测到零件被拿取」，而是只要求「手出现在零件附近并停留了一段时间」。

逻辑上就是，手在那个区域待了3秒以上，就算你完成了这个步骤。不是100%准确，但大部分情况下工人不会对着空气假装操作。

YAML里配一下就行：

detection:
  type: "approach_zone"
  zone: "screw_tray"
  duration_min: 3  # 手在螺丝盘区域停留至少3秒

这样状态机就不用纠结「到底检测到螺丝没有」了，检测人的动作就够了。

我的建议

四条思路优先级：

1. 预算允许就加特写相机（思路一），最直接，几百块钱解决问题
2. 不想加硬件，先试放宽条件（思路四），零成本，改个配置就行
3. 效果不行就加传感器（思路三），光电传感器几十块钱，性价比极高
4. 思路二（检测动作结果）适合零件位置固定的场景，可以跟上面几条组合用

别一上来就想搞完美的视觉方案。能解决问题就行，管它是视觉还是传感器。

---

一个被忽略的成本：时序标注

最后聊一个这篇文章没有展开、但可能是整个SOP检测最耗成本的问题——时序标签到底怎么做。

很多人觉得行为检测最难的是模型，其实不是。模型有现成的（YOLO检测目标、MoveNet提取关键点、TCN做时序分割），框架也搭好了。真正耗时的是数据标注。

空间标注相对简单——框一个螺丝刀，画一个工位区域，点几个关键点，这些有成熟的标注工具，标注员培训半天就能上手。

但时序标注完全不一样：

• 「拿起工具」从哪一帧开始？手刚开始靠近？还是手指碰到工具？
• 「放下工具」哪一帧结束？手指离开工具？还是手已经收回？
• 「焊接」持续多久？从起弧到收弧？还是从电弧稳定到消失？
• 两个动作重叠怎么办？工人左手在拿零件、右手在操作设备，你标谁？
• 工人咳嗽，抓痒这些意外动作怎么处理？

我之前在一个新产线上做标注，光是定义「每个动作的时间边界在哪里」就跟现场工程师讨论了两天。不同人对边界的理解不一样，标注出来的标签一致性很低。后来花了一周时间写了一个详细的annotation protocol（标注规范），把每种动作的开始帧、结束帧、重叠规则都定义清楚，标注质量才稳定下来。

也就是文章前面提到的事件切分。

这件事直接决定了TCN能不能训好、时序边界稳不稳、模型泛化能力强不强。工业行为检测最后大量时间其实耗在标注规范定义和标签一致性上，而不是模型训练本身。

后续的答疑文章我会专门写一篇「工业行为时序数据到底怎么标」，把我们的标注规范和踩坑经验分享出来。

---

写在最后

这7个问题，其实都指向同一个核心矛盾：实验室里的方案，到了工厂现场就会变形。

状态机在Demo里跑得很漂亮，上了产线就发现并行操作处理不了。YOLO在测试集上精度很高，到了现场就发现两个相似动作分不开。一个摄像头拍多个工位省了几百块钱，结果调试成本多花了好几天。

这些坑，模型再强也绕不过去。因为它不是算法问题，是工程问题。

我自己踩完这些坑之后，最大的感受就是：别在实验室里追求完美方案。 先用最简单的架构跑通流程（状态机+单工位+物理隔离），到了现场碰壁了，再根据你的具体痛点选择升级方向。状态机能跑通就先用状态机，留好扩展接口，后面换成事件驱动的时候改动最小。

还有一个建议：能硬件解决的问题，别硬上算法。 小零件检测不到？加个特写相机，几百块钱搞定。光线不均匀？加个遮光罩，比调算法靠谱一百倍。多人追踪搞不定？调整一下工位布局，可能比开发DeepSORT省几个月。

SOP系列答疑会持续更新。有其他问题评论区或私信问。

---

📎 相关阅读

• 工业视觉踩坑实录（六）：SOP行为检测：用AI替你盯着工厂流水线
• 工业视觉踩坑实录（十三）：SOP系列之二，“你们这是帮我们，还是监视我们？”