徐卓菲最近在做一个道路缺陷检测的小项目，要求是检测路面坑槽、裂缝等缺陷，并且要有一个能直接操作的图形界面。技术栈选型时没怎么犹豫，检测部分用了 YOLOV8，界面部分用了 PyQt5，整套方案大概花了两周时间从数据准备到最终落地。如果你正好也在做类似的桌面端检测工具，或者准备拿这个方向做课程设计、毕业设计，这篇文章应该能帮你把整个流程串起来，少踩几个我踩过的坑。
这类项目最大的问题不是模型训练，而是“从模型到能用”的过程——有训练好的权重，但别人拿不到模型文件不会用，或者检测脚本跑在终端里不直观。加上 PyQt 界面之后，整个工具才真正变成一个可以交付的产品形态：加载图片、打开视频、实时摄像头检测都能在窗口里完成，检测结果、类别、置信度、画面叠加都一目了然。下面我从项目拆解、数据准备、训练调参、界面实现到问题排查，完整过一遍。
1. 整体设计与技术选型思路
1.1 为什么选 YOLOV8 而不是其他检测模型
道路缺陷检测本质上是一个目标检测任务，需要在图像中找到坑槽、裂缝、修补区域等缺陷的位置并分类。选检测模型时我对比过几个方向：两阶段的 Faster R-CNN 精度不错但推理速度慢，实时性差一些；SSD 在精度和速度之间比较均衡，但在小目标检测上表现一般；YOLO 系列本身是速度和精度的平衡点，YOLOV8 又引入了 anchor-free 检测头和 C2f 结构，小目标检测能力比前代强不少。
以裂缝这种细长目标为例，它在整张图中占据的像素比例往往很小，传统目标检测思路在小物体上容易漏检。YOLOV8 的多尺度检测头会分别在 80x80、40x40、20x20 的特征图上做预测，小尺寸特征图负责大目标，大尺寸特征图负责小目标，裂缝这种细长结构在高层特征图上能得到更好的响应。我用同一批道路缺陷数据分别跑过 YOLOV5 和 YOLOV8，在裂缝这一类别的 mAP50 上，V8 大概能高出 3 到 5 个百分点，漏检率也低一些。
另外，YOLOV8 的训练和部署比较省心。训练框架直接在 ultralytics 这个包里封装好了，配置文件和数据格式都是 YAML，几乎不用写底层代码。权重导出到 ONNX、TensorRT 也都有现成接口，后期想加速推理或者做跨平台部署成本都很低。对于一个人要负责数据、训练、界面全流程的情况，开发效率非常重要。
1.2 界面层为什么选 PyQt5
既然要做一个桌面工具，界面框架的选择范围其实就是 PyQt5、PySide2、Tkinter、wxPython 这几类。Tkinter 和 wxPython 在基础控件上有边界，做图像显示、视频流刷新这类高频视觉更新比较吃力，而且界面风格偏老。PyQt5 的 QLabel、QGraphicsView 可以直接显示 QImage/QPixmap，做视频帧的实时刷新非常顺滑，信号槽机制天生适合处理摄像头帧回调这类异步事件。
我实测下来，用 PyQt5 的 QTimer 定时器以 30 FPS 刷新 QLabel 的 QPixmap 时，CPU 占用和界面响应都很稳定，不会出现明显卡顿。PyQt5 的另一大优势是控件生态齐全，进度条、表格、下拉框、绘图组件都有，做检测结果统计面板、历史记录列表这些辅助功能很方便，界面观感也专业得多。
如果你要发版给别人用，PyQt5 打包成 exe 也有一套成熟流程，配合 PyInstaller 加一个 spec 文件就能把依赖带齐。无论从开发效率、界面表现力还是交付能力上，PyQt5 都是现阶段最合适的选项。
1.3 项目的模块划分
这个项目我按三个模块拆：
- 模型推理模块：负责加载 YOLOV8 权重、对输入帧执行推理、将检测结果转换成统一的 Python 数据结构（类别名、置信度、边框坐标）。
- 界面交互模块：负责搭建主窗口布局，处理用户操作事件（打开图片、开始检测、切换视频源），刷新画面显示和结果列表。
- 数据处理模块：负责把推理结果叠加到原始帧上（画框、写标签），以及把检测统计信息整理成界面可用的格式。
这样拆分的好处是模型和界面的耦合度低。后期换模型版本、换推理后端时，只需要改推理模块的接口实现，界面代码完全不用动。我一开始图省事把模型调用直接写在界面类里，后面每次调参数都得把界面重启一遍，调试效率特别低。后来重构成独立模块，体验好了很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据准备与模型训练细节
2.1 道路缺陷数据集怎么凑、怎么标
任何检测项目的上限都是由数据决定的。道路缺陷的公开数据集现在有一些，比如某高校公开的路面裂缝数据集、某跨平台数据集平台上的坑槽数据集，但实际用下来会遇到几个问题：类别体系不统一、图片分辨率差异大、场景偏向单一。我建议不要直接拿公开数据训练完就上，而是做一个“公开集 + 自采数据”的混合策略。
自采数据不用特别刻意到路面去拍，网上能找到一些路面维修现场、道路巡查的公开图片，筛选出包含裂缝、坑槽、修补痕迹的，统一整理到某个目录下。标注工具用 LabelImg 或者更轻量的 labelme 都行，输出格式选 YOLO 的 txt 格式，每行记录一个目标的类别序号和归一化的中心坐标、宽高。
标注时有一个特别值得说的点：裂缝这类长条目标不要用过于细长的框去包，稍微留一点边，检测框会稳定很多。比如一条斜向裂缝，如果你精确到像素级贴着裂缝标，训练出来的回归头很难稳定预测这么极端的长宽比，推理时边框抖动会很厉害。我一般会在裂缝边缘外扩 5 到 10 个像素再存标注框，效果明显改进。
数据集目录结构按 YOLOV8 的习惯组织：
text复制datasets/
road_defect/
images/
train/
val/
labels/
train/
val/
训练集和验证集按 8:2 划分，同一个来源的图片尽量放在同一侧，避免因为场景相似导致验证集虚高。标注类别我用了五类：横向裂缝、纵向裂缝、网状裂缝、坑槽、修补区域。类别数量不宜过多，一开始分太细会导致某些类别的样本量不足，模型学不好，后期合并反而是常态。
2.2 训练参数配置经验
YOLOV8 训练命令很简洁，直接通过 yolo 命令行工具就能启动，但参数选择有不少讲究。我实测的配置是这样的：
bash复制yolo detect train \
data=road_defect.yaml \
model=yolov8s.pt \
epochs=150 \
imgsz=640 \
batch=8 \
lr0=0.01 \
augment=True \
cache=True
首先模型规模上，道路缺陷检测这种场景不需要上 yolov8x，一方面显存占用大，训练慢，另一方面小模型推理延时低，桌面端体验更好。yolov8s 大概 11M 参数，在精度和速度之间比较均衡，我的实测里单帧推理在 GPU 上能达到 10ms 级别，CPU 上大概 200 到 400ms，桌面应用完全够用。
imgsz 是一个容易被忽略的参数。默认 640 的效果在大多数场景下够用，但道路缺陷里有不少小目标（远处的小裂缝、小坑槽），我试过调到 960 之后小目标召回有明显提升，代价是训练时间增加一倍左右。如果你的机器显存预算比较紧张，还是建议先用 640 把流程跑通，后期再调大输入尺寸做精度优化。
batch 的大小取决于显存。以 8G 显存为例，yolov8s + 640 输入下 batch 开 8 是可以接受的，如果显存不够可以先降 batch。batch 太小时 BN 的统计量不稳定，训练震荡会明显一些，所以我一般尽量保 batch 不低于 4。
学习率方面，lr0 用默认的 0.01 就好，但如果你用了较大的 batch，可以适当调高一些。我在 batch 16 的情况下会把 lr0 调到 0.02，优化器用默认的 SGD，收敛过程比较稳定。前期训练会看到一个快速下降然后平台期，这是正常的，不要因为 loss 曲线波动就频繁调整超参。
2.3 数据增强与训练监控
YOLOV8 默认的增强策略已经很丰富，包括随机透视变换、HSV 色彩增强、Mosaic 拼接等。道路缺陷场景里我额外注意了两点：
第一，色彩增强不要开太强。路面本身的颜色就是灰阶为主的，如果 hsv_h 设得过高，把路面变成奇怪的色偏，训练出来的模型在真实灰路面上泛化反而会变差。我用默认配置基本没动 HSV 参数。
第二，Mosaic 增强对裂缝这种细小目标不太友好。Mosaic 是把四张图拼成一张再训练，相当于把目标等比缩小，裂缝本来就细，缩完之后可能只剩几个像素宽，模型很难学到有效特征。如果发现训练时裂缝类别的 loss 一直降不下来，可以尝试把 mosaic 关闭或者降低概率。我用的是 ultralytics 里面的超参配置文件，把 mosaic 概率从默认调低到 0.4 左右，训练更稳。
训练过程的监控重点关注三张曲线：val/box_loss、val/cls_loss、metrics/mAP50。如果 mAP50 在训练中后期还在缓慢上升，说明欠拟合，可以加 epoch；如果 mAP50 已经平坦甚至下降，而训练 loss 还在降，基本就是过拟合了，此时需要加数据增强或者提前终止。我用 early stopping 设为 30 个 epoch 无改善就自动停，省了很多等待时间。
训练完成后，ultralytics 会自动在 runs/detect/trainX/ 目录下生成 weights/best.pt 和 weights/last.pt，best.pt 就是最终交付的模型文件，之后 PyQt 界面加载的就是它。
3. 核心代码架构与关键实现
3.1 推理模块的封装
推理模块我封装成一个 Detector 类，对外只暴露两个方法：load_model 和 detect。detect 接收一个 BGR 格式的 NumPy 数组（OpenCV 读出来的格式），返回一个包含检测结果的列表。下面是核心实现，去掉了无关细节：
python复制import cv2
from ultralytics import YOLO
class DefectDetector:
def __init__(self, weights_path: str, conf_thres: float = 0.35):
self.model = YOLO(weights_path)
self.conf_thres = conf_thres
self.class_names = self.model.names
def detect(self, frame_bgr):
results = self.model.predict(
source=frame_bgr,
conf=self.conf_thres,
iou=0.45,
imgsz=640,
verbose=False
)
if not results:
return []
boxes = results[0].boxes
detections = []
for box in boxes:
x1, y1, x2, y2 = box.xyxy[0].cpu().numpy()
confidence = float(box.conf[0])
cls_id = int(box.cls[0])
detections.append({
"bbox": [int(x1), int(y1), int(x2), int(y2)],
"confidence": round(confidence, 4),
"class_id": cls_id,
"class_name": self.class_names[cls_id]
})
return detections
这里有几个细节想多解释：在 detect 方法里保持了 conf_thres 作为参数，便于界面上的置信度滑块实时调整，可以在不重新加载模型的情况下调节检测灵敏度。verbose=False 很关键，否则每次推理都会往控制台刷信息，界面跑起来时会非常烦人。
关于 device 的选择，ultralytics 会自动检测 GPU，但如果你在只有 CPU 的机器上运行，可以显式指定 device="cpu" 来避免一些环境兼容问题。如果想把推理速度再压一压，可以把模型导出为 ONNX 格式，再用 onnxruntime 做推理后端，实测在 CPU 上大约可以提速一倍。这个后面在部署优化里细说。
3.2 界面布局与刷新逻辑
PyQt 界面我用了主窗口 + 中央部件的结构，布局上分成三个区域：左侧是操作区和图片/视频源选择区，中间是显示检测结果画面的主预览区，右侧是检测结果表格和统计信息区。下面对应界面逻辑做一个概览。
界面刷新的核心是 QTimer。对视频流和摄像头场景，我用一个 30ms 的定时器周期性触发帧读取和检测：
python复制self.timer = QTimer(self)
self.timer.timeout.connect(self.process_next_frame)
self.timer.start(30)
每次定时器触发时，从视频对象读取一帧，经过检测模块处理，把检测结果绘制到帧上，再转换成 QImage 显示到 QLabel。这样做的优点是逻辑简单，帧率可控。不需要处理异步线程切换问题，实测下来 30ms 一帧对 CPU 而言压力也不大。
摄像头场景有一点要注意：不要在 UI 线程里执行 cv2.VideoCapture.read()，因为读摄像头在某些驱动下会阻塞，界面会跟着卡死。我的做法是把摄像头读取放到一个后台 QThread 中，通过信号把帧传回主线程，主线程只负责检测和显示。这个方案比纯粹用 QTimer 更稳，代码量也没多多少。
python复制class CameraThread(QThread):
frame_ready = pyqtSignal(object)
def __init__(self, camera_index=0):
super().__init__()
self.cap = cv2.VideoCapture(camera_index)
self.running = True
def run(self):
while self.running and self.cap.isOpened():
ret, frame = self.cap.read()
if ret:
self.frame_ready.emit(frame)
self.cap.release()
def stop(self):
self.running = False
self.wait()
主界面里连接这个信号：
python复制self.camera_thread = CameraThread()
self.camera_thread.frame_ready.connect(self.process_frame)
这样摄像头帧读取、检测、显示三个环节各归其位，互不阻塞，界面即使在做密集推理时也不会失去响应。
3.3 检测结果绘制与统计
检测结果的可视化直接用 OpenCV 的 rectangle 和 putText 就可以实现。关键点是处理中文标签的问题：OpenCV 的 putText 不能直接显示中文，如果你只想显示英文类别名（如 pothole、crack），那没问题，但界面里一般需要中文。我的做法是用 PIL 的图像绘制功能做中文叠加，流程是：把 BGR 帧转成 RGB 的 PIL Image，用 ImageDraw 绘制中文文本和边框，再转回 BGR 给 OpenCV 使用。实测这个转换过程带来的性能损耗可以忽略不计，比初始化 OpenCV 自带的 FreeType 模块方便太多。
框的颜色按类别区分，坑槽用橙色、裂缝用蓝色、修补区域用绿色，这样用户一眼能分辨缺陷类型。每个框的左上角写上类别名和置信度百分比，置信度低于某个阈值的检测结果可以做成半透明显示，避免大量低分框干扰视线。
统计面板我用一个 QTableWidget 来展示当前帧的检测明细，同时在下方用 QLabel 汇总本帧的缺陷总数和各类别数量。这样一个画面里发生了什么、检测到了多少缺陷，全部可视化，对现场演示和结果记录都很有用。
4. 界面交互与功能模块实现
4.1 图片检测与视频流检测的切换
用户最常用的两个场景是单张图片检测和视频流检测，这两个入口的交互逻辑差别不小，但复用同一套检测代码。图片检测的实际操作路径是：点击“打开图片”按钮，弹出一个文件选择对话框，选定图片后把图片路径存入界面变量并立刻触发一次检测，检测结果显示在预览区，表格同步更新。视频流检测则是通过打开视频文件或者打开摄像头，进入连续检测模式。这里的核心设计是用一个 mode 变量区分当前状态：
python复制self.mode = "image" # 或 "video" / "camera"
打开图片和打开视频按钮分别设置 mode，并启动相应的处理链。切换模式时需要释放上一个模式占用的资源（如关闭视频文件、停止摄像头线程），不然下一次切换可能因为句柄未释放而出错。我踩过的坑是连续切换视频和图片时摄像头没有正确释放，导致程序异常退出，后面用了统一的 reset_process 方法，每次都先停止线程、释放视频对象，再按新状态初始化，问题解决了。
4.2 参数调节与结果导出
界面上我加了几个实用控件，最核心的是置信度阈值滑块。这个滑块从 10% 到 90% 可调，默认 35%，拖动后立即重新触发当前帧检测，实时看效果。道路缺陷检测项目的现场情况变化大，有时需要适当降低阈值查漏检、有时需要提高阈值降误报，滑块的实时调整能大大提升可用性。
导出功能我也做了：检测结果的明细可以一键导出到 CSV 文件，每一行保存图片名、缺陷类别、置信度、边框坐标；预览画面可以保存为标注过的图片。这两个功能对工程复核和报告文档编写很有价值。导出用 Python 的 csv 模块写文本文件就行，不引入额外依赖。
界面上的“保存结果”按钮我绑定了一个槽函数：获取当前检测结果列表，用 csv.writer 写入文件，文件名自动附加时间戳避免覆盖。整个过程不到十行代码，但对用户来说能感知到这是一个完成度很高的工具。
4.3 界面布局中容易被忽略的细节
PyQt 界面做久了会发现，功能都对但不好用的情况比比皆是。我的经验里有几个细节值得摊开说。
第一个是预览区的图像缩放适配。检测框是在 640x640 或原始分辨率上画的，但 QLabel 显示区域有限，直接把大图塞进去只会显示一部分。我采用了 QLabel 加 setScaledContents(True) 的方式做等比缩放，但要注意：显示缩放后检测框坐标也要同步缩放，否则框会画在错误位置。我的做法是维护一个比例因子 scale = displayed_width / original_width，所有坐标画框前先乘上这个因子。
第二个是视频结束时的事件处理。cv2.VideoCapture 读到最后会一直返回 False，此时不处理的话界面会显示最后一帧不动，表现上看就是卡住了。我在读取失败时弹出状态栏提示“视频播放完成”，并把模式切回图片，让界面保持可用状态。
第三个是摄像头的分辨率设置。很多内置摄像头默认分辨率只有 640x480，做检测完全够用，但如果外接高清摄像头，默认分辨率可能非常大，直接读帧会导致检测耗时变长、界面变卡。我在打开摄像头前先尝试设置期望宽度 1280、高度 720，失败则退回默认分辨率，实测能避免不少莫名其妙的性能问题。
5. 常见问题与排查技巧实录
5.1 模型加载慢与显存占用过高
如果你加载模型后程序启动非常慢，或 GPU 显存占用异常高，多数情况是模型默认把推理放到了 GPU 上且没有释放缓存。我遇到过一次：每次检测 GPU 显存都会涨一点，多跑几张图就 OOM 了。排查一圈发现是 ultralytics 在每次 predict 时默认重新分配了一次 CUDA 上下文，其实可以在模型加载后显式设置 torch.cuda.empty_cache() 来缓解，更稳的作法是在代码开头设置环境变量限制显存预分配比例：
bash复制export CUDA_VISIBLE_DEVICES=0
代码层面也可以做类似设置：
python复制import torch
torch.cuda.set_per_process_memory_fraction(0.7, device=0)
如果目标机器没有显卡，建议直接用 CPU 推理。YOLOV8s 在 CPU 上跑一张 640 图大约 300ms 左右，对单张检测场景来说完全可接受，只是视频流实时处理会有些吃力。
5.2 界面卡死或响应延迟
界面卡死的绝大多数原因都是把耗时操作直接放在了 UI 线程里。视频检测时，每次处理包括读取帧、执行模型推理、画框、刷新控件，其中任何一步慢都会拖累整个界面。解决思路就是把视频读取和推理放到工作线程里，主线程只负责显示。我实测用 QThread 处理后，即使 CPU 推理耗时达到 400ms，界面依然能拖拽、能点击按钮，只是画面帧率会相应下降，不会再出现“无响应”的问题。
还有一个容易被忽略的细节：如果检测结果显示在 QTableWidget 里，每秒刷新几十次表格会导致界面不停地重绘，CPU 占用极高。我的做法是在视频流模式下不实时刷新表格，只刷新预览图和统计标签，等视频暂停或结束时再一次性刷新表格。这样性能体验会好很多。
5.3 图片路径中文导致的加载异常
OpenCV 在某些平台上读取中文路径的文件时会报错，这是老问题了。我在 PyQt 的文件对话框里选了中文路径的图片后，加载失败，程序直接弹异常。解决办法是先用 sys 文件系统编码处理，或者直接用 Python 的 open 读取文件字节流，再用 cv2.imdecode 解码：
python复制import cv2
import numpy as np
def load_image_from_path(path):
with open(path, "rb") as f:
data = f.read()
img = cv2.imdecode(np.frombuffer(data, np.uint8), cv2.IMREAD_COLOR)
return img
这段代码对中文路径、空格路径都有很好的兼容性，强烈建议使用，虽然只有几行，但是填了一个大坑。
5.4 推理精度没训练时高，复现不出来
训练时 mAP 看着挺高，一到实际图片上就漏检，这种情况排查思路有三条：第一，检查推理时的输入尺寸是否和训练一致。训练用 960，推理用 640，小目标肯定受影响。第二，检查置信度阈值。训练时 mAP 计算的阈值范围很宽，实际使用时 conf=0.35 在部分应用场景下偏高，可以试着往下调再观察。第三，检查图像增强对光照的压制程度。如果你训练时用了很强的 HSV 增强，而真实场景图像光照比较正常，推理结果和训练时的分布会有偏移。一个快速验证方法是用训练集里表现好的图片去推理，如果训练集图都检测正常，说明是数据分布差异问题；如果训练集图也有问题，说明推理配置或者模型权重选错了。
5.5 部署时依赖环境不一致
在自己电脑上运行好好的，换一台电脑运行就各种报错，这类问题在 PyQt + YOLO 的项目里很常见。总结下来有几种排查方向：一是 Python 版本不一致，ultralytics 要求 Python 3.8 以上，但不同版本依赖的包版本有差异；二是缺少系统动态库，PyQt5 在 Windows 上依赖一些 VC++ 运行库，Linux 上依赖 libgl 相关库；三是 OpenCV 的 DLL 冲突，常常是因为机器上装了多个 OpenCV 版本，或者 OpenCV 与 Qt 的插件加载顺序有问题。
我最后的解决办法是统一用一套虚拟环境，做好 requirements.txt，打包发布时用干净的 Python 环境去跑 PyInstaller，并在目标机器上用同样的 Python 小版本测试一遍。打包时注意 PyInstaller 需要把 ultralytics 的配置文件和默认权重路径加进 data 列表，否则 exe 会找不到默认参数。
5.6 摄像头无法打开或画面黑屏
摄像头打开失败，先检查是不是被其他程序占用了，Windows 下相机设置里的隐私权限开关也要确认。在代码层面，打开摄像头前可以用 cv2.CAP_DSHOW 参数避免某些 Windows 上的 DirectShow 兼容问题：
python复制cap = cv2.VideoCapture(camera_index, cv2.CAP_DSHOW)
如果画面是黑屏但程序不报错，可能是摄像头分辨率设置不对，或者驱动返回的帧形制不匹配。试着把期望分辨率调低，例如 640x480，排除分辨率过高导致驱动异常的情况。还有一个容易被忽略的点：笔记本电脑的摄像头在某些场景下需要经过一段初始化时间，程序刚启动就立刻打开摄像头容易拿到空帧，可以在线程启动后加一个短暂延时再开始读帧。
6. 部署优化与后续扩展方向
6.1 ONNX 导出与 CPU 推理加速
桌面端工具很多时候跑在普通办公电脑上，没有独显，CPU 推理速度就是核心瓶颈。YOLOV8 官方支持一键导出 ONNX：
bash复制yolo export model=best.pt format=onnx imgsz=640 opset=12
导出之后用 onnxruntime 加载模型执行推理，比原始 PyTorch 在 CPU 上快不少。结合我前面的 Detector 接口设计，这里只需要替换底层调用实现，界面层完全不需要改动。onnxruntime 的 GPU 版本也能在支持 DirectML 的 Windows 设备上跑，兼容性比 CUDA 好。
如果你要把 ONNX 再加快一层，可以考虑用 onnxruntime 的 graph optimization 级别调为 enable_all，在模型加载时自动做算子融合和常数折叠，对分支结构多的网络有时能带来 20% 左右的提升。
6.2 批量检测与数据管理
单张、单视频检测只是工具的第一阶段。我目前正在把项目扩展成一个小型巡检数据管理工具：支持选择整个文件夹批量检测，检测结果自动存入 SQLite 数据库，每条记录包括图片文件名、检出缺陷类别、数量、置信度、检测时间。这样每一次巡检拍回来的照片可以直接导入软件跑一遍，输出一份带统计结果的表格，做道路养护评估和前后对比就有依据了。
批处理界面不用重新设计，在现有主界面加一个“批量检测”按钮，进度条绑定到 QProgressDialog 上，内部用一个工作线程循环处理文件夹内所有图片。每张图的结果按约定结构写入数据库，进度信息通过信号实时反馈到界面。
6.3 模型迭代与继续训练
这个项目的价值不是一次训练完就结束。采集到新的道路缺陷图片后，可以在旧模型基础上继续训练，而不是从预训练权重重新开始。做法是修改训练命令，把 model 参数换成已有的 best.pt：
bash复制yolo detect train data=road_defect.yaml model=best.pt epochs=50
这样模型会在现有知识基础上只在新数据上微调，训练时间大幅缩短，同时能够适应新场景。我实测在新采集的 200 张夜间路面图上继续训练 50 轮后，夜间裂缝的召回率比重新训练高了大概 8 个百分点，原因是模型已经掌握了白天的缺陷特征，微调只要修正光照差异就够了。这个“持续迭代”的机制是实际项目里比一次性精度优化更有效的手段。
7. 一些补充的实操建议
最后分享几个从项目里沉淀下来的小建议，不是教科书里能直接找到的东西。
数据集标注阶段一定要多人交叉复核。一个人标注的框和类别很容易有偏差，比如有人把纵向裂缝标成了横向裂缝，或者漏标了小坑槽。拉上一个同学或者同事，花半天时间把训练集的标注过一遍，比后期返工省时间得多。我第二次做数据集时让同组的人随机抽了 20% 的图复核，结果挑出了十几处标注问题，重新修正后 mAP 涨了一个多点。
界面开发时先导航到性能测试，不要做一步看一步。我第一次做界面的时候，每加一个控件就启动程序点一遍，看着没啥问题，等所有模块都接好之后才发现整个主界面卡成了幻灯片。如果一开始就明确“视频读帧在后台线程、推理在独立线程、界面只做显示”，后面就不会返工。
还有一个小技巧是用环境变量控制 Debug 模式。我在程序启动时读取一个环境变量，如果设置了 DEBUG=1，就把推理耗时、帧率、内存占用打印到控制台。联调时开着这个开关随时能看性能瓶颈，发布时关掉，用户看到的是干净的界面。这样不用反复改代码加打印，效率高很多。
对于做毕设或者作品集的同学，我建议在基础功能完成之后，再挑一个点做出亮点。有的人做夜间检测优化，把推理前做了自动对比度增强，夜间裂缝的检出效果肉眼可见地提升；有的人做缺陷尺寸估算，利用简单的几何换算，结合车辆拍照离地高度估算缺陷的实际物理尺寸，这在巡检报告里非常加分。这类差异化亮点在答辩和项目展示时特别抢眼，价值远大于把界面花哨程度堆满。
整个项目从前到后，最有成就感的时刻其实不是模型训练出来的那一刻，而是把一个检测脚本变成一个别人能直接操作、能出报告、能拿到现场去用的桌面工具的时候。这个过程里的技术点不复杂，但组合起来能产生很实在的价值，希望这篇内容能帮你把这条路走得更顺。