企业官网建设流程全解析

简介：面向智慧工地安全领域的YOLOv11目标检测开发者，《智慧工地安全：YOLOv11高空作业安全带佩戴检测模型调优技巧》是一份51页的PDF文档。内容覆盖YOLO系列算法原理回顾、高空作业安全带数据集的采集标注与预处理、学习率/批量大小等超参数调优、数据增强策略、训练验证流程优化、常用性能指标分析以及云端/边缘/混合部署案例，可为安防监控、工业检测等场景下快速落地高精度安全带佩戴检测方案提供参考。资源包内仅包含1个PDF文件，压缩包大小2.26MB，文档无缺页或乱码，文字、图表、目录均显示正常，支持阅读器大纲与章节快速定位，可按目录顺序阅读或直接跳转目标章节。目前已有142人学习下载，适合希望系统掌握YOLOv11模型调优技巧的研究者、算法工程师及相关专业学生查阅使用，为实际项目提供可复用的调参思路。

1. 高空作业安全带检测：为什么先聊 YOLOv11 调优而不是换模型

在智慧工地项目里，安全带佩戴检测是最容易被低估的一类视觉任务。高空场景中，安全带挂点小、工人距离摄像机远，正样本往往只占图像几十个像素，加上逆光、遮挡和反光背心的干扰，模型稍有不慎就从高召回跌成高误报。用 YOLOv11 做这个任务，不是因为它在 COCO 上刷榜，而是它的解耦头、训练收敛特性和端侧部署路径，在工程上最省心——真正决定项目能不能验收的，是后续的模型调优技巧：小目标优化、数据配比、NMS 后处理和量化部署。这篇笔记按我自己在工地项目里的流程来写，从网络结构怎么理解，到标签怎么标、参数怎么调、坑在哪、部署怎么省内存，读完你可以在自己的数据集上直接把参数抄走试一遍。

2. YOLOv11 网络结构里跟安全带检测直接相关的部分：先理解再动手

2.1 从 C3k2 到 SPPF 变体：哪些模块真正影响小目标召回

YOLOv11 的 backbone 和 neck 相比 YOLOv8 最大的变化，是把原来 C2f 里的一部分卷积路径换成了 C3k2 模块。C3k2 的核心是用更小的 kernel 组合替代部分大卷积，理论上参数更省，但实际上对安全带这类小目标的检测，它并不直接决定召回率。真正决定小目标能不能被检出来的，是下采样倍率和特征层融合的方式。

YOLOv11 默认还是 P3/P4/P5 三尺度输出。P3 对应 8 倍下采样，是安全带检测的主战场。巡逻球机画面里一根安全带的宽度通常在 8~16 像素之间，只有落在 P3 层上的特征才有足够分辨力。如果按默认的 640 输入去训练，P3 层感受野大概是 8×8 的原始区域，对照安全带目标规模，勉强够用，但如果施工现场把摄像机架在塔吊臂或基坑边缘，目标缩到 4 像素，P3 也救不回来。

C3k2 里有一个可以调的小参数，是中间 bottleneck 的个数。默认配置下，C3k2 在 backbone 的每个 stage 里只堆 1 个 bottleneck，如果你发现 P3 层小目标漏检多，可以把 backbone 前两个 stage 的 bottleneck 数加一倍，代价是训练速度大约降 15%，但对小目标的特征表达能力会有可感知的提升。这个改动不需要改模型结构文件，直接在 YOLOv11 的 yaml 配置里改数字就行。

2.2 SPPF 的 pool 尺寸选择与目标尺寸的匹配关系

YOLOv11 的 SPPF 模块用三个串联的 5×5 max pool 来扩大感受野。对于安全带这类小目标，SPPF 的 pool 尺寸影响很小，但有一个容易翻车的点：如果你为了适配工地场景把输入分辨率从 640 提到 1280，但 SPPF 的 pool 尺寸没动，neck 层输出特征图变大之后，信息聚合范围相对变小，对极小目标不一定有帮助。

我的做法是：当输入分辨率提升到 1280 时，把 SPPF 的三个 pool 从 5 改成 3。理由是高空图像里目标虽然小，但背景也相对干净，不需要过大的感受野去关联上下文——安全带就是一条带子挂在人身上，上下文范围比车辆检测小得多。改 pool 尺寸在 yaml 里同样是一行事。

# yolov11-safety.yaml 片段，基于 yolov11s 调整 backbone: - [-1, 1, Conv, [64, 3, 2]] - [-1, 1, Conv, [128, 3, 2]] - [-1, 2, C3k2, [256, False]] - [-1, 1, Conv, [256, 3, 2]] - [-1, 2, C3k2, [512, False]] - [-1, 1, Conv, [512, 3, 2]] - [-1, 2, C3k2, [1024, False]] - [-1, 1, SPPF, [1024, 3]] # 原为 5，1280 输入时改成 3

上面这段 yaml 里，SPPF, [1024, 3]最后的数字 3 就是 pool kernel size。如果你输入分辨率保持 640，不建议动它。这里需要注意：改了 SPPF 的 pool 尺寸之后，neck 层的通道数不会变，所以预训练权重依然可以加载，不会出现 shape mismatch 的问题。

如果你想在 neck 里再接一个注意力模块，HCANet 那种思路可以参考——在 P3 层输出前加一个通道注意力，强制模型关注安全带这种细长结构。不过常见做法是在训练稳定之后再加，一开始就加会让收敛变慢，损失曲线会长时间下不去。

2.3 解耦头与 loss 分配：为什么安全带检测容易「检得出、框不准」

YOLOv11 的 head 是解耦的，分类分支和回归分支各走各的卷积。安全带的分类很简单，就一个类别，难的是回归——安全带的框是极端的长条形，宽高比常常超过 1:5，而默认 anchor-free 的回归头对极端长宽比目标天生不敏感。

训练时如果发现 mAP50 还可以、mAP50-95 一直低，大概率是回归分支对长条形目标的定位精度不足。常见解决路径有两个：一是把回归 loss 从默认的 CIoU 换成 SIoU，SIoU 对角度和长宽比更敏感，对细长目标有明显改善；二是在数据增强里对长条形目标做专门的随机旋转增强，让模型见过更多角度的安全带，避免它把竖直佩戴的安全带学了、斜挎的就漏掉。

# 在 YOLOv11 的 loss 配置里切换回归 loss 的写法 # ultralytics/cfg/default.yaml 中修改 loss 相关参数 loss: box: 7.5 # 默认 7.5，长条形目标可提到 9.0 cls: 0.5 # 单类别任务可以再降 dfl: 1.5 # 分布式 focal loss，建议保持默认

参数说明：box权重提高之后，模型会更卖力地把框回归准，但如果你的工地画面里遮挡严重，框的标注本身就带噪声，box 权重太高反而会把标注噪声学进去。cls在单类别任务里不是瓶颈，降一点可以防止分类分支和回归分支在解耦头里互相抢梯度。

最后说环境配置。YOLOv11 的训练环境其实没有想象中苛刻，CUDA 11.8 以上配 PyTorch 2.x，ultralytics 包直接 pip 装就行。真正要注意的是 batch size 和显存的匹配，后面第 4 章会细说。

3. 数据与标签策略：安全带检测的成败在标注阶段就定了

3.1 安全带目标尺寸分布统计：小目标优化的前提

很多工地项目的标注数据是直接找外包标了事。做 YOLOv11 小目标优化前，第一步先统计目标尺寸分布，连目标多小都不知道，谈优化就是玄学。用下面的脚本把标注框的尺寸分布拉出来，看 P3 层理论上能不能覆盖。

import json from collections import Counter # 假设标注是 labelme 格式，这里换成你自己的解析逻辑 with open("annotations.json", "r") as f: data = json.load(f) size_bins = Counter() for img in data["images"]: for ann in img["annotations"]: w = ann["bbox"][2] # 标注框宽 h = ann["bbox"][3] # 标注框高 max_side = max(w, h) if max_side < 8: size_bins["<8px"] += 1 elif max_side < 16: size_bins["8-16px"] += 1 elif max_side < 32: size_bins["16-32px"] += 1 else: size_bins[">32px"] += 1 print(size_bins)

这段代码的逻辑很简单：把每个标注框的长边分桶，长边小于 8 像素的在 P3 层上都不一定有一个完整的 anchor 特征覆盖。统计完之后，如果<8px的比例超过 20%，你的调优重心就必须放在输入分辨率和复制粘贴增强上，而不是去调 NMS 阈值。参数上需要关注的是 bbox 坐标系的归一化方式——如果标注文件里是像素坐标而训练时用的是归一化坐标，尺寸分布会被算错，先把单位统一了再统计。

3.2 标注规范：反光背心、安全绳和安全带的区分

安全带检测最常见的标注错误，是把反光背心当成安全带。工地工人普遍穿反光背心，背心上的荧光横条和反光带在视觉上跟安全带高度相似，尤其当工人背对镜头时，反光背心的肩带和腰带看起来就像没系安全带。标注规范里必须明确：只标注跨过肩部和腰部的独立织带，不标反光背心自带的装饰条。

标注框的贴合度也要定标准。安全带的几何形态是一条窄带，但很多外包标注员习惯性把框拉成正方形，导致长宽比信息丢失。对回归分支来说，框的长宽比本身就是特征，正方形框会让模型学到错误的目标形状。我一般要求标注框紧贴安全带的可见部分，不延伸到人体轮廓之外，宁可框小一点，不可框大。

如果同一人同时系了安全绳和安全带，两个目标重叠度高，标注时按遮挡关系只标可见的那个。否则训练时同一个位置出现两个框，模型会被 YOLOv11 的匹配策略搞糊涂——它会把两个框分配给同一个 anchor 区域，导致 loss 震荡。

3.3 数据增强组合：小目标复制粘贴比 Mosaic 更稳

YOLOv11 默认开启 Mosaic、MixUp 和 HSV 扰动。但高空安全带场景有个特殊问题：Mosaic 把四张图拼在一起后，目标整体缩小到原来的 1/2 甚至 1/4，本来就 8 像素的安全带会变成 2 像素，完全超出可学习范围。我在工地项目里直接关掉了 Mosaic 在最后 50 个 epoch 的作用（ultralytics 里可以将mosaic设为 0 或按 epoch 衰减），改用小目标复制粘贴增强。

复制粘贴增强的思路是：把标注好的安全带目标从原图抠出来，缩放旋转后贴到另一张图的空旷区域（比如天空、地面、未施工区域）。这个操作能有效增加小目标样本数，因为安全带的背景变化不大，贴图造成的域偏移很小。

# ultralytics/cfg/default.yaml 关键增强参数（基于 YOLOv11 默认改） mosaic: 0.5 # 训练前 60% 的 epoch 保留，后半程建议降到 0.1 或关闭 mixup: 0.1 # 单类别任务 mixup 收益小，降下来防震荡 hsv_h: 0.015 # 色调扰动保持默认 hsv_s: 0.7 # 饱和度扰动保持默认 hsv_v: 0.4 # 明度扰动可以开到 0.5，工地逆光多 degrees: 45.0 # 关键参数：安全带佩戴角度变化大，旋转增强必须开 translate: 0.1 scale: 0.3

参数说明：degrees: 45.0是安全带检测最能出效果的一项增强，因为工人弯腰、转身、攀爬时安全带的视觉角度变化远大于普通目标。mosaic后半程降下来是为了避免小目标被过度缩小。mixup对单类别检测基本没有正向收益，保留一个很小的值防过拟合就够了。

3.4 验证集构建：按视频抽帧而不是按图像随机划分

工地数据集通常是从监控视频里抽帧得到的。如果直接把所有帧打乱后随机划分训练集和验证集，同一个人的同一段动作会同时出现在两边，验证集 mAP 会虚高 5~10 个点，部署到现场就现原形。正确做法是按视频片段划分，把每路摄像头的连续时间段作为一个整体，一部分时间段进训练集，另一部分时间段进验证集。

验证集要特别覆盖三类场景：工人背对镜头、逆光、夜间补光。这三类是最容易在测试阶段翻车的，如果验证集里没有，调优就失去了参照。我自己会在训练集之外单独留一个「hard set」，专门放这些恶劣样本，每个 epoch 结束用 hard set 算一次 mAP，这个值比官方验证集的 mAP 更能反映现场真实水平。

4. 训练调优核心参数与超参数组合：从 loss 曲线到 mAP 的完整链路

4.1 输入分辨率与 batch size 的匹配：先算显存账

YOLOv11 小目标优化的第一个杠杆是输入分辨率。默认 640 输入下，8 像素的安全带在 P3 层上只剩 1×1 个特征点，几乎没有形状信息。我把输入分辨率提到 960 或 1280，P3 层上 8 像素目标能占 2×2 到 3×3 个特征点，召回率会有肉眼可见的提升，特别是从球机远距离画面里检出安全带。

但分辨率不是白提的。960 输入比 640 输入的计算量大 2.25 倍，显存占用同步上涨。用 4090 24G 训练时，batch size 从默认 16 要降到 8，不然直接 OOM。1280 输入下，我通常会配合梯度累积来模拟更大的 batch。

# 960 输入 + 梯度累积的启动命令 yolo train \ data=safety.yaml \ model=yolov11s.pt \ imgsz=960 \ batch=8 \ epochs=150 \ optimizer=SGD \ lr0=0.01 \ lrf=0.01 \ warmup_epochs=3.0 \ cos_lr=True \ accumulate=4

参数说明：accumulate=4表示每 4 个 batch 做一次梯度更新，等效 batch size 是 32，比直接开 batch=32 省显存，但训练时间会略长。optimizer=SGD是我在小目标检测任务上的习惯——AdamW 收敛快，但后期容易在小目标回归上震荡；SGD 配合 cosine 学习率衰减更稳。warmup_epochs=3.0不能省，YOLOv11 前几个 epoch 的 anchor 分配还很不稳定，跳过了容易在第一个 epoch 就损失爆炸。

4.2 anchor 分配策略与 loss 权重：三条经验参数

YOLOv11 是 anchor-free 的，但它在训练时仍然有正样本匹配的过程。默认的匹配策略会根据目标的宽高比选择特征层，对细长目标不会特别照顾。这里有三条调参经验：

第一，把boxloss 权重从默认 7.5 提到 9.0 到 10.0。安全带的分类很简单，模型不会认错，难的是框的边界，特别是肩带和腰带交叉的位置。第二，把cls权重从默认 0.5 降到 0.3。单类别任务里分类分支的梯度会主导早期训练，压一压能让回归分支拿到更多梯度。第三，dfl保持默认 1.5 不要动。DFL 对边界框的离散分布建模很敏感，乱调会让框收敛到错误的位置。

# 推荐的安全带检测 loss 权重配置 loss: box: 9.5 # 原 7.5，长条形目标回归压力大 cls: 0.3 # 原 0.5，单类别任务分类压力小 dfl: 1.5 # 保持默认

这三种设置的效果，反映在验证集上通常是 mAP50 变化不大，但 mAP50-95 会从 35 左右升到 42 左右。如果你的项目验收只看 mAP50，这一个改动不够明显，但在实际抓拍里框会从「大概框住人」变成「框住安全带本体」，下游的违规判定逻辑才写得下去。

4.3 训练轮数与学习率策略：从 loss 曲线判断何时停

安全带检测数据集一般就几千张，训练 150 epoch 足够。关键是学会看 loss 曲线，而不是盲目加轮数。YOLOv11 训练时主要看两条曲线：训练 loss 和验证 mAP。如果训练 loss 还在稳定下降、验证 mAP 也还在涨，说明欠拟合，继续训；如果训练 loss 还在降但验证 mAP 不动了，开始过拟合，就该回调增强或提前停止。

硬要给出一个可抄的参数，我会建议：warmup 3 个 epoch、cosine 学习率、初始 lr0 在 SGD 下用 0.01、在 AdamW 下用 0.001。训练到 30 epoch 时，如果 mAP50 还没过 50，先别急着调参，回看数据质量和标注规范——大多数时候是标注问题而不是模型问题。

4.4 模型结构选择：yolov11s 是工地场景的性价比底线

YOLOv11n 在 Jetson 上跑得最快，但从小目标检测的效果看，n 模型在 P3 层上的特征通道太少，8 像素的安全带基本学不出形状。工地项目我至少用yolov11s，如果对精度要求高且部署端是 PC 或云端，yolov11m更稳。模型越大，P3 层能表达的特征越丰富，对极小目标的提升是结构性的，比调任何 loss 权重都直接。

表格里的数字是项目里接近的量级，不同工地场景会差不少，但比值有参考性。yolov11s在 960 输入下，mAP50 和推理耗时最平衡，是我的默认选择。想上yolov11m，先确认部署端的算力预算，否则训练出来了也落不了地。

4.5 训练产物管理：每次实验保留完整配置与权重

调优过程中最大的坑不是参数不对，而是改乱了不知道哪版参数跑出哪个结果。我每个实验都固定用 ultralytics 的自动日志，跑完直接看runs/detect/train/里的args.yaml和weights/best.pt。args.yaml记录了这次实验的全部参数，best.pt是按验证集 mAP 保存的最优权重。

如果要管理多个实验版本，给每次训练命名加后缀：

yolo train model=yolov11s.pt data=safety.yaml imgsz=960 batch=8 epochs=150 name=exp_s_960_v2

name=exp_s_960_v2会让训练输出到runs/detect/exp_s_960_v2/目录，不会覆盖之前的实验。到了调优后期，你会发现最值钱的就是这份实验记录——回滚的时候它就是后悔药。

5. 模型调优避坑指南：5 个反复出现的现场问题

5.1 远距离小目标漏检：P3 层单独加权

现象：验证集上一切正常，一到现场球机画面，距离超过 15 米的工人就检不出来。

原因：现场距离导致目标实际像素比训练集里的分布更小。训练集的标注框长边中位数是 14 像素，现场远距离目标只有 5~7 像素，超出了训练分布的下界。

解决：不用换网络，先做两件事。第一，把训练集里小于 8 像素的目标做 2~3 倍复制粘贴增强，强制把训练分布往下扩；第二，推理时把输入分辨率从 960 提到 1120。ultralytics 支持在 predict 时设置imgsz，跟训练时不一致也没关系。经过这两个改动后，现场远距离召回能从 50 提到 70 左右。

5.2 逆光场景误检严重：不做额外处理，先看训练增强

现象：下午低角度阳光时，把安全绳的阴影误检成安全带，或者把塔吊钢丝绳误检成目标，误报率飙升。

原因：安全带的 HSV 特征在逆光下发生偏移，模型学到的颜色分布和形状特征在强阴影下失效。

解决：把hsv_v从默认 0.4 开到 0.6，hsv_s从 0.7 开到 0.9，在训练阶段就见过更宽的亮度变化。另外，不要在输入图像上额外加自适应直方图均衡，工地画面的亮度分布很复杂，全局均衡反而会把阴影加重。

5.3 NMS 把密集人群中的多个目标压成一个框

现象：脚手架上有两三个人同时作业，距离很近，模型检出了多个安全带，但 NMS 之后只保留了一个框或直接框住两个人。

原因：YOLOv11 默认 NMS 阈值是 0.5，对密集重叠目标来说太激进，重叠度高的小目标会被吞掉。

解决：把 NMS 的 IoU 阈值从 0.5 降到 0.3 到 0.35。在 ultralytics 里推理时可以设置iou=0.35。代价是密集场景下的重复框会多一些，需要在后处理里按置信度排序去重。

# 推理时降低 NMS IoU 阈值，保留密集小目标 from ultralytics import YOLO model = YOLO("runs/detect/exp_s_960_v2/weights/best.pt") results = model.predict( source="camera_008.mp4", imgsz=1120, conf=0.35, # 置信度阈值，按需调整 iou=0.35, # NMS IoU 阈值，密集场景调低 save=True, )

参数说明：conf=0.35和iou=0.35是两个不同维度——conf控制哪些框被保留，iou控制重叠框怎么合并。如果你降低iou之后重复框变多，说明conf可以适当提高一点。yolov11 保存推理结果时，save=True会自动把标注框画在帧上并保存为视频或图片，这个参数在排查阶段很好用——直接看可视化结果就能判断是 NMS 的问题还是检测器的问题。

5.4 验证集 mAP 高、现场表现差：数据泄漏与场景偏差

现象：训练时验证集 mAP50 到了 92，一到现场只有 70 不到，差距大到无法解释。

原因：两类问题叠加。第一，验证集按帧随机划分，同一段视频的相似帧同时进了训练集和验证集，mAP 虚高。第二，现场摄像机安装角度和训练数据差异大，球机的俯视视角在训练集里占比太少。

解决：验证集按视频片段而不是按帧划分，施工前先建一个 hard set。安装新的摄像机后，先用它录 30 分钟素材，人工标注后做一次增量微调。这类问题没有一劳永逸的解法，只能在数据闭环上做文章。

5.5 Jetson Nano 上训练好的模型推理时内存溢出

现象：PC 上跑得好好的 best.pt，转到 Jetson Nano 上推理，前几帧正常，几分钟后进程被杀，报 out of memory。

原因：PyTorch 模型在 Jetson 上直接跑，推理时会有大量显存碎片；视频流读写没释放句柄；每帧都做图像缩放对象，内存只增不减。

解决：先转 TensorRT 再部署，这会同时解决速度和内存问题。Jetson Nano 的详细部署步骤见第 6 章，这里只说关键点：视频帧要复用同一个 cv2.VideoWriter 对象，不要每帧新建；帧处理完马上释放；推理统一走 TensorRT engine，不再加载 PyTorch 模型。

6. 从 PyTorch 到 Jetson：YOLOv11 安全带的端侧部署调优实战

端侧部署是智慧工地项目里避不开的环节。边缘盒子和 Jetson 设备是主流方案，这里给一套我常用的 YOLOv11 部署流程，从导出到推理都覆盖，重点说yolov11 预测后保存和 int8 量化的坑。

第一步，把训练好的 best.pt 导出为 ONNX，再转 TensorRT。这里注意：导出时务必指定opset=12，否则 Jetson 上的 TensorRT 版本可能不认。第二步，用trtexec生成 engine 文件。Jetson Nano 的算力有限，建议 FP16 精度，int8 需要校准集且 mAP 下降明显，安全带这种小目标对量化误差很敏感，我不推荐。

# 在 Jetson Nano 上导出 ONNX（如果直接导出 TensorRT 则跳过这步） yolo export model=best.pt format=onnx opset=12 dynamic=False imgsz=960 # 用 trtexec 生成 FP16 engine trtexec \ --onnx=best.onnx \ --saveEngine=best_fp16.engine \ --fp16 \ --workspace=1024

参数说明：imgsz=960要与训练时的输入一致或按现场需求重新定——这个参数决定了推理网络输入张量的尺寸，改大之后推理变慢，改小之后小目标失效。dynamic=False固定输入尺寸，Jetson 上省显存也省推理时间。workspace=1024是 TensorRT 构建时的最大显存预算，单位是 MB，不算太大，避免在构建阶段就爆显存。

构建好的 engine 文件可以直接在 Python 里用 TensorRT 加载推理。正规工程做法是把 engine 的输入输出绑定好，图像预处理用 CUDA 完成，帧循环里只做推理和画框。

import cv2 import numpy as np import tensorrt as trt import pycuda.autoinit # 依赖 pycuda # 加载 engine with open("best_fp16.engine", "rb") as f: engine_data = f.read() runtime = trt.Runtime(trt.Logger(trt.Logger.WARNING)) engine = runtime.deserialize_cuda_engine(engine_data) # 推理时输入图像尺寸按 engine 定义 input_shape = (960, 960) cap = cv2.VideoCapture("rtsp://192.168.1.64/live") writer = cv2.VideoWriter( "output_result.avi", cv2.VideoWriter_fourcc(*"XVID"), 25, (1920, 1080), ) while True: ret, frame = cap.read() if not ret: break # 预处理：resize 到 960，归一化 img = cv2.resize(frame, input_shape) img = img.astype(np.float32) / 255.0 img = img.transpose(2, 0, 1)[None] # 推理 + 后处理，省略 TensorRT 绑定细节 # boxes, scores = infer(engine, img) # 画框并保存 writer.write(frame) cap.release() writer.release()

逻辑说明：这个帧循环是最小可用的骨架。yolov11 推理结果保存的正确做法是复用同一个 VideoWriter，而不是每帧调用 imwrite——工地视频一跑就是几十分钟，频繁磁盘 IO 会掉帧甚至卡死。writer的编码用 XVID，兼容性比 MJPG 稳，文件大小也控制得住。

如果你的工地摄像头是枪机固定机位，还有一个内存优化技巧：画面里的施工区域只占一部分，可以先把检测区域裁剪出来再做 resize。这样输入尺寸可以从 960 降到 640，Jetson 上的推理延迟能从 40ms 降到 18ms 左右，漏检率也不会明显变差——因为被裁掉的区域本来就没有作业面。

最后说一个我长期以来的操作习惯：任何部署项目，第一次跑通都先保存一份带检测框的输出视频，而不是只看终端日志里的检测数量。检测数量可以骗人，但框在画面上画没画正、有没有飘，一眼就能看出来。这个习惯帮我避过无数次「模型指标正常但现场不可用」的翻车。希望这些调优技巧能帮你在工地上少踩几个坑。

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