简介：面向建筑工程安全管理与计算机视觉学习者的YOLOv11实战文档，围绕安全帽检测与高空作业风险预警两大场景，介绍如何用单阶段目标检测算法解决传统检测方法效率低、成本高的问题。文档共37页，为单个PDF文件，内含完整目录，支持章节跳转和阅读器左侧大纲快速定位，文字、图表、目录显示正常，压缩包仅2.24MB，下载使用便捷。内容从建筑工程安全检测现状与需求出发，依次讲解YOLO系列算法演进、YOLOv11网络结构、安全帽数据集收集与标注工具选型、数据增强与划分、模型训练与优化技巧，再到高空作业风险预警系统的需求分析、架构设计、模块划分和实现细节，最后附完整实战案例分析。读者可参照其中数据来源选择、标注流程、训练环境配置、系统部署维护等环节，掌握从数据到模型再到预警系统的完整落地路径。目前已有46人学习下载，适合需要快速上手YOLO目标检测的工程人员与研究人员。

1. 工地图像里的安全帽检测为什么不能靠通用模型：一个小目标问题的开场

塔吊顶上的枪机离地面少说几十米，1080P画面里一个没戴帽的工人通常只占二三十个像素；防尘网、钢筋和混凝土又把背景搅得比公开数据集复杂一个量级。建筑工程里的安全帽检测，和网上那些“对着一个人脸特写框帽子”的demo，差距全部来自这里。YOLOv11在通用目标上表现不差，但要在工地上真的报出“谁没戴帽、这个人在几米高处作业”，从网络选型、数据组织到告警规则都要另行设计。

这篇笔记想解决的，就是把YOLOv11用于建筑工程安全帽检测与高空作业风险预警的完整路线讲清楚：为什么网络结构选型要考虑小目标和遮挡，安全帽数据集怎么组织，训练参数里哪几个最影响精度，Jetson上怎么部署，以及最后如何把检测框变成能用的风险事件而不是一堆报警截图。适合两类人：一类是智慧工地项目的算法工程师，另一类是负责现场安全管理的IT负责人——前者能照着复现，后者能判断这套方案和你手里的监控点位是否匹配。

2. YOLOv11的网络结构对安全帽检测意味着什么：C3k2、C2PSA与anchor-free的三点取舍

2.1 主干更换C3k2：小目标特征为什么不能只看通道数

YOLOv11在主干和颈部把YOLOv8那套C2f换成了C3k2。C2f的特点是split之后的多分支梯度流，信息回传好但计算路径多；C3k2更像当年C3的串行堆叠，只是内部加了一层split，让每个stage在接近的FLOPs下更容易把计算花在最有用的位置。直观理解：安全帽检测的特征不是“颜色”而是“帽檐弧线+顶部轮廓”这种位置敏感的形状特征，串行模块在一层层的感受野推进中，比宽而浅的并行结构更利于小目标。

选型上的直接判断：同样的分辨率下，YOLOv11-n和s的体量做安全帽检测是够的，因为任务类别少、输出头简单，瓶颈不在网络容量而在小目标召回。宽度因子w控制着通道数，从n到x精度会涨，但工地监控往往要跑多路，单路延迟和显存占用比那两三个点的AP50更敏感。我一般先用n跑通pipeline，跑完看小目标召回，不够再换m或者提分辨率，而不是一上来就上最大体量。

对安全帽这个场景还有个实际影响：C3k2让模型更容易适配低算力设备。Jetson Nano这类设备跑YOLOv8-s在640分辨率下勉强能实时，但要跑到1280分辨率做小目标检测几乎不可能；YOLOv11-n在1280下配合TensorRT还有一线机会，这也是后面部署章节能成立的前提。

2.2 C2PSA注意力：遮挡样本多时收敛更快，但别指望它化腐朽为神奇

主干末尾那个C2PSA，是把PSA（位置敏感注意力）塞进C2结构里的组合模块。PSA把特征图按位置做子区域聚合，让每个位置都能参考邻域的空间关系。对安全帽检测，典型场景是工人背对镜头、帽檐被脚手架横杆挡住一半、或者戴了安全帽但帽在画面边缘只剩1/3。这些样本靠普通卷积很难在同一个位置同时激活“头”和“帽”两类特征，注意力模块能帮网络在目标不完整时仍然输出激活。

这里要泼一盆冷水：注意力模块不是玄学，它的收益完全取决于训练集里遮挡和多姿态样本的占比。如果数据集几乎全是正脸、无遮挡、目标占画面1/10以上的清晰样本，加了C2PSA也不会让你凭空涨点。我在安全帽数据里会刻意保留“背影+遮挡+低照度”这三类难例，并把它们和简单样本按1:1混入，C2PSA的作用才体现得出来。反过来，难例过多又会让训练震荡，需要配合后面的样本平衡策略。

参数层面的建议：C2PSA不需要单独调节超参，它的行为跟着训练轮数、学习率和数据分布走。如果发现遮挡样本loss下不去，优先增加这类样本，而不是去调注意力内部结构。

2.3 anchor-free解耦头与DWConv：框回归和推理速度的平衡点

YOLOv11的检测头继续用anchor-free解耦头，真正的新变化是把部分3×3卷积换成了DWConv。对安全帽场景，anchor-free的意义在于“帽”和“头肩”两个框经常高度重叠——戴着帽时帽框和头框几乎同心，用anchor-free直接回归框中心比anchor-based预设的边界框数量更省；训练前也不用再对着数据集做K-Means算anchor，省掉了一个经常被忽略的预处理步骤。

DWConv则压低了每个head的参数量和计算量。好处是推理更快、部署更轻，代价是DWConv对小目标的定位不如普通卷积精细——毕竟深度卷积是逐通道的，通道间信息需要后面的1×1卷积去融合。实际表现是：框的IoU往往差零点几个点，但漏检率几乎不变。对安全帽这种“检测比分割更关键”的任务，这个交换值得。

判断该不该迁到YOLOv11，有一条边界很清晰：如果老项目还在YOLOv5上维护，迁移成本主要在数据集格式和anchors适配，收益是速度和显存；如果已经在YOLOv8上跑通了，迁到v11的收益是延迟和体积，不是精度的质变。不要为了换而换，安全帽场景里一个精标数据集对精度的提升，比从v8到v11的网络变化大得多。

3. 给YOLOv11准备安全帽数据集：类别设计、目录组织与样本平衡

3.1 类别怎么设计：拆出头肩类，预警规则才做得出

安全帽检测最常见的数据集设计是只标“person”和“helmet”，这是从通用目标检测继承下来的思路，在工程预警里会栽跟头：画面里出现一个没戴帽的工人背影时，模型输出“person”，你压根不知道这个人头上有没有帽。我的常见做法是至少拆出三个类：helmet（安全帽本体）、head（未戴帽时的头/头肩区域）、person（全身，可选）。这样风险预警规则就能写成“head出现且附近没有helmet→未戴帽”，而不是靠person框去猜。

标注细节比类别名称更容易被忽视。戴帽样本只标helmet，不要同时标head——否则帽框和头框重叠，网络学到的“帽”和“头”特征互相干扰；未戴帽样本只标head，head框从下巴到头顶包含脖子。戴帽但帽檐压低、帽被遮挡的样本，宁可标成低置信度也不要硬框。另外，我通常在head类别里把“安全帽颜色变化”做进增强，因为工地上白帽、黄帽、蓝帽是按工种分的，颜色一致性太强会让模型学成“黄色块检测器”。

数据来源上，不用拿手机去工地现拍。直接从现场IPC的RTSP流按5秒间隔抽帧，再按“塔吊视角、围挡周边、楼层内、出入口”四类场景分层抽样，能覆盖同一工地的视角多样性。一个可用的安全帽数据集规模，我一般从几千张起步，重点不是张数而是未戴帽样本不少于总数的30%。

3.2 环境配置与数据集目录：YOLOv11最小训练前的组织方式

先确认环境：Python 3.10以上、NVIDIA驱动对应CUDA可用，装ultralytics一行命令：

conda create -n yolo11 python=3.10 -y conda activate yolo11 pip install ultralytics

装完跑一句yolo detect predict model=yolo11n.pt source=bus.jpg验证环境。这里容易翻车的是CUDA和PyTorch版本不匹配，安装前先nvidia-smi看驱动支持的CUDA版本，再按ultralytics官方要求装对应torch版本，别装完再回来找环境问题。

数据集目录按YOLO格式组织，图片和标签分开：

mkdir -p datasets/helmet/{images/train,images/val,labels/train,labels/val} # 把工地A的0-4999帧放train，工地B的5000-6000帧放val python split_by_site.py ...

划分时按工地/摄像头编号分，不要按帧随机分——同一监控画面相邻帧极其相似，随机划分会把几乎一样的图同时塞进train和val，验证指标虚高，上线就现原形。

3.3 用脚本统计小目标分布：安全帽场景的样本平衡怎么做

安全帽检测多数时候是小目标检测。写个小脚本先摸底，再看要不要补样本：

import os from pathlib import Path def analyze(labels_dir, area_thresh=32 * 32): stats = {} for f in Path(labels_dir).glob("*.txt"): for line in f.read_text().strip().splitlines(): parts = line.split() if len(parts) < 5: continue cls = int(parts[0]) w, h = float(parts[3]), float(parts[4]) area = w * h # 归一化面积 d = stats.setdefault(cls, {"count": 0, "small": 0}) d["count"] += 1 if area < area_thresh / (1280 * 1280): d["small"] += 1 return stats print(analyze("datasets/helmet/labels/train"))

脚本逻辑是读YOLO格式归一化坐标，统计每个类别的框总数和小于32×32（按1280输入对应）的小目标数量。参数注意area_thresh这个分母要和训练时的imgsz保持一致，否则小目标统计失真。看到helmet类小目标占比超过一半，就该优先做下面几件事：把更多远距离抽帧补进来、提高训练分辨率、以及把mosaic增强打开，而不是继续加大总样本量。未戴帽的head类如果只有helmet的1/5，也先不要调loss权重，回到监控录像里把发生过未戴帽告警的时段回放抽帧，人工补标比任何调参都有效。

4. 用YOLOv11训练安全帽检测模型：最小命令、5个必调参数与小目标优化

4.1 最小训练命令：1280分辨率不是给显卡上强度

安全帽检测的最小训练命令可以压到一行：

yolo detect train data=helmets.yaml model=yolo11n.pt epochs=200 imgsz=1280 batch=16 workers=8 device=0 project=runs/helmet name=baseline

helmets.yaml里写train/val路径和类别名，类别顺序和标注txt里的数字必须一一对应，这是最常见的低级事故。imgsz=1280不是炫技：安全帽大量目标是20像素以下的框，640分辨率下这些目标最终只占8×8个像素，卷积下采样两三次特征就没了。提到1280，小目标在特征图上的尺寸翻倍，recall的提升往往比换大模型更直接。代价是显存按面积涨，batch=16在12G卡上勉强能跑，显存不够就降到batch=8配gradient_accumulation，或者先用640跑通再切1280。

训练日志里重点盯两个数：一个是box_loss是否在最后20轮还持续下降、另一个是close_mosaic之后的验证mAP是否出现锯齿。正常情况mAP是爬升后平稳，如果反复跳到0，基本就是标签和imgsz设置不匹配。

4.2 5个必调参数：mosaic、关闭翻转和置信度的配合

参数表直接给结论：

flipud保持0这点值得单独说：工地枪机装在塔吊上往下拍，垂直翻转等于把地面的人变成“倒立在天上的人”，网络会学到错误的朝向先验。hsv的饱和度增强和3.1的“黄色块检测器”问题直接相关——现场黄色钢筋、黄色警戒线到处都是，饱和度过大就分不清帽和背景了。置信度阈值conf不在训练参数里，它是推理时设的，后面部署章会讲。

另一个容易忽略的参数是patience，我一般给50。安全帽数据集小，训练到100轮就收敛了，patience太大纯烧电，太小又可能在close_mosaic后还没稳住就提前停。

4.3 预测后保存推理结果：不写爆磁盘的落盘方式

训练完用best.pt跑一次验证集，然后把推理结果保存下来看效果：

from ultralytics import YOLO model = YOLO("runs/helmet/baseline/weights/best.pt") results = model.predict( source="datasets/helmet/images/val", conf=0.35, iou=0.45, imgsz=1280, save=True, save_txt=True, save_conf=True, project="runs/helmet/eval", name="baseline" )

代码逻辑清晰：save=True把带框的图保存下来，save_txt=True把每个框的类别和坐标写成YOLO格式txt，save_conf=True在txt里额外带上置信度。这三个开关是排查漏检的关键——只看带框图你只能确认检没检到，配合txt才能统计“哪些类别在哪个置信度段被漏掉”。第一次跑完一定把head类在conf 0.2到0.4之间的漏检图拉出来看看，这比看mAP数字诚实得多。

落盘有个现实问题：监控是24小时跑的，每帧都存推理结果，一块1T硬盘撑不过几天。后面部署章的做法是“事件触发保存”：只有触发未戴帽风险的帧才落盘，并同时存前后各5帧做上下文，平时只把检测结果累加到内存计数。

4.4 小目标优化的三招：分辨率、切片和泄漏预防

小目标优化按性价比排序，第一招永远是提imgsz。从640提到1280，对20像素目标的提升最明显；加到1536后收益递减而显存暴涨，一般不推荐。第二招是mosaic增强配合close_mosaic，先模拟小目标，最后10轮再恢复真实尺度，让网络从“大尺度特征”回到“真实尺度推理”。第三招是分块检测：1080P画面切成2×2的4块分别送模型，再对重叠区做NMS合并，专治塔吊全景机位下的极端小目标。分块的代价是推理量乘4，通常只在关键点位开，用一块Jetson跑一路1080P勉强能顶住。

第三招有个隐蔽的坑：切块后同一个工人可能同时出现在两块边缘，NMS合并时如果IoU阈值设太严，会产生同一个人重复告警；设太松又会把相邻两个工人合成一个框。我用的是“只对类别相同且框中心距小于50像素的框合并”，而不是默认的类间IoU合并，实测重复告警能降一半。

5. 在Jetson上部署YOLOv11做实时检测：导出、INT8与五个排查坑

5.1 导出TensorRT引擎：FP16还是INT8，校准集从哪来

Jetson上跑PyTorch模型不现实，第一步导出engine。我的固定路径是先导出ONNX再交给TensorRT：

yolo export model=runs/helmet/baseline/weights/best.pt format=onnx opset=12 dynamic=False imgsz=1280 trtexec --onnx=best.onnx --saveEngine=best.engine --fp16 --workspace=4096

参数说明：dynamic=False是为了固定输入尺寸，Jetson上动态shape会拖慢推理；--fp16在Jetson Orin系列上精度损失可以接受，但Jetson Nano的GPU算力较弱，FP16的tensor core性能不完整，实际部署经常直接转INT8。INT8就要加校准集：

trtexec --onnx=best.onnx --saveEngine=best_int8.engine --int8 \ --calib=calibration.cache --calibBatchSize=8 --calibData=data/calib

校准集从验证集里挑200张，覆盖“白天、傍晚、未戴帽、遮挡、远距离”五类，别只挑清晰正样本。INT8之后小目标框的位置可能偏移几个像素，原因是检测头回归分支对量化噪声敏感。若发现偏移，优先把检测头三个输出层排除在INT8之外，只量化backbone。

导出后一定要做一致性验证：同一张图分别在PyTorch和engine上推理，对比输出框坐标和置信度。坐标偏差小于0.5个像素属于正常，超过2个像素就是量化配置有问题，别直接上生产。

5.2 Jetson上的多路实时推理循环：队列、半精度和帧缓冲

Jetson上跑多路视频流的骨架：

import cv2, queue, threading import numpy as np from ultralytics import YOLO engine = YOLO("best_int8.engine", task="detect") frames = queue.Queue(maxsize=16) def capture(rtsp): cap = cv2.VideoCapture(rtsp) while True: ret, frame = cap.read() if not ret: time.sleep(5) cap.open(rtsp) continue frames.put(frame) threading.Thread(target=capture, args=("rtsp://camera001",), daemon=True).start() last_event = {} # 每个机位的告警冷却时间 while True: frame = frames.get() results = engine.predict(frame, conf=0.45, imgsz=1280, half=True, verbose=False) # 检测结果解析、风险规则判断、event触发保存...

这个循环里三个要点：rtsp断流用sleep加重连，不然线程会空转把CPU吃满；frames队列限制16帧，超过就丢，保证推理永远消费最新帧而不是堆积延迟；half=True配合INT8 engine，在Jetson上能再省一点带宽。Jetson Nano上跑多路，每路之间最好各用各的engine实例和线程，不要共用一个predict调用——Ultralytics的predict内部是同步的，共用一个实例会让第二路阻塞。

5.3 训练和部署中的五个坑：现象、原因和解决

1. 未戴帽的recall高不起来，mAP看起来还行。现象是head类AP低而helmet类AP高。原因是head样本太少，且标注时把戴帽的头也标了head，网络学到“头=帽”的强关联。解决：严格按3.1的规则重标，head只在未戴帽时出现，再补未戴帽样本到总数的30%。

2. 把黄色警戒线、钢筋上的黄色油漆检成安全帽。现象是conf 0.5以下误报一堆。原因是hsv增强过大，颜色特征主导了形状。解决：把hsv_s回调到0.5以下，并把黄色背景的负样本单独挖出来加进训练集，必要时用Mosaic把“黄色钢筋+未戴帽的人头”拼在一起。

3. 报警时断时续，同一工人经过时漏报了两帧。现象是检测没问题但告警闪烁。原因是抽帧间隔太大或运动模糊把框丢了，只做单帧判断。解决：告警加去抖——同一位置的head连续2帧以上且跟踪ID一致才触发，触发后保持3到5秒，这个规则在最后一章展开。

4. 夜间画面recall断崖下跌。现象是白天92分夜间68分。原因是训练集几乎全是白天帧，暗光噪点被增益放大。解决：训练集混入30%的夜间和傍晚帧，推理时暗光先做CLAHE预处理，比调conf有用。

5. engine推理结果和PyTorch不一致，框偏了几个像素。现象是同一个模型两种结果，confidence也整体偏低。原因是INT8校准集太干净或calibration方式不匹配。解决：按5.1的占比重新挑校准集，检测头保持FP16；换entropy/percentile校准方式重试。

6. 把检测结果升级成高空作业风险预警：规则去抖与推理结果保存

检测模型输出的是框和类别，工地要的是“事件”。我常用的风险规则是组合判断：head框存在 + 以head中心为圆心、1.2倍框宽的范围内没有helmet框 → 未戴帽候选；再叠加作业面判断——通过相机标定把画面中的高空作业区框出来，或按GB/T 3608的约定，2米及以上视为高处作业，只有候选出现在这些区域才报“高空未戴帽”，而不是全图报警。去抖规则用跟踪ID：同一个未戴帽目标连续2帧以上被检出才置为告警事件，告警保持5秒，避免单帧闪烁造成的通知轰炸。

告警帧保存按“事件”组织，不是按时间戳：

event_id = f"{site_id}_{track_id}_{frame_count // 25}" cv2.imwrite(f"alarms/{date}/{event_id}.jpg", frame) with open(f"alarms/{date}/{event_id}.jsonl", "a") as f: f.write(json.dumps({"cls": cls, "conf": conf, "xyxy": box}) + "\n")

event_id里的frame_count//25把25帧内的检测合并成一次事件，jsonl逐行追加比反复打开关闭json文件靠谱。我习惯在交付时把“未戴帽”改成“未戴帽且处于作业面、连续两帧确认”，现场报警量通常能降一半，工长反而更认这套系统——宁缺毋滥在安全告警里同样是句实话。希望你从这篇实战笔记里拿走的，不只是YOLOv11的命令，而是这套从数据到事件的处理习惯，希望帮到你。

本文还有配套的精品资源，点击获取