装配车间里最让我头疼的一件事，就是明明每个工位都贴了SOP，也做了岗前培训，但漏装、错装、顺序颠倒这类问题依然隔三差五冒出来。后来我们上了视频分析方案，把AI和SOP结合起来，才真正把装配过程管住了。这篇就跟大家聊聊这个项目的完整思路：怎么用AI视频分析盯住装配流程里那些“看不见”的质量隐患，以及落地过程中踩过哪些坑。
如果你正在做产线工艺数字化、智能制造转型，或者只是对AI在工业场景的应用感兴趣，这篇内容应该能给你一些可复制的经验，而不是停留在PPT层面的概念。
1. 传统SOP在装配现场的三大失控点
1.1 漏装错装：人工目检的盲区
我先说一个真实案例。有个线体做变速箱装配，一道工序要打28颗螺栓。SOP写得很清楚：“用M8螺栓对角打紧，扭矩25N·m”。但工人实际操作时，偶尔会漏掉一两颗，或者某一颗没打到位。这种问题，靠终检人员的眼睛根本发现不了——螺栓在壳体内部，外观上看不出区别，扭矩抽检也做不到逐颗覆盖。
问题出在哪儿？SOP管的是“应该怎么干”，但没人实时确认工人“实际干了什么”。抽检合格率高，不代表每件产品都合格。传统的质量管控，本质上是抽样逻辑，而装配过程的质量是连续发生的，抽样必然有漏网之鱼。
我自己做过统计，在一条15工位的装配线上，完全靠人工目检的漏检率大约在1%~3%之间。听起来不高，但放到年产量几十万件的生产线上，就是每年几千件不良品流到市场。这就是为什么必须引入实时视觉监督。
1.2 工艺顺序倒置：流程文件管不到的实时性
比漏装更隐蔽的是顺序错误。比如某个产品要求先装A零件再装B零件，如果工人先装了B，再硬塞A，就会导致密封圈被压变形。这种问题在终检时的外观检测完全看不出来，但装到下游总成里，异响、泄漏、配合不畅都是它引发的，最后用户拿到的是一台“带病出厂”的产品。
更麻烦的是，装配顺序的正确性没办法靠班组长盯出来。一个班8小时几百件产品，班长不可能每件都盯。抽检时是规范的，但不抽检时就完全靠工人自觉。SOP文件理论上约束了顺序，但文件没有“眼睛”。
过去我们用过纸质巡检单，也用过MES报工，但这些都是事后记录。要真正管住顺序，必须有一个系统，在工人动手的那一刻就能判断“这一步做对了没有、做的是不是当前该做的那一步”。
1.3 为什么传感器方案解决不了这个问题
你可能想，扭矩扳手可以监控力矩数值，传感工装可以检测零件是否存在，是不是就够了？不够。扭矩扳手只能告诉你“这颗螺丝打了多少牛米”，但确认不了工人打的是哪颗螺栓、打了几颗、是不是按对角线顺序打的。
传感工装（比如光电传感器、接近开关）能确认零件放上去了，但确认不了“先放了谁后放了谁”，也判断不了动作是否合乎工艺标准。传感器解决的是结果量测，而装配过程的核心风险在操作过程本身。
所以最终的落地方案，一定是视觉为主、传感器为辅。视觉能看到动作、顺序、零件状态，传感器可以配合做拧紧力矩、气密性这些视觉看不透的物理参数的确认。
2. 视频分析识别装配动作的技术架构与难点
2.1 一条三阶段算法链：检测、跟踪、动作语义理解
实地做下来，视频分析盯装配动作的核心算法链是分三段的：目标检测、目标跟踪、动作语义理解。我分别说。
第一段，目标检测。用YOLOv8或者RT-DETR这类检测模型，在画面里把关键对象框出来：工人的手、工具（螺丝刀、电枪、压装头）、零件本体、工装定位销之类的。模型不复杂，关键是把“这个框是什么”搞清楚。至少每个工位要区分5~8类目标。
第二段，目标跟踪。ByteTrack、DeepSORT都行。检测是逐帧做的，但如果每一帧都重新识别目标是谁，就会在快速动作时丢掉对象ID。跟踪的作用是把同一只手、同一把工具在连续帧中的轨迹串起来，这样才能分析“手从哪里移动到了哪里”。
第三段就是动作语义理解。这一步有几种做法：基于骨架的姿态识别（MediaPipe、HRNet提取关键点），或者基于交互区域判断的ROI分析。实际做下来，骨架识别在办公室场景里很准，但在装配车间里，手部和小零件互相遮挡严重，骨架点经常被切断，所以我更推荐另一个思路，两步法：先用检测器锁定“人和零件、人和工具”发生交互的区域，再在这个区域内判断交互关系，比如工具是否靠近螺栓位、手是否把零件从料盒移到了工装上。不要一上来就做全局动作分类，那样极易误报。
| 算法层 | 具体方法 | 输出 | 作用 |
|---|---|---|---|
| 目标检测 | YOLOv8 / RT-DETR | 目标框+类别 | 知道画面里“有什么” |
| 目标跟踪 | ByteTrack / DeepSORT | 稳定轨迹ID | 知道目标“分别是谁、怎么动” |
| 交互语义 | ROI判断 / 骨架姿态 | 工序状态变化 | 知道动作“是否符合SOP” |
2.2 装配场景特有的视觉陷阱
这个必须单独拿出来讲。办公场景的人体识别，和车间装配场景的视觉识别，完全不是一回事。装配场景里有几个非常特殊的干扰源：
第一是金属反光。拉丝不锈钢、铝合金表面在灯光下会形成高光斑，把零件本身原本的纹理特征全淹掉了。第二是透明或深色零件，很多密封圈、胶管是黑色的、透明的，在暗背景里对比度极差，检测器经常抓不到。第三是防静电手套，普遍是灰色的，纹理本来就很弱，手一旦快速移动，检测框就跟着抖。
还有节拍问题，装配线单个动作往往只有3~5秒。如果相机帧率不够，或者算法推理速度太慢，根本抓不住动作细节。我们当时把相机帧率定在30fps，抽帧处理到15~20fps，在这个频率下，快速拧螺栓、快速插拔气管这类动作才不会丢关键帧。
处理反光和低对比度的思路，不全是算法的活，很多问题可以在相机端就解决。后面部署部分我会细说。
2.3 用“状态机+视频流”定义工序边界
视频分析最难的地方，不是识别某个动作，而是判断“当前这个动作是不是SOP要求的那一步”。流程文件的描述是自然语言，机器没法直接执行。所以一个关键做法是：把SOP定义成状态机。
每道工序，其实就是一系列状态的迁移。以装配端盖为例，SOP写在纸上是：“取端盖，放到壳体上，对准定位销，用6颗M8螺栓对角打紧。”
转成状态机是这样的：
{ "step": 4, "name": "端盖预装", "preconditions": { "cover_detected_in_hand": true, "housing_stationary": true }, "actions": [ { "object": "cover", "action": "place_onto", "target": "housing" } ], "completion_conditions": { "cover_on_housing": true, "alignment_pin_visible": true }, "timeout": 8000, "next_step": 5 }每帧视频送入系统后，算法输出的是“手部位置、工具类别、零件状态”这些底层描述，每个值喂给状态机，状态机判断前置条件是否满足、当前动作是否匹配SOP、完成条件是否达成。如果超时未满足，就触发报警。
这个设计的核心优点是：SOP本身就是规则，不用让模型自学工艺逻辑。模型负责感知，状态机负责判断，两者解耦之后，即使换产品、改工艺，只需要更新状态机配置，不用重新训练整个模型。
3. 把SOP文本变成AI可执行的监督逻辑
3.1 SOP数字化：从自然语言到结构化状态机
这块是整个项目的真正难点，比训练模型难得多。我当时花了一周时间和工艺工程师一起，把线体上三十多道装配工序全部做了结构化拆解。
很多东西只有动手做才意识到。比如“对角打紧”这种词，人懂，但机器不懂。你要把它拆成“螺栓1→螺栓5→螺栓3→螺栓7→螺栓2→螺栓6→螺栓4→螺栓8”这个顺序，或者至少定义成“不允许连续打紧相邻两颗”。再比如“扭矩25N·m”，视觉根本看不出扭矩，这就需要和扭矩枪的数据联动，视觉负责确认位置，传感器负责确认数值。
结构化之后的结构，就是上一节写的那种JSON状态机。每一道工序都要定义：
- 前置条件：这一步开始前，系统必须观察到了哪些状态（比如“上一零件已压装完成”“端盖在料盒中已可见”）
- 动作清单：这一步包含哪几个动作，动作的对象是谁
- 完成判据：系统看到什么，才认定这一步真正完成
- 超时窗口：这一步正常需要多久，超过就预警
这个定义过程必须由工艺工程师主导，算法工程师配合。如果让算法工程师自己拍脑袋定状态机，最后做出来的系统会跟产线的真实工艺脱节，上线就是灾难。
3.2 相机的选型与工位布点
硬件选型没有那么多玄学，关键是匹配工位的实际情况。我们用的方案大概是这样的：
相机：500万像素黑白/彩色工业相机，帧率在30~60fps，配8~12mm定焦镜头。黑白相机在光照不足时反而更好用，但对颜色识别不友好。如果工序里需要区分不同颜色的零件，就用彩色相机，否则黑白就够。
安装位置：优先从操作者前方上方向斜45度俯拍，这个角度能同时看到手部动作、料盒区域、工装夹具区。千万不要正上方拍，正上方容易被手臂遮挡工件。
补光：用低角度的环形光源或者顶部面光源，关键是要匀。直射光在金属件上肯定反光反到你怀疑人生，光源方向要尽量和相机轴线分开，形成大角度，才能压住镜面反射。
如果工位空间允许，还可以加一个侧方位相机专门拍零件状态，和一个正上方相机专门拍手与工具的交互。多一个视角，状态机的判断准确率能提升一大截，但成本也上去了，看预算取舍。
3.3 样本采集与标注的正确姿势
很多人一听到AI就以为要采几万张图，其实装配场景没那么夸张。我们的做法是：先在目标线体上连续录制20~30小时的正常生产视频，然后切成有代表性的片段。
标注的重点不是逐像素分割，而是标注“零件状态”和“工序完成时刻”。对每一帧，我只需要标注：画面中有什么零件、零件在什么位置（料盒/工人手中/工装上）、当前处于哪一步工序、这一步是否完成。
类别的定义要跟着SOP走，不要想标注什么就标什么。比如某道工序的关键点是“端盖被放到壳体上”，那标注的核心就是“cover_on_housing”这个状态从false变true的那个时刻。每个工序准备500~1000个正样本、200~500个负样本就够用了。
负样本特别重要，而且容易被忽略。负样本就是错误动作的录像，比如漏装拧紧、顺序颠倒这类情况。如果没有足够的负样本，模型会倾向于“一切都很好”，误报率低但漏报率极高，那就失去了监督的意义。
3.4 模型训练和推理的硬件选择
训练端不用纠结，一张RTX 4090或者更低的显卡都够用。装配场景的检测模型不大，YOLOv8s或者YOLOv8m级别就足够了，训练时间大概是一两天。
推理端是重点。装配线上往往不是只有一个工位，至少是十几个工位。如果每个工位放一台推理盒子，成本太高。更好的做法是一台推理服务器挂多路相机，我们用的是Jetson Orin或者带一块GPU的x86服务器，一路一路分配流。单帧推理延迟控制在50ms以内，状态机综合判定延迟在500ms以内，对装配线的3~5秒节拍来说完全来得及。
还有一个部署阶段的建议：千万别一上来就做“在线报警+停线”。先离线跑录像验证，再在线报警但不联动设备，最后才接通MES联动。一步到位的结果往往是误报太多导致线体停摆，工人和管理层都对系统失去信任，项目直接夭折。
4. 现场部署中的误报排查与节拍适配
4.1 误报日志的排查链路：一次漏判的根因分析
上线跑了一周之后，我们遇到一个很典型的误报投诉：某个工位，明明工人已经把6颗螺栓全部打完了，系统还是报了“漏装螺栓”。工人很不满，说系统是瞎报。
我当时没有急着调模型，而是走了一遍完整的排查链路：
第一步，先翻报警日志，找到那条报警的时间戳。第二步，把那一时刻前后的录像帧全部导出来，人眼重新看一遍——确认工人确实完成了打螺栓动作。第三步，看算法在这一段时间内的检测置信度曲线。结果发现：框住螺栓的置信度在第5颗螺栓上突然掉到0.4以下，导致算法认为螺栓“消失了”。
第四步，我回看了那几分钟的录像，发现操作者身体微微侧了一下，佩戴的工牌反光刚好照在螺栓区域，导致模型把螺栓区域识别成了高光噪声。第五步，解决办法不是加训练数据，而是在输入端处理反光问题——在镜头前加了偏振片，弱化镜面反射。处理后，同类误报直接归零。
这条链路其实每次都适用：报警日志 → 录像回放 → 置信度曲线 → 干扰源定位 → 硬件/软件调整。如果跳过中间步骤直接闷头调模型，大概率把参数改乱也解决不了问题。
4.2 光照、反光、遮挡的处理经验
装配线的光照问题，我强烈建议把它当硬件问题处理，而不是算法问题。
金属零部件的高反光，用偏振片基本能压住，偏振方向要实际去转角度试，找一个最佳的消光位置。透明零件和黑色零件，要加背景板，在工位背后放一块和零件颜色不同的漫反射板，对比度一下就起来了。
还有一个很多人不注意的坑：车间荧光灯的频闪。工业相机是用固定快门，一旦快门速度和灯管频率接近，画面就会出现明暗条纹。这种问题会一帧一帧地影响识别结果，让模型忽好忽坏。解法是：把相机曝光模式调成外触发或者用频闪匹配的LED光源，避开和市电频率的同步。
遮挡问题是最无解的。装配作业中，人手、工具、零件互相遮挡是常态，指望模型百分之百持续识别不扑空，是不现实的。我们的处理方案是设置一个“容忍窗口”：允许在一定时间（比如2秒）内，某几个目标识别置信度低，只要这个窗口内有一个高置信度识别结果，就认为目标存在。对状态机来说，用“一段时间内的多数帧判断”而不是“单帧判断”，能显著降低漏报率，同时不增加误报率。
4.3 多工位并发与节拍瓶颈的妥协方案
一条装配线往往有十几二十个工位，不可能每个工位都配一台高配推理机。我们最终的做法是按工位风险等级分优先级：对质量影响最大的关键工位（拧紧、压装、密封面安装）用一路相机一路推理流，其余工位用低帧率抽帧共享一路推理流。
但多路并发必然带来推理资源抢占问题。我的经验是：在服务器上按工位配置帧率配额，重要的工位给高帧率（30fps），次要工位给低帧率（10fps），而不是所有工位都跑满帧。这样既能控制成本，也能保证关键工位的响应及时。
另一个节拍问题，是关于报警时机的。装配线的节拍非常紧凑，如果算法在工位中途报警，工人正在操作，根本来不及看屏幕，反而造成中断。我们最终的方案是：报警不打断，先进证据缓存区。当这道工序结束时，声光提示“本工位存在疑似异常，请复核”，同时屏幕上弹出当时的异常截图。这样既不拖慢节拍，又能保证异常的强制复核。
4.4 与MES系统反向联动的分层管控
系统判定的结果最终要落到管理动作上，不能停在报警日志里。我们和MES对接时，设计了三级联动管控：
一级：正常结果，只记录工序完成时间戳和证据片段索引，写入过程质量表。二级：质量风险（比如某道工序扭矩偏低但视觉正常），推送Andon看板，提示班组长关注。三级：严重异常（漏装、顺序颠倒、异物残留），直接拦截工装流转，必要时停线，同时把证据推送到返修工位。
对接协议用的就是常规的HTTP/REST或者MQTT，消息体一般包括工位ID、工单号、工序步骤号、异常类型、证据视频地址、评分置信度这些字段。MES侧拿到消息后，按规则引擎分配不同的处理流程。
这块我要提醒一件事：不要让系统一上来就具备停线权限。停线权限要分级开放，先让系统跑一个月，把误报率压到可接受范围，再开放到高等级异常的自动停线。否则头一个礼拜系统天天误停线，产线主管会直接要求拆掉这套设备。
5. 系统上线后的真实收益与后续演进
5.1 质量数据的真实变化：不只是漏装下降
系统跑了三个多月之后，我们把数据拉出来做了一次对比分析。漏装、错装率比上线前下降了八成以上，但这只是最表面的收益。
更重要的变化是，管理方式从“事后抽检”变成了“过程透明”。以前产线经理想知道某个批次的质量情况，得等抽检报告，现在每天早会上直接看“工序违规热力图”，哪个工位哪个时间段的违规高发，一眼就看得清清楚楚。
还有一个之前没想到的收益：质量追溯有了可视化证据。有一次客户投诉某个产品异响，我们直接调出该产品对应工位的视频片段，确认了装配过程是否存在异常动作。以前这种事要吵半天，现在视频一放，真相就在那里。内部复盘从以小时计，缩短到了分钟级。
5.2 让SOP从“死文档”变成活流程
我最有感触的一点，是这套系统让SOP的更新有了数据驱动。以前工艺工程师改一版SOP，主要靠经验和客户投诉反馈。现在，SOP版本更新之后，系统能自动统计每个步骤的首次通过率。
有一个工位我们发现报警率一直很高，正常生产老是触发“顺序异常”提示。调出过程数据一看，发现该工序SOP里定义的“先装左侧卡扣再装右侧卡扣”，在人体工学上根本不合理，工人实际操作都是先右后左。后来工艺工程师去现场确认，确实是把顺序定义反了，修正SOP之后报警率立刻降下来了。
这就是从“稽查”到“辅导”的转变。系统不再是单纯给工人挑错，它把产线的隐性瓶颈显性化了——有些报警频繁的工序，本质上是SOP设计不合理，不是工人操作不规范。
5.3 后续还能怎么扩展
这套架构的后续演进方向也很清楚。一条是往工具联动的方向走：视觉判断“螺栓位置是否正确”，扭矩数据判断“力矩值是否达标”，两者融合，对装配质量的定义就从“动作合规”升级到“参数合规”。
另一条是往预测性分析走：把视频分析的过程数据和设备工艺参数（气压、温度、振动）放在一起建模，试图在异常发生之前就识别出风险工序。这块目前我们还只是数据积累阶段，但方向是明确的——用AI把过去不可见、不可量化的操作过程变成可持续分析的资产。
说点实在的
整个项目做完，我最大的体会是：先别追求一步到位的全自动智能化，先把离散装配工序里“最容易漏、最容易错”的那几道工序，装上一双看得见的眼睛。视频分析不是要替代人的经验，而是把人的经验和规则变成每一件产品的数据化安全保障。如果你也在推进类似的项目，我建议从一个小工位、一道关键工序、一个有明确痛点的点开始做验证，跑通了再横向铺开，会比一开始就想建一套完整的系统要稳得多。
