企业官网建设流程全解析

1. 项目概述：为什么选择YOLO系列做水果识别桌面应用

先说句实在话：水果识别这套东西，网上教程一抓一大把，但绝大多数都停在"跑通官方Demo"那一步。真正要落地成一个能双击打开、拖张图进去就能用的桌面工具，中间还有很长一段路要走。我做的这个项目就是把YOLOv5/v8/v10的训练到PySide6桌面应用部署整个链路走了一遍，这篇文章把关键环节和踩过的坑都记录下来。

这个项目解决的实际问题是：给水果分拣场景提供一个离线、可视化、可操作的识别工具。比如说小型的果蔬店要统计货架上的水果种类，或者家庭用户想识别冰箱里放了什么水果，这些场景都不适合架一台服务器做云端推理，一台带GPU的普通电脑直接跑桌面应用是最务实的方案。应用的价值在于把模型打包成图形界面，拖拽图片、实时摄像头识别、批量处理图片，这些操作不需要使用者懂任何深度学习知识，双击就能用。

适合来参考这篇文章的人，我大致分三类：第一类是学过深度学习理论但没做过完整项目的学生，第二类是工作中遇到水果识别需求但不知道怎么从模型走到产品的工程师，第三类是单纯想给自己的技术栈加一个"从训练到部署"闭环经验的开发者。你说你只关心模型精度？那训练部分值得看；你说你想直接做个软件？那PySide6集成部分可以重点看；两者都想要的话，就从头到尾过一遍。

有一点我得先说清楚：YOLOv5、v8、v10虽然都叫YOLO，但它们的架构和训练细节差异挺明显的，不是改个配置文件就能无缝切换。这篇文章会花不少篇幅做版本选型分析，因为这里面的考量直接决定了后续训练成本和推理表现，千万别跳过。

我最终选择的主方案是基于YOLOv8的，后面会讲清楚为什么不是v5也不是v10。同时三个版本我都会给出可复用的训练策略，方便你根据手里的硬件和精度需求自己权衡。

2. 技术选型解析：YOLOv5/v8/v10怎么选，以及PySide6的优势

2.1 YOLO版本对比：从结构到适用场景的硬核分析

我在动手之前，把三个版本的官方文档和源码都过了一遍，结合水果识别这个具体任务做了对比。这里直接给结论，再解释结论怎么来的。

YOLOv5是目前生态最成熟、资料最多的版本，网上随便一搜就是大量现成的教程。它的优势在于稳定：CSPDarknet骨干网络加PANet颈部结构，经过大量社区验证，各种硬件适配都做得比较到位。在水果识别这种类别较少的任务上，v5s或者v5m的精度完全够用，而且显存要求不高，一张6G显存的卡就能跑得有模有样。但它的问题也很直接，就是代码风格和官方的其他YOLO版本不统一，用的是自己的仓库维护方式，后续如果要迁移到v8或者v10，代码习惯上要调整一下。

YOLOv8是Ultralytics团队在v5基础上重构的版本，最大的变化是换成了C2f模块替代原来的C3模块，颈部结构也做了优化。C2f这个模块的核心思路是把不同层级的特征图做更充分的融合，梯度流更丰富，所以同等参数量的情况下，v8的mAP普遍比v5高1到2个点。对水果识别来说，这意味着对"青苹果和青梨"这类颜色接近的目标，v8的区分能力会好一些。另外v8官方的Python包做得特别顺手，训练、验证、导出的一体化接口写得很简洁，对要做桌面应用的人来说，这个API设计省了很多事。

YOLOv10是较新的版本，主打实时性，引入了NMS-free的机制。传统YOLO在做目标检测的时候，网络输出一堆候选框，需要靠非极大值抑制去掉重复框，v10通过更精细的标签分配策略，让网络直接输出干净的检测结果，省掉了NMS这一步。在推理速度上确实有优势，官方数据在相同精度下延迟可以降低不少。但代价是：NMS-free的模型在密集遮挡场景下容易出现漏检，水果在货架上层叠摆放时，这个问题会暴露得比较明显。我的实际测试里，v10在单个水果的图片上表现不错，但在一筐水果的场景里，偶尔会漏掉被大面积遮挡的果子。

2.2 选型结论：为什么主力用YOLOv8

最后的决定是：主力训练用YOLOv8m，同时保留一个YOLOv5s作为快速验证模型，v10则作为速度要求的备选方案。

选择v8m的核心理由是精度和速度的平衡点最符合水果识别场景。水果识别有几个天然难点：同一种类的水果颜色差异大，比如苹果有红的有青的；不同种类的水果形状接近，比如桃子和苹果不仔细看确实像；还有光照变化、遮挡重叠、反光这些实际问题。v8的C2f结构在特征提取上的优势，对这几种难点都有不同程度的缓解。m这个尺寸在保证精度的同时，单张图片推理时间在普通显卡上能控制在30毫秒左右，部署到桌面应用里完全能做到"拖进去就出结果"的体验。

v5s保留作为快速验证模型，主要是训练速度快，改数据集、调参数的时候先用它跑一轮，10分钟就能看出大概趋势，比每次都跑v8m省时间得多。v10目前我还在持续观察，如果后续用户反馈对速度要求更高（比如要在大批量图片上做实时处理），可以考虑切换。

这里有个隐藏的成本问题：三套模型如果每套都从头训练，数据集准备的工作量是乘三的。所以我的做法是数据集一套，训练脚本做成通用模板，通过参数切换不同版本，后续会讲具体怎么做。

2.3 PySide6：桌面应用框架选择的理由

为什么不用Tkinter、不用PyQt5/PyQt6，也不用Electron？这个选择我犹豫过一阵子，最终还是落在PySide6上。

Tkinter的问题是界面太朴素，做出来的东西一眼就是工具软件，用户观感不好，而这偏偏是给非技术人员用的软件，界面的友好程度直接影响使用意愿。PyQt5和PySide6本质上都是Qt的Python绑定，功能上几乎没区别，但PyQt5的GPL授权协议对商用场景限制较多，PySide6是LGPL协议，做闭源分发更安心。Electron的问题就更直接了：体积大、内存占用高，一个做图像识别的工具动辄几百兆，在用户电脑上跑起来风扇呼呼转，体验不友好。而且要调Python的推理模型，Electron还得再套一层后端服务，架构上绕远了。

PySide6的优势是：可以用QSS做接近现代风格的界面、信号槽机制天然适合处理"点击按钮->加载模型->异步推理->显示结果"这类交互流程、和Python生态无缝衔接，模型推理代码可以直接在应用里调用，不用额外起服务。我用PySide6做的界面，在普通办公电脑上运行，内存占用稳定在400到500兆，启动时间不到3秒，这个表现是能接受的。

3. 水果识别数据集处理：标注规范与增强策略

3.1 数据来源与标注的实操细节

数据集是决定模型上限的因素，这一点怎么强调都不过分。算法结构能提升的精度是有限的几个点，但数据质量差，模型直接废掉。我收集数据的渠道主要有三个：自己拍摄、公开数据集筛选和网络图片爬取。

自己拍摄是最可控的，我用手机在超市、水果店、家里餐桌各种场景拍了大约2000张图片。拍摄的时候有个小技巧：不要只拍正对着水果、光线均匀的"理想照片"，要有意制造一些困难样本。比如把水果放在阴影里、让两个苹果叠在一起、隔着保鲜膜拍、晚上开暖光灯拍，这些场景模型训练时见了，部署的时候才不会翻车。公开数据集我筛选过一遍，只保留背景干净、标注准确的那部分，宁可数量少一点，也不要混入噪声样本。网络图片爬取这块，要注意版权问题，我主要是参考构图方式和场景多样性，不会直接拿别人的图进训练集。

标注工具用的是LabelImg，它支持YOLO格式的直接导出，操作路径是：画框->输入类别->保存txt。标注规范上，我定了几个原则：

• 遮挡超过50%的目标不标注，因为模型确实学不会"猜出被遮住的半颗苹果"
• 框要贴合目标边缘，不能为了省事把框画得过大，否则IoU计算会有偏差
• 类别不平衡时要记录各类别数量，及时补充少数类

最终数据集是6个类别：苹果、香蕉、葡萄、橙子、梨、桃子。总共4200张，因为水果种类本身不多，识别难度集中在类内差异和场景变化上，数据量在这个量级上已经能训练出效果不错的模型。

3.2 数据增强：这个环节直接决定模型泛化能力

训练的时候如果直接丢原始图片进去，模型很容易过拟合。水果识别的特殊性在于：同一颗苹果，在自然光、冷光灯、阴影下，模型看到的是完全不同的图像。所以数据增强是训练流程里很有价值的环节。

我用的Mosaic增强是YOLO系列默认开启的，iou=0.2的关闭设置、随机透视、HSV色域增强、随机翻转都开了。这里重点说两个容易踩坑的参数。

HSV增强的hsv_h我设为0.015，hsv_s设为0.7，hsv_v设为0.4。这个组合的意思是：色相轻微变化，饱和度和明度的变化幅度大一些。水果识别的关键特征很多就在颜色上，如果色相变化太猛，青苹果会变成红苹果，类别就乱套了。但饱和度和明度的变化能帮模型适应不同光照，这是好事。有个参数叫mosaic，我推荐训练的前半段开mosaic，后10个epoch关掉。原因很朴实：mosaic把四张图拼在一起，目标会被压缩变小，模型在后期需要适应正常尺寸的目标，否则部署时遇到正常大小的水果会不敏感。

还有一个细节：MixUp增强我关了。水果图片背景相对干净，MixUp之后两张图叠加，语义会变得混乱，对类别区分没有帮助，反而拖慢收敛。这个决策是基于多轮实验对比的，开MixUp的那组训练mAP反而掉了1.5个点。

4. YOLOv8水果识别模型训练：从配置到评估的完整流程

4.1 训练环境的准备与依赖安装

训练环境我用的是Ubuntu系统加一张12G显存的显卡，PyTorch版本2.0以上，CUDA用的11.8。如果是Windows环境，建议直接用官方提供的conda环境配置，别自己手动装依赖，版本冲突能让人崩溃一整天。

创建一个干净的conda环境，Python版本3.9：

conda create -n fruit_yolo python=3.9 conda activate fruit_yolo pip install ultralytics

需要注意，ultralytics这个包同时支持yolov8和yolov5的模型加载，如果之前电脑上装过旧版本的torch，建议先更新：

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

还有个容易忽略的点是检查本机CUDA算子是否正常编译。装完之后跑一段测试代码，能输出设备信息就说明环境没问题。

4.2 数据集配置与模型训练的完整命令

YOLOv8的数据集配置是一个YAML文件，路径配置和数据类别是核心。我用的配置如下：

path: /home/user/projects/fruit_detection/ train: images/train val: images/val test: images/test nc: 6 names: ['apple', 'banana', 'grape', 'orange', 'pear', 'peach']

划分比例我按8:1:1来切，训练集3360张、验证集420张、测试集420张。这里有个心得：验证集要保证每个类别都有一定数量，不要随机切完发现某个类别在验证集里只有几张图，那指标评估的方差会很大。

训练命令：

yolo detect train data=/path/to/fruit.yaml model=yolov8m.pt epochs=150 imgsz=640 batch=16 device=0

参数含义不多说了，重点讲三个关键选择。epochs设150是经过对比的：100轮在小数据集上已经能看到不错的mAP，但150轮的模型在困难样本上的表现会更好，超过200轮之后收益就很低了，反而有过拟合风险。imgsz设640，这是精度和速度的常规妥协点，测试过768输入能涨0.8个点的mAP，但推理时间增加了约40%，对桌面应用来说不值得。batch设16基于12G显存的容量，刚好能放下，再大就会爆显存。

训练过程中我习惯盯两个指标：训练loss曲线要平滑下降，验证集mAP50要稳步上升。如果mAP50在某个epoch之后出现连续下降，基本就是过拟合开始了，应该早停而不是硬着头皮跑完所有epoch。

4.3 评估结果解读与模型选择

这是整个项目里最容易出问题的地方。很多初学者一看到mAP50是0.95就欢呼，但水果识别应用里，我更关注的是mAP50-95和每个类别的单独AP。

训练跑完的mAP50-95在0.88左右，mAP50到了0.97。但要注意，mAP50反映的是IoU为0.5时检测的准确性，对框的精度不够敏感。实际部署时，如果框偏大偏小，mAP50依然可以是满分，但对用户来说，框的位置不准确就是不好用。所以要把mAP50-95作为主要参考，它对框的质量要求严格得多。

类别层面，表现最好的是香蕉，AP50-95有0.93，原因可能是香蕉的形态特征太明显了，弯弯的形状和亮黄色在特征空间里跟其他水果区分度很高。最难的是橙子和梨，AP50-95在0.85左右，因为颜色、形状和苹果都有重叠，尤其是青苹果和青梨，模型偶尔会分不清。这个结果直接指导了后续的数据补齐工作，我又拍了几百张青苹果和青梨的特写图，针对性加强这两个类的区分。

4.4 训练结果可视化与阈值调整

训练完成后，results.png里是全部曲线，confusion_matrix.png能直观看到哪些类别互相混淆。我看了混淆矩阵之后，发现橙子被误判为橘子和柚子各出现了几十次，这是训练数据中这两个类别的样本太少导致的。新增样本后，误判数量明显下降。

推理阈值方面，默认conf_thres是0.25，在实际测试中发现水果识别场景可以适当提高。因为目标本身是常见的、特征清晰的水果，模型输出的置信度普遍在0.7以上，把conf_thres提到0.5能有效减少误检，又不会影响正常识别。我在界面里加了滑动条让用户调整这个参数，默认0.4，适合大多数场景。

5. PySide6桌面应用开发：界面设计、多线程推理与核心实现

5.1 应用架构与界面功能设计

这个桌面应用的架构分三层：界面层、控制层、推理层。界面层负责接收用户操作、显示结果和状态；控制层负责调度推理线程、管理模型生命周期；推理层封装检测模型，输入图片输出检测结果。

从用户角度设计的功能有五个核心模块：

• 本地图片识别：拖拽或点击选择图片，显示原图和检测框
• 摄像头实时识别：调起电脑摄像头，实时显示视频流和检测结果
• 批量图片处理：选择文件夹，对文件夹内所有图片进行识别，结果保存到输出目录
• 参数调节面板：置信度阈值、IoU阈值的滑块调节
• 识别结果统计：显示每类水果的检测数量、当前帧推理耗时

界面布局上，左右分栏设计：左侧是图片显示区域，右侧是操作面板和结果列表。这个布局是参考了几个商业标注软件的习惯，用户上手成本低。

5.2 多线程推理：为什么不能在主线程跑模型

PySide6应用的常见崩溃原因就是直接在UI线程里跑深度学习推理。推理一次要几十毫秒甚至上百毫秒，如果摄像头实时模式每秒处理十帧，UI线程就被占满了，窗口拖不动、按钮点不了，看起来就像死机了。

解决思路是QThread加信号槽机制。我把推理任务封装成一个Worker对象，继承QObject，用moveToThread方法移入子线程。界面发起推理请求时通过Signal通知Worker线程，Worker线程推理完成后通过另一个Signal把结果传回主线程更新界面。

核心代码结构是这样的：

class InferenceWorker(QObject): finished = Signal(dict) error = Signal(str) progress = Signal(int) @Slot(str) def predict_image(self, image_path): try: results = self.model.predict(image_path, conf=self.conf_thres) detection = parse_results(results, image_path) self.finished.emit(detection) except Exception as e: self.error.emit(str(e))

这里有个特别重要的细节：模型在第一次推理时需要加载权重、预热CUDA，大概要花一到两秒钟，这个过程必须在子线程里完成，否则界面就会出现明显的"初始化白屏"。我的做法是在应用启动时先实例化模型但先不推理，等用户第一次选择图片后才真正加载权重，这样整体体验更流畅。

摄像头模式的处理逻辑略有不同，它需要连续不断的视频帧流。我用的方案是QTimer定时器，每隔50毫秒从摄像头读取一帧，放到推理队列里，推理线程处理完一帧就通过信号把结果发回主线程更新显示。这样即使推理速度跟不上帧率，也只是显示的刷新频率变慢，界面不会卡死。

5.3 图像显示与检测结果绘制

PySide6里显示图片最常用的是QLabel加QPixmap，但直接塞大尺寸图片会占用大量内存，而且缩放到小窗口时会导致字体模糊、图片失真。更规范的做法是：读取原始图像，绘制检测框之后，按QLabel的实际大小缩放，然后用QPixmap显示。

检测框绘制使用OpenCV比用QPainter更方便，因为可以直接在numpy数组上操作，OpenCV的rectangle和putText方法速度也快。绘制完的结果格式是BGR，需要转成RGB再换成QPixmap：

rgb_image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB) h, w, ch = rgb_image.shape bytes_per_line = ch * w qimage = QImage(rgb_image.data, w, h, bytes_per_line, QImage.Format_RGB888) qpixmap = QPixmap.fromImage(qimage)

框的颜色和标签的样式，如果每个类别都随机给颜色，用户看到一堆花花绿绿的框反而不直观。我的做法是给每个类别固定一个颜色，苹果红色、香蕉黄色、葡萄紫色、橙子橙色、梨绿色、桃子粉色，这样用户一眼就能根据颜色过渡到对号入座的理解。

5.4 模型导出与推理加速

PySide6应用里直接加载.pt文件是可以的，但首次推理前需要对模型做预热，而且CPU部署时.pt格式的推理效率不是最优的。我在项目中同时提供了两种部署格式。

一种是导出ONNX格式，用onnxruntime推理。优点是跨平台能力强、CPU上比PyTorch原生推理快，模型文件也小。导出命令：

from ultralytics import YOLO model = YOLO('best.pt') model.export(format='onnx', dynamic=True, imgsz=640)

动态输入尺寸这个参数一定要开，这样部署后可以处理任意尺寸的输入图片，不至于用户的照片因为尺寸不符被强制缩放。onnxruntime推理时代码也很简洁：

import onnxruntime as ort sess = ort.InferenceSession("best.onnx", providers=["CUDAExecutionProvider", "CPUExecutionProvider"])

providers的配置需要注意，如果用户电脑没有NVIDIA显卡和对应CUDA依赖，onnxruntime会直接报错。所以这里要把CPUExecutionProvider放在最后兜底，让依赖自动回退。实测下来，ONNX格式在CPU上的推理速度能到每张图150到250毫秒，GPU上能到20到40毫秒，对于桌面应用来说是够用的。

另一种是TensorRT导出，这需要NVIDIA显卡。TensorRT能把模型做层融合和精度校准，推理速度会比ONNX再快一截，适合对实时性要求极高的场景。但导出过程复杂，环境配置也有门槛，我的建议是：如果用户不是重度使用摄像头实时识别，TensorRT的收益感知不明显。

5.5 界面美化与QSS样式

PySide6应用如果不做样式处理，默认控件风格停留在十几年前的感觉，用户一打开就想卸载。我用QSS模拟了现代应用的风格：深色主题、圆角按钮、卡片式分区。

深色主题的关键是配色要协调，我用的是深灰蓝底加亮色强调。按钮的QSS写法大致是这样的：

QPushButton { background-color: #3a86ff; color: white; border-radius: 6px; padding: 8px 20px; font-size: 14px; border: none; } QPushButton:hover { background-color: #6ea8fe; } QPushButton:pressed { background-color: #2b62c4; }

值得注意的一点是QSS里不支持直接设置渐变阴影，如果要做出阴影效果可以用QSplashScreen或者自制控件，但会显著增加复杂度。我的建议是，个人工具项目的界面做到配色统一、控件错落有致就够了，不必追求极致的毛玻璃效果，那部分时间不如花在打磨交互逻辑上。

6. 应用打包分发：PyInstaller打包流程与常见坑点

6.1 打包配置与体积优化

桌面应用做完之后，最后一个要攻克的问题是分发给别人用。不能在每台目标电脑上都装Python环境然后跑源码，这不现实。PyInstaller是目前最成熟的Python打包工具，用法也简单，但打包深度学习项目会有一堆特殊问题。

基础打包命令：

pyinstaller --windowed --onefile --name FruitDetector main.py

这里两个参数很关键：--windowed让打包后的程序不显示黑色控制台窗口，--onefile把所有依赖打包成单个exe文件。但单文件方案有个缺点：启动时需要解压到临时目录，大项目启动会慢。我的项目打出来是800多兆，解压时间要十几秒，所以最终改用了--onedir模式，生成一个文件夹，启动速度和目录结构都一目了然。

体积优化方面，800兆的大头是CUDA相关库和PyTorch本体。如果目标用户机器有NVIDIA显卡，保留CUDA依赖能让推理速度快很多，但体积直接爆炸；如果用户机器可能没有独立显卡，那就得走CPU推理，不确定因素太多。我的处理是默认打包CPU版本推理，配置文件里预留了GPU开关，让高级用户自己改配置切ONNX的GPU providers，这样对没有独显的用户最友好。

6.2 项目文件结构检查与路径问题

打包之后最常见的问题是运行时报错找不到模型文件。开发环境里路径是model/best.onnx，直接运行没问题，打包后就变成临时目录下的路径，程序找不到文件。

我的解决方式是使用sys._MEIPASS机制，把模型文件作为data文件添加进打包配置：

if hasattr(sys, '_MEIPASS'): base_path = sys._MEIPASS else: base_path = os.path.abspath(".") model_path = os.path.join(base_path, 'model/best.onnx')

PyInstaller的spec文件里加：

datas=[('model/best.onnx', 'model')]

这样打包出来的文件夹里就会包含模型文件，程序启动时从临时目录加载。这里有个细节：用户电脑上如果被杀毒软件拦截临时目录的读取，程序会直接崩溃，所以如果出现"开始加载模型"后闪退的情况，优先考虑这个原因。

6.3 跨平台打包与Windows兼容性

我主要做的Windows版本，但PySide6是跨平台的，Linux和macOS理论上都能跑。跨平台时注意一个坑：不要直接在不同系统间复制打包产物，因为动态链接库不通用，必须在目标平台上重新打包。macOS上打包还需要额外处理签名问题，不然用户第一次打开会提示"已损坏，无法打开"。

Windows上验证兼容性时要注意：最低支持的Windows版本、是否有缺少的VC运行库、常见杀毒软件误报。我的经验是，PyInstaller打包的程序用UPX压缩外壳有时会触发杀毒软件误报，解决方式是去掉UPX或者加白名单。

6.4 打包验证清单

每次打包之后，我会按这个清单逐项验证：

• 在新装的虚拟机里用无Python环境的干净系统测试
• 分别测试图片识别、摄像头识别、批量处理三个模块
• 检查模型文件路径是否正常加载
• 验证置信度滑动条在不同阈值下的效果差异
• 确认程序能正常关闭且进程完全退出

第4点值得展开：很多人在界面里加了滑动条但没做好联动，Qt的信号绑定和PySide6不同版本之间偶有差异。我用的是Qt Designer生成的UI转成py文件，再手写业务逻辑，这种方式比起纯代码画界面更直观，也避免了两套方案并存导致的手动同步问题。

7. 实操过程实录与经验总结：从训练代码到桌面应用的一次完整演练

7.1 完整训练流程脚本

为了让整个流程可复现，我把训练部分整理成了一个脚本，从数据集划分到模型评估一条命令跑通：

from ultralytics import YOLO # 数据集划分已在前期完成，直接加载配置 model = YOLO('yolov8m.pt') # 训练150轮，早停机制 results = model.train( data='dataset/fruit.yaml', epochs=150, imgsz=640, batch=16, patience=30, save_period=10, project='runs/train', name='fruit_v8m', exist_ok=True, pretrained=True, optimizer='SGD', lr0=0.01, augment=True, seed=42 ) # 验证最佳权重 best_model = YOLO('runs/train/fruit_v8m/weights/best.pt') metrics = best_model.val(data='dataset/fruit.yaml') print(f"mAP50-95: {metrics.box.map}") # 导出ONNX best_model.export(format='onnx', dynamic=True, imgsz=640)

seed=42这个参数很容易被忽略，但对实验可复现性很关键。深度学习训练有随机性，不固定种子的话，两次训练可能得到完全不同的模型表现，后续对比实验就说不清楚了。

7.2 水果识别常见问题与排查技巧

整理一批实际运行中遇到的典型问题，按频率排序，做一个速查表：

表格里第一行值得展开讲：学习率设置不合理是初学者最常见的问题。我早期用默认的Adam优化器跑，loss降到某个点就不动了，换成SGD加合适的初始学习率才稳定收敛。后来发现是默认动量参数设置的收敛速度从根本上不对。

第二行的教训也印象深刻：有一批标注是外包做的，标注框普遍比目标大一圈，结果训练完模型预测的框全部偏大，识别位置不准确。后来花时间把所有数据的标注都重新过了一遍，才把框的质量提上来。

7.3 模型效果提升的试验记录

在训练过程中，我记录了不同实验组合的效果对比：

最后一组值得多说两句：v8s的参数量只有约11M，v8m是25.9M，模型大小翻倍但mAP提升不明显，只有约2.4个百分点。但推理速度v8m仍然能到GPU上30毫秒左右，桌面应用完全感觉不到延迟。所以看到2.4个点的提升，我的判断是换得值，模型的鲁棒性在困难样本上的表现更好。

7.4 部署效果的实测反馈

整个应用做完之后，我拿了30张没进过训练集的实拍照片做了盲测。结果：28张全部识别正确，1张把青苹果误判为梨，1张把重叠的两个橘子识别成了一个。误判的这两张都有一个共同点：都是强逆光导致的颜色失真和轮廓不清。这也说明，模型对光照变化的适应还有提升空间，后续可以考虑在数据增强中加入更多逆光模拟。

实测还有一个比较愉悦的发现：CPU推理模式下，批量处理50张图片总共耗时约12秒，单张平均240毫秒，这个速度对于离线处理场景完全够用。摄像头实时模式下，GPU推理帧率稳定在30帧以上，CPU推理在8到12帧之间，有轻微卡顿感但不影响使用。

7.5 版本迁移与后续扩展方向

做完这个项目之后，我最大的体会是：做AI应用，模型训练只是起点，真正考验人的是把模型包成一个好用的产品。从训练到PySide6部署，看着很长，但每一步都有章可循。PySide6这个框架的生态现在已经很成熟了，配合QThread做推理调度，做出来的桌面应用体验跟商业软件有差距，但已经能走出"纯技术Demo"的范畴。

后续打算扩展的方向有两个，供参考：

第一个是把模型换成YOLOv10做推理速度对比。之前提到v10的NMS-free设计在速度上有优势，准备在用户量上来之后再评估是否值得切换。切换的话主要工作量在推理代码适配上，因为v10的推理输出格式和v8略有不同，需要调整后处理代码。

第二个是增加训练数据收集的自动化。现在每次识别结果如果置信度低于阈值，可以自动把图片存到一个"待确认"文件夹，定期人工筛选后加入训练集做增量训练，形成数据闭环。这个功能价值很大，因为它让模型越用越准，真正贴合实际场景。

另一个实用的小技巧：在批量识别时增加进度条和统计汇总功能，用户可以直观看到已经处理了多少张、识别出了哪些类别、各有多少个，这是分拣场景下使用频率最高的功能，也是用户几乎一上来就会问"有没有统计"的地方，后来才发现，统计这块做得好，软件的专业感直接拉满。