从写脚本到造轮子：我是如何重构游戏自动化框架的

最近在折腾一个游戏自动化的框架，顺便复盘了一下这几年的架构心路历程，踩了不少坑，也有些新的思考。

作者头像

文章作者 Kate Tseng

为什么回到 Python？

几年前我第一次写这个框架时，用的是 Auto.js，那时候架构比较简单，经典的单例模式跑天下。但随着需求变复杂，单例模式就开始显得力不从心了，代码耦合度太高，改一点点逻辑就像牵一发而动全身。

这次重构，我的第一反应是跟风试试 Rust。毕竟这几年 Rust 的风头正劲，性能和安全都摆在台面上。于是我让 AI 帮我把代码逻辑搬过去，结果让人大跌眼镜：

Python 版本（手写优化）： 模版匹配核心逻辑能做到 1~3ms。
Rust 版本（AI 辅助重构）： 折腾半天，也就勉强做到 3~5ms。

我也试过让 AI “抄”我的 Python 逻辑去改 Rust，结果生成的代码性能就是上不去。这一点确实有点难以接受，明明是“系统级语言”，在特定场景下却输给了胶水语言。最后为了稳定性和开发效率，还是决定回滚到 Python。毕竟 Python 的生态摆在那里，轮子多，遇到问题容易找解决方案，对于自动化脚本这种场景，开发效率往往比极致的 runtime 性能更重要。

哭笑不得的表情

面对 Rust 性能不及预期时的无奈

框架设计的核心痛点：总感觉缺了点什么？

回到 Python 后，我面临的最大问题不是语言本身，而是架构设计。

现在的框架设计我总觉得不够“结实”。原因很简单：对未来的不可预知性。

我担心万一过两个月突然冒出一个新需求（比如游戏大改版，或者要接入多开、云挂机），现在的架构又得推倒重来。这种反反复复的大改最搞人心态。

为了解决这个问题，我目前的策略是做减法：

剥离无关细节：把所有跟核心业务无关的杂七杂八的模块都扔出去。
保留核心调度器：现在的框架里，我只保留了一个 “任务调度器” 作为核心模块。

我认为，只要调度器设计得够灵活，外挂什么功能都只是插件的问题，不会动地基。

框架设计的避坑指南与最佳实践

作为一个从脚本小子进阶的“小白”，结合这次重构的经历，我总结了几条框架设计的经验（或者是教训），供大家参考：

1. 核心优先

不要一上来就想着“我要做个大而全的平台”。设计框架的第一步，应该是剥离。

你的核心是什么？ 是图像识别？是输入模拟？还是任务流控制？
对于游戏自动化来说，核心往往是状态管理和任务调度。把这两块抽象出来，其他的（比如日志、配置读取、GUI）都可以用开源现成的库去填。

2. 面向接口编程，而不是面向实现

这在 Java 领域是老生常谈，但在 Python 脚本里容易被忽视。

不要在主流程里把具体的识别算法（比如 AForge 还是 OpenCV）写死。定义好一个 Recognizer 接口，以后你想换算法，甚至想用网络请求识别，都不用改主流程代码。

3. 依赖倒置

如果你现在的代码里，TaskScheduler 依赖具体的 GameModule，那就错了。

应该是 GameModule 依赖于 Scheduler 定义的事件钩子。这样你以后要写另一个游戏的自动化脚本，只需要写模块，调度器不用动一行代码。

4. 接受“适度重构”

不要追求“一次设计，终身受用”。这是不可能的。

好的框架是“长”出来的，不是“想”出来的。先把核心调度器跑通，当需求变更导致架构别扭时，再去重构那一个点。只要你的核心模块（调度器）足够内聚，重构的成本就会控制在可接受范围内。

写在最后

设计框架其实就是在做取舍。在 Rust 的性能诱惑和 Python 的生态便利之间，我选择了后者；在大而全的复杂架构和极简主义的核心调度之间，我也正在尝试后者。

如果你也在做类似的自动化工具开发，建议先从任务调度器入手，把输入输出抽象清楚，剩下的慢慢补齐。不要怕改代码，怕的是地基没打好，改一处塌一片。