让 AI 在场景里增加一面墙很容易，判断它有没有把玩家的路线堵死，则需要真正运行游戏。
我是 EVEngine 的作者。我一直关注 AI 做游戏之后的维护问题：哪些规则必须保留，怎样把规则变成可以重复执行的检查。0.6.1 纳入的 whitebox-playtest，就是沿这个方向做的一步。
把一次手动检查留下来
设想一个走廊场景。人手检查时，会重置场景、调整墙体、按住前进键、等待几帧，再查看角色和场景状态。下次改了墙的位置，还要重复这些步骤。
白盒工具把这些步骤组织成一份 recipe：reset、scene、inputs、waitFrames、play，以及最终 assert。它既能批量搭景，也能注入输入，并把结果交给断言检查。目的在于让检查步骤可以保存、重跑和比较。
引擎侧提供 eve_scene_batch 和 eve_whitebox_playtest；Python 工具也能作为独立 stdio MCP 服务接入，提供 wb_run、wb_apply_scene、wb_playtest、wb_default_recipe。
批量操作还有一个实际作用：把多次场景调整放在一次调用里，减少 Agent 逐对象来回调用的次数。但批量提交是否全部成功，仍要读取返回结果，不能凭调用次数推断。
从最小 recipe 开始
仓库的 tools/whitebox-playtest 目录提供 corridor recipe。先在该目录验证工具配置：
bash
python -m whitebox_playtest --dry-run --trace干跑不需要引擎，适合检查 recipe 和工具接口；它不能证明真实碰撞或角色移动正确。连接真实引擎时，可按该版本 README 的方式启动舞台：
bash
eve run --debug --mcp-port=7529 examples/ai-stage然后在工具目录执行：
bash
python -m whitebox_playtest recipes/corridor.json --port 7529 --report build/wb_report.json这些命令来自 v0.6.1 的工具文档，运行前需要对应的 Python 环境和带相关模块的引擎。输入包含等待或抓帧时，调用可能返回 pending；需要继续轮询 eve_input_poll，直到完成。Python runner 已负责这一步。
断言要检查游戏要求
示例 recipe 展示了 scene.applied、info.count 等报告字段的断言，也支持 eq、gte、contains、truthy 等操作。它们能检查基本执行结果，但"对象添加成功"与"玩家能走到出口"是两种不同的要求。
对于真实游戏，可以逐步补充更贴近玩法的检查：在固定起点生成角色，运行明确的输入或控制脚本，在限定时间内检查目标状态；失败时保存状态和画面。具体目标和观察字段需要由游戏接入，不能照搬一个通用断言就宣布地图全部连通。
尤其要区分导航与移动：寻路算出了路径，角色仍可能因为碰撞体、台阶或自身尺寸而卡住。涉及通行性的验收，应尽可能让真实角色控制和碰撞参与。
用同一份检查陪着 AI 继续改
比较适合的工作方式是：先把一个已知能通过的小场景存成 recipe，再让 AI 改一处内容，重复运行相同检查。如果失败，把报告、输入和场景变更一起交给它，缩小问题范围。
检查通过也有范围。它只能说明这份 recipe 覆盖的要求得到满足；关卡节奏、战斗手感和美术质量仍需要人体验。对维护来说，先把几条确定的硬性规则守住，已经比每轮都从头人工巡视更有积累价值。
这项能力由 PR #545 引入，并纳入 0.6.1。完整配置、recipe 字段与示例见 v0.6.1 工具说明。本文是基于源码文档的工作流介绍，没有另行执行上述命令。
EVEngine 源码 · 官网。项目采用双许可，使用及商用条件见仓库许可证。