用途
Game QA 是一个游戏质量验证技能，用于在构建成功之后判断游戏是否真正可玩。它的核心观点是：构建成功只证明编译通过，并不等于一次成功的试玩。验证应当与代码改动内容以及当前可用的运行时相匹配。
验证通道
根据不同目的可选择以下验证通道：
- smoke：构建、启动、到达首个可操作状态，并触发主要输入。
- feature：验证变更后的行为，包括其进入/退出状态、失败情况以及相邻系统。
- bug regression：在可能时复现此前的故障，验证修复，并检查相关路径。
- visual：检查有代表性的游戏画面截图，关注构图、可读性、缺失美术、裁切以及 HUD 遮挡。
- performance：在建议优化之前，先用引擎自身的诊断能力复现并测量所报告的瓶颈。
使用方式
应阅读项目已有的脚本、测试设置与引擎约定，优先使用项目既有的构建与逻辑检查方式。
对于已配置的 OhMyGame Web 预览，优先使用 game_use：复用它已有的会话、发送真实输入、检查运行时错误与资源加载失败、抓取有代表性的渲染状态，并在同一轮内关闭会话（即使失败也要关闭）。OhMyGame 负责预览服务器，不应另外保留一个开发服务器运行。
对于原生引擎，应使用可用的运行时工具、真正支持启动或交互的引擎连接，或项目自有的自动化方式。仅有一个编辑器 MCP 连接并不构成游戏验证。不要为了获取截图而把原生游戏包装成 Web 项目，也不要仅为了常规验证而安装新的浏览器或自动化框架。
当有助于到达受影响状态时，可使用已有的确定性重置、随机种子、状态快照或逐步操作。但仍需验证真实输入以及玩家实际看到的内容。仅当正常输入无法可靠到达或识别必要状态时，才添加最小化的仅测试用桥接；正常游戏流程不得依赖该桥接。
面向玩家的检查
需检查启动/加载、控制的可发现性与反馈、进度推进、转场、暂停/模态输入、失败/重启以及缺失资源。以实际游戏尺度检查精灵图，并检查模型的方向、构图、光照、动画与碰撞对齐。当布局或输入发生变化时，检查有代表性的受支持设备；当移动端是目标平台时，需执行移动端检查。
修复与报告
修复问题后应重复受影响的检查。在相关时应分别报告构建、逻辑、运行时、交互、视觉与性能证据。如果无法获得运行时交互或截图，应运行最强的受支持检查，并说明哪些内容仍未被验证。单张截图、DOM 检查或一次编辑器操作都不构成完整的试玩验证。