前阵子我把一个基于深度学习YOLOv11的食物检测系统完整做了一遍，从数据集整理、模型训练到登录注册界面和检测UI全部跑通。这里说的“YOLO数据集”不是某款现成的数据包，而是指YOLO格式的标注数据。整套系统最后包含Python项目源码、训练好的模型权重、可视化界面，能直接拿来做图像识别演示，也能在此基础上扩展成食堂结算、健康饮食记录这类应用。这篇文章把我实际做的时候的思路、参数和踩坑点完整写下来。如果你正在做目标检测相关课程设计、毕业设计，或者想给餐饮场景搭一个快速原型，这篇东西可以直接参考。1. 项目整体设计与功能拆解1.1 这个系统到底解决什么问题食物检测不是新鲜话题，但真正动手做的人往往会在“模型能跑”和“系统能用”之间卡很久。最常见的落地场景是食堂自助结算：盘子往摄像头底下一放，系统要同时识别出画面里有哪几种菜、每个菜在什么位置，再根据菜品单价自动计算金额。这和单纯给一张图打一个分类标签完全不一样，属于典型的目标检测问题，必须画框定位。也有很多人用它做健康饮食记录，拍一餐饭，自动识别出米饭、鸡肉、青菜，再换算成热量或营养元素。我做这套系统的目标很明确：不接支付、不做称重、不搞复杂部署，先把核心链路走通。用户打开系统后先登录或注册，进入主界面后可以选一张本地图片，也可以打开摄像头实时检测。YOLOv11负责输出每个检测框的类别、坐标和置信度，UI负责把结果画出来并展示成表格。这样做的好处是每个模块都能单独替换，后面想接价格表、营养数据库，只需要在识别结果后面加一个映射，不需要重写模型推理部分。对于正在做课程设计或毕设的人来说，这种“模型+UI+登录注册”的完整结构也很加分。很多教程只给一个训练脚本和一堆指标，评审老师看不到实际效果；而整套系统能现场演示，从注册登录到图像识别一气呵成，展示性和实用性都够。1.2 技术选型：为什么是YOLOv11而不是其他版本选YOLOv11而不是YOLOv5或YOLOv8，我考虑了三点。首先是速度和精度的平衡。YOLOv11在主干网络里用了更高效的特征提取模块，比如C3k2和C2PSA，整体计算量下降，特征表达反而更细腻。食物检测有个特点：很多类别外观接近，比如炒饭和炒面、不同做法的鸡肉，模型需要捕捉纹理和形状细节，而不是只看颜色。新模型在这一点上比旧版更有优势。其次是生态。YOLO生态库把训练、验证、导出和推理都封装成了命令行，几行就能跑起来。对非算法出身的开发者来说，不用手写网络结构和损失函数，只要把数据集整理成标准格式，就能得到一个可用的权重文件。这一点在项目开发里非常重要，能把精力省下来放到UI和业务逻辑上。第三个原因是部署灵活性。YOLOv11按参数规模分成n/s/m/l/x几个型号，我的需求用n或s就够。n模型在CPU上也能跑，s模型在普通显卡上很流畅，不需要为了演示买高性能设备。当然，如果你手头已经有一套YOLOv8的代码，也不是非得升级，但从做新项目角度，直接用新版本意味着后面支持周期更长，相关问题和教程也更多。1.3 功能模块一览我把系统拆成几个独立模块，职责划分如下：模块主要工作对应文件/资源模型训练数据集整理、YOLO格式转换、训练与验证train脚本、datasets/food.yaml检测核心加载权重、执行推理、返回检测框结果detector.py用户系统登录、注册、密码哈希、会话信息auth.py、login_window.py界面展示图片/摄像头检测、结果绘制与表格展示main_window.py数据资源训练图像、标注txt、类别定义、模型权重datasets/、weights/best.pt一开始我把所有代码塞在一个脚本里，后来发现一旦要调UI、改模型逻辑，就会互相拖累。比如摄像头画面卡了，你很难判断是模型推理慢，还是UI绘制阻塞。拆成模块后，我可以在不打开界面的情况下单独测试Detector类，用脚本跑一批图片对比速度和精度，确认没问题再接回界面。这个习惯建议从一开始就养成。2. YOLOv11核心原理与数据集准备2.1 YOLOv11相比前代的关键改进如果你只是调用接口，不一定要从头推导网络结构，但理解几个关键模块对调参和排查问题很有帮助。YOLOv11的backbone使用了C3k2结构，可以把它理解成一套轻量化的特征提取单元，能在保持通道信息交互的同时减少冗余计算。后面的C2PSA模块引入了注意力机制，让网络更关注图像中真正重要的区域。放到食物检测里，就是当画面里有餐盘、桌面、餐具这些背景时，模型会优先把注意力放在食物区域，减少误检。另一个重要的设计是anchor-free检测头。旧版YOLO需要预先聚类出一组锚框，模型基于锚框做回归；新版不再依赖固定锚框，而是直接预测目标中心与宽高。带来的直接好处是后处理更简单，小目标和密集目标的适应性更强。一盘子菜里往往同时有肉块、蔬菜、汤汁，目标大小差异很大，anchor-free更省心。YOLOv11还在不同尺度特征图上分别做预测，大目标在深层特征图检测，小目标在浅层特征图检测。这个设计对食物场景尤其关键，因为摄像头角度不同，同一道菜在画面里可能非常大，也可能只是角落里的一个小碗。多尺度预测让模型在不同距离下都不容易漏检。2.2 食物数据集：公开数据与自建标注的结合新手经常问：“哪里能下载YOLO数据集？”实际上“YOLO数据集”不是某个现成数据包的名字，而是一种标注格式。只要图片对应的txt文件满足YOLO规范，任何数据集都可以被训练流程使用。规范是：每张图片对应一个同名txt，每行表示一个目标，格式为“类别id 中心点x 中心点y 宽度 高度”，注意这里的坐标都是相对于图片宽度和高度的归一化值，取值在0到1之间。一个典型的目录结构如下：datasets/food/ ├── images/ │ ├── train/ │ │ ├── 001.jpg │ │ └── ... │ └── val/ │ ├── 101.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── 001.txt │ │ └── ... │ └── val/ │ ├── 101.txt │ └── ... └── food.yaml标注工具我推荐用图形化工具，比如LabelImg或者X-AnyLabeling。打开图片后用矩形框手动框出食物区域，软件会导出txt。这里有两个特别容易错的地方：一是类别ID必须从0开始，不能从1开始；二是如果某个类别在训练时排在names列表第一位，那它的ID就是0，推理时也要保持同样顺序，否则结果全部错位。数据来源上，我的做法是把公开食物图像和自己拍的照片混合起来。公开数据类别覆盖广，但拍摄场景和食堂不完全一样；自己拍的照片虽然数量少，但能覆盖真实灯光、餐盘样式、常见摆盘。建议每类目标至少准备200到500张，做十几个类别时总量不要低于两三千张。如果某些类别样本太少，识别效果会很差，优先补样本比换模型更有效。2.3 数据增强与训练参数设置食物场景和通用物体识别不太一样。食堂灯光偏暖、手机拍照有白平衡差异、菜品颜色会因为烹饪方式改变，这些都会让模型在实际使用中变差。所以训练时数据增强不是可有可无。训练流程默认会开启Mosaic增强，把四张图拼成一张训练，能提升模型对遮挡和小目标的鲁棒性。我还会保留HSV色域增强，随机改变色调、饱和度和亮度，用来模拟不同灯光环境。增强策略上，随机翻转对食物场景要小心。有些菜品有方向性，比如摆盘讲究的鱼，翻转后可能不太自然，但实际检测中影响不大，我一般还是开。还有一个值得说的是上下翻转，食物图片很少有倒着的，我会关掉上下翻转，只留左右翻转，避免模型学到不真实的方向特征。训练参数我建议从这几个值起步：imgsz=640：输入尺寸，太大训练慢，太小小目标容易丢。batch=16：显卡不够就降到8或4。epochs=100~150：数据量小训练100轮基本可以收敛。patience=20：验证指标连续20轮不提升就早停，省时间。optimizer=AdamW：收敛更稳，尤其适合迁移学习微调。3. 训练模型与效果调优3.1 训练环境准备与依赖安装训练部分我用的环境是Python虚拟环境加显卡，如果只有CPU也能跑，但训练时间会明显变长，建议先用小数据集验证流程。依赖其实不复杂，核心就这几个：ultralytics torch torchvision opencv-python PySide6 numpy用下面命令安装：pip install ultralytics torch torchvision opencv-python PySide6 numpy有个经验：先装PyTorch，再装ultralytics，最后装PySide6，顺序反过来偶尔会遇到Qt插件冲突。如果电脑是NVIDIA显卡，PyTorch建议装CUDA版本；没有显卡就装CPU版本，推理和界面演示不会受太大影响，只是训练慢。确认训练环境是否用了显卡，可以执行：python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'CPU')"如果输出第一项是False，说明PyTorch没装到CUDA版本，后续训练会非常慢，先解决环境再训练。3.2 训练脚本与关键参数说明训练前需要写一个数据配置文件food.yaml，内容大概是：path: datasets/food train: images/train val: images/val nc: 6 names: 0: rice 1: chicken 2: beef 3: vegetable 4: soup 5: noodle然后一条命令开始训练：yolo detect train data=food.yaml model=yolo11n.pt epochs=100 imgsz=640 batch=16 patience=20 project=outputmodel=yolo11n.pt表示加载官方预训练权重，不要在随机初始化下从零训练。食物检测虽然在通用数据集上没有对应任务，但预训练模型已经学会通用特征，迁移过来收敛速度快得多。patience=20是早停参数，验证集指标连续20轮没有提升就终止训练，避免无意义等待。训练日志里你会看到每一轮的box loss、cls loss、dfl loss，还有mAP50和mAP50-95。不要只盯着mAP50-95看，食物检测这种类别间相似度高的任务，mAP50能到0.80以上其实就很好用了。mAP50-95更严格，一般会低一些。如果mAP50不到0.6，优先检查数据集标注和类别划分，而不是急着换大模型。3.3 模型评估与过拟合排查训练结束后，在output/exp/weights/目录里会生成best.pt和last.pt。last.pt是最后一轮的权重，best.pt是验证集表现最好的权重，部署时用best.pt。想查看模型在验证集上的效果，可以执行：yolo detect val model=output/exp/weights/best.pt data=food.yaml会输出mAP、精度、召回率等指标，还会生成混淆矩阵图片。混淆矩阵能直观看到哪些类别容易互相混淆。比如我把“鸡肉”和“牛肉”分成了两类，如果样本里红烧鸡块和红烧牛肉外观很像，模型就会频繁混淆。解决办法有三个方向：增加这类样本数量、把容易混的类别合并成一个更大类，或者仔细检查错标样本。对我来说，检查错标样本往往最有效，有时候是标注框没框准，有时候是图像背景里带出了旁边菜的一部分。如果训练loss一直在降，但验证mAP不升甚至下降，就是过拟合。数据量小的时候尤其常见。我的建议是先减少训练轮数或提高patience，其次增加数据增强强度，最后再考虑加dropout。不要一上来就换更大模型，模型越大对数据量要求越高，小数据集上更容易过拟合。4. UI界面与登录注册模块实现4.1 界面技术栈选择：PySide6还是PyQt5界面部分我推荐PySide6，主要因为它是Qt官方维护的Python绑定，协议友好，更新跟得上Qt版本。PyQt5资料多、老项目多，但新项目从长期维护角度，选PySide6更省心。两者API非常接近，网上搜PyQt5教程基本也能参考，迁移成本不高。具体布局上，登录注册界面用QWidget或QDialog，主界面用QMainWindow。图像显示用QLabel加QPixmap，检测结果用QTableWidget。之所以不用OpenCV的imshow来显示结果，因为它没法做漂亮的控件布局，也没法和登录注册系统整合。用Qt的好处是能够把按钮、图片、表格都放在一个窗口里，交互体验接近成熟桌面软件。4.2 登录注册模块的设计与实现登录注册看起来简单，但有两个地方必须认真处理：数据库和密码存储。数据库我用Python自带的sqlite3，没有额外安装服务。启动时创建一张用户表，包含用户名、密码哈希、盐、创建时间。密码不能明文保存到数据库，这一点真不是小题大做。我用的是PBKDF2哈希加随机盐，原理是先给每个用户生成一个随机盐，把盐和密码一起做多次哈希运算，即使数据库泄露，攻击者也不能直接看到原始密码。核心代码大致是：import hashlib, os def hash_password(password: str) -> str: salt = os.urandom(16) digest = hashlib.pbkdf2_hmac( "sha256", password.encode("utf-8"), salt, 100_000 ) return salt.hex() + "$" + digest.hex() def verify_password(password: str, stored: str) -> bool: salt_hex, digest_hex = stored.split("$") salt = bytes.fromhex(salt_hex) digest = hashlib.pbkdf2_hmac( "sha256", password.encode("utf-8"), salt, 100_000 ) return digest.hex() == digest_hex登录逻辑就是根据用户名读取存储的哈希，再用用户输入的密码调用verify_password比对。注册界面要检查用户名是否重复、密码长度是否达标、两次输入是否一致。登录成功后把当前用户名传到主界面，显示成“当前用户：xxx”。这样比单独做权限系统简单，但演示和课程设计足够了。窗口切换的逻辑也不复杂，登录成功后创建主窗口并关闭自己：self.main_window = MainWindow(username) self.main_window.show() self.close()4.3 检测主界面与结果展示主界面我分成三块区域：顶部是操作按钮，中间大块是图像显示，右边是检测结果表格。点击“选择图片”后，通过文件对话框拿到图片路径，调用检测核心，再把检测结果画回图片。这里最容易犯的错误是在UI线程里直接跑模型。YOLOv11推理一次虽然只有几十到几百毫秒，但在图形界面里，这几十毫秒UI已经卡住了。处理办法是把推理放到QThread里，识别完成后通过信号把结果传回主线程。示意代码：class DetectThread(QThread): result_ready = Signal(object) def __init__(self, detector, image): super().__init__() self.detector = detector self.image = image def run(self): boxes = self.detector.predict(self.image) self.result_ready.emit(boxes)检测框拿到以后，用QPainter在原图上画矩形和标签，再更新到QLabel上。右侧表格同步写入类别和置信度：for i, box in enumerate(boxes): self.table.setItem(i, 0, QTableWidgetItem(class_names[box.cls])) self.table.setItem(i, 1, QTableWidgetItem(f"{box.conf:.2f}"))摄像头检测则用QTimer定时抓帧。有一点要注意，实时检测时不要把每一帧都完整预处理再叠加绘制，最好复用同一个Detector实例，避免反复加载模型。视频流如果逐帧推理太慢，可以隔一帧检测一次，上一帧的位置通过简单的跟踪逻辑延续到下一帧，流畅度会明显提升。5. 项目部署与常见问题排查5.1 如何快速跑通整个项目拿到源码后先看目录结构，我推荐这样组织：food_detection/ ├── app.py ├── detector.py ├── auth.py ├── login_window.py ├── main_window.py ├── requirements.txt ├── weights/ │ └── best.pt └── datasets/ └── food/requirements.txt内容建议固定版本，不要全部留空让环境乱装。我吃过亏，ultralytics版本一变，模型加载就有兼容问题。安装依赖后，直接用python app.py启动。app.py只做一件事：创建登录窗口，登录成功后创建主窗口。Detector类在初始化时加载weights/best.pt，如果你不想自己训练，拿到预训练权重放进去就能用。登录注册默认连接本地user.db，没有额外配置要求。想单独验证模型，可以写一个测试脚本：from detector import Detector import cv2 detector = Detector("weights/best.pt") image = cv2.imread("test.jpg") results = detector.predict(image) for box in results: print(box.cls, box.conf, box.xyxy)这样不打开UI也能快速看结果，排查问题更方便。建议项目里长期保留这个脚本，每次改完模型推理逻辑，先跑它再开界面。5.2 常见问题与解决方案速查实际跑项目时我遇到过的坑整理成一张表，你可以直接对照排查：现象可能原因解决办法加载模型报错ultralytics版本不一致用训练时的版本，或pip install -U ultralyticsCUDA out of memorybatch或imgsz太大调低batch，清空显存，换yolo11n界面卡死推理放在主线程用QThread把推理丢到后台摄像头黑屏或打不开摄像头索引不对或权限被占用依次试0、1，检查系统是否占用识别结果全部错位类别顺序训练前后不一致检查names列表顺序，保持0开始且不变val指标差但训练loss低过拟合减少epochs、增加数据增强、检查标注中文路径导致图片读不了OpenCV/Qt对中文路径不友好把项目路径改成纯英文第三行“界面卡死”是最常见的，新手几乎都会踩。我当时也是先写了同步推理，点击识别后窗口直接变白，几秒后才恢复。后来改成QThread加信号，问题立刻解决。第四行“类别顺序错位”也很隐蔽，因为模型权重里记住了训练时的类别ID，你在推理时如果改了names顺序，检测框还是那些框，但贴上去的标签全错了。5.3 避坑经验与个人体会做完这个项目，我最大的感受是：环境和工程习惯比模型算法更容易决定项目能不能交付。训练模型只花了不到半天，但调环境、调UI线程、处理中文路径、对齐类别顺序，花的时间远多于训练。所以一开始就建虚拟环境、固定依赖版本、目录用纯英文、路径写成相对路径，能省下大量时间。另一个经验是选择模型大小不要一味求大。我在CPU笔记本上测试过，YOLOv11n单张640图片推理大约0.3到0.6秒，YOLOv11s会更慢一些。如果只是给老师演示或者本地体验，n模型完全够用，而且体积小、部署方便。真要在食堂结算这种场景做实时检测，建议用s模型加GPU，或者做ONNX导出加速。这个系统后续想扩展也很自然，识别到类别ID以后映射到菜品价格表或营养表，就能变成结算台或饮食管理工具。我实际做得最多的还是换类别名、加数据、训新模型这套流程，把检测核心稳定下来后，其他功能都是锦上添花。如果你正准备做类似项目，建议按这个顺序推进：先跑通Detector单测，再做登录注册，最后接摄像头和UI。这样每一步出问题都能定位得很清楚。
前阵子我把一个基于深度学习YOLOv11的食物检测系统完整做了一遍，从数据集整理、模型训练到登录注册界面和检测UI全部跑通。这里说的“YOLO数据集”不是某款现成的数据包，而是指YOLO格式的标注数据。整套系统最后包含Python项目源码、训练好的模型权重、可视化界面，能直接拿来做图像识别演示，也能在此基础上扩展成食堂结算、健康饮食记录这类应用。这篇文章把我实际做的时候的思路、参数和踩坑点完整写下来。如果你正在做目标检测相关课程设计、毕业设计，或者想给餐饮场景搭一个快速原型，这篇东西可以直接参考。1. 项目整体设计与功能拆解1.1 这个系统到底解决什么问题食物检测不是新鲜话题，但真正动手做的人往往会在“模型能跑”和“系统能用”之间卡很久。最常见的落地场景是食堂自助结算：盘子往摄像头底下一放，系统要同时识别出画面里有哪几种菜、每个菜在什么位置，再根据菜品单价自动计算金额。这和单纯给一张图打一个分类标签完全不一样，属于典型的目标检测问题，必须画框定位。也有很多人用它做健康饮食记录，拍一餐饭，自动识别出米饭、鸡肉、青菜，再换算成热量或营养元素。我做这套系统的目标很明确：不接支付、不做称重、不搞复杂部署，先把核心链路走通。用户打开系统后先登录或注册，进入主界面后可以选一张本地图片，也可以打开摄像头实时检测。YOLOv11负责输出每个检测框的类别、坐标和置信度，UI负责把结果画出来并展示成表格。这样做的好处是每个模块都能单独替换，后面想接价格表、营养数据库，只需要在识别结果后面加一个映射，不需要重写模型推理部分。对于正在做课程设计或毕设的人来说，这种“模型+UI+登录注册”的完整结构也很加分。很多教程只给一个训练脚本和一堆指标，评审老师看不到实际效果；而整套系统能现场演示，从注册登录到图像识别一气呵成，展示性和实用性都够。1.2 技术选型：为什么是YOLOv11而不是其他版本选YOLOv11而不是YOLOv5或YOLOv8，我考虑了三点。首先是速度和精度的平衡。YOLOv11在主干网络里用了更高效的特征提取模块，比如C3k2和C2PSA，整体计算量下降，特征表达反而更细腻。食物检测有个特点：很多类别外观接近，比如炒饭和炒面、不同做法的鸡肉，模型需要捕捉纹理和形状细节，而不是只看颜色。新模型在这一点上比旧版更有优势。其次是生态。YOLO生态库把训练、验证、导出和推理都封装成了命令行，几行就能跑起来。对非算法出身的开发者来说，不用手写网络结构和损失函数，只要把数据集整理成标准格式，就能得到一个可用的权重文件。这一点在项目开发里非常重要，能把精力省下来放到UI和业务逻辑上。第三个原因是部署灵活性。YOLOv11按参数规模分成n/s/m/l/x几个型号，我的需求用n或s就够。n模型在CPU上也能跑，s模型在普通显卡上很流畅，不需要为了演示买高性能设备。当然，如果你手头已经有一套YOLOv8的代码，也不是非得升级，但从做新项目角度，直接用新版本意味着后面支持周期更长，相关问题和教程也更多。1.3 功能模块一览我把系统拆成几个独立模块，职责划分如下：模块主要工作对应文件/资源模型训练数据集整理、YOLO格式转换、训练与验证train脚本、datasets/food.yaml检测核心加载权重、执行推理、返回检测框结果detector.py用户系统登录、注册、密码哈希、会话信息auth.py、login_window.py界面展示图片/摄像头检测、结果绘制与表格展示main_window.py数据资源训练图像、标注txt、类别定义、模型权重datasets/、weights/best.pt一开始我把所有代码塞在一个脚本里，后来发现一旦要调UI、改模型逻辑，就会互相拖累。比如摄像头画面卡了，你很难判断是模型推理慢，还是UI绘制阻塞。拆成模块后，我可以在不打开界面的情况下单独测试Detector类，用脚本跑一批图片对比速度和精度，确认没问题再接回界面。这个习惯建议从一开始就养成。2. YOLOv11核心原理与数据集准备2.1 YOLOv11相比前代的关键改进如果你只是调用接口，不一定要从头推导网络结构，但理解几个关键模块对调参和排查问题很有帮助。YOLOv11的backbone使用了C3k2结构，可以把它理解成一套轻量化的特征提取单元，能在保持通道信息交互的同时减少冗余计算。后面的C2PSA模块引入了注意力机制，让网络更关注图像中真正重要的区域。放到食物检测里，就是当画面里有餐盘、桌面、餐具这些背景时，模型会优先把注意力放在食物区域，减少误检。另一个重要的设计是anchor-free检测头。旧版YOLO需要预先聚类出一组锚框，模型基于锚框做回归；新版不再依赖固定锚框，而是直接预测目标中心与宽高。带来的直接好处是后处理更简单，小目标和密集目标的适应性更强。一盘子菜里往往同时有肉块、蔬菜、汤汁，目标大小差异很大，anchor-free更省心。YOLOv11还在不同尺度特征图上分别做预测，大目标在深层特征图检测，小目标在浅层特征图检测。这个设计对食物场景尤其关键，因为摄像头角度不同，同一道菜在画面里可能非常大，也可能只是角落里的一个小碗。多尺度预测让模型在不同距离下都不容易漏检。2.2 食物数据集：公开数据与自建标注的结合新手经常问：“哪里能下载YOLO数据集？”实际上“YOLO数据集”不是某个现成数据包的名字，而是一种标注格式。只要图片对应的txt文件满足YOLO规范，任何数据集都可以被训练流程使用。规范是：每张图片对应一个同名txt，每行表示一个目标，格式为“类别id 中心点x 中心点y 宽度 高度”，注意这里的坐标都是相对于图片宽度和高度的归一化值，取值在0到1之间。一个典型的目录结构如下：datasets/food/ ├── images/ │ ├── train/ │ │ ├── 001.jpg │ │ └── ... │ └── val/ │ ├── 101.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── 001.txt │ │ └── ... │ └── val/ │ ├── 101.txt │ └── ... └── food.yaml标注工具我推荐用图形化工具，比如LabelImg或者X-AnyLabeling。打开图片后用矩形框手动框出食物区域，软件会导出txt。这里有两个特别容易错的地方：一是类别ID必须从0开始，不能从1开始；二是如果某个类别在训练时排在names列表第一位，那它的ID就是0，推理时也要保持同样顺序，否则结果全部错位。数据来源上，我的做法是把公开食物图像和自己拍的照片混合起来。公开数据类别覆盖广，但拍摄场景和食堂不完全一样；自己拍的照片虽然数量少，但能覆盖真实灯光、餐盘样式、常见摆盘。建议每类目标至少准备200到500张，做十几个类别时总量不要低于两三千张。如果某些类别样本太少，识别效果会很差，优先补样本比换模型更有效。2.3 数据增强与训练参数设置食物场景和通用物体识别不太一样。食堂灯光偏暖、手机拍照有白平衡差异、菜品颜色会因为烹饪方式改变，这些都会让模型在实际使用中变差。所以训练时数据增强不是可有可无。训练流程默认会开启Mosaic增强，把四张图拼成一张训练，能提升模型对遮挡和小目标的鲁棒性。我还会保留HSV色域增强，随机改变色调、饱和度和亮度，用来模拟不同灯光环境。增强策略上，随机翻转对食物场景要小心。有些菜品有方向性，比如摆盘讲究的鱼，翻转后可能不太自然，但实际检测中影响不大，我一般还是开。还有一个值得说的是上下翻转，食物图片很少有倒着的，我会关掉上下翻转，只留左右翻转，避免模型学到不真实的方向特征。训练参数我建议从这几个值起步：imgsz=640：输入尺寸，太大训练慢，太小小目标容易丢。batch=16：显卡不够就降到8或4。epochs=100~150：数据量小训练100轮基本可以收敛。patience=20：验证指标连续20轮不提升就早停，省时间。optimizer=AdamW：收敛更稳，尤其适合迁移学习微调。3. 训练模型与效果调优3.1 训练环境准备与依赖安装训练部分我用的环境是Python虚拟环境加显卡，如果只有CPU也能跑，但训练时间会明显变长，建议先用小数据集验证流程。依赖其实不复杂，核心就这几个：ultralytics torch torchvision opencv-python PySide6 numpy用下面命令安装：pip install ultralytics torch torchvision opencv-python PySide6 numpy有个经验：先装PyTorch，再装ultralytics，最后装PySide6，顺序反过来偶尔会遇到Qt插件冲突。如果电脑是NVIDIA显卡，PyTorch建议装CUDA版本；没有显卡就装CPU版本，推理和界面演示不会受太大影响，只是训练慢。确认训练环境是否用了显卡，可以执行：python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'CPU')"如果输出第一项是False，说明PyTorch没装到CUDA版本，后续训练会非常慢，先解决环境再训练。3.2 训练脚本与关键参数说明训练前需要写一个数据配置文件food.yaml，内容大概是：path: datasets/food train: images/train val: images/val nc: 6 names: 0: rice 1: chicken 2: beef 3: vegetable 4: soup 5: noodle然后一条命令开始训练：yolo detect train data=food.yaml model=yolo11n.pt epochs=100 imgsz=640 batch=16 patience=20 project=outputmodel=yolo11n.pt表示加载官方预训练权重，不要在随机初始化下从零训练。食物检测虽然在通用数据集上没有对应任务，但预训练模型已经学会通用特征，迁移过来收敛速度快得多。patience=20是早停参数，验证集指标连续20轮没有提升就终止训练，避免无意义等待。训练日志里你会看到每一轮的box loss、cls loss、dfl loss，还有mAP50和mAP50-95。不要只盯着mAP50-95看，食物检测这种类别间相似度高的任务，mAP50能到0.80以上其实就很好用了。mAP50-95更严格，一般会低一些。如果mAP50不到0.6，优先检查数据集标注和类别划分，而不是急着换大模型。3.3 模型评估与过拟合排查训练结束后，在output/exp/weights/目录里会生成best.pt和last.pt。last.pt是最后一轮的权重，best.pt是验证集表现最好的权重，部署时用best.pt。想查看模型在验证集上的效果，可以执行：yolo detect val model=output/exp/weights/best.pt data=food.yaml会输出mAP、精度、召回率等指标，还会生成混淆矩阵图片。混淆矩阵能直观看到哪些类别容易互相混淆。比如我把“鸡肉”和“牛肉”分成了两类，如果样本里红烧鸡块和红烧牛肉外观很像，模型就会频繁混淆。解决办法有三个方向：增加这类样本数量、把容易混的类别合并成一个更大类，或者仔细检查错标样本。对我来说，检查错标样本往往最有效，有时候是标注框没框准，有时候是图像背景里带出了旁边菜的一部分。如果训练loss一直在降，但验证mAP不升甚至下降，就是过拟合。数据量小的时候尤其常见。我的建议是先减少训练轮数或提高patience，其次增加数据增强强度，最后再考虑加dropout。不要一上来就换更大模型，模型越大对数据量要求越高，小数据集上更容易过拟合。4. UI界面与登录注册模块实现4.1 界面技术栈选择：PySide6还是PyQt5界面部分我推荐PySide6，主要因为它是Qt官方维护的Python绑定，协议友好，更新跟得上Qt版本。PyQt5资料多、老项目多，但新项目从长期维护角度，选PySide6更省心。两者API非常接近，网上搜PyQt5教程基本也能参考，迁移成本不高。具体布局上，登录注册界面用QWidget或QDialog，主界面用QMainWindow。图像显示用QLabel加QPixmap，检测结果用QTableWidget。之所以不用OpenCV的imshow来显示结果，因为它没法做漂亮的控件布局，也没法和登录注册系统整合。用Qt的好处是能够把按钮、图片、表格都放在一个窗口里，交互体验接近成熟桌面软件。4.2 登录注册模块的设计与实现登录注册看起来简单，但有两个地方必须认真处理：数据库和密码存储。数据库我用Python自带的sqlite3，没有额外安装服务。启动时创建一张用户表，包含用户名、密码哈希、盐、创建时间。密码不能明文保存到数据库，这一点真不是小题大做。我用的是PBKDF2哈希加随机盐，原理是先给每个用户生成一个随机盐，把盐和密码一起做多次哈希运算，即使数据库泄露，攻击者也不能直接看到原始密码。核心代码大致是：import hashlib, os def hash_password(password: str) -> str: salt = os.urandom(16) digest = hashlib.pbkdf2_hmac( "sha256", password.encode("utf-8"), salt, 100_000 ) return salt.hex() + "$" + digest.hex() def verify_password(password: str, stored: str) -> bool: salt_hex, digest_hex = stored.split("$") salt = bytes.fromhex(salt_hex) digest = hashlib.pbkdf2_hmac( "sha256", password.encode("utf-8"), salt, 100_000 ) return digest.hex() == digest_hex登录逻辑就是根据用户名读取存储的哈希，再用用户输入的密码调用verify_password比对。注册界面要检查用户名是否重复、密码长度是否达标、两次输入是否一致。登录成功后把当前用户名传到主界面，显示成“当前用户：xxx”。这样比单独做权限系统简单，但演示和课程设计足够了。窗口切换的逻辑也不复杂，登录成功后创建主窗口并关闭自己：self.main_window = MainWindow(username) self.main_window.show() self.close()4.3 检测主界面与结果展示主界面我分成三块区域：顶部是操作按钮，中间大块是图像显示，右边是检测结果表格。点击“选择图片”后，通过文件对话框拿到图片路径，调用检测核心，再把检测结果画回图片。这里最容易犯的错误是在UI线程里直接跑模型。YOLOv11推理一次虽然只有几十到几百毫秒，但在图形界面里，这几十毫秒UI已经卡住了。处理办法是把推理放到QThread里，识别完成后通过信号把结果传回主线程。示意代码：class DetectThread(QThread): result_ready = Signal(object) def __init__(self, detector, image): super().__init__() self.detector = detector self.image = image def run(self): boxes = self.detector.predict(self.image) self.result_ready.emit(boxes)检测框拿到以后，用QPainter在原图上画矩形和标签，再更新到QLabel上。右侧表格同步写入类别和置信度：for i, box in enumerate(boxes): self.table.setItem(i, 0, QTableWidgetItem(class_names[box.cls])) self.table.setItem(i, 1, QTableWidgetItem(f"{box.conf:.2f}"))摄像头检测则用QTimer定时抓帧。有一点要注意，实时检测时不要把每一帧都完整预处理再叠加绘制，最好复用同一个Detector实例，避免反复加载模型。视频流如果逐帧推理太慢，可以隔一帧检测一次，上一帧的位置通过简单的跟踪逻辑延续到下一帧，流畅度会明显提升。5. 项目部署与常见问题排查5.1 如何快速跑通整个项目拿到源码后先看目录结构，我推荐这样组织：food_detection/ ├── app.py ├── detector.py ├── auth.py ├── login_window.py ├── main_window.py ├── requirements.txt ├── weights/ │ └── best.pt └── datasets/ └── food/requirements.txt内容建议固定版本，不要全部留空让环境乱装。我吃过亏，ultralytics版本一变，模型加载就有兼容问题。安装依赖后，直接用python app.py启动。app.py只做一件事：创建登录窗口，登录成功后创建主窗口。Detector类在初始化时加载weights/best.pt，如果你不想自己训练，拿到预训练权重放进去就能用。登录注册默认连接本地user.db，没有额外配置要求。想单独验证模型，可以写一个测试脚本：from detector import Detector import cv2 detector = Detector("weights/best.pt") image = cv2.imread("test.jpg") results = detector.predict(image) for box in results: print(box.cls, box.conf, box.xyxy)这样不打开UI也能快速看结果，排查问题更方便。建议项目里长期保留这个脚本，每次改完模型推理逻辑，先跑它再开界面。5.2 常见问题与解决方案速查实际跑项目时我遇到过的坑整理成一张表，你可以直接对照排查：现象可能原因解决办法加载模型报错ultralytics版本不一致用训练时的版本，或pip install -U ultralyticsCUDA out of memorybatch或imgsz太大调低batch，清空显存，换yolo11n界面卡死推理放在主线程用QThread把推理丢到后台摄像头黑屏或打不开摄像头索引不对或权限被占用依次试0、1，检查系统是否占用识别结果全部错位类别顺序训练前后不一致检查names列表顺序，保持0开始且不变val指标差但训练loss低过拟合减少epochs、增加数据增强、检查标注中文路径导致图片读不了OpenCV/Qt对中文路径不友好把项目路径改成纯英文第三行“界面卡死”是最常见的，新手几乎都会踩。我当时也是先写了同步推理，点击识别后窗口直接变白，几秒后才恢复。后来改成QThread加信号，问题立刻解决。第四行“类别顺序错位”也很隐蔽，因为模型权重里记住了训练时的类别ID，你在推理时如果改了names顺序，检测框还是那些框，但贴上去的标签全错了。5.3 避坑经验与个人体会做完这个项目，我最大的感受是：环境和工程习惯比模型算法更容易决定项目能不能交付。训练模型只花了不到半天，但调环境、调UI线程、处理中文路径、对齐类别顺序，花的时间远多于训练。所以一开始就建虚拟环境、固定依赖版本、目录用纯英文、路径写成相对路径，能省下大量时间。另一个经验是选择模型大小不要一味求大。我在CPU笔记本上测试过，YOLOv11n单张640图片推理大约0.3到0.6秒，YOLOv11s会更慢一些。如果只是给老师演示或者本地体验，n模型完全够用，而且体积小、部署方便。真要在食堂结算这种场景做实时检测，建议用s模型加GPU，或者做ONNX导出加速。这个系统后续想扩展也很自然，识别到类别ID以后映射到菜品价格表或营养表，就能变成结算台或饮食管理工具。我实际做得最多的还是换类别名、加数据、训新模型这套流程，把检测核心稳定下来后，其他功能都是锦上添花。如果你正准备做类似项目，建议按这个顺序推进：先跑通Detector单测，再做登录注册，最后接摄像头和UI。这样每一步出问题都能定位得很清楚。