vibegame

Godot AI 美術流程：盯住批次化處理，以及生成和程式碼之間的同步

2026-09-10T16:45:00+08:00

先說結論

目前常見的 Godot ai 美術流程 是這樣的：提示詞出圖，去掉背景，切成精靈圖，把 PNG 放進 Godot 的 res://，再設 Nearest，掛到 AnimatedSprite2D 或 Control 上。但實事求是地講，這套邏輯已經過時了——如果你當前已經在高頻呼叫 Cursor、Claude Code、Codex 這類工具的話。如何在整套工作流中針對批次化處理美術素材，以及處理好批次化生成與程式碼邏輯之間的同步問題，才是目前的開發流程應該關注的地方。

常見流程還停在五步

常見寫法會這樣排：先寫提示詞，用影像模型畫出角色、場景或介面。再去背景、修邊、統一尺寸。然後按格子切成精靈圖，再起名字。接著把檔案拖進 Godot 工程。最後在編輯器裡設過濾方式，把圖掛到節點上，用指令碼播放動畫或響應點選。

是的，這已經是上世紀的做法了，叔叔。Godot 官方教程裡，AnimatedSprite2D 和 SpriteFrames 也確實還是這樣吃一張格子圖。社群裡從 Figma 進 Godot，常見的也是 Exporter 加 Importer，走一遍就算完成。

已經在高頻呼叫編碼工具時，缺的是批次處理，以及圖層上下文能不能跟著走。節日要換一套介面時，原來掛好的節點往往對不上。用 AI 再生成一版主題時，也是同樣的問題。一張 PNG 拖進 res://，程式設計工具讀到的是檔名，讀不到這塊是不是按鈕。

生成之後還要盯住這三步

AI 生成的平面圖還需要大量的自動化處理，才能和節點樹匹配。 影像模型給出的是一張合成圖。HUD、按鈕、血條疊在同一張點陣圖上。進 Godot 之後，整屏當一張 Sprite，或靠人一格一格切，都還沒完。如果還在依賴手工為每張切好的圖片重新命名，或者直接拿著自動化指令碼切圖生成的 Part 26，那真的是在給後續的 AI 程式設計增加過多的無效上下文。

一次一張，撐不起後面的改動。 提示詞可以再跑一遍，得到的是另一張新圖。圖層關係、尺寸、哪一塊能點，不會自動帶到下一張上。萬聖節要換皮時，常見流程裡的「再匯出一次 PNG」會把接線重做一遍。情人節要再出一套時，也是同樣的缺口。

大量無組織、無結構的切圖檔案，和程式工程之間的即時對映，是需要重視的一環。 通過 MCP，開啟的 Godot 可以接到 Cursor 上，當前場景和指令碼可以讀。前提是切圖已經按引擎目錄寫進去，節點還叫原來的名字。Figma to Godot 的匯入是單向的已經寫過：只走一遍的 Exporter 或 Importer，覆蓋不到重新生成。Godot AI 美術流程裡，同一段缺口出現在出圖之後。

我已經走通且在實踐的方式：把省下的時間轉到玩法策劃上

把生成之後的處理放到 VberAI Studio 裡做完，再匯入到 Godot 中。切圖、命名、按目錄匯出不再佔掉整天，省下的時間可以轉到真正的玩法策劃上。

介面如果還是一張平面 PNG，在畫板上選中這一屏，開啟重疊圖層選單，跑 Auto-Layering（自動分層）。按檢測邊緣切圖，匯出有意義命名的圖片檔案。步驟見自動分層：圖片轉多圖層。需要 Photoshop 檔案時，同一套圖層可以 PNG 到 PSD，再 PSD 到 Godot。

已經是格子精靈圖、塊與塊之間空隙清楚時，用 Auto Split。本機切成單張。名字會帶序號，進引擎前仍要改成能讀的名字。說明見自動切圖。

節日要換一套視覺時，不要另外匯出一套對不上原來名字的圖。選中已分層的畫板，跑 AI Reskin（換皮膚）。圖層關係和尺寸仍一一對應，再匯出一輪即可。說明見 AI 換皮膚。

原始檔如果在 Figma，用 Import Project（匯入專案） 讀入 .fig，再 Export to Godot。匯出得到 .tscn，預設路徑按 Godot 的 Assets 目錄來寫。步驟見 Figma 到 Godot。設計稿要改，回到 VberAI Studio 再匯出一輪，工程裡的節點還能對上原來的圖層結構。

程式碼這一邊，通過 Godot MCP，把當前開啟的場景和指令碼交給程式設計工具。美術資源同步和程式碼邏輯同步要一起做。只把 PNG 丟進 res://，會停在「圖已經在工程裡」；節點名字和圖層上下文不在，後續的 AI 程式設計仍對不上事件。

去背景這一步，遊戲介面不要用照片摳圖工具硬切 HUD。VberAI Studio 裡的 AI 去背景對準的是保留按鈕和條，去掉場景底。

小結

別再信任 AI 告訴你的標準流程，尤其是在 AI 已經鋪開的現在。提前考慮如何排程和同步多個 AI 生成源頭之後的資料，這將會直接拉開差距。

Figma 到 Godot 的匯入工具是單向的：MCP 和可重新生成的美術同步需要另一套流程

2026-09-10T16:00:00+08:00

先說結論

從 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 編碼工具已經成為主流。是時候重新調整工作流，讓資源的生成和到引擎的對映做到更高程度的同步。

Cocos Creator 2.x MCP

2026-09-09T15:14:00+08:00

先說結論：3個步驟

Cocos Creator 2.x MCP 用在已經開啟的 Cocos Creator 2.4.x 工程上，讓 AI 程式設計工具看見並操作編輯器。3.8.6+ 工程改走 Cocos Creator 3.x MCP。從 Cocos Creator 2.x MCP 下載。通道本身怎麼工作，見 MCP 怎樣把 AI 程式設計工具接到遊戲引擎上。

步驟 1：開啟 CocosCreator2.x MCP Server

從官網安裝後，開啟 CocosCreator2.x MCP Server。視窗若要求登入，先登入。Cocos Creator 2.x 保持開啟，工程就是當前這份。

步驟 2：確認 Running，用一鍵配置

在 Server（服務） 頁，Status（狀態） 應顯示 Running（執行中）。這個窗口裡預設埠是 4000。MCP URL 是 http://127.0.0.1:4000/mcp。主流程式設計工具用 One-Click Configuration（一鍵配置）。

另外兩頁是 Tool Management（工具管理） 和 Quick Config（快捷配置）。傳輸方式是 Streamable HTTP（MCP 2025-03-26）。

步驟 3：把 AI 程式設計工具接上

走完 One-Click Configuration（一鍵配置）。寫程式碼時要通過 MCP 讓程式設計工具跟工程對話，Cocos Creator 和 MCP 服務都要開著。

版本、工具列表和授權：vberai.com/game-engines/cocos2x。

Cocos Creator 3.x MCP

2026-09-09T15:14:00+08:00

先說結論：3個步驟

Cocos Creator 3.x MCP 用在已經開啟的 Cocos Creator 3.8.6+ 工程上：讓 AI 程式設計工具看見並操作場景、節點、預製體，而不只是在文本里補全程式碼。從 Cocos Creator MCP 下載。2.4.x 工程改走 Cocos Creator 2.x MCP。通道本身怎麼工作，見 MCP 怎樣把 AI 程式設計工具接到遊戲引擎上。

步驟 1：開啟 Cocos Creator MCP Server

從官網安裝後，開啟 Cocos Creator MCP Server。視窗若要求登入，先登入。Cocos Creator 3.x 保持開啟，工程就是當前這份。

步驟 2：確認 Running，用一鍵配置

在 Server（服務） 頁，Status（狀態） 應顯示 Running（執行中）。這個窗口裡預設埠是 3000。MCP URL 是 http://127.0.0.1:3000/mcp。主流程式設計工具用 One-Click Configuration（一鍵配置）。

另外兩頁是 Tool Management（工具管理） 和 Quick Config（快捷配置）。傳輸方式是 Streamable HTTP（MCP 2025-03-26）。

步驟 3：把 AI 程式設計工具接上

走完 One-Click Configuration（一鍵配置）。寫程式碼時要通過 MCP 讓程式設計工具跟工程對話，Cocos Creator 和 MCP 服務都要開著。

版本、工具列表和授權：vberai.com/game-engines/cocos。

Godot MCP

2026-09-09T15:14:00+08:00

先說結論：3個步驟

Godot MCP 用在已經開啟的 Godot 4 工程上：讓 AI 程式設計工具看見並操作場景、節點、指令碼，而不只是在文本里補全程式碼。從 Godot MCP 下載。通道本身怎麼工作，見 MCP 怎樣把 AI 程式設計工具接到遊戲引擎上。

步驟 1：開啟 Godot MCP Server

從官網安裝後，開啟 Godot MCP Server。視窗若要求登入，先登入。Godot 4 保持開啟，工程就是當前這份。

步驟 2：確認 Running，用一鍵配置

在 Server（服務） 頁，Status（狀態） 應顯示 Running（執行中）。這個窗口裡預設埠是 2000。Endpoint（介面） 是 http://127.0.0.1:2000/mcp。主流程式設計工具用 One-Click Configuration（一鍵配置）。

這一頁上有 Start（啟動） / Stop（停止）。另外兩頁是 Tools（工具） 和 Setup（設定）。傳輸方式是 Streamable HTTP（MCP 2025-03-26）。

步驟 3：把 AI 程式設計工具接上

走完 One-Click Configuration（一鍵配置）。寫程式碼時要通過 MCP 讓程式設計工具跟工程對話，Godot 和 MCP 服務都要開著。

版本、工具列表和安裝包：vberai.com/game-engines/godot。

Unity MCP

2026-09-09T15:14:00+08:00

先說結論：3個步驟

Unity MCP 用在已經開啟的 Unity 工程上：讓 AI 程式設計工具看見並操作場景、遊戲物件、預製體，而不只是在文本里補全程式碼。從 Unity MCP 下載。通道本身怎麼工作，見 MCP 怎樣把 AI 程式設計工具接到遊戲引擎上。

步驟 1：開啟 Unity MCP Server

從官網安裝後，開啟 Unity MCP Server。視窗若要求登入，先登入。Unity 編輯器保持開啟，工程就是當前這份。

步驟 2：確認 Running，用一鍵配置

Server Status（服務狀態） 應顯示 Running（執行中）。這個窗口裡預設埠是 6594。Endpoint URL（介面地址） 是 http://127.0.0.1:6594/mcp。主流程式設計工具用 One-Click Configuration（一鍵配置）。

傳輸方式是 Streamable HTTP（MCP 2025-03-26）。狀態旁邊是 Stop Server（停止伺服器）。

步驟 3：把 AI 程式設計工具接上

走完 One-Click Configuration（一鍵配置）。寫程式碼時要通過 MCP 讓程式設計工具跟工程對話，Unity 和 MCP 服務都要開著。

版本、工具列表和授權：vberai.com/game-engines/unity。

MCP 怎樣把 AI 程式設計工具接到遊戲引擎上

2026-09-09T15:14:00+08:00

先說結論：3個步驟

遊戲開發的場景中，如果不熟悉切圖和相關的邏輯，很容易就會煩躁。AI 程式設計工具能寫程式碼，但預設看不見引擎裡那棵節點樹，也不知道一張帶名字的切圖該掛在哪個按鈕上。

MCP（Model Context Protocol）相當於在 AI 程式設計工具和遊戲引擎之間，專門架起一條通訊方式。切圖如果已經按引擎目錄匯出、名字也對得上，就不必再口頭告訴程式設計工具「這張圖放到什麼位置」。它通過 MCP 讀取當前開啟的工程。

步驟 1：真正煩的是切圖放哪，不是圖本身

磁碟上的一張 PNG 還不是遊戲 UI。程式設計工具仍要弄清哪個節點是攻擊按鈕、哪個目錄是 Assets/Textures、哪份預製體已經搭好佈局。靠對話一張張貼截圖來解釋，會很慢。

自動分層：圖片轉多圖層匯出有意義命名的圖片檔案，再加上按引擎目錄匯出（例如 Figma 到 Unity），已經能回答前半段。MCP 回答後半段：當前開啟的編輯器，而不是桌面上的壓縮包。

步驟 2：MCP 在本地跑一個服務

每個引擎的 MCP 都是編輯器旁邊的一個小視窗。Server Status（服務狀態） 應顯示 Running（執行中）。程式設計工具連的是本機地址，例如 Unity MCP 上的 http://127.0.0.1:6594/mcp。

目前 VberAI Studio 裡的 MCP 工具都支援 One-Click Configuration（一鍵配置）。裝好之後，主流程式設計工具都可以一鍵配上。一鍵配置之後，寫程式碼時要通過 MCP 讓程式設計工具跟工程對話，引擎和 MCP 服務都要開著。

步驟 3：用一鍵配置接上程式設計工具，再開啟對應引擎的頁面

Cursor、Codex、Claude Desktop 一類主流程式設計工具，用一鍵配置接上即可。通道通了之後，當前場景、層級、帶名字的資源，都走 MCP，而不必再往對話裡貼截圖。

同一套邏輯，換一個引擎視窗——例如在 Godot MCP 中，用埠 2000，地址是 http://127.0.0.1:2000/mcp：

已經開啟哪個引擎，就進哪一頁：

從圖片到多圖層：如何把角色圖拆成圖層，加快遊戲資源準備

2026-09-09T13:39:00+08:00

先說結論

轉換系列剛補完 Figma 到 Unity、PNG 到 PSD，Godot 和 Cocos Creator 那幾條也重寫過。連著看下來，感受很清楚：image-to-layers 已經簡單。把一張 PNG 拆成圖層不難；按原來的位置和互動資訊，把這些圖層復原到遊戲引擎中，才是後面要盯住的問題。

現在能用的答案，不只是多一個拆圖按鈕。垂直方向的工具要把圖層的名字、位置、互動這些上下文一直帶著走。Docs 裡已經寫開的是：自動分層：圖片轉多圖層、Figma 到 Unity、AI圖片翻譯、AI 換皮膚。

拆圖層已經不難

把一張 PNG 拆成不同的圖層，現在已經簡單。當前的 AI 分層基本上都能切開，也能補上邊緣和被擋住的部位。

除了 VberAI Studio 裡的自動分層：圖片轉多圖層，市面上還有不少工具可以一鍵拆圖。拆開之後如何接著處理，才是大問題：原來的位置還在不在，按鈕還是不是按鈕，匯入到引擎中能不能按原樣復原。

匯入到引擎，原圖層的上下文資訊都要保留和同步

Figma 到 Unity 在自動分層之後，按 Assets 目錄匯出：Prefabs 是組裝好的介面，Textures 是切圖。圖層的名字、位置、疊放順序、哪一塊能點，這些上下文都要跟著走。少了任何一項，Codex 和 Unity MCP 都對不上節點，匯入到引擎中的就只是一堆圖。

Photoshop 年代那些經驗——面板做九宮格、字不要畫進圖、匯出前先排完按鈕狀態——仍然在說引擎裡的真實工作。它們不再是準備遊戲資源的起步條件。Figma 到 Unity 那篇 Exp 已經寫過：舊準則裡至少有一半不再卡住進度。

垂直化的工具價值在於持續的共同上下文共享機制

自動分層：圖片轉多圖層按檢測邊緣切圖，匯出有意義命名的圖片檔案。Figma 到 Unity 或 PSD 到 Unity 把同一套圖層匯入到 Unity 工程目錄中。AI圖片翻譯換字，AI 換皮膚換外觀，圖層關係和尺寸仍一一對應。

這幾項能連著跑，靠的是同一套圖層上下文沒有在中途斷掉。單獨拆圖層做得到切圖，帶不走後面的名字、位置和互動。

小結

上下文共享的前提下，做批次化的遊戲 UI 拆圖才更有開發環境中的基本可用性。

Figma 到 Unity：AI First 之後，不必把介面手動處理流程作為最大時間成本項來考慮了

2026-09-09T13:12:00+08:00

先說結論

在本站釋出了 Figma 到 Unity 的流程之後可以看出來：在 AI 急劇衝擊舊有遊戲開發流程的大背景下，即便是 2026 年 5 月 Saharukh 那篇 Figma to Unity 裡列出的黃金準則，現在至少有一半不再卡住開發進度。從 AI First 的角度看，這只是讓一切能自動化的流程都更加自動化，效率跟著上來。

當前站點的所有教程和已經釋出的文章，都圍著 AI First 的核心邏輯：不先把遊戲引擎學透，而是結合已經能用的 AI 能力，回到做遊戲本身的樂趣。現在已經走通的工具鏈組合是：

Codex：負責編碼
VberAI Studio：負責美術資源的批次化生成和處理
Unity MCP：負責在編碼工具和遊戲引擎之間同步
Unity：最後驗證、測試，整理成完整的遊戲工程

原文還在堅持的細節有一半都已經失效

先詳細羅列原文裡的經驗都有哪些，後面會一一對應。

設計稿在 Figma 裡好看，不等於遊戲裡能用。 原文的說法是：介面要會動、要響應、要能縮放、要有多種狀態、要能在不同裝置上跑、還要在即時引擎裡扛得住效能。所以 Figma 到 Unity 不能當成「匯出一張圖就結束」。

Figma 是圖紙，Unity 是工地。 進到 Unity 之後才會冒出這些具體問題：按鈕能不能點、指標懸停時怎樣、停用時怎樣、換一種語言字會不會擠爆、彈窗在手機和電腦上是否都合適、動畫順不順、介面會不會把幀率拖垮。

一個按鈕不是一張矩形加一行字。 原文列過一整串：普通、懸停、按下、停用、選中、手柄焦點、音效、點選動畫、本地化、自適應縮放、可能的光效，以及接到玩法程式碼上的事件。所以「把按鈕從 Figma 匯出去」聽起來輕，做到工程裡並不輕。

匯出切圖只是其中一小段。 還要事先決定：哪些做成圖片、哪些直接在 Unity 裡搭、哪些做成可複用的預製體、哪些要做九宮格拉伸、哪些要動畫、哪些要著色器、哪些要本地化、哪些要同時應付鍵盤、滑鼠、觸控和手柄。

不要把整屏都匯出成一張圖。 原文點名的壞例子包括：整屏、帶文字的按鈕、固定尺寸的面板、用多張靜圖拼進度條、把文案烤進 PNG。文案一旦進圖，翻譯就很難改；整塊面板不好縮放；靜圖進度條沒法平滑填充；每屏一張大圖又重又難改。更好的拆法是：文字留在 Unity 裡當真正的文字，按鈕做成可複用元件，面板多用九宮格，進度條用填充圖或著色器，圖示匯出成精靈圖，重複件做成預製體。

命名在專案變大之前看起來無聊。 Rectangle 124、Group 56、Icon copy 9、Frame 32 進工程之後，開發或技術美術只能猜。原文給的好名字是 btn_primary_bg、icon_currency_gold、panel_shop_base、hud_health_fill、popup_reward_frame、img_avatar_border_rare。

按元件想，不要只按整屏想。 商店這一屏拆開：頂欄、貨幣條、商品卡、購買按鈕、滾動區、分類頁籤、確認彈窗。Figma 裡是可複用元件，Unity 裡是可複用預製體，例如 Shop Item Card 對上 PF_ShopItemCard，裡面再放圖示、名稱、價格、稀有框、購買按鈕、鎖定 / 選中 / 懸停。

Figma 的排版不等於 Unity 的排版。 同一套介面可能要面對手機、平板、電腦、超寬屏、劉海和安全區、不同語言、不同輸入方式。實現時要考慮錨點、縮放、安全區、佈局組和可伸縮間距。介面不能像一張貼紙，只貼在一個解析度上。

動畫不要留到最後。 彈窗淡入、按鈕略微縮放、血條閃一下、獎勵圖示發光、報錯時抖一下——這些是在告訴玩家發生了什麼。不早做，後面會和佈局、節奏、效能、玩法流程打架。

介面也會吃效能。 半透明疊層、大貼圖、模糊、遮罩、粒子、會動的圖示、沒整理過的畫布、過多零散精靈圖、頻繁重建佈局。高階電腦上不明顯，手機上會變成真問題。

原文給的十條製作流程： 整理 Figma 檔案 → 標出可複用元件 → 決定匯出什麼 → 按尺寸和透明區域準備資源 → 匯入 Unity 並設貼圖、壓縮、圖集 → 做預製體 → 補狀態 → 加動畫和反饋 → 在多種螢幕上試 → 儘早看繪製次數、視訊記憶體、過度繪製和畫布重建。

原文要避開的失誤： 整屏匯出成圖、文案烤進精靈圖、不管按鈕狀態、只按一個解析度設計、圖層亂起名、忘記本地化、不管手柄或觸控、獨特資源太多、不做圖集、動畫太晚、不管安全區、效能留到最後才看。

介面技術美術 被寫成設計和工程之間的人：準備資源、搭預製體、做著色器、做動畫、最佳化效能、做可複用元件、適配解析度，一邊讓設計師看見引擎限制，一邊讓開發保住畫面。職責被概括成：保護設計，讓它在製作過程裡還能活下來。

以上這些，在「先有人、再有工具」的年代裡，每一條都花時間。

對照：AI First 之後，哪些還成立，哪些不再是中心

首頁寫得很直：用接近 Figma 的互動組織美術資源，再用引擎 MCP 做密集協同，把原來靠人力的環節拆開。對照原文，可以先看成一張表。

原文還在強調的工作	AI First 之後還成不成立
設計稿好看不等於遊戲裡能用	仍成立。能點、能縮放、能換語言，最後都要在 Unity 裡驗證。
匯出切圖不是全部	仍成立，但中心變了。缺的不再是人親手決定每一塊怎麼切，而是檔案能不能按引擎目錄匯出，讓 Codex 讀得懂。
不要整屏匯出、不要把文案烤進圖	仍成立。本地化那篇已經寫過：字烤進圖，後面只能整張重做。
`Rectangle 124` 這類名字進工程會亂	仍成立。自動分層就是在按檢測邊緣切圖，匯出有意義命名的圖片檔案；名字亂，後面的預製體和指令碼也對不齊。
按鈕要有懸停、按下、停用、手柄焦點、音效、事件	一半成立。這些狀態和事件仍然要在 Unity 裡出現；但不必須先由介面技術美術在匯入前用手搭完。Codex 加 Unity MCP 可以在預製體落地之後補。
九宮格、著色器、圖集、畫布重建	一半成立。手機專案裡這些仍會爆。AI First 的順序是：先讓介面進工程能跑，再讓 Codex 對著開啟的編輯器去查、去改，而不是先把這些當成入門門檻。
按元件做成預製體	仍成立，而且已經被匯出這一步接住了一部分。Figma 到 Unity 裡，選 Prefab（`.prefab`）再解壓，`Assets/Prefabs` 是組裝好的介面，`Assets/Textures` 是切圖。
動畫和效能必須編進「匯出之前的流程」	不再是中心。原文把動畫和效能寫成製作流程的第 8、第 10 步，好像不排進計劃就不能匯出。現在更常見的是：先匯出能用的預製體，再在 Unity 裡用 Codex 和 Unity MCP 補運動和開銷。
必須有一位介面技術美術守在中間	對沒有遊戲開發背景的人，這條最先失去作用。首頁的前提就是不必先精通引擎。守門人改成：VberAI Studio 負責把稿整理成引擎目錄，Unity MCP 把當前場景和指令碼交給 Codex。

所以「不必把介面手動處理流程作為最大時間成本項來考慮了」。介面仍然要做對：不要再把原文那十條靠人一點點處理的流程，當成 Figma 到 Unity 的入場券。

現在這套組合實際改了哪一段

VberAI Studio 對準的是原文裡最耗人的前半段：整理圖層、起能用的名字、決定切哪些圖、按 Unity 的 Assets 目錄匯出。.fig 用 Import Project（匯入專案） 進來，再跑自動分層，最後 Export to Unity。這一步覆蓋的是「檔案如何結構化地匯出到 Unity 工程資料夾中」，覆蓋不到懸停態、本地化字號、粒子好不好看——這些原文後半段，本來就不該假設設計工具一次做完。

Unity 仍是驗證發生的地方。預製體拖進場景之後，原文問過的那些問題還在：能不能點、換語言會不會擠、劉海會不會擋、會不會掉幀。

Unity MCP 對準的是 MCP 能做、設計工具做不了的那一段：把當前場景、層級和指令碼同步給 AI 工具。Figma 加 Cursor 之後，設計稿怎麼進 Godot 已經寫過類似分工：MCP 負責開發和場景上下文；設計工具繼續改稿，需要時按引擎目錄匯出。Unity 這邊同一套邏輯。

Codex 對準的是原文留給「介面技術美術 / 程式」的接線：給按鈕掛事件、補幾種狀態、把文字留成可翻譯的文本、按不同解析度試一次。首頁的身份是設計師兼會寫基礎程式碼的產品經理，不是引擎專家；這些接線如果還要求先手寫完一套介面框架，AI First 就走不下去。

四件套串起來，原來的開發模式變成：

用 AI 生成工具先做出遊戲 UI 截圖，再到 Figma 裡簡單處理邊緣情況和需要修補的地方。
在 VberAI Studio 裡匯入、自動分層、匯出 Unity 的 Assets（預製體 + 切圖）。
在開啟的 Unity 工程裡，用 Unity MCP 讓 Codex 看見當前介面層級。
用 Codex 補互動、狀態和基本適配；稿要改，回到 VberAI Studio 再匯出一輪，而不是在引擎裡手改貼圖名字。

原文裡的介面技術美術，保護的是「設計在製作過程裡別被做丟」。現在保護設計的方式變了：圖層和名字在匯出時就對齊，後面的判斷交給人看結果，具體操作交給 Codex 在引擎裡改。

或許把任何文字資訊都畫進圖層裡——這種現在看起來蠢笨的做法，以後也不一定還是問題，只要 AI 自動生成和自動標註的成本、便利性，已經壓過以往整套手改的總成本。

小結

AI 能力在快速吞噬著原有遊戲開發裡那些還沒自動化的流程。
VberAI Studio 幾乎是沿著遊戲開發這條垂直方向，用 AI First 又迭代了一層。這類工具遲早會更大規模地加快遊戲開發。
沒有被這套組合自動吃掉的空間，會在未來變得急劇縮小。

Figma 到 Unity

2026-09-09T11:20:00+08:00

先說結論：6個步驟

Figma 到 Unity 的主要邏輯是：針對已經分層的 .fig 檔案 UI / HUD，要批次化處理好美術素材後，匯入到 Unity 中。VberAI Studio 用 Import Project（匯入專案） 匯入這份檔案，再跑自動分層：檢測邊緣切圖，匯出有意義命名的圖片檔案，然後選 Export to Unity。

已經是分層的 Photoshop 檔案：PSD 到 Unity。

步驟 1：存一份本地 `.fig`

在 Figma 中開啟選單：File（檔案）→ Save Local Copy（儲存本地備份）。已經命名的編組（畫框、按鈕、HUD 條）會帶到 VberAI Studio。

步驟 2：在 VberAI Studio 裡 Import Project

在 VberAI Studio 的專案頁，選 Import Project（匯入專案），選擇剛剛匯出的 Figma 的 .fig 檔案。

步驟 3：自動分層

選中畫板（例如 cat_journey_UI）。在選中後的工具欄裡開啟重疊圖層，選 Auto-Layering（自動分層）。

對話方塊是 Run AI auto-layering?，再點 Start layering。

帶名字的邊界會出現在圖上，這意味著分層切分的圖片都處理好了。關於這一步驟的詳細說明可以參考自動分層。

步驟 4：匯出到 Unity

保持已分層的畫板選中（這裡是 cat_journey_UI_layer）。開啟 Export，選 Export to Unity。

步驟 5：選擇匯出到 Unity 的形式

匯出到 Unity 時，可以選匯出形式。對話方塊裡 Target engine 是 Unity；格式可以選 Prefab（.prefab）。Export to 可以選 ZIP 壓縮包，或直接寫到目標工程。Default paths 會按引擎預設目錄來放檔案。

步驟 6：檢查匯出結果

這次選的是 ZIP 壓縮包。解壓後是 Assets 總資料夾：Prefabs 裡是 Unity 可用的 .prefab（組裝好的介面，可以拖進場景）；Textures 裡是具體的切圖檔案（按圖層起好名的 PNG）。

PSD 到 Unity

2026-09-09T11:20:00+08:00

先說結論：6個步驟

PSD 到 Unity 的主要邏輯是：針對已經分層的 Photoshop 檔案（PSD 或 PSB），要批次化處理好美術素材後，匯入到 Unity 中。VberAI Studio 匯入這份設計稿，再跑自動分層：檢測邊緣切圖，匯出有意義命名的圖片檔案，然後選 Export to Unity。

已經是 .fig 檔案：Figma 到 Unity。還是一張扁平 PNG、需要先分層：PNG 到 PSD。

步驟 1：開啟分層 PSD

編組要有名字（畫框、按鈕、HUD 條）。這些名字會帶到 VberAI Studio。

步驟 2：在 VberAI Studio 裡匯入 PSD/PSB

在 VberAI Studio 選 Import → PSD/PSB（匯入 PSD/PSB）。

步驟 3：自動分層

選中畫板（例如 cat_journey_UI）。在選中後的工具欄裡開啟重疊圖層，選 Auto-Layering（自動分層）。

對話方塊是 Run AI auto-layering?，再點 Start layering。

帶名字的邊界會出現在圖上，這意味著分層切分的圖片都處理好了。關於這一步驟的詳細說明可以參考自動分層。

步驟 4：匯出到 Unity

保持已分層的畫板選中（這裡是 cat_journey_UI_layer）。開啟 Export，選 Export to Unity。

步驟 5：選擇匯出到 Unity 的形式

步驟 6：檢查匯出結果

PSD 到 Godot

2026-09-08T18:40:00+08:00

先說結論：3個步驟

PSD 到 Godot 的主要邏輯是：針對已經分層的 Photoshop 檔案（PSD 或 PSB），要批次化處理好美術素材後，匯入到 Godot 中作為場景使用。VberAI Studio 匯入這份設計稿，再匯出到 Godot。匯出得到 .tscn；預設路徑按 Godot 的 Assets 目錄來寫。

已經是 .fig 檔案：Figma 到 Godot。還是一張扁平 PNG、需要先分層：PNG 到 PSD。

步驟 1：開啟分層 PSD

編組要有名字（畫框、按鈕、HUD 條）。這些名字會帶到 VberAI Studio，並進到 Godot 的節點樹裡。

步驟 2：在 VberAI Studio 裡匯入 PSD/PSB

在 VberAI Studio 選 Import → PSD/PSB（匯入 PSD/PSB）。

步驟 3：匯出到 Godot

選中這一屏（例如 Main Screen）。開啟 Export，選 Export to Godot。

對話方塊裡把格式設成 Scene（.tscn）。Default paths 會去專案裡找 Assets 資料夾，並按這套目錄寫檔案。

演示影片

PSD/PSB 匯入，再匯出到 Godot：

PNG 到 PSD

2026-09-08T18:36:00+08:00

先說結論：3個步驟

PNG 到 PSD 的主要邏輯是：針對只有一張扁平 PNG 的遊戲 UI（HUD、整屏截圖、從來沒有分層的畫板），要先批次化處理好美術素材，再回到 Photoshop 裡改。先跑自動分層：檢測邊緣切圖，匯出有意義命名的圖片檔案，再選 Export to Photoshop PSD。匯出的 .psd 裡，這些塊是分開的圖形層和文字層。同一套步驟也適合很多張都從單張 PNG 起步的 UI。

步驟 1：自動分層

在 VberAI Studio 開啟這張 PNG，選中畫板（例如 cat_journey_UI）。在選中後的工具欄裡開啟重疊圖層，選 Auto-Layering（自動分層）。

對話方塊是 Run AI auto-layering?，再點 Start layering。

帶名字的邊界會出現在圖上，這意味著分層切分的圖片都處理好了。關於這一步驟的詳細說明可以參考自動分層。

步驟 2：匯出為 Photoshop PSD

保持已分層的畫板選中（這裡是 cat_journey_UI_layer，1536×864）。開啟 Image Export，選 Export to Photoshop PSD。

步驟 3：開啟 PSD

檔案會寫成 {name}_layer.psd，這份稿是 cat_journey_UI_layer.psd。Photoshop 裡能看到已命名的圖形層和文字層（技能格、貨幣圖示、HUD 文案），可以挪位置、隱藏或改樣式，不用再截一次屏。

要把這份檔案匯入到 Godot 中：PSD 到 Godot。

精靈圖網格切圖

2026-09-08T17:31:00+08:00

開啟一張精靈圖。能數清行列就用簡單網格；已經知道格子寬高、偏移和間距就用手動網格；透明畫素把各塊隔開時用自動檢測。

調整疊加線直到格子對齊。跳過空格子可以丟掉全透明的格。在預覽裡排除不需要的幀，再匯出單張、按行拼條或按列拼條。放大用鄰近取樣，畫素畫不會發糊。檔案只留在本機，不會上傳。

AI 去背景

2026-08-28T18:30:00+08:00

先說結論：3個步驟

AI Background Removal 用在完整的遊戲 UI / 場景板上：要清掉環境襯底，同時儘量留下 HUD、按鈕、文字條和其它介面層。介面元素的保留是這條路徑的重點——按遊戲介面幀定製；Pixian.ai、Remove.bg 一類偏照片的去背，HUD 塊經常被削邊或整塊拿掉。

開啟去背景選單，選 AI Background Removal，跑一遍，再核對場景環境是否已去掉、UI 是否還能進引擎或繼續做精靈。光暈、半透明邊要精細摳、又不走重繪時，見 AI 超精細摳圖。

步驟 1：從一張遊戲 UI 場景板開始

用環境美術和 HUD、控制元件疊在同一幀上的點陣圖——狀態列、任務卡、技能欄、虛擬搖桿都還在。

步驟 2：選 AI Background Removal

選中圖片後，開啟去背景選單，選 AI Background Removal。

步驟 3：檢查介面元素是否還在

結果去掉繪製的環境，角色、路牌、寶箱和周圍 HUD 留著。匯出前過一眼面板和圖示邊緣。

環境已去掉；HUD 和可互動 UI 還在板上。

常見問題

2026-08-26T16:00:00+08:00

VberAI Studio 要付費才能用嗎？

不訂閱也能用，只是積分消耗偏高。某幾個功能如果會經常用，後面多半會自己去充積分——幾乎每次走 AI 生成都會扣相應積分。

VberAI Studio 中如何匯入 Figma 的 .fig 檔案？

在 VberAI Studio 的專案頁，點 Import Project（匯入專案），選對應的 .fig 檔案即可匯入。

零基礎能開始做小遊戲嗎？

這個實驗還在進行。可以從本站文章裡找某條流程裡最短的走法，先看入門。

自動分層：圖片轉多圖層

2026-08-26T14:39:00+08:00

先說結論：3個步驟

本頁的圖片轉多圖層（Image to Layers）就是 Auto Layering（自動分層）：把一張合成圖拆成可單獨編輯的圖層。不用畫框：檢測邊緣切圖，匯出有意義命名的圖片檔案。和 Layer Split 在同一工具欄；目標一樣，按框定尺寸的走那一頁。

為什麼切完之後，名字、位置和互動還要跟著進引擎：從圖片到多圖層：如何把角色圖拆成圖層，加快遊戲資源準備。

步驟 1：開啟 Auto-Layering

選中畫板（例如 cat_journey_UI）。開啟重疊圖層選單，選 Auto-Layering（自動分層）。

步驟 2：確認開始分層

對話方塊是 Run AI auto-layering?，再點 Start layering。彈窗裡若仍寫 Manual Layering，對應現在的 Layer Split。

步驟 3：檢查帶名字的圖層

帶名字的邊界會出現在圖上，這意味著分層切分的圖片都處理好了。結果鋪在原圖右側。複雜的 HUD 和場景件會自動框出來。

演示影片

同樣要拆層，但手動畫框：Layer Split。圖層已經切好之後，用 PNG 到 PSD 寫成 Photoshop 檔案。同一批圖層也可以匯入到 Unity 中：Figma 到 Unity，或 PSD 到 Unity。

一鍵遊戲主題換皮：市面上已經有了針對美術資源的批次節日換皮膚工具

2026-08-20T15:00:00+08:00

VberAI Studio 的換皮膚很容易用上癮。功能說明見換皮膚。

對獨立開發和遊戲設計師來說，遊戲美術已經齊了之後，再辦一次節日活動並不輕鬆。對美術設計幾乎是一場災難。

核心工作是在舊美術上批次加上新的節日效果：萬聖節要一套節日主題圖示；情人節會湧出大量表達愛意的視覺元素。專案階段改變不了這一點。有持續運營時，美術和開發總會在那些日子之前進排期，節日內容先做好上線準備，日期到了再放出來。

更核心的是批次、並且提示詞要一致。

換皮膚就是為這個來的。生成按結構化文件提交：結構化的美術資源設定留著，只替換視覺呈現。

小結

遊戲 UI 的批次換皮膚需要批次 API 請求和返回。原來的環境引數設定非常重要。

同一點也出現在 r/aigamedev 這條討論裡：用 AI 給資源換皮膚。工作室一旦部署換皮膚，收穫是便捷的節日換皮：短時間、按指定方向生成大量資源。後面可能還有成本公式——怎樣排程，才能把生成成本壓到儘量低。眼下更穩的路，仍是讓懂排程的人去排專業的活。排程更專，要生成的量會下來，這才是生產端這一輪升級。

AI 換皮膚

2026-08-20T14:30:00+08:00

先說結論：4個步驟

AI 換皮膚 用在 VberAI Studio 裡已經做完的 UI / HUD 畫板上：要換一套氣氛，又不想手改佈局。選中畫板，開啟 AI 換皮膚，寫目標主題，這一輪會按提示詞重繪各層外觀。圖層關係和圖片尺寸仍一一對應。字的顏色常常還停在源圖上，後面需要再統一一遍標籤顏色。

步驟 1：在選中的畫板上開啟 AI 換皮膚

在 VberAI Studio 畫布上選中要換風格的那一屏（例如 Main Screen）。畫板上方浮出的選中工具欄裡，選最右側帶 AI 標記的 AI 換皮膚。

步驟 2：輸入主題提示詞

AI 換皮膚 對話方塊按描述重繪視覺風格。確認前能看到積分（這一輪大約 68–130 積分）。

提示詞示例：

Halloween-themed page atmosphere

步驟 3：檢查結果

等跑完，再看畫板。環境、面板邊框和道具會跟著主題走；畫面上的字往往還是源圖顏色，標籤後面可能要再統一一遍顏色。

步驟 4：圖層關係和尺寸

圖層關係和圖片尺寸仍一一對應。

演示影片

在選中的畫板上做 AI 換皮膚，從提示詞到一一對應的分層結果：

Figma 到 Cocos Creator，完美支援設計稿轉Prefab

2026-08-20T13:40:00+08:00

先說結論：3個步驟

Figma 到 Cocos Creator 的主要邏輯是：針對已經分層的 .fig 檔案 UI / HUD，要批次化處理好美術素材後，按設計稿轉 Prefab，匯入到 Cocos Creator 3.x 中使用。VberAI Studio 用 Import Project（匯入專案） 匯入這份檔案，再匯出到 Cocos Creator 3.x。匯出結果在 Assets 總資料夾裡：Prefabs 是組裝好的介面，Textures 是按圖層起好名的切圖。介面邏輯用 Cursor 或 Codex 補。在 Cocos Creator 裡 Build，預覽會開到本地網頁。

步驟 1：存一份本地 `.fig`

在 Figma 中開啟選單：File（檔案）→ Save Local Copy（儲存本地備份）。

步驟 2：在 VberAI Studio 裡 Import Project

在 VberAI Studio 的專案頁，選 Import Project（匯入專案），選擇剛剛匯出的 Figma 的 .fig 檔案。

步驟 3：匯出並預覽

選中這一屏（例如 Main Screen）。開啟 Export，選 Export to cocosCreator3.x。

介面邏輯用 Cursor 或 Codex 接上。在 Cocos Creator 裡 Build 工程，預覽會開到本地網頁。

匯出結果按 Assets 目錄來放：Prefabs 裡是 Cocos Creator 可用的 Prefab（組裝好的介面，可以拖進場景）；Textures 裡是具體的切圖檔案（按圖層起好名的 PNG）。

2026年9月最新操作流程指引

從 Figma 經 VberAI Studio 進到 Cocos Creator 的完整一遍：

Figma 加 Cursor 之後，設計稿怎麼進 Godot

2026-08-19T14:17:00+08:00

先說結論

Figma 負責美術設計，Cursor 負責寫程式碼。中間還缺一步：圖層還在、名字對得上、檔案儲存到 Godot 工程目錄裡，好讓 AI IDE 直接讀取。

Figma 沒有針對遊戲引擎的結構化匯出。VberAI Studio 可以當作中間環節。

缺的是什麼

只匯出一張 PNG，圖層和命名都沒了。真正需要的是：圖層還在、名字能對上、檔案已經儲存在引擎正在使用的目錄裡。

MCP 能把當前場景和指令碼同步給 AI 工具，但不會按引擎結構批次儲存美術資源。這一步還是需要在設計工具的流程中實現。

2025 年 5 月，Latenode 上有人問過同一件事：Exporting Figma designs to Godot: Current status?。當時常見做法是匯出切圖，再在 Godot 裡重新搭建介面。2026 年 5 月 Figma 出了畫布內 Agent（Fast Company），調整圖層更方便了，但是仍然沒解決掉檔案如何結構化地匯出到 Godot 工程資料夾中。兩套可以一起用：MCP 負責開發和場景上下文；設計工具繼續修改稿件，需要時按引擎目錄匯出。

.fig 這條路寫在 Figma 到 Godot。PSD/PSB 匯入是另一篇：PSD 到 Godot。VberAI Studio 匯入 PSD 時，向量圖層還不完整。同一份稿用 Import Project 匯入 .fig，更順暢，向量也能比較完整地帶進匯出。流程見這段影片：

Import Project：把 .fig 匯入 Studio，再匯出到 Godot

Studio 專案頁上的 Import Project 入口不明顯，容易錯過。

小結

要原始檔對齊、一次儲存進開發目錄，VberAI Studio 可用。配上對應的 MCP（例如 Godot MCP），可以少一輪手工整理檔案。
就算 Figma 以後自己做引擎匯出，遊戲製作仍更常要批次生成和替換；只匯出 PNG 覆蓋不到。

Figma 到 Godot

2026-08-18T17:20:00+08:00

先說結論：3個步驟

Figma 到 Godot 的主要邏輯是：針對已經分層的 .fig 檔案 UI / HUD，要批次化處理好美術素材後，匯入到 Godot 中作為場景使用。VberAI Studio 用 Import Project（匯入專案） 匯入這份檔案，再匯出到 Godot。匯出得到 .tscn；預設路徑按 Godot 的 Assets 目錄來寫。

已經是分層的 Photoshop 檔案：PSD 到 Godot。

步驟 1：存一份本地 `.fig`

在 Figma 中開啟選單：File（檔案）→ Save Local Copy（儲存本地備份）。已經命名的編組（畫框、按鈕、HUD 條）會帶到 VberAI Studio，並進到 Godot 的節點樹裡。

步驟 2：在 VberAI Studio 裡 Import Project

在 VberAI Studio 的專案頁，選 Import Project（匯入專案），選擇剛剛匯出的 Figma 的 .fig 檔案。

步驟 3：匯出到 Godot

選中這一屏（例如 Main Screen）。開啟 Export，選 Export to Godot。

對話方塊裡把格式設成 Scene（.tscn）。Default paths 會去專案裡找 Assets 資料夾，並按這套目錄寫檔案。

演示影片

Figma Import Project，再匯出到 Godot：

提升清晰度

2026-08-11T21:22:00+08:00

先說結論：3個步驟

HD Upscale 用在需要更大畫素尺寸、又能接受一點生成改寫的點陣圖上。能調的是重繪範圍、輸出格式和放大倍率；跑完會扣積分，結果作為新圖層鋪在源圖右側。密集的遊戲 UI、烤進畫面的字、小圖示網格目前仍不穩——把重繪範圍拉高，改的是樣子，很難把字標拉回清晰。

本篇演示用的源圖：商店 / 背包場景，HUD、道具格和環境疊在一張底板上。

步驟 1：在選中的圖上開啟 HD Upscale

在畫布上選中圖片。選中後的工具欄裡選 HD Upscale（AI 一組）。

步驟 2：設重繪範圍、格式和倍率

對話方塊會顯示原尺寸和預計放大後的尺寸。可調：

Redraw range — 允許重繪細節的幅度（低則結構更貼源圖；高則改寫更多）
Output format — PNG、JPG 或 WEBP
Magnification — 放大倍率（例如 ×2）

確認前能看到積分消耗。放大後的底板會作為新圖層出現在原圖右側。

步驟 3：檢查放大後的圖層

跑完後把新圖層和源圖對比。這張商店 UI 底板上，低重繪會把畫面放大，但小圖示和介面文字的邊仍然軟。

把 Redraw range 拉高（例如 0.6），這一輪會把更多算力花在重繪上。佈局和道具可能漂；字標和細的 HUD 記號往往還是糊的，或變成噪點，讀不出來。

更在意匯出尺寸變大、不太要求 UI 畫素級還原時，用 HD Upscale。背包圖示、狀態文字或畫素邊必須卡死的底板，重繪留低——或者這條先跳過，只放大那些吃得消生成細節的層。

精靈圖自動切圖

2026-07-17T18:30:00+08:00

拖入精靈表，或選擇本地圖片 / ZIP。工具在瀏覽器裡按透明通道或背景色切開每一塊，匯出 PNG，也可打包下載。檔案留在本機。

不透明圖可在設定裡指定背景色；最小尺寸用來丟掉過小的碎塊。按外形摳出會留下透明邊緣，按包圍盒則裁成矩形。

自動切圖

2026-07-17T15:13:00+08:00

先說結論：2個步驟

Auto Split 用在塊與塊之間已經有明顯空隙的精靈表上：要在本地儘快切成單獨的點陣圖。不耗積分，在本機跑；切完後每塊都可以單獨匯出，或拖到後面的步驟裡繼續處理。

命名沿用源精靈表，再加一段序號字尾。切的是幾何區域，不是模型打的標籤，所以這些名字仍是自動生成、不好讀——匯出後若要能認，再自己改名。

步驟 1：開啟 Split — Auto Split

在畫布上選中精靈表。選中後的工具欄裡開啟 Split，再選 Auto Split。

步驟 2：檢查切出來的碎圖

Auto Split 會檢出分離的區域，切成單張圖。每塊沿用精靈表的基名，再加序號字尾（例如 … Part 26），可以直接匯出，或拖到後面繼續處理。

更在意速度和積分、不太在意檔名含義時，用 Auto Split。若要好認的名字或更緊的邊界，進引擎前先改名，或改走手動切。

只在瀏覽器裡切、檔案不離開本機，可以用本地的 Sprite Auto Split Extractor。

App Store 截圖還在一張張本地化？用 VberAI Studio 批次做 Image Translate

2026-07-16T16:45:00+08:00

先說結論

Tired of localizing App Store screenshots one by one 問的是：App Store 截圖還要不要一張張本地化，有沒有工具一次做完。VberAI Studio 的 Image Translate 可以按批次處理。

獨立團隊碰到畫進截圖裡的 UI 文字，仍要按語言重新截圖，或進 Photoshop / Figma。App Store、Google Play、Steam 上架也是同一套耗時。r/SoloDevelopment 上也有一條商店頁討論：幫遊戲公司做商店頁本地化的服務商已經在流程裡跑 AI。

接下來的測試就是最好的證明。

商店宣傳圖

Frostpunk 2 Steam 商店頁的預覽圖可以作為這次本地化的測試用例。

用上面這張英文原圖，在 VberAI Studio 中選擇簡體中文生成後的效果。

文案換成了簡體中文。人物、金色邊框、價格行和右側內容格子都還在原來的位置。要整張構圖完整的商店圖，這份檔案可以用。

和把圖片直接發給主流的 ChatGPT 圖片生成、或者 Nano Banana 圖片生成不同，這裡的圖片翻譯效果更準：只重新生成文字區域，其餘畫面基本不動。看得出經過了另一套工具 Harness 處理，很適合做遊戲 UI 的本地化。

流程見 Image Translate：選中圖片 → Image Translate → 選擇語言 → 匯出同尺寸檔案。

小結

可行。在 VberAI Studio 裡，直接呼叫主流生圖模型做 AI 圖片翻譯，完全沒壓力。

演示影片

App Store 商店預覽圖的國際化，批次完成，用 AI 圖片翻譯。

AI 超精細摳圖

2026-07-16T15:10:00+08:00

先說結論：3個步驟

Super AI Matting 用在精靈或 UI 截圖上：要乾淨的透明底，又不跑影像生成。光暈、軟邊、半透明畫素的邊緣質量比較穩——做遊戲美術時，往往比通用去背服務更合適。這條路徑只做摳圖：去掉襯底，前景畫面保持原樣。

工具欄入口是 Remove background — Super AI Matting。選中圖片，跑 Super AI Matting，匯出透明結果，進引擎或繼續做精靈都可以。

步驟 1：從帶背景的精靈或場景截圖開始

用還帶著原來背景的點陣圖——角色、HUD、發光圖示和環境疊在同一幀裡。

步驟 2：選 Remove background — Super AI Matting

選中圖片後，開啟 Remove background 選單，選 Super AI Matting。

步驟 3：檢查摳圖結果

輸出去掉場景襯底，前景美術和 UI 邊緣還在。光暈和半透明區域通常比面向照片的自動摳圖更乾淨。

棋盤格襯底：背景已去掉，透明處能看見格子。

這條路徑不重繪畫素，只摳源圖裡已有的內容。遊戲精靈帶光暈、法術拖尾或軟邊圖示時，要直接進引擎、少一圈毛邊，這個差別會很明顯。

提取背景

2026-07-16T14:40:00+08:00

先說結論：3個步驟

Extract Background 用在完整的場景精靈上：要一張沒有角色、HUD、互動提示的環境底板。開啟 Extract 選單，選模型和尺寸，再生成。輸出是一張可拿去複用的背景候選，建築邊緣不必指望和原圖畫素級對齊。

Extract Background 讓模型在去掉前景角色和 UI 的前提下把場景補回來，得到一張偏背景的圖，後面做美術或關卡都能用。

步驟 1：從一張完整場景精靈開始

用環境、角色、UI 疊在一起的場景。下面這張是村莊鏡頭，NPC、HUD 和畫面上的字都還在。

步驟 2：開啟 Extract Background 並設模型

選中圖片後，開啟 Extract 選單，選 Extract Background。

在 AI Extract Background 對話方塊裡選模型（例如 GPT Image 2），設輸出尺寸和質量，再開始提取。

步驟 3：檢查乾淨背景

結果去掉角色和 UI，留下環境底板——房子、地面、樹、天空——可以當背景再用。

抽出來的背景往往對不齊源影像素。這個例子裡，建築外形和部分畫風相對原幀會漂。當成品鎖版之前，先過一眼（需要的話再輕輕修）。

AI圖片翻譯

2026-07-16T14:20:00+08:00

先說結論：3個步驟

Image Translate 用在大批已經把字烤進畫面的精靈或 UI 點陣圖上。字繼續留在圖裡也行時，這是一條比較快的本地化路徑：選目標語言，跑生成，得到同尺寸的圖——場景大體還在，標籤換成另一種語言。它走的是影像生成，不是單獨匯出文字層，版式和風格都還在畫素裡。

Image Translate 用模型生成，改寫位圖裡的字，再輸出一張同尺寸資源。第一遍不必逐條手繪標籤。

步驟 1：從一張源語言 UI 圖開始

用已經帶源語言的遊戲介面或場景精靈。下面這張是英文介面（地名、NPC 提示、招牌、背包 / 設定等字）。

步驟 2：開啟 Image Translate 並設定目標語言

選中圖片後，在工具欄開啟 Image Translate。

在 AI Image Translate 對話方塊裡選目標語言（例如日語），確認圖層，再跑 Translate。

步驟 3：檢查同尺寸的譯後圖

結果和源圖尺寸相同。畫面上的字換成目標語言（地點名、NPC 提示、商店 / 出口招牌、背包 / 設定一類）。

英文標籤換成日文；場景美術還在板上。

沒有AI輔助工具的時候，畫素精靈圖的處理和生產流程是怎麼樣的？比我想像中的麻煩多了。

2026-07-15T18:00:00+08:00

先說結論

已經有不錯的AI工具足夠處理畫素風角色動畫幀和精靈圖這件事了。為看清整條呼叫鏈怎麼串起來，使用之前熟悉的工具鏈走了一遍：參考圖生圖、摳底、對齊匯出、GIF 預覽，再到最終精靈圖。下面按步驟記錄，並標出阻力點。

測試中用到的工具

工具	作用
Grok Image	生圖快，短時間內可出多個方向備選
GPT Image 2	更慢，畫質更穩；關鍵詞或參考給對時輸出更可靠
Pixian.ai	去背景；高階版對大尺寸摳圖完整性更好
Figma	裁切、對齊、命名與整條鏈路的視覺化記錄

走查順序

整條鏈路裡，工具呼叫大致為：Grok Image ×2、GPT Image 2 ×2、Figma ×2+、Pixian.ai ×2、Ezgif ×1（合計約九次切換）。標題圖是從兩枚靜態圖示想法走到可在 Ezgif 預覽的 GIF。從想法落到可預覽動畫，耗時明顯偏長，中間還夾著返工與棄用路徑。

步驟 1：Grok Image，參考圖 + 提示詞生成畫素風原圖

用參考圖與提示詞生成畫素風格原始圖：

Two icons share the same style—one for “Documents” and the other for “Experiments”—and both employ a gamified aesthetic. The “Documents” icon depicts a scroll shimmering with magical trails of light, while the “Experiments” icon features a weapon-forging tool, symbolizing a resource honed through the fires of experience.

步驟 2：Figma，裁成獨立小圖

在 Figma 中把目標圖示裁成單獨一張小圖，便於後續序列幀生成。

步驟 3：GPT Image 2，生成序列幀

用 GPT Image 2 生成序列幀。提示詞約束有誤（要求首尾幀一致），實際只得到約 5 幀可用結果；黑底為模型輸出。

步驟 4：Pixian，移除背景

對序列幀做背景移除。

步驟 5：Figma，逐幀對齊、命名與匯出

逐幀調整上下對齊與動作幅度一致性，按順序命名並匯出。這是整條鏈路裡人工成本最高的一段。

步驟 6：ChatGPT 對話內直接試生成

在對話裡直接生成測試動畫，效果不理想，放棄該路徑。

背景為黑色，未做透明處理；遊戲場景不可直接使用。

步驟 7：Ezgif，逐幀打包為透明 GIF

用 Ezgif 逐幀合成 GIF，背景透明，便於站點或本地預覽動作。

步驟 8：引擎側目標形態，序列幀精靈圖

Godot 等引擎實際更常用一張排好的序列幀精靈圖（透明 PNG / WebP）。

阻力點

阻力點 1：步驟 5 的人工對齊成本高、結果不穩定

鏈路最大短板在步驟 5：需要手動對齊物體、壓住動作幅度跳變。AI 序列幀的幀間一致性不可預測，這一步會引入大量不確定與返工。

阻力點 2：強依賴乾淨摳底與可迭代預覽

工作流離不開兩個前置條件：

背景移除足夠乾淨，能信
能快速預覽 GIF / 動畫效果，並據此重生成或微調

缺一則後續對齊與引擎接入都會反覆卡住。

對照：主流產品形態

當前更穩的角色精靈序列幀路徑，多半會結合骨骼 / 繫結校對：在給定動作約束後再生成，幀間保證通常高於「純提示詞出多幀再手調」。

一鍵工具（見文末服務）把排程、摳底、對齊與預覽收進產品。通用工具鏈則把每一步的阻力暴露得更清楚。

提取 UI 元素

2026-07-15T17:15:00+08:00

先說結論：3個步驟

Extract UI Elements 用在一張具體的遊戲場景截圖上：調視覺模型，把 UI 抽出來拼進一張精靈點陣圖。區域數量和邊界要卡得很準時不太合適——結果是近似的，跟所選模型有關。

Extract UI Elements 對當前圖片直接調模型做 UI 提取。不用寫提示詞，介面上點完就能跑。

步驟 1：從選單選中這個功能

提取前先準備好場景或精靈截圖。下面這張是本篇演示用的源圖。

選中目標圖後，開啟提取相關選單，選提取 UI 元素。

僅作點選流程入口參考。截圖為截至 2026 年 9 月 3 日的最新產品介面。

步驟 2：設模型和引數

對話方塊裡選模型和輸出尺寸。可選 GPT Image 2、Nano Banana / Nano Banana 2、Nano Banana Pro。尺寸越大，抽出來的物件往往更多、花樣也更多。

僅作點選流程入口參考。截圖為截至 2026 年 9 月 3 日的最新產品介面。

步驟 3：看提取結果

生成後檢查拼合結果。當前輸出是一張不透明的點陣圖圖層；接到後面的步驟前，通常還要清一次。

GPT Image 2，輸出尺寸 1K。

更合適的場景：從點陣圖到精靈表

UI 更密的單張點陣圖，比上面步驟 1–3 的演示更適合 Extract UI Elements。模型從一張源圖抽出控制元件和面板，拼到一張精靈圖上；豐富度和邊界精度都高於步驟 3 那張演示結果。

源圖：一張 UI 很密的點陣圖。

輸出精靈表，GPT Image 2，輸出尺寸 1K。

用AI生成精靈圖，再針對處理成可以匯入到遊戲引擎的美術資源

2026-07-15T10:00:00+08:00

先說結論

把 AI 生成的精靈表做成可進遊戲的畫素美術，常常卡在兩類問題上：場景分類和語義角色（阻力點 1），以及把散圖整理成可進引擎的結構化資源（阻力點 2）。這兩類，VberAI 做切分、提取和清理會更省事。下文再展開其餘阻力點，以及 Cursor 式的 Rules、命名和元資料。

Reddit 上的討論

Reddit r/aigamedev 有一條相關討論：

用AI生成精靈圖，再針對處理成可以匯入到遊戲引擎的美術資源

討論圍繞同一條管線：用 AI 生成精靈表，再清理成可進入遊戲的畫素美術。評論裡常見的卡點包括：生成結果難以直接進引擎、動畫幀不夠穩定、清理後仍要大量手工處理。

在整理 Layer Split 這類提取流程時，這些卡點可以進一步拆成更細的阻力點。

阻力點分析

阻力點 1：精靈需要分類，也帶有場景語義

精靈進入遊戲後，通常要先被歸入不同用途，例如：

場景建築 / 裝飾元素：位置相對固定，互動很少，一般不需要碰撞設定
可互動 / 可碰撞物件：往往附帶碰撞、遮擋、層級，有時還涉及狀態切換

因此，資源在「看起來像一張精靈」之前，已經隱含分類與行為預期。影像模型更擅長生成畫面，較少系統化回答「這張圖在場景裡承擔什麼角色」。VberAI 目前也未把分類與場景語義做成系統能力：切分、提取、整理可以完成，「裝飾還是碰撞體」這類判斷仍主要落在匯出後、在 IDE 裡的批次處理。

阻力點 2：美術資源應按結構化資料管理，卻仍常被當作散圖處理

遊戲美術最終要進入引擎目錄與引用關係。更穩妥的形態接近帶結構的資源描述：型別、用途、關係、可檢索欄位齊全。匿名點陣圖堆很難撐起後續自動化。

AI 生成階段通常先得到一張或一組圖，結構資訊後補。VberAI 的 Layer Split / 框選提高了邊界控制精度（見 Layer Split），但結構化方式仍偏人工：對每張圖重複「選區、分層、確認」，成本隨素材量上升。核心問題是處理步驟能否沉澱為可複用結構。單次做完還不夠。

阻力點 3：常識性上下文如何傳給模型——同一介面圖內規則並不統一

同一張介面圖裡，不同元素需要的生成約束不同：

角色立繪 / 頭像：通常只要單張結果，不需要 idle、run、attack 等多幀狀態；無約束生成卻常多出狀態表（見標題圖）
多幀動畫：需要更強的一致性約束（比例、朝向、節拍、關鍵幀），重生成與篩選成本更高
介面中只露出區域性的元素：直接生圖有時可以補全被裁切部分；若只做手動切分後再提取，則會受原圖區域性資訊不足限制

左：VberAI 手動標註提取，框選過緊，建築右側被切掉。右：GPT Image 2 精靈表，建築完整，底部土堆和草坪仍粘在一起。

這裡缺少類似 Cursor Rules 的用法：把「只要單幀」「需要跑動迴圈」「允許補全遮擋區域」寫成可複用、可切換的上下文約束，再交給模型執行。常識約束若不能穩定傳入，結果容易停在「視覺上可接受」與「引擎內可直接使用」之間。

同一條 Reddit 討論裡：

I tried doing this with nano banana. I was trying to animate a cartoony dinosaur running. It would create the sprite sheet, but I couldn’t get enough good frames to make a convincing run animation.

I ultimately just cut out the limbs and tried animating them as a 2d skeleton in Unity. Just like anything, I think it takes practice and creativity to make these things work.

這條反饋對應同一類限制：模型可以產出精靈表，卻未必能穩定產出足夠、可用的動畫幀；工作流最終退回更可控的拆件 / 2D 骨骼方案。差距不只在模型畫質，也在任務上下文與驗收標準是否進入工具鏈。

阻力點 4：自動化命名與元資料——支撐 MCP / IDE 呼叫

美術資源最終要打包進引擎。若要通過 MCP 與 Cursor 等 IDE 協作，可呼叫性更多取決於圖背後的 元資料。單張點陣圖本身撐不起排程。

有效排程通常依賴兩層：

有意義的命名：用命名建立初始上下文（物件是什麼、屬於哪一類、用於哪一步）
更完整的內建元資料：按資源型別做檢索、篩選、批次處理與按規則呼叫（harness）

在這一點上，VberAI 已有明確進展：處理後的輸出會自動帶上有意義的命名，後續檢索與資源管理更直接。命名與元資料把生成結果推進到更接近「可被 IDE / MCP 引用的結構化資產」。

小結

遊戲美術資源本身帶結構，因此適合放進 AI 生成式開發流程。真正要處理的是結構化 harness：分類語義、可檢索元資料、可配置上下文規則，以及能被引擎與 IDE 接力的命名體系。

VberAI Studio 已經覆蓋切分、提取與自動命名中的若干環節。阻力點 1–3 仍更依賴人工判斷或缺少系統化配置；後續若這些約束能變成可複用、可被 Agent 呼叫的結構，管線完整度會明顯高於繼續加深單次手動操作。

分層切圖

2026-07-09T10:00:00+08:00

先說結論：3個步驟

Layer Split 用在已經選中的點陣圖上：切圖尺寸要跟著手畫的框走。畫完框之後會自動分層並用 AI 切；匯出檔名還能對上各塊內容。同一工具欄裡還有 Auto-Layering（自動分層），不畫框，檢測邊緣切圖。全自動切圖請參考自動分層：圖片轉多圖層。

物體被擋住或貼在一起時，手畫一框仍能單獨摳出一件東西——比如只要建築，不要邊上的草和土。

步驟 1：從工具欄開啟 Layer Split

在畫布上選中圖片。選中後的工具欄裡，開啟重疊圖層入口（Extract 右側）。裡面是兩個平級項：

Layer Split（分層切圖）——手動畫區域，再自動分層、AI 切圖。生成尺寸跟畫的框走。
Auto-Layering（自動分層）——不手動畫框，檢測邊緣切圖，匯出有意義命名的圖片檔案。

Extract 裡原來的 Manual Layering 已經沒了。Layer Split 就是那條流程的現用名：先畫框，再自動分層和切圖。

步驟 2：把畫面層和文字層分開

開啟 Layer Split 之後，框出目標畫面所在的整塊區域，再標哪些層是畫面、哪些層是文字。框決定生成尺寸。畫面 / 文字分開標，後面加工時能插手的地方會多一些。

步驟 3：生成處理結果

框和層型別確認後跑生成。輸出會按這些邊界和標註來。

複雜場景仍可能碰到額外的處理上限。跑完後，輸出圖會帶上能對上各塊畫面的名字，後面找起來方便一些。

演示影片

在選中的畫板上做 Layer Split，從工具欄到按框切圖：

同樣要拆層，但不畫框：自動分層：圖片轉多圖層。

入門

2026-06-26T10:00:00+08:00

AI優先的思路學習如何製作遊戲：先摸清常見製作卡點，再用生成能力把卡住的環節拆開，最後把產出變成引擎能直接匯入的資源。

過程裡會對照不同工具，說清楚各自能做什麼、卡在哪。VberAI Studio 是這條線上的核心，操作上更接近「直接用 AI 做遊戲」。

把耗時費力的內容生產交給 AI。

入門

2026-06-26T10:00:00+08:00

這裡的經驗過程會放置更加細化的經驗筆記。文件頁通常對準一個具體問題；這裡更常寫某條路徑上的做法，以及路上最直接的體驗。

vibegame

Godot AI 美術流程：盯住批次化處理，以及生成和程式碼之間的同步

先說結論

常見流程還停在五步

生成之後還要盯住這三步

我已經走通且在實踐的方式：把省下的時間轉到玩法策劃上

小結

Figma 到 Godot 的匯入工具是單向的：MCP 和可重新生成的美術同步需要另一套流程

先說結論

舊匯入為什麼是單向的

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

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

小結

Cocos Creator 2.x MCP

先說結論：3個步驟

步驟 1：開啟 CocosCreator2.x MCP Server

步驟 2：確認 Running，用一鍵配置

步驟 3：把 AI 程式設計工具接上

Cocos Creator 3.x MCP

先說結論：3個步驟

步驟 1：開啟 Cocos Creator MCP Server

步驟 2：確認 Running，用一鍵配置

步驟 3：把 AI 程式設計工具接上

Godot MCP

先說結論：3個步驟

步驟 1：開啟 Godot MCP Server

步驟 2：確認 Running，用一鍵配置

步驟 3：把 AI 程式設計工具接上

Unity MCP

先說結論：3個步驟

步驟 1：開啟 Unity MCP Server

步驟 2：確認 Running，用一鍵配置

步驟 3：把 AI 程式設計工具接上

MCP 怎樣把 AI 程式設計工具接到遊戲引擎上

先說結論：3個步驟

步驟 1：真正煩的是切圖放哪，不是圖本身

步驟 2：MCP 在本地跑一個服務

步驟 3：用一鍵配置接上程式設計工具，再開啟對應引擎的頁面

從圖片到多圖層：如何把角色圖拆成圖層，加快遊戲資源準備

先說結論

拆圖層已經不難

匯入到引擎，原圖層的上下文資訊都要保留和同步

垂直化的工具價值在於持續的共同上下文共享機制

小結

Figma 到 Unity：AI First 之後，不必把介面手動處理流程作為最大時間成本項來考慮了

先說結論

原文還在堅持的細節有一半都已經失效

對照：AI First 之後，哪些還成立，哪些不再是中心

現在這套組合實際改了哪一段

小結

相關教程

Figma 到 Unity

先說結論：6個步驟

步驟 1：存一份本地 .fig

步驟 2：在 VberAI Studio 裡 Import Project

步驟 3：自動分層

步驟 4：匯出到 Unity

步驟 5：選擇匯出到 Unity 的形式

步驟 6：檢查匯出結果

PSD 到 Unity

先說結論：6個步驟

步驟 1：開啟分層 PSD

步驟 2：在 VberAI Studio 裡匯入 PSD/PSB

步驟 3：自動分層

步驟 4：匯出到 Unity

步驟 5：選擇匯出到 Unity 的形式

步驟 6：檢查匯出結果

PSD 到 Godot

先說結論：3個步驟

步驟 1：開啟分層 PSD

步驟 2：在 VberAI Studio 裡匯入 PSD/PSB

步驟 3：匯出到 Godot

演示影片

PNG 到 PSD

先說結論：3個步驟

步驟 1：自動分層

步驟 2：匯出為 Photoshop PSD

步驟 3：開啟 PSD

精靈圖網格切圖

AI 去背景

步驟 1：存一份本地 `.fig`

步驟 1：存一份本地 `.fig`

步驟 1：存一份本地 `.fig`