★ FEATURED ARTICLE 做道路缺陷检测这个方向你最先要接受的不是模型精度不够而是路况本身太“野”。裂缝可能细到几个像素坑槽在不同光照下颜色差异极大修补区域更是形态各异。我最近把一个基于YOLOV8的道路缺陷检测项目从模型训练一直做到PyQt界面落地整个过程踩了不少坑也攒下一套可以直接参考的完整路径今天拆开讲讲。先说这个项目能干什么给一段道路图片、视频或者直接接摄像头模型自动把裂缝、坑槽、修补区域等缺陷框出来同时界面实时显示检测结果和统计信息。它面向的受众也很明确——正在做课程设计、毕业设计或者在做小型巡检系统预研的人。如果你只是想快速跑通一个Demo网上教程很多但如果想把“模型训练”和“可视化界面”两条线串起来做成一个能给别人演示、能实际操作用的完整工具下面这些内容应该能帮你省掉不少弯路。这篇文章不打算写成一章一章的说明书而是按一个真实项目的推进顺序来讲先搞清楚需求再选型然后是数据准备和训练接着把模型变成可部署的推理管道再落到PyQt界面最后把那些坑点和优化手段全部摆出来。1. 从“人工看路”到“模型查路”需求与选型逻辑1.1 道路缺陷检测到底要检测什么很多第一次接触这个方向的人会把道路缺陷理解成“坏了的路面”但这个概念在实际工程里是分得很细的。常见的有路面裂缝、坑槽、龟裂、网裂、修补区域、磨损、车辙等每一类缺陷的外观、尺寸、拍摄角度都不太一样。裂缝往往细长、颜色偏深有些宽度只有几个像素坑槽则是局部凹陷和周围路面有明显色差和纹理差异修补区域通常是一个颜色更深、边界不规则的块状区域。如果按传统人工巡检的方式巡查人员要么靠肉眼沿路看要么拿着相机拍完回来一张张翻。前者效率低后者对人员的经验要求高。很多实际项目里真正的问题不是“能不能看到缺陷”而是“数据量太大人看不过来”。这也是为什么基于深度学习的目标检测方案会流行起来——它能把“找缺陷”这件事前置到采集端附近先由模型自动筛一遍再由人工复核模型找出来的可疑区域。但要注意道路缺陷检测不等于普通的目标检测。普通检测任务里的目标通常有明显轮廓、完整结构和稳定的颜色而裂缝这类目标在整张图像中的面积占比非常小容易受到路面纹理、阴影、水渍、车道线干扰。所以在做需求分析时不能只定一个“检测破损”的模糊目标最好把类别和边界定义清楚。我一般会先做一张类目表列出类别名、典型形态、最小目标像素范围以及可接受的最低置信度。别嫌这一步麻烦它直接影响后面数据标注和质量评估。1.2 为什么选YOLOv8而不是两阶段检测器道路缺陷检测的落地场景决定了模型对“速度”和“易用性”的要求非常高。不管是装在巡检车上还是放在后端的分析工作站上面对的都是一段段视频或成千上万的图片。如果每张图要跑几百毫秒甚至一秒以上整体处理效率会很难看。YOLOv8这类单阶段检测器最大的优势就是速度和精度的平衡尤其是官方给了n、s、m、l、x一系列不同规格的模型原型阶段选n或s性能和资源占用都很友好。和两阶段检测器相比YOLOv8把目标分类和边界框回归放在同一个阶段完成结构上少了区域提议这一大块因此在GPU和CPU上都能跑出比较可用的帧率。对道路缺陷这种“目标小、类别不多但数据量极大”的场景单阶段模型完全扛得住。更实际的理由是它的工程化体验。YOLOv8训练时只需要一份YAML数据配置和一行命令导出ONNX、TensorRT、OpenVINO等格式也都是内置能力这对后面接到PyQt界面非常关键。我见过不少用老版本检测框架做的项目模型效果不错但到部署阶段才发现导出格式各种兼容性问题最后还得反回去改代码。YOLOv8在这一点上省掉了很多无谓的折腾。不过选型也不是没有代价。YOLOv8默认的设计偏向通用目标检测对裂缝这种极端长宽比的小目标如果训练时不做输入尺寸、数据增强方面的调整很容易漏检。这个问题我会在后面专门提到。简单说选它没错但不是拿过来就用必须针对道路缺陷的特点做适配。1.3 PyQt界面在这个项目里承担的角色很多做算法的人会问模型训练好了直接写个脚本调用不就行了吗为什么非要套一个PyQt界面我的答案是脚本是给自己用的界面是给别人用的。在实际项目里使用检测系统的往往是巡查人员或复核人员他们不会去敲命令行也不关心模型结构。他们需要的是“打开软件—选择一段视频—看到结果框和统计数—导出报告”这一套流程。PyQt在这个项目里承担的是一个典型的桌面端交互层。它本身不负责算法但负责把模型输出的信息变成人能理解和操作的东西。选择PyQt而不是Web界面的原因也很简单本地运行不需要搭服务器摄像头、视频文件、图片文件的读取直接用OpenCV和PyQt配合离硬件更近同时PyQt的QThread和信号槽机制非常适合处理实时视频流这种“一边采集、一边推理、一边刷新界面”的并发任务。另外PyQt的控件体系很完整比如QFileDialog选文件、QLabel显示图像、QTableWidget展示检测结果、QProgressBar显示处理进度、QChart做统计图基本不需要额外引入重量级前端框架。对一个人的开发量来说这是能最快把模型包装成可演示产品的路线。2. 训练之前那些绕不开的准备工作2.1 环境版本组合少一点“兼容性惊喜”这部分看起来基础但我在实际部署时踩过太多次环境坑所以单独拿出来说。先说Python版本建议直接用3.10或3.11太高或太低都可能遇到某个依赖库没有对应轮子的问题。PyTorch的版本要和CUDA版本对应如果是NVIDIA显卡先查清楚驱动支持的CUDA版本再装对应PyTorch否则训练时会出现“GPU不可用”的诡异问题。依赖方面核心是ultralytics库、opencv-python、PyQt5或PyQt6、numpy。这里有个细节PyQt5和PyQt6在部分API上有差异比如信号连接方式、枚举类型的写法建议项目一开始就定好用哪个不要中途切换。我这次用的是PyQt5和OpenCV 4.x的组合稳定性和兼容性都比较好。另外强烈建议全程用虚拟环境不要往系统Python里直接装。原因很简单道路缺陷检测项目往往还要装onnxruntime、pandas、matplotlib这些辅助库不同项目之间的依赖很容易互相冲突。一个干净的虚拟环境能让你把精力放在模型和界面上而不是反复处理“装了这个库之后另一个库用不了了”的问题。安装完依赖后最好先跑一个最小的YOLOv8推理脚本确认GPU能正确识别模型能正常加载。这一步只要跑通后面所有工作都是在验证过的地基上进行的。我见过不少项目一上来就训练训练到一半发现CUDA没生效白白浪费几个小时。2.2 路面缺陷数据集的采集、标注与增强数据是道路缺陷检测项目里最花时间的一环。公开的路面缺陷数据集当然可以拿来预训练或作为补充但真实项目里建议还是要有一部分自己的现场数据。原因很简单公开数据集拍摄的环境、相机高度、路面类型和你最终部署的场景很可能不一样模型泛化性会打折扣。采集数据时不要只挑“拍得清楚”的图片最好覆盖不同光照、不同天气、不同路面材质、不同拍摄角度。裂缝在清晨和正午的光线下表现差异非常大水渍和阴影又特别容易造成误检。我一般会分场景建子目录比如晴天、阴天、雨后、逆光、夜晚如果允许的话然后在每个场景下采集足够多的样本。标注这一步推荐用LabelImg或X-AnyLabeling这类工具输出成YOLO格式的txt文件。YOLO格式每一行是“类别id 中心点x 中心点y 框宽 框高”坐标值都归一化到0到1之间。标注时要注意裂缝这类细长目标用矩形框去框会带入很多背景信息这是不可避免的但框一定要紧贴裂缝的实际范围不要为了省事拉一个大框。拉框太松模型学到的特征会很模糊。对于类别不平衡问题比如裂缝样本两千张、坑槽只有两百张我的经验是先用图像翻转、旋转、亮度变化、噪声叠加做离线增强把少样本类别扩到和多数类接近的量级然后再训练。YOLOv8本身也有内置的Mosaic和MixUp增强但这类增强对道路缺陷是否一定有利要实测。裂缝本身是细微纹理过度扭曲可能会让模型学不到有效特征。2.3 训练超参数怎么给以裂缝和坑槽为例这里我给一份我实际用过的训练配置参考不是绝对标准但能帮你避开一些明显不合理的选择。模型我用的是yolov8s输入尺寸imgsz设为640这样在精度和速度之间比较均衡。实话实说如果你主要检测坑槽这种中等大小的目标640完全够但如果裂缝漏检率太高下一步不是盲目堆训练轮数而是把imgsz提高到1280或者采用滑窗裁图的方式把大图切成小块再推理。以下是超参数参考表# data.yaml 示例 train: dataset/train/images val: dataset/val/images nc: 4 names: [crack, pothole, repair, rut]训练命令一般是这样yolo detect train datadata.yaml modelyolov8s.pt epochs150 imgsz640 batch16 device0batch大小要参考显存来定8到16通常是s模型的甜点区。epochs我在小数据集上一般设150但开了早停如果连续30轮验证集mAP没有提升就自动停止。学习率让YOLOv8默认的自动策略去管就可以先用默认值跑起来除非loss明显不收敛再手动调整。这里还有一个很多人忽略的点预训练权重很重要。用yolov8s.pt这种在大型通用数据集上训练过的权重作为起点比自己从零开始训练节省大量时间而且收敛效果通常更好。道路缺陷虽然不属于通用目标类别但模型学到的底层特征比如边缘、纹理、形状表征是可以迁移过来的。2.4 怎么判断模型真正能用了指标与实践训练完成后不要只看loss降没降要看验证集上的mAP50和mAP50-95。mAP50是IoU阈值0.5下的平均精度适合快速判断模型有没有学到类别mAP50-95则是更严格的综合评价对目标框的位置精度和分类置信度都有要求。道路缺陷场景里裂缝这种小目标的mAP50-95一般不会太高但如果mAP50能到0.7以上已经具备实用价值。判断模型能不能实际部署还要看误检集中在哪一类。我最常遇到的问题就是把明亮的水渍检测成坑槽或者把路面接缝当成裂缝。这种时候不要急着加数据硬撑先去PR曲线里看对应类别的准确率召回率转折点然后决定是调置信度阈值还是针对性收集“容易混淆”的负样本。负样本是什么就是那些不是缺陷但看起来很像缺陷的路面区域。把几十张这类图片放进训练集里并标注成背景或者单独类别往往比盲目增加正样本更有效。为了验证泛化性我还会拿一小段没有参与训练的视频做模型上线前的“路测”。视频里的缺陷是连续的模型可能在某一帧漏检、在下一帧又检出来。这种时间上的不稳定从单张图片指标上看不出来必须在视频推理阶段处理。3. 从训练权重到可部署的推理管道3.1 推理流程的五个环节模型训练完得到的best.pt还不能直接往界面里塞。更稳妥的做法是把推理逻辑封装成一个独立的检测器类让界面代码只负责调用而不用关心模型内部怎么处理。完整的推理流程大体分成五个环节图像读取、预处理、模型推理、后处理、结果绘制。预处理很关键。YOLOv8在训练时会对输入图像做letterbox变换也就是把图像等比缩放到指定尺寸剩余部分用灰色填充。推理时也要做同样操作否则检测框的位置会偏。如果直接用OpenCV的resize把一张宽图压扁到640×640模型看到的物体形变和训练时差别很大检测效果会明显下降。后处理是把模型输出的原始预测转换成可用的边界框。YOLOv8会输出大量候选框但很多是重复的同一个目标所以要做非极大值抑制按照置信度排序去掉IoU过高的冗余框。这一步如果自己写要注意IoU阈值的设置调小了会漏掉重叠目标调大了会出现同一个缺陷被框两次的情况。我习惯把所有逻辑放在一个Detector类里初始化时加载模型和配置文件对外只暴露一个predict(frame)方法返回检测框列表、类别和置信度。这样后面在PyQt里无论是图片检测、视频检测还是摄像头检测调用方式完全一致。实测下来这样的封装既减少了重复代码也方便以后更换模型来源。3.2 导出ONNXCPU部署的性价比之选很多道路巡检项目的部署机器是没有独立显卡的CPU推理速度直接决定工具可不可用。YOLOv8自带的PyTorch推理在CPU上速度不够理想尤其是s模型跑大分辨率图片时一帧可能要几百毫秒。这时候导出ONNX格式再用onnxruntime加载是性价比最高的优化方式之一。导出很简单from ultralytics import YOLO model YOLO(best.pt) model.export(formatonnx, halfTrue, dynamicFalse, opset12)导出的best.onnx用下面的方式推理import onnxruntime as ort sess ort.InferenceSession(best.onnx, providers[CPUExecutionProvider])为什么ONNX比PyTorch快因为onnxruntime针对CPU做了算子融合、内存复用和线程调度优化去掉了PyTorch运行时里很多动态图开销。我在自己的测试机器上对比过同一张1280×1280的测试图PyTorch CPU推理大约1.2秒ONNX推理降到0.7秒左右提升还是很明显的。如果还想更快可以做INT8量化但量化会损失一定精度尤其是裂缝这种小目标量化后漏检可能变多。我一般会先在FP16或FP32的ONNX上验证一遍确认界面流程稳定后再考虑要不要量化。3.3 输出解析与绘制别让可视化拖后腿使用YOLOv8官方库做推理时模型输出可以直接拿到处理好的检测框省心很多。但如果导出ONNX自己生成推理引擎就要自己解析输出数组。不同版本、不同导出方式下输出格式会有差异这个没法完全照抄网上代码建议先打印出输出的shape再写解析逻辑。拿到检测框之后绘制也是一门学问。OpenCV的cv2.rectangle能画矩形框但中文标签会乱码。YOLOv8官方模型默认的标签是英文比如crack、pothole如果界面想显示中文最好自己维护一个类别ID到中文名称的映射表再用PIL在图像上画出中文文本然后转回OpenCV的BGR格式。这一步虽然不复杂但很多人在做PyQt界面时才突然发现中文标注是乱的临时去查资料很打断节奏。绘制时还有一个小经验检测框的颜色不要每个类别随机取最好是固定色值并且在图例里写明。裂缝用红色坑槽用橙色修补用蓝色这样巡检人员能快速区分。另外置信度阈值不要写死在算法里要留成界面上的一个可调参数。原因是不同场景下对误检的忍受程度不一样有人更看重召回有人更看重准确率配置化总比硬编码好。4. PyQt界面的完整实现思路4.1 界面规划和交互需求开始写代码之前先把界面需求列清楚。我这个项目的界面结构是这样的左侧是一个大画布用来显示原始图像、视频帧和检测结果右侧是一个控制面板从上到下依次是数据源选择按钮、类别和阈值参数区、检测结果表格、统计信息底部是进度条和执行状态栏。这个布局的好处是信息流很自然操作路径短使用者不需要额外学习。画布用QLabel配合QPixmap显示图像不做复杂渲染。参数区里放一个置信度阈值SpinBox或Slider方便实时调节。结果表格QTableWidget用来列出每次检测的所有目标包括类别、置信度和位置坐标锚定框多的时候比直接看图更清晰。统计信息区显示当前帧检测到的各类缺陷数量以及累计处理帧数和平均推理耗时。界面设计上有一条原则算法相关的操作不要暴露太多比如模型路径、图像缩放参数这些在开发调试阶段放配置文件里不要都堆到界面上。给最终用户看的东西越简单越好。PyQt开发的效率很高我大概用两天左右就完成了布局和基础交互真正花时间的是后面实时视频流和多线程这一块。4.2 图片检测文件选择、推理与结果展示图片检测是最简单也是最核心的流程。点击“打开图片”按钮用QFileDialog.getOpenFileName让用户选择jpg、png、bmp等格式文件。读入后先用cv2.imdecode读取注意路径不要直接传给cv2.imread因为Windows下中文路径可能导致读取失败imdecode从文件字节流解码更稳妥。检测函数拿到图像后先判断图像尺寸。如果宽度超过2000像素直接喂给模型可能显存吃紧或者推理很慢。我的做法是提供两种策略一是等比缩小到合理范围再检测缺点是漏检小目标二是滑窗裁图把大图切成多个900×900的块分别检测再把结果合并回原图坐标。后者稍微麻烦一点但能保住裂缝这种小目标实际效果明显更好。结果显示时原始图像和检测结果要分开展示方便用户对比。我通常会让画布显示检测后图像另外在结果表格中保存原始信息。别忘了在界面上显示本次检测的耗时这个数字看起来不起眼但对用户体验影响很大。每次检测耗时超过两秒使用者就会觉得卡顿超过五秒基本会被判定为不可用。4.3 视频和摄像头实时检测多线程是关键视频和摄像头检测是整个项目里最容易翻车的部分。最简单的写法可能是在一个循环里读取视频帧、执行推理、更新界面然后发现界面窗口拖不动、按钮点了没反应。原因就是主线程被推理任务占住了无法处理界面事件。正确的思路是把摄像头读取和模型推理放到后台线程把UI更新留在主线程。我一般用QThread自定义一个InferenceThread里面跑一个while循环不断从VideoCapture读取帧调用Detector推理然后把处理后的图像通过pyqtSignal发送给主线程的槽函数。核心结构大概长这样class InferenceThread(QThread): frame_ready pyqtSignal(object) def __init__(self, detector, source): super().__init__() self.detector detector self.source source self.running True def run(self): cap cv2.VideoCapture(self.source) while self.running and cap.isOpened(): ok, frame cap.read() if not ok: break result_frame, detections self.detector.detect(frame) self.frame_ready.emit(result_frame) cap.release()信号槽机制是Qt线程模型的核心工作线程只负责发信号主线程在事件循环里接收信号并更新QLabel。这条线一定要理清楚否则很容易写出“线程崩溃”或者“界面假死”的代码。视频检测还有一个性能优化点不是每一帧都要推理。道路缺陷变化是连续的可以每两帧或每三帧推理一次中间帧直接复用上一帧的检测结果或者干脆只在关键帧上绘制结果。这样能把实时帧率提升不少。实测中720P摄像头配yolov8n的ONNX模型跳帧检测后能够稳定跑到每秒20帧以上基本满足实时预览需求。4.4 统计与导出让检测结果能交差检测结果如果只是停留在界面上看过就完了那离一个可用的工具还差一步。实际巡检项目里最后要输出的是能存档、能汇报的结果。所以我在PyQt界面里加了一个“导出报告”功能把当前检测到的所有目标整理成CSV或JSON文件。CSV可以直接用Excel打开适合人工复核JSON适合程序间交换方便后续接入其他管理系统。导出内容至少要包含图片编号或视频时间戳、类别ID、类别名称、置信度、边界框坐标。如果是从视频检测最好再加一列文件名中对应的帧序号方便回溯到具体画面。统计信息也要一并写入比如整段视频里各类缺陷的出现次数、平均置信度等。统计模块我直接用Python的collections.Counter统计类别频率再加一个总处理帧数和平均推理耗时的字段放到界面的状态栏。导出按钮触发时写文件这类操作放在后台线程避免主界面卡顿。文件写完后用QMessageBox弹出保存路径用户体验会很自然。5. 实战中踩过的坑和对应的解法5.1 OpenCV图像和Qt界面之间的格式转换PyQt界面显示OpenCV图像最常见的坑就是颜色发蓝发红。原因很简单OpenCV读进来的图像是BGR通道顺序而Qt的QImage默认按照RGB解释。如果不把BGR转成RGB图像里的红色和蓝色就会互换看起来非常别扭。转换代码一般是这样rgb_image cv2.cvtColor(bgr_frame, cv2.COLOR_BGR2RGB) h, w, ch rgb_image.shape bytes_per_line ch * w q_image QImage(rgb_image.data, w, h, bytes_per_line, QImage.Format_RGB888)转换成QImage之后再用QPixmap.fromImage显示到QLabel上。这里有一个隐蔽的坑QImage构造时如果直接传rgb_image.data底层并没有复制数据只是引用了同一块内存。一旦后面rgb_image变量被回收或者内容被修改界面上的图像可能变成花屏。稳妥的做法是构造完QPixmap之后保持对原始frame的引用或者在需要长期保留时用.copy()复制图像数据。5.2 线程里更新UI的正确姿势PyQt中直接在工作线程里调用setText、setPixmap这类UI更新方法轻则界面卡顿重则程序崩溃。Qt的设计是UI操作必须发生在主线程而工作线程通过信号通知主线程。所以规范的做法就是在InferenceThread里emit一个携带图像或文本的信号在主线程里用pyqtSlot装饰的槽函数去更新控件。另外一个容易被忽略的问题是信号频率太高。实时视频检测时frame_ready信号可能每秒发几十次主线程如果每个信号都触发一次图像缩放和绘制CPU占用会飙升。我的处理方式是控制发信号的节奏比如每处理两帧才发一次信号。还可以在emit前判断当前是否有未处理的帧如果上一帧还没来得及显示就丢弃当前帧保证界面始终显示最新的结果而不是排队堆积。这样既保证了画布流畅也避免了内存持续增长。5.3 推理慢的常见原因和优化顺序如果发现检测速度不达标不要马上怀疑模型太大。先说优化顺序第一看图像分辨率第二看模型规格第三看推理后端第四看后处理和绘制开销。图像分辨率是最容易被忽略的。很多视频源是1920×1080或更高如果直接把整帧送入模型即使模型本身不大预处理和推理耗时也会成倍上升。把输入尺寸从1280降到640速度可以提升三到四倍精度损失对常见缺陷来说是可控的。如果必须检测小目标就局部区域高清裁剪而不是全局上大分辨率。模型规格方面yolov8n和yolov8s在速度上差距很大。如果部署机器是普通CPU优先选n如果有独立显卡s甚至m都可以接受。推理后端方面ONNX配合onnxruntime是CPU上的首选在有NVIDIA GPU时TensorRT的收益更明显但它依赖环境配置原型阶段可以先不碰。最后还有一个很多人想不到的点绘制边框和文字也占时间。如果目标多每帧画几十个框加文字说明OpenCV的绘制函数累计开销也不小。实时模式下可以关掉文字或者降低绘制频率。实测中类似“推理只要100毫秒绘制却要50毫秒”的情况并不少见。5.4 裂缝小目标、阴影和光照干扰怎么调道路缺陷检测的精度问题最后基本都会归结到两类一类是裂缝这种小目标漏检一类是水渍、阴影、路面接缝造成的误检。针对小目标漏检我的经验排序是先把输入分辨率提上去然后做滑窗推理最后再考虑增加数据。输入分辨率从640提到1280对裂缝检测的提升通常显著优于简单加数据。如果内存有限就用滑窗把一张大图切成若干小块逐块推理再合并。合并时要注意相邻窗口的目标可能被重复检测所以需要按IoU做一个跨窗口去重。针对阴影和水渍误检最有效的不是调模型结构而是清理训练数据。把容易误检的负样本尽量多的收集起来比如带明显阴影的路面、刚洒过水的路面、沥青接缝加入训练集并在标注时保持为空背景。模型在训练时见过这些样本后就会越来越倾向把它们当背景。后处理也可以加一道按位置过滤比如缺陷区域如果出现在图像顶部的天空部分大概率是误检可以直接丢弃。还有一个操作层面的技巧置信度阈值不要固定一个值。如果当前场景比较干净可以把阈值调到0.5以上减少误报如果明显有裂缝但检不全就降到0.25左右。我把这个阈值暴露到界面上就是为了让使用者能根据具体情况自行调整而不是被写死的算法参数束缚。6. 沿着这个原型还能往哪些方向走一个能跑通图片、视频、摄像头检测的YOLOv8PyQt项目做到这里其实已经具备了一个桌面检测工具的基本骨架。如果你想在这个基础上继续扩展我建议优先考虑以下几个方向。第一个方向是接定位信息。路面缺陷如果只知道在图片里的位置对巡检工作来说还不够。可以在采集时同步记录GPS坐标再用相机内外参把检测框中心点映射到经纬度生成一个带坐标的缺陷地图。这一步相当于把检测结果从“图片里的一堆框”升级成了“可指导维修的现场数据”。第二个方向是缺陷程度的量化。坑槽面积、裂缝长度这些指标不是靠目标检测框直接得到的。可以接一个分割模型比如YOLOv8-seg把缺陷像素抠出来再通过像素标定换算成实际尺寸。这类输出对养护部门更有价值也更容易体现项目的实用性。第三个方向是模型量化与边缘部署。把ONNX模型进一步转成INT8量化版本部署到低功耗的工控机或车载小主机上实现初级的路侧实时监测。加上日志上传和远程管理就是一个完整的边缘巡检节点。我在实际开发里最大的体会是算法只占整个项目的一半另外一半藏在数据处理、界面交互和工程化部署里。把YOLOv8的模型训练和PyQt的界面串联起来需要的不是某一个很深的技术点而是把整条链路中各个细枝末节都照顾到。希望这篇文章能帮你在做同类项目时少踩几个坑尽快跑通属于自己的那一版。
阅读完成 · 觉得有帮助？
