Godot 上的 AI 全自动开发，自动验证走得通吗
先说结论
Godot 上的全自动开发和自动验证走得通，前提是编码代理和正在运行的游戏在同一台机器上。Cursor 和 Codex 已经能在远程主机上工作。Godot Runtime Bridge 在这台主机上把工程跑起来，交回画面，并发送模拟点击，下一轮修改就可以从这次走查来。公开讨论里已经有人回复，Codex 走通了这一步。这条回路对得上的环境是 Godot。代理核对的画面，在下一处改动是界面时，仍要带着原来的图层上下文。
走查还停在人按播放
编码代理已经能写 GDScript，也能改 .tscn。改完之后的核对仍是人：打开编辑器，按播放，看一遍，再把坏掉的地方描述回去。Cursor 和 Codex 现在可以把这件事放到远程主机上。工程在那台机器里。预览如果只在另一张桌子的窗口上，代理改完就停住。走查进不了和这次修改同一份上下文。
同一台主机可以跑游戏，也可以点
Godot 跨平台。工程语言是 GDScript。场景是文本。已经在跑 Cursor 或 Codex 的远程主机，可以在同一台机器上跑 Godot。
Godot Runtime Bridge 把代理接到正在运行的游戏上。这段演示 里，代理在走查中找到问题，改工程，再核对一次。桥接留在游戏所在的那台机器上。远程主机上，这台机器就是代理的机器。代理启动游戏，读画面，发送点击，写下一次修改。开发、测试、以及根据测试做的修改，都在一台主机上。
这条回路放到公开讨论里之后，已经有人回复：Codex 上同一条路走通了。代理在主机上改工程，游戏在那里跑，结果回到下一轮修改。两轮之间，不必再由人按播放。
AI First 的自动验证需要的就是这个环境
Unity 的 MCP 已经能写进打开的编辑器。Godot 多出来的是同一台远程主机上的运行时：游戏能跑，画面能回来，模拟点击能推动下一轮。跨平台的引擎、GDScript，再加上 Godot Runtime Bridge，让这一轮发生在代理所在的机器上。编辑器插件的数量一度显得比 Unity 少。对 AI First 来说，要核对的是主机上的这条回路，而这条回路对得上 Godot。
核对过的画面仍要和图层对上
这条回路可以确认一段脚本。点击落到了，数值变了，崩溃出现在日志里。界面是下一处核对。代理可以看见一颗按钮位置不对。这一屏如果仍是一张图，或者切图和节点不再共用名字和位置，下一次美术修改就落不到脚本刚刚接好的那些节点上。
Godot AI 美术流程 已经在盯生成之后的这段缺口。Figma 到 Godot 的导入工具是单向的 从设计稿一侧写过同一件事：导入一次写出的是一份快照，后面的生成读不到这份快照。
界面要还能重新导出来，放在 VberAI Studio 里做。图层名字、位置、哪一块能点，随文件写进 Godot 工程目录。界面要改，再导出一轮。节点还能对上。打开的场景和脚本仍通过 Godot MCP 交给编程工具。Godot Runtime Bridge 再在主机上把这个工程跑起来。自动回路验证的，是导出时那些图层还在的游戏。设计稿步骤见 Figma 到 Godot。
Godot Runtime Bridge 覆盖的是运行、画面和模拟输入。它不把图层上下文写回工程。VberAI Studio 覆盖的是这次导出。主机上的回路和美术导出要用同一套图层名字，否则下一轮验证的画面，工程已经无法按原结构再导出来。
小结
Godot 上的全自动开发和自动验证走得通。把工程放到跑着 Cursor 或 Codex 的远程主机上，用 Godot Runtime Bridge 跑起来，让代理点击并修改。美术导出留在同一套图层上下文上，回来的画面才能对上节点。