企业官网建设流程全解析

关于 YOLOv8/YOLOv5 + PySide6 做花卉识别系统，我先说结论：这个技术栈是够用的，而且很适合作为深度学习和图形界面结合的完整项目。它不只是训练一个模型，而是把模型、数据处理、界面交互、批量识别、打包部署全链路串起来。如果你想拿它做毕业设计、课程设计，或者作为简历里的实际项目，关键不在那一行训练命令，而在于数据怎么整理、参数怎么调、界面怎么封装、出错了怎么排查。这篇文章会按实际开发顺序拆开讲，从安装环境到训练模型，再到写一个能选图、能拍照、能显示识别框的 PySide6 桌面应用，最后补充我踩过的坑。

1. 这套系统到底解决什么问题，值不值得做

1.1 它不仅是“识花软件”，更是一套完整的目标检测工程

很多人看到“花卉识别鲜花识别检测系统”，第一反应是“用分类模型不就行了吗？”。这里有个重要区分：图像分类只能告诉你“这是什么花”，目标检测做的是在整张图里找出每一朵花的位置，用矩形框标出来，再告诉你每个框里是什么品种。如果你的应用场景是“阳光下有一片花丛，画面里有玫瑰、菊花、月季混在一起”，分类模型会非常吃力，目标检测模型则能同时输出多个目标的位置和类别，更适合真实图片。

所以这个项目的本质是物体检测（Object Detection），不是单纯分类。它解决的问题是：在复杂背景、多目标、多类别的情况下，自动定位并识别花卉。落地场景包括景区拍照识花、植物研究辅助工具、智能花卉分拣系统、拍照巡检等。对学习者来说，完整做一遍这个项目，等于把深度学习检测模型的完整流程和桌面应用开发流程都练了一遍，这在课程设计和求职项目里是非常拿得出手的。

1.2 适合什么场景和人群

这个系统适合三类人：

• 计算机视觉方向的学生：需要把 YOLO 模型、训练流程、评估指标、模型导出串起来，做毕设或者课程设计。
• 想要快速搭建桌面工具的开发者：不想一直用命令行做推理，想有一个能选择图片、实时显示识别框的界面。
• 准备简历项目的求职者：只写“我会 YOLO”太单薄，如果写成“我训练过自建数据集，并用 PySide6 封装成桌面系统”，项目完整度会高很多。

当然也有不适合的情况：如果你想做大规模实时视频分析，比如无人机航拍万亩花田检测，桌面单机工具并不是最优方案，那要往服务化和分布式方向走。如果只是做一个手机 App 识花，PySide6 桌面端也不是最终解法，更适合小程序或移动端推理。所以要先明确自己的目标场景，不要一上来就想着把功能做“大”。

1.3 YOLOv8 和 YOLOv5 同时出现，怎么选

这个项目标题里同时出现了 YOLOv8 和 YOLOv5，说明设计者希望系统具备兼容性。实际开发中，建议不要同时作为两个独立方案来做，而是把其中一个作为主力，另一个作为对照。我一般建议新手先用 YOLOv8，因为它的 API 更简洁，训练命令和推理接口设计更友好，数据集格式和文档也更清晰。如果你的环境比较老，或者需要迁移到自有部署平台，YOLOv5 可能更稳，因为生态时间长，社区资料多，很多老设备的兼容方案都齐了。

从实际效果看，在中小规模花卉数据集上，YOLOv8 默认配置的精度通常略高于 YOLOv5，但差距并不会大得离谱。真正影响结果的还是数据质量、标注一致性和训练参数。所以选型时不用太纠结，关键是选一个守住，跑通之后再做对照。

2. 环境准备：先把依赖版本和硬件条件确认清楚

2.1 Python 和 PySide6 的版本搭配，为什么安装顺序很重要

PySide6 是 Qt6 的 Python 绑定，安装本身不算难，但容易和已有环境冲突。我建议使用独立虚拟环境，不要直接装到系统 Python 里，否则以后打包或者升级依赖时很可能一团糟。

环境准备顺序很重要，按这个顺序走能少很多坑：

1. 创建虚拟环境：python -m venv flower_env
2. 激活虚拟环境：Windows 下执行flower_env\Scripts\activate，Linux/macOS 下执行source flower_env/bin/activate
3. 安装 PySide6：pip install PySide6
4. 安装 PyTorch：根据自己有没有 N 卡选择 CPU 版或 CUDA 版
5. 安装 YOLO 相关依赖：pip install ultralytics或处理 YOLOv5 仓库依赖

这里有个容易踩的问题：如果先装 PyTorch，再装 PySide6，通常没问题；但如果你在已安装 ultralytics 的环境里升级了 Python 或 PyTorch，很可能出现动态链接库不匹配。所以先创建一个干净环境，再逐项安装，每个库装完跑一下最小导入验证，比攒着一口气装完然后报错更高效。

2.2 深度学习框架装 CPU 版还是 GPU 版，主要看显存

花卉检测模型不算超大模型，但训练时 GPU 和纯 CPU 的体验差别非常大。如果只是做界面演示，跑推理，CPU 也可以接受，但速度会比较慢，尤其是摄像头实时识别时，CPU 推理的帧率可能只有 1-3 FPS。如果是训练自己的数据集，CPU 训练一个中等规模数据集，可能要按小时或天计算，而一般 GPU 只需要几十分钟到几小时。

判断方式很简单：

• 有 NVIDIA 独立显卡且显存不低于 4GB：建议安装 CUDA 版 PyTorch。
• 没有 NVIDIA 显卡，或者显存只有 2GB 左右：先用 CPU 版跑通流程，训练时把图片尺寸和 batch 调小。
• 如果你想用的是 Mac 的 M 系列芯片，可以正常安装 PyTorch，YOLO 在 Apple Silicon 上也能跑，但很多预编译的 CUDA 加速用不了。

安装 PyTorch 时不建议手动下载 CUDA 工具包，直接通过 PyTorch 官网提供的 pip 命令安装最稳妥。因为 PyTorch 自带的 CUDA 运行库版本和系统驱动有对应关系，如果你不清楚驱动版本，就先用nvidia-smi查看驱动支持的 CUDA 版本，再选择匹配的 PyTorch 版本。

2.3 建议的最小配置和推荐配置

如果你只是做一个能演示的小系统，这个配置足够了：

• CPU：4 核以上
• 内存：8GB 以上
• 显卡：可选，无显卡也能运行推理
• 系统：Windows 10/11 或 Ubuntu 20.04+

如果你想训练一个效果不错的花卉模型，推荐配置是：

• CPU：6 核以上
• 内存：16GB 以上
• 显卡：NVIDIA GTX 1660 6GB 起步，显存越大越好
• 硬盘：至少准备 10GB 空间存放数据集、权重文件和中间结果

显存不够时不要硬训练，优先把batch-size降到 4 或 2，再把imgsz从 640 降到 512 或 416，能明显减少显存占用。低配置机器也能跑，但不要指望训练速度和高端显卡一样快，也不要一上来就开大批次训练。

建议：第一次跑通时，不要追求高精度，先用最小数据集验证整个流程能走通，再考虑提升训练规模和效果。

3. 数据集整理：花卉识别的第一道坎不是模型，是数据

3.1 数据从哪来，如何避免类别不平衡

花卉识别系统的上限，很大程度由数据集决定。训练好一个检测模型，必须有带位置框标注的数据，不是简单的一堆花照片就能直接用。数据来源主要有几类：

• 公开数据集：比如部分开源花卉检测数据集、植物分类数据集，但很多公开集是分类格式，需要转换并补标注。
• 自己拍摄：用手机拍不同场景、不同角度、不同光照下的花，工作量比较大，但效果最贴合实际应用。
• 网络采集：需要注意版权和合规性，只能作为学习用途，不要用于商业化项目。
• 爬取后清洗：先做图像去重、筛选，再交给标注工具处理。

类别不平衡是个容易被忽略的问题。如果你的数据集里月季有 2000 张，菊花只有 100 张，训练出来的模型很可能对月季过拟合，对菊花识别能力很差。解决思路：

1. 尽量让每类图片数量接近，至少不要差 5 倍以上。
2. 对样本少的类别做增强，比如旋转、翻转、裁剪、亮度变化。
3. 训练参数里可以调节class weights，但这个方式不如直接补数据稳定。

3.2 标注格式转换：VOC、COCO、YOLO 格式之间的坑

标注工具有很多选择，比如 LabelImg、LabelMe、CVAT、X-AnyLabeling。标注出来的结果可能是 Pascal VOC 的 XML 格式，也可能是 COCO 的 JSON 格式，而 YOLO 训练需要的是 TXT 格式。每种格式的坐标定义和存储方式不同，转换时最容易出错。

YOLO 格式每张图对应一个同名 TXT 文件，每一行内容是：

class_id center_x center_y width height

其中坐标值要归一化到 0 到 1 之间。举例：如果一张图宽 640 像素，高 480 像素，一个目标框左上角为 (100, 80)，右下角为 (200, 160)，那么中心坐标是 ((100+200)/2 / 640, (80+160)/2 / 480) = (0.234, 0.25)，宽度是 ((200-100)/640)=0.156，高度是 ((160-80)/480)=0.167。

转换时最容易出现的问题：

• 坐标忘记归一化，训练时 loss 非常不稳定。
• class_id 从 0 开始，但自己在标签文件里从 1 开始标了。
• 图片路径里的文件名和标注文件名不一致，导致训练时找不到标注。
• 图片格式是 BMP 或 PNG，但数据加载配置里没写对。

如果你只是转换一两次，手写脚本或直接用开源转换脚本都可以。如果数据量很大，我建议先写一个小工具统一检查标注文件：图片尺寸、TX 文件数量、类别 id、坐标范围。训练前多检查一遍，能省下大量调试时间。

3.3 训练集、验证集、测试集怎么划分，并写 data.yaml

数据准备好之后，需要划分成三部分：

• 训练集：模型学习的样本，通常占 70% 到 80%。
• 验证集：训练过程中用来评估模型、看是否过拟合，通常占 10% 到 15%。
• 测试集：训练完成后用来做最终评估，尽量不参与训练调参，占 10% 到 15%。

不要把测试集和验证集混用。很多人只划分训练和验证，然后拿验证集当最终效果，这样结果偏乐观，后期部署时才会发现模型泛化能力不足。

划分后需要生成一个data.yaml文件，YOLO 训练时通过它找到数据集。一个典型配置如下：

path: D:/flower_dataset train: images/train val: images/val test: images/test nc: 5 names: 0: rose 1: chrysanthemum 2: tulip 3: sunflower 4: orchid

这里path是数据集根目录，train和val是相对路径。如果你的图片和标注文件是放在一起的，YOLO 会自动在同一目录查找同名 TXT 文件，所以图片目录和标签目录的对应关系要确保正确。有些情况下需要单独指定train_labels路径，但常见版本默认是和图片同目录或挂在labels子目录里，一定要去确认。

4. 模型训练：单条命令能跑通，但 mAP 不达标要看这些参数

4.1 YOLOv8 和 YOLOv5 的训练命令差异

数据集整理好后，训练这一步比想象中简单，因为它已经被官方封装成很成熟的命令行工具。YOLOv8 的典型训练命令是：

yolo detect train data=flower.yaml model=yolov8n.pt epochs=100 batch=16 imgsz=640 device=0

YOLOv5 的典型训练命令是：

python train.py --data flower.yaml --weights yolov5s.pt --epochs 100 --batch-size 16 --img 640 --device 0

差别主要在参数名上：YOLOv8 用model和imgsz，YOLOv5 用weights和img。如果你同时折腾两个版本，很容易在参数名上来回踩坑。我的建议是，刚开始只选一个版本，把训练命令写熟，再去看另一个版本的差异。

第一次训练时，可以用yolov8n.pt或yolov5s.pt做预训练权重，不要直接从头训练，也不要一上来就用最大的模型。预训练权重能让你少跑很多轮就得到不错的效果。如果数据集和预训练类别差异很大，也仍然建议用预训练权重做迁移学习，它学到的通用特征对花卉这种真实物体是有帮助的。

4.2 关键参数：epochs、batch、imgsz、device、workers

这几个参数直接影响训练速度、显存占用和最终效果。

epochs表示训练轮数。对于小规模数据集，100 轮基本够用，如果从预训练权重开始，50 轮也能看到明显效果。训练轮数太少会欠拟合，太多会过拟合。我判断训练是否结束，不是只看轮数，而是看验证集 loss 是否还在下降，下降不明显就可以停了。

batch-size决定每次送入 GPU 的图片数量。显存不足时优先降低它。但 batch 太小，训练收敛速度会慢，而且 BatchNorm 层的统计可能不稳定。如果显存只有 6GB，建议从 8 开始，跑一次看显存占用，再逐步调整。

imgsz是输入图片的尺寸。默认 640 适合大多数场景。如果你有很多小花朵，640 足够；如果图片里花非常小、非常密集，可以提高到 960 或 1280，但显存和训练时间会明显增加。反之，如果只是做一个演示系统，416 或 512 也能出效果，速度更快。

device指定训练设备，0表示第一块 GPU，cpu表示用 CPU。多人共用服务器时，要确认 GPU 显存没有被别人占用，否则一启动就 OOM。

workers表示数据加载的进程数。不要盲目调大，Windows 下 workers 超过 8 可能导致数据加载异常。可以先设为 4，如果训练时 CPU 还没有吃满，再往上调。

4.3 如何判断训练是否正常：loss、mAP、PR 曲线

训练过程中要盯的不是训练集 loss，而是验证集指标。YOLO 的输出目录里会保存results.csv或results.png，里面包含：

• train/box_loss
• train/cls_loss
• val/box_loss
• val/cls_loss
• metrics/precision
• metrics/recall
• metrics/mAP50
• metrics/mAP50-95

训练正常时，loss 整体下降，mAP 上升。如果验证集 loss 持续上升而训练集 loss 还在下降，说明过拟合了，可以提前停止或者加入更多数据增强。mAP50 在简单场景下达到 0.9 以上不算罕见，但在复杂花卉数据集上能稳定到 0.8 以上已经不错。mAP50-95 更低，而且提升更慢，这是正常现象。

如果你在意模型在“找得准不准”上的表现，要看 Precision；如果在意“找得全不全”，要看 Recall。具体到花卉检测，如果你希望识别出画面中大部分花，而不是漏掉，Recall 更重要；如果你希望每个识别结果都很可信，Precision 更重要。

4.4 训练时最常见的三类失败：显存溢出、NAN、训练发散

显存溢出一般报错是CUDA out of memory。解决顺序是：先减小 batch-size，再减小 imgsz，最后替换成更小的模型。不要一上来就加device=0还不够，还要确认没有其他进程占用显存。

训练时出现 loss 为 NAN，常见原因包括：学习率过大、梯度爆炸、数据里有异常值、模型或损失函数不兼容。先做这几件事：降低学习率，检查数据集标注是否有坐标越界，把batch-size调小。如果仍然 NAN，可以检查是否是预处理阶段除零错误，比如某些图片尺寸为空或标注文件为空。

训练发散的症状是 loss 不断上升或剧烈震荡，mAP 一直为 0。常见原因是数据集标签格式错误、类别数量不一致、或者学习率太大。不要急着改网络结构，先用一个小数据集跑一个短训练，比如 10 个 epoch，确认稳定后再放开。

5. 推理和模型导出：本地验证通过后，再考虑界面集成

5.1 单张图片、文件夹、视频和摄像头的推理验证

训练完成后，输出目录下会有best.pt和last.pt。best.pt是验证集上效果最好的权重，last.pt是最后一次迭代的结果。部署时优先使用best.pt。

在写 PySide6 界面之前，先用命令行验证推理结果。YOLOv8 的推理命令：

yolo detect predict model=runs/detect/train/weights/best.pt source=test.jpg conf=0.25 save=True

source可以是单张图片、文件夹路径、视频文件，甚至摄像头序号。conf是置信度阈值，低于这个值的检测框会被过滤掉。检测结果会保存在 runs/detect/predict 目录下。

预测时如果结果为空，先别急着怀疑模型。检查图片分辨率是否过小、花朵目标是否太小、conf阈值是否设置太高。你可以把conf降到 0.1 看能否输出大量候选框，如果还是什么都没有，重点查图片格式和模型输入通道。

摄像头推理在 YOLO 命令行里可以直接用摄像头序号，但一旦进了 PySide6 界面，就不建议再用命令行方式，而是要通过 Python API 加载模型并逐帧推理。

5.2 导出 ONNX 和 TorchScript 时要注意什么

如果只想在本地桌面系统里用.pt文件，不需要导出。但如果未来要考虑别的推理框架，比如 OpenCV DNN、ONNX Runtime，或者想对比不同推理引擎的速度，可以导出。YOLOv8 导出命令：

yolo export model=best.pt format=onnx dynamic=True

导出 ONNX 时有个容易踩的坑：opset版本和推理框架支持不一致，会导致某些算子不支持。如果用 ONNX Runtime 加载，可以先确认你的 onnxruntime 版本是较新的版本，再导出。导出后可以用onnxruntime写一个简单脚本验证输出张量形状。

TorchScript 导出对 PySide6 集成也有帮助，因为它不依赖ultralytics包，运行体积更小，推理速度更稳定。但 TorchScript 在不同 PyTorch 版本之间兼容性并不完美，所以如果环境固定，可以放心用；如果要在多环境部署，ONNX 更稳妥。

5.3 性能判据：FPS、单张耗时、模型大小

界面集成前，要给系统定几个性能目标，否则做完了也不知道算不算合格。

• 单张推理耗时：CPU 上 YOLOv8n 对 640x640 图片可能在 0.2 到 1 秒之间，GPU 可能在 10 到 50 毫秒。如果你的电脑配置较差，耗时高不奇怪。
• FPS：摄像头实时检测达到 15 FPS 以上，体验就比较流畅。低于 5 FPS 基本没法用。
• 模型大小：yolov8n.pt大约 6MB 左右，yolov8s.pt大约 22MB。如果你要打包给用户使用，模型越大，加载越慢，启动越慢。

需要注意的是，加载模型本身也有耗时。在 PySide6 界面里，最好启动时一次性加载模型，而不是每次选图片都重新加载。如果你把模型加载放在按钮点击事件里，用户会明显感觉到卡顿。

建议：第一次集成到界面时，先设置一个“模型加载中”的状态提示，不然用户点击按钮后长时间没有反馈，会以为程序崩溃了。

6. PySide6 界面设计：把模型封装成可用系统，重点在消息循环和线程

6.1 界面整体布局：选择图片、展示结果、显示日志

一个合格的花卉识别桌面系统，界面不需要很花哨，但必须让人能用。我建议核心布局采用左右结构或上下结构：

• 左侧是图片预览区：用来显示原始图片和识别后的结果图。
• 右侧是控制区：选择图片按钮、摄像头开启按钮、模型加载进度、识别结果列表。
• 底部或侧边是日志区：显示当前执行的步骤和异常信息。

用 PySide6 实现时，核心控件包括 QLabel 或 QGraphicsView 显示图片，QPushButton 触发操作，QTextEdit 显示日志，QComboBox 选择模型。界面代码不复杂，但要注意坐标转换：YOLO 输出的框坐标是归一化或原始像素坐标，显示到 QLabel 上时如果图片被缩放，需要把坐标也做对应缩放，不然框会画歪。

一个简单的方式是：先设置 QLabel 按比例缩放显示图片，然后将检测框坐标按缩放比例转换。具体比例是label_width / image_width和label_height / image_height。

6.2 模型加载和推理为什么必须放到 QThread 里

这是 PySide6 应用里最常见的卡死原因。如果你直接在按钮点击事件里调用模型推理，推理耗时会阻塞 Qt 的事件循环，界面会变成“无响应”状态。要解决这个问题，必须把耗时操作放到后台线程。

简单做法是创建QThread子类，把模型推理放进去，在主线程里通过信号接收结果。下面是一个简化示例：

import sys import cv2 from PySide6.QtCore import QThread, Signal from ultralytics import YOLO class InferenceThread(QThread): result_ready = Signal(object) error_occurred = Signal(str) def __init__(self, model_path, image_path, parent=None): super().__init__(parent) self.model_path = model_path self.image_path = image_path def run(self): try: model = YOLO(self.model_path) img = cv2.imread(self.image_path) results = model.predict(img, conf=0.25) self.result_ready.emit(results) except Exception as e: self.error_occurred.emit(str(e))

这个示例把模型加载也放在子线程里，好处是界面启动后可以继续交互。但要注意，如果反复创建和销毁线程，并且每次都重新加载模型，开销会很大。更好的方式是启动时先加载模型到内存，线程只负责推理，不负责加载模型。

正确做法是：在主程序初始化时把模型加载好，线程的run()只调用模型推理并发送结果。这样既避免卡界面，也避免模型重复加载。

6.3 在界面里显示 YOLO 检测结果：坐标框、类别名、置信度

预测结果results是ultralytics的 Results 对象，常见用法是拿到一个boxes数据，里面包含：

• boxes.xyxy：左上角和右下角坐标
• boxes.cls：类别索引
• boxes.conf：置信度

绘制结果有两种方式。第一种是直接用results[0].plot()，生成一张带框的图像，直接在 QLabel 里显示。它最简单，但只能在整块图上显示标签，不够灵活。第二种是自己遍历框，用 OpenCV 画矩形和文字，然后显示。这种方式更可控，可以自定义颜色、字体和标签。

我用得比较多的是第二种，因为可以过滤置信度阈值、改变标签措辞，而且可以把检测结果保存成结构化数据。如果只是演示，第一种足够。

6.4 摄像头实时检测和图片检测的处理差异

图片检测是单次推理，摄像头检测是连续多帧推理。实时处理时要注意几个问题：

• 摄像头帧率通常 30 FPS，但推理速度不一定跟得上。需要控制处理帧率，不要每一帧都推理，否则界面卡顿。我一般会隔一帧或两帧处理一次。
• 摄像头画面需要垂直翻转，否则画面左右反的，体验很怪。可以用cv2.flip(frame, 1)。
• 如果在子线程里做摄像头视频流，注意线程退出时要释放摄像头资源，否则下次打开摄像头会提示被占用。

摄像头检测的主循环是这样：

while self.capture.isOpened(): ret, frame = self.capture.read() if not ret: break frame = cv2.flip(frame, 1) results = self.model.predict(frame, conf=0.25) annotated_frame = results[0].plot() # 转换成 Qt 可显示的 QImage 再发送到主线程 self.result_ready.emit(annotated_frame)

注意model.predict默认可能返回一个结果列表，results[0]是当前帧的检测结果。处理视频时不要对每个结果都做show窗口操作，否则会和 PySide6 的消息循环冲突。

6.5 打包成 exe 的常见问题

桌面应用做完了，很多人想打包成 exe 发给别人用。PyInstaller 是常用工具，但 PySide6 和深度学习库打包通常会遇到几个问题：

• 打包体积很大，几百 MB 很正常。
• 缺少动态链接库，启动时报 DLL 找不到。
• 模型文件路径在打包后和源码中不同，导致加载失败。
• ultralytics内部有动态导入，PyInstaller 分析依赖时可能漏掉部分模块。

简单的应对措施：

1. 使用--collect-all ultralytics收集所有资源文件。
2. 把模型文件通过--add-data携带进去，并在代码中改成resource_path方式定位。
3. 打包后一定要在干净机器上测试，不要只在开发机跑。

如果你的项目是毕业设计，通常不需要打包成 exe，在 IDE 里能运行完整功能就已经满足要求。如果想打包，建议先打包一个最小测试版本，确认能启动后再加入模型和界面。

7. 常见问题排查：先看日志，再改参数，不要盲调

7.1 启动报错：torch 导入失败、PySide6 版本冲突

启动程序时最常见的错误是ModuleNotFoundError: No module named 'torch'或No module named 'PySide6'。这种问题通常是因为当前终端或 IDE 激活的项目环境不是安装依赖的环境。先检查pip list确认包的安装情况，再确认 IDE 解释器路径。

还有一类问题是torch和PySide6版本冲突，导致 Qt 动态库加载异常。可能的表现是：程序能启动，但打开摄像头时崩溃，或者点击按钮时提示线程错误。这种时候不要急着改代码，先确认虚拟环境里torch、opencv-python、PySide6是不是都用同一个环境安装的。如果你之前从源码安装了 opencv，后来又 pip 安装了 opencv-python，很容易发生底层库冲突。

7.2 训练卡住：数据加载、工作线程数、磁盘速度

训练开始时如果一直停留在Scanning或Downloading，或者进度条不动，先排查以下几项：

• 数据集路径是否包含中文或特殊字符，这会导致一些库在 Windows 下读取异常。
• 图片和标注文件是否存在，是否和数据划分路径一致。
• 磁盘剩余空间是否足够，训练过程会不断写入缓存和权重文件。
• workers是否设得过大，导致数据加载线程相互阻塞。可以先设为 0 试试。

如果数据量很大，磁盘读写速度也会影响训练。建议把数据集放到本地 SSD 上，不要放在网络盘或移动硬盘里。

7.3 检测效果差：输入尺寸、置信度阈值、NMS 阈值

检测结果不理想时，按顺序排查，不要一次改多个参数：

1. 先看原始输入图片的分辨率，如果图片非常小，物体边缘模糊，模型很难识别。
2. 把conf调低到 0.1，看是否有很多框。如果调低后能检出更多目标，说明原阈值太高。
3. 如果很多框重叠，调节 NMS 的 IoU 阈值，默认 0.45 是通用值，可以调到 0.5 或 0.6。
4. 如果仍然识别不出来，考虑训练时imgsz和推理时imgsz不一致的问题。训练用 640，推理却用 1280，模型可能不匹配。

7.4 界面卡死：大概率是主线程被推理占住了

界面点击后未响应，最常见的根因就是推理操作放在了主线程里。解决办法就是前面提到的 QThread，或者使用QTimer分步处理。还要注意，子线程里不能直接刷新界面控件，必须通过信号把数据传递到主线程，否则 Qt 会报“cross-thread”错误。

如果摄像头视频流在子线程里持续推理，同时主线程还在加载大图片，也可能出现界面卡顿。可以设置一个阈值，视频流每秒最多处理 15 帧，不处理的帧直接丢弃，只显示最新帧。

7.5 日志和输出目录管理：提前规划能省很多事

很多人在一个小项目里因为输出目录混乱浪费大量时间。训练输出、测试输出、界面日志都混在一起，最后连哪个 weight 是哪个数据集的都分不清。

我建议在项目根目录下建这几个子目录：

flower_project/ ├── dataset/ │ ├── images/ │ ├── labels/ │ └── data.yaml ├── runs/ │ ├── train/ │ └── detect/ ├── models/ │ └── best.pt ├── ui/ │ └── main_window.py └── logs/ └── app.log

这样训练结果、模型文件、日志记录都能对号入座。运行时把日志也写入文件，以后排错能直接看历史记录，不用靠记忆。

最后留几个我自己的实践建议

如果你打算花一周时间把这个系统做完整，我会建议这样排优先级：

第一，先把数据集和训练跑通。即使只有几百张图、几个类别，也要先把data.yaml和训练命令走通，拿到一个可用的best.pt。模型好不好是后续所有工作的基础。

第二，再写推理脚本。用命令行验证单张图片，确认模型能用，输出框和标签位置正确。这一步不需要界面，脚本越简单越好。

第三，最后才写 PySide6 界面。先把模型加载和推理放到线程里，再做图片显示和结果绘制，最后扩展摄像头。

第四，如果时间富余，再做打包和日志。打包不是必需项，但如果你想把系统给别人演示，打包能省去对方配置环境的痛苦。

这个项目真正落地时，最该盯住的不是功能列表，而是输入格式、资源占用和失败重试。数据格式错、线程卡死、模型路径找不到，这三个问题占了绝大多数调试时间。把每一步都验证清楚，整个系统会比预期顺利得多。