Claude+VSCode环境搭建与ok-nte项目实战评测

2026-06-15阅读 0热度 0

Claude

相信不少玩家都琢磨过：把重复性高的游戏操作交给脚本，自己只玩核心决策环节。这背后是个有意思的技术命题——用计算机视觉加模拟交互，构建一套能理解游戏任务并自主执行的程序。说白了，就是用代码复现"观察→判断→操作"的循环。 ![](http://img.318050.com/uploads/20260607/17807949896a24c66d37ea6956329970.webp) 这个系列就从这儿切入。目标很直接：剖析几个开源项目，理清自动化脚本的设计思路与框架搭建方法。过程中会借助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比例（比如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系列入门门槛最低。今天的探索到这里。通过读代码和实际跑通框架，对这个"感知-决策-执行"的闭环有了初步理解。后续如果继续深入，会分享任务注册机制、场景判断逻辑这些具体细节。技术学习的价值在于理解原理、提升能力。始终在法律与规则允许的范围内使用技术，才是正路。

Claude+VSCode环境搭建与ok-nte项目实战评测

相关阅读

最新教程

最新资讯