先說結論

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 跑起來，讓代理點選並修改。美術匯出留在同一套圖層上下文上，回來的畫面才能對上節點。

看一遍這條迴路