基于YOLOv8的课堂行为检测系统实战：从数据标注到部署优化

简介：目标检测是计算机视觉中应用最广泛的技术之一，YOLO系列凭借出色的速度与精度平衡，成为实时检测任务的首选方案。在课堂场景中，需要识别举手、睡觉、玩手机、书写等细粒度行为，这对小目标检测、遮挡处理和实时性提出了更高要求。YOLOv8通过anchor-free检测头、解耦分类分支和C2f特征提取模块，在中小目标识别上表现优异，配合合理的类别定义和均衡的数据集，能够有效提升行为判别的准确率。从数据标注、模型训练到推理部署，完整的工程化流程是落地关键：使用LabelImg或X-AnyLabeling制作高质量标注集，通过Ultralytics框架训练调参，再借助ONNX或TensorRT完成加速，甚至可迁移至RK3588等边缘设备。本文基于真实项目，详细拆解了课堂行为检测系统的实现过程，涵盖环境配置、训练策略、源码架构与部署优化，为相关开发者提供可复用的实践经验。 头一回做课堂行为检测这个方向时，我其实走了不少弯路。最开始直接用预训练模型跑通用目标检测，效果只能说差强人意——挨着坐的学生互相遮挡、手部目标太小、趴桌子的姿态和低头写字难以区分，这些问题靠通用模型根本解决不了。所以后来我干脆从数据标注、模型训练到推理部署完整撸了一套基于YOLOv8的课堂行为检测系统，把图片检测、视频检测、实时摄像头推流都做了进去，源码也整理成了可直接使用的工程。这篇就把整个项目拆开讲，从环境配置、数据集制作到训练调参和部署优化，把能复现、能抄作业的部分都写清楚，踩过的坑也一并列出来。

1. 课堂行为检测为什么选YOLOv8，而不是Faster R-CNN或YOLOv5

1.1 行为检测任务对模型的要求与YOLOv8的适配性

课堂场景有它的特殊性：第一，学生数量多且密集，单张图片里可能同时出现几十个人脸和姿态；第二，遮挡严重，坐在后排的学生经常被前排同学挡住半张脸；第三，行为判定的关键特征往往集中在手部、头部这样的中小目标上，比如举手、玩手机、趴桌子，这些动作在整幅画面里只占很小一块区域；第四，作为教学辅助系统，必须要有实时或准实时的分析能力，不能一帧分析几十秒。

这几个要求叠加起来，Faster R-CNN这类两阶段检测器的精度虽然不错，但推理速度实在撑不起视频流的分析需求。而YOLOv8在速度和精度的平衡上做得相当好，尤其在小目标检测这一块，相比YOLOv5有了明显的结构升级。它在C2f模块里融合了梯度路径，保留了更多细粒度特征信息，再结合PAN-FPN的多尺度特征融合，小目标的特征在深层和浅层之间传递时丢失更少。我做了一组对比实验，在自建的课堂行为数据集上，YOLOv8n的mAP50能到78左右，推理速度在GTX 1660Ti上还有60多帧，这在两阶段模型里几乎是不可能的。

为什么选YOLOv8而不选YOLOv5，核心差在这几点上：

• YOLOv8把检测头换成了anchor-free结构，不需要预设锚框尺寸和比例，省掉了聚类锚框的步骤，对不同目标尺寸的适应能力更强；
• 头部网络采用了解耦结构（Decoupled Head），分类分支和回归分支分开走两条卷积分支，不再共享参数，这解决了分类和定位任务对特征需求不同的问题，收敛更快、精度也更高；
• C2f模块相比C5的CSP结构，输入只会经过一个1x1卷积，然后送入多个Bottleneck分支堆叠，再把所有分支输出的特征concat起来，信息流更丰富，梯度回传更平稳。

1.2 YOLOv8的三种模型架构与课堂场景的算力匹配

YOLOv8官方提供了n、s、m、l、x五个版本，从n到x参数量和计算量依次上升。课堂行为检测的系统部署环境差异很大，我见过有人在教室电脑上用CPU跑，也有人在机房用RTX 3080甚至边缘设备RK3588做实时分析，所以选哪个版本得看你的实际算力。

我的建议是：

• YOLOv8n：适合边缘设备、嵌入式设备、CPU推理，或者对实时性要求极高、算力紧张的场景。精度相对低一些，但胜在轻量，模型文件只有6MB左右；
• YOLOv8s：这是我认为课堂行为检测的性价比之选。在GTX 1660Ti这样的6GB显存显卡上，imgsz=640时训练batch size开到16没问题，推理速度在80帧左右，精度比n版高出一截；
• YOLOv8m/l：适合离线分析服务器或训练条件充裕的情况，精度更高但速度明显下降，教室实时分析一般不推荐；
• YOLOv8x：说实话不太建议用在课堂行为检测上，它的精度提升相对成本来说不划算，出图慢，部署也困难。

我最终的项目源码默认用的是YOLOv8s，训练和推理的实测数据在后面的章节里会给出。如果你的显卡更好，可以照着同样的代码流程直接换m或l模型重训，不需要改任何逻辑代码。

2. 课堂行为数据集制作：从公开数据集到标注实操

2.1 数据集来源与自建数据的必要性

做课堂行为检测，首先得面对一个现实问题：公开的课堂行为数据集非常少。常见的一些行人检测、姿态估计数据集（比如COCO、MPII）里虽然有"人"这个类别，但没有"举手""玩手机""睡觉"这样的行为标签。直接拿COCO预训练模型来跑课堂场景，模型只能告诉你"这里有个人"，不能告诉你"这个人正在做什么"。

所以自建数据集是绕不开的一步。我当时的思路是这样：一方面收集网络公开的课堂场景图片，注意筛选清晰度高、光线正常的画面；另一方面从学校教室监控视频里抽帧，按一定时间间隔截取图片，保证样本覆盖不同坐姿、不同位置、不同光照条件。数据集规模不用追求极大，我最终用了大约6000张图片，每张图片按后续要讲的操作方式标注，就已经能训出可用的模型了。

你如果完全从零开始，也可以先用Open Images v7这类大规模数据集的子集做预训练，再用自己的课堂数据微调，这种"预训练+微调"的策略能大幅减少标注成本。

2.2 标注类别体系设计

标注之前，首先要定义好行为类别。类别定义直接决定模型能学到什么，我踩过的一个坑就是类别分得太细，模型反而学不会。

我最终采用的课堂行为类别体系是这样的：

这里的经验是：类别可以是动作，也可以是"状态+动作"的组合。比如"writing"和"reading"不是瞬时动作，而是持续状态，检测模型完全可以识别，但需要你在标注时保持标准统一。比如"低头看手机"到底算using_phone还是sleeping？如果学生的头低得快要碰到桌面但手上有手机，我标using_phone；如果头趴在桌子上没有任何手部动作，我标sleeping。这样统一标准后，模型学到的特征才不至于互相打架。

2.3 标注工具选择与YOLOv8数据标注具体操作

数据集标注用的工具，我推荐两个：LabelImg和X-AnyLabeling。

LabelImg是老牌工具，简单直接，适合快速上手做目标检测框标注。不过用它标注大量数据时效率偏低，因为它的自动保存和快捷键支持还算凑合，但缺少半自动标注能力。

X-AnyLabeling是最近圈子里用得比较多的工具，最大的优势是支持加载基础模型做半自动预标注。你可以先用YOLOv8官方预训练权重对图片跑一遍检测，把结果导入标注工具，人工只需要修正框的位置和类别，标注效率能提升至少2倍。我在标注初期就是先用YOLOv8s的COCO预训练模型把"人"这个大类框出来，然后在这一层检测框的基础上微调细节和添加行为类别标签。

具体标注操作流程：

1. 安装X-AnyLabeling，模型设置里导入Ultralytics导出的YOLOv8 ONNX模型，或者直接用内置的Segment Anything做分割预标注辅助定位人体；
2. 打开图片文件夹，用自动标注功能生成初步检测框；
3. 人工审核每个框：定位不准的拖动修正，类别标签错误的在下拉框里改正，漏检的用矩形框手工补上；
4. 导出标签格式为YOLO格式（每张图片对应一个.txt文件，每行是"类别编号 cx cy w h"），坐标是归一化的中心点和宽高；
5. 标注完成后划分数据集，我按8:1:1划分训练集、验证集、测试集，目录结构严格按YOLO格式组织。

2.4 数据清洗与平衡：为什么你的模型总是漏掉某个行为

数据集的"量"不是万能的，样本平衡性才是决定模型表现的关键。我在第一版数据集里，writing的样本占到了40%以上，而using_phone只有不到5%。结果训练出来的模型对writing检测效果还行，对using_phone几乎完全失灵——这种类别不平衡会让模型偏向于"好认"的类别。

处理办法主要是这几个：

• 统计每类样本的框数量，对样本量少的类别做数据扩增，尤其是随机旋转、亮度变化、翻转等不影响行为语义的增强；
• 对样本量充裕的类别做随机下采样，在训练时通过数据加载器的采样权重控制类别比例；
• 针对类别混淆问题做难例挖掘，比如sleeping和writing容易混淆，可以把这些"长得像"的样本单独挑出来，多标注一些，模型会对它们的边界特征更加敏感。

另外还有一个容易被忽略的点：背景样本。课堂场景里会有空座位、黑板、投影屏幕等大量非目标内容。如果数据集里所有图片都有人，模型容易把背景误检成目标。我加入了不少纯背景图片（不包含任何学生），标注文件为空，训练时模型能学到"没有目标时输出低置信度"，这对降低误报率帮助很大。

3. 环境配置与训练调参：从GTX 1660Ti到现成源码的完整流程

3.1 Ubuntu/Windows下配置YOLOv8环境

我主要用的环境是Ubuntu 22.04 + Python 3.10 + PyTorch 2.x + CUDA 11.8/12.1。有不少读者问到Windows下能不能跑，当然可以，Ultralytics官方对Windows的支持已经很成熟了，只是路径处理和Dataloader多进程上要注意一点，后面会提。

环境配置的核心步骤如下：

# 创建虚拟环境并激活 conda create -n yolo8 python=3.10 conda activate yolo8 # 安装PyTorch，注意CUDA版本要和本机驱动匹配 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 # 安装Ultralytics pip install ultralytics # 验证安装 yolo predict model=yolov8n.pt source='https://ultralytics.com/images/bus.jpg'

这里有个容易出错的地方：直接pip install ultralytics会顺带安装最新版PyTorch，但如果你先装了PyTorch再装ultralytics，它会检测已有环境，一般不会重复装。如果出现torch版本冲突导致报错，建议用conda创建一个全新环境，严格按上面步骤来。

说到GTX 1660Ti，我拿它做了一整轮的训练测试。1660Ti是6GB显存，训练YOLOv8s时batch size开到16会爆显存，我最终用batch size=8，imgsz=640，配合梯度累积效果也还可以。如果你也用1660Ti这类6G卡，可以直接照抄下面这组参数。

3.2 训练命令与关键参数解析

源码里的训练入口是train.py，核心内容基于Ultralytics的YOLO接口封装。最核心的训练逻辑可以直接用命令实现：

yolo detect train \ data=classroom_behaviors.yaml \ model=yolov8s.pt \ epochs=150 \ imgsz=640 \ batch=8 \ lr0=0.001 \ lrf=0.01 \ optimizer=AdamW \ cos_lr=True \ warmup_epochs=3 \ workers=4 \ device=0 \ project=runs/train \ name=classroom_detect

几个关键参数的解读：

• data=classroom_behaviors.yaml：这是数据集的配置文件，里面定义训练集、验证集的路径以及类别名称字典。注意这个文件里的path路径最好写成绝对路径，相对路径在Windows和Linux下行为不一致，很容易踩坑；
• model=yolov8s.pt：加载YOLOv8s的COCO预训练权重。这是在COCO上先学过的模型，再微调到课堂行为数据集上，收敛速度比从零训练快得多；
• lr0=0.001：初始学习率。如果是直接用预训练权重微调，学习率不要给太大，否则容易把预训练特征破坏掉；
• cos_lr=True：使用余弦退火学习率调度，训练后期学习率平滑下降，有助于收敛到更好的局部最优；
• warmup_epochs=3：前3个epoch学习率从很小逐渐升到设定值，避免刚开始训练时参数震荡太剧烈。

3.3 训练过程中的监控与损失函数解读

训练过程中，重点看这几个指标：train/box_loss、train/cls_loss、train/dfl_loss、val/box_loss、val/cls_loss、metrics/precision(B)、metrics/recall(B)、metrics/mAP50(B)。

很多初学者一看loss下降就高兴，其实要重点关注验证集上的loss和mAP趋势。如果训练集loss一直降，但验证集loss在某个epoch后开始回升，mAP停滞甚至下降，这就是典型的过拟合信号。这时候要么减少epoch数，要么增大数据增强的强度，要么加早停。

还有一个很常见的场景：用YOLOv8画损失函数曲线图。训练结束后Ultralytics会自动生成results.png，里面包含所有loss曲线和精度曲线。如果你想自己封装一段脚本画更定制化的曲线，可以用pandas读取runs/.../results.csv，再用matplotlib画图。

我的一份训练记录（YOLOv8s，6000张图，150个epoch，1660Ti）：

从实测来看，这个精度已经足够支撑课堂行为的辅助分析。如果你把模型换成m系列，mAP50能再涨2-3个百分点，但推理速度会下降一半左右。

3.4 训练完成后如何评估模型，如何找出失败案例

只看mAP是不太够的。我认为训练完必须做一次失败案例复盘：

1. 用训练好的模型跑一遍验证集，把预测结果和真实标注的可视化图批量导出；
2. 找出FN（漏检）和FP（误检）最典型的图片，逐一分析原因；
3. 如果是遮挡导致的漏检，可以考虑做更高分辨率的输入，或者做多尺度推理；
4. 如果是类别混淆导致的误检（比如sleeping被标成writing），说明类别定义或边界样本标注有问题，回到数据集去修正。

Ultralytics提供了很方便的可视化接口：

from ultralytics import YOLO model = YOLO('runs/train/classroom_detect/weights/best.pt') results = model.predict(source='data/val', save=True, save_txt=True)

这样每张验证图片都会保存检测框可视化图，人工翻一遍就能直观判断模型盲点在哪。这个步骤虽然花时间，但比盲目调参有用得多。

4. 检测系统源码架构：图片、视频与实时推理的完整实现

4.1 系统模块划分与推理流程

我提供的源码不是简单的几行模型调用，而是一个相对完整的工程。整体模块划分是：

• detect.py：统一推理入口，支持图片、视频、摄像头；
• models/yolo_detector.py：封装YOLOv8模型的加载与推理逻辑，支持切换权重文件；
• utils/annotator.py：负责在检测结果上绘制框、标签、置信度，以及行为统计；
• utils/video_processor.py：视频抽帧、结果回写、按时间段统计行为占比；
• configs/config.yaml：可配置的模型路径、类别名称、置信度阈值、帧率等参数。
• web_demo：基于Flask的简易Web界面，上传图片或视频即可可视化检测结果。

这样做的好处是：如果后续想换模型（比如从yolov8s换成yolov8m），只需要改配置文件里的模型路径，不用改任何业务代码。

4.2 图片检测模块的实现细节

图片检测的逻辑最简单，核心代码如下：

import cv2 from ultralytics import YOLO class YOLOv8Detector: def __init__(self, weights_path, conf_thres=0.4, iou_thres=0.45): self.model = YOLO(weights_path) self.conf_thres = conf_thres self.iou_thres = iou_thres self.names = self.model.names def detect_image(self, image_path): results = self.model.predict( source=image_path, conf=self.conf_thres, iou=self.iou_thres, verbose=False ) boxes = results[0].boxes.xyxy.cpu().numpy() confs = results[0].boxes.conf.cpu().numpy() clss = results[0].boxes.cls.cpu().numpy().astype(int) return boxes, confs, clss

需要注意置信度阈值的设置。课堂场景里检测目标数量多、存在大量遮挡，置信度阈值设得太高（比如0.7），会导致很多真实行为被过滤掉；设得太低（比如0.15），又会涌出一堆无效框。我实测下来，0.35-0.45是比较合理的区间，具体按你的模型精度微调。

4.3 视频检测与行为统计的实现

视频检测的难点在于稳定性：单独看每一帧的特征可能会跳动，后一帧检测到举手、前一帧没检测到，如果直接输出结果，统计口径会乱。我在源码里加入了基于跟踪的跨帧平滑策略。

简单说就是先用YOLOv8检测单帧目标，然后用ByteTrack或BoT-SORT把连续帧里的同一个学生关联起来，给每个学生分配一个稳定的track_id。这样在统计行为时，可以按track_id聚合多帧的检测结果，再通过滑动窗口投票的方式决定该学生当前处于什么行为状态。

以"举手"为例，某学生track_id=3，在最近10帧里有7帧检测到raising_hand，那系统判定这个学生当前处于举手状态。这种投票机制能有效过滤单帧误检和漏检。

class FrameBuffer: def __init__(self, window_size=10): self.window_size = window_size self.buffer = {track_id: [] for track_id in range(1000)} def update(self, track_id, label): self.buffer.setdefault(track_id, []).append(label) if len(self.buffer[track_id]) > self.window_size: self.buffer[track_id].pop(0) def stable_label(self, track_id, threshold=0.6): labels = self.buffer.get(track_id, []) if not labels: return None most_common = max(set(labels), key=labels.count) ratio = labels.count(most_common) / len(labels) return most_common if ratio >= threshold else None

视频检测的另一个关键点是抽帧策略。按每帧全量检测虽然准确，但非常消耗算力，一个5分钟的课堂视频全量检测可能要好几分钟。我在源码里支持按帧间隔抽样检测（比如每秒检测2-3帧），中间帧直接用最近一次检测结果代替，对行为统计来说影响很小，但推理时间能缩短到原来的1/3。

4.4 摄像头实时检测的实现

摄像头检测和视频检测在代码层面大同小异，区别在于图像源从VideoCapture换成摄像头索引号。这部分我用OpenCV的VideoCapture(0)读取摄像头，把每一帧送入检测器，然后用VideoWriter流式输出。

实时摄像头检测要注意的点是不要每帧都做全量推理。比如摄像头是30FPS，YOLOv8s在1660Ti上推理一张640x640的图约12ms，按理说能跟上30FPS，但如果同时开多个模型实例或分辨率太高，就会积累延迟。我建议在实时模式下限制推理帧率，比如每秒最多推理10帧，保持分析的稳定性。

5. YOLOv8模型部署与推理加速：从ONNX导出到嵌入式设备

5.1 为什么要做模型转换，ONNX和TensorRT怎么选

训练完的PyTorch权重是.pt格式，适合做训练和实验，但直接部署到生产环境有几个问题：一是依赖PyTorch运行时，环境重；二是推理速度还有提升空间；三是嵌入式设备根本装不了PyTorch。

我推荐的部署路径是先导出ONNX，再根据目标平台导出引擎格式：

# 导出ONNX yolo export model=runs/train/classroom_detect/weights/best.pt format=onnx opset=12 # 导出TensorRT引擎（NVIDIA显卡） yolo export model=runs/train/classroom_detect/weights/best.pt format=engine device=0

ONNX是一个中间格式，几乎所有推理框架都支持，适合做跨平台迁移和验证。TensorRT是NVIDIA专门为自家GPU做的推理优化，能在ONNX基础上进一步加速。实测下来，TensorRT FP16推理比原生PyTorch快3倍左右。我在部署到服务器时用的就是TensorRT FP16。

5.2 边缘设备部署：RK3588环境下的NPU加速

热词里出现RK3588相关的部署问题，我恰好做过这个方向的实验。RK3588是瑞芯微推出的高性能边缘计算平台，自带6 TOPS的NPU，很适合做课堂摄像头终端的本地推理。

RK3588部署YOLOv8的流程大概是：

1. 在PC上把训练好的.pt权重导出为ONNX；
2. 用RKNN-Toolkit2工具链把ONNX模型转换为RKNN格式：
3. 在RK3588设备上用RKNN Python接口加载RKNN模型做推理；4. 如果需要更高性能，可以在NPU上做量化（INT8/FP16），注意量化后精度会有所下降，需要做数据集校准来补偿。

# 在PC上安装rknn-toolkit2并转换 rknn_convert --input_path best.onnx --output_path best.rknn --target_platform rk3588

我在RK3588上实测YOLOv8s的RKNN INT8模型，推理速度大约在60ms一帧，勉强满足准实时分析。如果换成YOLOv8n，能跑到30ms左右，流畅度就上来了。所以边缘部署场景，我一般推荐用n或s版本，并且配合抽帧策略。

5.3 推理结果的可视化与业务集成

模型只是系统的一部分，真正给用户使用的是业务层的可视化。源码里的annotator模块支持直接在画面上绘制目标框和行为标签，标签颜色按类别区分。睡觉用蓝色、玩手机用红色、举手用绿色，这样老师在教学管理后台一眼就能看出异常行为的位置和占比。

除了单个框的可视化，我还加了行为统计图：视频分析完成后生成整个时间段的各类行为占比折线图和饼图，以及每个学生的行为时间线。这部分在源码里是基于matplotlib生成的，方便对接任何Web前端展示。

6. 部署过程中的性能对比与常见问题排查

6.1 不同推理后端性能实测对比

我在源码里封装了PyTorch、ONNX Runtime、TensorRT三种推理后端，都是统一接口，可以一键切换。实测数据（都在同一台机器：i5-12400F + RTX 3060 12G）如下：

从表格可以看出来，TensorRT FP16是精度和速度最均衡的选择。如果你部署的机器是NVIDIA显卡，建议优先用TensorRT；如果是纯CPU环境或嵌入式设备，ONNX Runtime加适当抽帧是更实际的选择。

6.2 显存不足与训练中断的处理

GTX 1660Ti用户训练时最常遇到的就是CUDA out of memory。如果你的batch size开大了导致OOM，不要直接手足无措，有几种解决思路：

• 调小batch size，从16降到8或4；
• 调小imgsz，从640降到512，但注意会损失小目标检测精度；
• 开启梯度累积（Ultralytics里可以通过accumulate参数控制），相当于变相扩大batch size，对收敛稳定性有帮助；
• 设置cache=True会占用大量内存，如果内存也比较紧张，建议取消缓存。

另外，训练中断是家常便饭。Ultralytics支持断点续训，在训练命令里添加resume=True即可从上次保存的checkpoint继续训练。我每次训练都会设置save_period=10，每10个epoch自动存一次中间权重，这样即使中途断电，损失也最多10个epoch。

6.3 检测效果不佳的常见原因与排查清单

训练完模型效果不理想，不要急着换模型结构，先按这个清单排查：

1. 数据集标签检查：随机抽100张标注图，人工确认每个框的位置和类别是否准确。标注错误是模型表现差的最常见原因，没有之一；
2. 类别分布检查：统计每一类的目标框数量，看是否存在严重不平衡；
3. 训练曲线检查：看验证集mAP曲线的趋势是否还在上升，如果150个epoch还没收敛，可以加训练轮数或调整学习率；
4. 推理参数检查：置信度阈值是否设置得太高，导致漏检严重；
5. 测试集难度检查：确认测试集和训练集的数据分布是否一致，如果测试集里全是极端角度或极暗画面，模型表现差是正常的；
6. 预处理一致性检查：训练时做了哪些数据增强，推理时是否也做了同样处理（尤其是letterbox的填充方式，训练和推理必须一致，否则检测框会偏移）。

说实话，我见过太多人一上来就研究怎么改进YOLOv8的网络结构，结果连自己的数据都没标对。模型结构改进是锦上添花，数据和标签质量才是决定模型上限的下限。

7. 用YOLOv8做课堂行为检测的一些切身经验

如果让我总结这个项目里最值得说的经验，有这么几条：

第一，类别体系的设计要克制。我最初设计过8个类别，把"举手"分成"右手举手"和"左手举手"，把"读书"和"看屏幕"分开。结果模型精度掉得厉害。后来我把类别合并到6个，把左右手合并，把"看屏幕"直接去掉，模型mAP一下涨了6个点。行为检测不是人类行为学的穷举，而是"够用就行"。

第二，标注质量的标准化比标注数量更关键。有一次我统计发现模型对writing和using_phone的区分一直不好，后来排查才发现是两名标注员对这个边界的行为理解不一致，同一种动作两个人标了不同标签。后来我整理了详细的标注规范文档，配演示图，并且每周抽检标注结果，这个问题才解决。

第三，部署前的推理时间评估不能只看模型推理，还要算上预处理和后处理。预处理里的letterbox缩放、归一化，后处理里的NMS和坐标映射，这些在批量推理时同样烧时间。我在系统里用多线程把预处理和推理并行起来，整体吞吐提升了20%以上。

第四，不要忽略业务侧的规则逻辑。在行为统计里，我加入了"最短持续时间"的规则——某个行为状态必须持续超过3秒才被认定为有效状态。这个规则过滤掉了大量因为学生偶然动作（比如打哈欠时手抬了一下）导致的误判，比调模型阈值靠谱得多。所以行为检测系统从来不是"模型输出什么就是什么"，模型给的是观测，业务侧需要一套平滑逻辑来把观测变成"结论"。

第五，隐私合规是课堂行为检测绕不开的话题。如果你要做的是教室内的日常分析系统，一定要在设计阶段就想好数据脱敏、访问权限、存储周期这些安全措施，系统记录的行为数据必须确保不会泄露个人隐私，部署形态尽量做到"本地分析、不留云端"。这也是我源码里把默认推理模式做成离线模式，不依赖任何云端服务的原因。

整个项目从数据准备到训练、部署、再回到数据修正，我前后迭代了四个版本。回头看，YOLOv8本身只是整条链路里相对稳定的一环，真正的工程量在数据、工程化和业务逻辑上。这篇文章把关键环节和坑都展开写了，希望对正在做类似课堂行为检测项目的同行们有帮助。最后再提一句：源码里的配置文件、训练脚本、推理模块和部署工具都是完整可运行的，你拿到手之后，先别急着改结构，用自己的数据完整跑一遍流程，等跑通了再回头优化，这是最高效的实践路径。

本文还有配套的精品资源，点击获取