YOLOv5训练DNF识别模型：自动脚本目标检测避坑指南

简介：基于YOLOv5目标检测的DNF自动脚本实现项目，面向游戏自动化开发者和计算机视觉学习者，解决游戏内实时画面识别、目标定位与自动操作衔接的问题。压缩包共95个文件，整体约27MB，以Python源码和编译后的pyc为主，辅以YOLOv5模型配置（yaml）、预训练权重、图像模板以及dockerfile和shell脚本，便于环境部署与二次开发。代码覆盖屏幕图像捕获、按键模拟、技能识别、方向移动与捡物判断等关键模块，目录内还包含测试截图和说明文档，结构分层清晰。目前已有406人学习，适合希望理解YOLOv5从模型调用到游戏落地全流程的中级开发者。项目内附训练好的权重文件，可直接运行体验，也可参考识别逻辑迁移到其他目标检测驱动的自动化场景。

1. 把 YOLOv5 识别算法装进 DNF 自动脚本：这个标题背后真正难啃的地方

在搜索框敲下“基于YOLOv5 DNF识别算法的DNF自动脚本实现”的人，多半已经见过几个号称能跑的 dnf 脚本源码。但真正上手你会很快发现，自动循环本身不难，难点全在“识别”这一层：DNF 是横版渲染，技能一放满屏光效，怪物、掉落物、UI 图标层层叠叠，传统模板匹配和按颜色找点的方案换个地图就翻车。YOLOv5 的价值在于把“看见目标”变成可以训练、可以迭代的检测模型——你先标注数据、用 YOLOv5 训练自己的数据集，再让模型稳定输出目标类别和坐标，自动脚本才有资格谈下一步的“自动”。

这篇笔记不吹不黑，按我自己的实操路径从数据准备、训练配置、推理闭环一路讲到调试避坑，最后一章收三个让识别更稳的调试技巧。适合正打算动手、或者模型已经能跑但识别率不理想的人；如果你从网上拿到的压缩包里只有孤零零的脚本片段，没有模型权重也没有数据集，这篇文章正好帮你把缺口补上。识别算法这件事，资料越少越容易走弯路，下面这些步骤都是我能复现、能交代清楚来龙去脉的做法。

2. 自制 DNF 数据集：从截帧到标签，把“识别算法”的第一步踏稳

2.1 预训练模型不是万能药：DNF 的目标和 COCO 差着一整条线

很多人拿到 YOLOv5 的第一反应，是直接用官方 yolov5s.pt 对游戏窗口做推理。结果很统一：几十个框在人物和背景上乱飞，怪物和掉落物基本漏检。原因不复杂——COCO 数据集里根本没有“DNF 的怪物”“金币堆”“传送门”这些类别，预训练模型学到的 80 类里跟游戏场景沾边的无非 person、bottle、chair，跟游戏渲染风格完全是两套东西。所以在“基于YOLOv5 DNF识别算法”这个标题里，真正决定成败的不是 YOLOv5 的网络结构，而是你有没有一份干净、类别明确的数据集。

这里有一个被低估的优势：游戏画面的纹理非常规整，同一类怪物在不同地图里的外观变化远小于真实世界，所以哪怕你只标几百张图，识别效果通常就能达到可用的水平。这一点比工业质检、自动驾驶的数据友好得多。第一步是定类别清单，我一般控制在 5～8 类，比如“普通怪、精英怪、掉落物、消耗品、传送门”，按行为分组而不是按外观细分；类别一多，边界混淆指数上升，后面训练和调参的精力会全花在解决同类误判上。

2.2 截帧、标注与目录布局：给 YOLOv5 喂数据的标准动作

数据集准备的头一步是截帧。常见做法是用 mss 抓窗口区域，先把原始帧按 JPG 存下来，再用标注工具框出目标。下面这个脚本按固定间隔抓取主显示器内容，跑几分钟就能攒下几百张原始素材：

import mss import cv2 import numpy as np import os import time with mss.mss() as sct: monitor = sct.monitors[1] # 主显示器完整区域 out_dir = "dnf_frames" os.makedirs(out_dir, exist_ok=True) for i in range(300): frame = np.array(sct.grab(monitor)) frame = cv2.cvtColor(frame, cv2.COLOR_BGRA2BGR) cv2.imwrite(f"{out_dir}/dnf_{i:04d}.jpg", frame) time.sleep(0.5) # 控制节奏，避免连拍相似帧

这里两个关键点：mss 单次截屏只有几毫秒，比 PIL 的 ImageGrab 快一个量级；抓“整个显示器”只是权宜之计，后续做窗口模式时应该切成目标客户区，第五章会专门讲这个坑。截帧时建议在游戏里多跑几个场景——城镇、副本、boss 战、掉落瞬间都要覆盖到，模型才能分清“怪物在移动”和“怪物倒地待拾取”这些实际状态；光在一个地图里截 500 张，模型换个图就会漏检。

素材到手后用 labelImg 或 X-AnyLabeling 标注，导出 Pascal VOC XML，再转成 YOLO 训练用的 txt。这一步总会遇到“网上下的数据集是 XML，训练脚本只认 txt”的尴尬，所以我把转换脚本贴出来：

import xml.etree.ElementTree as ET import os def voc2yolo(xml_path, class_names, out_dir): tree = ET.parse(xml_path) root = tree.getroot() img_w = int(root.find("size/width").text) img_h = int(root.find("size/height").text) lines = [] for obj in root.findall("object"): name = obj.find("name").text cls_id = class_names.index(name) box = obj.find("bndbox") x1, y1, x2, y2 = [int(box.find(t).text) for t in ("xmin", "ymin", "xmax", "ymax")] cx = (x1 + x2) / 2 / img_w cy = (y1 + y2) / 2 / img_h w = (x2 - x1) / img_w h = (y2 - y1) / img_h lines.append(f"{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}") txt_path = os.path.join(out_dir, os.path.splitext(os.path.basename(xml_path))[0] + ".txt") with open(txt_path, "w") as f: f.write("\n".join(lines)) if __name__ == "__main__": class_names = ["monster", "elite", "item", "buff", "portal"] os.makedirs("labels", exist_ok=True) for xml_file in os.listdir("xmls"): if xml_file.endswith(".xml"): voc2yolo(os.path.join("xmls", xml_file), class_names, "labels")

转换逻辑本身不复杂，唯一要强调的是 class_names 的顺序：txt 里只存类别 id，顺序一变前面标注全部作废，所以第一遍就要把类别清单敲定，并同步写进后面的 data yaml。手工标注有一个我吃了亏才养成的习惯：框要紧贴目标边缘，宁紧勿松。YOLO 系列对中心点坐标敏感，对框大小误差反而宽容；框松了，模型学到的上下文里会混入太多背景，尤其是金币堆、药剂这类“小东西”，松框和紧框的差别在实测里非常明显。

最终目录结构建议直接对齐 YOLOv5 官方默认布局：

dataset/ images/ train/ val/ labels/ train/ val/

images 和 labels 的文件必须同名不同后缀，YOLOv5 的 dataloader 会按文件名配对。新手最容易在这翻车：标注文件放错目录、jpg 和 txt 大小写不一致、同名文件不在同一子目录，train 过程会静默跳过一批样本，表现出来就是 loss 曲线怪异、验证 mAP 忽高忽低。训练启动后如果发现某个类别一帧都没参与训练，先回来检查目录配对，不要急着调超参数。

2.3 划分训练/验证集：别把“同一场战斗的连续帧”随机打散

数据划分是“用 YOLOv5 训练自己的数据集”里最容易被低估的步骤。很多人直接 random split，结果同一场战斗的连续 10 帧被散到 train 和 val 里，验证集几乎就是训练集的轻微变形，指标自然虚高；等部署到新副本，立刻原形毕露。我一般按场景划分：每场战斗或每个地图的截图放进同一个子集，再按场景分配 8:1:1。如果想把验证做扎实，把不同分辨率、不同画质档位的素材分别归档，确保验证集覆盖到每一种画质，防止模型只认得某一台机器的渲染效果。

增强方面，YOLOv5 默认开启的 mosaic、random_perspective、HSV 变换对游戏场景基本够用。需要调整时重点关注 hsv_h 和 hsv_s：DNF 的怪物血条、角色名颜色一致性很强，增强幅度过大会让模型把“颜色”当噪声，反而掉点。有一点容易被忽略：mosaic 之后，游戏里的血条和 UI 文字会被拼接切断，如果这些 UI 元素是你要识别的目标，默认 mosaic 概率反而有害。我见过有人为了提升“角色血条”识别率，最后把 mosaic 关掉才涨点，这种属于 dataset-specific 的调整，不能只看默认值。

到此，数据集已经满足训练前置条件。截帧和标注虽然机械，却决定了后续所有环节的上限，值得留足时间；我自己第一条数据就花了整整一个周末，但后面所有调参都比前期省事得多。

3. 训练 YOLOv5 模型：三个必调超参数和网络结构的取舍逻辑

3.1 选 YOLOv5 的哪个变体：速度与精度的平衡点在这

YOLOv5 官方把网络结构按宽度和深度切成 n/s/m/l/x 五个型号，yolov5n 最轻快但小目标召回明显偏弱。DNF 场景有个特点：掉落物和部分 UI 图标都很小，一张 1920×1080 截图里，金币堆可能只有 20×20 像素，所以不能只看推理速度选型号。我的经验是 yolov5s 在这个场景是最稳的起点；显存充裕、希望第一版就少漏检的，直接上 yolov5m 也完全合理。大致的性能参照如下：

这个表只是选型参照，具体耗时取决于显卡、TensorRT 优化和画面复杂度。自动脚本不需要 60fps 的识别帧率，20ms 左右完全够用，人的手速也在 100ms 量级，把资源花在“更准”上比“更快”划算。另一个容易被忽略的选型维度是输入分辨率：常规检测用 640 是效率与精度的折中，但你要识别 20 像素的小目标，640 输入会丢失细节。常见做法是把 --img 提到 960 甚至 1280 再训一版，但训练和推理时间同步上涨，小目标仍然是最难的部分。我的建议是第一版先 640 跑通全流程，之后开一版 960 对比验证集 mAP，再决定要不要为那十几毫秒买单。

3.2 训练命令的最小可用配置：img、batch、epochs 和 data yaml

模型确定后，真正影响是否翻车的是几个 yolov5 超参数。一套我多次验证能稳定收敛的起步命令是这样的：

python train.py \ --data dnf.yaml \ --weights yolov5s.pt \ --img 640 \ --batch 16 \ --epochs 300 \ --workers 4 \ --cache ram

逐个说参数：--data 指向数据集描述文件；--weights 用预训练权重的理由是复用 COCO 学到的底层纹理和边缘特征，只需把高层语义微调到 DNF 目标上，比从零开始收敛快得多；--img 640 要和标注时的尺寸语义一致；--batch 16 在 8GB 显存上安全，显存小降到 8，显存大升到 32，但 batch 越大 epochs 也要跟着加才能避免欠拟合；--epochs 300 对几百张图的场景不算多，YOLOv5 前 50 轮主要在稳定训练，后面才开始真正拟合类别特征；--workers 4 是数据读取进程数，Windows 下如果出现奇怪的死锁或 CPU 占满，先降到 2；--cache ram 把图片预载内存，减少每个 epoch 的磁盘 IO 等待，几百张图不过几个 GB，内存够就开着。

对应的 dnf.yaml 长这样：

# YOLOv5 对相对路径的兼容性一般，建议直接写绝对路径 train: D:/dnf_dataset/images/train val: D:/dnf_dataset/images/val nc: 5 names: ['monster', 'elite', 'item', 'buff', 'portal']

nc 必须和 names 长度一致，不一致时训练不会立刻报错，而是在中途某个维度校验挂掉，白跑半天。启动训练后日志会打印类别列表，养成“开训前扫一眼 class 数量”的习惯，能省很多无谓的等待。如果你用的是 YOLOv5 不同时期的官方仓库，命令行参数可能略有出入，以 clone 到本地的仓库 README 为准；原则是 data、weights、img、batch、epochs 这几个永远存在。

3.3 训练结果怎么读：mAP 很漂亮但实测漏检时，问题出在哪

训练完成后，去看 runs/train/exp 下的 results.csv 和 confusion_matrix.png。我判断模型好坏不是只看最后一轮 mAP，而是先看混淆矩阵：如果 item 和 buff 互相混淆严重，说明两个类在视觉特征上太接近，要么合并类别，要么回去补标更难的正样本，比如带光效遮挡的目标。另一个高频现象是训练集 mAP 0.99、验证集 mAP 只有 0.75，这几乎可以断定过拟合，优先加大增强而不是追加 epochs。

TensorBoard 的 loss 分项同样值得看：cls_loss 远高于 box_loss，多半是标签类别标错；obj_loss 降不下去，看看背景里是不是混入了大量未标注的相似目标。我第一次训 DNF 数据集时，mAP 看起来不错，但一实测就发现“药剂”和“金币”互相误判，后来打开 confusion matrix 才发现这两类在缩略图上几乎一个样；合并成一个“拾取物”类之后，整个模型的稳定性立刻上来了。识别算法不是类别分得越细越好，而是“对下游动作有用的类别”才值得单独存在。

4. 把模型接进自动脚本：抓屏、推理、动作的最小闭环

4.1 先统一坐标系统：模型输出怎么换算到屏幕真实位置

写任何闭环代码之前，先理清坐标系，否则每一行都是坑。YOLOv5 输出的检测框是相对输入图像的归一化坐标（cx, cy, w, h，取值 0～1）；要还原成屏幕坐标，必须知道输入图像来自屏幕的哪个区域。我习惯用一个函数统一换算：

def to_screen_coords(box, monitor, frame_w, frame_h): # box: [cx, cy, w, h]，monitor: mss 抓屏区域字典 x_center = box[0] * frame_w + monitor["left"] y_center = box[1] * frame_h + monitor["top"] w = box[2] * frame_w h = box[3] * frame_h return int(x_center), int(y_center), int(w), int(h)

monitor 必须和 mss 抓屏时用的是同一个对象，不能一边抓 A 区域一边拿 B 区域的偏移来做换算。“点击总是偏 100px”这类问题，十有八九是这里错了。在做动作之前，值得写一个可视化工具，把检测框画回原图并打印坐标，确认偏差来源再继续；否则出错时你无法判断是识别问题还是坐标问题，调试效率会非常低。

4.2 推理封装：用 ONNX 跑一个稳定可复用的识别实例

模型训练完，常见做法是导出 ONNX 再部署，核心好处是脱离 PyTorch 运行时，CPU/GPU 都能跑，后续接 C++ 或其它语言也方便。YOLOv5 自带导出脚本：

python export.py --weights runs/train/exp/weights/best.pt --include onnx --img 640

导出后的最小推理循环如下：

import cv2 import numpy as np import onnxruntime as ort import mss import time session = ort.InferenceSession( "best.onnx", providers=["CUDAExecutionProvider", "CPUExecutionProvider"], ) def preprocess(frame, target_size=640): # 输入要求 NCHW、RGB、float32、0~1 img = cv2.cvtColor(frame, cv2.COLOR_BGRA2BGR) # mss 出来是 BGRA h, w = img.shape[:2] r = min(target_size / w, target_size / h) # 等比缩放，保持长宽比 new_w, new_h = int(w * r), int(h * r) resized = cv2.resize(img, (new_w, new_h), interpolation=cv2.INTER_LINEAR) canvas = np.full((target_size, target_size, 3), 114, dtype=np.uint8) dh, dw = (target_size - new_h) // 2, (target_size - new_w) // 2 canvas[dh:dh + new_h, dw:dw + new_w] = resized blob = canvas[:, :, ::-1].transpose(2, 0, 1).astype(np.float32) / 255.0 return np.expand_dims(blob, axis=0), w, h with mss.mss() as sct: monitor = sct.monitors[1] while True: t0 = time.perf_counter() frame = np.array(sct.grab(monitor)) blob, orig_w, orig_h = preprocess(frame) out = session.run(None, {session.get_inputs()[0].name: blob})[0] elapsed = (time.perf_counter() - t0) * 1000 print(f"{elapsed:.1f} ms，目标数量 {out.shape[1]}")

这里有两处最容易踩坑。第一，mss 抓出来是 BGRA，要先用 cvtColor 转 BGR，再翻转到 RGB；YOLOv5 训练时用的是 RGB，顺序错一点，模型精度立刻跳水。第二，我刻意没有直接用 cv2.resize 把画面硬拉成 640×640，而是做了 letterbox，保持长宽比并填充 114 灰度值——这和 YOLOv5 训练时的预处理保持一致，检测框还原时才不会横向或纵向被额外拉伸。如果直接 resize，非正方形的画面会被压变形，框的中心坐标换算回去也会有系统性偏差。另一个版本相关的问题是：不同 YOLOv5 版本导出的 ONNX 输出形态不一样，有的带 NMS（输出 [1, N, 6]），有的是原始预测（[1, 25200, 85]）需要自己过滤；写后续处理前先打印 out.shape，再去搜对应版本的解析代码。

4.3 动作执行：把高置信度检测变成一次像样的点击

识别有了坐标，最后一步是把坐标交给鼠标键盘。我一般用 pydirectinput 而不是 pyautogui：DNF 这类游戏对鼠标模拟比较敏感，pyautogui 的点击在部分机器上会被吞，pydirectinput 走 DirectInput 通道，兼容性更稳。一个最精简的选择目标并点击的函数：

import pydirectinput def click_best_target(out, cls_id, conf_thr, monitor, frame_w, frame_h): candidates = [] for det in out[0]: # out[0] 的形状是 [N, 6] cx, cy, w, h, score, cls = det if int(cls) != cls_id or score < conf_thr: continue x = int(cx * frame_w + monitor["left"]) y = int(cy * frame_h + monitor["top"]) candidates.append((score, x, y)) if not candidates: return None candidates.sort(reverse=True) _, x, y = candidates[0] pydirectinput.moveTo(x, y, duration=0.05) pydirectinput.click() return (x, y)

这个函数只做三件事：按类别过滤、按置信度排序、取最高分坐标移动点击。真正的工程问题在“点击之后”：目标是怪物，点完要等技能冷却；是掉落物，点完要判断拾取是否结束；多目标并存，还要有优先级策略。这些超出识别算法本身，但决定了脚本是否“像人”。另一个必须控制的量是点击频率，毫秒级连续点击很容易触发游戏的安全策略，正常的人类操作轨迹应该在几十到几百毫秒之间随机变化，这一点最后一章还会展开。

5. 避坑：把自动脚本从“能跑”优化到“稳定跑”的五道坎

5.1 检测框在目标上抖动，点击永远慢半拍

现象：模型每帧都能检测到目标，但框的位置在 1~2 像素范围内跳来跳去，点击决策跟着左右摇摆。

原因：YOLOv5 对每一帧独立推理，画面里的残留特效、角色技能光效会造成目标的轮廓特征波动，框的回归值随之抖动。这是检测器的固有属性，不是代码 bug。

解决：在输出端做时间平滑。对同一类别维护最近 5 帧的框中心坐标，按置信度加权平均再输出；也可以用一阶指数移动平均，代码更轻。注意深度：角色转身或目标消失后，坐标会短暂滞后，平滑过深会让脚本点向旧位置，所以一般 alpha 取 0.3～0.5 比较合适。

5.2 训练 loss 降得漂亮，实测识别率上不去

现象：训练期 mAP 一路走到 0.9，但真实游戏里一开循环，大量漏检和误检。

原因：最常见是标签问题——类别标错、框太松、相似目标没标全；其次是验证集划分不严，连续帧同时出现在 train 和 val，指标虚高。

解决：先看 confusion_matrix 定位“哪和哪在混”，回数据集补标那些被漏掉的难例；再用按场景划分的验证集重新评估。清理一批脏标签带来的提升，往往比增加 500 张训练图还明显，这是我踩过最值的一跤。

5.3 换机器、换分辨率后坐标全部偏移

现象：1920×1080 下脚本运行正常，换到 2560×1440 或系统开启 125% 缩放，点击坐标一塌糊涂。

原因：Windows 的 DPI 缩放会改变窗口坐标与物理像素的映射关系；win32gui 提供的很多坐标是逻辑像素，而 mss 截屏是物理像素，两者混用必然偏移。

解决：脚本启动时先声明 DPI 感知，让所有坐标统一到物理像素：

import ctypes ctypes.windll.shcore.SetProcessDpiAwareness(2) # 必须在任何窗口查询之前调用

在混合 DPI 的多显示器环境里，还要确认 mss 的 monitor 编号对应的是目标显示器，而不是默认主屏。

5.4 模型推理只要 20ms，整条循环却卡到 150ms

现象：单独测推理很流畅，合进脚本循环后整体延迟明显变大，动作和画面都跟不上。

原因：常见有两个——脚本还挂着训练进程在抢 GPU；抓屏和推理同步串行，mss.grab 阻塞期间 GPU 空闲等待。如果一边训练一边跑脚本，显存被打满，推理自然排队。

解决：训练和运行分开，别在同一张卡上同时干两件事；抓屏放到独立线程，用最新帧覆盖策略，主循环只消费队列里的最新帧。如果只是单通道识别，把抓屏放在循环最前面紧跟推理也可以，但后续加 UI 逻辑时线程化的收益更大。

5.5 窗口模式点击偏移十几像素，时好时坏

现象：全屏模式一切正常，切到窗口模式就出现固定偏移，每次移动窗口偏移量跟着变。

原因：win32gui.GetWindowRect 返回的是窗口外矩形，包含标题栏和边框；这部分不在游戏画面内，导致截屏区域与检测框坐标错位。

解决：改用客户区坐标。先拿客户区矩形，再把客户区原点换算到屏幕坐标，作为截屏区域：

import win32gui hwnd = win32gui.FindWindow(None, "地下城与勇士") client_rect = win32gui.GetClientRect(hwnd) pt = win32gui.ClientToScreen(hwnd, (0, 0)) monitor = { "left": pt[0], "top": pt[1], "width": client_rect[2], "height": client_rect[3], }

这样截到的是纯游戏画面，识别结果换算出的屏幕坐标也能和真实鼠标事件对上。窗口无边框或全屏时 GetWindowRect 和客户区差异不大，但窗口模式下必须用客户区。如果游戏窗口标题会变，建议用进程 PID 反查句柄而不是按标题字符串找。

6. 让 DNF 识别更稳的三个收尾技巧：置信度阈值、消失确认和随机化动作

模型能跑起来之后，最后决定体感的往往是几个小细节。第一个技巧是每个类别单独设置信度阈值，不要全场景共用一个值。YOLOv5 推理时通常传一个全局 conf 阈值，但 DNF 场景里怪物这类大目标置信度天然偏高，掉落物图标这类小目标普遍偏低。我会把掉落物阈值放到 0.3 左右，怪物阈值提到 0.6，避免为了捡东西而付出大量误检成本。阈值怎么定？先用一批真实截图跑一遍，按类别统计 score 分布再决定，而不是拍脑袋设一个 0.5。

第二个技巧是目标消失确认。很多脚本只在单帧里判断“有没有目标”，某帧因特效遮挡漏检就立刻做出错误动作。更稳的状态机写法是：同一类别连续出现 N 帧才触发动作，连续 M 帧消失才认为目标已离开。N 和 M 不用大，2～3 帧就足以滤掉大部分瞬时噪声。

第三个技巧是动作随机化。把点击前的停顿设成 0.2～0.4 秒的随机值，而不是固定 sleep；鼠标移动路径也可以加一点曲率和速度变化。这既是为了让操作节奏接近真实玩家，也是降低连续固定节奏动作被游戏安全策略盯上的概率。我第一次做这类脚本时点击间隔精确到 150ms，跑了十分钟就开始被反复踢下线；改成 200 到 400 毫秒随机之后，明显稳定很多。把这三个技巧合起来，这套基于 YOLOv5 的识别方案才算真正从“能跑”变成“能稳定跑”。希望这些实操细节帮到你，剩下的路，就从跑通一个最小闭环开始。

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