AIRI 游戏 AI 实战Dome Keeper 的 YOLO 数据采集 Mod 与端到端训练管线解析【免费下载链接】airi Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-samas altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airi本文基于 AIRI 仓库中的 DevLog 2026.02.16作者 LemonNekoGH展开围绕其从airi-factorio转向 Dome Keeper 后的数据采集与训练实践深入拆解数据采集 Mod 的仓库组织方式、采样策略、标注坐标系与 Letterbox 陷阱、数据集切分方案并结合上一阶段的纯视觉经验DevLog 2025.08.26串联出一条可复用的采集 → 过滤 → 切分 → 训练闭环。读者读完可掌握为游戏 Mod 搭建 YOLO 数据采集管线时需要避开的典型坑位以及一整套可直接借鉴的设计决策。背景为什么从 Factorio 转向 Dome Keeper在 DevLog 2025.08.26 中LemonNeko 分享了airi-factorio纯视觉方向的进展把 Factorio 客户端装进 Docker、通过 VNC 在浏览器里实时查看画面并用 YOLO 模型做目标检测推理速度从 400ms 优化到约 20ms。这套玩法验证了纯视觉 目标检测 AI 决策的可行性但 Factorio 本身太自由、太复杂对 AI Agent 的可控性要求过高于是作者转向了Dome Keeper——一款节奏相对简单、画面目标清晰的游戏更适合作为下一阶段的数据采集与模型验证场景。在 AIRI 主仓库的 README.md 中这个方向被登记为子项目AIRI DomeKeepergame-playing-ai-dome-keeperAllow AIRI to play DomeKeeper与 AIRI Factorio、Minecraft 等并列于Brain 能力的路线图之中README.md。也就是说Dome Keeper 并不是一次孤立的实验而是 Project AIRI让 AI 会玩游戏这一整体目标下的又一块拼图。数据采集 Mod把Start YOLO Data Collection按钮装进暂停菜单整个工作的第一步是编写一个游戏 Mod 用于采集标注数据。安装 Mod 后游戏暂停菜单中会出现一个Start YOLO Data Collection按钮点击即开始采集画面帧与对应的标注文件。这一交互设计非常直白采集动作由真人玩家在真实游戏过程中触发从而获得贴近真实对局的画面分布而不是脚本生成的合成场景。仓库结构反编译代码不进版本库开发 Dome Keeper Mod 的前提是反编译游戏但游戏源代码受版权保护、不能公开。作者因此仔细设计了仓库结构反编译出的游戏源码放在仓库根目录的external/文件夹并在.gitignore中整目录忽略确保不会误提交Mod 代码通过软链接链接进游戏源码目录既能正常编译/加载又保持了仓库内只有自己写的代码的干净边界。这一做法与airi-factorio阶段的思路一脉相承——当年用符号链接把 tstl 编译产物链进游戏目录以便调试见 DevLog 2025.07.18。两者的共同点在于在必须依赖第三方/私有产物的前提下用文件系统层面的隔离保持仓库的可发布性。采样策略从固定频率到有目标优先的负样本控制初期策略非常简单每 0.5 秒采集一帧。但实际跑起来后发现一个严重问题——大多数帧里画面中一个目标都没有于是负样本占比极高。数据量看着在涨有效信息密度却在下降训练集被大量无意义背景帧稀释。修改后的规则改为有目标帧优先只有画面中出现enemy或ore_*矿石类目标才把该帧记为有目标帧必须先采够 5 张有目标帧才允许采 1 张无目标帧。这样既保留了一小部分背景帧帮助模型区分无目标上下文又不会把训练集稀释得太厉害。这一策略本质上是在信息密度与背景多样性之间做权衡与上一阶段非正方形图片导致置信度骤降等问题的应对思路一致见 DevLog 2025.08.26——检测模型的训练质量首先取决于数据的有效分布而不是总量。标注陷阱一UI 叠加导致的错标采集过程中如果**暂停菜单或升级面板TechTree**处于打开状态UI 会大面积覆盖游戏场景但标注逻辑仍在照常给矿石和敌人打标签从而产生UI 上盖着一个 bbox的错误样本。这个问题的隐蔽之处在于从标注 txt 文件本身完全看不出来——文件内容看起来一切正常只有在可视化标注时才会暴露。作者给出的解决方案非常轻量给PauseMenu/TechTreePopup加上 group 标记只要检测到该 group 中存在可见节点就直接跳过本次采集。用 Godot 的 group 机制做可见性守卫避免在 UI 层覆盖场景时写入脏数据。这也提醒我们数据采集的脏数据往往不来自算法而来自上下文状态未纳入考量。标注陷阱二坐标系不一致导致的整体偏移这是整个过程中最疼的一个坑所有目标的 bbox 都朝同一方向整体偏移看起来就像整张图被错误缩放。根因是view 的逻辑尺寸与实际纹理像素尺寸不一致bbox 计算用的是viewport.get_visible_rect().size视图逻辑坐标截图却是从 texture 上取的纹理像素坐标。两个坐标空间存在比例与偏移差异直接混用就会导致标注整体错位。修复方式是把坐标变换分两步走先把 bbox 从 view 坐标缩放到 image 像素坐标再做 letterbox 的缩放与偏移。这套逻辑在上一阶段其实已有先例airi-factorio的收集脚本通过game.take_screenshot截图、基于实体 selection box 生成标注见 DevLog 2025.08.26同样面临游戏坐标 → 截图坐标的映射问题。坐标空间统一是任何游戏内数据采集管线的第一原则。标注陷阱三Letterbox 变换必须作用于 bbox训练时输出统一归一化到640×640并做了居中 padding灰色114/255。这一步如果只对图片做、不对 bbox 做同样的变换标注必然错位。因此正确的 bbox 变换是两步组合先对 bbox 做缩放 offset从 view 坐标到图像坐标再归一化到 640×640含 letterbox padding 补偿。这里114/255是 YOLO 生态中常见的 letterbox 填充色默认值约等于 0.45 灰与上一阶段训练分辨率 640×640、模型导出 ONNX的做法保持一致见 DevLog 2025.08.26。对任何接入 YOLO 的采集管线而言图片怎么变换标注就必须怎么变换是必须写进代码注释的铁律。数据集切分30 秒一段、4/1/1 循环切分最初计划按session对局会话切分数据集但一个 session 可能很长而且同一 session 里可能玩多局导致 train/val/test 分布不理想。最终改为按时间切分每 30 秒切一个段按4/1/1比例循环分配到train/val/test。这样3 分钟就能完成一个完整的切分周期验证成本大幅降低——不需要等一整局打完就能拿到一套结构完整的训练/验证/测试集。对迭代频繁的实验阶段来说快速闭环比统计严谨更优先。性能与卡顿优先减负而不是一上来就上线程Image.resize()和save_png()都是CPU/IO 密集操作采样频率太高会导致游戏卡顿。作者的取舍很明确尽量通过减少无目标帧来降低 IO 压力而不是一开始就上多线程。结合前面的采样策略两者形成呼应有目标优先的过滤规则不仅提升了数据质量也顺带降低了无效 IO。这是把数据质量优化与性能优化统一起来的好例子——先消除不必要的工作量再考虑并行化避免过早引入线程复杂度。当前成果一个稳定且可快速验证的训练闭环综合以上设计作者总结出一条端到端管线Capture → filter negatives → auto split → auto generate data.yaml → train directly即采集 → 过滤无目标帧 → 自动切分 → 自动生成data.yaml→ 直接训练。data.yaml是 YOLOUltralytics训练所需的标注清单文件自动生成意味着从游戏 Mod 采集到开始训练之间不再需要人工搬运数据。训练日志已经能看出端倪矿石类ore_*mAP 表现良好说明采集链路与坐标变换是正确闭环的dome/enemy/player类别样本仍然偏少需要后续补充。这正是上一阶段纯视觉方案的延续用 YOLO 预训练权重做底座、在游戏截图数据集上微调、输出 ONNX 模型再接入浏览器推理DevLog 2025.08.26。Dome Keeper 方向目前处于数据积累 管线验证阶段模型精度最高的类别恰好验证了采集逻辑的正确性而样本稀疏的类别则明确了下一步的工作重点。下一步复用 Playground 与补样本作者明确列出两项后续计划扩展airi-factorio仓库中的纯视觉 Playground让它支持 Dome Keeper使整个proj-airi组织都能复用这套实时画面 检测结果可视化 AI 决策的框架补充更多样本尤其是dome、enemy、player三个类别——它们是当前训练短板。结合 README.md 的 DevLog 索引这篇 2026.02.16 的 DevLog 被登记为Dome Keeper data collection and training pipelineMod 代码也已开源见 README.md 的子项目列表说明该方向仍在持续投入。结语可迁移的六条经验回到这篇 DevLog 本身最值得记住的是六条经过实战检验的设计决策仓库隔离反编译产物放external/并 gitignoreMod 代码用软链接接入保持可发布性有目标优先采样5 张有目标帧后才允许 1 张无目标帧平衡信息密度与背景多样性UI 状态守卫用 group 可见性检测跳过 UI 覆盖帧防止看不见的错标坐标系统一view 逻辑尺寸与纹理像素尺寸必须显式做两步变换否则 bbox 整体偏移Letterbox 同步变换图片归一化到 640×640padding 灰114/255时bbox 必须走同样的缩放 offset 归一化时间切片 4/1/130 秒一段循环切分 train/val/test3 分钟一个完整周期最大化验证迭代速度。这套经验不仅适用于 Dome Keeper对任何游戏内 Mod 采集 YOLO 数据集的场景都有直接参考价值也是 Project AIRI 让 AI 真正看见并理解游戏世界的关键一步。【免费下载链接】airi Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-samas altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考