Python+计算机视觉实现Windows自动化脚本：从定点点击到动态识别

weixin_30892889

487人浏览 · 2026-08-30 12:45:30

weixin_30892889 · 2026-08-30 12:45:30 发布

简介：本资源是一套面向Python初学者与游戏自动化爱好者的技术实践脚本，聚焦解决《梦幻西游》中传统定点点击辅助易失效、适配性差的核心痛点。通过融合计算机视觉（PIL图像识别）、Windows底层操作（pywin32模拟鼠标/窗口控制）与轻量模板匹配逻辑，实现对游戏界面中按钮、任务图标等动态元素的鲁棒定位与精准交互，显著提升重复操作效率。压缩包共19个文件，含3个核心Python源码（mhxy_fz.py为主控脚本，memory_pic.py负责图像比对）、8张标注清晰的游戏界面截图（用于模板匹配）、4个XML配置文件（定义识别区域与阈值参数）、2个编译缓存文件及1份README说明文档，整体仅436KB，结构紧凑、即下即用。目前已有187人学习下载，读者可直接复现完整辅助流程，掌握图像采集→模板构建→窗口捕获→坐标计算→鼠标触发的全链路开发思路，并获得可扩展的模块化代码框架与典型游戏UI识别排错经验。做游戏自动化脚本的老哥应该都有过类似的经历：最早写挂机脚本，清一色用固定坐标定点点击，跑起来像模像样，结果游戏一更新、窗口一缩放、分辨率一改，脚本直接废掉，还得重新录制一遍坐标。后来我换了一套思路，用计算机视觉直接识别画面里的目标，让脚本自己“看”到按钮在哪、角色在哪，然后再去点击，效果完全不一样。这个项目就是基于这套思路做的一个梦幻西游场景下的自动化控制脚本，技术栈是Python + 计算机视觉 + pywin32 + PIL。

这个方案要解决的核心问题，就是定点点击的三个老大难：坐标写死在代码里，窗口一变就失效；没有反馈机制，点没点中全靠运气；动作固定到连鼠标轨迹都一模一样，很容易被判定为脚本。而视觉方案用PIL截取屏幕、OpenCV做模板匹配定位目标、pywin32负责模拟鼠标键盘，配合坐标换算，实现了“所见即所得”的动态点击。整个项目非常适合想深入理解Windows自动化控制、图像识别落地实践、Python桌面应用开发的读者，也适合那些被传统坐标脚本折磨过、想升级技术方案的自动化脚本爱好者。

1. 项目背景与技术思路拆解：定点点击为什么被淘汰

1.1 定点点击方案的三大痛点

先说说传统定点点击脚本的毛病。早期做挂机脚本，最简单粗暴的方案就是记录某个按钮的固定坐标，然后定时用鼠标模拟点击。比如游戏里“师门任务”按钮在(1150, 760)，脚本就每30分钟点一次这个坐标。这种逻辑没有任何图像处理，纯粹是拿操作系统层面的坐标在做机械操作。

第一个问题是窗口尺寸变了就全部错位。现在Windows系统都开了DPI缩放，同一台电脑，缩放比例从100%调到150%，窗口实际渲染尺寸全部变了，原来记录的坐标统统作废。更不用说换一台分辨率不同的电脑，或者玩家把游戏窗口从1920x1080拖到1600x900，脚本直接失效。

第二个问题是游戏更新后UI布局一旦调整，坐标跟着全乱。游戏厂商随手改一个按钮位置，所有写死坐标的脚本就变成“盲人摸象”，点哪里都不是。你前期花大量时间录制的坐标点位，一个版本更新就全部归零。

第三个问题更隐蔽，就是没有反馈验证。定点点击脚本只是“点了”，但不关心“点没点中”。万一网络卡顿、弹窗遮挡、目标不在预期位置，脚本照样按照原计划往下走，结果就是一整条自动化链路全部跑偏，挂了一天机啥也没干成。我见过最夸张的例子，脚本把背包按钮点成了宠物按钮，而代码里还浑然不知，继续执行后续逻辑。

1.2 计算机视觉方案是怎么解决这些问题的

计算机视觉方案的核心思路，是让脚本具备“感知能力”。它不再依赖固定的像素坐标，而是通过屏幕截图、图像识别，在每一帧画面里实时查找“要找的目标长什么样”，找到了再根据目标当前的位置动态生成点击坐标。

举个很直观的例子。定点点击脚本找“商会的回购按钮”，它记住的是“(980, 540)这个位置要点击”；而计算机视觉方案记住的是“回购按钮的图标长什么样”，然后每一帧截屏后遍历全屏找这个图标，找到了就计算它的中心坐标去点击。不管窗口怎么拖、分辨率怎么改、按钮放哪里，只要图标还是那个图标，脚本就能找到它。

这套方案的第二个好处，是能给操作加一层“确认机制”。识别模块找不到目标时，脚本可以选择原地等待、重新截图、或者报告错误，而不是傻乎乎地按照死坐标乱点。比如识别“确认”按钮的置信度低于0.8时，脚本自动重试三次，这个逻辑用坐标方案根本做不到，因为你永远不知道当前画面里到底有没有这个按钮。

第三个好处是人机交互更自然。视觉方案可以根据目标的实时位置动态调整鼠标移动路径，配合随机延迟和轨迹扰动，动作不再像机器人那样每次都是同一条直线、同一个速度。这一点对反检测和真实感提升非常有帮助，自动化程度越高的脚本，越需要这种动态生成的操作模式。

2. 技术选型与整体架构：为什么是pywin32 + PIL + 计算机视觉三件套

2.1 三个核心库各自负责什么

这个项目最核心的三个依赖，各司其职。PIL（Pillow）负责屏幕图像采集，它提供了一个极其简单粗暴的接口 ImageGrab.grab() ，一行代码就能把整个屏幕或者指定区域截成一张图。比Windows底层的GDI抓屏、DXGI抓屏要友好太多，对于入门级别的桌面自动化项目，它是性价比最高的选择。

pywin32负责Windows系统和应用层的交互，它是Python调用Win32 API的桥梁。脚本里用到的 win32api.SetCursorPos 移动鼠标、 win32api.mouse_event 模拟点击、 win32gui.FindWindow 定位游戏窗口，都是通过它实现的。有些情况下还会用到 win32con 里的各种消息常量，比如 WM_LBUTTONDOWN 、 WM_LBUTTONUP ，这些是后台发消息控制的关键。

计算机视觉部分用的库是OpenCV（cv2），它是整个方案的眼睛。屏幕截完图之后，OpenCV负责在图像里做模板匹配、颜色过滤、特征定位。 cv2.matchTemplate 是最常用的方法，它在屏幕截图中滑动匹配预设的目标小图，返回一个匹配度矩阵，然后取最高分的位置作为目标坐标。

这三个库分工明确：PIL负责“看屏幕”，OpenCV负责“认目标”，pywin32负责“动手操作”。截屏、识别、操作这三步完成一个闭环，循环执行就是一套完整的视觉自动化脚本。

2.2 为什么不直接用现成“找图”框架

你可能会问，现在很多现成的自动化工具也号称支持“找图找色”，比如按键精灵、大漠插件，为什么还要自己用Python写一套？因为现成框架的“找图”本质上还是封装好的模板匹配，灵活性非常有限，只能做简单的“找到了就点”逻辑，而且对多目标、动态目标、复杂场景的支持很差。自己用OpenCV写的识别逻辑，可以对模板做多尺度缩放、做颜色空间转换、做边缘检测、加形态学操作，甚至接一个深度学习目标检测模型。这些能力是那些黑盒框架给不了的。

另一个考虑是跨平台和可调试性。按键精灵的脚本语言、大漠插件的DLL调用链，出问题的时候定位难度很大。而Python生态里，PIL截图的结果可以直接保存成图片看，OpenCV处理的时间可以用 cv2.imshow 可视化显示匹配结果，整个流程每一步都能拆开独立测试，开发效率高一个量级。

再者，自己写这套方案的过程本身就是一个很好的学习路径。你会从截屏开始，逐步理解图像坐标系和屏幕坐标系怎么换算，模板匹配的置信度阈值怎么调，多目标检测怎么去重，这些底层原理一旦掌握了，往后做任何Windows自动化项目都能信手拈来。用现成工具永远学不到这一层。

2.3 脚本整体流程与模块划分

整个脚本的运行逻辑并不复杂，核心就是一个循环：

用PIL截取当前游戏窗口区域的画面，转成OpenCV能处理的numpy数组；
在截图中做目标模板匹配，找到关键按钮或目标点的坐标；
把图像坐标转换成屏幕坐标（考虑到窗口位置和缩放系数）；
用pywin32移动鼠标、模拟点击或键盘操作；
随机延迟一段时间，再进入下一轮循环。

实际写代码的时候，我会把每一步拆成独立函数。 capture_screen() 专门负责截屏， find_target() 专门负责识别目标， move_and_click() 专门负责鼠标操作， run_task() 负责调度整个流程。各模块独立的好处是便于调试，截图不对就查 capture_screen ，识别不到东西就查 find_target ，操作没反应就查 move_and_click ，不用在几百行的无限循环里大海捞针。

模块化还有一个好处，就是可以单独给每个模块写测试。比如我在开发时经常先跑一遍 capture_screen ，把截图保存到本地看一眼，确认窗口区域对不对；然后单独跑 find_target ，把匹配结果用矩形框画出来保存，确认识别坐标准不准。全部确认无误，才把它们串起来跑完整流程，这样定位问题的成本非常低。

3. 核心模块实现与实操要点

3.1 屏幕捕获：从PIL.ImageGrab到后台窗口截图

屏幕捕获是整个流程的第一步，也是很多新手容易翻车的地方。最简单的实现是直接全屏截图，代码长这样：

from PIL import ImageGrab

# 全屏截图
screen = ImageGrab.grab()
screen.save("screen.png")

但全屏截图有两个隐患。第一是截图的像素量很大，1920x1080的截图，每一帧处理时间明显拉长；第二是外部干扰，如果桌面上有其他窗口盖住了游戏窗口，截图里就会出现杂七杂八的东西，影响识别精度。所以我更推荐先定位游戏窗口，只截取窗口所在的矩形区域。

import win32gui
from PIL import ImageGrab

hwnd = win32gui.FindWindow(None, "梦幻西游")
left, top, right, bottom = win32gui.GetWindowRect(hwnd)
width = right - left
height = bottom - top

# 只截游戏窗口区域
screen = ImageGrab.grab(bbox=(left, top, right, bottom))

这里有一个非常容易踩的坑： win32gui.GetWindowRect 返回的窗口矩形包含标题栏和窗口边框，如果你的目标按钮位于窗口客户区内部，而模板图是从客户区截取的，那么匹配到的坐标就会整体偏移一块标题栏的高度。解决方法是先用 win32gui.GetClientRect 获取客户区大小，再用 win32gui.ClientToScreen 把客户区原点换算成屏幕坐标，从而得到客户区在屏幕上的真实矩形。

注意：窗口阴影特效在某些系统上也会影响 GetWindowRect 的结果，多出来的几像素偏移虽然看起来不大，但配合高DPI缩放后误差会被放大，轻则点击偏移，重则点错按钮。

还有一个实用技巧，截屏之前先调用一次 SetProcessDPIAware() ，否则PIL截出来的图会被Windows虚拟化缩放，坐标换算会全乱。Windows对高DPI的进程默认做缩放模拟，你以为截的是1920x1080的屏幕，实际图像尺寸可能是150%比例放大后的结果。

import ctypes
ctypes.windll.shcore.SetProcessDPIAware()

如果追求更高的执行效率，可以用 ImageGrab.grab(all_screens=True) 配合多显示器场景，但性能会下降，一般单游戏窗口场景不需要。还有个替代方案是 mss 库，它的截图速度比PIL快不少，适合对帧率要求高的场景。不过PIL的兼容性最好，作为入门首选完全够用。

3.2 图像定位：模板匹配的置信度与多目标处理

拿到截图之后，图像定位模块就要登场了。最常用的模板匹配方法，是把目标图（比如一个按钮的图标）和截图同时转成灰度图，然后交给OpenCV的 matchTemplate 处理：

import cv2
import numpy as np

# 把PIL图像转成OpenCV的numpy数组
screen_bgr = cv2.cvtColor(np.array(screen), cv2.COLOR_RGB2BGR)
screen_gray = cv2.cvtColor(screen_bgr, cv2.COLOR_BGR2GRAY)

template_gray = cv2.imread("template.png", cv2.IMREAD_GRAYSCALE)

# 模板匹配，method用归一化相关系数
result = cv2.matchTemplate(screen_gray, template_gray, cv2.TM_CCOEFF_NORMED)
min_val, max_val, min_loc, max_loc = cv2.minMaxLoc(result)

matchTemplate 的原理是滑动窗口，把模板图从左到右、从上到下在截图里滑动，每到一个位置算一次相关系数。 TM_CCOEFF_NORMED 方法的输出范围是-1到1，1表示完全一致。实践中阈值一般设置在0.75到0.9之间，低于0.75的基本都是误匹配。

max_loc 只是匹配度最高点的左上角坐标，还需要加上模板的宽高，才能得到目标的中心坐标：

h, w = template_gray.shape
center_x = max_loc[0] + w // 2
center_y = max_loc[1] + h // 2

这个思路简单有效，但有几个进阶问题必须处理。

第一个是模板大小和截图中目标大小不一致的问题。游戏窗口重新缩放后，同一个按钮在屏幕上的像素尺寸会发生变化，固定模板必然匹配失败。解决办法有两种：要么对模板做多尺度扫描，要么在截图中先做scale空间搜索。多尺度扫描的实现比较简单，就是生成一系列不同缩放的模板图，逐一跑 matchTemplate ，取所有结果中匹配度最高的那组坐标。

第三个是多个相同目标的问题。比如画面里有多个相同的怪物、多个相同的按钮图标，直接用 minMaxLoc 只能取到匹配度最高的那一个。如果脚本需要逐个点击，就需要用阈值筛选出所有匹配点：

locations = np.where(result >= 0.8)
points = list(zip(*locations[::-1]))

拿到所有匹配点之后还要做非极大值抑制（NMS），否则同一个目标周围会产生一大圈重复的点。NMS的逻辑很简单：按匹配度从高到低排序，取最高点，然后删掉附近一定范围内的其他点，循环直到没有剩余点。这个思路和深度学习目标检测里的NMS是同一个道理。

实战中我还发现一个细节，模板图尽量截取带有边缘特征的区域，而不是一大片纯色背景。纯色区域的匹配结果是灾难性的，因为任何位置的相关性都差不多，很容易到处误报。如果模板是红底白字按钮，那就截一个包含按钮边框和文字的矩形，比只截按钮中心更可靠。

3.3 坐标转换与模拟点击：前台操作、后台消息与点击稳定性

图像识别得到的坐标是“窗口内图像坐标”，而pywin32的鼠标操作需要的是“屏幕坐标”。如果游戏窗口位于屏幕左上角且没有缩放，两者恰好相等，但实际场景几乎不会这么理想。正确的换算公式是：

screen_x = window_client_left + (img_x * scale_x)
screen_y = window_client_top + (img_y * scale_y)

这里的 scale_x 和 scale_y 是窗口实际渲染尺寸和截图尺寸的比值。比如截图像素是1280x720，窗口客户区实际是1600x900，那缩放系数就是1.25。算好缩放系数，点击操作才谈得上准确。

然后是模拟点击。最直接的方式是 SetCursorPos 移动光标，然后用 mouse_event 发送按下和弹起：

import win32api
import win32con

win32api.SetCursorPos((screen_x, screen_y))
win32api.mouse_event(win32con.MOUSEEVENTF_LEFTDOWN, 0, 0, 0, 0)
time.sleep(0.05)
win32api.mouse_event(win32con.MOUSEEVENTF_LEFTUP, 0, 0, 0, 0)

这个方案在大多数前台游戏场景都能工作，但有三个问题要注意。

第一个问题是鼠标移动轨迹太突兀。 SetCursorPos 是瞬移，玩家肉眼可见鼠标从A点瞬间跳到B点，这种操作特征非常明显。改进方案是写一个平滑移动函数，把鼠标路径拆成十几个小段，每段用 time.sleep 加一点随机延迟：

def smooth_move(x, y, steps=15):
    start_x, start_y = win32api.GetCursorPos()
    for i in range(1, steps + 1):
        mid_x = int(start_x + (x - start_x) * (i / steps))
        mid_y = int(start_y + (y - start_y) * (i / steps))
        win32api.SetCursorPos((mid_x, mid_y))
        time.sleep(random.uniform(0.002, 0.01))

第二个问题是游戏窗口处于后台或最小化状态时，前台点击无效。很多游戏挂机场景希望脚本在后台运行，这时候就要用 PostMessage 向窗口发送鼠标消息，也就是所谓的后台点击：

import win32gui

lparam = (screen_y << 16) | screen_x
win32gui.PostMessage(hwnd, win32con.WM_LBUTTONDOWN, win32con.MK_LBUTTON, lparam)
time.sleep(0.02)
win32gui.PostMessage(hwnd, win32con.WM_LBUTTONUP, 0, lparam)

后台点击的原理，是直接把鼠标消息投递到游戏窗口的消息队列，绕过鼠标光标的物理移动。但能不能成功，取决于游戏窗口的消息处理逻辑。像梦幻西游这样的客户端游戏，后台消息通常能正常触发点击；但有些3D游戏使用DirectInput直接读取鼠标硬件状态，后台消息就无效，只能用驱动级模拟或者前台置顶点击。

第三个问题是点击被系统的“鼠标加速”干扰。Windows默认开启鼠标加速度，物理移动和光标位移不是线性关系。不过 SetCursorPos 是绝对定位，不受鼠标加速影响，所以视觉方案反而比物理模拟鼠标移动更精准。

3.4 增加识别稳定性的几个细节设计

识别稳定性是整个脚本体验的分水岭。匹配度阈值调低了误报多，调高了漏报多，怎么平衡？我的做法是分开处理。

目标按钮类操作，阈值设高一点（0.85以上），因为按钮识别错误会导致点击错误操作，损失很大，宁可漏报重试也不要误报。状态检测类操作，比如判断当前界面是不是背包界面、判断角色血量条位置，阈值可以低至0.7，漏检了无非是再检测一次，影响不大。

匹配方式上，彩色匹配比灰度匹配信息量更大，但计算量也大。我的经验是：模板和截图对比时，优先用灰度匹配，因为速度快；如果灰度匹配的区分度不够（比如两个按钮颜色不同但形状相似），可以单独提取颜色通道做匹配。更高级一点的做法，是用HSV色彩空间做颜色过滤，找到特定颜色的区域，再在这片区域里做形状判断。

还有一个容易被忽略的细节：截图质量和模板质量是识别准确率的根基。模板图必须从真实运行环境中截取，不能从网上找宣传图裁剪，因为宣传图经过抗锯齿、滤镜处理，颜色分布和实际游戏画面差别很大。另外，模板图不要带阴影、不要带高光，尽量保证内容是扁平化的图标或者文字区域。

性能方面，一帧全屏1920x1080的模板匹配耗时大约在50到200毫秒，取决于模板大小和机器性能。如果脚本需要高频检测，比如每0.5秒检测一次，建议把截图区域缩小到目标可能出现的范围，而不是每次全屏搜索。还有一种做法是降低截图分辨率，匹配完成后再把坐标放大回原始尺寸，精度会略微下降，但速度能快好几倍。

4. 常见问题与排查技巧实录

4.1 识别不到目标：先看截图，再看阈值

识别不到目标是最常见的问题，也是最容易排查的。我遇到这种情况，第一反应永远是保存当前截图，人工检查截图里目标到底在哪、长什么样。

如果截图里根本没有目标，那就是触发时机不对，脚本执行到这段逻辑时游戏界面还没切换过来。解决方法是加等待逻辑，等界面元素出现再往下走。

如果截图里有目标，但匹配度很低，那就是模板和目标差异太大。此时把模板图和截图里目标的实际外观对比一下，看是不是尺寸不对、颜色偏了、UI样式变了。我建议直接写一个调试脚本，把匹配到的区域用矩形框画出来，保存成图片慢慢看。

detected = screen_bgr.copy()
cv2.rectangle(detected, max_loc, (max_loc[0] + w, max_loc[1] + h), (0, 255, 0), 2)
cv2.imwrite("detected.png", detected)

4.2 点击偏位：DPI缩放与窗口边框的计算误差

点击偏位是最隐蔽的问题。图像识别返回的坐标明明是对准了按钮中心，但点击下去就是没反应，或者点了旁边的位置。原因通常有三个。

第一是DPI缩放。Windows的缩放比例不是100%时， GetWindowRect 返回的可能是物理坐标，而PIL截图返回的是缩放后的虚拟坐标，两者不匹配。最直接的解决办法，是进程开头调用 SetProcessDPIAware() ，让整个进程基于真实物理像素工作，不再做缩放。

第二是窗口边框和阴影。 GetWindowRect 返回的窗口矩形，包含了非客户区，甚至包含系统阴影。如果从客户区截图，却用窗口矩形作为坐标偏移基准，就会差出一段距离。解决方法是改用 GetClientRect 加 ClientToScreen ，拿到客户区在屏幕上的精确位置。

第三是模板匹配返回的 max_loc 是模板左上角在截图里的坐标，如果计算中心点时忘记加上模板尺寸的一半，点击位置会偏到左上角。这种低级错误，肉眼直接看 detected.png 就能发现矩形框没有对准目标。

4.3 Python环境与依赖库的兼容性问题

这个项目用到的库，版本兼容性有时候会把人坑到怀疑人生。

pywin32 安装出问题的概率很高，尤其是Python 3.8以上的版本，某些旧版pywin32没有预编译的wheel包，装起来直接报错。我的建议是直接用 pip install pywin32 装最新版，装完确认 win32api 能正常import。还有一个细节， win32api.SetCursorPos 在部分Windows版本上需要管理员权限才能生效，如果脚本移动到一半光标不动，检查一下是不是以管理员身份运行的终端。

OpenCV的安装相对简单， pip install opencv-python 即可。但注意不要同时安装 opencv-python 和 opencv-contrib-python ，两个包会互相冲突。Pillow和OpenCV的numpy数组转换也常有人出问题，安装时要确保numpy版本和opencv的编译版本匹配，否则会报类似 numpy.dtype size changed 的运行时错误。

PIL的 ImageGrab 在不同系统上的行为也有差异。Windows上直接支持，macOS上需要额外权限，Linux上依赖 XCB 。我们做Windows游戏自动化，基本不用考虑这个，但如果你打算把代码移植到其他平台，就要提前做模块替换。

4.4 脚本长时间运行后识别率下降

这是个大坑。脚本挂机跑了几个小时之后，突然开始频繁识别失败，或者点击后没反应。排查下来最常见的原因有两个。

第一个是游戏内场景切换导致光照变化。比如从白天场景切换到夜晚场景、从室内到室外、或者游戏里下起了雨，整体色调一变，固定模板的匹配度就断崖式下跌。针对这个，我建议准备多套亮度对比度下的模板，或者对截图做一次直方图均衡化预处理，降低光照对匹配的影响。

第二个是窗口被部分遮挡或者弹窗干扰。游戏突然弹出一个活动公告，挡住了目标区域，识别自然失败。脚本如果遇到识别不到目标就一直卡在那里，时间久了就是“假死”。比较好的设计是加入超时机制，连续N次识别失败后执行一次“恢复操作”，比如关闭弹窗、切回原界面、重新打开目标窗口，再继续尝试。

第三个原因是内存泄漏。PIL和OpenCV在长时间循环里，如果 numpy 数组传递过程中有引用未释放，Python的垃圾回收虽然会兜底，但OpenCV在Windows上的部分接口会持有底层内存。挂机几小时后内存占用飙升，导致系统开始使用虚拟内存，整个脚本运行变卡，识别耗时大幅拉长。建议每跑一段时间做一次内存占用检查，如果异常升高，就从源头排查循环里是否有大数组在反复创建却未释放。

5. 心得体会与其他应用场景的思考

这套视觉自动化方案的威力，其实远不止游戏脚本一个场景。它本质上是一套通用的“屏幕交互自动化”能力，任何“看屏幕、找目标、做操作”的需求都能套这个架构。比如RPA办公自动化：识别Excel表格里的按钮、根据图片内容自动填写表单、在旧系统中自动抓取数据；再比如桌面软件自动化测试：根据UI元素截图自动点击验证功能；甚至可以做辅助工具：识别屏幕上的验证码图片、自动截取关键信息等等。

我个人的体会是，做这类项目最值钱的不是那几行点击或匹配的代码，而是“定位问题”的思路。脚本跑起来遇到问题时，先确认是哪一层出的问题，是截图截错了、识别识别错了、还是点击点错了。把问题定位到具体模块之后，解决就是分分钟的事。很多新手卡了很久，就是因为他们把这三个步骤混在一起调试，截图看一眼、代码改两行、又跑一遍，效率极低。

最后再分享一个我一直在用的习惯：把所有阈值参数、模板路径、点击延迟，全部抽离到配置文件里，不要散落在代码各个角落。因为调参在自动化项目里是家常便饭，今天匹配度阈值要调，明天延迟时间要改，如果参数都在配置里，改完一重启就生效，不用动代码逻辑，也不用担心改坏什么。这个习惯帮我节省了无数个小时，强烈推荐给所有写自动化脚本的人。

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