Figma 到 Godot：手動流程 vs AI Studio 工作流程對比

為什麼多數團隊的 Figma → Godot 仍像純手工

獨立與中型 Godot 專案常在 Figma 裡設計 HUD、選單與商店介面，再在編輯器用 Control 節點重建：MarginContainer、VBoxContainer、TextureRect、Label、Button 以及 Theme 資源。

問題不在 Figma 能否匯出 PNG——當然可以。真正的問題是 佈局歸誰管：設計師的 Frame，還是工程師逐像素重搭錨點與容器。

本文對比兩條路徑：

1. 手動流程 — 匯出資源 → 導入 Godot → 手工搭 UI
2. AI 流程 — 用 VberAI AI Studio（簡稱 AI Studio）把 Figma 結構變成可掛場景的階層，再按需配合 Godot MCP 迭代

按「每一螢幕該用哪條」來選，而不是所有面板走同一套管道。

Figma → Godot「做完」的標準是什麼

只出現貼圖不算完成。你需要：

• 節點樹能對應有意義的 Figma Frame（頂欄、列表、底欄）
• 佈局在 16:9、9:16 與視窗化桌面下不必逐層手擰間距
• 字型與主題 token 接近設計體系
• Figma 改版時不必整景重做

兩條路徑都能做到「完成」，差別在 首螢幕可玩 UI 的時間，以及 下一次設計改版的成本。

手動流程：匯出、導入、重建

常見步驟

1. 在 Figma 標記可匯出項（圖示、九宮格面板、全幅背景）
2. 按 1x / 2x 匯出 PNG/SVG，並記錄縮放約定
3. 資源放入 res://ui/（或團隊 Art 目錄）
4. 在 CanvasLayer 或 UI 場景下建 Control 根節點
5. 用 HBoxContainer / VBoxContainer / GridContainer 巢狀直到間距貼近稿面
6. 配 Theme 字型、顏色、StyleBox；用 GDScript 或 C# 接按鈕訊號

手工仍然更合適的場景

情況	為什麼適合手搭
一次性原型介面	比引入新工具更快
強執行時期 UI（庫存與資料綁定）	結構主要歸程式碼管
嚴格的 StyleBox / 主題規範	設計出像素，工程師管主題
UI 面積極小（僅暫停遮罩）	任何管道的啟動成本都不划算

團隊常低估的成本

• 重排稅 — Figma Auto Layout ≠ Godot 容器；每一層巢狀都是主觀判斷
• 字型漂移 — Figma 的 Inter ≠ 你的 DynamicFont / Theme；行高與字距常在 QA 才暴露
• 九宮格翻車 — 按鈕拉伸縫，往往要到週中才重切
• 改版循環 — 設計把底欄挪 12px，程式可能要動半棵樹

中等複雜度的主選單，從乾淨 Figma Frame 到冒煙過的 Godot 場景，許多團隊仍要 45–120 分鐘——還沒算訊號與本地化。

用 AI Studio 的 AI 流程：保留結構的導入

常見步驟

1. 整理 Figma：Frame 命名清晰（HUD_Root、Btn_Play、Panel_Shop），避免匿名 Frame 128
2. 開啟 VberAI 上的 VberAI AI Studio（AI Studio）
3. 導入目標 Frame（或 Studio 管道支援的匯出包）
4. 在畫布預覽圖層；隱藏草稿 Frame，合併干擾層
5. 目標引擎設為 Godot，輸出 Control 階層 / 可掛場景節點（不要只丟散圖）
6. 導入 Godot 專案；開啟產生場景掛到 UI 根下
7. 冒煙測多種寬高比；在引擎內修補主題字型與訊號

AI Studio 會保留 Frame 結構，而不是給你一張必須反向拆成容器的圖集。

AI 路徑更合適的場景

情況	為什麼 AI Studio 有幫助
多螢幕 UI 套件（設定、商店、暫停、HUD）	命名與結構遷移能攤薄一次性成本
遠端設計師頻繁改 Figma	再導入勝過花小時重搭盒子
團隊已用 VberAI 的 Godot MCP	同一棧：設計進、編輯器代理後續
帶新人認識 UI 場景	產生樹是可講的起點

可選下一步：有了 Godot MCP，可在 Cursor / Claude 裡批次重新命名節點、綁定 pressed、換貼圖——尤其 Figma 層名仍亂時。

並排對比

維度	手動	AI Studio → Godot
首螢幕可玩佈局時間	每螢幕 45–120+ 分鐘	Figma 規範後通常分鐘級
巢狀保真度	看工程師紀律	有命名 Frame 時貼近稿面
Theme / StyleBox 掌控	最高（全自寫）	引擎內輕度打磨後足夠強
佈局級改版成本	高	再導入更低
僅換色 / 換圖示	低–中	常直接在 Godot 改、不必重導
工具開銷	只有 Figma + Godot	需 VberAI 帳號與 AI Studio 習慣
最適配	稀少 UI、原型、偏程式碼 UX	反覆出現的選單 / HUD 管線

兩條路都少不了引擎打磨：按鈕仍要訊號，本地化仍要字串鍵，Godot 主題仍要過一遍。差別在於工程時間花在 重造佈局，還是花在 接線與手感。

大多數量產團隊採用的混合模式

1. 殼層介面（主選單、設定外框、商店殼）走 AI Studio
2. 庫存 / 任務等動態列表仍用手工或指令碼產生
3. Figma 對 佈局殼 負責；Godot 對 行為 負責
4. Frame 結構變了就再導入；微視覺在 Godot 裡改

Figma 變更	建議
新頁籤行 / 列重排	經 AI Studio 再導入
換圖示、按鈕色	在 Godot 改場景 / 主題
新畫板整螢幕	新導入 → 新 .tscn
文案 / 多語言	Godot + 翻譯檔案

與 VberAI 產品棧的關係

• VberAI AI Studio — Figma / PSD → Godot Control 結構（標題與標題欄用 AI Studio 承接搜尋）
• Godot MCP — 導入後的編輯器自動化（重新命名、掛鉤訊號、場景檢查）
• AI Super Matting — 圖示層變成 TextureRect 前做乾淨透明摳圖

三者把「設計稿 → 可玩」縮短，又不逼美術離開 Figma。

結語：該選哪條？

選 手動：只有一兩個小螢幕、互動高度程式碼化，或不想引入共享導入習慣。

選 AI Studio：Figma 裡已有多 Frame UI 套件、設計週更迭，且需要與 Frame 名對應的 Godot 場景——而不是一堆 PNG。

成長中的 Godot 團隊多半落在混合：AI Studio 管殼，手搓管即時資料檢視。

想在同一螢幕上計時對比？開啟 VberAI AI Studio，導入命名規範的 Figma 選單 Frame，匯出 Godot Control 階層，再對照你上次手工重建的耗時。