车间现场装了一圈摄像头之后，紧接着就遇到了新问题：画面是有了，但靠人盯着屏幕看工人有没有戴手套，根本不现实——十几路画面轮播下来，眼睛都看花了，漏掉的情况还是不少。后来我用YOLOv8搭了一套安全手套佩戴识别检测系统，把摄像头画面接进去，模型自动判断画面里的人物是否佩戴手套，未佩戴就直接在UI界面上标出来并记录日志。整个项目包括YOLOv8模型训练、YOLO格式数据集制作、PySide6界面、Python源码和训练好的权重文件，今天我把整个从零到落地的过程完整拆开讲，适合正在做工业安全相关视觉项目、或者想快速上手YOLOv8做实际检测任务的人。
这套系统的核心价值在于：它不是一个只跑通Demo的玩具，而是一个能实际部署到现场、支持实时视频流检测、带统计和告警能力的小型工业级应用。我踩过的坑、调过的参数、删掉重做的数据集，都会一并写出来。
1. 项目定位：先搞清楚要检测什么、什么是难点
1.1 检测目标与类别定义
这个项目要解决的需求很明确：在作业区域通过摄像头自动识别人员手部是否佩戴安全手套。实际拆解下来，检测目标有两种定义方式。一种是直接把整只手框出来，然后判断属于“戴手套”还是“未戴手套”；另一种是更细粒度地检测，把手套本身作为目标对象，检测到手套框说明佩戴了，检测不到再加上手部关键点辅助判断。后者在算法复杂度上高不少，对数据集的要求也更苛刻。
我最终采用的是第一种：定义两个类别，glove_worn（戴手套）和glove_not_worn（未戴手套）。因为YOLOv8是目标检测模型，它输出的是边界框和类别置信度，如果我们直接对手部区域分类，模型学到的是“手部+手套”的整体视觉模式，比单独检测手套再匹配手部要稳定得多。实际训练和推理结果也验证了这个思路：在遮挡、侧手、握拳等复杂姿势下，整手区域的分类准确率明显更高。
另一个值得注意的设计决策是：很多类似项目一开始就把类别拆得很细，比如“左手戴右手没戴”“白色手套”“蓝色手套”等。后面你会发现数据集根本收集不齐，标注工作量翻倍，模型还容易混乱。安全手套检测这类场景，二分类已经覆盖了绝大多数业务需求，真要细分可以在后续迭代中用同一份数据进行扩展。
1.2 为什么选YOLOv8而不是其他模型
目标检测领域可选方案很多，YOLOv5、YOLOv8、Faster R-CNN、SSD、CenterNet等各有特点。选择YOLOv8作为核心模型，我主要看中几点。
首先是速度和精度的平衡。工业现场部署不可能每台机器都配顶级显卡，普通工控机或者上一代GPU才是常态。YOLOv8n和YOLOv8s这两个轻量版本在保持不错mAP的同时，推理速度能做到实时甚至更高，满足视频流检测的基本要求。而Faster R-CNN虽然精度上限高，但推理速度往往只有个位数FPS，部署后实用性很差。
其次是工程生态。YOLOv8的官方仓库在训练、验证、导出、推理方面封装得很完善，PyTorch环境下几个接口就能完成全流程，后续导出ONNX再转为其他格式也很顺手。社区活跃意味着遇到问题容易找到案例参考，对非研究型项目来说非常关键。
对比YOLOv5，YOLOv8在C2f模块和Anchor-Free解耦头设计上做了升级，小目标检测能力和训练收敛稳定性都有提升。对于手套这种相对较小的目标来说，这个提升是有实际意义的。实际测试下来，在相同数据集和训练配置下，YOLOv8s的mAP50比YOLOv5s高出大概2到3个百分点，漏检率更低。
1.3 系统整体模块划分
整个系统在逻辑上拆成三个独立模块：数据层、模型层、应用层。
数据层负责数据集构建、标注、格式转换和数据增强，是整个项目的地基。模型层基于YOLOv8训练检测模型，输出训练好的权重文件。应用层用Python搭建UI界面，加载模型进行实时推理，展示检测结果、统计数据并保存记录。
数据层和应用层之间通过模型权重文件解耦。也就是说数据集改进了，只需要重新训练并更换权重文件就能更新检测效果，不需要改UI代码。这种模块化设计是我在一开始就刻意保留的，后续迭代维护会轻松很多，别人接手项目时也容易理解。
2. 数据集准备：识别系统真正的分水岭
2.1 数据收集：怎么拍、拍多少、拍什么
不少人以为模型效果不好是网络结构的问题，其实绝大多数情况是数据集的锅。安全手套检测这个任务，数据收集的关键不是数量，而是多样性。我在第一版数据集里只收集了800多张图片，看起来数量不多，但因为覆盖了多种光照、角度、手套颜色和背景，训练出来的模型在实际场景中反而比某些几千张的单一场景数据集更可靠。
数据来源主要有三个渠道。一是现场摄像头截取视频帧，这是最接近实际工况的数据，建议占数据集的大头。二是用手机在车间、实验室、户外等不同环境补拍，能提供摄像头视角之外的多样性。三是从开源数据集中挑选部分相关图片做补充，但要注意场景差异，如果训练集和实际部署场景差异太大，迁移效果会打折扣。
采集时有个容易忽略的点：手的姿势和遮挡状态。不要只拍手掌摊开的照片，要包含握拳、抓握工具、伸手拿东西、双手在操作台下方等姿态。还要重点收集手套颜色与背景颜色相近的样本，以及强光、背光、暗光条件下的样本。第一版数据集里这类困难样本比例不足，导致后面模型在现场对深色手套在暗色背景下的目标几乎全部漏检。
2.2 标注细节与YOLO格式转换
标注工具我用的是LabelImg这类的开源工具，选择它主要是因为操作简单、团队上手成本低、导出的格式方便转换。标注时框选的是人手的整体区域，重点是包含手腕和部分小臂下沿，这样模型能学到更多上下文信息，而不仅仅是手指部分。很多新手标注时框得太紧，只框手掌，导致模型特征不足，推理时容易漏检或误检。
标注类别只有两类，操作相对简单，但整个流程还是花了将近两天时间。主要原因是边界的判断标准要统一：手套与袖口之间怎么截断，线手套和橡胶手套是否区分，戴了一半的算不算佩戴，这些都必须在标注前定好规则。我当时的规则是：手套完全覆盖手部且腕部以上有明确手套边界的算glove_worn，手套没有完全覆盖手部或手部裸露皮肤可见的算glove_not_worn。规则不提前定好，先后标注的样本会出现不一致，模型训练时就会困惑。
标注完成后，LabelImg默认输出是Pascal VOC格式的XML文件，需要转成YOLO格式的TXT文件。YOLO格式每行表示一个目标，结构是class x_center y_center width height，坐标均为归一化到0到1之间的相对值。我写了段小脚本做批量转换，并顺便检查是否有坐标为负数、宽度或高度为零的异常标注，这类脏数据会在训练时报错或导致损失值异常。
2.3 数据集划分和数据增强实践
数据整理完成后，按照train : val : test = 8 : 1 : 1的比例划分。划分时要注意按场景分组而不是完全随机。如果同一个视频里连续帧被随机分到训练集和验证集，验证结果会虚高，因为模型已经“见过”非常相似的内容了。我按视频片段分组，确保同一段连续画面只进一个集合。
数据增强方面，YOLOv8训练时默认启用了马赛克增强、随机平移、旋转、缩放等策略，能有效提升模型的泛化能力。但安全手套检测场景里，翻转、亮度调整、灰度化这几个操作尤为重要。手有左右手之分，水平翻转能帮助模型学到左右手的通用特征；车间光照变化大，亮度扰动让模型对明暗不那么敏感。
这里补充一个容易做过头的地方：旋转角度不宜设置过大。手套检测的目标形态相对固定，头部朝下手倒置的情况在现场很少出现。如果旋转角度调到90度甚至更大，模型会花大量参数去学习现实中很少出现的姿势，反而影响正常状态下的检测精度。我最后把旋转范围限制在正负15度以内。
3. 模型训练：配置、监控、调优一整套流程
3.1 环境与依赖安装
整个项目基于Python 3.9 + PyTorch + Ultralytics。安装过程比较简单，核心就三步：创建虚拟环境、安装PyTorch、安装ultralytics包。GPU版本的PyTorch需要提前确认与显卡驱动和CUDA版本的匹配关系，这一步如果装错，训练时会提示找不到CUDA设备，或者直接使用CPU训练导致速度极慢。
训练环境建议至少8GB显存，这样YOLOv8s模型在batch size为16的情况下可以正常训练。如果显存不够，可以降低batch size，但不要降得太低，否则BatchNorm统计不稳定，损失曲线会来回震荡。一般16GB显存跑YOLOv8s的默认配置完全够用，再大的模型比如YOLOv8m以上，在普通设备上就显得吃力了。
Ultralytics安装完成之后，还需要在项目目录下放一份数据集配置文件，用于指定训练集、验证集路径以及类别名称。这个YAML文件和YOLO格式的数据集是配套的，训练脚本通过读取这个文件知道去哪里找图片、数据集的类别数量是多少。路径建议写绝对路径，避免相对路径导致找不到文件的问题。
3.2 训练脚本与关键参数调整
训练命令用Ultralytics官方封装好的API就可以，核心参数包括模型权重、数据集配置、训练轮数、批次大小、输入图像尺寸、设备等。第一次训练我通常会先用默认参数跑一到两个epoch，确认数据加载、预处理、模型结构都能正常运转，再启动正式迭代。这样可以快速发现数据集格式问题，避免跑到一半才报错浪费时间。
针对安全手套检测这个特定任务，我在默认参数基础上做了几个调整。输入图像尺寸设为640，这是YOLOv8性能与精度都非常均衡的默认值，对于手套这种小目标，如果现场分辨率足够，可以尝试640的倍数，但要评估显存和速度的代价。训练轮数设为150轮，配合早停机制，当验证集指标连续多轮不提升时会自动停止，避免过拟合。
学习率方面，默认的0.01配合余弦退火策略效果已经不错。我做过对比实验，把学习率调到0.02后，前期收敛更快，但后期出现震荡；调到0.005则收敛变慢，最终精度相当。综合考虑，维持默认学习率最省心。还有一个容易忽略的参数是workers，它控制数据加载的并行进程数，设置太小会导致GPU等待数据，训练效率下降。
3.3 指标解读与常见训练陷阱
训练完成后，主要看三个指标：mAP50、mAP50-95和混淆矩阵。mAP50衡量的是IoU阈值为0.5时的平均精度，是这个项目最关注的指标，因为现场检测只要框的位置大致正确就能满足业务需求。mAP50-95更严格，适合研究场景，但对部署应用来说过于苛刻。
我训练的模型最终mAP50达到0.92左右，mAP50-95在0.71左右。看起来数字不错，但验证集指标好不等于现场效果就好。第一次训练完部署到现场后发现，模型对蓝色手套在蓝色工作台上的场景漏检明显。原因就是训练集中这类样本太少，模型没有充分学到手套与背景的边界特征。解决办法是回到数据集补充这一类样本，重新训练，而不是去调模型结构或换更大的网络。
另一个容易被忽略的坑是类别不平衡。由于现场大多数工人都正确佩戴了手套，随手一拍的视频帧里glove_worn样本数量是glove_not_worn的好几倍。模型会倾向把不确定的目标预测为多数类。处理方式包括收集更多未戴手套样本、对少数类做过采样、或者在损失函数中调整类别权重。实际项目中，补充样本比调损失更有效，因为真实样本带来的特征多样性是人工增强很难完全替代的。
训练过程中还可以利用Ultralytics自动输出的results.csv文件，里面记录了每个epoch的loss和指标变化。如果训练集loss持续下降而验证集指标停滞甚至倒退，基本可以判断过拟合，要检查数据增强是否过强、早停设置是否合理。如果训练集loss都不下降，则先看数据标注格式是否正确、学习率是否过大。
4. UI界面设计与实时推理集成
4.1 UI框架选型：PySide6还是Tkinter
项目需要一个能展示视频画面、实时叠加检测框、显示统计数据的界面，同时在点击按钮后能启动或停止检测。我对比了PySide6和Tkinter两种方案。Tkinter上手快、代码量少，但做视频显示需要配合OpenCV的画布转换，界面美观度和响应速度都比较有限。PySide6虽然模板代码多一些，但控件丰富、样式可定制、信号槽机制在处理实时视频流刷新时优势非常明显。
对于这个项目，我最终选了PySide6。原因一是检测结果的实时刷新涉及多线程数据传递，PySide6的Signal/Slot机制能让推理线程的结果安全地传到主界面线程，不需要手动加锁；二是界面要显示检测统计表格和告警日志，控件能力足够支撑。如果你只是临时演示一下，不介意界面简陋，Tkinter也是可以用的，核心推理逻辑完全一样，区别只在外层封装。
安装PySide6之后，界面布局我设计成左侧主视频显示区、右侧信息面板的结构。信息面板从上到下分别是检测结果统计数据（总检测人数、佩戴数量、未佩戴数量、佩戴率）、当前帧检测详情列表、系统日志区，底部是“开始检测”“停止检测”“保存截图”“导出报表”四个按钮。这种布局在部署现场操作时很直观，作业人员不需要培训就能看懂。
4.2 推理引擎封装与结果输出
UI界面与模型推理之间我用了一个检测器类来做封装，核心逻辑是加载YOLOv8权重文件，将输入帧送入模型做前向推理，把输出的坐标、类别和置信度解析为统一的检测结果对象。这样UI层完全不需要关心模型细节，换模型只改配置文件。
推理帧的处理有几个关键细节。第一，输入图像要按模型的输入尺寸做等比缩放，多余部分用灰色填充，推理完成后坐标需要映射回原始图像尺寸，否则显示的框会偏移。第二，置信度阈值默认设为0.45，这个值需要现场调。阈值太高会漏检低置信度的正样本，太低会频繁误报。第三，类别过滤要提前做，如果模型同时训练了其他类别，推理时只保留当前需要的类别。
结果输出除了在界面上画框，还要同步记录到结构化数据中。每一帧的检测结果包含时间戳、目标编号、类别、置信度、坐标信息，可以实时追加到内存列表，并在导出报表时写入CSV或Excel。如果有告警需求，可以在检测到未佩戴手套时触发声音提示或在界面上高亮告警状态。告警逻辑需要注意防抖，连续几帧都检测到未佩戴再触发告警，避免单帧误检测导致频繁误报。
4.3 多线程处理避免界面卡顿
实时视频检测里最常见的坑就是界面卡死。如果在主线程里做视频帧读取加模型推理加界面刷新，模型推理耗时一长，界面就无法响应用户操作，画面看起来像死了一样。解决方式是把视频读取和推理放到独立的工作线程中，主线程只负责接收推理结果并刷新界面。
我的实现方式是启动一个工作线程，循环从摄像头或视频文件中读取帧，对每帧执行推理，然后将结果通过PySide6的Signal发到主线程。主线程收到信号后更新QLabel上的视频画面和统计数据。这样即使推理帧率较低，界面也不会卡死，用户仍然可以点击停止按钮或调整参数。
线程之间的数据交互还要注意内存管理。摄像头帧和推理结果在多次传递过程中会不断创建新对象，如果内存释放不及时，长时间运行后内存占用会持续增长。我的做法是复用固定大小的字节缓冲区，并在视频帧显示转换时注意及时释放不再使用的图像对象。实际运行了一整天之后，内存占用稳定在2GB以内，没有出现明显泄漏。
4.4 界面交互与参数调节
实际部署时，不同现场对置信度阈值、告警灵敏度、检测区域的要求都不一样。如果把参数写死在代码里，每次调整都要改代码重启，非常耗时。我后来在界面上增加了一个参数设置区域，运行过程中可以实时调整置信度阈值和非极大值抑制阈值，调整结果即时生效。这个设计在现场调试阶段帮了大忙，基本不用重启程序就能完成参数寻优。
另外还加了一个检测区域限定功能，通过鼠标在视频画面上拖拽选择感兴趣区域，只检测该区域内的目标。有些通道区域不需要检测，或者某些区域摄像头视角太偏、检测效果不佳，直接用区域限定就能过滤掉。这个功能的代价是推理时需要对目标中心点做额外的区域判断，判断逻辑本身就几行代码，但能显著减少误报。
5. 部署现场遇到的问题与排查经验
5.1 漏检误检的调参方向
项目落地过程中最容易反复折腾的问题就是漏检和误检。现场部署第一天，模型频繁把戴着深蓝色手套的手判断为未戴手套，因为我训练集里手套颜色大多是浅色和黄色。针对这个情况，我先把置信度阈值调低观察，但结果误检也上来了。进一步分析发现，深蓝色手套与背景的对比度太低，模型提取到的特征不足以做出正确判断。
正确的解决思路是回到数据层面。我专门到现场采集了深色手套在不同背景下的画面，又用数据增强工具把已有的浅色手套样本做了颜色扰动，模拟更多色彩环境，重新训练后漏检率明显下降。这轮排查给我的经验是：不要指望调阈值能补足模型能力缺陷，阈值只是置信度筛选，模型本身没有学到特征，再怎么调阈值也只是在矮子里面拔高个。
误检的场景也有代表性：有些工人手上拿着深色工具，模型会把工具误判为未戴手套的手。原因是未戴手套类别中包含了部分皮肤色泽偏深或光线不足的样本，模型学到的特征不够纯粹。我重新检查了标注样本，把这类容易混淆的样本单独挑出来复核，裁剪明显错误的标注，又新增了一批手持工具但手部特征清晰的样本，问题才得到缓解。
5.2 性能卡顿与显存优化
部署工控机的显卡性能有限，推理速度一度只有不到10FPS，画面看起来有明显的卡顿感。排查思路是先确认瓶颈在推理还是视频读取。测试发现摄像头读取本身很快，卡顿主要来自模型推理。优化方向包括换用更小的YOLOv8n模型、推理时关闭不必要的后处理、在支持半精度的情况下启用FP16推理。这几项组合之后，推理耗时从80毫秒降到了45毫秒左右，画面流畅度明显改善。
如果对实时性要求更高，还可以做跳帧检测——比如每两帧抽一帧检测，中间帧直接沿用上一帧结果。安全帽手套这类场景目标运动速度不快，直接跳帧检测基本不影响准确率。但使用跳帧时要保证结果展示的连续性，否则检测框会在画面上跳动。
另外，模型加载阶段也要注意，YOLOv8加载权重时会占用一部分显存。如果同时运行多个视频流，每路都加载一个模型实例，显存很快就会不够。我后来改成了共享同一个模型实例，多个视频线程只做前处理和结果解析，显存占用大幅下降。GPU显存一般只要4GB以上就能比较从容地运行YOLOv8n和YOLOv8s的实时推理。
5.3 模型加载与异常处理
部署过程中还有一个容易忽视的环节是模型加载的稳定性。训练好的权重文件在开发环境加载正常，但拷贝到现场工控机后偶尔会出现加载失败或推理结果异常。常见原因包括PyTorch版本不一致、模型文件在传输过程中损坏、依赖包版本冲突。最稳妥的做法是在部署机器上完整复现训练环境的依赖版本，并定期校验权重文件大小和哈希值。
还有一个前端交互层面的问题：摄像头在运行过程中可能断线或画面冻结，如果没有异常处理，程序会在读取视频帧时直接崩溃。我在视频流读取位置加了异常保护，检测到画面连续多帧无变化或读取失败时自动重启摄像头连接，并记录日志。这个保护逻辑虽然简单，但避免了现场无人值守时程序假死的情况，实用性极强。
6. 这个项目还能往哪里走
6.1 多类别扩展：安全帽、反光衣一起做
安全手套只是现场防护装备中的一项。同一个摄像头画面里，工人可能既需要戴手套，又需要戴安全帽、反光衣、护目镜。模型结构完全可以支撑多类别检测，只需要在数据集类别定义中加入这些目标并重新标注训练即可。
实际训练时要注意，类别增加后数据集的复杂度会上升，特别是不同防护用具尺寸差异大——安全帽在画面里比手套大不少。这种情况下单阶段检测器仍然能工作，但需要更精细地调整Anchor参数和类别权重。更合理的做法是评估场景后拆分多个模型，一个专门检测防护装备，一个专门检测人员，再在后处理逻辑里做关联判断，这样单个模型的压力更小，精度更可控。
6.2 视频流追踪与行为分析
目前的实现帧级检测，逐帧判断是否戴手套。如果要做人员维度的统计，比如“某个工人持续多长时间未佩戴手套”，就需要加入目标追踪算法。常用的ByteTrack或DeepSORT可以给每个检测目标分配稳定的ID，结合每一帧的检测结果统计同一ID的连续状态变化。
增加追踪模块后，能实现更智能的告警规则：发现一个ID连续超过5秒处于未佩戴状态才触发告警，避免误报。还可以统计一个班次内不同人员未佩戴手套的总时长分布，给安全管理提供数据支撑。追踪模块的引入会增加一定的CPU开销，但ByteTrack这类轻量算法在普通工控机上性能损耗可控。
6.3 边缘端部署与告警联动
AI检测如果一直依赖工控机上的GPU运行，成本会比较高。类似的任务可以迁移到边缘设备上部署，用转换工具将模型导出为相应格式后运行。部署到边缘设备的好处是功耗低、体积小、可以就近安装在摄像头旁边，视频流不走主干网络，时延更低。
告警联动方面，检测到未佩戴手套时可以在现场直接联动语音播报或声光报警器，也可以通过消息推送把告警截图发送到管理员的手机上。这里的思路是不要只做“看到问题”，要把“看到问题”转化为“处理问题”的完整闭环。代码层面只需在检测逻辑里增加一个告警接口，把告警事件和现场截图推送给下游系统。
我在实际项目中的体会是：这类视觉检测系统的技术难度并不仅仅在模型本身，更在于数据怎么组织、现场怎么调试、异常怎么处理、产品怎么让人愿意用。模型花了两天训练出来，数据收集标注花了整整一周，部署调试又花了一周。如果你也打算做类似项目，我的建议是前期多花时间把数据集做实，不要急于把模型跑出来就以为完成，现场真正用起来之后打磨迭代的时间往往比想象中长得多。最后再分享一个小技巧：训练完成后，找一段完全没有参与训练的真实现场视频，跑一遍完整流程看效果，这比任何验证集指标都更能反映模型能不能真正落地。
