之前的游戏辅助跑了一个月了因为刷了很多资源。账号能力提高很多，于是就有了刷下一级副本的能力。下一级副本效率提高了 50%，单位时间产出也高了 50%，但难度随之上升：Boss 会释放随机技能。只要吃上一个，游戏失败的概率就会明显提高，这正是我最大的痛点。

痛点与需求分析

• 随机技能识别困难：Boss 技能出现位置不固定，传统像素匹配常常漏检。
• 数据采集耗时：需要大量手动截图、切分网格并分类，几乎全是体力活。
• 模型精度不稳定：上线后经常出现误判，导致实际收益大幅下降。
• 成本与维护压力：AI 网站积分消耗快、套餐费用高，且模型需要频繁迭代。

至于选型对比。OpenCV vs YOLO

最初使用 OpenCV 的 match-image 来匹配角色，但在复杂场景下效果极差。最终方案改为点击塔获取详情，再匹配头像，匹配度基本能达到 99%。不过，只是 Boss 技能只在棋盘上出现。短时间内连续截图三次进行匹配既耗时又效果差，只能转向 YOLO。

为什么不再用 OpenCV

OpenCV 属于基于像素模板的匹配技术，对光照、角度变化极为敏感；在随机技能的多样化表现面前几乎失效。

为何选择 YOLO 分类分支

• YOLO 是深度学习目标检测模型，能够在复杂背景中捕捉特征。
• 程序已有明确的网格划分，Boss 技能只会出现在网格内。可直接使用 .classify 分支进行类别判断，无需定位坐标。
• 训练材料相对简单，只需收集不同技能的截图并按类别归档。
• 参考同事 2018 年玩猫狗分类的经验，快速落地。

操作流程

1. 收集训练数据：
   • 编写脚本。在指定时机连续截图，以保证数据多样性；其实，此阶段必须手动进行游戏操作。
   • 玩足够多局后收集所有不同 Boss 技能的截图。
2. 网格切分与标签化：
   • 使用另一脚本将完整截图按网格切分，得到单格图片。
   • 把同一技能的图片放入同一文件夹，例如“skill_A”、 “skill_B”。这一步最耗时且完全依赖人工劳动，是典型的体力活。
3. 模型训练与导出：
   • 运行提供的训练代码。将标注好的数据喂入 YOLO 分类网络，输出 ONNX 模型文件。
4. 上线使用：
   • 加载 ONNX 模型，在游戏运行时实时识别当前格子中的技能并做出对应操作。

*提示*：理论上应划分出一部分数据作为验证集。但实际测试发现直接使用全部数据训练效果更好，模型精度略有提高。

业务介入与调优经验

A/B 测试发现上线后仍有误判，因为 Boss 技能并非每局都会出现。将错误样本重新加入训练集可以提高模型，但手动找错成本极高。通过分析日志，我发现模型往往找到了最相似的技能，只是置信度低于 50%。降低阈值后仅取置信度最高的结果，成功率几乎达到了 100%。这说明即使是 AI，也离不开人为调参和业务理解。

再看关键调整点。

• Simplify detection: 使用 YOLO 分类分支而非检测分支，大幅减少计算量，提高帧率。
• Selectively match: 在 OpenCV 阶段仅保留关键角色进行匹配，一样提高效率。

AI 能力现状与成本考量

AIGC 网站曾因夸大 AI 能力而导致误判。现在我们更理性地看待它：AI 可以让工程师专注业务，而不是纠结底层 API，就像厨师不必自己洗菜一样。怎么说呢，但仍然需要人类参与数据标注、阈值调节和业务逻辑设计。

I 使用的是 Træe，这次开发用了 5 天总计消耗约 2000+ 积分。当前套餐每月仅提供 2000 积分，需要升级才能满足正常工作量；若全职投入，一个月约需 240 元预算。领域价格仍在波动，但我未来会趋于稳定——能力更强、价格更亲民。

AI 并非万能，还需人类深度参与