企业官网建设流程全解析

刚帮一个朋友调试完工地监控系统，他那边一直靠门卫人工登记进出车辆，渣土车、搅拌车、水泥罐车一天几十台，高峰期堵在门口，漏记错记是常事。后来我们聊到用视觉方案自动识别，于是基于 YOLOv10 做了一套工地运输车识别检测系统，覆盖数据准备、模型训练、UI 界面封装到上线调优的完整链路。这篇文章就把整套项目怎么落地讲清楚，包含源码组织、训练参数、界面逻辑和实测优化，做毕设、做小型项目或者自己搞视觉方案的开发者可以直接参考。

1. 为什么这个项目选择了YOLOv10：工地场景的特殊性与模型选型逻辑

1.1 工地运输车识别到底难在哪

工地和普通道路监控最大的区别在于环境不可控。我最初想直接套用开源的通用车辆检测模型，但实际测试发现效果很不理想。工地现场常年有扬尘，摄像头位置又普遍偏低，车辆经过时扬起灰尘会直接遮住车头车尾特征。更麻烦的是光照条件跨度极大——晴天正午的高对比度、傍晚逆光时的剪影、夜间靠补光灯照出的一片惨白，这些都是通用模型没有重点优化过的场景。

车辆类别本身也很有迷惑性。渣土车和普通的重型自卸卡车外形接近，混凝土搅拌车和油罐车远看都是"大罐子"，装载机和挖掘机这类工程机械在工地里也会频繁移动。如果类别定义不清晰，网络在特征提取时会非常纠结。另外，工地运输车往往从远处进入监控画面，刚开始只是几十个像素的小目标，逐渐靠近后又会出现大目标的截断问题——车头已经出画面，只剩车厢还在取景框里。

传统方案基本做不了这件事。背景建模和帧差法虽然实现简单，但它们只能判断"画面里有东西在动"，扬尘、飞鸟、光影变化都会触发误报，更别说区分这是渣土车还是搅拌车。我早期试过用 Haar 特征级联分类器，效果也很差，因为这类方法本质上是浅层特征匹配，应付不了工地这种高遮挡、高噪声、多尺度的复杂场景。

1.2 YOLOv10相比YOLOv8/v5在部署上的关键改进

YOLO 系列在通用检测任务上已经非常成熟，那为什么最终选了 YOLOv10？核心原因有两个：端到端部署的简洁性和推理延迟的稳定性。

YOLOv10 最值得注意的设计是去掉了 NMS（非极大值抑制）这一步。传统 YOLO 模型预测完一组候选框之后，还需要用 NMS 把重叠的高置信度框合并掉，而 NMS 本身带有超参数，在不同场景下需要反复调试。YOLOv10 采用双标签分配策略，训练时让一个预测头走"一对一"匹配，另一个走"一对多"匹配，推理阶段直接输出最终结果，去掉 NMS 不仅减少了一次后处理耗时，也避免了 NMS 阈值设置不当导致的漏检或误检。

网络结构上也做了针对性优化，骨干部分引入了更轻量的模块设计，整体参数和计算量比同尺度的 YOLOv8 更小。对工地这种部署环境来说，这意味着同样用一块普通显卡，YOLOv10 可以跑出更高的 FPS；如果压缩到 CPU 方案，模型参数更小的优势会更明显。精度方面，在相同条件下 YOLOv10 与 YOLOv8 基本持平，某些类别上略有提升，配合它更低的延迟，综合性价比是高的。

我实测下来，同样的视频流，YOLOv8s 在工控机上推理一帧大约需要 28ms，YOLOv10s 大约是 20ms，差距不算夸张，但在持续 24 小时运行的场景里，稳定性和低延迟就是实打实的收益。

1.3 为什么不选两阶段模型和大模型方案

我也考虑过 Faster R-CNN 这类两阶段检测器，精度确实有优势，尤其对小目标更友好。但问题是推理速度完全跟不上实时监控的需求。工地出入口的视频流至少是 25fps，Faster R-CNN 在 CPU 上基本跑不动，在普通 GPU 上也勉强只能做到每帧 100ms 以上的延迟。而 YOLOv10 在同样硬件上能轻松跑出实时帧率，对于"识别运输车并触发提示"这种需求，速度优先级高于那一点点精度差距。

大模型方案我也评估过。像通用分割大模型那种思路，精度上限确实高，但部署时需要考虑显存占用和推理延迟。一个工地项目通常只会配一台几万元以内的工控机或旧服务器，在这种硬件条件下，大模型的推理耗时和内存占用都是不可接受的。视觉检测任务里，"够用"比"最优"更重要，YOLOv10 在精度、速度、部署成本三者之间找到了一个很稳的平衡点。

我把几类方案的对比整理了一下，方便你按自己的硬件条件做选择：

2. 数据是地基：工地运输车数据集的采集、标注与增强细节

2.1 类别定义与标注边界

做检测项目的第一件事不是急着下载权重训练，而是先把类别定义锁死。这个项目的核心对象是"工地运输车"，我最终保留了五类基础运输车辆，另外把常见的工程机械单独列出作为可选项。你可以直接参考这组定义：

如果你只做毕业设计，建议把类别控制在 3 到 5 类，数据量不需要太大，训练迭代也更快。如果项目要真正落地到工地使用，再把装载机、挖掘机这类工程机械加进去，但每增加一个类别就要相应补足该类别的样本数量，不然会出现严重的类别不平衡。

标注时的边界规则比想象中重要。我的经验是严格遵守三条原则：目标可见部分太少不标，例如车辆被扬尘遮到只剩一个角；目标在画面里小于 15 个像素不标，否则只是给网络增加噪声；车体被画面边缘截断超过一半不标，因为这种目标的特征已经不完整。尤其要注意搅拌车和罐车的区分，两者都是大罐子，但搅拌车罐体上有明显的加强筋斜纹，罐子尾部有卸料斗，标注时框要完整框住整个罐体，别只框半截。

2.2 采集策略与标注实操

数据来源我建议按"工地自有监控 + 网络公开开源数据 + 手机补充拍摄"三个渠道组合。工地自有监控视频是最好的数据源，因为它的视角、高度、画面风格和最终部署环境几乎一致。方法很简单：从监控录像里按时间间隔抽帧，例如每小时抽取 5 分钟，再把这 5 分钟内按每 2 秒一帧保存，避免连续帧大量重复导致的数据冗余。如果安装位置近期不会调整，还可以专门录制几个不同光照时段的视频段，从源头提升数据多样性。

公开的开源检测数据集可以用来补充车辆侧面的样本，但这个渠道需要花时间清洗，很多通用数据集里的车辆图片是在城市道路拍摄的，环境背景干净，放到工地场景里反而会成为负样本干扰。手机补充拍摄的价值在于可以捕捉到工地现场的真实机位，比如用手机在门卫室旁边拍一段进出车辆的视频，虽然画质和监控有差异，但能丰富车辆角度。

标注工具我用的是 LabelMe，操作门槛低，支持多人协作。标注完导出时选择 YOLO 格式，会生成对应的 txt 文件，每一行是"类别ID x_center y_center width height"，坐标都是归一化到 0 到 1 的浮点数，直接就能喂给训练脚本。这里提醒一句，标注时千万不要框得过大或过小，框太紧会把搅拌罐的边缘纹理切掉，框太松会把背景地面和扬尘也包进来，都会显著影响特征学习。以眼见的目标整体为准，尽量贴合车辆轮廓。

2.3 针对工地环境的增强策略与数据集划分

工地场景的增强不能只套通用方案，要围绕实际环境做定向增强。我在训练配置里除了开启 Mosaic 和 HSV 扰动，还额外做了几类针对性增强：

• 模拟扬尘：给随机样本添加高斯噪声和模糊核，模拟灰尘遮挡的朦胧感。
• 模拟逆光：对部分图片做亮度整体下调并拉高对比度，模拟黄昏逆光下的剪影效果。
• 模拟夜间补光：降低曝光、增强画面噪点，贴近夜间监控的实际画质。
• 目标遮挡模拟：随机擦除目标区域，模拟车辆之间有遮挡的常见情况。

增强强度需要把握分寸，我的习惯是把亮度扰动范围设置在 ±30%，噪声强度不要大到人眼都看不清目标的程度，否则网络会学到错误纹理。增强的目的是扩充样本分布，不是把训练集变得面目全非。

数据集划分上，一定要避免"同源污染"。如果直接从同一段视频里抽帧，相邻帧画面几乎一样，把连续帧同时分到训练集和验证集，验证出来的指标会虚高。我的做法是先按视频来源分组，每个来源的视频时间片段整体分配，比如前三天的监控抽帧放训练集，第四天放验证集，第五天放测试集，这样验证结果才有参考意义。常见比例是 8:1:1，图片总量我建议每个类别至少准备 300 到 500 张有效标注图，总样本量在 2000 到 3000 张之间，对这个规模的项目已经足够训练出可用模型。

3. 模型训练实操：从环境配置、超参数调整到指标评估的完整过程

3.1 训练环境搭建与版本组合

环境配置是很多新手卡壳的第一关。我给出一个经过反复验证的组合，照抄基本不会出问题：Python 3.9 或 3.10、PyTorch 2.1 以上、CUDA 11.8 或 12.1，视觉库使用 ultralytics 库来加载和训练 YOLOv10 权重。显卡方面建议显存不低于 8GB，这样可以用 batch size 16 训练 YOLOv10s；如果没有独立显卡，用 CPU 训练也不是完全不行，但需要把模型换成 YOLOv10n，图片尺寸降到 416，训练时间要做好按天计算的心理准备。

安装依赖直接用包管理工具装这几项：

pip install ultralytics pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install opencv-python onnxruntime

我建议训练时在命令行里使用python train.py的写法管理整个训练流程，把配置和数据集成在一个工程目录下。YOLOv10 的权重文件下载后放在项目目录下的weights文件夹里，初始可以先用yolov10n.pt跑通全流程，确认数据配置无误后再换成更大的模型。

3.2 迁移学习与分阶段训练策略

直接随机初始化权重训练，需要非常多的数据和算力才能收敛，项目阶段显然不现实。正确的做法是加载在大型通用视觉数据集上预训练好的 YOLOv10 权重，用迁移学习微调到工地运输车类别。预训练权重已经学会了通用的边缘、纹理、形状等底层特征，我们只需要在高层语义上做适应。

具体到训练策略，我采用分阶段微调：

1. 第一阶段冻结骨干网络的大部分层，只训练检测头部分。骨干网络提取的是通用特征，不需要大规模改动，让检测头先学会"这些类别对应什么特征组合"。冻结实现方式是在 ultralytics 模型对象上遍历参数并设置requires_grad=False。
2. 第二阶段解冻全部层，用较小的学习率整体微调。此时骨干网络会在工地场景的专属特征上做精细调整，例如搅拌罐的斜纹、渣土车的货厢结构。
3. 每个阶段跑 30 到 60 个 epoch，整体训练在 100 到 150 个 epoch 左右可以收敛。

训练脚本可以参考下面这段：

from ultralytics import YOLO model = YOLO("weights/yolov10n.pt") # 阶段一：冻结骨干，只训练检测头 for name, param in model.model.named_parameters(): if "cv" not in name and "dfl" not in name: # 保留检测头部分可训练 param.requires_grad = False model.train( data="dataset/construction_vehicle.yaml", epochs=60, imgsz=640, batch=16, lr0=0.01, warmup_epochs=3, name="stage1" ) # 阶段二：解冻全部层，低学习率精调 for param in model.model.parameters(): param.requires_grad = True model.train( data="dataset/construction_vehicle.yaml", epochs=60, imgsz=640, batch=16, lr0=0.002, name="stage2" )

数据集配置文件construction_vehicle.yaml是训练的关键入口，格式如下：

path: ./dataset train: images/train val: images/val test: images/test names: 0: dump_truck 1: concrete_mixer 2: flatbed_truck 3: tank_truck 4: crane_truck

上面对应的标注 txt 文件要与每张图片同名放置，目录结构保持清晰，这是最容易被初学者忽略的一步。路径写错或者类别号对不上，模型会直接训练出一个废品。

3.3 超参数设置与常见误区

训练超参数建议按下面的初始值起步，再根据训练曲线动态调整：

我踩过最明显的坑是批量大小和图片尺寸都开得很大，然后发现显存溢出，于是下意识把 batch 调到 4，结果训练集 loss 曲线波动剧烈。后来才意识到，batch size 太小会导致梯度噪声过大，正确做法是保持 batch 在 16 左右，实在不够就用多卡或梯度累积，而不是死守小 batch。还有一个经验是 imgsz 不要盲目调大，640 起步往往已经够用，只有验证集上小目标漏检明显时才升级到 1280，因为大图会成倍增加训练时间。

3.4 训练监控、指标评估与迭代方向

训练过程中，ultralytics 会在输出目录下生成一组结果文件，重点是results.png里的 loss 曲线和验证指标曲线。我一般看四个信号：train/box_loss和train/cls_loss是否稳定下降、metrics/mAP50(B)是否在稳步上升、验证 loss 与训练 loss 的差距是否过大。如果训练 loss 下降但验证 mAP 停滞，大概率是过拟合，优先减少训练轮次、增加数据增强强度，或者加一点 dropout；如果两个 loss 都不降，则要检查数据标注有没有错、类别 id 是否对得上。

评价模型效果时，我会同时看mAP50和mAP50-95两个指标。mAP50衡量的是 IoU 阈值为 0.5 时的平均精度，对大多数应用场景已经足够；mAP50-95更严格，衡量在不同 IoU 阈值下的综合表现，数值会更低更"真实"。实际训练中，一个类别 mAP50 达到 0.85 以上、mAP50-95 在 0.6 以上，基本就具备落地条件了。

混淆矩阵是迭代方向的重要指引。如果混凝土搅拌车经常被识别成罐车，说明它们的外观特征在高层语义空间没有被充分区分，这时我会单独收集这两类车辆的样本，增加它们同时出现、同角度的训练图，让网络学会两者之间的细粒度差异。这个"看混淆矩阵补数据"的循环，比盲目加所有类别的数据要高效得多。

4. 系统源码与UI界面：把训练好的模型封装成可用的检测工具

4.1 系统功能与项目目录设计

训练完成拿到best.pt权重后，项目的重心就从"训练模型"转移到"做成工具"。这一步是区分"模型演示"和"实际可用系统"的关键，很多同学训练完就停在验证集上跑几张图片，但没有用户会直接使用命令行去看结果，他们需要一个界面、一个上传图片或视频的入口、一个可以调阈值开关的控件。

我在这个项目里把系统拆成几个模块：模型推理层、UI 交互层、结果展示层、导出记录层。目录结构大致如下：

construction_vehicle_system/ ├── main.py # UI 程序入口 ├── detector.py # 模型推理封装 ├── config.yaml # 界面初始参数与模型路径 ├── weights/ │ └── best.pt # 训练好的模型 ├── dataset/ │ ├── images/ │ └── labels/ ├── ui/ │ ├── main_window.py # 主窗口逻辑 │ └── widgets.py # 自定义控件 ├── outputs/ │ └── results/ # 检测结果保存目录

UI 框架我选择了 PySide6，相比 Tkinter 它更现代化，显示图像、表格组件都很成熟，而且和 OpenCV 配合起来很顺手。如果只是做一个极简演示，Tkinter 也能胜任，但要做到项目展示或实际部署，建议直接上 PySide6。

4.2 模型推理层的设计

推理层单独封装成一个类，便于 UI 层和后续功能复用。核心逻辑是加载权重、对输入图像做一次前向推理、返回检测框列表和类别信息。用 ultralytics 的YOLO类足够简洁，但要注意控制conf和iou两个参数。conf是置信度阈值，默认 0.25，实际使用中工地场景建议在 0.4 到 0.5 之间，太低会混入大量背景误检，太高又会漏掉远处的小目标；iou在 YOLOv10 中影响相对小，因为已经不需要 NMS，但接口上仍保留，设置 0.5 左右即可。

from ultralytics import YOLO import cv2 class TransportDetector: def __init__(self, weights_path="weights/best.pt", conf=0.45): self.model = YOLO(weights_path) self.conf = conf def detect_frame(self, frame): results = self.model.predict( frame, conf=self.conf, imgsz=640, verbose=False ) detections = [] for r in results: boxes = r.boxes.xyxy.cpu().numpy() confs = r.boxes.conf.cpu().numpy() cls_ids = r.boxes.cls.cpu().numpy().astype(int) for box, conf, cls_id in zip(boxes, confs, cls_ids): detections.append({ "bbox": box, # [x1, y1, x2, y2] "confidence": float(conf), "class_id": int(cls_id), "class_name": self.model.names[int(cls_id)] }) return detections

这里有个经验细节：predict每次调用会输出大量日志，把verbose=False关掉能让界面保持干净。输入图像要确保是 BGR 格式的 numpy 数组，OpenCV 读取默认就是这种格式，如果使用 PIL 或其他方式加载，需要先转换。

4.3 PySide6界面开发的关键逻辑与两个隐蔽坑

界面的核心功能其实不复杂：一个图像显示区、一个选择图片按钮、一个检测按钮、一个结果列表表格、一个置信度滑块。我贴一段简化版的核心代码，把自己实现过程中踩过的两个坑单独说明。

import sys import cv2 from PySide6.QtWidgets import ( QApplication, QMainWindow, QLabel, QPushButton, QFileDialog, QVBoxLayout, QHBoxLayout, QWidget, QTableWidget, QTableWidgetItem, QSlider, QComboBox ) from PySide6.QtGui import QImage, QPixmap from PySide6.QtCore import Qt from detector import TransportDetector class MainWindow(QMainWindow): def __init__(self): super().__init__() self.setWindowTitle("工地运输车识别检测系统") self.detector = TransportDetector() # 图像显示区 self.image_label = QLabel() self.image_label.setMinimumSize(800, 600) self.image_label.setAlignment(Qt.AlignCenter) # 按钮控件 self.open_btn = QPushButton("打开图片") self.detect_btn = QPushButton("开始检测") self.detect_btn.setEnabled(False) # 置信度滑块 self.conf_slider = QSlider(Qt.Horizontal) self.conf_slider.setRange(10, 90) self.conf_slider.setValue(45) self.conf_label = QLabel("置信度阈值: 0.45") # 结果表格 self.table = QTableWidget(0, 3) self.table.setHorizontalHeaderLabels(["类别", "置信度", "坐标 [x1,y1,x2,y2]"]) layout = QVBoxLayout() layout.addWidget(self.image_label) layout.addWidget(self.conf_label) layout.addWidget(self.conf_slider) layout.addWidget(self.table) btn_layout = QHBoxLayout() btn_layout.addWidget(self.open_btn) btn_layout.addWidget(self.detect_btn) layout.addLayout(btn_layout) container = QWidget() container.setLayout(layout) self.setCentralWidget(container) self.open_btn.clicked.connect(self.open_image) self.detect_btn.clicked.connect(self.run_detection) self.conf_slider.valueChanged.connect(self.update_conf) self.current_frame = None def open_image(self): path, _ = QFileDialog.getOpenFileName( self, "选择图片", "", "Image Files (*.jpg *.jpeg *.png)" ) if not path: return self.current_frame = cv2.imread(path) self.show_frame(self.current_frame, []) self.detect_btn.setEnabled(True) def show_frame(self, frame, detections): display = frame.copy() for det in detections: x1, y1, x2, y2 = map(int, det["bbox"]) cv2.rectangle(display, (x1, y1), (x2, y2), (0, 255, 0), 2) label = f"{det['class_name']} {det['confidence']:.2f}" cv2.putText(display, label, (x1, y1 - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) # OpenCV 是 BGR，QImage 是 RGB，必须转换，否则颜色偏蓝 rgb_frame = cv2.cvtColor(display, cv2.COLOR_BGR2RGB) h, w, ch = rgb_frame.shape qimage = QImage(rgb_frame.data, w, h, ch * w, QImage.Format_RGB888) pixmap = QPixmap.fromImage(qimage).scaled( self.image_label.width(), self.image_label.height(), Qt.KeepAspectRatio, Qt.SmoothTransformation ) self.image_label.setPixmap(pixmap) def run_detection(self): if self.current_frame is None: return detections = self.detector.detect_frame(self.current_frame) self.show_frame(self.current_frame, detections) self.populate_table(detections) def update_conf(self, value): conf = value / 100.0 self.conf_label.setText(f"置信度阈值: {conf:.2f}") self.detector.conf = conf def populate_table(self, detections): self.table.setRowCount(len(detections)) for row, det in enumerate(detections): self.table.setItem(row, 0, QTableWidgetItem(det["class_name"])) self.table.setItem(row, 1, QTableWidgetItem(f"{det['confidence']:.2f}")) self.table.setItem(row, 2, QTableWidgetItem(list(map(int, det["bbox"])).__str__()))

第一个坑是颜色格式问题。OpenCV 读入的图像是 BGR 顺序，而QImage.Format_RGB888要求的是 RGB 顺序，不转换的话画面整体发蓝发红，像是被蒙了一层诡异滤镜。直接用cv2.cvtColor先转一遍即可，这个细节能省下不少排查时间。

第二个坑是图像缩放比例。界面显示区域固定时，直接把QPixmap塞进去会拉伸变形，车辆的长宽比会失真，视觉上非常不专业。一定要用scaled配合Qt.KeepAspectRatio，保持原图比例再缩放显示。这一步在"看起来像正式项目"和"一看就是随手 Demo"之间起了很大作用。

4.4 ONNX导出与部署加速

模型在 PyTorch 环境里推理没问题，但真正部署到工控机上，往往希望减少依赖、提升速度。把权重导出成 ONNX 格式是一个低成本高收益的做法。ONNX 模型可以在没有 PyTorch 的环境中运行，体积更小，推理延迟通常还能下降 20% 左右。导出方法非常简单：

model = YOLO("weights/best.pt") model.export(format="onnx", dynamic=True, half=True)

这里dynamic=True允许动态输入尺寸，half=True存储为半精度浮点，能进一步压缩体积。导出后在 UI 推理层加载 ONNX 模型，实测 YOLOv10s 在 GTX 1660 上能从 20ms 降到 15ms 左右。如果部署机器是纯 CPU 环境，ONNX Runtime 也能正常运行，只是帧率有限，建议配合降低输入尺寸到 480 或 416 使用。

5. 实测中的坑与优化：从漏检、误报到推理速度的调优记录

5.1 扬尘、雨天、逆光对精度的影响

系统上线前，我在一个工地上连续测了几天监控视频，效果好的时段是晴天上午，效果差集中在三个时段：傍晚逆光、夜间补光、雨后地面反光。傍晚逆光时，采光方向上驶来的车辆车身几乎变成黑色剪影，模型明显倾向于漏检；夜间补光虽然解决了一部分亮度问题，但车灯会过曝形成大面积高光区域，影响车头特征提取。

针对这些问题，我做了两层处理。第一层是图像预处理，在推理前对输入帧做对比度增强，用了 OpenCV 的 CLAHE 自适应直方图均衡，算法对亮度不均的画面效果比较明显，能缓解逆光的过暗问题；第二层是数据层补救，我让现场人员补充了一段傍晚和夜间的监控视频，重新抽样标注后强化训练。两轮迭代之后，逆光条件下的漏检率有肉眼可见的下降。如果你不想投入太多时间收集夜间数据，也可以考虑在部署时加一盏补光灯，从源头改善光照条件。

5.2 小目标和遮挡车辆的漏检问题

远程小目标的漏检是最难缠的问题。工地出入口通常有几十米纵深，车辆刚进入画面时，在 1080p 画面里可能只占不到十分之一，模型经常识别不到。我最初把置信度阈值放到 0.25，误报又明显增加，属于"捡了芝麻丢了西瓜"。

经过几轮测试，我用三个手段组合解决了大部分问题。第一个手段是提高imgsz，从 640 调到 960，小目标漏检率下降明显，代价是推理时间增加约 50%；第二个手段是对监控画面做区域拆分，把出入口画面按上下分成两个检测区分别推理，虽然增加了一次推理调用，但每个区域里的目标相对更大；第三个手段是结合检测结果的时序稳定性做过滤，单帧置信度低于 0.4 的目标不直接采信，如果连续三帧都在同一位置出现且置信度稳定，才判定为有效车辆。这套逻辑配合简单的位置跟踪，可以把误报压得很低。

遮挡问题则主要靠标注规范解决。车辆排队进出时彼此遮挡，我现在会标注完全可见的车，部分遮挡超过三分之一的目标直接跳过，避免网络学到残缺特征后产生错误关联。训练数据里如果完全没有遮挡样本，网络在真实场景遇到遮挡时会手足无措，所以我还用随机擦除增强补了这一块，效果也不错。

5.3 推理延迟的优化思路

工地现场对实时性的要求没有想象中那么严苛，但是 24 小时不间断运行的系统，如果推理卡顿导致视频流积压，整个监控链路就会出问题。我在优化推理速度时做了几个调整：

最终部署方案是保留 YOLOv10s + ONNX + FP16，输入尺寸保持 640，只在夜间低峰时段启用抽帧检测。这样既保证了白天高频进出时的识别密度，也控制了整体计算负载。做实时视频检测时还要注意 UI 线程阻塞的问题，推理尽量放在独立线程里执行，主线程只负责刷新界面，不然视频流一长，界面会直接卡死。

最后再分享一点实际体会

这套系统从数据准备到最终稳定运行，我最大的感触是"模型训练只占整个项目三分之一的功夫"。数据标注规范、类别定义清晰、UI 交互顺畅这些环节，看起来不炫技，但真正决定了系统能不能落地。训练 YOLOv10 权重很快，但花在整理数据、反复看混淆矩阵补样本、调整置信度阈值的时间，远比跑那几个 epoch 长得多。如果让我重新做一次，我会先把监控场景里的常见车型拍全，把标注边界规则定死，再开始训练——这一步省下的时间，是后面所有环节都补不回来的。