简介基于YOLOV5的FPS类游戏自动瞄准系统是一套面向目标检测学习者的可运行完整项目。它整合了YOLOv5模型推理、屏幕画面捕获、检测框范围配置及鼠标移动模拟等模块适合作为毕业设计、课程设计或工程实训的起步参考。资源共110个文件压缩包约76.98MB以29个Python脚本、28个YAML参数配置、13个pyc编译文件及3个pt模型权重为主体另有sh启动脚本、图像样本、文本说明和Dockerfile等辅助内容目录结构清晰。目前已有883人学习下载项目内附带训练日志与示例图片可直观观察YOLOv5训练过程中的标签图、相关图及批次样本便于理解检测效果。使用前只需在FPSUtils.py中调整分辨率、在FPSdetect.py中指定模型路径即可快速启动体验。1. YOLOv5 自动瞄准一次从检测框到准星的坐标接力做 FPS 自动瞄准真正的难点不在模型训练而在坐标链路YOLOv5 只给出图像坐标系里的目标框鼠标需要的是屏幕坐标系的位移。两者之间隔着分辨率换算、检测区域裁剪、推理耗时和鼠标平滑几道关卡漏掉任何一环准星都不会听话。这个项目用 yolov5s 做检测核心配置、推理、控制拆成三个文件构成一条完整的视觉到外设闭环适合做毕设、课程设计或想看清检测结果如何被消费的 YOLOv5 学习者。项目里自带的 bus.jpg、labels_correlogram.jpg 和 train_batch 系列图片都是训练和验证阶段留下的产物可以直接拿来验证链路。需要划清边界这套链路只建议在单机、离线或允许 Mod 的场景里验证技术接入在线对战属于破坏公平性的行为。坐标映射与实时推理的思路本身是中性的换到巡检、抓取等场景依然成立。2. YOLOv5s 检测链路与目标坐标映射2.1 为什么选 yolov5s精度与帧率的平衡点YOLOv5 按深度和宽度系数分成 s、m、l、x 四个常用版本。s 是 smallest权重文件 yolov5s.pt 约 14 MB在 COCO 上 mAP 大概 37 出头GTX 1060 级别显卡上单帧推理可以做到 510 ms。自动瞄准是强实时任务从看到目标到准星移动的整条链路超过 100 ms操作感就会明显发粘所以选型的第一优先级是延迟而不是 mAP。游戏画面里的目标类别固定、背景相对单纯yolov5s 的精度完全够用。这里有个常见误区总想换更大的模型提升识别率。实际在自动瞄准场景里漏检通常不是因为模型不够强而是训练数据没覆盖目标的外观变化。盲目升级到 yolov5l帧率几乎掉一半收益却很小。先保证 30 FPS 以上的稳定推理再考虑精度才是正确的调优顺序。项目目录里的 labels_correlogram.jpg 是训练阶段的标注相关性分布图train_batch1.jpg 和 train_batch2.jpg 是批数据预览这些图能帮你快速判断数据集本身有没有问题而不是去怀疑模型。2.2 检测框坐标到屏幕坐标的换算2.2.1 坐标系定义与区域偏移YOLOv5 默认输出 xyxy 格式即[x1, y1, x2, y2, conf, cls]单位是像素原点在输入图像左上角。问题在于喂给模型的帧是从屏幕检测区域裁剪下来的不是完整屏幕所以目标在屏幕上的真实位置必须加上检测区域左上角的偏移量。def box_to_screen(box, region): # box: 模型输出的单个目标框 [x1, y1, x2, y2, conf, cls] # region: FPSUtils.py 里配置的检测区域含 x/y/w/h cx (box[0] box[2]) / 2.0 # 检测框中心 x区域坐标系 cy (box[1] box[3]) / 2.0 # 检测框中心 y区域坐标系 screen_x int(region[x] cx) screen_y int(region[y] cy) return screen_x, screen_yregion[x]和region[y]是检测区域左上角相对屏幕左上角的偏移cx和cy是目标在裁剪帧里的中心。这里有个精度隐患如果 region 的宽高和实际截图的尺寸不一致偏移量会整体错位表现为目标框在屏幕上贴不准目标。这个现象在第 5 章会给出验证方法。2.2.2 缩放还原letterbox 之后的坐标补偿另一个高频坑是图像缩放。推理前通常会把截图 resize 到 640×640 输入给模型模型输出的是 resize 后的坐标。不做比例还原直接映射屏幕坐标会整体偏小准星永远落在目标左上方。def restore_scale(box, orig_w, orig_h, input_size640): # 模型在 640x640 下推理还原到原始裁剪帧尺寸 scale_x orig_w / input_size scale_y orig_h / input_size x1, y1 box[0] * scale_x, box[1] * scale_y x2, y2 box[2] * scale_x, box[3] * scale_y return [x1, y1, x2, y2]注意这段是简化版只处理了等比缩放。如果用了 letterbox 补边还需要把 padding 的像素量先减掉再乘缩放比例否则目标位置会向下向右偏移一块固定距离。2.3 推理耗时预算一条链路能容忍多少延迟把整条链路拆开看大致是屏幕截图 0.52 ms图像预处理 13 ms模型推理 510 ms后处理和坐标换算小于 1 ms鼠标指令下发 0.11 ms。GPU 推理时合计约 1020 ms这是跟手的前提。一旦 fallback 到 CPU模型推理单项就要 3060 ms整链路逼近 100 ms准星明显跟不上目标。环节GPU 推理耗时CPU 推理耗时常见优化手段屏幕截图0.5~2 ms0.5~2 ms用 mss 替代 PIL.ImageGrab预处理1~3 ms1~3 ms直接转 tensor少做额外复制模型推理5~10 ms30~60 msFP16 半精度、输入尺寸降到 416后处理坐标换算1 ms1 ms只对通过阈值的目标做换算鼠标指令0.1~1 ms0.1~1 ms走系统硬件层 API减少调度延迟从表里能看出CPU 场景下模型推理是绝对瓶颈。常见做法是先把输入尺寸从 640 降到 416优先保帧率或者换更轻的检测头。这个项目默认走 GPU 推理跑之前先确认torch.cuda.is_available()返回 True否则后面调什么都白搭。3. 三个核心模块的代码拆解项目结构很干净手工维护的只有三个文件utils/FPSUtils.py 负责配置FPSdetect.py 负责模型和推理Main.py 负责主循环。这种拆分方式值得直接抄进自己的项目——配置、推理、控制三层分离后面调参不需要动逻辑代码。3.1 FPSUtils.py分辨率与检测区域的统一出口打开 utils/FPSUtils.py需要改的主要是屏幕分辨率、检测区域和截图方式。我的习惯是先写一个get_screen_size()用系统 API 拿真实分辨率而不是手填 1920×1080避免显示器切换或窗口缩放后坐标全乱。# utils/FPSUtils.py import win32api # 屏幕分辨率也可以运行时自动获取 SCREEN_WIDTH 1920 SCREEN_HEIGHT 1080 # 检测区域只保留屏幕中央跳过边缘减少无效推理 DETECT_REGION { x: int(SCREEN_WIDTH * 0.25), y: int(SCREEN_HEIGHT * 0.20), w: int(SCREEN_WIDTH * 0.50), h: int(SCREEN_HEIGHT * 0.60), } def get_screen_size(): # 用系统 API 自动获取避免手填出错 return win32api.GetSystemMetrics(0), win32api.GetSystemMetrics(1)DETECT_REGION 的 x/y 是检测区域左上角w/h 是宽高。把这四个值集中在一个文件里是因为后面所有模块都要共用同一组坐标FPSdetect.py 用它裁剪截图Main.py 用它做坐标还原。如果直接在各文件里硬编码改一次分辨率要搜三个文件很容易漏改一处导致坐标错位。3.2 FPSdetect.py模型加载与单帧推理封装FPSdetect.py 的核心是attempt_load加载权重。项目给出的示例路径是FPSAutomaticAiming\yolov5s.ptWindows 下反斜杠要用原始字符串或正斜杠。我一般写成环境变量加默认值的组合换机器不用改代码# FPSdetect.py import os import numpy as np import torch from models.experimental import attempt_load from utils.general import non_max_suppression, letterbox from utils.torch_utils import select_device MODEL_PATH os.environ.get(FPS_MODEL, yolov5s.pt) def load_model(): device select_device(0 if torch.cuda.is_available() else cpu) model attempt_load(MODEL_PATH, map_locationdevice) # 加载 FP32 权重 model.eval() return model, deviceattempt_load是 YOLOv5 仓库封装的加载函数比torch.load多了解析 checkpoint 内 model 字段的逻辑直接传 .pt 路径即可。map_locationdevice决定权重落在 GPU 还是 CPU。容易漏的是model.eval()不调用的话 BN 层和 Dropout 会留在训练模式同一张图每次推理结果都可能不同瞄准时准星会像抽风一样乱跳。推理部分建议封装成独立函数输入裁剪帧输出过滤后的目标列表def detect(frame, model, device, conf_thres0.5, iou_thres0.45): img letterbox(frame, 640, stride32)[0] # resize padding 保持宽高比 img img.transpose((2, 0, 1))[::-1] # HWC - CHW, BGR - RGB img np.ascontiguousarray(img) img torch.from_numpy(img).to(device) img img.float() / 255.0 # 归一化到 0~1 if img.ndimension() 3: img img.unsqueeze(0) # 加 batch 维 with torch.no_grad(): pred model(img)[0] pred non_max_suppression(pred, conf_thres, iou_thres)[0] return pred.cpu().numpy() # 每行 [x1, y1, x2, y2, conf, cls]这段把 640×640 输入的预处理流程完整走了一遍letterbox 保持宽高比缩放并补黑边transpose 做 HWC 到 CHW 转换并反转通道顺序归一化后进 NMS。新手最容易把通道顺序搞反导致画面偏红偏蓝检测结果全乱。如果发现检测框位置和实际目标明显错位优先查 letterbox 的 padding 量有没有参与坐标还原。提示YOLOv5 的 letterbox 会补黑边严格场景下要把 padding 量记录并减掉再还原坐标否则目标框整体向右下偏移。3.3 Main.py主循环、目标选择与鼠标执行Main.py 是最后一道拼图把截图、推理、选目标、移动鼠标串起来。选目标策略很关键画面里多个目标同时出现时取置信度最高的框还是取离准星最近的框后者在实战里更合理因为自动瞄准的目的是把准星拉到目标上而不是盯住某个最强目标。# Main.py import time import mss import numpy as np from utils.FPSUtils import DETECT_REGION from FPSdetect import load_model, detect model, device load_model() def pick_target(dets, screen_center): # 多个目标时选离屏幕中心最近的有效框 best, best_dist None, float(inf) for det in dets: cx (det[0] det[2]) / 2 DETECT_REGION[x] cy (det[1] det[3]) / 2 DETECT_REGION[y] dist (cx - screen_center[0]) ** 2 (cy - screen_center[1]) ** 2 if dist best_dist: best_dist dist best det return best with mss.mss() as sct: region { left: DETECT_REGION[x], top: DETECT_REGION[y], width: DETECT_REGION[w], height: DETECT_REGION[h], } center (DETECT_REGION[x] DETECT_REGION[w] // 2, DETECT_REGION[y] DETECT_REGION[h] // 2) while True: frame np.array(sct.grab(region))[:, :, :3] dets detect(frame, model, device) if dets is not None and len(dets) 0: target pick_target(dets, center) tx (target[0] target[2]) / 2 DETECT_REGION[x] ty (target[1] target[3]) / 2 DETECT_REGION[y] # move_mouse 按自己的鼠标协议实现平滑方案见第 4 章 move_mouse(tx, ty) time.sleep(0.005)主循环里我用了 mss 截图sct.grab只抓指定区域比 PIL.ImageGrab 快不少。pick_target返回的是原始检测框但移动鼠标前又做了一次坐标还原因为detect返回的坐标是 letterbox 还原后的裁剪帧坐标必须加上 region 偏移才是屏幕坐标这一点和第 2 章的换算逻辑保持一致。文件职责需要改的参数出错时的典型现象utils/FPSUtils.py分辨率、检测区域SCREEN_WIDTH/HEIGHT、DETECT_REGION目标框位置整体偏移FPSdetect.py权重加载、推理封装MODEL_PATH、conf_thres / iou_thres加载报错 / 漏检误检多Main.py主循环、目标选择、鼠标执行move_mouse、pick_target 策略准星乱跳 / 盯错目标4. 参数标定与鼠标平滑把检测精度落成准星精度4.1 检测区域的标定方法DETECT_REGION 设太大会增加无效推理设太小会漏掉边缘目标。我一般用三分法横向取屏幕中央 50%纵向取中央略偏上 60%。原因是 FPS 游戏里目标活动热区集中在中部上下两端通常是天空和地面不会出现需要瞄准的目标。具体数值取决于游戏视野标定方法是在目标出现在屏幕不同位置时观察检测框是否完整落在区域内。如果目标在区域边缘被截断模型输出的是一个残破的框中心点会偏离真实位置这时候不是调模型而是把区域向外扩一点。4.2 置信度阈值与超参数的联动调整conf_thres 决定多像才算目标。0.5 是通用起步值游戏画面纹理比自然场景简单可以适当调到 0.60.7 减少误检。iou_thres 决定重叠框的合并程度0.45 是 YOLOv5 默认值。如果发现准星在两个目标间反复横跳优先检查是不是 iou_thres 过低导致同一目标被输出成了两个框而不是急着改平滑参数。参数建议范围调低后果调高后果conf_thres0.4~0.7误检变多准星乱动漏检变多目标丢失iou_thres0.4~0.5同一目标输出多个框相邻目标被合并成一个框输入尺寸416~640小目标更难检测推理耗时明显上升检测区域宽度屏幕的 40%~60%边缘目标不可达无效推理比例变高这组参数要联动着调输入尺寸降到 416 后小目标的置信度会整体下降conf_thres 要跟着放宽一档反过来坚持用 640 尺寸就要接受帧率下降并考虑开启 FP16 半精度推理。YOLOv5 的推理代码里把model.half()调用加上输入 tensor 也转成 half在支持 FP16 的显卡上能省掉约 30% 的推理时间。4.3 鼠标平滑与目标速度前馈把 move_mouse 直接替换成 tx/ty 后第一个现象通常是准星剧烈抖动。原因是连续帧里检测框中心在目标身体上来回跳直接把原始坐标交给鼠标准星就跟着抖。常见做法是加一个低通滤波让准星朝目标方向按比例移动而不是瞬移。class SmoothAim: def __init__(self, alpha0.35): self.alpha alpha # 越大响应越快越小越稳 self.cur_x 0.0 self.cur_y 0.0 def step(self, target_x, target_y): # 每帧只移动剩余距离的一部分天然抑制抖动 self.cur_x (target_x - self.cur_x) * self.alpha self.cur_y (target_y - self.cur_y) * self.alpha return int(self.cur_x), int(self.cur_y)alpha 是平滑系数0.35 表示每帧吃掉 35% 的剩余距离。目标越远前半程移动越快接近目标后自动减速这正好符合快速拉近、精细瞄准的操作习惯。目标高速横移时准星跟不上把 alpha 提到 0.5停下时还在小幅摆动降到 0.2。不过纯位置反馈有个固有缺陷目标匀速移动时准星会有一个固定滞后量永远追在目标屁股后面。进阶做法是加速度前馈用最近两帧的目标中心坐标差估算速度把下一帧的预计位移提前加到目标点上def predict_target(prev_center, curr_center, alpha0.8): # 估算目标速度并外推下一帧位置alpha 控制速度估计的平滑度 vx (curr_center[0] - prev_center[0]) * alpha vy (curr_center[1] - prev_center[1]) * alpha return curr_center[0] vx, curr_center[1] vy这一步对移动靶的提升非常明显代价是会引入一点预测误差需要根据实际帧率调整外推系数。帧率越稳定外推越可靠。提示调平滑系数时先固定在一个低速移动的目标上观察不要在混战场景里调否则你分不清是参数问题还是目标切换问题。5. 验证链路与三类高频坑5.1 先用 bus.jpg 打通检测链路项目目录里的 bus.jpg 是 YOLOv5 官方测试图也是一张标准的 COCO 验证图。第一次跑通之前不要直接开游戏调试先用它验证模型和推理代码把 detect 的输入改成读取 bus.jpg如果输出里出现置信度较高的 bus 检测框说明模型加载、预处理、NMS 整条链路是通的。这时候问题只可能出在截图和坐标环节排查范围立刻缩小一半。5.2 权重路径与 map_location 报错attempt_load 最常见的报错是路径分隔符问题。Windows 路径用反斜杠必须写成原始字符串rFPSAutomaticAiming\yolov5s.pt或换成正斜杠否则\y会被当成转义字符。另一个高频报错是 map_location 传了 cuda 但机器上没有可用显卡torch 直接抛 RuntimeError。对应到 FPSdetect.py 的写法就是 select_device 返回了 cpu但 attempt_load 里仍写死 cuda两处必须保持一致。5.3 坐标偏移与 DPI 缩放的验证启动前要改的三处——分辨率、检测区域、鼠标代码——改完后如何确认坐标链路是对的一个实用的验证方法是把 move_mouse 暂时替换成打印目标坐标然后在游戏里固定准星移动角色让目标出现在屏幕不同位置比对打印坐标和实际目标位置。如果横向对、纵向偏优先怀疑 Windows DPI 缩放显示设置里缩放不是 100% 时系统 API 拿到的分辨率和游戏实际渲染分辨率不一致。解决方式是右键主程序在兼容性设置里勾选替代高 DPI 缩放行为。验证通过后再把鼠标移动接回主循环。正式运行前务必加一个紧急停止开关检测到全局热键就跳出 while 循环。这类系统调试时最容易出的问题就是鼠标被永久接管窗口失焦也停不下来一个可靠的热键退出比任何精度优化都重要。本文还有配套的精品资源点击获取 YOLOv5自动瞄准实战：从检测框到屏幕坐标的完整映射链路
简介基于YOLOV5的FPS类游戏自动瞄准系统是一套面向目标检测学习者的可运行完整项目。它整合了YOLOv5模型推理、屏幕画面捕获、检测框范围配置及鼠标移动模拟等模块适合作为毕业设计、课程设计或工程实训的起步参考。资源共110个文件压缩包约76.98MB以29个Python脚本、28个YAML参数配置、13个pyc编译文件及3个pt模型权重为主体另有sh启动脚本、图像样本、文本说明和Dockerfile等辅助内容目录结构清晰。目前已有883人学习下载项目内附带训练日志与示例图片可直观观察YOLOv5训练过程中的标签图、相关图及批次样本便于理解检测效果。使用前只需在FPSUtils.py中调整分辨率、在FPSdetect.py中指定模型路径即可快速启动体验。1. YOLOv5 自动瞄准一次从检测框到准星的坐标接力做 FPS 自动瞄准真正的难点不在模型训练而在坐标链路YOLOv5 只给出图像坐标系里的目标框鼠标需要的是屏幕坐标系的位移。两者之间隔着分辨率换算、检测区域裁剪、推理耗时和鼠标平滑几道关卡漏掉任何一环准星都不会听话。这个项目用 yolov5s 做检测核心配置、推理、控制拆成三个文件构成一条完整的视觉到外设闭环适合做毕设、课程设计或想看清检测结果如何被消费的 YOLOv5 学习者。项目里自带的 bus.jpg、labels_correlogram.jpg 和 train_batch 系列图片都是训练和验证阶段留下的产物可以直接拿来验证链路。需要划清边界这套链路只建议在单机、离线或允许 Mod 的场景里验证技术接入在线对战属于破坏公平性的行为。坐标映射与实时推理的思路本身是中性的换到巡检、抓取等场景依然成立。2. YOLOv5s 检测链路与目标坐标映射2.1 为什么选 yolov5s精度与帧率的平衡点YOLOv5 按深度和宽度系数分成 s、m、l、x 四个常用版本。s 是 smallest权重文件 yolov5s.pt 约 14 MB在 COCO 上 mAP 大概 37 出头GTX 1060 级别显卡上单帧推理可以做到 510 ms。自动瞄准是强实时任务从看到目标到准星移动的整条链路超过 100 ms操作感就会明显发粘所以选型的第一优先级是延迟而不是 mAP。游戏画面里的目标类别固定、背景相对单纯yolov5s 的精度完全够用。这里有个常见误区总想换更大的模型提升识别率。实际在自动瞄准场景里漏检通常不是因为模型不够强而是训练数据没覆盖目标的外观变化。盲目升级到 yolov5l帧率几乎掉一半收益却很小。先保证 30 FPS 以上的稳定推理再考虑精度才是正确的调优顺序。项目目录里的 labels_correlogram.jpg 是训练阶段的标注相关性分布图train_batch1.jpg 和 train_batch2.jpg 是批数据预览这些图能帮你快速判断数据集本身有没有问题而不是去怀疑模型。2.2 检测框坐标到屏幕坐标的换算2.2.1 坐标系定义与区域偏移YOLOv5 默认输出 xyxy 格式即[x1, y1, x2, y2, conf, cls]单位是像素原点在输入图像左上角。问题在于喂给模型的帧是从屏幕检测区域裁剪下来的不是完整屏幕所以目标在屏幕上的真实位置必须加上检测区域左上角的偏移量。def box_to_screen(box, region): # box: 模型输出的单个目标框 [x1, y1, x2, y2, conf, cls] # region: FPSUtils.py 里配置的检测区域含 x/y/w/h cx (box[0] box[2]) / 2.0 # 检测框中心 x区域坐标系 cy (box[1] box[3]) / 2.0 # 检测框中心 y区域坐标系 screen_x int(region[x] cx) screen_y int(region[y] cy) return screen_x, screen_yregion[x]和region[y]是检测区域左上角相对屏幕左上角的偏移cx和cy是目标在裁剪帧里的中心。这里有个精度隐患如果 region 的宽高和实际截图的尺寸不一致偏移量会整体错位表现为目标框在屏幕上贴不准目标。这个现象在第 5 章会给出验证方法。2.2.2 缩放还原letterbox 之后的坐标补偿另一个高频坑是图像缩放。推理前通常会把截图 resize 到 640×640 输入给模型模型输出的是 resize 后的坐标。不做比例还原直接映射屏幕坐标会整体偏小准星永远落在目标左上方。def restore_scale(box, orig_w, orig_h, input_size640): # 模型在 640x640 下推理还原到原始裁剪帧尺寸 scale_x orig_w / input_size scale_y orig_h / input_size x1, y1 box[0] * scale_x, box[1] * scale_y x2, y2 box[2] * scale_x, box[3] * scale_y return [x1, y1, x2, y2]注意这段是简化版只处理了等比缩放。如果用了 letterbox 补边还需要把 padding 的像素量先减掉再乘缩放比例否则目标位置会向下向右偏移一块固定距离。2.3 推理耗时预算一条链路能容忍多少延迟把整条链路拆开看大致是屏幕截图 0.52 ms图像预处理 13 ms模型推理 510 ms后处理和坐标换算小于 1 ms鼠标指令下发 0.11 ms。GPU 推理时合计约 1020 ms这是跟手的前提。一旦 fallback 到 CPU模型推理单项就要 3060 ms整链路逼近 100 ms准星明显跟不上目标。环节GPU 推理耗时CPU 推理耗时常见优化手段屏幕截图0.5~2 ms0.5~2 ms用 mss 替代 PIL.ImageGrab预处理1~3 ms1~3 ms直接转 tensor少做额外复制模型推理5~10 ms30~60 msFP16 半精度、输入尺寸降到 416后处理坐标换算1 ms1 ms只对通过阈值的目标做换算鼠标指令0.1~1 ms0.1~1 ms走系统硬件层 API减少调度延迟从表里能看出CPU 场景下模型推理是绝对瓶颈。常见做法是先把输入尺寸从 640 降到 416优先保帧率或者换更轻的检测头。这个项目默认走 GPU 推理跑之前先确认torch.cuda.is_available()返回 True否则后面调什么都白搭。3. 三个核心模块的代码拆解项目结构很干净手工维护的只有三个文件utils/FPSUtils.py 负责配置FPSdetect.py 负责模型和推理Main.py 负责主循环。这种拆分方式值得直接抄进自己的项目——配置、推理、控制三层分离后面调参不需要动逻辑代码。3.1 FPSUtils.py分辨率与检测区域的统一出口打开 utils/FPSUtils.py需要改的主要是屏幕分辨率、检测区域和截图方式。我的习惯是先写一个get_screen_size()用系统 API 拿真实分辨率而不是手填 1920×1080避免显示器切换或窗口缩放后坐标全乱。# utils/FPSUtils.py import win32api # 屏幕分辨率也可以运行时自动获取 SCREEN_WIDTH 1920 SCREEN_HEIGHT 1080 # 检测区域只保留屏幕中央跳过边缘减少无效推理 DETECT_REGION { x: int(SCREEN_WIDTH * 0.25), y: int(SCREEN_HEIGHT * 0.20), w: int(SCREEN_WIDTH * 0.50), h: int(SCREEN_HEIGHT * 0.60), } def get_screen_size(): # 用系统 API 自动获取避免手填出错 return win32api.GetSystemMetrics(0), win32api.GetSystemMetrics(1)DETECT_REGION 的 x/y 是检测区域左上角w/h 是宽高。把这四个值集中在一个文件里是因为后面所有模块都要共用同一组坐标FPSdetect.py 用它裁剪截图Main.py 用它做坐标还原。如果直接在各文件里硬编码改一次分辨率要搜三个文件很容易漏改一处导致坐标错位。3.2 FPSdetect.py模型加载与单帧推理封装FPSdetect.py 的核心是attempt_load加载权重。项目给出的示例路径是FPSAutomaticAiming\yolov5s.ptWindows 下反斜杠要用原始字符串或正斜杠。我一般写成环境变量加默认值的组合换机器不用改代码# FPSdetect.py import os import numpy as np import torch from models.experimental import attempt_load from utils.general import non_max_suppression, letterbox from utils.torch_utils import select_device MODEL_PATH os.environ.get(FPS_MODEL, yolov5s.pt) def load_model(): device select_device(0 if torch.cuda.is_available() else cpu) model attempt_load(MODEL_PATH, map_locationdevice) # 加载 FP32 权重 model.eval() return model, deviceattempt_load是 YOLOv5 仓库封装的加载函数比torch.load多了解析 checkpoint 内 model 字段的逻辑直接传 .pt 路径即可。map_locationdevice决定权重落在 GPU 还是 CPU。容易漏的是model.eval()不调用的话 BN 层和 Dropout 会留在训练模式同一张图每次推理结果都可能不同瞄准时准星会像抽风一样乱跳。推理部分建议封装成独立函数输入裁剪帧输出过滤后的目标列表def detect(frame, model, device, conf_thres0.5, iou_thres0.45): img letterbox(frame, 640, stride32)[0] # resize padding 保持宽高比 img img.transpose((2, 0, 1))[::-1] # HWC - CHW, BGR - RGB img np.ascontiguousarray(img) img torch.from_numpy(img).to(device) img img.float() / 255.0 # 归一化到 0~1 if img.ndimension() 3: img img.unsqueeze(0) # 加 batch 维 with torch.no_grad(): pred model(img)[0] pred non_max_suppression(pred, conf_thres, iou_thres)[0] return pred.cpu().numpy() # 每行 [x1, y1, x2, y2, conf, cls]这段把 640×640 输入的预处理流程完整走了一遍letterbox 保持宽高比缩放并补黑边transpose 做 HWC 到 CHW 转换并反转通道顺序归一化后进 NMS。新手最容易把通道顺序搞反导致画面偏红偏蓝检测结果全乱。如果发现检测框位置和实际目标明显错位优先查 letterbox 的 padding 量有没有参与坐标还原。提示YOLOv5 的 letterbox 会补黑边严格场景下要把 padding 量记录并减掉再还原坐标否则目标框整体向右下偏移。3.3 Main.py主循环、目标选择与鼠标执行Main.py 是最后一道拼图把截图、推理、选目标、移动鼠标串起来。选目标策略很关键画面里多个目标同时出现时取置信度最高的框还是取离准星最近的框后者在实战里更合理因为自动瞄准的目的是把准星拉到目标上而不是盯住某个最强目标。# Main.py import time import mss import numpy as np from utils.FPSUtils import DETECT_REGION from FPSdetect import load_model, detect model, device load_model() def pick_target(dets, screen_center): # 多个目标时选离屏幕中心最近的有效框 best, best_dist None, float(inf) for det in dets: cx (det[0] det[2]) / 2 DETECT_REGION[x] cy (det[1] det[3]) / 2 DETECT_REGION[y] dist (cx - screen_center[0]) ** 2 (cy - screen_center[1]) ** 2 if dist best_dist: best_dist dist best det return best with mss.mss() as sct: region { left: DETECT_REGION[x], top: DETECT_REGION[y], width: DETECT_REGION[w], height: DETECT_REGION[h], } center (DETECT_REGION[x] DETECT_REGION[w] // 2, DETECT_REGION[y] DETECT_REGION[h] // 2) while True: frame np.array(sct.grab(region))[:, :, :3] dets detect(frame, model, device) if dets is not None and len(dets) 0: target pick_target(dets, center) tx (target[0] target[2]) / 2 DETECT_REGION[x] ty (target[1] target[3]) / 2 DETECT_REGION[y] # move_mouse 按自己的鼠标协议实现平滑方案见第 4 章 move_mouse(tx, ty) time.sleep(0.005)主循环里我用了 mss 截图sct.grab只抓指定区域比 PIL.ImageGrab 快不少。pick_target返回的是原始检测框但移动鼠标前又做了一次坐标还原因为detect返回的坐标是 letterbox 还原后的裁剪帧坐标必须加上 region 偏移才是屏幕坐标这一点和第 2 章的换算逻辑保持一致。文件职责需要改的参数出错时的典型现象utils/FPSUtils.py分辨率、检测区域SCREEN_WIDTH/HEIGHT、DETECT_REGION目标框位置整体偏移FPSdetect.py权重加载、推理封装MODEL_PATH、conf_thres / iou_thres加载报错 / 漏检误检多Main.py主循环、目标选择、鼠标执行move_mouse、pick_target 策略准星乱跳 / 盯错目标4. 参数标定与鼠标平滑把检测精度落成准星精度4.1 检测区域的标定方法DETECT_REGION 设太大会增加无效推理设太小会漏掉边缘目标。我一般用三分法横向取屏幕中央 50%纵向取中央略偏上 60%。原因是 FPS 游戏里目标活动热区集中在中部上下两端通常是天空和地面不会出现需要瞄准的目标。具体数值取决于游戏视野标定方法是在目标出现在屏幕不同位置时观察检测框是否完整落在区域内。如果目标在区域边缘被截断模型输出的是一个残破的框中心点会偏离真实位置这时候不是调模型而是把区域向外扩一点。4.2 置信度阈值与超参数的联动调整conf_thres 决定多像才算目标。0.5 是通用起步值游戏画面纹理比自然场景简单可以适当调到 0.60.7 减少误检。iou_thres 决定重叠框的合并程度0.45 是 YOLOv5 默认值。如果发现准星在两个目标间反复横跳优先检查是不是 iou_thres 过低导致同一目标被输出成了两个框而不是急着改平滑参数。参数建议范围调低后果调高后果conf_thres0.4~0.7误检变多准星乱动漏检变多目标丢失iou_thres0.4~0.5同一目标输出多个框相邻目标被合并成一个框输入尺寸416~640小目标更难检测推理耗时明显上升检测区域宽度屏幕的 40%~60%边缘目标不可达无效推理比例变高这组参数要联动着调输入尺寸降到 416 后小目标的置信度会整体下降conf_thres 要跟着放宽一档反过来坚持用 640 尺寸就要接受帧率下降并考虑开启 FP16 半精度推理。YOLOv5 的推理代码里把model.half()调用加上输入 tensor 也转成 half在支持 FP16 的显卡上能省掉约 30% 的推理时间。4.3 鼠标平滑与目标速度前馈把 move_mouse 直接替换成 tx/ty 后第一个现象通常是准星剧烈抖动。原因是连续帧里检测框中心在目标身体上来回跳直接把原始坐标交给鼠标准星就跟着抖。常见做法是加一个低通滤波让准星朝目标方向按比例移动而不是瞬移。class SmoothAim: def __init__(self, alpha0.35): self.alpha alpha # 越大响应越快越小越稳 self.cur_x 0.0 self.cur_y 0.0 def step(self, target_x, target_y): # 每帧只移动剩余距离的一部分天然抑制抖动 self.cur_x (target_x - self.cur_x) * self.alpha self.cur_y (target_y - self.cur_y) * self.alpha return int(self.cur_x), int(self.cur_y)alpha 是平滑系数0.35 表示每帧吃掉 35% 的剩余距离。目标越远前半程移动越快接近目标后自动减速这正好符合快速拉近、精细瞄准的操作习惯。目标高速横移时准星跟不上把 alpha 提到 0.5停下时还在小幅摆动降到 0.2。不过纯位置反馈有个固有缺陷目标匀速移动时准星会有一个固定滞后量永远追在目标屁股后面。进阶做法是加速度前馈用最近两帧的目标中心坐标差估算速度把下一帧的预计位移提前加到目标点上def predict_target(prev_center, curr_center, alpha0.8): # 估算目标速度并外推下一帧位置alpha 控制速度估计的平滑度 vx (curr_center[0] - prev_center[0]) * alpha vy (curr_center[1] - prev_center[1]) * alpha return curr_center[0] vx, curr_center[1] vy这一步对移动靶的提升非常明显代价是会引入一点预测误差需要根据实际帧率调整外推系数。帧率越稳定外推越可靠。提示调平滑系数时先固定在一个低速移动的目标上观察不要在混战场景里调否则你分不清是参数问题还是目标切换问题。5. 验证链路与三类高频坑5.1 先用 bus.jpg 打通检测链路项目目录里的 bus.jpg 是 YOLOv5 官方测试图也是一张标准的 COCO 验证图。第一次跑通之前不要直接开游戏调试先用它验证模型和推理代码把 detect 的输入改成读取 bus.jpg如果输出里出现置信度较高的 bus 检测框说明模型加载、预处理、NMS 整条链路是通的。这时候问题只可能出在截图和坐标环节排查范围立刻缩小一半。5.2 权重路径与 map_location 报错attempt_load 最常见的报错是路径分隔符问题。Windows 路径用反斜杠必须写成原始字符串rFPSAutomaticAiming\yolov5s.pt或换成正斜杠否则\y会被当成转义字符。另一个高频报错是 map_location 传了 cuda 但机器上没有可用显卡torch 直接抛 RuntimeError。对应到 FPSdetect.py 的写法就是 select_device 返回了 cpu但 attempt_load 里仍写死 cuda两处必须保持一致。5.3 坐标偏移与 DPI 缩放的验证启动前要改的三处——分辨率、检测区域、鼠标代码——改完后如何确认坐标链路是对的一个实用的验证方法是把 move_mouse 暂时替换成打印目标坐标然后在游戏里固定准星移动角色让目标出现在屏幕不同位置比对打印坐标和实际目标位置。如果横向对、纵向偏优先怀疑 Windows DPI 缩放显示设置里缩放不是 100% 时系统 API 拿到的分辨率和游戏实际渲染分辨率不一致。解决方式是右键主程序在兼容性设置里勾选替代高 DPI 缩放行为。验证通过后再把鼠标移动接回主循环。正式运行前务必加一个紧急停止开关检测到全局热键就跳出 while 循环。这类系统调试时最容易出的问题就是鼠标被永久接管窗口失焦也停不下来一个可靠的热键退出比任何精度优化都重要。本文还有配套的精品资源点击获取