ok-ww 鸣潮自动化脚本已经稳定跑了三周每天登录后第一件事就是把日常全部托管出去。很多人第一反应是这东西是不是很复杂其实核心逻辑非常朴素定时调度、图像识别、模拟输入。这篇设置指南我会把整个项目拆开来讲包括设计思路、环境配置、关键实现和实际踩坑记录目标是让刚拿到脚本的人也能在10分钟内跑通基础环境并且能按自己的习惯调整任务队列。先给个预期这套脚本解决的是“花时间重复点按钮”的问题不是自动打怪也不是碰竞技内容。它适合每天都要清日常、但又不想把时间耗在固定操作上的玩家也适合想入门“桌面自动化”写法的开发者。下面从设计思路开始一步步说清楚。1. 先把设计思路理清楚这套脚本到底在自动化什么1.1 日常任务为什么适合做自动化《鸣潮》这类开放世界动作游戏的日常流程有个很明显的特征大量操作是固定且重复的。打开某个界面领取每日奖励点一下派遣入口确认声骸收集切换体力副本一键合成再关掉提示弹窗。这些动作每天走一遍位置基本不变流程顺序也不变只是玩家手动点会觉得很枯燥。自动化脚本能成立前提是三个条件都满足第一是操作对象的位置固定第二是操作结果可以用画面变化来判定第三是流程可以线性拆解成步骤队列。日常任务三点全占。按钮图标固定领取后会出现奖励确认画面任务链可以拆成“进入界面→点击目标→确认结果→进入下一步”。这些条件天然适合用图像识别加模拟点击来做不需要读取游戏内存也不需要修改客户端文件风险面小很多。我在设计脚本时没有把“自动战斗”加进去除了合规考虑还有一个技术原因战斗过程变数太大识别逻辑会非常复杂而且出了问题很难排查。日常任务就不一样场景固定、目标固定、判定结果固定用小成本就能获得很高的可靠性。1.2 技术选型为什么用 Python 加 OpenCV而不是现成工具市面上的按键类工具很多做常规自动化确实够用但我选择自己用 Python 写理由是可控性。现成工具的大部分功能都封装在黑盒里识别失败时很难判断是模板图的问题、窗口缩放的锅还是模拟点击被拦截了。自己写脚本每一步都有日志出现偏差可以直接看截图定位。技术栈其实不多Python 3.10、OpenCV 负责模板匹配pywin32 负责窗口句柄获取和后台消息发送Pillow 负责截屏处理再用标准库 time、logging 做调度和日志。整个依赖不到十个包安装成本很低。后面所有章节里的代码都是我实际在用的版本不搞花活能跑通才算数。选 OpenCV 做图像识别而不是用更复杂的深度学习方案是因为模板匹配在“固定 UI 场景”下已经足够。游戏 UI 里的按钮、图标、弹窗位置都是静态的模板匹配相当于在一张大图里找一张小图的位置速度和精度都够用。深度学习方案适合识别内容不固定的场景比如野生素材、动态怪物对日常任务来说是过度设计。1.3 模块划分调度、识别、点击、日志各管一摊脚本写成一个大文件并不是不行但排查问题时会很痛苦。我按职责拆成了四个模块任务调度、图像识别、输入模拟、日志告警。任务调度负责编排“先做什么后做什么”也就是任务队列图像识别负责从截屏画面里找到目标坐标输入模拟负责把坐标转换成点击、按键消息发送给游戏窗口日志告警负责记录每次动作的结果以及发现异常时截存现场图片。四个模块各管一摊哪个环节出问题看日志就能定位到具体模块不用对着几百行代码猜。这种拆分还有一个好处如果你想换个游戏只需要更换任务调度里的流程列表和模板图片识别、模拟输入这些底层模块基本不用动。后续扩展新功能也只要在任务队列里加一步操作不影响其他逻辑。2. 环境准备与核心配置10 分钟跑通的前置条件2.1 安装 Python 与依赖第一步是准备 Python 环境。建议直接用 3.10 或更高的稳定版本太低版本的 OpenCV 会出现兼容问题太高版本偶尔会遇到部分库没有预编译包的情况。安装命令在 Windows 下很简单打开命令行执行pip install opencv-python pillow pywin32 loguru这几个包就是全部依赖。OpenCV 用来做模板匹配和图像处理Pillow 用来截屏和保存图片pywin32 用来调 Windows 窗口消息loguru 用来打日志。装完可以快速验证一下在 Python 里执行import cv2不报错就说明环境没问题。装依赖这一步经常有人卡在镜像源上如果你在国内网络环境下安装慢可以临时换用镜像源把 pip 命令改成带-i 镜像地址的形式。装完之后我建议顺手把版本号固定到requirements.txt里避免哪天升级了依赖导致脚本行为变化。2.2 获取窗口句柄与游戏显示区域后台挂机和一键日常都绕不开“找到游戏窗口”这一步。Windows 下每个窗口都有一个句柄hwnd脚本先通过窗口标题找到句柄再根据句柄拿到窗口的显示区域位置和大小后续所有截图、点击都基于这个区域计算。获取句柄最简单的方式是用 pywin32 的FindWindow它支持按窗口标题模糊匹配。不过《鸣潮》这种游戏客户端可能有多个顶层窗口直接用FindWindow可能拿到的是容器窗口而不是实际渲染区域建议用EnumWindows遍历所有窗口按标题和类名双重条件筛选。拿到句柄后再用GetClientRect和ClientToScreen把客户区坐标转成屏幕坐标。这里有个很容易踩的坑系统 DPI 缩放。如果 Windows 显示设置里缩放比例不是 100%截图和点击坐标会整体偏移。解决办法是在main里先调用系统 API 禁用 DPI 感知的进程级缩放或者把游戏窗口所在显示器的缩放统一成 100%。我建议两种都写上先禁用进程 DPI 感知再在配置里加一个dpi_scale参数兜底。2.3 核心配置项说明与推荐值脚本根目录下有个config.yaml所有可调参数都集中在这里。第一次跑通时大部分参数保持默认就行只有几个关键项需要确认。配置项作用推荐值说明window_title游戏窗口标题关键字客户端标题用于查找窗口句柄match_threshold模板匹配置信度阈值0.85太高容易漏识别太低容易误点click_interval两次点击之间的基础间隔0.3 秒太快会被窗口消息队列丢弃retry_count单个步骤失败后的重试次数5 次超过后跳过并记录screenshot_dir异常截图保存目录./logs/screenshots排障时非常有用task_queue启用哪些日常任务预置列表按实际需求调整开关重点说一下match_threshold。这个值决定了一张图“像不像”模板。我推荐从 0.85 起步如果发现漏识别就适当降低比如 0.8如果发现频繁错点就升高比如 0.9。阈值不是越大越好因为游戏画面里按钮周围经常有动态特效模板匹配分数会波动需要找到一个自己能接受的平衡点。我的做法是每个模板准备两张图一张普通状态、一张高亮状态识别时取匹配分数高的一张这样阈值可以稳定设在 0.85 附近。2.4 首次启动校准先让脚本“看见”按钮环境装好、配置填好之后不要急着跑全流程。我第一次开发时就犯过这个错误直接全流程跑结果卡在第一步半天没反应。正确做法是先做一次识别校准让脚本截一张当前游戏画面手动指定画面里的“每日任务”入口坐标保存为模板图再运行一次单独识别测试。校准的流程可以做成一个独立函数截屏 → 显示图片 → 用鼠标框选目标区域 → 保存为模板文件 → 用模板对该区域做一次匹配测试。这样能确认整条链路走得通截屏正常、模板能被识别、坐标换算正确。校准通过后再去跑完整任务队列成功率会高很多。3. 一键日常与后台挂机实现细节3.1 模板匹配怎么找按钮和入口模板匹配的原理不复杂就是拿一张小图在大图里逐像素滑动计算每个位置的相似度最后取相似度最高的地方作为命中点。在游戏界面里按钮、图标、弹窗都满足“形状固定”的条件所以这个方法很有效。核心代码非常简单import cv2 import numpy as np def find_template(screen, template, threshold0.85): # screen 是当前截屏的 BGR 图像 # template 是预先保存的按钮或区域模板 screen_gray cv2.cvtColor(screen, cv2.COLOR_BGR2GRAY) template_gray cv2.cvtColor(template, cv2.COLOR_BGR2GRAY) result cv2.matchTemplate(screen_gray, template_gray, cv2.TM_CCOEFF_NORMED) _, max_val, _, max_loc cv2.minMaxLoc(result) if max_val threshold: h, w template_gray.shape[:2] center_x max_loc[0] w // 2 center_y max_loc[1] h // 2 return (center_x, center_y), max_val return None, max_val返回的是“找到的坐标 匹配分数”。如果分数低于阈值脚本会认为目标不在当前画面进入重试逻辑。注意这里的坐标是基于截屏原图的像素坐标不是最终点击屏幕的坐标。完整的坐标还需要叠加窗口客户区在屏幕上的偏移。有一个经验模板图一定要从同尺寸的游戏画面里截取不要自己去缩小放大。比如游戏窗口固定为 1920x1080模板图就在这个分辨率下截取。如果你把游戏窗口改成 1600x900必须同步缩放模板否则识别率会直线下降。我在代码里做了自动缩放逻辑但还是建议尽量固定窗口尺寸省掉一层不确定性。3.2 后台模拟点击坐标换算与消息发送“后台挂机”的核心在于模拟点击不能依赖鼠标指针真实移动。如果切到其他窗口鼠标坐标就对不上了所以必须用 Windows 消息机制直接把点击指令发给目标窗口。第一步先把匹配坐标换算成窗口客户区坐标。之前通过ClientToScreen拿到了窗口客户区左上角的屏幕坐标那么目标点在客户区内的坐标就是画面坐标 - 客户区左上角坐标。换算之后用PostMessage发送鼠标按下和抬起的消息import win32api import win32con import win32gui def click_at(hwnd, x, y, delay0.05): lparam win32api.MAKELONG(x, y) win32gui.PostMessage(hwnd, win32con.WM_MOUSEMOVE, 0, lparam) win32gui.PostMessage(hwnd, win32con.WM_LBUTTONDOWN, win32con.MK_LBUTTON, lparam) win32api.Sleep(int(delay * 1000)) win32gui.PostMessage(hwnd, win32con.WM_LBUTTONUP, 0, lparam)这段代码在很多窗口程序里都能生效因为消息直接进入了窗口的消息队列不需要窗口处于前台。但它有两个边界条件必须清楚。一是部分游戏引擎对WM_LBUTTONDOWN/UP做了额外校验可能要求先有WM_MOUSEMOVE消息甚至要配合WM_ACTIVATE激活消息才响应所以我在发送点击前先发一个WM_MOUSEMOVE。二是如果你发现后台点击完全无效很可能这个游戏窗口在失焦时暂停了渲染或者过滤了非激活状态的消息那就需要换一种方案。3.3 日常任务队列编排任务队列是整个脚本里最贴近需求的模块。我的做法是把每个日常操作定义成一个“步骤对象”包含识别模板、执行点击、等待确认、判定成功四项内容。然后用一个列表把它们排好顺序脚本按顺序执行每完成一步记录一次日志。以当前预置队列为例大致是这样1. 打开“每日任务”面板 2. 领取今日活跃奖励 3. 进入声骸派遣界面 4. 确认派遣结果并领取奖励 5. 清理指定副本的体力 6. 回主城进行一次材料合成 7. 关闭所有弹窗并返回主界面每个步骤之间我都设置了额外的等待间隔这个间隔不是死的会根据上次识别耗时动态调整。比如等待画面加载时我会先截屏识别“确认”按钮如果没出现说明可能还在加载就继续等待而不是盲目点击。这样能避免“点了早了一秒导致点歪”的问题。队列执行完成后脚本会生成一份摘要日志列出每个步骤用了多少次尝试、有没有跳过、总耗时多久。这个摘要对后续调参特别有用比如你发现某一步重试率很高就可以针对那一步单独截屏排查。3.4 挂机循环的心跳与节流后台挂机不是只跑一次任务队列就结束而是要在后台持续运行每隔一段时间检查当前状态并执行必要操作。我把它设计成一个带心跳的循环每隔 5 秒截一次图判断当前是否处于主界面如果是则按任务队列顺序执行如果不是则判断是否卡在某个弹窗里尝试关闭弹窗后回到主界面。这个心跳间隔很有讲究。太短会因为频繁截屏消耗较多 CPU太长又会让脚本反应迟钝。5 秒是我实测下来比较平衡的值挂机时 CPU 占用能控制在比较低的水平。节流机制也非常重要。脚本里所有动作之间都加了最小间隔限制防止出现两个操作在同一个瞬间发出导致消息被丢弃。实际跑下来最稳定的节奏是识别耗时 200 毫秒等待 点击消息 300 毫秒等待。整个队列跑完大概三到四分钟比手动点击慢一点但完全不用人盯着。4. 常见问题与排查技巧实录4.1 识别不到模板或坐标偏移这是最常遇到的问题症状表现为日志里连续出现“目标未找到”或者点击位置明显偏了。对照排查表来定位会比较快现象可能原因处理方式一直报 target not found游戏画面尺寸和模板不一致固定游戏窗口分辨率重建模板偶尔识别失败按钮上有动态特效遮挡降低 match_threshold 到 0.8 附近点击位置偏左上或偏右下窗口客户区坐标换算错误用 ClientToScreen 重新计算偏移设置缩放后全部错位系统 DPI 缩放影响禁用进程 DPI 感知或统一缩放比例窗口被遮挡时识别不到后台截屏被系统裁剪改成窗口可见但移出主屏幕范围的方式我之前被 DPI 缩放坑过一次表现是识别到的坐标看起来正常但点击总是点偏。排查到最后发现是系统缩放 125%窗口客户区坐标乘以缩放系数后产生了偏差。后来我在程序初始化时直接调用 SetProcessDPIAware把这个问题从根上解决了。4.2 后台挂机一切到桌面就失效后台模式能不能生效核心取决于游戏窗口在失去焦点后是否继续渲染。有些游戏客户端一旦失焦就会降低帧率甚至暂停画面渲染这时候截屏得到的画面是冻结的识别逻辑自然就全乱了。针对这种窗口我的处理方法是把窗口挪到屏幕显示区域之外比如通过SetWindowPos把窗口移动到 (-32000, -32000) 的位置。这样窗口仍然处于“前台可见”状态不会失焦但人眼已经看不到它占用桌面空间了。这个技巧不一定对所有游戏有效因为有些游戏会检测窗口是否完全不可见但至少在我的环境里是能正常工作的。如果这个方案也不行那就只能保持窗口在桌面不被遮挡或者接受前台执行的方式。4.3 任务卡死和无限重试脚本跑长时间后容易遇到一个场景某个弹窗没按预期出现导致后续步骤全部卡住。如果脚本没有超时机制就会陷入无限重试的死循环。我给每个步骤都加了两道保险。第一道是重试上限默认每个步骤最多重试 5 次超过之后记录异常并跳过不让整个队列卡死。第二道是看门狗机制如果心跳循环连续 10 次都没有成功完成任何一个任务步骤就自动重启当前任务队列并保存这几轮的现场截图。截图存在./logs/screenshots目录下文件名带时间戳翻看日志时能直接对应上当时的画面状态。排查卡死问题时我通常直接看日志里的时间戳。如果最后一条日志和当前时间差了一大截说明脚本可能陷入了某个不可见的等待循环这时重点去看最近保存的异常截图一眼就能看出是不是弹窗“长”得和预期不一样。4.4 使用边界与合规建议这个话题很多人会刻意回避但我觉得必须讲清楚。脚本本质是“替代手动重复点击的个人辅助工具”不是外挂它不读取或修改游戏数据不提供自动战斗能力也不涉及任何对抗玩家逻辑。但即便如此自动化操作仍然有可能违反游戏用户协议中关于第三方工具的条款。我的建议非常明确不要拿主账号做测试先用一个不重要的账号在低峰时段运行不要长时间高频使用避免对服务器产生异常请求量不要让脚本完全无人值守跑一整天。务必及时关注游戏官方对外部工具的更新说明如果明确禁止就停止使用。脚本长期维护也是一个实际问题。游戏界面一旦改版模板图就可能全部失效。我每次基础更新后都会重新截一遍模板更新队列顺序测试完整流程。总之这类工具的生命力在于“能用就够用”不要追求过度自动化也不要赌它永远不会失效。5. 实操心得与后续扩展方向我自己实际跑了一个多月最大的体会是“克制”。最初我也想把战斗系统自动化和素材规划加进去后来发现每一层复杂度的提升都会让出问题的概率成倍增加。现在这套脚本只维护最稳定的那批固定日常效果反而最好。每次更新游戏版本我只花十几分钟重新校准模板就能再稳定用很久。如果你想让脚本更贴合自己的账号习惯可以从三个方向扩展。一是增加定时执行功能比如每天固定时间自动跑完队列这需要把心跳模块改成基于调度表的循环二是增加素材消耗统计在合成步骤后读取背包数量变化输出一份每日消耗报告三是给异常推送加一个通知渠道比如通过本地 HTTP 请求转发到手机这样人在外面也能看到脚本执行状态。还有一个小技巧是给自己留一条“手动兜底”路径脚本跑完或异常退出后不要自动重试太多次而是留一个快捷键暂停所有动作回到手动操作。自动化工具一旦失控最可怕的不是点击错位置而是它在一片混乱中继续执行预设任务。让脚本学会“停下来等人处理”比让它更聪明地自动恢复更实用。如果你正准备把这套方案用在其他固定 UI 的工作流上可以照搬本文的模块拆分思路。识别、点击、调度这三层是通用骨架替换模板图和任务队列就能适配新的场景。唯一需要认真对待的是后台点击能不能生效这件事建议先花 30 分钟做一次链路验证再决定要不要继续投入。