⚠️ 重要声明
本文所有内容仅供技术学习与自动化原理研究，探讨图像识别、任务调度、模拟输入等计算机技术。严禁将文中提及的任何工具或代码用于违反游戏用户协议、破坏游戏公平性或干扰正常服务的行为。使用第三方工具所导致的账号封禁、法律纠纷等后果，均由使用者本人承担。请务必尊重游戏开发者的劳动与规则。

相信很多玩家都曾想过：能不能利用程序自动完成游戏里一些高度重复的操作，把精力留给真正有趣的体验？这也是技术领域一个有趣的课题——如何通过计算机视觉与模拟交互，实现对游戏任务的理解与自动执行。

抱着学习和验证技术可行性的心态，我开始了这个系列。希望能通过拆解几个开源项目，搞清楚自动化脚本的工作原理和框架设计。这个过程中我会借助 AI 编程工具来帮助阅读代码、搭建环境。

AI代码助手

最快速接入AI代码能力的办法就是VSCODE+AI插件。如果想免费，可以安装一个通义灵码，目前不收费。如果有预算，可以买一个编码套餐，然后使用Claude接入，我这里用了智谱的GLM，可以参考这个文档配置，有任何问题都去可以咨询豆包：

链接: 智谱CodingPlan接入claude-for-ide

其中最重要一步是进入下面目录，修改setting文件，配置对应的apikey和指定的模型。

 cd C:\Users\你自己的用户名\.claude\settings.json

学习任意游戏工具

我让 AI 推荐一个结构清晰的项目来研究一下游戏自动化任务的实现，它推荐了这个基于 ok-script 框架的项目供参考：：ok-nte: link
（注意：此仓库仅用于研究任务调度与图像识别框架，请勿用于实际游戏运行）

它言之有理赶紧fork下，让AI教我看看这个项目：

依赖正在后台安装。先给你代码阅读路线图：

代码阅读顺序（由浅入深）

顺序	文件	作用	为什么先读它
1	main.py	入口，3行代码	理解启动流程
2	src/config.py	全局配置	了解项目注册了哪些任务、用什么OCR/截图方式
3	src/tasks/BaseNTETask.py	任务基类	二次开发最核心的文件，所有任务都继承它
4	src/tasks/DailyTask.py	日常任务	最完整的任务实现范例，写新任务参照它
5	src/interaction/NTEInteraction.py	游戏交互	键鼠操作封装，自动化脚本的操作基础
6	src/scene/NTEScene.py	场景定义	场景识别和判断逻辑
7	src/combat/BaseCombatTask.py	战斗系统	自动战斗核心，体力刷本会复用
8	src/globals.py	全局单例	OpenVINO模型、线程池、声音系统

建议：先读前4个文件就够了，理解任务框架后再看具体实现。你可以先打开上面列的文件开始阅读，从 main.py 开始，然后看 src/config.py。重点看 config.py 里的 onetime_tasks 和 trigger_tasks 列表——这就是任务注册机制，我们开发新模块也是往这里加。

那我们就相信AI的安排，开始看。

这里学到了一个冷知识，在下面文件夹里可以找到自己和calude的聊天记录，复制出来就是md的格式，可以直接发给大家看啦

explorer "%USERPROFILE%\.claude\projects"

看完代码后，我打算在严格控制的研究环境下跑一下这个框架，看看它的任务识别和模拟输入能否正常工作。AI 帮我梳理了依赖安装和运行方式：

cd D:\autoProject\ok-nte
D:\anaconda3\envs\endfield\python.exe main.py

运行后弹出了一个 GUI 界面，集成了截图、任务选择和运行控制功能。为了理解它的工作机制，我把运行日志发给 AI 一起分析，总结了几个关键技术细节：

• 图像识别对分辨率有要求：框架依赖固定的窗口比例进行图像匹配，测试时发现 16:9 比例（如1280x720）可以稳定识别，而非标准比例会影响场景判定。
• 模拟输入需要系统权限：脚本使用了 PostMessage 等方式模拟键鼠，在 Windows 下必须以管理员身份运行调用进程，否则会报拒绝访问 错误。这属于操作系统的安全限制，并非程序刻意提权。

2026-05-17 21:32:40,456 ERROR TaskExecutor intercation:PostMessage error 591472: (5, 'PostMessage', '拒绝访问。')

• 部分任务需要手动进入交互状态：比如一些非传送直达的场景（钓鱼等），脚本未实现自主寻路，需要手动让游戏进入相应界面后再由框架接管，这也是纯视觉脚本的常见局限性。

  这些验证让我们更清楚地看到，基于图像识别和模拟输入的框架能完成哪些自动化步骤，又有哪些边界。对于想要了解这种技术方案可行性的同学来说，是一次有效的实践

四款游戏自动化工具完整对比

扩展调研：不同游戏的开源自动化框架
既然对 ok-script 框架有了一定认识，我打算横向比较一下其他游戏自动化项目都用到了哪些技术栈，这有助于拓宽技术视野。AI 帮我整理了一个基于公开仓库的技术调研表：

游戏	推荐工具	技术栈	同ok-script框架
异环	ok-nte	Python + ok-script	✅
原神	BetterGI	C# / .NET 8	❌
原神	ok-genshin-impact	Python + ok-script	✅
终末地	MaaEnd	Go + MaaFramework	❌
终末地	ok-end-field	Python + ok-script	✅
星穹铁道	ok-StarRailAssistant	Python + ok-script	✅

注：上表仅为技术栈调研，所有仓库均来自公开 GitHub 搜索。请勿将这些工具用于任何违反游戏协议或破坏游戏环境的行为。

从表格可以看出，同一游戏可能存在不同语言和架构的实现，选择哪种方案往往取决于个人技术偏好以及对框架成熟度的取舍。对于我们学习任务调度和图像识别来说，Python 生态下的 ok-script 系列相对易于上手。

今天的探索就到这里，通过阅读代码和实际跑通框架，对自动化脚本的“感知-决策-执行”闭环有了初步理解。后续如果进一步学习，会继续分享任务注册机制、场景判断逻辑等具体细节。

再次提醒：技术学习的价值在于理解原理、提升能力，请始终在法律与规则允许的范围内使用技术。