我是 EVEngine 的作者。上次介绍项目时，我主要谈了脚本、热重载和 MCP。这次想用 0.6.0、0.6.1 的具体更新，回答一个更实际的问题：AI 写出第一版游戏之后，工具怎样帮助它继续修改？
假设要做一个有角色、建筑和伙伴的战斗场景。第一轮把场景摆出来并不算结束：建筑可能挡住路，伙伴可能站错位置，材质可能在换光照后失真。开发者需要能重复搭建场景、操作角色、检查状态，再根据证据修改。
0.6.0：先把运行与反馈的基础理顺
0.6.0 整合了动作战斗、战棋、RPG 存档与程序化地形相关示例和文档，也包含独立天空运行时、聚光灯与可配置阴影、道路网络、静态网格合并等改进。对写游戏的人来说，这些能力提供了组合玩法和场景的起点。
开发工具方面，MCP 软重启、ProviderRef 与 capability 生命周期检查，让运行中的工具引用有更明确的有效范围。部分 API 改用结构化 Result，调用方需要检查操作结果，而不能默认"发出调用就一定成功"。这些改动不直接增加画面元素，却关系到 AI 能否识别失败并继续排查。
这一版也明确写出了边界。例如当时的 combat-arena 是自动对战模拟组合示例，渲染仅清屏；不能因为名字里有 arena，就把它宣传成完整动作游戏。各域存档能力也不能直接等同于跨所有系统的统一事务编排。
0.6.1：把修改、观察和验收接起来
0.6.1 纳入了白盒批量搭景与自动试玩。Agent 可以通过 recipe 描述场景修改、输入和断言，把一次检查保存下来。下次修改后重复执行，才有机会发现"之前能过，现在过不了"的变化。
另一个很实用的更新是 MCP 同帧渲染附件捕获。除了最终画面，还能检查同一帧的深度、法线、材质参数和阴影附件。角色变黑、表面发亮或者遮挡异常时，AI 可以获得更具体的诊断材料。当前这项捕获能力主要由 Vulkan 提供，WebGPU 明确返回 Unsupported。
物理方面，新增可选 Jolt 后端，并通过后端中立的世界、刚体、形状和关节契约接入；原有默认后端保持不变。房屋坍塌示例则把一次高成本模拟烘焙为可回放数据，适合反复调镜头、材质与演出。
创作工具也在继续补齐：材质工作室、地形场景创作、角色骨骼调整、桥梁生成，以及多种参数化武器特效，都让脚本有更多可组合的对象。但功能纳入版本，不等于所有示例已在所有图形后端完成相同程度的验证。
更值得观察的是第二次修改
如果想评估这种开发方式，我建议选一个很小的场景，连续改三轮：先搭一个可走通的通道，再加障碍，最后加入伙伴或战斗行为。每轮都记录输入、结果和失败原因。
场景规范也应足够具体：出生点不能被占用、出口必须可达、一次攻击不能重复结算。引擎提供批量操作和检查入口，开发者仍需要定义验收条件。白盒测试工具存在，并不意味着任意地图的可达性已经自动得到证明。
EVEngine 希望让 AI 能参与编写、运行、观察、调试和验证游戏。0.6 到 0.6.1 的这些工作，正是在给后续修改提供抓手。欢迎从一个示例开始，带着真实需求试一轮，也欢迎反馈哪种检查最难接入你的游戏。
本文依据公开发布记录整理，未把历史 PR 的局部测试结果当作本次全平台实测结论。截至 2026 年 10 月 27 日，GitHub Release 的 v0.6.0、v0.6.1 均已取消预发布标记；正文中的历史候选验证记录仍应按其原有范围理解。
参考：0.6.0 发布记录、0.6.1 发布记录。GitHub 源码与文档 · 官网。项目采用双许可，具体使用和商用条件以仓库许可证为准。