1. 从手动刷本到脚本托管FGO-py 到底解决了什么问题玩《命运/冠位指定》的朋友大概都有过这样的体验活动期间为了搬空商店同一个副本要重复刷上百次每次操作都是点技能、选卡、等结算、再点下一把。一管体力刷完手指酸了眼睛也花了关键是这个过程毫无乐趣可言纯粹是机械劳动。FGO-py 就是冲着这个痛点来的——它是一个用 Python 写的自动化脚本能够接管游戏中的重复性操作让你把刷本这件事交给程序去跑。我第一次接触这类工具的时候心里其实是有顾虑的。市面上不少所谓的游戏辅助要么需要修改游戏文件要么需要注入进程风险高不说还容易把账号搭进去。FGO-py 的思路不太一样它走的是图像识别 模拟点击的路线本质上就是看屏幕、动鼠标跟你自己坐在电脑前操作没有本质区别。它通过截取游戏窗口的画面用 OpenCV 做模板匹配和图像处理判断当前处于哪个界面然后决定下一步该点哪里。整个过程不碰游戏内存不改游戏数据从技术路线上就规避了很多风险。这个项目适合什么人用我觉得有三类人特别合适。第一类是活动期间想省时间的上班族每天体力有限手动刷太累交给脚本挂着就行。第二类是想学 Python 自动化但找不到练手项目的人FGO-py 的代码结构清晰涉及图像识别、窗口操作、配置管理等多个知识点拿来当学习材料非常合适。第三类是对自动化测试感兴趣的技术爱好者它用到的很多思路跟 UI 自动化测试是相通的比如元素定位、状态判断、异常重试这些。需要提前说明的是这类工具的使用需要你自己权衡。游戏官方对自动化的态度各时期可能不同使用前建议了解清楚相关规则。我写这篇东西的目的是分享技术实现和实操经验不是鼓励大家去违反任何规定。技术本身是中性的怎么用取决于你自己。从技术栈来看FGO-py 主要依赖这么几块Python作为主语言OpenCV负责图像处理pywin32或类似库负责窗口操作和鼠标模拟NumPy处理数组运算配置文件用JSON或YAML管理。如果你打算用 Docker 来跑还需要了解容器化的基本操作。下面我会把这些东西拆开来讲从环境搭建到核心原理再到实际使用中的各种坑尽量让你看完就能上手。2. 环境搭建Python、OpenCV 和那些让人抓狂的依赖问题2.1 Python 版本选择与虚拟环境隔离装 Python 这件事听起来简单但实际踩坑的人非常多。FGO-py 对 Python 版本有一定要求太老的版本比如 3.6 以下可能不支持某些语法特性太新的版本比如刚发布的 3.13又可能遇到第三方库还没适配的问题。我实测下来Python 3.9 到 3.11这个区间是最稳的兼容性最好各种依赖库都有预编译的 wheel 包不需要自己折腾编译。安装的时候有个细节要注意Windows 上装 Python 一定要勾选Add Python to PATH否则后面在命令行里敲python会提示找不到命令。如果你已经装完了才发现没勾也不用重装手动把 Python 安装目录和 Scripts 目录加到系统环境变量里就行。虚拟环境这块我强烈建议用上。很多人图省事直接全局装依赖结果不同项目之间版本冲突搞得一团糟。用venv创建独立环境每个项目一套依赖互不干扰python -m venv fgo-env fgo-env\Scripts\activate激活之后命令行前面会出现(fgo-env)的标识说明你已经在虚拟环境里了。后面所有 pip 安装操作都在这个环境下进行不会污染全局。2.2 OpenCV 安装为什么你总是遇到 ModuleNotFoundErrorModuleNotFoundError: No module named opencv这个报错我见过太多次了。很多人以为是没装其实装了但装错了包名。OpenCV 在 pip 里的包名是opencv-python不是opencv也不是cv2。正确的安装命令是pip install opencv-python如果你需要额外的 contrib 模块一些高级图像处理算法可以装opencv-contrib-python。但 FGO-py 用到的功能基本都是基础模块装普通的就够了。安装过程中如果卡在下载或者编译大概率是网络问题或者缺少编译工具。Windows 上一般直接下载预编译的 wheel 就行不需要本地编译。如果 pip 下载慢可以换国内镜像源pip install opencv-python -i https://pypi.tuna.tsinghua.edu.cn/simple装完之后验证一下在 Python 里跑import cv2然后print(cv2.__version__)能打印出版本号就说明成功了。如果还是报错检查一下是不是在正确的虚拟环境里或者是不是有多个 Python 版本导致装到了别的地方。2.3 窗口操作依赖与屏幕分辨率适配FGO-py 需要跟游戏窗口交互这就涉及到窗口句柄获取、窗口位置计算、鼠标点击模拟这些操作。Windows 平台上通常用pywin32这个库安装命令是pip install pywin32。装完之后可能还需要跑一下python Scripts/pywin32_postinstall.py -install来注册一些组件具体路径根据你的 Python 安装位置调整。屏幕分辨率这块是个大坑。FGO-py 的图像识别是基于模板匹配的也就是说它预先截取了一些界面元素的图片作为模板然后在游戏画面上找这些模板。如果你的游戏窗口大小跟模板截取时的分辨率不一致匹配就会失败。所以游戏窗口的分辨率必须固定不能随便拉伸。一般建议用窗口模式运行游戏把窗口调整到脚本要求的分辨率然后不要再动它。我自己的做法是先把游戏窗口调好然后用工具比如 Windows 自带的截图工具或者 Python 的 mss 库截一张全屏图看看游戏区域在屏幕上的坐标范围把这个信息填到配置文件里。这样脚本就知道该去哪里截图、该在哪里点击了。2.4 Docker 方案值得折腾但门槛不低有人会问能不能用 Docker 跑 FGO-py。技术上可行但实际体验取决于你的使用场景。Docker 的优势是环境隔离、部署方便特别适合在服务器上长期挂机。但问题是Docker 容器里要访问宿主机的游戏窗口需要把显示设备或者 X11 转发配置好这在 Windows 上比较麻烦在 Linux 上相对容易。如果你打算用 Docker基本思路是基础镜像选一个带 Python 的 Linux 镜像把 FGO-py 的代码和依赖装进去然后通过挂载的方式让容器能访问到宿主机的显示服务。具体配置涉及DISPLAY环境变量、X11 socket 挂载这些网上有相关教程可以参考。不过说实话如果你只是在自己电脑上跑直接用本机 Python 环境更简单没必要为了 Docker 而 Docker。提示Docker Desktop 在 Windows 上安装时可能提示 Virtualization support not detected这是因为 BIOS 里的虚拟化功能没开。重启进 BIOS找到 Intel VT-x 或 AMD-V 选项设为 Enabled 就行。3. 图像识别是怎么看懂游戏界面的3.1 模板匹配找图定位的核心逻辑FGO-py 判断当前界面状态靠的是模板匹配。原理说起来不复杂你事先准备好一张小图比如攻击按钮的截图然后让 OpenCV 在大图当前游戏画面里滑动这个模板计算每个位置的相似度相似度最高的位置就是模板出现的位置。OpenCV 提供了cv2.matchTemplate函数来做这件事常用的匹配算法有TM_CCOEFF_NORMED、TM_CCORR_NORMED等。FGO-py 一般用归一化相关系数匹配因为它对亮度变化不那么敏感结果也更直观——返回值在 0 到 1 之间越接近 1 表示越相似。实际使用中你需要设定一个阈值比如 0.8只有相似度超过这个值才认为匹配成功。阈值设太高容易漏检设太低容易误检。我自己的经验是对于按钮类元素0.85 左右比较合适对于文字类元素因为字体渲染可能有细微差异可以适当降到 0.75 到 0.8。import cv2 import numpy as np def find_template(screen, template, threshold0.8): result cv2.matchTemplate(screen, template, cv2.TM_CCOEFF_NORMED) min_val, max_val, min_loc, max_loc cv2.minMaxLoc(result) if max_val threshold: h, w template.shape[:2] return (max_loc[0], max_loc[1], w, h) return None这段代码就是模板匹配的最小实现。max_loc是匹配位置左上角的坐标加上模板的宽高就能得到完整的矩形区域后续点击就点这个区域的中心。3.2 多尺度匹配与分辨率兼容前面说了分辨率要固定但有时候你换了电脑或者改了窗口大小模板就对不上了。这时候可以用多尺度匹配来救急把模板缩放到不同尺寸分别去匹配取最好的结果。代价是计算量成倍增加速度会慢下来。def multi_scale_match(screen, template, scales[0.8, 0.9, 1.0, 1.1, 1.2]): best_match None best_score 0 for scale in scales: resized cv2.resize(template, None, fxscale, fyscale) if resized.shape[0] screen.shape[0] or resized.shape[1] screen.shape[1]: continue result cv2.matchTemplate(screen, resized, cv2.TM_CCOEFF_NORMED) _, max_val, _, max_loc cv2.minMaxLoc(result) if max_val best_score: best_score max_val h, w resized.shape[:2] best_match (max_loc[0], max_loc[1], w, h) return best_match if best_score 0.8 else None这个方法在分辨率变化不大的时候管用但如果缩放比例超过 20%匹配精度会明显下降。所以最好的办法还是固定分辨率多尺度匹配只作为临时方案。3.3 颜色检测与状态判断除了找图FGO-py 还会用颜色检测来判断一些状态。比如判断某个技能是否可用可以通过检测技能图标周围的颜色——可用时是亮色冷却时是灰色。OpenCV 可以把图像从 BGR 转到 HSV 色彩空间然后在特定色相范围内做掩膜统计像素数量来判断颜色占比。def check_color_ratio(image, lower_hsv, upper_hsv): hsv cv2.cvtColor(image, cv2.COLOR_BGR2HSV) mask cv2.inRange(hsv, lower_hsv, upper_hsv) ratio np.count_nonzero(mask) / mask.size return ratio这个方法比模板匹配更轻量适合做快速的状态预判。比如先判断当前是不是在战斗界面如果是再去匹配具体的按钮能省不少计算。3.4 图像预处理让识别更稳的几个技巧原始截图直接拿去做匹配效果往往不够好。FGO-py 在匹配之前会做一些预处理常见的有灰度化、二值化、边缘检测、降噪这些。灰度化就是把彩色图转成灰度图减少计算量同时消除颜色波动的影响。二值化是把灰度图转成黑白图突出轮廓。边缘检测比如 Canny可以提取图像中的线条信息对于形状明显的元素效果很好。降噪比如高斯模糊可以消除截图中的随机噪点提高匹配稳定性。def preprocess(image): gray cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) blurred cv2.GaussianBlur(gray, (3, 3), 0) edges cv2.Canny(blurred, 50, 150) return edges预处理的选择要看具体场景。对于按钮类元素灰度 高斯模糊通常就够了对于文字类元素可能还需要做二值化来增强对比度。我建议你先用原始图跑一遍看看哪些地方识别不稳再针对性地加预处理。4. 脚本主循环从截图到点击的完整链路4.1 主循环的基本结构FGO-py 的核心是一个不断循环的状态机。每一轮循环做这么几件事截取当前游戏画面、识别当前处于哪个界面、根据界面状态决定下一步操作、执行操作点击或滑动、等待一段时间让游戏响应、进入下一轮。这个循环的频率不能太高也不能太低。太快了游戏还没响应完就去截下一张图容易误判太慢了效率低下刷一把要等半天。我实测下来每轮循环间隔 0.5 到 1 秒比较合适具体看你的电脑性能和游戏加载速度。import time def main_loop(): while True: screen capture_screen() state recognize_state(screen) if state battle: handle_battle(screen) elif state result: handle_result(screen) elif state menu: handle_menu(screen) else: handle_unknown(screen) time.sleep(0.8)这个结构看起来简单但实际写起来要考虑的东西很多。比如状态识别错了怎么办点击没生效怎么办游戏卡住了怎么办这些异常情况都需要处理。4.2 状态识别与优先级设计游戏界面有时候会有重叠比如弹窗盖在战斗界面上或者加载动画还没结束。这时候如果只按单一条件判断很容易误判。FGO-py 的做法是给每个状态识别设一个优先级先检查高优先级的特征匹配上了就按那个状态处理不再往下查。比如弹窗的优先级最高因为弹窗不处理掉后面的操作都会被挡住。其次是加载动画检测到加载中就等待不做任何操作。然后是战斗界面、结算界面、菜单界面这些。def recognize_state(screen): if find_template(screen, templates[popup_close]): return popup if find_template(screen, templates[loading]): return loading if find_template(screen, templates[attack_button]): return battle if find_template(screen, templates[result_ok]): return result return unknown优先级的设计要根据实际游戏流程来定。我建议你把常见的界面都截一遍然后按出现频率和阻塞程度排序阻塞性强的放前面。4.3 点击操作与随机化处理点击看起来简单调个 API 就行但实际有不少讲究。首先是点击位置不能总是点正中心因为有些按钮的边缘区域可能不响应。一般点中心偏下一点比较稳。其次是点击速度太快了游戏可能来不及响应太慢了效率低。还有就是随机化——如果每次点击的坐标和时间间隔都完全一样行为特征太规律不太自然。import random import pyautogui def click_at(x, y): offset_x random.randint(-3, 3) offset_y random.randint(-3, 3) pyautogui.click(x offset_x, y offset_y) time.sleep(random.uniform(0.1, 0.3))这个随机偏移的范围不要太大3 到 5 个像素就够了太大了可能点到按钮外面去。时间间隔的随机范围也要控制好既要保证游戏能响应又不能拖慢整体节奏。4.4 异常处理与自动恢复脚本跑久了总会遇到各种意外网络波动导致加载失败、游戏弹了个没见过的公告、鼠标被别的窗口抢走了、电脑休眠了等等。这些情况如果不管脚本就会卡在那里一动不动。FGO-py 的异常处理策略是检测到未知状态时先尝试一些通用的恢复操作比如点屏幕中央、按 ESC 键、点返回按钮。如果连续多次都无法恢复就记录日志并暂停等人工介入。def handle_unknown(screen): global unknown_count unknown_count 1 if unknown_count 10: log(连续未知状态过多暂停脚本) pause() return pyautogui.click(screen_center) time.sleep(1)这个unknown_count在识别到已知状态时要重置否则正常流程中偶尔几次未知也会累积到阈值。5. 配置管理与多账号适配的实操细节5.1 配置文件的结构设计FGO-py 的行为很大程度上由配置文件决定。配置文件里通常包含这些内容游戏窗口的位置和大小、各种模板图片的路径和匹配阈值、点击的坐标和延迟参数、要刷的副本编号和次数、体力恢复道具的使用策略等等。用 JSON 还是 YAML 看个人喜好。JSON 的好处是 Python 原生支持不需要额外装库YAML 的好处是可读性更好支持注释。我一般用 JSON因为解析速度快而且不容易出现缩进错误。{ window: { left: 0, top: 0, width: 1280, height: 720 }, thresholds: { button: 0.85, text: 0.75 }, battle: { max_turns: 3, skill_delay: 0.5, card_delay: 0.3 } }配置文件的结构要清晰不同功能的参数分开放方便查找和修改。我建议给每个参数加个注释说明JSON 不支持注释的话可以单独写个说明文档不然过段时间自己都忘了某个参数是干嘛的。5.2 多账号切换的实现思路如果你有多个账号要刷手动切换太麻烦。FGO-py 可以通过配置文件区分不同账号的参数比如不同的窗口位置、不同的队伍配置、不同的刷本策略。切换账号的时候改一下配置文件的路径或者内容就行。更高级的做法是写一个调度脚本按顺序启动多个 FGO-py 实例每个实例用不同的配置。但要注意多个实例同时跑可能会互相抢鼠标焦点导致点击错位。解决办法是让每个实例操作不同的窗口区域或者串行执行——一个跑完再跑下一个。import subprocess accounts [account1.json, account2.json, account3.json] for config in accounts: subprocess.run([python, fgo.py, --config, config]) time.sleep(5)串行执行的好处是稳定坏处是总时间长。如果你电脑性能好可以试试并行但一定要做好窗口隔离。5.3 参数调优延迟、阈值和重试次数这三个参数是影响脚本稳定性和效率的关键。延迟太短游戏响应不过来操作丢失延迟太长刷本速度慢。阈值太高识别不到元素阈值太低误识别。重试次数太少遇到偶发问题就卡住重试次数太多真出问题了还在那死循环。我的调优方法是先用保守参数跑一遍观察日志里哪些地方报错多然后针对性地调整。比如某个按钮经常识别不到就把它的阈值降一点某个操作后游戏加载慢就把那一步的延迟加长。参数保守值激进值建议循环间隔1.0s0.3s0.5-0.8s按钮阈值0.90.70.8-0.85文字阈值0.850.650.75-0.8重试次数1035-8这张表是我自己总结的经验值你可以根据实际情况微调。关键是每次只改一个参数改完跑一段时间看效果不要一次改一堆不然出了问题都不知道是哪个参数导致的。5.4 日志记录与问题回溯日志是排查问题的命根子。FGO-py 应该记录每一轮循环的状态识别结果、执行的操作、耗时、异常信息。日志级别分 DEBUG、INFO、WARNING、ERROR平时跑用 INFO 就行出问题了临时开到 DEBUG 看细节。日志文件要定期清理不然跑几天就几百兆了。可以按天分割只保留最近一周的。日志里最好带上时间戳和截图文件名这样出问题的时候可以直接看当时的画面比对着文字猜快多了。import logging from datetime import datetime logging.basicConfig( filenameffgo_{datetime.now().strftime(%Y%m%d)}.log, levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s )截图存档也很重要。我一般让脚本在识别失败的时候自动截一张图存下来文件名带上时间戳和状态。这样回头分析的时候能直观看到当时是什么界面、为什么识别错了。6. 那些文档里不会写的踩坑经验6.1 游戏更新导致模板失效游戏每次更新界面多多少少会有些变化。可能是按钮位置挪了几个像素可能是颜色调整了也可能是加了新的动画效果。这些变化对人是无感的但对模板匹配来说是致命的——原来能匹配上的模板更新后可能就匹配不上了。应对方法是每次游戏大版本更新后重新截取一遍模板图片。如果只是小更新可以先跑一下看看有没有报错报错了再针对性更新。我习惯在游戏更新后先手动跑几把确认脚本正常再挂机不然挂一晚上发现啥也没刷就亏大了。6.2 鼠标焦点被抢与窗口置顶Windows 上有个烦人的问题如果有别的窗口弹出来抢了焦点你的鼠标点击就会点到那个窗口上去。脚本不知道这件事还以为自己点的是游戏结果操作全部落空。解决办法有几个一是把游戏窗口设为置顶用pywin32的SetWindowPos函数可以做到二是脚本每次点击前先激活游戏窗口确保焦点在游戏上三是跑脚本的时候别开其他会弹窗的软件比如聊天工具、邮件客户端。import win32gui import win32con def bring_to_front(hwnd): win32gui.SetWindowPos(hwnd, win32con.HWND_TOPMOST, 0, 0, 0, 0, win32con.SWP_NOMOVE | win32con.SWP_NOSIZE)置顶之后游戏窗口会一直显示在最前面别的窗口盖不住它。缺点是你要干别的事的时候会被游戏挡住所以最好用双屏或者把游戏放到副屏上。6.3 体力耗尽与道具使用的判断逻辑刷本是要消耗体力的体力没了就得用道具恢复或者等自然恢复。脚本需要判断当前体力够不够不够的话是用道具还是停下来等。判断体力值可以通过识别界面上的数字但数字识别比较麻烦容易出错。更简单的办法是看开始战斗按钮是不是亮的——体力够的时候按钮是彩色的不够的时候是灰色的。用颜色检测就能判断。道具使用策略要在配置文件里写清楚优先用哪种道具、用多少个、用完了怎么办。我一般设置成优先用快要过期的道具然后是用存量多的最后才用稀有的。这个逻辑用简单的 if-else 就能实现关键是把优先级排好。6.4 长时间运行的稳定性问题脚本连续跑几个小时甚至几天可能会遇到内存泄漏、句柄耗尽、截图失败这些问题。Python 的垃圾回收机制大部分时候能处理好但如果你在循环里不断创建大对象比如全屏截图内存还是会涨。我的做法是截图用mss库而不是pyautogui因为mss更快而且内存管理更好每跑几百轮就主动gc.collect()一次定期重启脚本比如每 4 小时重启一次。这些措施能显著提高长时间运行的稳定性。还有一个容易忽略的问题是电脑休眠。如果电源设置里设了 30 分钟无操作就休眠脚本跑着跑着电脑睡了那就全白费了。记得把电源计划改成从不休眠屏幕可以关但系统不能睡。6.5 关于风险控制的个人建议最后说几句掏心窝子的话。这类工具用起来确实省事但风险是客观存在的。我的建议是不要在主账号上跑用小号先试试水不要 24 小时不间断地跑设置合理的休息时间模拟正常人的游戏节奏不要同时跑太多账号行为特征太明显关注游戏官方的公告和社区动态有风吹草动及时停手。技术本身没有对错关键在于怎么用。我分享这些是因为我自己对自动化技术感兴趣在这个过程中学到了很多图像处理和程序设计的知识。如果你也是抱着学习的心态来折腾那这些经验应该对你有帮助。如果你只是想省事那也要做好承担相应后果的准备。我在实际使用中最大的体会是稳定性比效率重要得多。一个跑得慢但稳定的脚本比一个跑得快但经常卡死的脚本有价值得多。宁可每把多等两秒也不要因为抢那一秒导致操作丢失、状态错乱。调参的时候也是这个原则先保证稳定再逐步优化速度。踩过几次坑之后你就会明白挂机刷本最怕的不是慢而是你早上起来发现脚本半夜就卡住了体力满了一整晚都没用出去。