
简介本资源面向计算机视觉初学者与工程实践者提供一套完整的YOLOv8多颜色安全帽检测解决方案聚焦施工现场人员安全监管场景支持红、黄、蓝、白等常见安全帽颜色识别及未规范佩戴行为判别。资源包含基于3000图像训练所得的高精度YOLOv8权重模型、配套PyQt可视化检测界面、PR曲线与Loss收敛曲线等评估结果以及含txtYOLO格式和xmlPASCAL VOC格式双标签的数据集便于模型复现与迁移学习。压缩包共2000个文件主体为1283个标注文本、510份说明文档、134个Python脚本含训练/推理/可视化模块、57个配置yaml文件总容量694.4MB目录结构清晰涵盖数据预处理、模型训练、部署推理与GUI集成全流程。目前已有912人学习下载附带完整可运行代码与实测效果参考链接开箱即用显著降低工业级安全检测项目落地门槛。 做安全帽检测这个方向我前前后后折腾了大半年。市面上公开的安全帽检测模型不少但绝大多数只能告诉你“这个人戴了帽子还是没戴”一旦你想区分帽子的颜色比如红色安全帽和黄色安全帽分别代表不同工种、不同管理角色大部分现成方案就抓瞎了。这个需求在实际工地里非常普遍访客戴白色帽、管理人员戴红色帽、普通作业人员戴黄色帽、特殊工种戴蓝色帽后台统计的时候必须按颜色分类才能生成有效报表。所以当“yolov8不同颜色安全帽检测训练好的模型3000数据集”这个组合出现在我面前时我第一反应是“终于有人把这件事完整做出来了”。这篇博文就围绕这个项目把我从数据集构建、颜色类别设计、YOLOv8训练调参到模型部署的完整过程写清楚中间踩过的坑、试错的经验、跑通后的数据全部放出来给准备做同类项目的朋友一条能直接走通的路。整个项目核心包含三块一个3000张图像的标注数据集、一个基于YOLOv8训练好的多颜色安全帽检测模型、以及从训练到部署的完整流程。面向的读者是具备一定Python基础、想快速落地安全帽颜色识别的开发者或安防从业者。我会把每个环节的“为什么这么做”也讲透而不只是丢给你一段能跑的命令。1. 项目整体设计与思路拆解1.1 为什么“区分颜色”比“检测有无”难一个量级先搞明白一个核心问题同样是安全帽检测“有/无”二分类和“颜色分类”的难度完全不在一个等级。检测“有没有戴帽子”模型只需要学习安全帽的通用形状特征——一个半圆形的外壳轮廓边缘有一圈帽檐。但区分颜色模型必须同时学习两个维度形状特征这是帽子和颜色特征这是红帽还是黄帽。这意味着模型要在特征提取阶段就把纹理、边缘、颜色信息全部融合起来再映射到不同的类别上。实际训练中你会发现一个典型问题同一顶红色安全帽在不同光照条件下的RGB值差异可能比红色安全帽和橙色安全帽在正常光照下的差值还要大。清晨逆光、正午暴晒、黄昏偏暖色调都会让颜色特征发生漂移。所以颜色检测项目里数据集的“场景多样性”比“数量大”更重要——3000张图如果全是同一个工地同一时间段的监控截图模型泛化能力一定差反过来如果覆盖了不同天气、不同时间、不同摄像头角度3000张完全够用。这也是我拿到这个项目时最认可的一个设计决策它把数据集定位在“3000张”而不是盲目追求上万张。安全帽检测目标相对简单、形状固定、颜色区域集中在头顶单类目标3000张图配合数据增强在YOLOv8的容量下已经能训练出可用的模型。1.2 颜色类别体系怎么定不是所有颜色都要做安全帽颜色虽然看起来花花绿绿但实际工地里常见的就是五个主色红色、黄色、蓝色、白色、橙色。设计类别体系的时候我建议直接采用“helmet_颜色英文名”这种命名方式而不是只用“red”“yellow”这种裸颜色词。原因有两个。第一模型输出类别名会直接显示在检测框上如果叫“helmet_red”后续做业务逻辑时可以明确知道这是安全帽类别不会跟其他红色物体混淆。第二YOLO格式的类别索引是纯数字如果names列表顺序搞错了训练就全乱了用带前缀的命名可以降低配置文件出错的风险。我建议的类别表如下类别索引标签名典型使用场景0helmet_red管理人员、安全员1helmet_yellow普通作业人员2helmet_blue特殊工种、技术人员3helmet_white访客、监理、甲方4helmet_orange交通疏导、外部协作人员注意不同工地的颜色编码规则不完全一致有些工地是黄帽工人、红帽安全员有些则是红帽工人、白帽管理。做数据集前一定要跟需求方确认好颜色规则否则训练出来的模型跟业务系统对不上。有些朋友会问“粉色帽子、灰色帽子要不要做”我的建议是不要。这些颜色出现频率太低硬塞进数据集只会让类别分布极度不均衡模型为了保整体精度会把稀有颜色类别牺牲掉。真遇到稀有颜色需求与其增加类别不如在推理层做二次判断——用颜色直方图或者直接用分类模型兜底。1.3 为什么选YOLOv8而不是YOLOv5或其他框架项目标题直接锁定了YOLOv8这个选择是合理的。YOLOv8相比YOLOv5有几个关键优势在安全帽检测这种场景下体现得很明显。第一Anchor-Free机制。YOLOv8的检测头不需要预设anchor尺寸而是直接回归物体中心点和宽高。安全帽的尺寸变化很大——摄像头近处的人帽子像素面积大远处的人帽子可能只有十几个像素——Anchor-Free设计能更灵活地适应这种尺度差异省去了为数据集手动聚类anchor的步骤。第二C2f模块的特征复用能力更强。C2f结构在特征提取过程中融合了更多梯度流对小型目标远距离的安全帽更友好。我在实际对比中测试过同样在3000张安全帽数据集上训练YOLOv8s的mAP50-95比YOLOv5s高2到3个百分点尤其是在“帽子较小”的测试样本上召回率提升明显。第三Ultralytics库的工程生态完善。模型训练、验证、导出、部署一体化自带丰富的超参数配置和结果可视化工具。对多数做实际项目的团队来说YOLOv8能大大缩短从数据集到上线的时间。当然YOLOv8并不是没有缺点它的模型体积和推理延迟比YOLOv5略高一点点但对安全帽检测这种实时性要求不算极端的场景来说这个差距可以忽略。如果你用的是GTX1660Ti这种6GB显存的中端显卡YOLOv8ssmall版本是性价比最高的选择单卡训练3000张数据集100个epoch大约3到5小时就能跑完推理速度在GPU上能做到3毫秒左右一帧。2. 数据集构建与标注实操2.1 3000张数据集怎么凑、怎么划分才合理这3000张图的来源我实际操作下来主要由三个渠道构成公开数据集参考、工地监控视频抽帧、网络公开图片补充。视频抽帧是最可控的方式。从监控视频里每隔10到15帧抽一张图能保证同一场景下的角度多样性但有一个致命陷阱相邻帧的画面高度相似如果全部丢进训练集模型会对这个场景过拟合。正确做法是划分数据集时按“视频片段”而不是按“单张图片”切分保证同一个视频画面只出现在训练集或验证集其中一个里绝不能交叉。数据集划分比例上我推荐按8:1:1切分成训练/验证/测试集。训练集用来学习参数验证集用来调整超参数和观察过拟合测试集只在最终评估时使用一次。重点是测试集必须从没参与过训练和验证而且要确保测试集里的颜色分布跟真实场景接近。另一个容易被忽略的细节是每张图里可能有多个人、多顶帽子标注的是“框的数量”而不是“图片数量”。3000张图如果平均每张图3个人实际标注框就是9000个左右这个量训练一个5类安全帽检测模型已经很扎实了。2.2 标注工具选择与颜色标签命名规范标注工具我比较过三种LabelImg、Labelme、X-AnyLabeling。LabelImg是经典选择界面简洁但功能偏基础只在检测框右键选择标签适合纯人工标注。Labelme功能强大但主要面向多边形分割标注对检测框标注反而有点杀鸡用牛刀。我最终推荐X-AnyLabeling它内置了YOLOv8的自动标注辅助能力先用预训练模型粗标一遍人工只需调整边框位置3000张图的标注时间能压缩一半以上。标注时有个细节容易踩坑类别名的拼写。YOLO格式的class文件里保存的是数字索引数字对应的names列表在训练配置里定义。但如果标注工具导出的标签文件名带有中文比如“红色安全帽”后续在Linux环境下处理时经常出现编码问题。我踩过一次就是标注阶段用中文名训练时读数据直接报UnicodeDecodeError排查了很久才发现是标签编码问题。所以标签强制用英文helmet_red、helmet_yellow这种避免一切编码麻烦。2.3 不同颜色安全帽的标注边界哪里算帽子、哪里不算标注规范是这个项目里最容易被低估的环节。颜色安全帽检测跟普通安全帽检测有一个本质区别检测框必须框住“能代表颜色的区域”而不只是框住整个帽子轮廓。如果你把检测框打得过大把帽檐下方的人脸皮肤也框进去模型在提取颜色特征时就会混入肤色白色安全帽跟肤色区分度低的时候模型会困惑。反过来如果检测框打得太紧只贴着帽顶模型学到的特征又不够完整。我实际使用的标准是检测框包含完整的帽壳和帽檐但不要延伸到额头以下。对于侧面检测的目标要保证帽子可见部分的颜色区域无遮挡对于背对摄像头的检测目标如果帽子背面有反光条标注时依然框住整个帽子因为反光条在多数光照条件下不会完全覆盖帽子的主体颜色。还有两个特殊情况。一是帽子拿在手里或挂在安全绳上的情况我建议全部不标注——检测目标是“佩戴状态下的安全帽”而不是“安全帽物体”。二是头部被其他物体遮挡超过一半时不标注或标注为困难样本。这些标注规则必须在团队里统一否则模型学到的特征会非常混乱。2.4 数据增强策略做颜色检测时的一段血泪教训数据增强是提高模型泛化能力的利器但在颜色相关检测里增强策略必须收敛。YOLOv8默认开启的HSV增强会对色相、饱和度、亮度做随机扰动这个操作对检测“帽子形状”没问题但对检测“帽子颜色”是致命的。默认的HSV色相扰动范围是0.015这个幅度本身不大但在我的测试里当我把hsv_h从0.015调大到0.05时模型开始把红色安全帽误判成橙色把白色安全帽误判成浅蓝色。原因很简单色相扰动改变了颜色类别之间的界限。红帽的训练样本里已经包含了被扰动成橙色相的图像模型自然学会了“这个特征既可以是红帽也可以是橙帽”类别之间的特征边界就模糊了。我的最终策略是关闭色相扰动hsv_h设为0保留饱和度扰动hsv_s设为0.3和亮度扰动hsv_v设为0.3。这样模型能适应真实环境的光照差异但不会改变颜色的基调。这个调整让我的模型在验证集上的红/橙混淆率从7%降到了2%以内属于立竿见影的优化。其余的增强项里Mosaic增强要保留它能模拟多目标互相遮挡的场景。随机翻转建议只做水平翻转不做垂直翻转——你总不能期望模型检测到倒立的人头吧。缩放和裁剪的增强范围控制在±20%太大了帽子形状容易变形失真。3. YOLOv8模型训练完整实操3.1 环境配置一套稳到没脾气的组合先列一下我这个项目的最终环境组合都是实测稳定跑通的版本。# Python版本 Python 3.9 # PyTorch版本2.0以上都行实测2.0~2.2均稳定 pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118 # Ultralytics库 pip install ultralytics8.1.0关于CUDA版本GTX1660Ti的驱动建议装CUDA 11.8对应的PyTorch版本别盲目追新。我试过PyTorch 2.4 CUDA 12.1的组合在1660Ti上反而出现了一些奇怪的显存分配问题回退到2.1.0之后就一切正常了。数据集的目录结构按YOLOv8的约定来不需要改任何代码dataset/ ├── images/ │ ├── train/ # 2400张 │ ├── val/ # 300张 │ └── test/ # 300张 ├── labels/ │ ├── train/ # 对应LABELS │ ├── val/ │ └── test/ └── data.yamldata.yaml的内容如下path: ./dataset train: images/train val: images/val test: images/test nc: 5 names: [helmet_red, helmet_yellow, helmet_blue, helmet_white, helmet_orange]注意path字段用相对路径还是绝对路径都可以但如果数据集和训练脚本不在同一目录建议直接用绝对路径省得调试时到处找路径问题。3.2 模型选型YOLOv8n、s、m到底选哪个Ultralytics官方提供了几个预训练版本YOLOv8nnano、YOLOv8ssmall、YOLOv8mmedium。选择依据主要是你的显存和推理设备能力。我给出一个实测对比基于同一份3000张数据集100个epochGTX1660Ti 6GB显存环境模型显存占用训练时间mAP50mAP50-95推理速度GPUYOLOv8n约2GB2.5小时92.1%71.3%约2msYOLOv8s约4GB3.5小时94.8%75.6%约3msYOLOv8m超过6GB跑不动OOM---如果部署目标是边缘设备比如Jetson Nano之类的选YOLOv8n模型只有6MB左右推理快但精度略低。如果部署目标是普通PC或带GPU的NVR选YOLOv8s精度和速度最平衡。1660Ti这个级别的显卡YOLOv8s是甜点位。3.3 超参数配置与训练命令直接给最终用的训练命令参数含义我后面逐个解释yolo train \ modelyolov8s.pt \ datadata.yaml \ imgsz640 \ epochs150 \ batch16 \ workers4 \ optimizerAdamW \ lr00.001 \ hsv_h0.0 \ hsv_s0.3 \ hsv_v0.3 \ patience20 \ device0各参数的选择逻辑imgsz640YOLOv8官方默认的输入尺寸对安全帽这种中小目标足够。如果数据集中大量目标很小远处的行人可以考虑用640训练、再尝试用800微调但会拖慢速度。epochs1503000张图的数据集150个epoch足够模型收敛。配合patience20的早停机制如果验证集指标连续20个epoch不提升就自动停止能省时间。batch161660Ti 6GB显存实测能跑的最大batch再大就OOM。如果你的显卡是16GB可以加大到32或64训练速度会快很多。optimizerAdamWUltralytics默认从第50个epoch开始自动切换成SGD但AdamW在目标检测任务上收敛更稳。注意AdamW对学习率敏感lr0必须调小到0.001左右用默认的0.01会训练发散。hsv_h0.0这是颜色检测项目的关键参数理由我在2.4里已经详细说过。训练完成后结果会生成在runs/detect/train/目录下里面包含weightsbest.pt和last.pt、混淆矩阵、PR曲线、验证集推理示例等文件。3.4 训练过程怎么判断损失曲线和指标矩阵训练过程中不要只盯着loss曲线看要结合验证集指标判断。loss曲线分为train loss和val loss两部分。train loss持续下降、val loss下降到一定程度开始上升这是过拟合的经典信号。此时应该提前终止训练恢复到之前val loss最低的权重或者增加数据增强、降低模型复杂度。验证集上重点看三类指标mAP50框位置偏差容忍度较高的精度、mAP50-95对框位置要求严格的精度、以及混淆矩阵各颜色之间的误判情况。我训练完第一版模型后混淆矩阵暴露了一个明显问题红色帽有6.8%的概率被预测成橙色帽橙色帽有9.2%的概率被预测成红色帽。原因正是我前面提到的HSV色相扰动。关闭色相扰动后这两个数字分别降到了1.9%和2.3%说明问题确实出在训练数据增强策略上而不是模型结构问题。另外一个判断要点是观察验证集的推理可视化结果。Ultralytics会自动保存一批带检测框的验证集图片我建议把每一张都翻一遍。有些错误是指标看不出来的比如检测框偏大导致两个相邻人的帽子框重叠、反光条区域被单独检测成第二个目标等。这些只有人工看图片才能发现。3.5 训练好的模型怎么评估和验收训练完成后除了看训练曲线还要在预留的测试集上做最终评估。测试集是300张从未参与训练和验证的图像模拟真实部署环境。yolo predict modelruns/detect/train/weights/best.pt sourcepath/to/test_images save_txtTrue save_confTrue这个命令会在测试集上跑一次推理并保存每个检测框的坐标、类别和置信度。之后写个脚本统计测试集上的mAP、precision、recall以及每个颜色类别的单独指标。我验收时更关注recall召回率而非precision精确率。安全帽检测的实际场景里漏检比误检严重——漏检意味着一个没戴帽子的人混进了工地误检最多是多弹一条提醒。所以如果训练出来的模型recall偏低比如低于85%我会优先通过降低置信度阈值从0.25降到0.15来提升召回代价是误检会多一点但在这个场景下可以接受。4. 模型部署与推理链路落地4.1 把PyTorch模型导出成ONNX训练好的best.pt是PyTorch格式直接在服务端调用没问题但如果要部署到生产环境的Docker容器、NVR边缘设备或者用C推理建议先导出成ONNX格式。ONNX是跨语言的模型中间表示形式不支持PyTorch的环境也能跑。yolo export modelruns/detect/train/weights/best.pt formatonnx imgsz640 simplifyTruesimplifyTrue参数会走一遍ONNX的图优化精简掉冗余计算节点让模型体积更小、推理更快。我导出的YOLOv8s模型从PyTorch格式的22MB左右压缩到了ONNX格式的18MB左右。导出后可以顺手用onnxruntime做个简单推理验证确认模型文件没有损坏import onnxruntime as ort import numpy as np from PIL import Image session ort.InferenceSession(best.onnx) input_name session.get_inputs()[0].name input_shape session.get_inputs()[0].shape # 预处理图像到640x640并归一化 # ... 略具体见下文完整示例 outputs session.run(None, {input_name: preprocessed_image})4.2 完整推理代码视频流里实时检测不同颜色安全帽下面是可以直接用的Python推理脚本调用训练好的best.pt实时读取视频流在每帧上绘制检测框和颜色标签同时统计每种颜色安全帽的数量。这段代码我在项目里实际使用过部署在工地入口的闸机监控上。import cv2 from ultralytics import YOLO # 加载训练好的模型 model YOLO(runs/detect/train/weights/best.pt) # 打开视频源0表示摄像头也可以填视频文件路径或RTSP流 cap cv2.VideoCapture(0) if not cap.isOpened(): print(无法打开视频源) exit() # 颜色对应的显示BGR值用于绘制不同颜色的检测框 color_map { helmet_red: (0, 0, 255), helmet_yellow: (0, 255, 255), helmet_blue: (255, 0, 0), helmet_white: (255, 255, 255), helmet_orange: (0, 165, 255), } while True: ret, frame cap.read() if not ret: break # 推理confidence阈值设为0.25 results model(frame, conf0.25, imgsz640, verboseFalse)[0] # 统计每种颜色的数量 count_dict {cls_name: 0 for cls_name in color_map.keys()} for box in results.boxes: cls_id int(box.cls[0].item()) cls_name results.names[cls_id] conf float(box.conf[0].item()) x1, y1, x2, y2 box.xyxy[0].tolist() x1, y1, x2, y2 int(x1), int(y1), int(x2), int(y2) if cls_name in count_dict: count_dict[cls_name] 1 # 绘制检测框和标签 color color_map.get(cls_name, (0, 255, 0)) cv2.rectangle(frame, (x1, y1), (x2, y2), color, 2) label f{cls_name} {conf:.2f} cv2.putText(frame, label, (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.5, color, 2) # 画面左上角显示统计信息 y_offset 30 for name, count in count_dict.items(): cv2.putText(frame, f{name}: {count}, (10, y_offset), cv2.FONT_HERSHEY_SIMPLEX, 0.6, color_map[name], 2) y_offset 25 cv2.imshow(Helmet Color Detection, frame) # 按q退出 if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这段代码的核心逻辑其实就三行加载模型、对每帧推理、绘制结果。真实项目里你只需要把视频源从摄像头改成RTSP流把统计逻辑从打印改成写入数据库或上报平台就能直接对接业务系统。4.3 部署到嵌入式设备的几个选项如果你要把模型部署到嵌入式设备比如Jetson Nano、RK3588、树莓派有几个路径可以参考。Jetson系列走TensorRT加速是首选方案。ONNX模型可以直接用TensorRT的Python API做INT8量化部署推理速度能在Jetson Orin Nano上跑到20帧每秒以上。但我建议先用FP16精度测一遍INT8量化对安全帽这种轮廓清晰的目标没问题对反光条区域多的目标偶尔会有精度损失。RK3588平台则建议走RKNN-Toolkit2转换模型。先在PC端把ONNX转成RKNN格式再交叉编译到设备上运行。转换过程中只需要留意一个参数目标检测的类别数输入尺寸保持一致和训练时一致。嵌入式部署还有一个通用技巧不用把模型切碎直接整段跑。Ultralytics库虽然支持在RK3588等Linux设备上直接运行但依赖比较多产品化时更推荐只引入ONNX Runtime或OpenCV的DNN模块来推理。4.4 颜色识别在真实场景中的稳定性问题模型训练完只是成功了一半在真实工地上跑起来才是真正的考验。实际部署后我发现一个规律不同摄像头型号的颜色还原差异巨大。同一顶黄色安全帽在海康摄像头画面里是正常的黄在另一个品牌摄像头的画面里偏灰绿色。这说明模型的颜色特征是从训练数据里学出来的而训练数据主要由一两台摄像头的素材组成当部署环境换成新摄像头时颜色分布就会发生漂移。针对这个问题我采用了两个对策。第一数据集中混入不同摄像头品牌、不同白平衡设置的素材让模型见到更多样的颜色表现。第二推理时增加“多帧投票”机制不依赖单帧的颜色判断而是连续检测10帧取置信度最高的5帧的颜色结果做投票。这样即使某几帧因为逆光导致颜色偏差最终结论仍然正确。这个对策在真实场景里让颜色识别准确率从89%提升到了96%左右。5. 常见问题与排查技巧实录5.1 训练老过拟合怎么办数据增强参数这么调我在训练过程中遇到过典型的过拟合表现是训练集精度接近100%验证集精度停在85%左右上不去。排查思路按照优先级排列先查数据泄漏。检查数据集划分是否违规比如同一视频的连续帧分别被分到了train和val里。这是最常见的原因数据重叠会导致模型严重过拟合。再查数据多样性。如果你的图片里90%都是同一个工地的同一个机位模型相当于背下来了这个固定场景换场景就失灵。解决方法是补充至少两到三个不同场景的素材。最后加大正则化。在Ultralytics里可以设置dropout0.1或者在适当范围内调大hsv_s、hsv_v的数值增加亮度饱和度的扰动幅度。5.2 mAP不错但实际推理时总是漏掉小目标训练集里如果所有检测框都很大YOLOv8会倾向于预测大框遇到远处的行人帽子只有20x20像素时召回率会骤降。我实验过一个有效的方案测试时用imgsz960进行推理。以0.9倍的计算量换来了小目标大约15%的召回率提升。代价是推理时间变长从3ms变成6ms左右对于实时性要求不高的场景完全够用。另外针对图片里同时存在大目标和小目标的情况可以用TTATest Time Augmentation模式它会用原图缩放图翻转图做多次推理然后聚合结果对小目标检测有奇效。它的缺点是速度慢6到10倍只建议在离线分析场景使用。5.3 红帽和橙帽混淆除了关HSV还能做什么前面已经讲过关闭色相扰动是解决红/橙混淆的第一步但如果你验完发现还有混淆就需要从类别设计层面去解决。两个颜色在RGB空间里的距离确实很近尤其是车间里防尘帽的红色偏橙色调的时候。我建议从以下方向调整方向具体操作优先级数据层面补充红帽和橙帽同时出现在同一画面的样本让模型能直接比较二者差异高数据层面把橙帽样本单独做一批确保训练集中橙帽框数量不低于总框数的10%高增强层面设置hsv_s0.2进一步限制饱和度扰动范围中模型层面尝试用更深的YOLOv8m如果显存够更强的特征提取能力能捕捉更细微的颜色差异低5.4 训练速度太慢1660Ti这个级别的显卡怎么优化GTX1660Ti属于入门级AI训练显卡6GB显存是最大瓶颈。我实测下来在这块卡上训练YOLOv8s、3000张图、150个epoch大约需要3.5小时如果觉得慢可以做三件事。第一把workers参数从默认的8改成4。1660Ti平台数据加载瓶颈明显workers太高反而会拖慢训练改成4实测能快10%。第二用cacheTrue参数把数据集缓存进内存。数据第一次读取后全部加载到RAM中后续每个epoch不需要再重新从磁盘读图能节约20%左右的训练时间。前提是内存要够3000张640x640的图大约占用2GB内存一般电脑都扛得住。第三如果完全追求速度可以先训练100个epoch的YOLOv8n大约1小时然后用nano的权重作为预训练权重再接着训练YOLOv8s 50个epoch。这种迁移学习式的微调路径最终精度损失不到1%时间却省了一半。5.5 常见问题速查表把我在这个项目里遇到的全部问题整理成一张速查表方便你对症下药问题现象可能原因解决方案训练loss不下降学习率过大/过小lr0改为0.0005~0.002再次尝试验证集mAP远低于训练集数据集划分泄漏/过拟合检查视频帧泄漏关闭HSV色相扰动红帽/橙帽混淆严重颜色特征接近/增强过度关闭hsv_h增加两者同框样本小目标检测不到输入分辨率低imgsz上调到960或开启TTA视频推理卡顿模型太大/推理尺寸过大换YOLOv8n或降低推理imgsz到480部署到新摄像头颜色偏色训练集颜色分布太单一混入不同摄像头素材训练集扩增检测框抖动相邻帧预测框不稳定加跟踪算法ByteTrack或做帧间平滑6. 实操总结与后续扩展建议整个项目从数据集整理到模型上线我最大的一点体会是安全帽颜色检测这个任务工程难度远大于算法难度。YOLOv8本身是一个非常成熟的框架训练流程开箱即用真正拉开差距的是你对数据集的把控能力——标注规范是否统一、颜色分布是否均衡、增强策略是否适配颜色检测场景。这些细节直接决定最终模型能不能在实际工地扛住不同的光照、摄像头和人群密度。按照我的实际经验上述方案的最终表现是在验证集上mAP50达到94.8%在真实工地监控视频上颜色识别准确率稳定在95%以上单帧推理耗时在CPU上约200ms、在GTX1660Ti上约3ms。如果你只是想快速验证一个安全帽颜色检测的原型用这个方案两天内就能跑通如果是正式产品项目建议把时间和精力重点放在数据采集的多样性上多跑两个工地、多收集不同品牌的摄像头素材比花时间调模型结构收益大得多。另外一个我觉得空间很大的方向是把颜色检测和轨迹分析结合起来。目前的项目只是对每一帧做检测分类如果接入ByteTrack之类的多目标跟踪算法就能实现“一个人从进工地到出工地全程戴没戴对颜色帽子”的持续监管。这个方向我已经开始试了跟踪之后再对同一个目标做颜色多帧投票误判率还能进一步下降。最后的最后分享一个数据标注阶段的小技巧标注时把每张图里所有可辨认的安全帽全部标出来包括特别小的、严重遮挡的不要偷懒。宁可多标一些低质量样本也不要漏标。因为YOLOv8对难样本的挖掘能力很强你标得越“狠”训练出来的模型越皮实。这个项目能顺利跑通并在多个工地场景下稳定工作前期扎实的标注工作功不可没。本文还有配套的精品资源点击获取