企业官网建设流程全解析

简介：面向Python课程设计/毕业设计的违规驾驶行为识别系统完整项目包，适合计算机、人工智能专业学生快速搭建可演示、可扩展的驾驶行为分析原型。资源围绕驾驶员状态检测与违规行为判别流程，提供识别模型源码、训练/推理脚本、依赖环境配置与数据库文件，覆盖数据预处理、模型训练到结果输出完整环节，便于直接部署运行。包体共收录128个文件，压缩包约64.93MB。核心由81个py源码文件构成，包含模型定义、主程序逻辑和功能模块；8个sh脚本用于环境初始化或一键启动；5个md/4个txt提供项目介绍、使用说明和技术笔记；4个pkl、2个npy与2个pth存放预处理数据、特征文件及模型权重，png图片展示界面或结果示例，zip内附相关依赖或数据集。目前已有295人学习/下载，适合正筹备毕设或课程项目的学生参考。通过完整源码、数据库及附带脚本，可快速获得可运行的违规驾驶行为识别系统，既学习基于Python的视觉行为分析实现思路，也能在此基础上补充检测逻辑、扩展数据集或改进模型，节省从零搭建时间。

1. 违规驾驶行为识别系统：一个毕设压缩包背后的完整工程链路

收到一份“Python毕业设计-违规驾驶行为识别系统源码+数据库.zip”，多数人的第一反应是解压、装依赖、跑通 demo。但这类系统真正的分量在别处：它从车载摄像头或监控视频流里检测驾驶员有没有打电话、抽烟、喝水，再把违规事件写进数据库，最后留出回放和统计界面。想做毕业设计的人会把它拆成“模型训练 + 系统集成”两个阶段；想借此入门目标检测的从业者，则能在这里看到一条从 YOLO 权重到 MySQL 落库再到 TensorRT 加速的完整链路。这篇文章就把这条链路逐段拆开讲，哪些代码可以直接抄，哪些参数是需要反复试的玄学，以及我踩过的几个典型坑。

2. 系统拆解与技术选型：先从 YOLO 说起，再谈数据库怎么设计

2.1 检测算法选型：为什么 YOLOv8 是起步首选，而不是自己从头训 CNN

违规驾驶行为识别，本质是找“人”和“物”的位置关系。常见做法是用目标检测模型同时框出驾驶员的脸、手、手机、水杯，再用规则判断这些目标之间的位置关系是否构成违规。选检测模型时，我建议直接上 YOLOv8，原因有三条：推理速度快、预训练权重成熟、Python 接口封装得干净，适合在毕业设计周期内做出效果。YOLOv5 也可以，但如果你不需要改 C++ 部署，v8 的ultralytics包在数据集管理和回调上更省事。

从头训练一个自定义 CNN 是最不建议走的路：你需要远超毕设体量的数据、调参时间，还要处理类别不均衡。OpenCV 的肤色检测、背景差分这些传统手段只能做辅助，比如用来判断“画面中是否有手出现在方向盘区域”，但真正决定系统能不能用的，还是 YOLO 这类深度模型。

实际选型时，建议先用yolov8n.pt预训练权重跑通整套流程，再把模型换成yolov8s或m看精度收益。不要把起步参数定得太大，否则后面每次尝试都会带着漫长的训练等待。

2.2 行为识别改成两阶段：检测加规则，而不是一个端到端分类网络

很多刚开始做这个题目的人，喜欢直接拿一个分类网络，输入是驾驶员图片，输出是“正常、打电话、抽烟、喝水”四类。这种方案的问题在于：分类网络输出的是全局概率，你无法解释为什么被判成“打电话”，也无法在夜间或遮挡场景下做局部修正。一旦某个类别误报偏高，你只能换模型或加数据，排查像摸黑。

我一般用两阶段方案：第一阶段用 YOLO 检测hand,face,phone,cup,mouth这些目标；第二阶段用坐标关系做判定。判定规则可以很朴素，比如手机框与手框的交并比大于阈值，且手机中心落在脸框附近，就判为“打电话”。这个规则是透明的，出了问题可以直接调坐标逻辑。

def judge_behavior(detections, frame_w, frame_h): # detections: [cls_id, x_center, y_center, w, h] 归一化坐标 hand_boxes = [d for d in detections if d[0] == 0] phone_boxes = [d for d in detections if d[0] == 1] cup_boxes = [d for d in detections if d[0] == 2] face_boxes = [d for d in detections if d[0] == 3] for hand in hand_boxes: for phone in phone_boxes: if iou(hand[1:], phone[1:]) > 0.3: return "using_phone" for cup in cup_boxes: if iou(hand[1:], cup[1:]) > 0.25: return "drinking" return "normal"

这段代码的逻辑是：先按类别把检测框分组，然后用手框分别和手机框、水杯框算 IoU。注意这里的 IoU 阈值不能照搬模型训练的 0.5，因为手和手机本来就是黏在一起的，IOU 能到 0.3 已经非常可疑。参数0.3和0.25是我常用的起点值，实际项目里要拿真实视频的标注帧去统计，而不是拍脑袋定。

为什么说两阶段比端到端分类更稳？因为规则可以叠加，比如连续K帧都触发才报警，能过滤掉单帧抖动；分类网络想做到时序平滑，就得引入 LSTM 或更复杂的结构，对毕设来说性价比不高。

2.3 数据库怎么设计：三张表就够，别一上来就做权限和后端框架

数据库在这个项目里承担的是“事件落库”职责。常见误区是一上来就设计用户表、角色表、日志表，搞得像要做一个 SaaS 平台。实际上一个违规驾驶识别系统，核心只有三张表：驾驶员信息表、识别事件表、事件截图或证据表。

下面是 MySQL 建表语句，字段按最小可用原则设计。

CREATE TABLE driver_info ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(32) NOT NULL, driver_license_no VARCHAR(18) UNIQUE, vehicle_plate VARCHAR(12) ); CREATE TABLE violation_event ( id INT PRIMARY KEY AUTO_INCREMENT, driver_id INT NOT NULL, behavior_type VARCHAR(16) NOT NULL, confidence FLOAT NOT NULL, frame_no INT NOT NULL, timestamp DATETIME NOT NULL, FOREIGN KEY (driver_id) REFERENCES driver_info(id) ); CREATE TABLE violation_evidence ( id INT PRIMARY KEY AUTO_INCREMENT, event_id INT NOT NULL, image_path VARCHAR(255) NOT NULL, video_segment_path VARCHAR(255), FOREIGN KEY (event_id) REFERENCES violation_event(id) );

建表时我特意把timestamp设为 DATETIME 而不是 INT，因为后期要用 SQL 直接按天统计违规数量，DATETIME 在GROUP BY DATE(timestamp)时更顺手。外键关系在毕设规模下不会成为性能瓶颈，但请记住为violation_event.timestamp建索引，否则事件量过万后查询会肉眼可见变慢。数据库连接用 SQLAlchemy 或 PyMySQL 都可以，但别在主循环里逐条 commit，这个坑后面避坑章节展开。

2.4 源码包解压后应该看到的目录结构

拿到一个合格的此类项目源码包，里面至少包含这几块：检测模型训练代码、推理服务代码、数据库脚本、Web 展示端、配置文件。合理目录结构如下。

distracted_driver_detect/ ├── config/ │ ├── dataset.yaml # 数据集路径与类别定义 │ └── system.yaml # 置信度、触发帧数、数据库连接串 ├── data/ │ ├── raw/ # 原始视频抽帧 │ ├── labels/ # 标注后的 txt / xml │ └── processed/ ├── models/ │ ├── yolov8n.pt │ ├── yolov8s.pt │ └── best.pt # 训练产出 ├── scripts/ │ ├── convert_voc2yolo.py │ └── train.py ├── service/ │ ├── detect_loop.py # 视频流推理 │ ├── behavior_rule.py # 行为判定规则 │ └── db_writer.py # 数据库异步写入 ├── web/ │ └── app.py # Flask 事件展示 └── requirements.txt

目录拆分的原则是各模块独立可测：训练代码和推理代码分离，规则判断从主循环里抽出来，数据库写入做成独立模块。这样你后面换数据集、换模型、换数据库，都不会牵一发动全身。很多下载的源码包结构混乱，训练和推理混在一个文件里，扩展时会非常痛苦。

3. 从数据集到训练闭环：把识别模型真正训出来

3.1 数据集选型：公开数据加自采数据的组合策略

训练违规驾驶识别模型，公开数据集中最知名的是 State Farm Distracted Driver Detection 竞赛数据，它提供了约 2 万张驾驶员图像，按 10 类分心行为标注，包括正常驾驶、发短信、打电话、喝水、化妆、整理头发等。但注意这是个分类数据集，标签没有目标框，你要用它训练 YOLO 必须自己画框或用半自动工具预标注。这是第一步坑：很多人下载完数据才发现不能直接丢给 YOLO 跑。

我的组合策略是：公开分类数据按类别抽取 30% 作为背景多样性的补充；主数据用车载监控视频自采抽帧，大概每 5 秒抽一帧，手动标注 2000 到 3000 张。自采数据必须覆盖不同时间段和光照条件，否则模型只会在“白天、晴天、固定机位”下表现好。类别建议只做 4 类起步：正常、打电话、抽烟、喝水。做得太细如“化妆”“整理头发”会导致类别间特征重叠严重，模型训出来边界模糊，误报反而增加。

标注工具用 LabelImg 或 X-AnyLabeling 都可以。标注时有一个容易被忽略的规则：目标被遮挡超过一半就别标，硬标进去的框会让模型学着在遮挡区域产生错误预测。

3.2 标注格式转换：VOC XML 转 YOLO txt 的脚本

LabelImg 保存的默认格式是 Pascal VOC XML，而 YOLO 系列需要的是归一化的 txt 文件。这个转换脚本几乎每个项目都要写一遍，我直接给你一份可用的。

import xml.etree.ElementTree as ET import os def voc_to_yolo(xml_path, out_dir, classes): tree = ET.parse(xml_path) root = tree.getroot() img_w = int(root.find("size/width").text) img_h = int(root.find("size/height").text) txt_name = os.path.basename(xml_path).replace(".xml", ".txt") out_path = os.path.join(out_dir, txt_name) with open(out_path, "w") as f: for obj in root.findall("object"): cls_name = obj.find("name").text if cls_name not in classes: continue cls_id = classes.index(cls_name) box = obj.find("bndbox") xmin = int(box.find("xmin").text) ymin = int(box.find("ymin").text) xmax = int(box.find("xmax").text) ymax = int(box.find("ymax").text) # 归一化到 0~1 x_center = (xmin + xmax) / 2 / img_w y_center = (ymin + ymax) / 2 / img_h w = (xmax - xmin) / img_w h = (ymax - ymin) / img_h f.write(f"{cls_id} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}\n") if __name__ == "__main__": xml_dir = "data/labels/voc" yolo_dir = "data/labels/yolo" os.makedirs(yolo_dir, exist_ok=True) classes = ["normal", "hand", "phone", "cup", "face"] for xml_file in os.listdir(xml_dir): if xml_file.endswith(".xml"): voc_to_yolo(os.path.join(xml_dir, xml_file), yolo_dir, classes)

脚本逻辑很直白：读 XML 里的目标框坐标和图片宽高，把绝对坐标换算成 0 到 1 的归一化中心点坐标和宽高，并按类别 ID 输出成一行一个目标的 txt。转换时有一个常见问题：YOLO 要求类别 ID 连续从 0 开始，如果你的 classes 列表中间少了某个类别，后续训练的类别映射就会错位。另一个常见问题是忘了过滤不在目标类别里的对象，比如数据里偶然标了“background”类，会在训练时报错。

转换完成后按 8:1:1 划分 train / val / test 目录，注意划分时保证同一段视频的帧只进其中一个集合，否则视频相邻帧出现在训练集和测试集里，评估指标会虚高。

3.3 用 YOLOv8 训练的最小可运行流程

数据集准备好后，训练闭环其实就三个命令：写 data.yaml、调用yolo命令、等 best.pt 产出。先看 data.yaml。

path: ./data # 数据集根目录 train: images/train val: images/val test: images/test names: 0: normal 1: hand 2: phone 3: cup 4: face

这里path指向你数据集的绝对或相对根目录，train、val、test路径是相对path的目录名。特别注意类别定义顺序必须和前面转换脚本里的classes列表一致，改一个都会造成灾难性的标签错位。

训练命令如下。

yolo detect train \ data=config/dataset.yaml \ model=yolov8n.pt \ epochs=50 \ imgsz=640 \ batch=16 \ patience=15 \ device=0 \ project=runs/detect \ name=exp_driver

重点参数逐个说明。model=yolov8n.pt不是从零开始，而是用 COCO 预训练权重做迁移学习，这是收敛速度的关键。imgsz=640是输入分辨率，如果后面发现小目标比如手里的手机经常漏检，可以提到 960 或 1280，代价是训练和推理速度都下降。patience=15表示验证集指标连续 15 轮没有提升就提前终止训练，规避过拟合。batch=16在 8GB 显存下配yolov8n基本安全，如果显存不足先调 batch，不要先调 imgsz。

训练结束后，产物在runs/detect/exp_driver/weights/下有两个权重：best.pt和last.pt。做系统集成时只认best.pt，别为了“多训几轮”去加载 last 权重。

3.4 训练参数与过拟合控制：一张参数表说清调优边界

训练完之后，调参是另一个反复试错的过程。我把常用参数和被验证过的范围列成表，新手可以直接按这个区间去试。

关于类别不均衡，比如“抽烟”样本远少于“打电话”，在 data.yaml 或训练命令里可以对cls_pw按权重列表赋值。YOLOv8 命令行的写法是在参数里拼接列表，比如cls_pw=1.0,3.0,2.5,1.2,1.0，顺序和类别顺序一致。还有一个隐蔽的参数是overlap_mask，如果你不用分割任务可以不管。

每轮训练完，看results.csv里的mAP50、mAP50-95和各类别的F1曲线。如果只看总 mAP 容易踩坑：phone 类别的 AP 往往最低，但恰恰是最关键的违规证据。

4. 把模型接进系统：视频推理、行为判定与数据库落库

4.1 视频流推理主循环的代码骨架

模型训练完，接下来就是把它接进系统。最简单的推理主循环从 OpenCV 读视频帧开始，送入 YOLO 模型推理，再交给规则模块判定。下面这个骨架是单路视频的最小可用版本。

import cv2 from ultralytics import YOLO model = YOLO("models/best.pt") cap = cv2.VideoCapture(0) # 摄像头或视频文件 conf_thres = 0.35 iou_thres = 0.45 while True: ret, frame = cap.read() if not ret: break results = model.predict( frame, conf=conf_thres, iou=iou_thres, verbose=False ) dets = results[0].boxes.data.cpu().numpy() # 转换为行为判定模块需要的格式 parsed = [[int(box[5]), box[0], box[1], box[2], box[3]] for box in dets] behavior = judge_behavior(parsed, frame.shape[1], frame.shape[0]) if behavior != "normal": cv2.putText(frame, behavior, (50, 50), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 0, 255), 2) cv2.imshow("detect", frame) if cv2.waitKey(1) & 0xFF == ord("q"): break

这段代码的要点是：model.predict接受一帧图像，返回Results对象，其中boxes.data是 [N, 6] 的张量，最后一列是类别 ID。显式指定conf和iou比用默认值可靠，因为行为判定对误报敏感，置信度阈值通常比模型评估时更高。parsed那一行把模型输出转成行为规则模块能直接消费的结构，避免规则模块依赖 ultralytics 的数据格式，这是解耦的关键。

上面是最简单的单线程同步写法，真实场景里摄像头帧率往往不足，瓶颈在于model.predict会阻塞整个循环。进阶做法是用队列把读帧和推理放在两个线程里，读帧线程只负责放入队列，推理线程从队列取帧并计算。这样能抵消大部分图像解码和传输造成的卡顿。

4.2 行为判定逻辑：连续帧触发和事件状态机

单帧判定很容易出现“虚报”：驾驶员只是伸手拿纸巾，就被判定成打电话。解决方法是加入连续帧触发机制，要求同一个行为持续K帧才对外报警。这里给出一个轻量级状态机实现。

class BehaviorTracker: def __init__(self, trigger_frames=5): self.trigger_frames = trigger_frames self.counter = 0 self.current = "normal" def update(self, behavior): if behavior == "normal": self.counter = 0 self.current = "normal" return None if behavior == self.current: self.counter += 1 else: self.current = behavior self.counter = 1 if self.counter >= self.trigger_frames: self.counter = 0 return self.current return None

状态机逻辑是：当单帧行为与上一帧行为一致时计数加一，一旦累计达到trigger_frames帧，就返回一次报警事件；行为切回normal则计数清零。trigger_frames以 5 到 10 帧为宜。如果视频是 25 帧每秒，5 帧相当于 0.2 秒，足够过滤大部分抖动，又不会让真实违规被吞掉。这个值调太大会让短促的打手机动作漏掉，调太小误报会直线上升。

这里有一个容易忽略的变量：model.predict默认会做整图缩放和颜色通道转换，会占用额外时间。如果你追求帧率，可以改用model(frame, device="0", half=True)开启 FP16 推理，速度提升明显但这种做法要求和后面 TensorRT 章节的设备保持一致。

4.3 事件落库：数据库连接池与批量提交

每次报警都实时写数据库，是系统最容易卡死的地方。SQLite 在低并发下能撑住，但一旦改成 MySQL 且事件量增大，每事件逐条 commit 会产生大量磁盘同步操作，阻塞推理线程。正解是引入连接池加批量提交。

from mysql.connector.pooling import MySQLConnectionPool from queue import Queue, Empty pool = MySQLConnectionPool( pool_name="driver_pool", pool_size=3, host="127.0.0.1", database="driver_monitor", user="root", password="yourpass" ) event_queue = Queue() def write_event(driver_id, behavior_type, confidence, frame_no): event_queue.put((driver_id, behavior_type, confidence, frame_no)) def flush_events(): rows = [] while True: try: rows.append(event_queue.get_nowait()) except Empty: break if not rows: return conn = pool.get_connection() cursor = conn.cursor() sql = "INSERT INTO violation_event (driver_id, behavior_type, confidence, frame_no, timestamp) VALUES (%s, %s, %s, %s, NOW())" cursor.executemany(sql, rows) conn.commit() cursor.close() conn.close()

说明一下：event_queue是解耦关键，推理线程只把事件丢进队列，写入由独立线程配合定时器每 3 秒调用一次flush_events完成。executemany批量提交比逐条 commit 减少了几十倍的网络和 IO 开销。pool 的大小通常取 3 到 5，太大不仅浪费连接，还会在并发写时拉低数据库性能。

这是数据库连接池最常见的用法，但要注意：池取出的连接用完必须归还，否则池会耗尽；我这里close()实际上把连接还给池，而不是断开。如果你用的是 SQLAlchemy，它的create_engine自带连接池，pool_pre_ping=True可以检查连接是否失效。

4.4 报警输出与截图回放

检测到违规事件后，要把证据固化下来，否则数据库里光有文字记录没法复核。最简单的固化方式是把报警时刻的视频帧截成 JPG，保存到本地目录，同时把路径写入violation_evidence表。

import os from datetime import datetime evidence_dir = "data/evidence" os.makedirs(evidence_dir, exist_ok=True) def save_evidence(event_id, frame): ts = datetime.now().strftime("%Y%m%d_%H%M%S") path = os.path.join(evidence_dir, f"event_{event_id}_{ts}.jpg") cv2.imwrite(path, frame) return path

这段没什么玄学，但要注意：保存截图和写数据库是两个动作，建议先写数据库拿到event_id再保存文件，最后更新证据表。如果顺序反过来，一旦图片保存失败，数据库会留下一堆没有任何图像证据的事件记录。后面如果再接入 Web 展示端，只需要做一个 Flask 页面从violation_event和violation_evidence两张表里查询并渲染图片路径即可。

5. 避坑手册：五个真实的翻车点与排查思路

5.1 翻车点一：打电话和抽烟互相误报

现象是：驾驶员手拿手机贴近嘴边时，系统有时把手机识别成烟，有时候又把手里的烟识别成手机。原因是手机和烟在低分辨率下外观特征重叠，尤其当 imgsz 只有 640 时，目标在画面里可能只有 20 像素宽，模型根本分不清。

解决这个问题，第一步是把 imgsz 从 640 提到 960 或 1280，这个动作通常能让 phone 类的 mAP 提升 5 个点以上。第二步是在标注时把“手与物体接触区域”单独建一个类，比如hand_with_obj，然后在规则阶段用手部框的类别区分烟和手机，而不是直接依赖 phone 类的置信度。第三步是给嘴部或面部加一个关键点检测模型，当物体框和嘴部框重叠时优先考虑吸烟，避免手机在嘴边被误判。

5.2 翻车点二：夜间和逆光场景下漏检率飙升

现象是白天效果很好，一到傍晚或地下车库就频繁漏检，尤其是暗色手机和手部在暗光下会直接消失。原因很直接：训练集里夜间样本太少，模型学到的主要是白天的颜色和纹理特征。

解决思路不是简单地提亮图像，而是扩充夜间样本。最省成本的做法是先把手头数据随机调整亮度、对比度和饱和度，模拟傍晚和微弱路灯环境，做出来的增强数据能让模型在夜间提升不少。如果真实夜间数据能收集 500 张，全部人工标注，效果会胜过几千张白天图。这里需要提醒的是，增强参数不要拉得太极端导致真实夜间反而过曝，通常亮度抖动范围在原始值的 0.6 到 1.4 倍之间即可。

5.3 翻车点三：训练集分布和真实场景分布不一致

现象是训练时 mAP50 到了 0.92，拿到实车摄像头上一测，漏报率直线上升。原因通常是公开数据集里的摄像头机位在驾驶座侧上方，角度固定，背景干净；而实际部署的机位偏转、座椅位置高低、车内摆件都会让特征偏移。

这类问题没有银弹。我能给到的实操建议是：在部署现场抽帧 200 到 300 张，不用完全标注，只要快速分类筛选出容易出错的场景，再做增量 finetune。如果现场采集困难，就用贴图合成方案，把标注好的手机、烟、水杯合成到真实车内背景上，生成大量带精确标注的伪数据。

5.4 翻车点四：推理只有十几帧，瓶颈不在模型

现象是单看模型推理时间只有 30 毫秒，结果整条视频流处理只有 12 帧每秒。定位后发现卡在 OpenCV 的imread和letterbox缩放上，每帧都要分配新内存做格式转换，Python 层的内存操作反而成了瓶颈。

解决办法有几个层次。最简单的是在进入循环前把推理宽度固定好，让 YOLO 输出的 tensor 复用，避免每帧重新分配。更高收益的做法是把预处理放到 GPU 上，用 CUDA 解码视频，或者直接上 TensorRT 并用固定输入尺寸，详情见第六章。这里先记住一个排查思路：发现帧率低，先看 CPU 占用和线程状态，别直接把锅甩给模型。

5.5 翻车点五：数据库写入拖慢主循环

现象是系统运行十分钟后，延迟越来越大，最后推理线程明显卡顿。原因通常是每检测到一次违规就同步执行一次 SQL INSERT 并且 commit，数据库磁盘 IO 把主循环阻塞了。

解决方法就是在 4.3 节写的连接池加批量写入，事件先入内存队列，3 秒一刷。如果事件量极大导致队列积压，可以加一个丢弃策略：当队列长度超过 5000 时，把最老的事件合并或丢弃，避免内存占用无限上涨，同时记录一条 warning。数据库同步在监控系统里属于下策，队列缓冲是上策。

6. 进阶与验收：TensorRT 加速和“事件级”指标怎么算

6.1 用 TensorRT 跑模型：从 PyTorch 导出到 engine 的关键坑

如果系统要跑在 Jetson 或带 NVIDIA 显卡的盒子上，把 YOLOv8 导出成 TensorRT engine 是值得做的一步。导出命令不复杂，但有几个参数必须留意。

yolo export model=models/best.pt format=engine device=0 half=True imgsz=640 workspace=2

导出后的 engine 文件直接可以被YOLO("models/best.engine")加载，推理时输入输出数据在 GPU 上完成，避免了 CPU 和 GPU 之间反复拷贝。half=True开启 FP16，能带来接近一倍的加速；workspace=2限制 TensorRT 构建时最大显存占用，显存小的机器必须设小一点。有一个容易被忽略的坑：导出 engine 必须在目标机器上做，TensorRT engine 和显卡架构绑定，本机导出到 Jetson 上加载会报错。

加载 engine 后，模型预测的输入尺寸固定为导出时的 640，如果你在预处理时把图像缩放到其他分辨率，检测会直接全部错乱。这也是上一章提到固定输入尺寸的原因。

6.2 事件级验证：mAP 不能说明问题

模型评估看 mAP 没有错，但系统验收不能只看它。对违规驾驶识别来说，更有意义的指标是事件级准确率和召回率。我建议把测试视频按“是否真实发生违规”切成片段，然后看系统在片段级别上的判断。

计算方式是把测试视频里真实违规的时间段标出来，系统每触发一次报警记录一次事件时间，事件起点落在标注段内就算命中。这个验证过程比看 mAP 要费时间，但它是答辩或验收时最拿得出手的证据。

6.3 一个日常习惯：每次训练写实验记录

最后分享一个个人习惯。我每轮训练都会在runs/detect/exp_driver/下保留一份args.yaml和results.csv，同时用一个简单的 markdown 文件记录数据集版本、增强策略、改了什么规则、验证结果如何。

## 2024-11-20 - 数据：自采 2800 张 + 公开抽 1200 张 - 模型：yolov8n imgsz=960 batch=12 - 增强：亮度 0.6~1.4，mosaic 关 - 结果：mAP50 0.89 / 事件级召回 0.80 - 问题：抽烟误报偏高，下一步加 hand_with_obj 类

这样做的好处是，几周后你再拿到一个新版的源码包或换一个数据集，回头翻记录能直接判断当前策略往哪个方向调。这类项目的坑大多来自不可复现的实验过程，而不是模型本身。希望这份笔记能帮你把从模型到数据库的链路顺利走通，少走几段夜路。

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