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系列默认开启的iou0.2的关闭设置、随机透视、HSV色域增强、随机翻转都开了。这里重点说两个容易踩坑的参数。HSV增强的hsv_h我设为0.015hsv_s设为0.7hsv_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.9conda create -n fruit_yolo python3.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 modelyolov8m.pt epochs150 imgsz640 batch16 device0参数含义不多说了重点讲三个关键选择。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, confself.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再换成QPixmaprgb_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(formatonnx, dynamicTrue, imgsz640)动态输入尺寸这个参数一定要开这样部署后可以处理任意尺寸的输入图片不至于用户的照片因为尺寸不符被强制缩放。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( datadataset/fruit.yaml, epochs150, imgsz640, batch16, patience30, save_period10, projectruns/train, namefruit_v8m, exist_okTrue, pretrainedTrue, optimizerSGD, lr00.01, augmentTrue, seed42 ) # 验证最佳权重 best_model YOLO(runs/train/fruit_v8m/weights/best.pt) metrics best_model.val(datadataset/fruit.yaml) print(fmAP50-95: {metrics.box.map}) # 导出ONNX best_model.export(formatonnx, dynamicTrue, imgsz640)seed42这个参数很容易被忽略但对实验可复现性很关键。深度学习训练有随机性不固定种子的话两次训练可能得到完全不同的模型表现后续对比实验就说不清楚了。7.2 水果识别常见问题与排查技巧整理一批实际运行中遇到的典型问题按频率排序做一个速查表问题现象可能原因排查方法解决方案训练时loss不下降学习率设置不合理查看初始loss值是否过大或过小调整lr0到0.001-0.01范围验证集mAP过低数据标注不一致抽查标注框与目标边缘匹配度统一标注规范后重新标注单个类别完全检测不到类别样本太少或类别名配置错检查数据集中该类数量补充数据或检查names列表顺序小水果目标漏检输入分辨率太小查看原图中小目标的像素占比增大imgsz或专门采集近景图摄像头识别卡顿推理线程阻塞检查是否在UI线程推理改为QThread异步处理打包后找不到模型文件路径配置错误确认sys._MEIPASS逻辑使用绝对路径或打包data文件表格里第一行值得展开讲学习率设置不合理是初学者最常见的问题。我早期用默认的Adam优化器跑loss降到某个点就不动了换成SGD加合适的初始学习率才稳定收敛。后来发现是默认动量参数设置的收敛速度从根本上不对。第二行的教训也印象深刻有一批标注是外包做的标注框普遍比目标大一圈结果训练完模型预测的框全部偏大识别位置不准确。后来花时间把所有数据的标注都重新过了一遍才把框的质量提上来。7.3 模型效果提升的试验记录在训练过程中我记录了不同实验组合的效果对比实验配置mAP50-95备注基础训练无额外增强0.82基准线开启MosaicHSV增强0.86提升明显关闭MixUp增强0.88减少语义混淆补充青色水果样本0.90针对橙梨区分使用YOLOv8m替代v8s0.92参数量增大最后一组值得多说两句v8s的参数量只有约11Mv8m是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略有不同需要调整后处理代码。第二个是增加训练数据收集的自动化。现在每次识别结果如果置信度低于阈值可以自动把图片存到一个待确认文件夹定期人工筛选后加入训练集做增量训练形成数据闭环。这个功能价值很大因为它让模型越用越准真正贴合实际场景。另一个实用的小技巧在批量识别时增加进度条和统计汇总功能用户可以直观看到已经处理了多少张、识别出了哪些类别、各有多少个这是分拣场景下使用频率最高的功能也是用户几乎一上来就会问有没有统计的地方后来才发现统计这块做得好软件的专业感直接拉满。