vibegame

遊戲開發新手指引：遊戲UI中的美術資源基礎常識，AI Vibe Coding 必讀

2026-09-29T16:24:00+08:00

先說結論

用 AI 做小遊戲，常常先得到一張完整的對打圖。進工程之前，這張圖要拆成背景、角色打鬥和介面控制元件。左邊的角色按動作做成一套精靈圖。打中的那一幀播打擊音效，背景音樂單獨鋪滿這一回合。錄屏在 YouTube。

先拿到的是一整張對打圖

現在用 AI 做小遊戲的人多了。常見的起點是生成一整張螢幕：兩個角色在宮殿前對打，底下是血條和能量條。回合跑起來以後，玩家看到的就是這一屏。

工程裡要用的是組成這一屏的切圖。以 1997 年街機格鬥為例，拳皇 97 那種舞臺上同時有遠景、兩個角色和底部的介面。這三塊要分開畫。

這張圖要分成三層

同一張畫面拆開，對應下面這三層。

Layer 0（背景）是舞臺。柱子、旗幟、宮殿、遠山和石板地面都在這一層。角色走動時，舞臺留在原地。整場用一張背景，畫素畫法和角色一致。

Layer 1（角色打鬥）是兩個人對打。棍子、長槍、打中時的閃光、揚起的土，都在這一層。人的位置和當前姿勢，也在這一層上更換。

Layer 2（介面控制元件）是頭像、血條、能量條，還有中間的裝飾。這些蓋在打鬥上面。剩餘的血量和能量變了，就換這幾條的圖。角色邁步時，控制元件停在原來的位置。

三層用同一套畫風。血條從滿畫到空，畫風和舞臺、角色保持一致。舞臺準備一張就夠。血條和能量條要有滿、一半、空三種。角色要把這套招式裡會用到的姿勢都畫出來。武器上的閃光和當次的姿勢畫在一起。

這張圖拆開並不難。匯入到引擎中時，原來的位置還在不在、哪一塊還是不是能點的控制元件，才是後面要盯住的。原圖層的上下文資訊要保留，並和畫面同步。具體寫在從圖片到多圖層。

左邊的角色要準備一套動作

完成圖裡，左邊這個人只有一個姿勢：身體壓低，棍子伸向前，身後是紅披風。一個回合裡，他還要站立、行走、出招、格擋、受擊、倒地，然後再站起來。

這些動作都要做成切圖，場景才能播。武器帶出的閃光也要畫上。每一幀裡是同一個人，衣服和朝向不變。玩家按下按鍵後，引擎按順序播放這些幀。

AI 生成時，經常只給出這一個姿勢。揮棍、受擊和起身，要補進同一張精靈圖。

畫面要和音效、背景音樂對齊

打中時的閃光，是角色層上的一幀。打擊音效從這一幀開始播。換一招，就換一段音效。背景音樂從回合開始播到回合結束。棍子打中時，這段音樂照常繼續。

音效單獨做成檔案，和這一幀一起播放。換招的時候，可以換上這一下對應的打擊聲。背景音樂用另一份檔案，覆蓋整回合。

小結

這一屏做得到。切圖按圖層和動作準備好，音效跟打中的幀對齊，匯入到引擎中之後，畫面還能對上當初生成的那張圖。

看錄屏

AI 3D：參考圖生成三維模型

2026-09-29T16:15:00+08:00

先說結論：5個步驟

AI 3D（三維模型） 用參考圖生成三維模型，放到畫布上。從 AIGC 開啟 AI 3D，停在 Image to 3D（圖生三維）。Meshy 和 Tripo 是三維服務商。開源模型 Hunyuan3D 也在同一份選單裡。這次用 Tripo H3.1 · Image to 3D。

步驟 1：開啟 AI 3D

在底部工具欄開啟 AIGC，選 AI 3D。

步驟 2：選擇模型

停在 Image to 3D（圖生三維）。Face limit（面數上限） 是 Default（預設）。Texture（貼圖） 開著。

Meshy 和 Tripo：

Meshy 7.1 · Image to 3D
Meshy 7.1 · Multi Image to 3D
Tripo H3.1 · Image to 3D
Tripo H3.1 · Multiview to 3D
Tripo P2 · Image to 3D

開源模型 Hunyuan3D：

Hunyuan3D 3.1 Pro · Image to 3D
Hunyuan3D V3 · Image to 3D

這次選 Tripo H3.1 · Image to 3D。

步驟 3：放入參考圖

放進一張普通圖片。三維模型由站點生成。

這次的參考圖是一張四視角圖，生成結果是四個人物角色。

步驟 4：在畫布上檢視模型

模型落在畫布上。

Play / Pause（播放 / 暫停）
Open 3D Studio（開啟 3D Studio）
AI tools（AI 工具）

步驟 5：開啟 3D Studio

開啟 3D Studio。

頂欄：

Render current frame（渲染當前幀）
Multi-view render（多視角渲染）
Render sequence（渲染序列）
Export model（匯出模型）

Godot 4.7 的 Codex Skill：把Godot 4.7的開發者文件做成了Skill

2026-09-27T17:45:00+08:00

先說結論

有了這款 Skill，Codex 會更加精確，直接透過本地查詢和命中，降低網路搜尋的不穩定性。錄屏在 YouTube。

直接下載倉庫壓縮包：godot-4.7-codex-docs-skill.zip。專案頁：godot-4.7-codex-docs-skill。

Godot當前的問題是：正在執行的編輯器並沒有把類文件開放給AI直接存取

有網友說，Godot 官方 Git 倉庫裡已經有了 godot-proposals#13608 的改進，但是還沒合併到主程式碼中。合併之後，Agent 可以直接向正在執行的編輯器要文件。

提案仍是 open，2025-11-10 提出。它給 EditorPlugin 增加 EditorInterface.get_documentation(class_name)，返回當前編輯器裡的類文件，包含 GDExtension 加進來的類。

實現 PR godot#112628 仍是 open。改動大約幾十行，包的是編輯器內部已有的文件資料。2026-06-11，JetBrains Rider 還在催合併。卡住的是返回值 Dictionary 的文件怎麼寫。功能沒有被否掉。

4.7 裡還沒有讓外掛向當前引擎要類文件的呼叫。在這個 PR 進入正式版之前，本地 Markdown 是可用的做法。它和 Godot MCP 放在一起用。MCP 讀寫已經開啟的編輯器裡的場景和節點（Godot MCP）。這些頁負責簽名。

怎麼用這份 Godot Codex Skill

在文件倉庫裡開啟 Codex 或 Cursor 時，AGENTS.md 和這份 Godot Codex Skill 會生效。用 $godot-47-docs 問一個類或一個方法。

遊戲專案和這份倉庫並排放著開啟時，旁邊的倉庫不會自動變成 Skill。對話方塊裡要同時寫出 $godot-47-docs 和文件目錄的絕對路徑，檢索才發生在 gdd_*.md 所在的目錄。只點名 SKILL.md、不給路徑，搜尋會跑在遊戲倉庫裡。

在 Codex 裡，把這個資料夾加到專案可以讀取的目錄。輸入 $godot-47-docs 啟用。要單獨帶上一頁，輸入 @，再輸入 gdd 和類名或方法名，選中那個檔案。這一頁進入上下文，目錄裡其餘檔案留在外面。

小結

模型寫出的 Godot 程式碼不穩定，主要來自幾個版本同時存在。當前的這個倉庫就是為了解決由於不同版本的細微差別可能導致的 Bug 報錯問題，增強 Godot 4.7 版本的 AI 編碼穩定性。

看一遍這份 Skill

VberAI 匯出到遊戲引擎中：同一塊畫板，Godot 和 Unity 各拿到什麼檔案

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

先說結論

同一塊畫板，在 VberAI Studio 裡匯出了兩次，一次是匯出到 Unity，按照 Unity 的工程資料夾格式儲存，一次是匯出到 Godot，按照 Godot 的格式儲存，做了一次完整的對比拆解。錄屏在 YouTube。

相同的部分：29 張 PNG，位元組和檔名都一致；都是 1920×1080 的一塊畫面；節點名字一致；每個圖的位置已經寫在場景檔案裡。

不同的部分：Godot 解壓開是一層檔案，共 59 個。Unity 解壓開先看到 Assets，裡面是 Textures、Prefabs、Materials，共 66 個。四段文字在 Godot 裡寫在節點上，在 Unity 裡寫成三份材質檔案。

這次匯出達到了目標。兩套都是按該引擎的目錄放好的美術資源。工程開啟之後，MCP 能讀到這塊已經按原位置拼好的介面。

兩種目錄不同，放進工程後 MCP 都能按原位置拼介面

先把兩個壓縮包並排開啟。Godot 這一包點開是一層檔案。Unity 這一包點開先是 Assets，再進去是三個資料夾。目錄不同。兩邊都是按各自引擎寫好的美術資料夾：名字和位置已經在檔案裡。把匯出放進工程，編輯器開著，MCP 讀到的就是這塊拼好的 1920×1080 介面。

Figma 到 Godot 和 Figma 到 Unity 寫的是每個引擎期望的目錄。下面按這次的兩個壓縮包點開看。兩份匯出可以直接下載：

Godot 壓縮包：59 個檔案，解壓後是一層。
Unity 壓縮包：66 個檔案，解壓後第一層是 Assets。

相同部分及拆解：29 張圖

點開任意一張同名 PNG。位元組相同，檔名也相同。

畫板和上面的物件：

background_2_2.png
pirate_ship.png、lava_platform.png
wooden_tower.png、wooden_hut.png、red_crystal_tower.png、pirate_skull_tower.png、fire_tower.png、dark_skull_tower.png

卡牌和技能：

large_skull_tower_card.png、skull_tower_card_one.png、skull_tower_card_two.png、skull_tower_card_three.png、skull_tower_card_four.png
green_spell_card.png、fire_spell_card.png、blue_spell_card.png

介面：

resource_status_bar.png、health_bar_2.png
gold_button_one.png、gold_button_two.png、gold_button_three.png
pause_button.png、pause_small_icon.png
coin_icon_2_2.png、skull_icon.png、heart_icon_2.png、shield_icon_2.png、metal_orb_icon.png

這四個名字在場景裡有標註，但是沒有切圖檔案。skull_count、coin_amount_2、life_count、tower_level 在資料夾裡找不到對應的 PNG。畫面上的 6/15、340、6、10 是直接寫在節點上的字。

場景裡的名字	畫面上的字	字號
`skull_count`	6/15	19
`coin_amount_2`	340	19
`life_count`	6	17
`tower_level`	10	21

Godot：59 個檔案，點開就是一層

點開 Godot 的壓縮包，整包就是這些：

*.png                     29 張圖
*.png.import              29 份匯入配置，每張圖旁邊一份
*.1920x1080_layer.tscn    1 個場景

.tscn 是 text scene 的縮寫，意思是文本場景。場景根節點是一個 1920×1080 的 Control。下面是 29 個 TextureRect 和 4 個 Label。每張圖指向 res://<名字>.png，也就是這一層裡的那個檔案。每份 .import 告訴 Godot 把這張 PNG 當作紋理。字色、描邊和陰影寫在 Label 上。

場景檔名是畫板 id 再加上 1920x1080_layer。

Unity：66 個檔案，點開先看到 Assets

點開 Unity 的壓縮包，第一眼是 Assets。這是 Unity 工程裡放資源的根目錄。進去之後是三個資料夾：

Assets/Textures/*.png                 29 張圖
Assets/Textures/*.png.meta            29 份匯入配置，每張圖旁邊一份
Assets/Prefabs/*.1920x1080_layer.prefab
Assets/Prefabs/*.prefab.meta
Assets/Materials/TMP_FX_*.mat         3 份文字樣式檔案
Assets/Materials/*.mat.meta

Prefab 的根是一個 Canvas，參照尺寸 1920×1080。子節點名字和 Godot 一致。每份 .meta 把 PNG 匯入成 Sprite。

Unity 解壓後是 Assets 裡的三個資料夾

Unity 匯入的是工程裡 Assets 目錄下的檔案。所以這個壓縮包的第一層就是 Assets。複製進工程之後，Textures、Prefabs、Materials 會併入編輯器已經在即時跟蹤的那棵目錄。PNG 如果放在壓縮包的根目錄，就在這棵目錄外面，編輯器不會匯入。

這三個資料夾，是這塊畫面實際用到的三類檔案。可以一個一個點開：

Textures 是切圖。每張 PNG 旁邊有一份 .meta。Sprite 是 Unity 裡給介面用的圖片，GUID 是這張圖在工程裡的編號，寫在 .meta 裡。.meta 匯出時已經寫好，放進工程並重新整理之後按這份設定匯入。
Prefabs（預製體）是拼好的介面。這次只有一個 .prefab。旁邊的 .prefab.meta 是它的匯入配置，不是第二個預製體。.prefab 裡有 Canvas、子節點名字，以及每個圖在 1920×1080 畫板上的位置。
Materials 裡這三份都是文字材質。那四段字的描邊和陰影，寫成 TextMesh Pro 材質。skull_count 和 coin_amount_2 共用一份，life_count 和 tower_level 各一份。每份都打開了 OUTLINE_ON 和 UNDERLAY_ON。

這份 Godot 包沒有再套這三層。場景裡每張圖的路徑都是 res://<名字>.png，所以 .tscn 和 PNG 放在同一層。.import 做的是 Unity 裡 .meta 做的那件事，並且就在 PNG 旁邊。.tscn 就是拼好的介面，所以沒有 Prefabs 資料夾。描邊寫在 Label 上，所以沒有 Materials 資料夾。點開 Godot，看起來像 Unity 的 Textures 裡面那一層，場景檔案也在這份名單裡。

Unity 和 Godot，哪一份匯出對 MCP 更友好

一樣友好。MCP 不比較資料夾有幾層。它讀的是檔案放進工程、編輯器開啟之後的場景。

Godot MCP 讀當前開啟的場景：那個 .tscn 裡的節點，以及指令碼。Unity MCP 讀當前開啟的場景：遊戲物件，以及 Assets/Prefabs 裡的那個 Prefab。MCP 就是這條通道。兩邊的名字和位置都已經寫好，所以按原位置拼回這塊介面，匯出裡已經完成。

壓縮包仍然要先複製進工程。畫板之後再改，要再匯出一次，MCP 裡才會出現新畫面。在 Godot 裡改的邏輯，或在 Unity 裡改的邏輯，也要先從畫板匯出，才能拿這份新內容去驅動下一次生成。

問與答

Assets 在 Unity 裡做什麼？

Assets 是 Unity 工程裡放資源的根目錄。圖片、預製體、材質都放在這棵目錄下面。編輯器只匯入這裡的檔案。這次匯出的壓縮包第一層寫成 Assets，複製進工程之後，會併入編輯器已經在即時跟蹤的那棵目錄。放在 Assets 外面的 PNG，Unity 不會當作工程資源匯入。

預製體為什麼看起來有兩個？

Prefabs 的簡體中文是預製體。點開 Prefabs，看到兩個檔案，預製體只有一個。

....1920x1080_layer.prefab 是預製體。整塊 1920×1080 畫面組在這一個檔案裡：29 張切圖的位置，加上四段寫在節點上的字。

同名的 .prefab.meta 是這份預製體的匯入配置，裡面記著它的 GUID。29 張切圖都在這一個預製體裡。

Materials 裡是不是都和文字有關？

這份匯出裡，是。Materials 中的三份檔案都是 TextMesh Pro 材質，檔名以 TMP_FX_ 開頭。畫面上的文字匯出到 Unity 中之後，字色、描邊和陰影存在這些材質裡。字號 19 的兩段共用一份，字號 17 和 21 各一份。Godot 把同樣的樣式寫在 Label 上，所以 Godot 的包裡沒有這個資料夾。

Textures 裡的 .meta 匯出之後會自動生效嗎？

會，但要等檔案進了 Unity 工程。.meta 在匯出時已經寫在每張 PNG 旁邊。解壓本身不會啟動 Unity。把 Assets 放進工程，編輯器重新整理並開始匯入時，會讀取這些已有的 .meta，按裡面的 Sprite 設定生效，不必再逐張手改。刪掉 .meta、讓 Unity 重新生成的話，GUID 會換成新的，預製體裡對這張圖的引用會對不上。

Unity 裡的 GUID 和 Sprite 是怎麼一起工作的？

Sprite 是 Unity 裡給介面和 2D 用的圖片。每張 PNG 的 .meta 裡有一串 GUID，是這個資源在工程裡的編號。預製體引用圖片時寫的是這串編號。檔案以後改名，只要 .meta 還在，預製體仍指向同一張圖。這次匯出的 .meta 和預製體是一起生成的，編號已經對上。

Godot 的 .tscn 是什麼縮寫？

.tscn 是 text scene 的縮寫，意思是文本場景。Godot 用這種文本檔案儲存場景：有哪些節點、放在哪、貼哪張圖、文字寫了什麼。二進位制的場景檔案是 .scn。這次匯出的是 .tscn，開啟能看到 1920×1080 的 Control，以及 29 個 TextureRect 和 4 個 Label。

小結

這次對照達成了。同一塊 1920×1080 畫板進了 Godot 和 Unity，圖、名字和位置都在。工程開啟之後，MCP 在兩邊讀到的是同一塊已經拼好的介面。

檔案本身還空著兩處。場景和 Prefab 的檔名仍是畫板 id 加上 1920x1080_layer，玩法裡的場景名這次匯出還沒有帶上。Unity 比 Godot 多 7 個檔案，因為文字樣式單獨放在 Materials。以後換主題或活動切圖，這些圖片檔名可以保持不變，用 AI 換皮膚再匯出一次。

看一遍這次匯出

Godot 是開源的嗎

2026-09-26T14:05:00+08:00

是。Godot 是開源的。

Godot 使用什麼語言

2026-09-26T14:04:00+08:00

Godot 使用 GDScript 和 C#。GDScript 是 Godot 自帶的指令碼語言。

Godot 上的 AI 全自動開發，自動驗證走得通嗎

2026-09-24T18:10:00+08:00

先說結論

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

看一遍這條迴路

Unity CLI 和 Unity Plugin for Codex 的區別

2026-09-24T12:00:00+08:00

先說結論

Unity CLI 和 Unity Plugin for Codex 是兩樣東西，在 Codex 會話裡會一起出現。CLI 是終端裡的 unity 命令：安裝編輯器、加模組、建立和開啟工程、登入、配置版本管理。外掛把 Unity Skills 裝進 Codex，請求可以按當前的 Unity 做法來寫。裝了其中一個，另外一個還是要單獨裝。

Unity CLI

官方說明是 Use the Unity command-line interface (CLI)。CLI 仍是實驗功能。它是獨立的 unity 程式，機器上可以不裝 Unity Hub 桌面應用，也能安裝編輯器、開啟工程。持續整合、指令碼、以及人在終端裡，跑的是同一套命令。輸出可以是 JSON 或 TSV，程序會返回退出碼。

這一頁上的常見命令：unity install、unity install-modules、unity editors、unity open、unity projects create、unity auth login、unity vcs setup。要從 CLI 控制已經開啟的編輯器，還要另外裝 Unity Pipeline 包，官方把這一步單獨寫在同一頁。

Unity Plugin for Codex

Unity’s plugin for Codex 把 Unity Skills 加進 Codex。一條 Skill 是某一項 Unity 工作的書面說明，會話就不用從舊帖子裡重拼這套說明。從外掛市場安裝：

codex plugin marketplace add Unity-Technologies/unity-agent-plugin
codex plugin add unity@unity-agent-plugin

新開會話後，/unity: 下面能看到這些 Skill。codex plugin list 裡 unity 顯示為已安裝並啟用。目錄頁是 Codex 中的 Unity Plugin，當前版本 0.1.6-beta。本站的安裝步驟：Codex 的 Unity 官方外掛：安裝、連線、呼叫 Skill。每一項適合什麼場景：Codex 中的 Unity Skills 詳細介紹。

兩者怎麼接上

外掛裡有一條 Skill 叫 unity-cli。它告訴 Codex 怎樣去呼叫 CLI。CLI 程式本身還是要裝在這臺機器上。人不開 Codex，也可以直接跑 unity open。Codex 裝了外掛之後，任務如果是「安裝這個編輯器」或「開啟這個工程」，仍然要有 CLI。CLI 在終端裡操作 Unity。外掛是 Codex 這一側的 Skills。unity-cli 是把這兩層接上的那條 Skill。

小結

Unity CLI 負責安裝、開啟、登入這一類終端操作。Unity Plugin for Codex 負責把當前的 Unity 做法交給 Codex。兩條都要在的時候，先有 CLI，再有外掛裡的 unity-cli。

怎樣把 Codex 連線到 Unity

2026-09-24T11:11:00+08:00

先說結論

官方外掛頁：Codex 中的 Unity Plugin。當前版本是 0.1.6-beta。

Codex 是 OpenAI 推出的 AI 編碼工具，內建在 ChatGPT 客戶端中。把 Codex 連線到 Unity，走兩條通道，各管一件事。官方外掛 unity-agent-plugin 當前是 0.1.6-beta，裡面的 Skills 把 Codex 指到現在的 Unity 做法。Unity MCP 在會話進行時讀取已經開啟的編輯器，工具呼叫才能對上眼前這份工程。Skills 是地圖。即時通道是訊號。

Codex 是什麼

Codex 是 OpenAI 推出的 AI 編碼工具，內建在 ChatGPT 客戶端中，可以直接從 ChatGPT 切換到 Codex 模式。它可以加一個功能、補一個錯誤，或回答某段指令碼在做什麼。單獨用的時候，它仍按訓練資料回答。Unity 工程在那之下會變：場景、包、編輯器版本。把 Codex 連線到 Unity，是給它一份當前的地圖，再給它一次對開啟工程的即時讀取，會話就不必靠來回貼上。

兩條連線

外掛：Skills 當作地圖

Unity 釋出了 Unity Plugin for Codex。目錄入口是 Codex 外掛頁上的 Unity。當前版本是 0.1.6-beta。裝上之後，在已經開啟的 Unity 6 編輯器裡批准連線，再按名字呼叫 Skill。每一項適合什麼場景：Codex 中的 Unity Skills 詳細介紹。安裝步驟：Codex 的 Unity 官方外掛：安裝、連線、呼叫 Skill。

一條 Skill 是某一項 Unity 工作的書面說明：用哪套 API、做哪些檢查、怎樣算做完。這是導航。Codex 少把提示詞花在重建一套論壇裡仍按舊編輯器描述的 API 上。

在 Codex 裡呼叫 Unity Skills，官方的做法是輸入 @Unity。Codex 會根據這句話自動分析，並自動呼叫對應的 Skill。

MCP：即時讀取編輯器

MCP 把已經開啟的編輯器送進編碼會話。VberAI 的 Unity MCP 在編輯器旁邊跑一個本地服務。服務狀態是 Running 時，Codex 可以讀這份工程的場景、物件和控制台，不必憑一段貼上的指令碼去猜。安裝與連線：Unity MCP。通道本身怎麼工作：MCP 怎樣把 AI 程式設計工具接到遊戲引擎上。

官方外掛也會在 Edit → Project Settings → AI → Unity MCP 裡批准 Unity 自己的 MCP Bridge。這座 Bridge 和 VberAI 的 Unity MCP 都在本機，不是同一個視窗。Skills 告訴 Codex 該跟哪套做法。即時通道告訴它這臺編輯器現在在做什麼。

省掉的來回

沒有外掛，也沒有 MCP 時，改程式碼要在 Unity 編輯器和對話之間來回複製貼上。提示詞裡少了包名或場景名，回到編輯器裡執行就會報錯。下一輪還要把漏掉的名字再貼一次。裝上外掛之後，當前 API 的用法已經寫在 Skill 裡。接上 MCP 之後，呼叫工具時可以直接讀到已經開啟的工程。

限制

2D 畫素和現成的 Skill 對得上。 2d-pixel-perfect、精靈編輯、圖集和 Tilemap 就是按這類工程寫的。3D 沒有同樣密度的 Skill。列表裡有 URP 和 Shader Graph。一整塊 3D 場景，仍比畫素相機加一塊 Tile 調色盤需要更多人工說明。

官方外掛面向 Unity 6 及以後。 更早的編輯器 API 得到的說明更少。工程還停在更早的大版本上時，Codex 會更常退回舊例子。

這兩樣工具提高的是寫程式碼的速度。 它們做不完每一個場景。模型仍要做選擇。叫錯一條 Skill，或描述還停在舊狀態，寫出來的程式碼仍會放不進這份工程。

費用

官方外掛從 Codex 目錄安裝，不收費。VberAI 的 Unity MCP 不是免費的。版本和許可見 vberai.com/game-engines/unity。

外掛、MCP 和 Unity CLI

Unity CLI 是終端介面：安裝編輯器、開啟工程、管理包和許可、跑構建和測試、讀日誌。人可以跑，代理也可以跑。它不告訴 Codex 一項 Unity 工作該怎麼做。

外掛是 Codex 這一側的整合。Skills 是說明。其中 unity-cli 教 Codex 怎樣去驅動 CLI。裝上外掛並沒有換掉 CLI。

MCP 是編碼時的即時傳輸。Unity 隨官方外掛提供一座 Bridge。第三方也可以再提供一座，VberAI 的 Unity MCP 就是這一座。CLI 把命令做快。外掛提供地圖。MCP 讓會話和開啟的編輯器保持同步。

小結

把 Codex 連線到 Unity，地圖和即時訊號要一起在。官方外掛裡的 Skills 負責當前 API。VberAI 的 Unity MCP 負責讀已經開啟的工程。2D 畫素對得上現成 Skill，3D 和 Unity 6 以前的工程要另外留神。外掛免費，這份 MCP 不免費。CLI 仍是命令列，不代替這兩條通道。

AI First：Unity中應該支援生成音樂和影片嗎？Yes

2026-09-23T18:26:00+08:00

先說結論

Yes。VberAI Studio 已經能用遊戲介面生成音樂和影片，步驟在 AI生成音樂/歌曲和 AI 生成影片。生成一旦進了工具，要覆蓋的種類會繼續變多。Unity 應該在編輯器裡跟上。Godot 已經有人用外掛把生成放進編輯器。入口有了之後，畫面、音樂和影片還要共用同一份上下文。

畫面可以直接拿來生成

Godot Asset Library 裡的 ElevenLabs API（wchc）配好金鑰之後，可以用提示詞，或用工程裡已有的文本，在編輯器裡生成語音。這份外掛當前做的是文本轉語音。接法和音樂是同一類：生成發生在編輯器裡，輸入是提示詞，或是工程裡已經有的材料。

在 VberAI Studio 裡，輸入是遊戲介面上的畫面。AI Sound 寫出音樂卡片，AI Video 寫出成片，結果都落回畫布。

邊界繼續向外擴

程式碼和美術資源已經是常用的兩類生成。音樂和影片要繼續加進去。一個平臺上可以同時長出多條自動生成流程，把以前留在編輯器外面的生成做深。

入口有了之後，上下文還要同步

Godot 的跟進已經發生在外掛上。Unity 什麼時候放進同類的編輯器入口，還是一個空著的問題。入口有了之後，介面、音樂、影片和場景還要帶著同一份上下文。介面改過，早先生成的音樂和影片仍停在上一次的描述上，下一次生成就對不上。

小結

Yes。Unity 應該在編輯器裡支援生成音樂和影片。Godot 已經用外掛把生成放進編輯器。畫面、音樂和影片還要留在同一份上下文上。

AI 生成影片

2026-09-23T18:10:00+08:00

先說結論：6個步驟

AI Video（AI 影片） 用畫布上已有的圖，加上一段文字，生成影片。在底部工具欄開啟 AIGC，選 AI Video（AI 影片）。模型列表裡有 Seedance 2.0、Veo 3.1 Fast、Seedance 2.5、Kling Video V3 Pro。這次用的是 Turbo MAX Image To Video。用 Pick from canvas（從畫布選取） 把畫面填進 First frame（首幀），寫上提示詞，再開始生成。時長和解析度選小一些，結果會更快回來。這次是 5 秒、480P。

下面這張是這次用的貓園場景。

步驟 1：開啟 AI Video

在底部工具欄開啟 AIGC，選 AI Video（AI 影片）。

步驟 2：選擇模型和尺寸

開啟模型選單。裡面有 Seedance 2.0、Veo 3.1 Fast、Seedance 2.5、Kling Video V3 Pro，以及 Turbo MAX 的幾項。這次選 Turbo MAX Image To Video。

模型旁邊的控制元件用來定時長和解析度。尺寸小一些，結果回來得更快。這次是 5 秒、480P。

步驟 3：從畫布選取首幀

First frame（首幀） 是起始畫面。End frame（尾幀） 可以空著。點選首幀上的新增按鈕。選單裡有 Upload from device（從本機上傳） 和 Pick from canvas（從畫布選取）。這次走 Pick from canvas。

步驟 4：點選圖片上的連結圖示

把指標移到畫面上，圖上會出現一個連結圖示。點這個圖示，圖片就會填進 First frame（首幀）。

步驟 5：寫下提示詞

在描述框裡寫這段影片。這次框裡的文字是：but featuring cute kittens, with an overall visual style inspired by *Kingdom Rush*. Please generate some audio tracks in a similar style that I can use as background music for the game.

步驟 6：在畫布上檢視成片

開始生成之後，成片會出現在畫布上，帶播放按鈕。這一條是 832×480，角標是 5.2s。

這次生成的影片：

演示影片

AI生成音樂/歌曲

2026-09-23T17:21:00+08:00

先說結論：6個步驟

Music / Song（音樂） 根據一段文字寫出曲子，再以卡片放在畫布上。在底部工具欄開啟 AIGC，再開啟 AI Audio（AI 音訊），選 Music / Song（音樂）。面板預設停在 Create music（建立音樂）。旁邊的 Video/animation music（影片或動畫配樂） 用來給已經有畫面的影片或動畫配樂。參考圖可以不放。需要的話，用 Pick from canvas（從畫布選取） 點中畫面上的圖層，再在 Music description（音樂描述） 裡寫提示詞。生成後的卡片可以直接播放，也可以剪輯和繼續編輯。

下面這張是這次用的貓園場景。

步驟 1：開啟 Music / Song

在底部工具欄開啟 AIGC，再開啟 AI Audio（AI 音訊），選 Music / Song（音樂）。

步驟 2：保持在 Create music

面板標題是 Music / Song。標題下面一行是 “Compose music from a prompt”。Create music（建立音樂） 已經選中。旁邊是 Video/animation music（影片或動畫配樂），給影片或動畫配樂時用這一項。

步驟 3：從畫布選取參考圖

Reference image（參考圖） 可以不放，一開始是空的。點選新增圖片的按鈕。選單裡有 Upload from device（從本機上傳） 和 Pick from canvas（從畫布選取）。這次走 Pick from canvas，參考圖用的是畫布上已有的圖層。

步驟 4：點選畫面上的圖層

游標會換成新增時的樣式。提示寫著 “Click a layer on the canvas to use as input”。點中這張圖，參考圖位置就會被填上。

步驟 5：寫下音樂描述

在 Music description（音樂描述） 裡寫這段音樂。這次填的是 a battle between cats, cute style game ui。

步驟 6：在卡片上播放和編輯

生成後的音樂以卡片出現在操作畫面上。這一張名叫 Music 1.mp3，時長 2:58，卡片上有播放按鈕。卡片上方的工具欄用來播放、剪輯，以及繼續編輯。

這次生成的檔案可以在頁面裡直接播放。

Music_from_AI_Sound.mp3

演示影片

MCP 該收費嗎？Unity 收費為什麼被罵

2026-09-20T17:50:00+08:00

先說結論

原來一直付費的 Unity MCP 權益，現在已經放到個人免費套餐裡了。看當前的 Personal 方案，Unity’s MCP access 可以直接用，不用綁信用卡。沒想到它曾經是付費權益，後來才開放成免費。Figma 的 MCP 一直要付費訂閱才有。有的 MCP 要收費，有的持續免費，主邏輯是：會不會產生請求成本。

Unity MCP 曾經是付費權益

Unity 定價頁上，Personal 這一列把 MCP 和 Cloud、CLI 寫在一起，套餐本身是 Free。

現在的 Personal 已經把 Unity's MCP access 寫進免費套餐。

幾個月前，Unity MCP 相關介紹下面的評論還在罵收費。一個月後有人只回了一句：MCP is free now。

罵得比較集中的一點是：Unity 這一側並沒有推理成本，token 已經在程式設計工具那邊付過了。

評論裡有人抨擊得很不留情面：Unity 這邊沒有 inference 成本，token 是自己帶到 Cursor、Claude 上的。再收一筆訂閱，看起來就像為了引擎不掉隊多付一次錢。Unity 自己的 Get started with Unity MCP 也是這個結構：編輯器在本地當 server，程式設計工具對著開啟的工程說話。

Unity MCP 把開啟的編輯器暴露給 Claude Code、Cursor、Codex 這類工具。

通道本身怎麼工作，見 MCP 怎樣把 AI 程式設計工具接到遊戲引擎上。Unity 6 內建 Bridge 走的是本機 IPC，說明見 Unity 的 Codex 外掛。

Figma 的 MCP 一直要訂閱

Figma 的 MCP 一直是付費訂閱才會有的權益。客戶端名單很長——Claude、Claude Code、ChatGPT、Cursor、VS Code——檔案仍在 Figma 一側。每一次呼叫，都是對著這份託管檔案發請求。

Figma MCP 能接到很多程式設計工具。許可權仍跟 Figma 訂閱走。

會不會產生請求成本

VberAI Studio 和 Figma 一樣。對接 VberAI 的 MCP 一定會產生更多請求成本。

遊戲引擎是完全在本地跑的客戶端。場景、節點、控制台都在本機。MCP 的成本就幾乎無限低。

小結

MCP 不是同一種產品。本地引擎這條通道可以持續免費。

檢視影片版本討論

ChatGPT Image 2.5 Sunburst 適合去做精靈圖嗎？

2026-09-18T17:40:00+08:00

先說結論

目前常見的做法，是在 ChatGPT 裡用 Image 2.5 Sunburst 去生成 ChatGPT 精靈圖。Developing sprite sheets with gpt-image-2 這條討論裡，AI Game Studio Dev Log 的作者提出了一套比較穩定的工作流：

通過 GPT Image 模型來生成角色設定圖（當時測試的模型還是 GPT-Image-2）；
通過 MiniMax H3 Max 模型生成 3–5 秒的動作序列幀；
使用 ffmpeg 提取並調整序列幀的大小和角色位置，保證動畫的連貫性；
使用 Aseprite 繼續編輯調整精靈圖，作為這批精靈圖的資產管理；
使用 ElevenLabs 做音效。

可以做到嗎？可以，但是不推薦。精靈圖需要的是一個能讓多個工具鏈共通的美術資源生成 Harness，而不是去依賴一個無法打通和共享上下文的獨立環境。

作者後續的兩條經驗

首先，在生成角色時，擁有同一角色的多個對齊檢視非常有用。作者的做法是生成側面、正面和背面檢視。這樣就能有一致的參考影像，可以從不同角度建立動畫序列。過去總會遇到「基線對齊」的問題，使用 GPT Image 2.5 後，這個問題已基本解決。這並非強制性的，也可以僅基於側面檢視生成正面和背面動畫，但這樣一來，角色的某些細節就容易發生變化。例如，身份牌可能會消失，或者頭髮顏色可能會略有變化。因此，擁有多個參考幀可以確保從不同角度生成一致的動畫。

第二條是，在生成動畫時，要對起始幀和結束幀進行條件化處理。如果要一段能迴圈的待機動畫，需要確保第一幀和最後一幀重合。如果角色正在執行一個向北轉身、然後又回到側檢視的動作序列，需要確保最後一幀的銜接保持一致。

影片評論區中討論的分層方案

因為我會經常更新自己的探索過程的影片，也拿到了很多人的討論資訊和看法，例如在一個影片站點下就出現了這樣的對話：

毫無意義，seedream 5.0 pro已經支援了影像分層，一個api的事兒
老大，請問這個seedream的分層要在哪裡使用呀
你大機率不是程式設計師，你按我說的一步一步做：開啟deepseek官網，下載deepseek harness，在deepseek註冊帳號申請key充五塊錢，然後直接在harness軟體的聊天視窗讓deepseek幫你做個影像分層小工具，其接入位元組Seedream 5.0 Pro的api，讓它自己搜api文件接入
哈哈，有個詞語叫重複造輪子。話說回來，也虧是這位UP在網上發了影片，大佬你在評論區指出來了，咱們才能知道還有這樣好的方法

上面兩個例子，處理上都還停在出圖、分層這一步。

角色精靈圖是一整塊需求

產品調研裡曾經發現過類似 SpriteCook 這樣的產品，專注去處理角色的 Sprite 及相應的圖片資源。這裡面其實涵蓋的是一整塊需求，並不是上面兩個例子的處理那麼簡單，例如：

生成的精靈圖後期的管理維護，按照原尺寸的資產重新生成，並和提示詞對齊；
生成的精靈圖資產在一個頁面下的快速編輯；
大批次的角色圖資源的批次化生成；
不同角色的持久化、穩定的提示詞 Harness。

上面的情況當然都可以實現。但如果需要大量、批次化、穩定地生成和處理、後期管理，甚至團隊資產管理，目前更接近的是 VberAI Studio 這一套工作鏈。

小結

在 ChatGPT 中使用 Image 2.5 生成精靈圖，不如直接在 Codex 專案中呼叫 Figma 的 MCP 去進行這批美術資源的管理，但後續還牽涉到更多如何與遊戲引擎的同步和互動。見 Figma 到 Godot 的匯入工具是單向的。所以並不推薦在 ChatGPT 中直接生成精靈圖，這意味著後期還要面對大量的 Harness 流程與美術處理流程需要構建。

Codex 的 Unity 官方外掛：安裝、連線、呼叫 Skill

2026-09-17T15:40:00+08:00

先說結論：3個步驟

Codex 的 Unity 外掛適合這樣的 Unity 6 工程：希望 Codex 按當前的 API 寫程式碼，而不是按十年積累下來的論壇答案寫。外掛由 Unity 以自己的名義釋出，裡面 31 個 Skill 都由負責對應功能的 Unity 團隊編寫。從 Codex 的外掛目錄安裝，或者用兩條命令安裝，然後在編輯器裡批准 MCP 連線，之後提需求時指定 Skill 的名字。需要 Unity 6 或更高版本。

步驟 1：找到外掛並安裝

兩條路徑，裝到的是同一個外掛。

在 Codex 的側邊欄開啟 Plugins（外掛），搜尋 Unity，從 Unity Technologies 名義釋出的目錄條目安裝。

從終端裝，同樣是兩條命令：

codex plugin marketplace add Unity-Technologies/unity-agent-plugin
codex plugin add unity@unity-agent-plugin

倉庫是 Unity-Technologies/unity-agent-plugin，許可證為 Unity Companion License。Claude Code 從同一個倉庫安裝，命令是 /plugin install unity@unity-agent-plugin。

它不是 Asset Store 的資源包，編輯器裡的 Package Manager（包管理器）找不到它。當前版本是 0.1.6-beta，後續更新通過 codex plugin marketplace upgrade unity-agent-plugin 獲取，不需要在機器之間複製檔案，也不需要為每個工程單獨配置。

新開一個 Codex 會話，輸入 /unity:，可以確認 Skill 列表是否已經載入。

步驟 2：在編輯器裡批准 MCP 連線

先把 Unity 6 工程開啟。下面這些操作都發生在正在執行的編輯器上。

在 Unity 裡開啟 Edit（編輯）→ Project Settings（專案設定）→ AI → Unity MCP，確認 Bridge 顯示為 Running。Codex 發來的第一個請求會落在 Pending Connections 裡，一直等到在編輯器裡點 Accept 才會放行。傳輸走本地 IPC，工程原始碼不會離開本機。

有兩個面板容易混。官方外掛用的是 Unity 編輯器內建的 MCP Bridge。這個站點另外介紹的 Unity MCP 是獨立的服務視窗，跑在 6594 埠，帶 Cursor 和 Codex 的一鍵配置。兩者都在本地執行，但不是同一個面板。通道本身怎麼工作，見 MCP 怎樣把 AI 程式設計工具接到遊戲引擎上。

連線批准之後，當前場景、GameObject 和 Console 日誌都可以在會話裡讀取和修改。

步驟 3：提需求時指定 Skill

Skill 以斜槓命令的形式按名字呼叫。如果只說「做一個設定介面」而不指定 Skill，用哪套 UI 框架就沒有定下來。uGUI 的工程裡被寫進 UI Toolkit 的程式碼、後面還要拆掉重來，多半是這麼來的。

先交給路由，讓它判斷工程的情況：

/ui 做一個設定介面，帶音量滑塊和返回按鈕

/ui 會先讀這個工程在用哪套 UI 系統，再轉給 /ui-uitk、/ui-ugui 或 /ui-imgui。其他領域同理：從 Built-in 遷移到 URP 用 /migrate-birp-to-urp，圖集打包用 /manage-sprite-atlas，CJK 文字顯示成方塊用 /optimize-text-mesh-pro，Unity IAP 用 /implement-in-app-purchases。

31 個 Skill 按用途分組的完整介紹：Codex 中的 Unity Skills 詳細介紹。

Unity CLI 和這個外掛不是一回事

這個問題被問得夠多，直接寫清楚。

Unity CLI 是一個介面。它從終端觸達引擎，負責安裝 Editor、建立和開啟工程、管理包和許可證、執行構建與測試、讀取日誌。AI 也好，人也好，都可以呼叫它。Unity 在 Unite Seoul 就釋出了 CLI，比兩個外掛都早。

外掛給出的是一套指引。每個 Skill 描述的是「這件 Unity 的活本來該怎麼做」，所以 Codex 會先看工程、用當前的 API、驗證結果之後再返回。沒有這套指引時，通用程式設計工具只能按網上關於 Unity 的所有內容取一個平均值來回答，而那裡面很大一部分是針對早就不再釋出的引擎版本寫的。

兩者在外掛內部交匯：unity-cli 本身就是 31 個 Skill 中的一個，專門教 Codex 怎麼使用 CLI。裝了外掛不等於可以不用 CLI，用了 CLI 也不等於 AI 就拿到了 Unity 對這件活的指引。

兩者之外還剩什麼

Skill 覆蓋的是工程開啟之後程式碼怎麼寫。批次化處理生成出來的 UI 美術資源——把一張合成圖按檢測到的邊緣切開，匯出有意義命名的圖片檔案，寫進 Assets/Textures 和 Assets/Prefabs，並且保留和同步原圖層的上下文資訊——發生在這之前，不在 Skill 列表裡。見 Unity 的 Codex 外掛：31 個 Skill 覆蓋了什麼，又留下了什麼。

PSD 匯入 Unity：沒有「保留畫布尺寸」選項，圖層位置留在 Prefab 上

2026-09-16T14:45:00+08:00

先說結論

r/Unity3D 上反覆出現的問題：把 PSD 分層匯入，同時讓每個 Sprite 還保留整張畫布的尺寸和原來的偏移。那條討論最後停在兩個建議——自己從 Photoshop 裡逐層匯出，或者把多出來的透明區域當成設計上的問題。這個行為背後的機制沒有被說清楚。

PSD Importer 裡並沒有這樣一個設定。位置保留在另一個地方：匯入時生成的 Prefab。第二次匯入時，畫布或圖層尺寸變了，SpriteRect 也不會跟著更新。要對回去，只能在 Sprite Editor 裡手改 rect，或者應用 Automatic Reslice——後者會丟掉這一組裡所有手工修改。

Individual Sprites (Mosaic) 實際產出什麼

把 Texture Type（貼圖型別）設為 Sprite (2D and UI)，Sprite Mode（Sprite 模式）設為 Multiple，Import Mode（匯入模式）設為 Individual Sprites (Mosaic)。圖層會打包成一張 Texture，每個圖層對應一個 SpriteRect，每個 SpriteRect 跟著該圖層自身的畫面走。2048 畫素畫布上一個 32 畫素的圓，匯入後就是一個 32 畫素的 Sprite。

這個選項旁邊有兩項 padding 設定，都不會把畫布還原回來。Mosaic Padding 控制打包 Texture 裡圖層之間的間距。Sprite Padding 是 PSD Importer 8.0.0（Unity 2022.2）加入的，作用是把每個 Sprite 在 Texture 裡的 rect 放大一點。兩者調整的都是間距，rect 的起點仍然是圖層畫面。Sprite Editor 裡的 Trim（收緊）方向相同，把 rect 收到不透明畫素的邊緣；想反過來把 rect 放大，只能一個 Sprite 一個 Sprite 手動改。

位置保留在 Prefab 裡，不在 Sprite 裡

Character Rig → Use as Rig（作為骨架使用）會根據原始檔生成一個 Prefab。Sprite 的層級和位置來自圖層層級、以及這些圖層在 PSD 裡的位置，每個 Sprite 還會拿到一個按圖層順序排的 Order in Layer 值，所以 Prefab 能把原始檔的排布復原出來。Use Layer Grouping（保留圖層分組）會把 Photoshop 的分組保留成父節點。

Inspector 裡這一段只在 Sprite Mode 為 Multiple、Import Mode 為 Individual Sprites (Mosaic)、並且已經安裝 2D Animation 包時才出現。Unity 把同一組開關寫在「為動畫準備美術素材」這一節下面，那裡預期的產出是一個能綁骨骼的角色 actor，配 .skeleton 資源和 Skinning Editor。兩種讀法下位置都能還原，只是一屏 UI 這樣匯入進來，得到的是一個動畫 actor，Canvas 層級還要另外搭。

所以那條討論其實有答案可用：相對比例和位置已經被處理掉了，每個 Sprite 保留畫布尺寸並不是提供這兩樣東西的開關。

檔案格式和被忽略的圖層屬性的代價

.psd 檔案預設走普通的 Texture Importer，會被壓平。要走分層這條路，需要選中檔案，把 Importer 下拉改成 UnityEditor.U2D.PSD.PSDImporter，或者直接用 .psb——PSD Importer 針對的就是這個格式，單邊最大支援 300,000 畫素。儲存時開啟 Maximize Compatibility（最大相容）。

生成 Sprite 和 Prefab 時，有四類 Photoshop 圖層屬性會被丟掉：Channels（通道）、Blend Modes（混合模式）、Layer Opacity（圖層不透明度）、Effects（圖層效果）。一張畫面依賴正片疊底圖層或者 40% 不透明度陰影的圖，匯入後這些都被壓平了，想把畫面還原成原始檔的樣子，就變成在 Unity 裡寫 shader、調材質的活。

第二次匯入

SpriteRect 的資料按 Layer ID 持久化，手工改過的內容才能在重新匯入之後留下來。同一個機制也意味著：原始檔裡改了圖層或畫布尺寸，SpriteRect 的大小和位置不會跟著變。要把它對回去，只能在 Sprite Editor 裡改 rect，或者應用 Automatic Reslice（自動重新切分）——後者會按當前原始檔重新生成全部 rect，並丟掉這一組裡所有手工修改。

一個角色檔案，這個代價是已知的。一屏會被重新生成的介面，或者一整個資料夾等著做同樣處理的 PSD，才是 batch 這個詞出現在搜尋裡的原因。PSD 到 Unity 走的是另一條路：分層這一步在 Editor 之外完成，然後一次匯出寫出 Assets/Prefabs 和 Assets/Textures，命名和目錄結構跟著檔案一起到位。

小結

畫布尺寸不是解決這個問題該調的地方。單個檔案上，位置已經由 Use as Rig 還原。重新生成的一屏介面，或者一整個資料夾的 PSD，每次再匯入時 SpriteRect 還是舊尺寸，每個檔案都要再做一遍同樣的 rect 調整。

Codex 中的 Unity Skills 詳細介紹

2026-09-16T09:30:00+08:00

Unity 官方 Codex 外掛 unity-agent-plugin（0.1.6-beta）附帶 31 個 Skills。下面按用途分組。第一列的英文是實際 Skill 名稱，指定時用這一列。

工程、Editor 與包

Skill	用途與適用情境
`new-unity-project`	從零建立新遊戲或原型時的引導：先釐清概念、目標平臺和商業化方向，再建立工程、版本控制和必要的包。不負責直接生成完整玩法。
`unity-cli`	從終端操作 Unity：安裝或管理 Editor、工程、模組、授權、構建和測試。已經連上 Editor 時，也可以檢視層級、執行 C#、修改場景或資源。
`unity-package-management`	用 Unity Package Manager 的 C# Client，在無介面環境或 CI 裡新增、移除、升級、查詢 UPM 包。避免手改 `manifest.json` 之後依賴解析出錯。
`generate-editor-search-query`	要在當前工程或場景裡找出具體資源或物件時，生成 Unity Search（Quick Search）查詢並開啟搜尋。適合找材質、Prefab、GameObject、元件、引用關係等只讀查詢。

UI、文字與本地化

Skill	用途與適用情境
`ui`	UI 的總入口。需求只說「做選單、HUD、設定頁、按鈕」，卻沒有指定框架時，先辨認工程用的是 UI Toolkit、uGUI 還是 IMGUI，再轉到對應專長。
`ui-uitk`	Unity 6+ 的 UI Toolkit：UXML、USS、`UIDocument`、資料繫結、自定義 Visual Element、Manipulator 與 `PanelSettings`。適合新的介面，以及 Editor / Runtime 的 UI Toolkit 工程。
`ui-ugui`	基於 Canvas 的 uGUI：`RectTransform`、Layout Group、Canvas 層級、Prefab UI、ScrollRect。適合已有 uGUI，或明確以 Canvas 為核心的工程。
`ui-imgui`	`OnGUI` / `OnInspectorGUI` 的 IMGUI Editor 工具、Custom Inspector、PropertyDrawer。新增 Editor 工具預設應先看 UI Toolkit，除非已有程式碼或需求明確使用 IMGUI。
`optimize-text-mesh-pro`	TextMeshPro 的字型回退、fallback atlas、SDF、padding、AutoSize、世界空間與 UGUI 的取捨，以及文字帶來的記憶體和效能問題。
`localization`	Unity Localization：Locale、String / Asset Table、Addressables 與中日韓字型支援。適合多語言 UI、翻譯流程，以及中日韓文字缺字。

2D、Sprite 與 Tilemap

Skill	用途與適用情境
`2d-pixel-perfect`	畫素風 2D 的 Pixel Perfect Camera 設定，以及抖動、模糊的診斷。會先區分 URP 和 Built-in 的不同實現，避免把兩套 API 混用。
`sprite-editor`	通過 Unity 的 Sprite Editor 資料提供者，修改 Sprite 的 rect、border、pivot、outline，並做自動切分、按格子切分、等角切分。
`sprite-segment-3x3grid`	按顏色匹配，把 Sprite 分析成 3×3 格子的文字表示，用來判斷中心色和周圍格的關係；也可以作為 RuleTile 規則的輸入。
`manage-sprite-atlas`	SpriteAtlas V2 的主 atlas / 變體 atlas、打包和平臺設定，並走構建前的流程來生成或配置 atlas。管理的是工程裡已經有的 Sprite。
`tilemap-palette-create`	建立 Tile Palette，支援矩形、六角和等角 Grid。適合先搭出關卡繪製用的工作臺。
`tilemap-ruletile-createempty`	沒有任何 Sprite 輸入時，建立空白的 RuleTile、HexagonalRuleTile 或 IsometricRuleTile，再手工填寫規則。
`tilemap-ruletile-createfromsegment`	已經有地形或邊緣 Sprite 時，建立自動拼接的 RuleTile；可以接收 3×3 分析結果，轉成鄰居規則。

圖形、渲染與畫面質量

Skill	用途與適用情境
`migrate-birp-to-urp`	把 Built-in Render Pipeline 遷到 URP，或處理遷移後的品紅材質。覆蓋材質、Shader、2D、PPv2、燈光、Lightmap、Reflection Probe 和質量設定等風險檢查。
`urp-postprocessing`	用 URP Volume 設定並除錯 Bloom、Tonemapping、色彩校正、景深、Vignette、Motion Blur 等後處理。
`validate-urp-render-graph-renderer-feature`	審查 Unity 6+ URP Render Graph 的 `ScriptableRendererFeature` / Pass：資源接線、材質繫結、descriptor、全域性資源和 Render Graph 慣例。
`shader-graph-create-custom-node`	把 HLSL 轉成 Shader Graph 能用的自定義節點，處理反射匯出，以及函式 / 引數的提示標記。
`optimize-web`	Unity WebGL / WebGPU 的下載體積、首屏載入、瀏覽器效能和耗電。覆蓋壓縮、CDN、資源裁減、Shader variant、KTX 和質量設定。

音訊、物理與導航

Skill	用途與適用情境
`audio-setup-mixers`	盤點場景和音訊資源，給 Audio Source 分類，並路由到已有的 Audio Mixer Group。不會自行新增 Mixer 或 Group，會先列出缺口和建議。
`optimize-audio`	針對短音效、音樂、環境音選擇 Load Type、取樣率、codec、Mono 和 Mixer 結構，用來降低記憶體和 CPU，同時要求測量，並在真機構建上驗證。
`physics-3d-collision`	3D PhysX 的碰撞 / Trigger 不觸發、穿透、Raycast 漏判、Ragdoll 爆炸、`AddForce` 等問題診斷。主範圍是 MonoBehaviour 的 3D 物理。
`initialize-ai-navigation`	AI Navigation：NavMesh Surface、Agent、Obstacle、Link、Modifier、Area / Cost、巡邏、避障、carving 與動畫銜接。

聯網、服務與商業化

Skill	用途與適用情境
`build-live-game`	Unity Services 的後端和運營功能：登入、Cloud Save、Cloud Code、排行榜、成就、進度、經濟系統、伺服器權威、Remote Config、實驗、分析和部署。
`setup-multiplayer-services`	即時多人聯網的架構選擇與實現：Session、Lobby、Matchmaking、Discovery、host / client，以及和 Netcode 的配合。適用於房間、隊伍和即時互動。
`setup-vivox-voice-chat`	Unity Vivox 的語音和文字聊天：麥克風許可權、VAD、按鍵說話、音量 / 靜音、發言指示、隊伍頻道、近距離 3D 聲音和訊息。
`implement-in-app-purchases`	Unity IAP：商品目錄、消耗 / 非消耗 / 訂閱、pending-confirm、收據驗證、權益、恢復購買、Apple / Google 擴充套件，以及從已有的第三方支付方案遷過來。
`levelplay-unity-integration`	LevelPlay Ads Mediation：Rewarded、Interstitial、Banner、ad unit、初始化、Android Gradle / iOS CocoaPods、ATT、ILRD，以及從舊的 IronSource / Unity Ads 遷過來。

小結

Unity 程式碼歷史悠久，這組 Skills 方便拿來做專案重寫。工程裡常見的是多年累計的 API、Built-in 設定和過時的內購、介面寫法。指定對應 Skill 之後，可以對著開啟的 Unity 6，讓 Codex 按當前的 URP、UI Toolkit、IAP 去改。

介面需求經常只說「做設定頁、HUD」，工程裡實際用的是 UI Toolkit、uGUI 還是 IMGUI，事先並不清楚。直接按其中一套去寫，後面要對著層級和元件返工。先指定 ui，再落到 ui-uitk 或 ui-ugui，可以讓 Codex 先讀工程，再按對得上的框架去搭。

渲染和後處理也有對應的 Skill。不少專案還停在 Built-in，遷到 URP 之後材質變粉、PPv2 對不上、自定義 Renderer Feature 接錯資源。指定 migrate-birp-to-urp、urp-postprocessing、validate-urp-render-graph-renderer-feature，可以讓 Codex 按現行 URP 去遷、去查。

上線相關的登入、存檔、多人房間、語音、內購和廣告調解，過去要自己拼文件和第三方遷移。指定 build-live-game、setup-multiplayer-services、implement-in-app-purchases、levelplay-unity-integration，可以把這一段交給 Codex，按 Unity Services 和現行 IAP / LevelPlay 的做法接到開啟的工程裡。

Cocos 精靈圖集

2026-09-15T15:30:00+08:00

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

調整疊加線直到格子對齊。跳過空格子可以丟掉全透明的格。幀名按從左到右、從上到下排列，和把 SpriteFrame 拖進 Cocos Creator 的 Animation Clip 時的順序一致。

匯出的 ZIP 裡是同名的一張 PNG 和一份 format 3 的 plist。把這兩個檔案一起拖進 Assets，Creator 會生成圖集，下面掛 SpriteFrame 子資源。取樣率和 crossFade 仍在編輯器裡設定；這裡不寫 .anim 動畫剪輯。

Creator 的 Auto Atlas 打包的是已經切開的 SpriteFrame，而且發生在構建階段。它不會把 AI 拼好的整張圖切成圖集。這份匯出對應 Creator 已經支援的 Cocos2d-x plist 加 PNG。

如何讓豆包生成遊戲開發可用的精靈圖：出圖容易，後續維護還要專業工具

2026-09-15T12:05:00+08:00

先說結論

大量遊戲開發新手已經在用主流的圖片生成模型出圖。目前常見的入口是豆包，生圖走 Seedream 5.0 Pro。第一張角色精靈圖往往很快就能拿到，有些情況下畫面已經很驚豔。

這一檔是好用的生成工具。Codex 生成程式碼，也是同一類能力。出圖之後，針對單張資源的指定生成、維護式生成，以及和程式碼層面一起同步部署，仍要專業工具來接。

新手已經在這樣出圖

目前常見的流程是開啟豆包，用 Seedream 5.0 Pro 出一張角色精靈圖，再拖進 Unity 或 Godot。標題圖就是這一小時裡常見的樣子：同一角色的待機、走動、攻擊，排在一張格子圖上。

出圖這一步已經夠用。站在遊戲工程裡看，這只是第一張點陣圖。

出圖容易，後面的生成並不容易

一次提示詞就能拿到看起來像遊戲資源的精靈圖。光影和材質有時已經能過關。PNG 檔案本身帶不來工程後半段。

節日要換一套視覺時，風格仍是原來那一套。同一角色只換一把武器時，比例和尺寸都要不變。切圖按引擎目錄寫進工程。再生成一輪之後，節點和指令碼仍指向原來的幀。

用AI生成精靈圖已經寫過分類、結構和元資料這些卡點。Seedream 5.0 Pro 把第一張點陣圖的觀感抬上去了。後面這些步驟並沒有一起做完。

Codex 已經把這條分界寫清楚了

Unity 給 Codex 出的官方外掛能對著開啟的編輯器，按當前文件寫程式碼。把外掛裝上只能說明自動化程式設計是越來越順了。AI 生成的美術怎麼批次化處理，以及和程式碼邏輯之間怎麼同步，仍在外掛之外。

Seedream 5.0 Pro 落在這條線的另一邊。強的是給出那張平面圖。針對單張資源的指定生成、維護式生成，以及和程式碼一起同步部署，仍在對話視窗之外。

後續工具要對齊的，是場景裡的潛在目標

後面接哪一家工具，名字並不那麼要緊。本站一直在看的是 VberAI Studio。無論接哪一套，後續生成都還要對齊下面這些目標。

整體風格要能一直對齊。 第一張精靈圖已經進工程之後，下一輪不能漂到另一套配色、外形或畫素尺寸上。

和遊戲引擎之間的資料同步、邏輯同步，要一起做。 切圖寫進 Godot 或 Unity 的工程資料夾。名字、圖集、動畫播放器，在下一輪生成之後還要能對上。MCP 可以讀開啟的工程；前提仍是檔案已經和節點樹對得上。說明見 Godot AI 美術流程。

特定圖片資源往往需要一次指定生成。 只換一把劍、只補一幀眨眼、只重畫介面上的那枚金幣。其餘格子要留住。

原來那套遊戲風格的生成提示詞，要能被繼承。 第一輪的提示詞、參考圖和約束要跟著資源走，不能只留在聊天記錄裡。

精靈圖這類特定格式上的自動化工作，要能批次化、穩定地做完。 網格切圖、按透明通道切圖、按點選順序拆幀、按 Photoshop 圖層裁切。本站工具裡已經有一條本機路徑。後續那一層要把這些步驟保持成可重複的批次處理。

VberAI Studio 已經能覆蓋切圖、匯出、按引擎目錄寫出的一部分。上面這些目標仍是要對齊的方向，不是一張已經勾完的清單。

小結

強的生圖模型會把第一張精靈圖縮短。遊戲開發能用的美術，還在後面那幾輪：針對單張資源的指定生成、維護式生成，以及和已經在用這些幀的程式碼一起同步。

PSD 轉精靈圖

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

開啟一份分層的 RGB PSD。工具列出已有畫素的柵格圖層，按不透明區域裁切，再把勾選的切圖拼成一張透明底精靈圖。匯出按圖層名打包的 ZIP，或匯出那張精靈圖。檔案只留在本機，不會上傳。

這不是完整的 Photoshop 渲染。混合模式、圖層樣式、文字，以及智慧物件內部都不會重繪。超過 80 MB 的檔案，或邊長超過 8192 畫素的畫布，會被拒絕。請先在 Photoshop 裡柵格化智慧物件，並去掉不用的圖層。

精靈圖拆包

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

開啟一張精靈圖。工具按透明空隙檢出每一塊。按動畫順序在圖上點選，序號會記下來。匯出選中的切圖，或把這一序列做成 GIF。檔案只留在本機，不會上傳。

Unity 的 Codex 外掛：31 個 Skill 覆蓋了什麼，又留下了什麼

2026-09-14T17:40:00+08:00

先說結論

目前常見的 Unity Codex 流程是這樣的：在 Codex CLI 裡裝上 Unity 的官方外掛 unity-agent-plugin，通過 MCP 連上已經開啟的 Unity 6 編輯器，再讓程式設計工具按 Unity 當前的文件去寫 URP、UI Toolkit、內購這些程式碼。

這一段確實好用。把外掛裝上只能說明自動化程式設計是越來越順了。而我在意的還是美術資源的處理：批次化處理美術素材，以及批次化生成與程式碼邏輯之間的同步。

官方外掛提供的是什麼

倉庫是 Unity-Technologies/unity-agent-plugin，Claude Code 和 Codex 用的是同一份。OpenAI 的 Eric Provencher 在 9 月 10 日寫過一句「Codex now has a Unity plugin!」，之後社群裡就開始出現大量解讀。

官方文件 Unity’s plugin for Codex 寫得很明確（也沒誇張）：這不是 Asset Store 上的資源，也不能從 Package Manager（包管理器） 安裝。README 寫明面向 Unity 6+，示例狀態是 unity@unity-agent-plugin installed, enabled 0.1.0-beta。

Codex 一側的安裝命令：

codex plugin marketplace add Unity-Technologies/unity-agent-plugin
codex plugin add unity@unity-agent-plugin

新開一輪 Codex 會話後，輸入 /unity: 就能看到這組 Skills。更新用 codex plugin marketplace upgrade unity-agent-plugin。Claude Code 走同一個倉庫，會話裡換成 /plugin install unity@unity-agent-plugin。

MCP 連的是開啟的編輯器

Unity 6 裡，Edit（編輯）→ Project Settings（專案設定）→ AI → Unity MCP 能看到 Bridge 是否 Running（執行中）。第一次連線會落到 Pending Connections（待批准的連線），需要在編輯器裡點 Accept（接受） 才放行。文件說通訊走本機 IPC，工程原始碼不必為此上傳。

這裡有兩個視窗容易混。官方外掛走的是 Unity 編輯器內建的這條 MCP Bridge。本站寫過的 Unity MCP 是另一個服務視窗，預設埠 6594，給 Cursor、Codex 做一鍵配置。兩條都在本機，但不是同一個面板。通道本身怎麼工作，見 MCP 怎樣把 AI 程式設計工具接到遊戲引擎上。

通道通了之後，當前場景、遊戲物件、Console（控制台） 日誌都能讀能改。前提仍然是：切圖已經按引擎目錄寫進工程，名字還能對上節點。

Skills 覆蓋的是工程裡的寫法

倉庫 skills 目錄目前是 31 個模組。和介面、圖相關的有 ui、ui-uitk、ui-ugui、ui-imgui、manage-sprite-atlas、sprite-editor、sprite-segment-3x3grid。其餘覆蓋 Tilemap、Pixel Perfect 相機、URP Render Graph、Shader Graph、從 Built-in 遷到 URP，以及內購、LevelPlay、多人服務、語音、TextMeshPro 字型回退、WebGL 和 Unity CLI 打包。

README 給的例句也停在同一層：做一屏設定介面、相機移動時畫素圖發抖、中文字在 TextMeshPro 裡變成空框、給 ScriptableRendererFeature 查 Render Graph。這些都是工程已經開啟之後，在編輯器裡要做的事。

換句話說，外掛解決的是「別再產出十年前的寫法」。外掛的目標似乎是為了通過 AI 改造 Unity 的歷史程式碼資產，達到最新的標準和實現。

介面圖的批次化處理仍在外掛之外

ui-uitk 回答的是這一屏該用 UI Toolkit 還是 uGUI。manage-sprite-atlas 回答的是工程裡已經有的圖怎麼打圖集。我手頭更常見的是前一步：AI 生成的商店圖、活動彈窗、HUD，每一張都是合成圖。

這批圖要檢測邊緣切圖，匯出有意義命名的圖片檔案，按 Assets/Textures、Assets/Prefabs 寫進工程，還要把原圖層的上下文一起保留和同步。一兩張可以自己做完。同一套介面再生成一版、節日要換一批圖的時候，數量就上去了。外掛的 README 和 Skills 列表裡沒有這一步。

大量無組織、無結構的切圖檔案，和程式工程之間的即時對映，是需要重視的一環。程式設計工具讀到的是檔名和節點名，讀不到這一塊畫素是不是按鈕；後續的 AI 程式設計仍對不上事件。

拆圖這件事現在已經不費時間。匯入到 Unity 中之後，原來的位置和互動資訊能不能復原，才是要盯住的。相關記錄見 Figma 到 Unity 和自動分層：圖片轉多圖層。

我已經走通且在實踐的方式：美術資源單獨批次化生成和單獨管理

編碼交給 Codex，加上官方外掛之後，對著開啟的 Unity 6 寫程式碼這一段更省心：按當前文件的做法生成，控制台報錯也能經 MCP 讀回來改。

介面圖的批次化生成和處理放在 VberAI Studio 裡做完，再匯入到 Unity 中。設計稿要改，回到 VberAI Studio 再匯出一輪，工程裡的層級還能對上原來的圖層結構。開啟的工程用 Unity MCP 同步，美術資源同步和程式碼邏輯同步要一起做。

小結

遊戲開發的並行任務的處理，不止有歷史程式碼更新這一個環節。

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。本機切成單張。名字會帶序號，進引擎前仍要改成能讀的名字。說明見自動切圖。

節日要換一套視覺時，不要另外匯出一套對不上原來名字的圖。選中已分層的畫板，跑 Restyle（換皮膚）。圖層關係和尺寸仍一一對應，再匯出一輪即可。說明見 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 tools（AI 工具），展開 Remove Background（去除背景），選 Remove background，跑一遍，再核對場景環境是否已去掉、UI 是否還能進引擎或繼續做精靈。光暈、半透明邊要精細摳、又不走重繪時，見 AI 超精細摳圖。

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

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

步驟 2：選 Remove background

選中圖片後，開啟 AI tools（AI 工具），展開 Remove Background（去除背景），選 Remove background。

步驟 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

先說結論：4個步驟

Smart Layering（智慧分層） 把一張介面圖拆成多圖層。Image to Layers 指的就是這一步。已經在用的介面，如果一次切完就不再看，後面通常還要手工改。所以切開之前會停一下：哪些框留下，哪些區域是程式文字，要不要開 HD enhance（高畫質增強）。確認之後，切好的圖放在一塊新畫板上，墊在源圖的一份複製上。

拆開並不難。匯入到引擎中時，原來的位置和互動還在不在，才是後面要盯住的。原圖層的上下文資訊要保留，並和畫面同步。具體寫在從圖片到多圖層。

步驟 1：用 AI Auto Box 圈出各塊

選中畫板。開啟 AI tools（AI 工具），點 Smart Layering（智慧分層），再點 AI Auto Box（AI 自動圈選）。這一步讀整張圖，把要單獨切開的元素各自圈出來。列表還沒確認時，可以在已有框裡再畫一個，也可以移動框、改框的大小。

步驟 2：核對圖層列表

每個框標成 UI element（介面元素），或 Program text（程式文本）。標成程式文本的區域，匯出時按文書處理，不做成圖片圖層。框疊在一起時有前後。拖動某一行，可以改哪一塊在上面。這張圖裡，生命數、金幣數和波次是程式文本。圖示和卡面是介面元素。

步驟 3：確認數量，再決定要不要高畫質增強

對話方塊標題是 Start manual layering?（開始手動分層？）。裡面寫著要切多少個元素，以及這次的估算。勾選 HD enhance（高畫質增強） 之後，切出來的圖層會再交給影像模型處理一次。細節更清楚，邊緣更乾淨。模型能補上的殘缺，也會補上。估算和上一步標的內容一致，再點確認。

步驟 4：在新畫板上看結果

處理完會新建一塊畫板。切分結果鋪在源圖的一份複製上。各塊貼得很緊。拖動某一層，或者拉動框邊上的控制點，才能看出它和原圖是分開的。圖層名字也一起寫上，例如 life_count、shield_icon、skull_tower_card_one。

演示影片

圖層切好、名字也寫上之後，用 PNG 到 PSD 存成 Photoshop 檔案。同一批圖層也可以匯入到 Unity 中：Figma 到 Unity，或 PSD 到 Unity。

在多個線上遊戲上跑同一次節日換皮

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

先說結論

手上帶著好幾個線上遊戲的團隊，同一個節日要過好幾遍。美術其實已經齊了，要做的是把一套定好的處理方式應用到每一塊要上線的畫板上，並且在日期之前準備好。能不能穩住，取決於三件事：相隔幾個月做出來的畫板之間提示詞是否一致、每塊畫板底下那套結構化設定、以及這些任務能不能批次提交。功能本身見 AI 換皮膚。

成本在數量上，不在單屏上

只有一個遊戲時，過節日看起來是一件設計工作。萬聖節要一套節日主題圖示，情人節會湧出大量表達愛意的視覺元素。一屏一屏做，是做得完的。

換成多個遊戲，演算法就變了。十個線上遊戲，每個十來塊節日畫板，就是一百二十次執行，對著一個不會挪的日期。日期不會因為佇列長就往後推。有持續運營時，美術和開發都會在那些日子之前進排期，內容先做好上線準備，日期到了再放出來。專案階段改變不了這個形狀：剛開始小規模測試的遊戲，和上線三年的遊戲，會在同一週要同一套節日內容。

所以要看的是數量，不是單屏。按「這塊畫板難不難」來估一次節日的工作量，大概會少算一整個遊戲組合的倍數。

提示詞一致，是真正卡住的地方

一堆遊戲裡的畫板並不是一起做出來的。不同的美術、不同的月份，對面板邊框或按鈕狀態該長什麼樣，習慣也不一樣。同一句主題描述鋪到這一批上，偏差就是從這裡來的：同樣的措辭，落在去年做的畫板和上週做的畫板上，效果並不一樣。

實際做法是主題寫一次，之後原句複用。每一屏各改各的，感覺像在調優，做出來的卻不像同一套。確實需要區別處理的畫板，值得單獨記成一條已知例外，而不是把它揉進改過的提示詞裡——後面再跑一遍時，需要的正是這份例外清單。

結構化設定，是美術資源能回到工程裡的原因

這裡的生成是按結構化文件提交的：結構化的美術資源設定留著，替換的是視覺呈現。正是這個分工，讓換完風格的畫板還能放回工程裡——圖層關係和圖片尺寸，仍然和引擎已經在匯入的那一套一一對應。

一批越大，把原來的環境引數帶下去就越重要。一屏上丟一個設定，是一處手工修復。一百二十屏上丟，就是「這批能直接匯入」和「這批得重新手工推一遍」的差別。

排期，才是團隊層面的那一半

量一上來，這件事就不再是美術問題，而是誰在什麼時間、按什麼順序、對著哪個截止日提交的問題。這是排期要回答的。

r/aigamedev 上這條討論也是同一個形狀：用 AI 給資源換皮膚。工作室一旦把這套能力鋪好，收穫是便捷的節日換皮：短時間、按指定方向生成大量資源。剩下的是成本問題——怎麼排工序，才能把總的生成量壓到儘量低。排程更專，要生成的量會下來，這是生產端這一輪的變化。

值得把它設計成團隊的固定流程，而不是某個人的工作習慣。帶著大量遊戲的小團隊人員流動快，一套只存在於某個人習慣裡的節日流程，每換一次人就要重建一次。寫下來的主題、記下來的例外清單、定好的提交順序，才能交接得下去。

小結

遊戲 UI 的批次換皮膚需要批次 API 請求和返回。原來的環境引數設定非常重要。再往上，稀缺的是排期，不是生成本身。

同一批遊戲的商店素材走的是同一份日曆，形狀也一樣：見 AI圖片翻譯。

AI 換皮膚

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

先說結論：4個步驟

Restyle（換皮膚） 用來給已經上線的遊戲做節日換裝。一個節日要換的，通常是一批已經做完的畫板。在 VberAI Studio 裡選中畫板，開啟 AI tools（AI 工具），點 Restyle（換皮膚），寫下要換成的主題。各層的樣子會按這句話重畫。圖層的疊放關係和每張圖的尺寸都還在，換完的畫板對得上工程裡已經在用的那套結構。畫面上的字經常還是原來的顏色，標籤顏色後面要再統一一次。

步驟 1：選中要換的畫面

在 VberAI Studio 的畫布上，選中要換風格的那一屏。開啟 AI tools（AI 工具），點 Restyle（換皮膚）。

步驟 2：寫下要換成的主題

Restyle（換皮膚） 對話方塊裡寫一段描述，介面會按這段話重畫。點確認之前，對話方塊裡會先顯示這次的費用。

提示詞示例：

Halloween-themed page atmosphere

步驟 3：看換完的畫面

等這一次做完，再看畫板。環境、面板邊框和道具會換成主題裡的樣子。畫面上的字經常還是原來的顏色。這些字的顏色，後面要再統一一次。

步驟 4：圖層關係和尺寸保持原樣

圖層的疊放關係沒變。每張圖的尺寸也沒變。

一批已經上線的遊戲，用同一次換皮膚

一屏做一次就夠。節日活動要覆蓋多款已經上線的遊戲時，同一句主題要在每一塊準備上線的畫板上再做一次。提示詞寫好之後，剩下的是把這些畫板排進處理順序。

一批畫面能不能看起來是同一次活動，看這三件事。

提示詞用同一句。 主題描述寫好一次，後面的畫板都用這句原文。相隔幾個月做出來的畫板，也用這一句。不要每換一屏就改寫一遍。

原來的介面設定留著。 Restyle（換皮膚）換的是看起來的樣子。底下的圖層設定還在。這些設定還在，換完的畫板就可以放回工程裡。畫板一多，更要留著這套設定。

一次提交多張。 在畫布上一張一張點，做不完一個完整遊戲的介面。要處理很多張時，需要批次介面：一次提交多張，一次拿回結果。

排期看的是這次活動裡有多少塊畫板。一個遊戲四張節日介面，另一個遊戲四十張，要處理的量差得很多。

節日換裝排到一批已經上線的遊戲上，寫在在多個線上遊戲上跑同一次節日換皮。

演示影片

選中畫板之後做 Restyle（換皮膚）：寫下主題，看到圖層關係和尺寸還在。

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

在畫布上選中圖片。開啟 AI tools（AI 工具），選 HD Upscale（提升清晰度）。

步驟 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：開啟 Image Split — Auto Split

在畫布上選中精靈圖。選中後的工具欄裡開啟 Image 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 的本地化。

流程見 AI 圖片翻譯：選中圖片，開啟 AI tools（AI 工具），選 AI image localization（AI 圖像本地化），再選擇語言，匯出同尺寸檔案。

小結

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

演示影片

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

AI 超精細摳圖

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

先說結論：3個步驟

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

開啟 AI tools（AI 工具），展開 Remove Background（去除背景），選 Fine cutout（精細摳圖）。選中圖片，跑一遍，匯出透明結果，匯入到引擎中或繼續做精靈都可以。

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

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

步驟 2：選 Fine cutout

選中圖片後，開啟 AI tools（AI 工具），展開 Remove Background（去除背景），選 Fine cutout（精細摳圖）。

步驟 3：檢查摳圖結果

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

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

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

提取背景

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

先說結論：3個步驟

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

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

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

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

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

選中圖片後，開啟 AI tools（AI 工具），再開啟 AI Extract（AI 提取），選 Extract Background（提取背景）。

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

步驟 3：檢查乾淨背景

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

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

AI圖片翻譯

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

先說結論：3個步驟

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

AI image localization（AI 圖像本地化） 用模型生成，改寫位圖裡的字，再輸出一張同尺寸資源。第一遍不必逐條手繪標籤。

商店素材也走這一輪。手上帶著多個遊戲、要上 App Store、Google Play 和 Steam 的團隊，每多一個語言、多一個平臺，同一套截圖就要再出一遍，數量漲得比美術本身快。

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

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

步驟 2：開啟 AI image localization 並設定目標語言

選中圖片後，開啟 AI tools（AI 工具），選 AI image localization（AI 圖像本地化）。

在 AI image localization（AI 圖像本地化） 對話方塊裡選目標語言（例如日語），確認圖層，再跑 Translate（翻譯）。

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

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

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

多個遊戲、多個商店的整套素材

一張截圖就是跑一次。多個遊戲上三個商店、八種語言，就是同一輪乘出來的量：遊戲數 × 屏數 × 語言數，這個數字比美術量漲得快得多。

鋪開之前先定下這幾件事：

每一屏以哪張圖為準。 每次都從原始圖重新生成，質量比較穩。拿已經譯過的結果再譯一遍，偏差會一輪輪疊上去。
各商店的尺寸。 輸出和源圖同尺寸，所以各商店要求的畫幅要在源圖這一側就準備好，而不是生成完再改。
提前驗字形。 中日韓文字和越南語的聲調符號，是烤進圖裡的標籤最先出問題的地方。每種語言先跑一屏，再決定整批要不要鋪開。

字在畫素裡，所以商店素材一改，是把受影響的那幾屏重新生成，而不是改一份文案表。商店素材的更新按批來排，和 AI 換皮膚裡的節日美術走同一份排期。

用真實商店圖做的例項：App Store 截圖還在一張張本地化？用 VberAI Studio 批次做 Image Translate。

沒有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：從選單選中這個功能

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

選中目標圖後，開啟 AI tools（AI 工具），再開啟 AI Extract（AI 提取），選 Extract elements（提取元素）。

步驟 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 生成精靈表，再清理成可進入遊戲的畫素美術。評論裡常見的卡點包括：生成結果難以直接進引擎、動畫幀不夠穩定、清理後仍要大量手工處理。

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

阻力點分析

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

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

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

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

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

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

AI 生成階段通常先得到一張或一組圖，結構資訊後補。VberAI 的 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-06-26T10:00:00+08:00

按一個新手已經試過的順序，用 AI 來做遊戲。先找出製作裡常見的卡住的地方。再用 AI 生成把這些地方做過去。最後把生成結果整理成引擎可以直接匯入的資源。

中間會把幾種工具放在一起看：各自做得到什麼，哪裡還不行。VberAI Studio 是這裡的主要工具。用起來更接近直接用 AI 把遊戲做出來。

費時間的內容製作，交給 AI。

所有經驗

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

這些筆記按一條已經走過的路徑來寫。文件一次回答一個具體問題。