先說結論

在本站釋出了 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 就走不下去。

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

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

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

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

小結

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

相關教程