很多做餐饮供应链、食品加工、手工艺品代工的朋友，大概率都经历过“数竹签”的噩梦。竹签这东西看着不起眼，真要大数量清点时，人工一根根数既慢又容易出错；用秤称重换算数量，又受竹签干湿度、粗细波动影响，误差大得离谱。我这次尝试的是一套基于深度学习YOLOv8的竹签计数检测系统，用目标检测模型对画面中的竹签逐根定位，再通过PyQt5做一个可交互的可视化界面，把“看到一根算一根”变成自动化的实时计数。整套系统跑下来，单张图片内百根竹签的计数误差可以控制在个位数，而且模型还能直接用在摄像头实时场景里。这篇文章就把整个项目的思路、数据集制作、模型训练、界面集成和踩坑记录完整写出来，适合正在做物体计数类项目、想入手YOLOv8或者准备给检测模型套一个Python界面的朋友参考。

1. 系统整体设计与技术选型思路

做这类计数检测项目，最容易犯的错误是拿到需求就直接开跑模型。我见过不少朋友把YOLOv8一顿下载，随机拍了几张图丢进去训练，结果自然是灾难性的。所以在动代码之前，先把整体架构想清楚，比什么都重要。

1.1 为什么是YOLOv8而不是其他检测框架

先说选择YOLOv8的理由。目标检测领域的方案很多，比较早的Faster R-CNN精度不差，但推理速度慢，做实时摄像头场景很吃亏。SSD速度快，但对小目标和细长物体的检测效果一般。YOLOv5本身很成熟，不过YOLOv8在结构上做了几项关键升级，更贴合竹签检测这种需求。

竹签有一个很特殊的形态特点：细长、长宽比极高，一根烧烤竹签在1080P画面里可能只有几十像素宽，却有几百像素长。传统Anchor-based方案对这种极端长宽比的目标很不友好，需要设计大量不同尺寸的先验框才能覆盖。YOLOv8改成了Anchor-Free的解耦检测头，直接预测目标中心和边框，相当于天然避开了“竹签长宽比不好匹配预设锚框”的麻烦。再加上C2f模块的特征提取能力和多尺度融合，竹签这类小目标的细节不容易在深层网络里丢干净。实际测试下来，YOLOv8s在精度和速度的平衡上表现最好，单张图推理大约在10到20毫秒量级，放到PyQt5界面里流畅度完全够用。

还有一个现实原因是生态成熟度。Ultralytics官方维护的代码库封装得很完整，训练命令、验证脚本、模型导出、推理API一条龙，对不擅长从零撸网络的人来说省了太多事。做计数系统，核心难点本来就不在于复现网络结构，而在于数据、调参和工程集成。

提示：如果项目对帧率要求极高（比如每分钟几百件的高速产线），可以优先尝试YOLOv8n或者导出为TensorRT加速；如果计数精度优先且算力充裕，YOLOv8m甚至YOLOv8l都能带来一定的召回率提升。

1.2 为什么需要一个PyQt5可视化界面

很多技术人觉得，模型跑通了，输出一个计数数字不就行了？但在实际生产环境里完全不是这么回事。一线操作人员不可能去打开命令行敲Python脚本，也不可能去解析JSON检测结果。他们要的是一张能直观看到“每根竹签都被红框框住”的界面，一个能显示当前总数的面板，一个能加载图片、打开摄像头的按钮。

PyQt5相比其他GUI方案有几个不可替代的优势。第一，它底层基于Qt，控件丰富且稳定，QLabel显示图像、QPushButton响应点击、QTableWidget展示统计信息，都是开箱即用。第二，PyQt5和OpenCV的配合非常顺畅，图像数据经过OpenCV处理后转成QPixmap就能直接显示，不需要额外的格式转换库。第三，打包成exe在Windows环境部署很成熟，车间工人双击就能运行，不需要安装Python环境。

界面设计上，我采用的是左图右控件的经典布局：左侧大区域用于显示原图和检测结果，右侧放置功能按钮、计数显示面板和日志输出区。这样操作人员在看实时画面时，注意力能集中在左侧，右侧保持状态信息的稳定展示。界面不需要花哨，但一定要信息清晰、逻辑顺手。

1.3 系统架构与工作流程

整个系统的数据流其实很简单，可以概括为“输入端 -> 模型推理 -> 后处理 -> 界面展示”四个环节。

输入端支持三种数据来源：单张图片、批量图片文件夹、USB摄像头实时视频流。统一通过OpenCV的接口读入图像，再做预处理。预处理阶段主要就是调整图像尺寸，适配YOLOv8模型输入的分辨率。模型推理部分加载训练好的权重文件，对当前帧执行前向传播，得到一组检测框、置信度和类别。后处理环节除了常规的NMS去重，还要针对竹签计数做专门的逻辑，比如设置置信度阈值、合并重复检测框。最后界面根据检测框数量刷新计数显示，并把画好框的图像展示出来。

这样分层设计的好处是每一块都能独立测试和替换。比如不想要摄像头了，可以只改输入端；模型效果不好，可以直接换权重文件；界面逻辑改动也不影响模型代码。实际开发时，我发现这种清晰的模块划分让调试难度下降了很多，出了问题能快速定位是数据问题、模型问题还是界面问题。

2. 竹签计数数据集的制作是成败关键

说句实在话，竹签计数这种通用目标检测任务，训练一个能看的模型不难，难的是在真实场景里把计数误差压低。而决定成败的第一关，不是模型结构，是数据集质量。我前后迭代了三版数据集，才把现场准确率从惨不忍睹拉到基本可用。

2.1 采集场景设计：核心是贴近真实

第一次做数据集时我偷懒了，拿一把竹签在光线均匀的白色背景前拍了几十张，又简单做了些随机旋转和缩放增强，训练出来的模型看起来精度很高，验证集mAP到了0.95以上。结果一到实际车间场景就崩了：现场是暖色调的黄色灯光，背景是深色的操作台，竹签堆叠方式和我的数据集完全不同，漏检率一下飙到百分之二三十。

后来我重新设计采集方案，专门强调“场景覆盖度”。采集时至少覆盖以下几个维度：不同背景（深色操作台、浅色桌面、不锈钢台面、蓝色塑料筐）；不同光线（明亮日光灯、车间侧光、阴影区域、夜间补光）；不同摆放形态（整齐平行排列、散乱交叉、多层堆叠、部分压在纸箱里）；不同数量规模（三五根的小撮，也有上百根的密集摊开）。一个场景至少拍几百张，每个维度组合都尽量出现，才能让模型真正学到竹签的本质特征，而不是某个特定背景下的特征。

有个容易被忽略的细节是采集分辨率。我一开始用手机拍的照片分辨率高，但训练时统一缩放到640x640后，竹签的细节被严重丢失。后来我调整策略，在保证检测目标尽量大（竹签单根在画面中不小于几十像素宽）的前提下拍摄。如果你要检测的场景是整筐几百根竹签，建议镜头离竹签近一些，或者干脆训练时用1280x1280分辨率。

2.2 标注规范：一台竹签一个框

数据标注我用的LabelImg工具，输出为YOLO格式的txt文件。万事开头难，但竹签标注的难点不在于工具操作，而在于标准统一。

我的标注规范说起来很简单：每一根完整可见的竹签，都用一个矩形框精确框住。但执行起来全是细节。比如一根竹签斜跨整幅画面，框必须调整到恰好贴合整根竹签的斜向范围，不能为了省事只框中间一段。比如竹签被其他竹签遮挡了三分之一，只要主体可见，依旧要标注，不能漏。比如画面边缘毛刺一样的半根竹签，露出超过一半也要标注。遇到场景中混有筷子、木棒这类易混淆物体时，不标注，因为这类物体不属于目标类别，也顺便提升了模型抗干扰能力。

标注框的贴合度直接影响计数准确率。框太松，检测头学会了一个框包含多根竹签的概率就高；框太紧，又容易把一根竹签的头部或尾部裁掉，导致特征学习不完整。实际体验下来，框的四周留一点余量即可，但余量一定要统一，不要这张图贴得很紧，那张图留一大片空白。标注完成后我做了严格的复核，把单张图片的检测框数量重新数一遍，和人工目测数量核对，避免漏标。

注意：标注时如果场景中竹签数量特别多，很容易标到一半就眼花漏掉。建议采用“从左上角往右下角逐行扫视”的方式标注，并且每个批次标完就统计一下总数，和已知数量比对。模型效果不好时，首先检查标注数据的质量，而不是急着调参。

2.3 数据增强：别把方向搞反了

YOLOv8的训练管线自带增强策略，包括Mosaic拼接、随机仿射变换、HSV色彩扰动、水平翻转等，默认配置在大多数场景下都够用。但针对竹签计数这种密集目标场景，增强策略要稍微调整。

Mosaic增强本身很强大，它把四张图拼接成一张，让小模型能够看到更多上下文信息。但训练AI生成漂亮没问题，一到挑战场景就必须关闭“合成的假象”带来的副作用。Mosaic里会大量出现竹签被拼接边缘切断的假象，如果增强太强，模型可能把截断的竹签当成完整竹签来学习。我的做法是把Mosaic关闭或把Mosaic概率从默认的1.0降到0.5，让模型多关注真实完整的竹签形态。

色彩增强方面，我保留了HSV扰动，因为不同车间灯光的色温差异确实很大，需要模型对颜色变化有一定鲁棒性。但饱和度和明度的扰动幅度我没有给很大，因为这会让浅色竹签在深色背景上的边缘特征被削弱。旋转增强我很谨慎，给了一个较小的角度范围。竹签的摆放并不是完全无规律，如果旋转过度，让竹签竖起来训练，而真实场景里都是横向平铺，反而会产生域偏移。

说白了，增强的目的是模拟真实场景的变化范围，不是制造现实中不存在的极端情况。训练前想想模型最后会在什么环境里服役，增强策略就要围绕那个环境来做。

3. YOLOv8模型训练全流程实操

数据准备完毕，终于来到模型训练的环节。这里记录的是我从零开始训练一个竹签检测模型的完整命令和参数取舍，也包括我在多次迭代后得出的调参心得。

3.1 训练环境准备

我本机用的是GPU训练，操作系统是Windows 10，显卡显存8GB。核心依赖包括Python 3.9、PyTorch 2.0.1、CUDA 11.8、Ultralytics 8.0.xxx版本、OpenCV、PyQt5。

在Windows环境安装Ultralytics很简单：

pip install ultralytics pip install pyqt5 opencv-python

装好之后可以写一段快速验证代码，确认CUDA可用：

import torch from ultralytics import YOLO print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

如果输出的cuda可用性是False，大概率是PyTorch版本和CUDA驱动不匹配，建议先去PyTorch官网用命令生成器选择对应版本重新安装。

3.2 数据集配置与训练参数调优

训练前需要把数据集整理成Ultralytics要求的目录结构：

datasets/bamboo/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/

每个图片对应一个同名的txt标注文件，内容是“类别 中心x 中心y 框宽 框高”的归一化数值。我最终训练集约800张图、标注实例总数接近25000个，验证集约200张图。这个规模对单类别目标来说不算大，但场景覆盖度一旦做起来，效果明显比数量堆得多更管用。

data.yaml文件写成这样：

train: datasets/bamboo/images/train val: datasets/bamboo/images/val nc: 1 names: ['bamboo_skewer']

训练命令我用的是：

yolo detect train data=datasets/bamboo/data.yaml \ model=yolov8s.pt \ epochs=300 \ imgsz=640 \ batch=16 \ patience=50 \ device=0 \ project=bamboo_train \ name=exp1

这里有几个参数值得展开说。预训练权重的选择，我建议直接用yolov8s.pt。竹签本身的纹理特征和通用物体特征有不少共性，迁移学习能让训练起点高很多，特别是在数据量不算大的情况下。从零训练不仅收敛慢，最终精度也往往不如带预训练的版本。

epochs设为300是因为我发现竹签数据在前100轮训练时loss下降很快，但到后期计数精度仍然有缓慢提升。patience设为50则是防止过拟合拖时间，如果验证集指标连续50轮不提升就自动停止。imgz选640是8GB显存下batch=16的安全选择，如果想用1280分辨率，我会建议batch降到4到8，否则很容易显存爆炸。

3.3 训练过程监控与效果评估

训练过程中要重点关注两类指标：loss曲线和验证集指标。Ultralytics会在每个epoch结束后打印精确率（Precision）、召回率（Recall）、mAP50和mAP50-95。

在竹签计数场景中，我评估模型的侧重点跟一般检测任务略微不同。对于通用检测，mAP50-95是一个核心指标；但计数任务真正要关心的是召回率。原因很简单：漏检一根竹签，意味着计数直接少一根；而框的位置稍微不精确，对计数的最终结果几乎没有影响。所以我训练时紧盯Recall这个数字，要求验证集上的Recall至少达到0.95以上，才算勉强具备现场部署的资格。

有一次训练出来的模型Precision是0.98，但Recall只有0.87。表面上看指标不错，但现场一测，每100根竹签漏掉十几根，计数误差根本没法接受。后来我通过补充更多重叠场景数据、把置信度阈值从默认的0.25下调到0.1，把Recall拉到了0.96，计数误差才算可控。这也再次说明，指标一定要结合实际业务场景来理解和取舍。

训练完成后，工作目录下会生成best.pt和last.pt两个权重文件。best.pt是验证集上指标最优的权重，一般直接拿它来做推理。如果部署时追求更快的速度，还可以用：

yolo export model=best.pt format=onnx

把模型导出为ONNX格式，配合OpenCV DNN模块部署，可以脱离PyTorch环境运行，这是后续做更轻量化部署的常用手段。

4. 检测结果到计数功能的落地

模型训练出来，只完成了第一步。从检测框到最终输出一个准确的数字，中间还隔着一个计数逻辑的合理设计。不少朋友在跑通模型后就以为大功告成，实际上计数逻辑的设计深深影响着最终系统的可用性。

4.1 计数器逻辑：检测只是第一步

Ultralytics的推理API返回的是一个Results对象，里面包含了当前帧中所有被检测到的目标信息，包括每个目标的类别ID、置信度和归一化坐标框。最简单的计数逻辑就是统计属于目标类别的检测框总数：

from ultralytics import YOLO model = YOLO('runs/detect/train/weights/best.pt') results = model('test_img.jpg', conf=0.25, verbose=False) boxes = results[0].boxes count = int((boxes.cls == 0).sum())

但这样粗糙的统计在真实场景里不够用。首先，NMS后处理偶尔还会留下同一个目标被重复检测的情况，一个竹签被模型预测成两个重叠度不高的框，此时总数会虚高。我的处理方式是增加一个去重阶段：如果两个框的中心距离小于某个阈值（比如20个像素），且尺寸相似，就认为它们是重复检测，只保留置信度高的那个。

另外，置信度阈值不能盲目设低。Recall不够时阈值低可以帮助捞回一些漏检；但阈值太低会引入大量误检，把桌面的阴影纹理也当成竹签。我最后的做法是对现场采集的几十个不同场景做了一遍阈值扫描，画出一条计数误差曲线，选择误差最低的阈值点作为固定参数。

4.2 处理重叠与遮挡的计数策略

竹签交叉堆叠是最棘手的场景。两根竹签呈X形交叉，检测器可能因为重叠区域的特征干扰，只检出一根而漏掉另一根；三根竹签紧紧并排，则可能被框成一个粗的框，数量直接从3变成1。

我从数据层面和推理层面同时做了优化。数据层面，训练集中专门增加了大量交叉堆叠的真实图片，让模型见过足够多的“两根交叉”形态，学会通过露出的头尾来区分独立目标。推理层面，我调整了NMS的IoU阈值，从默认的0.5调到0.7，降低高IoU框被抑制的概率，减少密集重叠时漏框的数量。此外还可以开启Ultralytics的半精度推理（half=True），虽然这不会直接改善漏检，但提速后方便在摄像头场景下尝试多帧融合——连续取几帧结果，如果计数波动小就取中间值或众数，这样单帧偶发漏检不会直接毁掉整个计数结果。

这里也分享一个关于计数任务本身的观点：检测框的位置其实不太用追求像素级精确，只要数量对得上，计数就是成功的。所以重叠严重时，与其纠结模型为什么没把框画准，不如把精力放在怎么让框的数量和真实目标数一致上。

4.3 计数准确率的评估方法

部署前，必须建立一套客观的计数准确率评估方法。我的做法是准备一份专门的测试集，包含若干张不同难度等级的现场图像，每张图由人工提前数出准确数量，再让系统跑一遍，算出绝对误差和相对误差。

评估结果用表格记录：

把整个测试集跑下来，重点看平均相对误差。如果平均误差在2%以内，现场使用时的体验已经相当好。如果误差过大，不要急着改模型，先回到数据层面复盘：是重叠场景数据不足，还是背景干扰过多，又或者是光照太暗导致细节丢失。这种逐项排查的效果，远好于盲目堆训练轮数。

5. PyQt5界面设计与系统集成

模型和计数逻辑都稳定了，最后一步就是把它包成一个普通操作人员也能上手使用的界面。PyQt5在这个环节展现出了强大的工程实用性，但也藏着不少坑。这一节从布局到多线程，把完整路径捋一遍。

5.1 界面布局与交互流程

我的界面主窗口分为左右两个区域。左侧是一个大尺寸的QLabel，用于显示图像和检测结果；右侧是一个固定宽度的控制面板，包含四个按钮（打开图片、打开文件夹、打开摄像头、停止检测）、一个计数数字显示控件、一个置信度阈值滑动条，以及一个日志输出框。

交互逻辑是这样的：点击打开图片，会弹出一个文件选择对话框，选定图片后，系统加载图片并送入模型推理，推理完成后在左侧显示画好框的效果图，同时在右侧计数面板更新当前数量。打开文件夹时，则对目录下的所有图片进行批量推理，输出一个汇总报告，记录每张图的计数结果。摄像头模式是最复杂的，点击后调用计算机的默认摄像头，系统以实时视频流的方式进行检测，每帧刷新计数结果。

如果摄像头画面里竹签在移动，就会出现同一个目标跨帧被重复计数的问题。我在实时模式下加入了一个简单的去重逻辑：维护一个目标ID列表，只有当新检测出来的目标中心点与上一帧所有目标的位置都相差超过一定距离时，才把它当作新目标计数。使用OpenCV的追踪算法可以做得更精细，但在竹签这种固定环境下，简单距离判断已经够用。

5.2 使用QThread避免界面卡顿

这是整个PyQt5集成中最重要的一个技术点。很多第一次写界面的朋友会把模型推理直接放进按钮的click事件里，结果就是点击按钮后整个窗口冻结，鼠标转圈，画面一卡就是好几秒，用户体验极其糟糕。

原因很简单：GUI的事件循环和推理任务在同一个线程里执行，推理阻塞了界面响应。解决办法是把推理工作放到一个单独的QThread子线程中，主线程只负责界面响应和结果展示。

我封装了一个CameraThread类，继承自QThread：

class DetectThread(QThread): frame_signal = pyqtSignal(dict) def __init__(self, model, camera_index=0): super().__init__() self.model = model self.cap = cv2.VideoCapture(camera_index) self.running = True def run(self): while self.running: ret, frame = self.cap.read() if not ret: continue results = self.model(frame, conf=0.25, verbose=False) count = int((results[0].boxes.cls == 0).sum()) plotted = results[0].plot() self.frame_signal.emit({'img': plotted, 'count': count}) def stop(self): self.running = False self.cap.release()

在界面里只需要连接这个线程发出的信号：

self.detect_thread.frame_signal.connect(self.update_frame)

然后在update_frame方法里更新图片和计数显示。这样无论推理多慢，界面都能保持流畅滚动、点击响应。如果推理一帧超过200毫秒，观察用户是否容易误操作，需要注意及时在UI上给出“处理中”状态提示，避免重复点击。

注意：多线程涉及界面更新时，永远只能通过信号槽机制在主线程里更新控件，不能在工作线程里直接调用控件的setText等方法，否则会出现随机崩溃、界面闪烁等诡异问题。

5.3 本地模型推理与显示刷新

在界面里做推理时，要注意图像的格式转换。OpenCV读入的是BGR格式的numpy数组，而QLabel显示图片需要QPixmap。转换链路一般是：

rgb_image = cv2.cvtColor(bgr_plot, cv2.COLOR_BGR2RGB) h, w, ch = rgb_image.shape bytes_per_line = ch * w qt_image = QImage(rgb_image.data, w, h, bytes_per_line, QImage.Format_RGB888) pixmap = QPixmap.fromImage(qt_image) self.image_label.setPixmap(pixmap.scaled( self.image_label.size(), Qt.KeepAspectRatio, Qt.SmoothTransformation))

这里比较坑的是bytes_per_line参数，它必须等于通道数乘以宽度。如果图像宽度是奇数，而你又直接把numpy数组data传给QImage，有时会因为行字节对齐问题导致图像扭曲或者偏色。稳妥做法是先用np.ascontiguousarray确保数据内存连续，再做转换。

摄像头模式的帧率也需要控制。如果模型推理速度是每秒20帧，但界面刷新的速度跟推理速度不一致，会造成视频卡顿或画面撕裂。我在摄像头线程里做了简单的节流，控制模型推理的帧率上限，同时确保UI刷新与检测帧率保持一致。实际体验中15帧每秒左右已经足够流畅，因为竹签计数场景本身不是一个高速运动场景，帧率不必拉满。

6. 常见问题排查与实操避坑实录

系统的开发过程中一定不会是一帆风顺的。这里把我踩过的坑、读者最容易遇到的问题和处理思路整理成一份速查表，希望帮你少走弯路。

6.1 检测环节的典型问题

我遇到的最典型问题第一版就是训练集背景太单一导致的现场失效，后来重做数据后这个问题基本消失。建议你一旦发现模型在验证集上指标很漂亮但现场效果差，先怀疑数据覆盖度。

6.2 界面运行中的典型问题

界面最常见的坑是摄像头关闭不掉。Windows下OpenCV的视频捕获对象如果线程没正确释放，摄像头灯会一直亮着，程序退出时甚至可能报错。解决方法是确保在关闭按钮中调用线程的stop方法，让线程内部执行cap.release()，而不是在主线程里直接销毁摄像头对象。

另一个问题是界面启动较慢。因为加载YOLOv8模型需要初始化PyTorch环境，通常需要几秒钟。如果用户点击按钮过早，界面看起来像卡住了。我在程序启动时就提前加载模型，配合一个“模型加载中…”的提示标签，用户感知会好很多。对于追求启动速度的部署场景，可以改成ONNX推理或者转成TensorRT，但这些优化带来的复杂度要根据项目需要谨慎评估。

还有一个容易被忽略的坑是路径问题。用PyInstaller打包成exe后，程序内引用模型文件的相对路径可能失效，导致运行时报找不到文件。我的习惯是把模型路径写成一个可配置参数放在界面里，同时也支持在当前目录下自动搜索权重文件，这样部署时不需要修改代码。

6.3 训练过程中的常见问题

训练时最常遇到的报错是显存不足。8GB显存跑yolov8s且imgsz=640时batch不能太大，我通常用16。如果想用1280分辨率，batch得降到4或8，或者开启amp混合精度训练，这一步能显著降低显存占用。如果还是不够，建议先拿yolov8n跑通流程，确认成果后再换大模型。

还有一个容易误导人的现象：训练loss下降但Recall一直上不去。这时最可能的原因是训练集里的正样本质量有问题，比如标注遗漏严重、或者标注框没有完全包含竹签导致模型学到的是不完整的特征。需要回到标注环节修正而不是继续加epochs。我自己曾经在标注时偷懒少标了几十根竹签，结果无论怎么调参，召回率的提升都非常有限，把漏标补上后指标就正常了。

7. 给同类计数项目的一点个人经验

做竹签计数系统最大的体会是：计数检测类项目真正的技术难度并不在网络结构，而在于数据场景的覆盖度和工程集成细节。YOLOv8把目标检测的门槛压得很低，任何人拿到官方教程都能训练出一个看起来可用的模型，但能不能在实际现场稳定运行，拼的是对数据的用心程度和对业务场景的理解深度。

如果你也在做类似的计数项目，无论是竹签、木签、棉签还是五金件，我建议第一步不是急着找模型，而是先花两周去收集真实场景的图像。把背景、光照、摆放姿态的多样性做足，把标注质量做到位，模型训练就会顺利很多。界面方面，优先考虑多线程和交互流畅性，不要让它成为项目交付时的最后一根稻草。

我自己后续还打算在这个系统上做两件事：一是把分类从单类别扩展成“原色竹签”和“碳化竹签”两个类别；二是用标定板做一个实际尺寸推算，让竹签在画面里斜着摆时也能更稳定地计数。这套基于YOLOv8加PyQt5的方案，还有很大的扩展空间，希望这篇记录能给同路人一些帮助。