YOLOv8鸡蛋检测系统：从数据集制作到Web部署全流程

1. 为什么是鸡蛋检测：养殖场景里的真实痛点

先说个场景。某养殖基地每天清晨要统计产蛋量，过去的方法是人进鸡舍，一板一板地数，或者按托盘重量估算。数得快的一小时能清点两三千枚，数完腰酸背痛，回头报表里还经常对不上账——漏数、重数、坏蛋混进去，全是问题。后来我接到这个项目，要求就一句话：能不能用摄像头自动数清楚鸡蛋，顺便把明显破损的挑出来。

鸡蛋检测这件事，听起来比行人检测、车辆检测简单，毕竟目标形态很统一，圆滚滚、颜色偏暖黄。但真正动手做才发现，它有一堆属于自己的坑：鸡蛋之间经常紧挨着甚至堆叠，光照一变颜色就飘，不同品系的蛋大小差异明显，再加上传送带上的滚动模糊，小目标密集排列的场景比比皆是。用传统图像处理做，阈值分割、霍夫圆检测，在实验室几张图上跑得挺好，一到现场就被打回原形。

所以最终方案选了YOLOv8。原因不复杂：第一，它是当前目标检测里开箱即用体验最好的框架之一，训练、验证、导出一条龙，对新手极其友好；第二，模型体积和精度之间的平衡很灵活，从nano到x系列可以按设备算力选；第三，社区资料多，后期做改进和部署都有现成路径可以抄。

我做的这套鸡蛋检测系统，包含完整源码、标注好的数据集、一键训练脚本、70多套改进创新点，以及Web前端展示页面。整条链路从数据到部署都是通的。这篇文章就把我从零到一的全过程拆开讲：数据怎么采、标注怎么控质量、训练脚本怎么设计、改进点怎么选、前端怎么接、坑都在哪里。无论你是做毕业设计、横向项目，还是想自己复现一套完整的目标检测落地流程，都可以照着走一遍。

顺便说一下，这套东西的定位不是"跑通demo就算完"，而是能真正应对养殖现场的复杂情况。后面我会把mAP、召回率、前向推理速度这些指标的具体表现和调整过程都写出来，方便你对照自己的项目做取舍。

2. 数据集制作：标注质量决定模型上限

2.1 图像采集与数量规划

很多人在这一步会犯一个毛病：觉得标注太费劲，先拍200张图标注完就开训。结果模型在测试集上看起来还行，一到新场景就"失忆"。鸡蛋检测虽然类别单一，但场景多样性一点不能少。

我的实践经验是，核心训练集至少准备800到1500张真实场景图，每张图里鸡蛋数量从几枚到几十枚不等。采集的时候要刻意覆盖这几种变化：

• 光照变化：鸡舍白炽灯、自然光、传送带补光灯，不同色温都要有。鸡蛋表面有高光反射，中午和傍晚拍出来的颜色差异非常大。
• 密度变化：既要拍散落稀疏的蛋，也要拍堆叠在一起的蛋。堆叠场景是训练的重点难点。
• 视角变化：俯拍为主，但也要有一些侧视角和远近不同的尺度。
• 蛋的种类：褐壳、白壳、粉壳都收一些，大小蛋分开标注，别让模型只认某一类。

如果你是从零采集，手机或者普通工业相机就够了，分辨率至少720p以上。要注意的是，训练时YOLOv8会把图像统一缩放到640×640，原图里的鸡蛋如果太小（小于16×16像素），学习特征会非常吃力。因此拍摄时尽量让鸡蛋在画面里占据一定像素面积，必要时分区域拍摄后再拼接。

2.2 标注工具与YOLO格式

标注工具用LabelImg这类开源工具就行，画矩形框，导出为YOLO格式的txt文件。每张图片对应一个同名txt，里面每一行是一个目标：

class_id x_center y_center width height

需要注意的是，四个坐标值全部是归一化的，除以图片宽高之后的小数，范围0到1。例如一张1920×1080的图里，某个鸡蛋框左上角在(480, 270)，宽高为(120, 120)，那么对应的txt内容就是：

0 0.28125 0.3125 0.0625 0.1111

这个格式是YOLOv8训练时默认读取的格式，不需要额外转换脚本。标注完成后，记得抽查一遍txt文件是否和图片一一对应，文件名前缀必须完全一致（比如egg_001.jpg对应egg_001.txt），大小写都不能错。

2.3 鸡蛋场景的标注难点

单类别目标看起来简单，但鸡蛋标注比多类别项目更考验一致性。我踩过的坑主要有三个：

第一是紧挨着的鸡蛋怎么框。两个蛋靠在一起，边界框是各画各的，还是合并成一个？答案永远是各画各的。如果合并，模型会学到"两枚靠近的蛋等于一个目标"，后处理时极难拆开。标注时框可以稍微包含一点相邻蛋的边缘，但不能把两个蛋吞进同一个框。

第二是高光区域要不要避开框。鸡蛋表面有弧形高光，如果框贴得太死，框内会包含一块很亮的区域，模型可能错误地学习"高光是鸡蛋的一部分"。解决办法是框沿蛋身轮廓画，稍微留出2到3像素的余量，让高光区域处于框内但不贴边。

第三是遮挡蛋怎么标。堆叠场景中，被挡住一半的鸡蛋要不要标？我建议标注，但只标可见部分的边界框，不要凭想象把被遮挡部分也包进去。这样模型学到的反而是"可见即目标"，配合NMS能够处理大部分部分遮挡场景。完全不标的后果是模型在遮挡场景里漏检率飙升。

2.4 数据划分与增强策略

划分标准我推荐8:1:1，训练集占八成，验证集和测试集各一成。划分时按目录拆，不要随机从全集中挑，否则会出现同一批连续拍摄的强相关图片同时落到训练集和测试集，导致测试指标虚高。

增强方面，YOLOv8自带的训练配置里默认开启了Mosaic和MixUp等策略，对鸡蛋这类小目标密集场景很有用。但我建议调整两个参数：Mosaic开启概率保持默认0.5以上，因为Mosaic会把四张图拼在一起，间接增加了单图中小目标的密度，非常契合传送带上鸡蛋密集排列的实际情况；而MixUp可以关掉或降到0.1左右，因为鸡蛋目标太相似，MixUp容易产生"半透明叠加"的模糊目标，对小目标学习反而不利。

自制数据集时还可以补充两类针对性增强：随机色温和亮度扰动，模拟鸡舍不同时段的光照；以及轻微随机旋转和透视变换，模拟相机安装角度偏差。这些在自定义数据加载器里加几行代码就能实现，实测能显著提升模型的泛化能力。

3. 一键训练脚本：核心配置与运行细节

3.1 工程目录结构

拿到整套源码后，第一件事是看目录结构。我的工程按下面的方式组织，清爽且不容易出错：

egg_detection/ ├── datasets/ │ ├── egg_dataset/ │ │ ├── images/ │ │ │ ├── train/ │ │ │ └── val/ │ │ └── labels/ │ │ ├── train/ │ │ └── val/ ├── train.py ├── data.yaml ├── requirements.txt ├── export_onnx.py ├── webapp/ │ ├── main.py │ ├── templates/ │ │ └── index.html │ └── static/ └── runs/

最关键的一条：images目录和labels目录必须在同一级，且train和val子目录名字完全一致。YOLOv8读取标注时，就是按照图片路径把"images"替换成"labels"来找对应txt文件的。如果你的目录结构是"labels放在datasets根目录下"，训练时会直接报"Found no labels"。

3.2 data.yaml配置文件

训练前需要准备一个data.yaml，内容很简单：

path: ./datasets/egg_dataset train: images/train val: images/val nc: 1 names: 0: egg

这里有个容易忽略的细节：path字段可以写绝对路径，也可以写相对于当前执行目录的相对路径。如果你用IDE运行而不是命令行，工作目录经常不在项目根目录，导致相对路径解析失败。我习惯在train.py开头加一行os.chdir(os.path.dirname(os.path.abspath(__file__)))，强制把工作目录切到脚本所在目录，彻底绕开这个问题。

3.3 一键训练脚本设计

所谓"一键训练"，核心就是把所有超参数通过argparse暴露出去，同时提供合理的默认值。脚本大体框架如下：

import os import argparse os.chdir(os.path.dirname(os.path.abspath(__file__))) def parse_args(): parser = argparse.ArgumentParser() parser.add_argument("--data", type=str, default="data.yaml") parser.add_argument("--weights", type=str, default="yolov8n.pt") parser.add_argument("--epochs", type=int, default=200) parser.add_argument("--batch", type=int, default=16) parser.add_argument("--imgsz", type=int, default=640) parser.add_argument("--device", type=str, default="0") parser.add_argument("--workers", type=int, default=8) return parser.parse_args() if __name__ == "__main__": args = parse_args() from ultralytics import YOLO model = YOLO(args.weights) model.train( data=args.data, epochs=args.epochs, batch=args.batch, imgsz=args.imgsz, device=args.device, workers=args.workers, patience=30, save_period=10, pretrained=True, optimizer="AdamW", lr0=0.001, cos_lr=True, amp=True, project="runs", name="egg_exp", )

这样设计的好处是，训练时只需要一条命令：

python train.py --epochs 200 --batch 16 --imgsz 640

不需要改任何源码。如果你只想快速验证流程，把--weights换成yolov8n.pt，--epochs降到50，十几分钟就能看结果。

3.4 关键超参怎么定

我把常用的超参数选型和理由整理成了一张表，方便你直接对照：

另外要说一下预训练权重的问题。YOLOv8n.pt是在COCO上预训练过的，虽然COCO里没有"鸡蛋"这个类别，但底层卷积层已经学会了通用纹理、边缘、形状特征。迁移学习后，哪怕只有几百张标注图，也能很快收敛。如果你的场景非常特殊（比如红外图像），那就不适合用COCO预训练，改为from scratch训练，epochs翻倍。

3.5 训练结果怎么看

训练结束后，runs目录下会生成results.csv和一堆曲线图。我重点盯四个指标：mAP50、mAP50-95、Precision和Recall。

鸡蛋检测是单类别任务，mAP50一般能到0.98以上才算合格，mAP50-95到0.85以上比较理想。如果mAP50很高但mAP50-95明显偏低，说明大目标检测好、小目标或边缘目标差，需要检查是不是训练图里鸡蛋普遍偏小，或者标注框和实际边缘偏差大。

Precision和Recall这对指标要结合起来看。Precision高Recall低，说明模型"挑食"，只检出最像鸡蛋的目标，容易漏检遮挡蛋；Precision低Recall高，说明模型"激进"，把鸡舍地上的杂物、阴影都当成鸡蛋。理想的组合是两者都大于0.95，这也是我做NMS阈值和置信度阈值调优时的主要依据。

4. 70+改进创新点：按模块拆解与实战筛选

4.1 "全家桶"里到底有什么

标题里的70+改进创新点，有的人看了觉得是噱头，但实际拆开来，都是这几年目标检测领域被反复验证过的经典模块。我把它们按模块归类，便于理解：

这些改进点不是随便堆上去就行的。我自己的经验是，最多组合三到四个模块，而且要分阶段加，每加一个都做对照实验。

4.2 针对鸡蛋场景的推荐组合

鸡蛋检测的特点是：目标纹理简单、颜色单一、场景密集、存在遮挡。基于这个特点，我的推荐组合是：

• 注意力用EMA或CA。这两种注意力对位置信息敏感，特别适合"鸡蛋在传送带上排列但背景是网格"的场景，能帮模型区分鸡蛋和网格阴影。
• Neck端加BiFPN。鸡蛋尺度变化不大，但密度大，BiFPN的双向融合能保留更多浅层细节，对小目标密集区域友好。
• 损失函数换成WIoU。鸡蛋标注中人工难免有框不精确的情况，WIoU对低质量标注的抗干扰能力比原始CIoU好，收敛也更稳。

这三者叠加，我在自己的数据集上做过测试：baseline的mAP50是0.971，加上EMA后到0.982，再加BiFPN到0.988，最后换WIoU到0.991。每一步提升都不大，但累积起来，模型在遮挡区域的漏检率明显下降。

4.3 消融实验怎么做

如果你想靠这套系统"发刊"，消融实验是绕不开的。思路很简单：以baseline为起点，每次只加一个改进模块，记录指标变化。最终呈现这样一张表：

这里有个经验：如果你的目标是发刊，不要只报mAP的涨跌，还要报参数量和推理耗时的变化，审稿人最在意"涨点是不是靠堆参数量换来的"。

4.4 组合改进的三个注意点

第一，别把注意力模块串成串。SE加CBAM再加CA，听起来是强强联合，实际很多通道注意力存在功能重叠，算力翻倍但精度纹丝不动。第二，改完模块后要重新跑一遍全部训练轮数，不要用baseline的训练曲线直接套。第三，改进模块和预训练权重有兼容性问题，比如换了Backbone，原本的COCO预训练权重就不能用了，必须从头训练，训练成本会显著上升。

我的建议是：先把baseline跑到最优，确认数据没有硬伤，再上改进模块。很多人一上来就堆改进，结果baseline都跑不明白，后面做任何消融都没有参照。

5. Web前端展示：从模型推理到可视化页面

5.1 整体架构设计

整套Web展示部分分为三层：前端页面负责交互和画框，后端服务负责接收图片并调用模型推理，模型层负责真正的目标检测。我用的是FastAPI作为后端框架，推理用ONNX Runtime，前端是原生的HTML加Canvas。

选FastAPI而不是Flask，是因为它天生支持异步，同时处理多个上传请求不会阻塞，而且自带接口文档，调试方便。如果你不熟悉FastAPI，Flask也完全够用，但并发上传时会卡，需要额外配多线程。

5.2 模型导出ONNX

训练好的PyTorch权重不能直接被Web后端调用（除非你把整个PyTorch环境都装进服务，但这样依赖太重）。标准做法是导出ONNX格式：

yolo export model=runs/egg_exp/weights/best.pt format=onnx opset=12 simplify=True

导出后得到一个best.onnx文件，几MB到十几MB不等，取决于你用的是n、s还是m系列。ONNX Runtime在CPU上跑也能保持不错的推理速度，不需要GPU。

如果你要部署到NVIDIA显卡上追求极致速度，下一步可以再转TensorRT，但ONNX已经是跨平台通用格式，Web项目里完全够用。

5.3 后端推理服务

后端代码很简洁，核心就一个接口：

from fastapi import FastAPI, File, UploadFile from fastapi.responses import JSONResponse import numpy as np import onnxruntime as ort import cv2 app = FastAPI() session = ort.InferenceSession("best.onnx", providers=["CPUExecutionProvider"]) def preprocess(image): img = cv2.resize(image, (640, 640)) img = img[:, :, ::-1].transpose(2, 0, 1) # BGR->RGB, HWC->CHW img = np.ascontiguousarray(img, dtype=np.float32) / 255.0 img = img[None, :, :, :] return img def postprocess(outputs, conf_thres=0.5, iou_thres=0.45): boxes = outputs[0][0] # shape (N, 6): x1, y1, x2, y2, conf, cls keep = boxes[boxes[:, 4] >= conf_thres] # 这里省略NMS实现，可直接调用cv2.dnn.NMSBoxes return keep @app.post("/predict") async def predict(file: UploadFile = File(...)): data = await file.read() np_arr = np.frombuffer(data, np.uint8) image = cv2.imdecode(np_arr, cv2.IMREAD_COLOR) input_tensor = preprocess(image) outputs = session.run(None, {session.get_inputs()[0].name: input_tensor}) dets = postprocess(outputs) return JSONResponse(content={"boxes": dets.tolist()})

这段代码里有几个关键细节：ONNX模型输入输出名要通过session.get_inputs()[0].name动态获取，不要硬编码，因为不同导出方式名字可能不同；预处理时颜色通道顺序必须和训练时一致，YOLOv8训练用的是RGB，而你用cv2读图默认是BGR，不转的话检测准确率会大幅下降。

5.4 前端页面与画框

前端页面我用的是单文件HTML加Canvas。用户上传图片后，通过fetch把图片POST到/predict，拿到返回的框坐标后，在Canvas上绘制矩形框和置信度标签。

核心画框逻辑如下：

async function detect() { const fileInput = document.getElementById("imageInput"); const file = fileInput.files[0]; const formData = new FormData(); formData.append("file", file); const resp = await fetch("/predict", { method: "POST", body: formData }); const data = await resp.json(); const canvas = document.getElementById("resultCanvas"); const ctx = canvas.getContext("2d"); const img = new Image(); img.onload = () => { canvas.width = img.width; canvas.height = img.height; ctx.drawImage(img, 0, 0); for (const box of data.boxes) { ctx.strokeStyle = "#00ff00"; ctx.lineWidth = 3; ctx.strokeRect(box[0], box[1], box[2] - box[0], box[3] - box[1]); ctx.fillStyle = "#00ff00"; ctx.font = "20px sans-serif"; ctx.fillText(`egg ${box[4].toFixed(2)}`, box[0], box[1] - 5); } }; img.src = URL.createObjectURL(file); }

这里要注意坐标缩放问题。模型在640×640下预测的坐标，需要按原图宽高等比映射回原始分辨率，否则画框位置会偏移。最简单的做法是后端返回归一化的中心点坐标和宽高，前端拿到后乘以画布实际尺寸。

5.5 摄像头实时检测

除了图片上传，我还做了摄像头实时检测模式。浏览器通过getUserMedia获取摄像头画面，每隔100毫秒截一帧发送到后端，后端推理完把框返回，前端在Canvas上实时绘制。实际效果是每秒10帧左右的检测速度，在本地网络部署下已经足够流畅。

实时模式需要特别注意帧率控制和画面卡顿问题。100毫秒是经验值——太频繁会产生积压，后端处理不过来；太稀疏看起来像幻灯片。另外，如果摄像头是俯拍传送带，建议前端先做个ROI区域截取，只把传送带所在的画面区域送去检测，既减少背景误检，又降低每帧传输数据量。

6. 踩坑实录：训练与部署中的高频问题排查

6.1 路径与标签不匹配

这是训练阶段遇到最多的报错，没有之一。现象是控制台打印"Found no labels"，或者训练正常启动但损失值一直不降。排查链路是：

• 检查images和labels目录是否在同一级；
• 检查train和val目录名称是否完全一致；
• 检查每个图片名和txt名是否完全对应，比如IMG_20250101_123456.jpg对应的必须是IMG_20250101_123456.txt，不能多空格、不能改后缀；
• 检查txt内容是否为5列格式（类别、x中心、y中心、宽、高），类别ID是否在data.yaml的nc范围内。

如果这些都没问题，再检查txt内容是否包含非法坐标——比如归一化后width或height大于1，说明标注工具输出的绝对像素值没除以宽高，这就是标注脚本的问题了。

6.2 训练时显存溢出

显存溢出的报错一般是CUDA out of memory。我的排查顺序是先降batch，从16降到8再到4，如果还溢出，把imgsz从640降到512。但要注意，imgsz降到512后模型精度会明显下降，所以降batch是首选。

另一个容易被忽略的点是workers参数。workers设太高，多个数据加载进程同时读取图片，CPU和内存会被打满，同样表现为训练中断。一般8核心CPU配4到6个workers就够。

如果你用的是公司显存较小的机器，还可以开启梯度累积，用小batch多步累加模拟大batch的效果。YOLOv8里可以用accumulate参数控制，相当于把有效batch size放大到batch×accumulate。

6.3 mAP高但实测效果差

这是最让人头大的问题。模型在验证集上mAP50到0.98，结果拿到鸡舍现场一测，传送带上的蛋漏检一大半。我排查后发现原因有三类：

第一，验证集和训练集同源。如果你划分数据时随机抽了10%做验证，而这10%图片和训练集来自同一天同一机位拍摄，那验证效果天然虚高。解决方法是按时间段划分：用前几天的图训练，后几天的图验证。第二，现场置信度阈值没调。训练时的最优置信度阈值是0.5左右，但现场画面更复杂，需要把阈值调到0.3甚至0.25，召回率才会上来。第三，NMS的IoU阈值太严，密集蛋框重叠时被误删。我实测把NMS的IoU阈值从0.45调到0.5，密集场景的漏检率能下降好几个百分点。

6.4 部署推理速度慢

ONNX Runtime在CPU上跑YOLOv8s，一张640×640的图大约需要60到120毫秒，看起来不慢，但如果前端实时检测每秒传10帧，后端就吃不消了。我的优化路径是：

• 模型从s换到n，推理时间直接减半，精度在鸡蛋场景几乎不掉；
• 导出ONNX时开启简化模式，去掉冗余计算节点；
• 后端用intra_op_num_threads和inter_op_num_threads调整线程数，默认线程数未必是最优的；
• 前端帧率从10帧降到5帧，传送带鸡蛋移动速度没那么快，5帧完全够用。

如果你有GPU，最彻底的方案是转TensorRT，但配置复杂度会上升一个台阶，建议先确认ONNX方案的延迟是否真的成为瓶颈，再决定要不要上。

6.5 密集堆叠蛋的漏检与误检

鸡蛋堆叠是检测系统在真实场景中最难处理的情况。被压住半个的蛋，模型有时会给出置信度很低的框，而被蛋影覆盖的网格线又容易被误判为蛋。我做了三件事来缓解：

一是训练数据里刻意增加了堆叠蛋的占比，让这类场景在训练集中占到三成以上，模型对"部分可见"的蛋更敏感。二是后处理时降低置信度阈值到0.25，然后用WBF（加权框融合）代替普通NMS，对同一个鸡蛋的多个低置信度检测框做融合，能有效提升密集场景的精确率。三是在前端展示时增加一个"密度模式"，检测到每张图超过30个框时自动开启分块检测，把画面切成四块分别推理再合并结果，实测每块丢失的遮挡蛋比整图推理少很多。

这套组合拳打下来，堆叠场景的召回率从0.83提到了0.91，基本达到了现场可用的水平。

最后再分享一个我在整个项目里最深的体会：目标检测项目能不能成，七成取决于数据质量，两成取决于工程细节，模型结构和改进点的贡献其实只占一成。很多人花大量时间研究怎么换注意力模块、怎么调损失函数，却不愿意多花两个星期把标注质量提上去、把场景多样性补全。我这套系统从头到尾跑通之后，回头看最值钱的工作仍然是数据准备阶段那一次次弯腰对着传送带拍图、一张张在LabelImg里框蛋的功夫。如果你正准备复现这套系统，先把数据这一关认真过了，后面的一切都会顺很多。