先說結論

從 Figma 到 Godot，一邊是 Figma 上的 Exporter 外掛，一邊是 Godot 裡的 Importer。Godot 一側還有單獨的 MCP 外掛。兩邊都有工具，把畫板切成圖、寫進引擎，仍然多半只做一次。

設計稿調整了之後，原來寫進引擎的介面往往就過時了。節日運營如果要批次換一套新介面，引擎裡的節點樹大機率對不上原來的圖層結構。用 AI 再生成一版新主題，也會碰到同一件事。

舊匯入為什麼是單向的

我最近在思考一個問題。到 2026 年 9 月，Cursor 這類 AI 編碼工具已經逐漸普及。社群裡從 Figma 進 Godot，常見的仍是 Figma 的 Exporter，再加上 Godot 的 Importer。做法通常是從 Figma 匯出切圖，再在 Godot 裡搭成 Control 節點。做完這一步，畫面第一次出現在引擎裡。

Figma 裡改一顆按鈕，Godot 裡的介面不會自動更新。需要先匯出，再讓驅動生成的 AI 檢查這次最新的變動，才能同步進 AI 的上下文。同理，Godot 裡的邏輯一旦變了，也無法有效地同步回 Figma，再用這份新上下文去驅動生成。

Godot 裡出現了新的改動——少一張圖、要換一屏、節點已經接好但畫面要重做——需要回到 Figma 一側再驅動 AI 生成。生成結果還要能映射回原來的節點和目錄。再導一次，常常是多一份貼圖，或者把已經接好的節點蓋掉。設計稿和工程還是無法做到即時同步。

有了 Figma 的 Exporter 和 Godot 的 Importer，重新搭建被縮短成走一遍。圖層的名字、位置、哪一塊能點，會按這一次匯出寫進引擎。寫進去的是一份 Snapshot。後面如果還要用 AI 重新生成介面，這份 Snapshot 並沒有即時同步到 AI 的上下文中。

AI First 之後，缺的是同步和再次生成

r/godot 上現在還能看到不少人對 AI 生成美術的反饋。有人把用生成資源寫成「原罪」，討論仍停在該不該用：I committed the cardinal sin of using AI generated assets。已經按 AI First 來做的人，更早開始排程生成、匯出和引擎裡的接線，用這些步驟在這個背景下把開發效率拉上去。

開發效率要上去，介面就不能每次都在引擎裡重新搭建一遍。通過 MCP，程式設計工具可以接到開啟的 Godot 上，當前場景、節點和指令碼可以讀，也可以改。這一段已經可以用 Godot MCP 完成。

給按鈕接事件時，靠的是節點還叫原來的名字，切圖還在原來的目錄。後來如果又生成了新的介面，名字和目錄都變了，開啟的工程裡就是一棵對不上的新樹，舊指令碼接不回去。

這裡缺兩件事。一件是資源同步：檔案要按引擎目錄寫進去，原圖層的上下文資訊都要保留和同步。另一件是可以重新生成：設計稿調整之後，還能從同一份分層檔案再匯出一輪，不必在引擎裡手改貼圖名字。只走一遍的 Exporter 或 Importer，覆蓋不到這兩件。單獨用 Godot 的 MCP 外掛，也覆蓋不到。同步的是當前開啟的編輯器，不會按引擎結構批次儲存美術資源，也不會在生成新圖之後把圖層關係帶回來。

AI First 背景下，real-time 的美術資源同步和程式碼邏輯同步需要並行

當前已經走通的做法是用 VberAI Studio 處理 Figma to Godot 這一段。把 .fig 匯入 VberAI Studio，再按 Godot 工程目錄匯出場景和切圖。圖層名字、位置、哪一塊能點，跟著檔案一起寫進引擎目錄。設計稿要改，回到 VberAI Studio 再匯出一輪，工程裡的節點還能對上原來的圖層結構。

程式碼這一邊，通過 Godot MCP，把當前開啟的場景和指令碼交給程式設計工具。美術資源同步和程式碼邏輯同步要一起做：在 VberAI Studio 裡保留還可以重新生成的分層源，並按引擎目錄寫出檔案；再用程式設計工具對著還對得上的節點去接事件。只做其中一邊，介面改第二次就會對不上。

完整步驟見 Figma 到 Godot。

小結

AI 編碼工具已經成為主流。是時候重新調整工作流，讓資源的生成和到引擎的對映做到更高程度的同步。