人物玩手机图片数据集构建与YOLOv8检测实战：从标注到避坑

简介：面向目标检测与行为识别任务的深度学习/机器学习图像数据集，适合训练手机使用行为检测模型的算法工程师与科研人员。数据源自现实场景拍摄与网络收集，由团队自行标注，标注质量高。图片围绕人物持手机状态，设置telephone（手机）、hold（拿着手机）、nohold（没有拿手机）三类目标框，采用VOC格式XML标注，可直接用于YOLO、SSD、Faster R-CNN等检测框架，也方便转为COCO等格式。资源包约2000个文件，主要包含JPG原图与对应XML标注文件，数据量为2015张图片，压缩后约311MB；文件名包含拍摄场景与时间戳信息，便于按时间段划分训练/测试集。目前已有2870人浏览学习，对于低头族行为分析、课堂专注度研究、公共安全监控及驾驶员分心预警等场景，是开箱即用的高质量标注资源。

1. 各种人物玩手机图片数据集：这东西能做什么、不能做什么

做过安防监控或者行为分析的人，大概率有这种经历：甲方提需求时说的是“检测玩手机的人”，听起来就是给摄像头画面打个框的事儿，真正把数据集建起来才发现，“玩手机”这个动作本身就模糊得吓人——有人把手机举在胸前打字，有人低头刷视频，有人只是握着手机没看屏幕，这仨在二维图像里往往是同一张图。所谓“各种人物玩手机图片数据集”，说白了就是一摞带标注的真实场景图片，用来训练模型识别“画面里的人在玩手机”。它对刚入深度学习、又想找个能练手能落地的项目的人来说非常合适，因为任务直观、数据可控、模型成熟，不需要造轮子。但我得先把丑话说在前面：这个数据集不是搜几张图打个标就能跑的，动作边界的定义、样本的均衡程度、标注框的粒度，每一步都直接决定模型的成功率。

2. 先定义“玩手机”：类别边界、数据来源与采集清单

2.1 玩手机不是一个动作：先把标签体系定死

你别嫌我啰嗦，这是整个项目里最重要的一步，也是最容易偷懒的一步。很多人拿到“玩手机”这个需求，直接建一个文件夹叫“play_phone”，然后把所有带手机的照片往里一丢。这个做法在几十张图上看着没问题，等模型训完一测才发现，漏检率高得离谱，误报率高得同样离谱——因为你把“手持手机”和“正在使用手机”混在一类里了。

我一般会先和需求方确认一个分类体系，动词层面的拆分比你想的更重要。常见做法是定三类核心正样本和两类负样本，具体如下表。

这个表看着简单，但它解决了一个关键问题：让标注员和模型都知道“拿在手里但没在看”不算玩手机。实际项目里，甲方可能不认这个逻辑，他会说“只要拿出来了就算玩”，那你就在需求文档里写清楚“拿在手里”和“低头使用”是两个类别，后续模型输出才有解释空间——这类项目最后汇报时，你要能说清楚误报都从哪来，而不是甩给模型“玄学不准”。

2.2 三种数据来源：自己拍、有节制地爬、从公开数据集里挖

定完类别，接下来是攒原始图片。我不建议只从一个渠道拿图，因为模型对场景的泛化能力，约等于你数据集里场景的多样性。常见做法是三路并进：第一路是自己拿手机或相机拍，找办公室、地铁站、商场休息区、教室这类典型场景，每一处拍一组连拍或短视频抽帧；第二路是写个简单的爬虫从图片搜索引擎批量下载，注意控制请求频率、做好去重，不要对着一个站点高并发地抓；第三路是去已有的公开数据集里挖“带手机的图”，比如通用目标检测数据集里的person类别图片，人工筛一遍能挑出大量负样本——负样本的作用后面会专门说，你现在只需要知道，负样本决定模型的误报率上限。

第一条路最可控，我建议占六成以上。拍的时候注意角度，俯拍和平视都要有，室内灯光和室外自然光都要有，单人场景和多人场景按 3:1 配比。有个反直觉的经验：大量单人图训出来的模型，在多人场景里漏检率会显著上升，你必须在一开始就按最终使用场景的比例去配数据，别等训完再补。

2.3 要不要做姿态标注：关键点标注的时机

如果你的最终目标只是“检测画面里有没有人玩手机”，那目标检测框就够了，不需要碰关键点。但有一条路值得提前铺：如果你预期后续要升级成行为识别（比如判断玩了多久、是不是在持续低头看），那建议在标注检测框的同时，给“低头”“抬手”“手机贴耳”这类姿态做额外标记，哪怕只是打一个标签字段，也不要在采集完几万张图之后再补——返工的成本远比你想象的高。

我见过一个团队前期图省事，只打了检测框，后来做驾驶分心检测，要从框里再判断驾驶员是在看手机还是看后视镜，最后返工重标了三分之一的数据，花了三周。所以如果预算允许，框之外再加一个“head_direction”属性字段，5 个值：look_down / look_forward / turn_left / turn_right / occluded。这个字段在后面做行为倾向分析时非常值钱，你在数据收集阶段加一个备注列就够了，成本几乎为零。

采集完后，做一个总量表：把每一类图片张数、正负样本比例、场景分布写清楚，这张表会在你定训练参数和向别人解释效果时反复用到。

3. 从原始图到训练集：标注工具、格式转换与数据划分脚本

3.1 标注工具怎么选：个人用 LabelImg，团队用 CVAT

采集完的图片基本都是标准格式，接下来就是标注。个人练手或者少量数据，LabelImg 是够用的，它是纯本地软件，不需要起服务，标注完直接存成 VOC XML。但你要是团队协作，或者数据量上了五千张，就建议用 CVAT，它跑在 Docker 里，多人同时标注、在线分配任务都方便，还自带自动标注插件接口。对于做玩手机检测来说，Label Studio 也可以，但它更适合做文本和多模态标注，纯画框反而有点重。

说句实在话，标注工具的好坏在数据量小的时候感知不强，一旦数据量大了，你最需要的功能是“同类别快速连续标注”和“在已有标注上微调框的位置，而不是重画”。LabelImg 里按 W 键切换画框，按 D 键切下一张，熟悉之后一人一天可以标到 800 张单人图；多人场景就要慢下来，200-300 张一天。时间估算按这个来，别排太满。

3.2 把 VOC XML 转成 YOLO 格式：转换脚本与三个必调参数

我默认你最终会用 YOLO 系列训练，因为目标检测里 YOLO 生态对这张数据集的适配度最高，后面第 4 章会说选型理由。YOLO 需要的标注不是 XML，而是每张图对应一个同名 txt，每行格式是：class_id x_center y_center width height，四个坐标都是相对于图片宽高的比例值（0-1 区间）。VOC 的 XML 记录的是左上角和右下角的绝对坐标，所以转换脚本的核心就是做一次坐标换算加归一化。

下面这段脚本是这类任务里我一直在用的模板，可以直接抄走改改：

import os import xml.etree.ElementTree as ET def convert_voc_to_yolo(xml_file, out_dir, class_map): """ 将单张 VOC XML 标注转为 YOLO 格式 txt。 class_map: {'using_phone': 0, 'calling': 1, 'holding_phone': 2} """ tree = ET.parse(xml_file) root = tree.getroot() img_w = int(root.find('size/width').text) img_h = int(root.find('size/height').text) out_lines = [] for obj in root.findall('object'): name = obj.find('name').text if name not in class_map: continue # 跳过未定义类别，例如 person 本身 bndbox = obj.find('bndbox') xmin = float(bndbox.find('xmin').text) ymin = float(bndbox.find('ymin').text) xmax = float(bndbox.find('xmax').text) ymax = float(bndbox.find('ymax').text) # 越界防护：个别标注可能超出图像边界 xmin = max(0, xmin) ymin = max(0, ymin) xmax = min(img_w, xmax) ymax = min(img_h, ymax) if xmax - xmin <= 0 or ymax - ymin <= 0: continue # 转 YOLO 中心点 + 宽高，并归一化到 0-1 cx = ((xmin + xmax) / 2) / img_w cy = ((ymin + ymax) / 2) / img_h w = (xmax - xmin) / img_w h = (ymax - ymin) / img_h out_lines.append(f"{class_map[name]} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}") if out_lines: base = os.path.basename(xml_file).replace('.xml', '.txt') with open(os.path.join(out_dir, base), 'w', encoding='utf-8') as f: f.write('\n'.join(out_lines)) return len(out_lines)

这段代码里有三个地方值得你注意。第一是越界防护，你从网上下载的图片有的带水印，标注时手一抖就可能让框超出边界，不截断的话训练时 YOLO 会在 Resize 阶段算错坐标。第二是类别过滤，XML 里可能既有玩手机的对象，也有正常的 person 框，脚本里用if name not in class_map: continue把它们过滤掉，避免把“人”也当成训练正样本。第三是输出精度控制在 6 位小数，坐标值本身是 0-1 的小数，精度不够的话，小物体框的误差会被放大，玩手机的框通常很小，这个细节不是玄学，是真值漂移的来源之一。

3.3 数据划分：按“事件桶”切，不按图片随机切

数据切分是个很少有人提但非常容易翻车的环节。很多人直接random.shuffle然后按 8:1:1 分训练、验证、测试集，这样做的隐患在于：如果你的图片是从连续视频抽帧得到的，同一条视频里的相邻帧高度相似，会被随机分到训练集和验证集里，验证指标会虚高，也就是“泄漏”。表现就是你训练时 loss 降得很顺利，验证集 mAP 也很漂亮，一上真实场景就崩。

我一般这样处理：所有图片在采集时按来源命名，比如office_20240110_001.jpg，前面的场景前缀就是“事件桶”。划分时按桶来切——桶级别打乱，而不是图片级别打乱。下面的脚本演示了怎么按前缀分桶：

import os import random from collections import defaultdict def group_split(image_dir, train_ratio=0.8, val_ratio=0.1, seed=42): """ 按文件名前缀（事件桶）做分组划分，避免同源图片泄漏。 image_dir: 存放所有图片的目录 """ random.seed(seed) files = [f for f in os.listdir(image_dir) if f.endswith('.jpg')] buckets = defaultdict(list) for f in files: bucket_key = f.split('_')[0] # 例：office_20240110_001.jpg -> office buckets[bucket_key].append(f) bucket_names = list(buckets.keys()) random.shuffle(bucket_names) n_train = int(len(bucket_names) * train_ratio) n_val = int(len(bucket_names) * (train_ratio + val_ratio)) train_buckets = set(bucket_names[:n_train]) val_buckets = set(bucket_names[n_train:n_val]) test_buckets = set(bucket_names[n_val:]) train_files, val_files, test_files = [], [], [] for b in train_buckets: train_files.extend(buckets[b]) for b in val_buckets: val_files.extend(buckets[b]) for b in test_buckets: test_files.extend(buckets[b]) return train_files, val_files, test_files

这段脚本的关键判断是f.split('_')[0]，它决定分桶粒度。如果你的图片不是按场景前缀命名的，比如是从几个大文件夹拷进来的，也可以改成按上级目录名分桶。原则就一条：同一次拍摄活动产生的图片，必须落在同一个桶里。不要嫌麻烦，这个坑我在自动驾驶类数据集上踩过，指标虚高到我不愿意跟人提。

4. 用 YOLOv8 跑通基线：训练配置、增强参数与首次调参的取舍

4.1 为什么首选 YOLO 而不是先想分类

数据已经标好，接下来就是训练环节。对于“人物玩手机图片数据集”这个任务，目标检测比图像分类更合适。原因很简单：分类模型要求图片里只有一个核心对象，而真实场景里多人共存才是常态；检测模型天然输出“谁在哪里玩手机”，直接对应监控和取证需求。检测模型里我优先推荐 YOLOv8，生态成熟、部署资料多、训练脚本封装得干净，Python 环境下一行命令就能跑起来，对着官方文档“动手深度学习”一次就能完成，不会像别的一些检测框架那样卡在环境配置上。

如果你的机器只带一个入门级显卡、显存 6G 以下，就用 yolov8n 或 yolov8s；显存够大、追求精度可以用 yolov8m。第一次跑基线，不建议直接用最大模型，先用轻量模型把整个数据链路打通，确认标注没有异常，再上大模型刷精度。

4.2 训练配置和三个必调参数

先看数据配置文件 data.yaml，这是必须自己动手写的：

# data.yaml path: /home/user/phone_dataset # 数据集根目录 train: images/train val: images/val test: images/test # 类别定义，顺序和数量必须与标注转换时一致 names: 0: using_phone 1: calling 2: holding_phone

这个文件本身没有太多玄机，但有两个常见的坑：一是path要写绝对路径，YOLO 在训练时会用这个路径拼接train和val的相对路径，写相对路径容易出现FileNotFoundError；二是names的顺序必须和你在转换脚本里定义class_map的顺序严格一致，否则你的标注类别全部错位——你以为在学 using_phone，实际上它学的是 holding_phone，而且这种错位不会在训练指标里暴露。

然后就是训练命令：

yolo detect train \ data=data.yaml \ model=yolov8n.pt \ epochs=100 \ imgsz=640 \ batch=16 \ patience=15 \ device=0

参数里patience=15指的是验证集指标连续 15 轮不提升就提前停止，这是个后悔药机制，别不小心关掉。imgsz=640在大多数监控画面和手机拍摄图上够用，如果你的原始图是 4K 大图，可以先缩到 1280 再裁成 640 训练，而不是硬顶高分辨率。首次训练不要追求极限精度，先跑通，看 loss 是否下降、val 指标是否随 epoch 上升。

如果你想换用其他预制模型，比如从 YOLOv5 切到 v8，只需改model=参数的权重名，yolo 命令会自动下载对应模型结构，数据标注格式不变。这里顺带提一句：机器学习模型的选择讲究匹配数据规模和场景复杂度，千万别一上来就套用大模型，玩的手机框在监控画面上通常只有几十像素，这个数据规模下，大模型带来的收益抵不过它对训练时间的消耗。

4.3 数据增强：mosaic 要慎用

YOLO 自带一套数据增强参数，在训练配置里可以用augment参数控制，但真实项目里我一般不直接用默认值，尤其是 mosaic。Mosaic 是把四张图拼成一张训练，对小物体检测有提升，但它有个副作用：玩手机的人往往在画面边缘，拼接时很容易被裁掉一半，模型反复看到残缺的“半个身体+手机”，反而学偏了。我的经验是首次训练先把mosaic=0.5，如果发现 mAP 到了 50 轮还在一路抖，就把 mosaic 降到 0.3 甚至 0。另外几个增强参数可以参考这个区间：

增强参数不是越大越好，每一次增强都改变原始分布，增强过头会让模型学到扭曲的纹理特征。你如果刚开始接触训练，我的建议是先用默认参数完整跑一版，把 mAP 记录下来，再按上表调整，对比两次结果。这就是“机器学习实战”的标准方式，别想一次性调对。

5. 避坑指南：5 个玩手机检测训练中的典型翻车现场

5.1 漏检的锅，一半是标注的锅

我在 2.1 里强调过标签定义，这里讲最直接的翻车现象：训练完的模型在办公室里检测效果很好，一到地铁站就漏检。原因是地铁场景里，乘客低头玩手机的姿势更“收敛”——手机离眼睛更近，手臂遮挡了身体前侧。你的训练集里如果全是坐姿、手臂自然下垂的办公室图，模型实际学到的是“手臂下垂+低头”，而不是“手机存在”。

所以不要急着怪模型，先回去看图。抽取 50 张漏检图，用标注工具打开看看：是不是标注框只框了手机、没框住手？是不是有一类姿势（比如站立低头）样本数量太少？如果是标注问题，补标比调参快。这类问题最好的预防手段，是在采集阶段就按姿势和场景做矩阵拍图，每个格子 200 张打底。

5.2 误报：把“拿手机”当“玩手机”的边界模糊

典型现象：模型把正在喝饮料的人框成了 using_phone，把拿充电宝的人框成了 calling。原因就是 calling 类和 using 类在真实场景里，遮挡严重，手机和饮料瓶、充电宝的颜色、纹理高度相似。你在类别定义里加了 holding_phone 作为负样本，但如果这个负样本数量太少，模型会倾向于把所有“手里有东西”都归到正样本类。

解决办法有两条路：一是加负样本，把 holding_phone、拿饮料、拿文件夹这些图补到与正样本 1:2 的比例以上；二是调标注粒度，把训练目标改成“watching_phone（看屏幕）”和“phone_to_ear（贴耳）”两类，过滤掉“手里拿着”这类中间态。前一条是数据问题，后一条是任务重定义问题，经验上先加数据，实在不行才换任务定义。

5.3 小目标翻车：监控画面里的手机只有十几个像素

玩手机动作在监控摄像头 1080p 画面下，手机本体的高度只有 20-30 像素，人物上半身框大约是手机的 40 倍大小，训练时模型很容易优化“检测人”的损失，而忽略掉那个小框。现象就是 mAP 很高，但小目标的 recall 低得吓人。

解决的思路是给模型“看大图”——常见做法是切图训练，也就是把原始大图切成 640x640 的切片（重叠 20%），手机在切片里会占到 60 像素以上。切片后标注文件要同步切，这个过程比较繁琐，但收益最直接。还有一种办法是用 SAHI 之类的切片推理工具在推理阶段取图，但训练阶段的切片收益远大于推理阶段，能切尽量切。

5.4 正负样本比例失衡，验证集指标很漂亮但现场一塌糊涂

你数据集里如果正样本占了九成，负样本只有一成，模型就倾向于把所有内容都判为正样本——因为整体准确率仍然能撑到 95% 以上。这类 bug 的特征是训练损失在下降，验证集 mAP 也很高，但去真实场景跑，误报频出。

我见过最夸张的案例是负样本里全是“空桌面、空走廊”，模型只需要输出“有手机”和“没有手机”，学到的图像背景是固定场景，换个现场就失灵。正确的负样本比例应该不低于正样本的三分之一，并且要混入有人的、有桌面的、有杂物的场景，才能逼模型去学“有没有手机”而不是“是不是同一间房”。

5.5 过拟合的伪象：loss 降了，验证集 mAP 却在原地打转

一个很容易误导新手的现象：训练 loss 持续下降，验证集 mAP 前 20 轮上涨，然后进入平台期并且不再上升。这说明模型开始背训练集数据了，只能通过早停机制判断。YOLO 训练日志里会把每个 epoch 的 val/box_loss 打出来，你要多盯一列指标“val/box_loss”，它应该和训练 loss 一起下降。如果训练 loss 还在降，val/box_loss 开始回升，说明模型在过拟合，需要回到增强参数章节调整，而不是继续训练。

这类问题没有一劳永逸的解药。我自己最常用的做法是：加数据增强强度（尤其 hsv 和 scale），同时换轻量模型，让模型的表达能力和数据规模匹配。深度学习不是魔盒，模型参数越多、数据越少，底线就越难看。

6. 评估与进阶：指标之外，上线前最好再校一遍的几件事

mAP 是评估模型的标准指标，但做这张数据集，我更习惯在测试集上做一遍混淆矩阵（分类问题看类别两两之间的误认），它比单一 mAP 更能暴露问题来源。以下面这张简化混淆矩阵为例，第三类 holding_phone 被误认为 using_phone 的比率如果在 10% 以上，说明你的类别边界定义需要修正，而不是模型能力不行。

到了要上线的阶段，有件事比调参更值得做：把完全没参与过训练的“盲测场景”图片喂给模型跑一遍，不看指标，只看人为判断的准确率。因为测试集就算再怎么分桶，也可能和你真实部署环境有分布偏移，这个盲测抽 200 张就够。

我还遇到过部署端的预处理差异造成的翻车：训练时用的是 640x640，部署端是 1280 输入，模型精度波动很大，原因是推理代码里的 resize 插值方式和训练时不一致。所以我会在演示给甲方看之前，先检查一下推理脚本的预处理部分。部署在移动端或边缘设备上时，再考虑转成 TensorRT 或 ONNX 的量化模型，轻量模型 yolov8n 转 INT8 之后推理速度大约能提升一倍，代价是精度掉 2 到 3 个点，可以接受。

另外一条进阶路径是给检测结果加时序信息。单帧检测容易误判，但如果你拿视频流里连续 5 帧做投票（5 帧中有 3 帧判定为玩手机，才输出报警），误报率能压掉一大截。这一步不需要改模型，在部署端写一个状态机就行，效果却非常显著。我自己的习惯是先做完这个时序过滤才交付，它能解决大多数“一闪而过”的误报。

最后讲一个我自己的教训。第一版玩手机检测模型，我把重点都放在调增强参数上，跑了一周实验，调来调去 mAP 都在 0.78 上下浮动。后来冷静下来，抽了 100 张漏检图，发现 60 张是标注时只有“人”的框、没有“手机”的框。问题根本不在模型或参数，而在数据源头。从那时候起，每次训练前我都会花半小时抽查标注，仔细看标注框是不是贴合手机边缘，而不是笼统地框一个人。这都是数据集的隐性成本，也是这类项目的真正门槛。希望你这次做的时候，从一开始就把这些账算进去，省下来的时间足够你把 models 跑两轮了。希望帮到你。

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