PyTorch+ResNet18实现司机危险驾驶行为识别告警系统

简介这是一份基于深度学习实现的司机危险驾驶行为识别告警系统完整项目评审得分98分适合正在准备毕业设计、课程设计或期末大作业的计算机相关专业学生也适合希望积累实战经验的学习者。项目围绕驾驶场景中的分神、打电话、吸烟、打哈欠等危险行为构建检测流程通过SSD目标检测模型与MobileNet等网络实现人脸及行为识别并通过GUI界面展示告警结果。资源包共64个文件压缩包约212.52MB涵盖12个Python源码文件、13个编译缓存文件同时包含预训练权重pth、h5、hdf5与模型配置文件内置7个测试视频和一批jpg测试图片可帮助快速复现并验证效果。代码附带详细注释与文档说明目录结构清晰按数据记录、模型权重、界面逻辑等模块划分便于理解与二次开发。目前已有274人学习使用适合作为完整项目参考。1. 先说清楚这个项目在做什么解决什么问题拿到“基于深度学习的司机危险驾驶行为识别告警系统”这个标题第一反应不是模型选什么而是它到底解决谁的什么问题。真实场景是货运车队、网约车平台、运输公司都想知道司机在开车时有没有打电话、看手机、喝水、抽烟、打瞌睡光靠行车记录仪拍路面没用得有一路摄像头对着司机实时判断行为并告警。这就是这个项目的核心——用深度学习模型对驾驶舱内画面做行为分类命中危险行为就弹窗告警。做成 Python 工程套上 GUI意味着这套东西不是只停留在一段推理代码而是能双击运行、接上摄像头就能用的完整工具适合课题、毕设也适合小规模车队做原型验证。开源的源码包里通常已经有训练好的权重、GUI 界面和注释你要做的是把它吃透、调好、跑在自己的数据上。2. 用 PyTorch 微调 ResNet18 识别危险驾驶行为先让模型“看得懂”“识别告警系统”里最难的一块就是识别。告警逻辑再完善模型认不出“开车看手机”和“正常看前方”的区别后面全是空话。所以第一件事是把模型定下来、训练出来并且把训练到部署的全链路参数讲清楚。这里我用最常见的做法基于公开数据集微调一个轻量级 CNN 分类模型而不是自己从零搭网络。2.1 行为类别怎么定别只盯着“打电话”打开这个方向的开源代码最常看到的类别划分来自那个经典的驾驶员分心数据集Kaggle 上的 State Farm Distracted Driver Detection 竞赛通常分成“正常驾驶”“右手发消息”“左手发消息”“右手打电话”“左手打电话”“操作收音机”“喝水”“伸手拿后座物品”“化妆”“和乘客说话”这 10 类。为什么我说别只盯着打电话因为实际落地你会发现真实车队的告警需求是分层的——最危险的是长时间低头看手机其次是打电话、喝水然后是伸手拿后座东西。类别定多了模型学不过来告警也不好定优先级类别定太粗比如只写“危险”和“安全”司机和安全管理又觉得不直观。所以推荐的做法是先定 5 到 6 个类别正常驾驶、手持打电话、看手机/发消息、喝水吃东西、操作中控面板、转身拿东西。这个划分既覆盖了法规里明令禁止的行为也兼顾了车队最常关注的场景。框架代码里类名建议直接写在配置文件的 CLASS_NAMES 里别散落在多个文件里后续改类别只需要动一处。训练数据的分法也要注意——同一个司机在训练集和验证集里同时出现会导致验证指标虚高。按司机 ID 分组划分而不是按帧划分这是这个方向最容易忽视的一个细节。很多参考工程都是 shuffle 后按比例分割这样同一司机的画面会同时落在两个集合里模型记住的是这个人而不是这个行为。2.2 数据集准备公开数据集为主、自采为辅的落地做法常见做法是先把公开数据集作为预训练基础再用自己摄像头录 1 到 2 小时驾驶舱视频做微调。视频要覆盖不同光线白天逆光、傍晚、地下车库。录的时候让司机真的做动作、而不是摆拍摆拍出来的动作和真实驾驶习惯差很多模型上线会翻车。先给出训练数据的目录组织方式这也是这类源码项目里最常见的数据组织形态data/ train/ normal/ phone_hand/ phone_text/ drink_eat/ operate_panel/ turn_back/ val/ normal/ phone_hand/ ...训练前先做一步预处理把图片统一缩放到 224x224并在训练时做随机增强。下面这段是数据加载部分最常见的写法我一般直接用一个带增强的 ImageFolder 来读from torchvision import datasets, transforms from torch.utils.data import DataLoader train_transform transforms.Compose([ transforms.Resize((224, 224)), transforms.RandomHorizontalFlip(p0.3), # 模拟左右手不同习惯 transforms.RandomRotation(degrees5), # 轻微旋转提升鲁棒性 transforms.ColorJitter(brightness0.2, contrast0.2), # 适应光线变化 transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) val_transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) train_data datasets.ImageFolder(data/train, transformtrain_transform) val_data datasets.ImageFolder(data/val, transformval_transform) train_loader DataLoader(train_data, batch_size32, shuffleTrue, num_workers4) val_loader DataLoader(val_data, batch_size32, shuffleFalse, num_workers4)这段代码的逻辑ImageFolder 按目录名自动生成类别标签目录名就是类名省去手写标签映射。增强里我只开了水平翻转、小角度旋转和亮度对比度抖动没开 RandomResizedCrop原因是驾驶舱画面里司机的人脸和手部位置相对固定过强的裁剪会让模型学到错误的部位信息。几个参数值得注意batch_size32 在普通消费级显卡如 6 到 8G 显存上配合 ResNet18 刚好合适显存小就降到 16。RandomHorizontalFlip(p0.3) 之所以不设成 0.5是因为有些动作左右手不对称比如左手持手机、右手操作挂挡翻转太频繁会让模型混淆方向。num_workers4 是读取图片的线程数Windows 下建议设为 0否则容易报 DataLoader worker 错误。2.3 训练参数六组关键参数与调法模型结构上我一般选 ResNet18 而不是 ResNet50 或更深的网络。理由有三个驾驶舱行为识别输入是单摄像头画面不要求 ImageNet 那种千类粒度ResNet18 最后一层特征已经够用延迟敏感在 CPU 上 ResNet18 跑一帧在 100ms 左右ResNet50 要接近 300ms源码工程多半还要再接 GUI 和告警线程模型推理不能独占太多 CPU。下面是一段可以直接跑的训练主循环用预训练权重微调最后替换全连接层输出类别数import torch import torch.nn as nn import torch.optim as optim from torchvision import models model models.resnet18(weightsmodels.ResNet18_Weights.IMAGENET1K_V1) num_classes len(train_data.classes) model.fc nn.Linear(model.fc.in_features, num_classes) device torch.device(cuda if torch.cuda.is_available() else cpu) model model.to(device) criterion nn.CrossEntropyLoss() optimizer optim.Adam(model.parameters(), lr1e-4) scheduler optim.lr_scheduler.StepLR(optimizer, step_size5, gamma0.5) for epoch in range(15): model.train() total_loss, correct, total 0.0, 0, 0 for images, labels in train_loader: images, labels images.to(device), labels.to(device) optimizer.zero_grad() outputs model(images) loss criterion(outputs, labels) loss.backward() optimizer.step() total_loss loss.item() * images.size(0) _, preds torch.max(outputs, 1) correct torch.sum(preds labels).item() total labels.size(0) print(fEpoch {epoch1}: loss {total_loss/total:.4f}, acc {correct/total:.4f}) scheduler.step() torch.save(model.state_dict(), model/driver_behavior_resnet18.pth)几个关键参数说清楚lr1e-4 对微调任务来说是把双刃剑小了收敛慢大了会把预训练特征破坏掉。如果发现 loss 前几轮不降可以改成 1e-3 跑两轮再调回来。StepLR 每 5 个 epoch 把学习率减半15 个 epoch 总共衰减两次够用且好调。全连接层输出改为 num_classes6这一步漏了的话验证时会报维度不匹配。这批代码跑完之后val 集准确率能做到 94% 以上就算达标。如果只有 92% 也别急着堆数据先看是不是类别不平衡——操作中控、转身拿东西这类样本天然少最简单的做法是对少样本类别在 DataLoader 里用 WeightedRandomSampler 做加权采样让模型在每轮迭代里看到少量类别的次数更多。3. PyQt5 GUI 主框架从摄像头到告警弹窗的完整链路模型训练好之后接下来就是用 GUI 把这套东西做成一个能交给别人用的工具。这里 GUI 框架我用 PyQt5选它的原因是OpenCV 的 highgui 只能出裸窗口给不了按钮、下拉框、状态栏Tkinter 虽然 Python 自带但摄像头画面实时刷新需要频繁 update做列表和历史记录也很别扭。PyQt5 的 QThread 机制天然适合摄像头取流、模型推理、界面刷新这三件事并行。3.1 三线程架构摄像头取流、推理、告警互不阻塞常见做坏了的源码工程长什么样把摄像头读帧、模型推理、UI 更新全写在一个 while 循环里结果就是摄像头 30 帧的源被模型拖到 5 帧界面一卡一卡告警弹窗直接把程序卡死这就是标准的“黑匣子翻车现场”。我一般这样拆三个线程取流线程只负责 cap.read()把最新一帧放进队列不碰模型。推理线程从队列取帧缩放后输入模型得到类别和置信度通过信号发给主界面。主线程只做 UI 刷新和告警判断。每个环节互不阻塞摄像头不会因为推理慢而丢帧堆积。下面是取流线程的写法import cv2 from PyQt5.QtCore import QThread, pyqtSignal class CaptureThread(QThread): frame_ready pyqtSignal(object) def __init__(self, source0, parentNone): super().__init__(parent) self.source source self.running True def run(self): cap cv2.VideoCapture(self.source) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) while self.running and cap.isOpened(): ret, frame cap.read() if not ret: continue self.frame_ready.emit(frame) cv2.waitKey(10) cap.release()说几个细节采集分辨率故意压到 640x480 而不是 1080p因为行为识别不需要看清司机脸上的毛孔1080p 每一帧在推理端都要缩放白费 CPU。waitKey(10) 是控制取流节奏的理论上 30fps 的源每帧间隔 33ms设 10ms 足够。如果不用 waitKey某些摄像头驱动会热得厉害。推理线程稍微复杂一点因为要处理模型加载、预处理和推理三件事。加载模型放构造函数里做不要在 run 里反复加载import torch import torch.nn.functional as F from torchvision import transforms import numpy as np class InferenceThread(QThread): result_ready pyqtSignal(str, float) # 类别名, 置信度 def __init__(self, model_path, class_names, parentNone): super().__init__(parent) self.model self._load_model(model_path) self.class_names class_names self.running True self.queue queue.Queue(maxsize2) def _load_model(self, model_path): from torchvision import models import torch.nn as nn model models.resnet18() model.fc nn.Linear(model.fc.in_features, len(self.class_names)) model.load_state_dict(torch.load(model_path, map_locationcpu)) model.eval() return model def run(self): while self.running: try: frame self.queue.get(timeout0.5) except queue.Empty: continue if frame is None: continue img cv2.resize(frame, (224, 224)) img_rgb cv2.cvtColor(img, cv2.COLOR_BGR2RGB) tensor torch.from_numpy(img_rgb).permute(2, 0, 1).float().div(255.0) tensor transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225])(tensor) with torch.no_grad(): output self.model(tensor.unsqueeze(0)) prob F.softmax(output, dim1) conf, idx torch.max(prob, 1) self.result_ready.emit(self.class_names[idx.item()], conf.item())这个线程有两个容易踩的坑。第一个是模型 load_state_dict 时如果之前训练保存的是带 module 前缀的权重用了 DataParallel 训练这里会报 key 不匹配解决方法是保存前先 model.module.state_dict()或者加载时做一个 key 过滤。第二个是预处理顺序要先 BGR 转 RGB 再做 Normalize很多人先归一化再转通道结果整个画面颜色反了识别结果直接崩。3.2 告警逻辑连续 N 帧命中才触发别让一次性误报吵到司机告警是这套系统里最容易被低估的模块。很多人拿到源码直接把“模型输出危险类别 置信度 0.7”当成告警条件结果是什么司机手里拿着矿泉水瓶正常喝水被识别成 drink告警响了阳光在司机脸上形成阴影模型抽风给了个 phone_text又响了。告警太敏感司机直接把系统关掉整条链路白做。我的做法是加一个“连续命中计数”逻辑连续 5 帧以上命中同一危险类别才触发告警。5 帧按 10fps 的推理速度就是 0.5 秒足够过滤掉单帧误报又不会漏掉真实危险行为。下面这一段是告警判断的参考实现class AlertMonitor: def __init__(self, threshold0.7, hit_count5): self.threshold threshold self.hit_count hit_count self.current_hits {} self.alerted set() def update(self, class_name, confidence): if confidence self.threshold: self.current_hits {} return None self.current_hits[class_name] self.current_hits.get(class_name, 0) 1 if (self.current_hits[class_name] self.hit_count and class_name not in self.alerted): self.alerted.add(class_name) return class_name return None def reset(self, class_name): self.alerted.discard(class_name)这个 AlertMonitor 的精髓在于当前命中计数器是全局字典而非单类别一个数因为模型在连续帧里偶尔会在两个危险类之间横跳加个字典能容纳轻微抖动。告警过一次的类别记录在 alerted 里防止同一行为连续触发 10 次弹窗直到 reset 才会重新告警。reset 的时机一般是检测到安全类别时调用——司机把手机放下系统就解除警报下次再拿手机才能再响。参数上threshold0.7 和 hit_count5 是我在真实视频上验证过比较稳妥的组合。阈值太高容易漏报比如司机转头时侧脸图片模型天然低置信度太低全是误报。如果部署场景是边开车边用建议把 hit_count 提到 8宁可晚 0.3 秒告警也要把误报压下来。3.3 界面布局与运行参数把关键开关放出来GUI 界面不追求好看但要让使用者一眼知道当前状态。参考这个方向常见源码工程的布局我一般放五个区域实时视频预览区、当前行为标签大字显示“正常驾驶/危险行为”、置信度条、告警历史列表、启动/停止按钮和摄像头源下拉框。关键参数别写死在代码里放 GUI 上让用户调from PyQt5.QtWidgets import (QMainWindow, QLabel, QPushButton, QComboBox, QListWidget, QSlider) class MainWindow(QMainWindow): def __init__(self): super().__init__() self.capture_thread None self.inference_thread None self.camera_source QComboBox() self.camera_source.addItems([摄像头 0, 摄像头 1, 视频文件]) self.frame_interval QSlider() self.frame_interval.setRange(1, 20) # 每 N 帧推理一次 self.alert_list QListWidget()frame_interval 这个滑块很有用——实际部署时如果 CPU 性能不够可以每 3 帧甚至每 5 帧做一次推理画面预览依然是全帧率只是行为识别的判断频率降下来。这是牺牲实时性换流畅度的常用手段。4. 从单帧识别到实时告警推理速度与准确率的三个必调点模型在图片上准确率高不代表在实时视频流里表现好。这一章把从“离线验证”到“实时告警”之间最关键的三个调整点写清楚这些都是这个方向源码工程里最常被忽略的部分。实时性不够再准的模型也只是一堆离线数字。4.1 摄像头参数设置曝光、白平衡和帧率摄像头对着司机最大的敌人是逆光——车前挡玻璃透进来的阳光会让司机脸部过曝模型基本认不出行为。常见做法是关掉自动曝光手动固定一个偏暗的曝光值同时把白平衡固定成固定模式cap cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) cap.set(cv2.CAP_PROP_FPS, 15) cap.set(cv2.CAP_PROP_AUTO_EXPOSURE, 0.0) # 关闭自动曝光 cap.set(cv2.CAP_PROP_EXPOSURE, -4.0) # 具体值视摄像头而定抓三个关键点FPS 如果源只支持 30fps 而取流线程设了 15fps有些驱动会自动跳回 30要在循环里实际读一次 ret 来判断曝光值在 Windows 下是相对值不同摄像头厂商的取值范围不一样建议先跑一段打印 cap.get(cv2.CAP_PROP_EXPOSURE) 看看范围再调USB 摄像头长时间运行会过热掉帧程序界面上最好加一个显示“最近 1 分钟平均推理帧率”的标签数据异常时用户能马上知道是摄像头问题。4.2 推理速度优化三个手段按顺序上实时系统里推理速度决定了系统的可用性。优化手段我一般按性价比排序第一把模型切到 ONNX Runtime。PyTorch CPU 推理有大量框架开销ONNX Runtime 在 x86 CPU 上能把单帧延迟从 120ms 压到 60 到 70ms。导出步骤很简单import torch from torchvision import models import torch.nn as nn model models.resnet18() model.fc nn.Linear(model.fc.in_features, 6) model.load_state_dict(torch.load(model/driver_behavior_resnet18.pth, map_locationcpu)) model.eval() dummy torch.randn(1, 3, 224, 224) torch.onnx.export(model, dummy, model/driver_behavior_resnet18.onnx, input_names[input], output_names[output], opset_version11, dynamic_axes{input: {0: batch}})导出的 ONNX 用 onnxruntime 推理原来 torch.no_grad() 那段代码换成 ort_session.run 就会快一大截。注意 onnx 导出时如果模型是 GPU 上训练的要先 map_location 到 cpu否则导出的 onnx 里会带 CUDA 算子在纯 CPU 部署环境直接报错。第二输入分辨率从 224 降到 160。行为识别这种粗粒度分类任务160x160 和 224x224 的准确率差距通常不超过 1%但推理时间能再省三分之一。训练时用 224 的模型部署时用 160 的输入置信度会整体偏低一点阈值可以相应调低 0.03 到 0.05。这个技巧在源码工程里通常写在配置文件的 input_size 里改一行就能生效。第三如果还慢就把主干网络换成 MobileNetV3-Small。ResNet18 在 CPU 上已经很快但 MobileNet 可以做到 20ms 以内。做法是把前面 2.3 节里的 models.resnet18 替换成 torchvision.models.mobilenet_v3_small分类头改成线性层其余代码不用动。代价是准确率会掉 1 到 2 个百分点但换来了在低端工控机上流畅运行的能力。4.3 从误报中做增量迭代告警历史是免费数据集这是这类项目迭代最快的一个手段。每一条告警记录都把触发前后各 10 帧的图片保存到本地目录按“类别_日期_序号”命名。跑一周你会积累几百张真实场景下的危险行为样本这些样本的价值远大于公开数据集——因为它们和你的摄像头视角、光线条件、司机习惯完全一致。保存告警帧的代码可以挂在告警触发点def on_alert(self, class_name, frame): import os, time folder falert_samples/{class_name} os.makedirs(folder, exist_okTrue) filename f{class_name}_{int(time.time())}.jpg cv2.imwrite(os.path.join(folder, filename), frame)这些样本积累到一定数量每个类别 200 张以上就把它并进训练集重新微调一轮。两三轮之后系统在你自己的场景里的表现会明显超过从公开数据集训练出来的模型。这就是这套系统“越用越准”的关键路径也是源码工程项目里最值得保留的设计习惯。5. 避坑指南这些坑在部署时最容易翻车这类项目的源码可能写得很漂亮但拿到真环境里跑问题几乎都出在环境、硬件和真实场景的差异上。以下五条是我积累的踩坑记录按现象、原因、解决三段式展开新手可以直接当排查手册用。5.1 现象PyTorch 装完程序一运行就提示 DLL load failed原因Windows 下安装 PyTorch 时如果用的是不带 CUDA 的 pypi 源装出来的包默认依赖的 Visual C 运行库版本不对或者 Python 3.8 配了最新版 torch版本不匹配。这类“黑匣子”问题最耗时间。解决先卸载重装 CPU 版pip uninstall torch torchvision pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu如果还报错大概率是 Python 环境问题建议直接用 anaconda 创建干净环境conda create -n driver python3.9再装依赖。项目源码里如果有 requirements.txt先看版本别盲目装最新。这一步解决了后面大部分运行问题都不会再出现。5.2 现象摄像头预览正常但推理结果全是同一个类别原因多数是预处理和数据流方向的 bug。最常见的两个一是前文提到过的 BGR/RGB 顺序搞反OpenCV 读出来是 BGR直接转 Tensor 后模型看到的是通道错乱图二是取流线程和推理线程共用一个队列但队列里存的是同一个 frame 对象的引用推理还没跑完下一帧就覆盖了数据。解决一是预处理里显式加 cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)二是队列用 queue.Queue(maxsize2)放帧时 frame.copy()消费完再清掉避免覆盖。这两个改完问题基本能消除。5.3 现象白天基本正常傍晚和夜间误报剧增原因模型训练数据多是白天光照环境夜间红外或低照度下的画面分布完全不同。另一个因素是仪表盘灯光、路灯频闪造成的画面闪烁会让模型输出置信度在类别之间跳变。解决一是夜间场景单独建一个阈值体系置信度阈值从 0.7 提高到 0.8hit_count 从 5 提到 10用更严格的条件换更低的误报二是积累夜间样本做二次微调方法就是 4.3 节那套。如果摄像头支持红外模式但默认没开检查驱动设置别在代码里硬切。真实夜间跑下来误报率能压到和白昼接近的水平。5.4 现象GUI 点击“停止”按钮后程序不再响应原因这是 PyQt5 多线程最经典的坑。停止按钮的槽函数里把线程的 running 标志位设为 False但线程还阻塞在 cap.read() 或 queue.get() 上没有机会退出循环于是线程没有回收界面就假死了。解决在 run 循环里把阻塞操作改成带超时的读取import queue try: frame self.frame_queue.get(timeout0.5) except queue.Empty: continue同时在线程的 run() 末尾加 self.finished.emit()主界面在 finished 信号槽里做 thread.wait()。这样点停止后 0.5 秒内线程必定退出不会卡死。这是 PyQt5 多线程停止操作的后悔药写 GUI 线程时先把这条记住。5.5 现象同一套代码换一台电脑性能差一半原因大多数和硬件相关。CPU 推理时PyTorch 在没有检测到 AVX/AVX2 指令集的旧 CPU 上会自动退回慢速内核另一个是摄像头驱动不同品牌摄像头在同分辨率下的 USB 带宽占用策略不同。解决检查 CPU 是否支持 AVX2检查推理线程是不是被 PyQt 主线程的定时器抢占——把推理线程的优先级调高QThread.setPriority(QThread.HighPriority)。如果换了品牌摄像头性能骤降打开任务管理器看谁在占用 CPU十有八九是摄像头驱动在后台做软件编码。这一步排查完性能差异通常能缩到 20% 以内。6. 验收与进阶用一段真人视频检验这套告警系统是否值得投入6.1 两个验收指标检出率和告警延迟判定这套系统能不能投入我只看两个数据。一是“危险事件检出率”让司机在镜头前做 10 次看手机、8 次喝水系统至少检出 8 次以上才算合格二是“告警延迟”从司机拿起手机到系统弹窗不超过 2 秒。这两个指标一卡很多训练精度 90% 以上但告警逻辑写得粗糙的源码工程立刻现原形。检出不达标是模型问题延迟超标是工程问题两个维度分别优化别混在一起调。6.2 一个可复现的验收脚本用一段自己录的视频做离线验收比对着摄像头反复试要稳定得多。录 10 分钟驾驶舱真人视频标注出每段危险行为的起止时间再写个脚本跑推理核对告警时间点。这个脚本本身不复杂核心逻辑是读视频逐帧推理命中危险行为时记录时间戳与标注的时间窗口做比对落在窗口内就算一次检出。标注文件的格式可以用简单的 JSON每段标注记录 start_time、end_time、class_name 三个字段。这个验收脚本的价值在于把它沉淀到项目里每次改完模型或告警参数都能跑一遍对比。不加这个脚本谁都能说自己“识别准确率高”配上可复现的验收流程数字就骗不了人了。6.3 下一步值得投入的三个方向如果这套系统跑通了再往上走有三个方向性价比最高。第一个是加上疲劳检测——闭眼和打哈欠的时序模式用 OpenCV 的人脸关键点 68 点就能做一个可用版本不用换模型架构只需在现有 GUI 里加一个“疲劳状态”标签。第二个是把识别结果接入车队管理后台告警记录上传、生成日报这是从“工具”变成“产品”的关键一步。第三个是在树莓派或 Jetson Nano 这类小主机上跑通用 ONNX Runtime 加 MobileNet 替换把整套系统做成一个盒子——司机上车插电就工作不需要一个台式机放在副驾。这套系统值不值得投入我的态度是如果只是为了演示那别投入太多时间在 GUI 上训练好模型、写好告警逻辑就够了如果能收集到足够多的真实驾驶舱视频这个方向是可以持续迭代的——因为每一次误报都会变成训练数据每一次漏报都能定位到具体是感知还是判断环节的问题。我自己做完这套东西最大的教训是别在模型结构上反复折腾先把手头数据用透把告警链路调到不惹人烦大多数问题就解决了。希望帮到你。本文还有配套的精品资源点击获取