相信很多玩家都曾有过这样的想法：那些高度重复的游戏操作，能否交给程序自动完成，从而把精力留给真正有趣的环节？这其实是一项颇具吸引力的技术课题——借助计算机视觉与模拟交互，让程序理解游戏任务并自动执行。简单来说，就是用代码还原“看到→思考→动手”的完整闭环。  本系列就从这里开始。核心目标十分明确：拆解几个开源项目，理清自动化脚本的设计思路和框架搭建方法。过程中将借助AI编程工具来阅读代码、配置环境——毕竟逐行手动啃源码效率太低。 ### AI 代码助手的配置与应用 要快速用上AI写代码的能力，在VS Code中安装一款AI插件是最直接的方式。免费选项包括通义灵码，目前完全免费。如果预算充足，也可以购买编码套餐接入Claude。这里使用的是智谱GLM，具体配置方法请参考官方文档。关键操作是进入以下目录，修改`settings.json`，正确填写apikey和模型名称： ``` cd C:Users你自己的用户名.claudesettings.json ``` ### 学习任意游戏自动化工具 让AI推荐一个结构清晰的项目来研究游戏自动化的实现，它推荐了基于ok-script框架的ok-nte仓库。这个项目主要用于研究任务调度和图像识别框架，并非实际用于游戏。 直接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`开始，然后是`config.py`。重点关注`config.py`中的`onetime_tasks`和`trigger_tasks`列表——这就是任务注册机制，后续开发新模块也要往这里添加。 顺着这个路线走，很快就能摸清整体脉络。 顺便分享一个冷知识：在以下路径中可以找到与Claude的聊天记录，复制出来就是Markdown格式，可以直接分享给他人。 ``` explorer "%USERPROFILE%.claudeprojects" ``` 读完代码后，计划在严格控制的环境中运行这个框架，测试任务识别与模拟输入是否正常运作。AI帮助梳理了依赖安装和运行方式： ``` cd D:autoProjectok-nte D:anaconda3envsendfieldpython.exe main.py ``` 运行后弹出一个GUI界面，集成了截图、任务选择与运行控制功能。将运行日志交给AI一起分析，总结出几个关键细节： - **图像识别对分辨率非常敏感**：框架依赖固定的窗口比例进行图像匹配。测试表明，16:9比例（如1280×720）能够稳定识别，非标准比例则会影响场景判断。 - **模拟输入需要系统权限**：脚本通过`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系列入门门槛最低。 今天的探索就到这里。通过阅读代码和实际运行框架，对“感知→决策→执行”的闭环有了初步理解。后续如果继续深入，会分享任务注册机制、场景判断逻辑等具体细节。 技术学习的价值在于理解原理、提升能力。始终在法律与规则允许的范围内使用技术，才是正确的方向。