這項由上海大學與新加坡MiAO Worlds公司聯合開展的研究，以預印本形式發布於2026年3月，論文編號為arXiv:2604.18591，研究方向橫跨人機交互與人工智慧生成內容兩大領域。
每一款遊戲背後，都藏著一場鮮為人知的"翻譯戰爭"。
美術設計師耗費數周，精心繪製出充滿異域風情的界面——歪斜的木紋邊框、飄動的魔法紋路、層疊錯落的藥瓶圖標。然後，這份凝聚了無數心血的視覺稿被交到了程序員手中。程序員面對這張截圖，需要一筆一划地測量每個元素的位置、手動裁剪每一個圖片素材、在引擎里一層一層地搭建嵌套結構，最終把這幅"畫"還原成引擎能夠真正運行的代碼。這個過程枯燥、耗時、且極易出錯，行業里稱之為"設計到引擎的苦差事"。
更麻煩的是，遊戲界面偏偏是所有數字界面里最難對付的一種。手機App的界面規規矩矩，按鈕是方的，文字是橫排的，布局遵循統一的網格邏輯；但遊戲界面完全不同，它的血條可能是一截彎曲的龍骨，技能圖標可能嵌在一面盾牌的浮雕里，整個界面可能像古捲軸一樣層層展開。現有的那些"截圖轉代碼"工具，基本上都是為規整的網頁和App設計的，一碰到遊戲界面就徹底懵圈——它們根本不理解這種不規則的形狀，更不知道該如何在引擎里還原那些深度嵌套的層級關係。
正是為了解決這個痛點，來自上海大學和MiAO Worlds的研究團隊開發了一套名為SPRITE的系統。SPRITE這個名字既是首字母縮寫（Screenshot Parsing and Reconstruction of Interfaces via Training-free Engineering，即"無需訓練的截圖解析與界面重建工程"），也暗合了Unity引擎中最基礎的2D圖形元素——精靈圖（Sprite）。這套系統的目標只有一個：給程序員一張遊戲界面截圖，它自動吐出引擎可以直接使用的完整工程文件。
一、這個問題到底有多棘手？從"畫"到"代碼"的鴻溝
要理解SPRITE為什麼值得關注，得先搞清楚遊戲界面開發的痛點究竟在哪裡。
假設你是一名遊戲程序員，設計師給了你一張RPG遊戲的商店界面截圖：左上角有一個帶金屬鉚釘的面板作為背景，面板里擺著一排商品格子，每個格子裡有道具圖標、數量標籤和價格，右下角有一個火焰紋樣的購買按鈕，整個界面還疊加在遊戲場景的模糊背景上。你的任務是在Unity引擎里把這個界面"搭"出來。
首先，你要把每個元素從截圖里裁出來——背景面板、每個格子、圖標、按鈕，每個都需要是透明背景的PNG格式。裁的時候，金屬面板的邊緣是不規則的鋸齒形，火焰按鈕的輪廓更是沒有任何直線，這些都只能手工處理。裁完之後，你要在引擎里一個一個地擺放這些元素，調整它們的位置、大小、層級關係——哪個在上面，哪個藏在哪個容器里。最後還要寫代碼，讓按鈕能點擊，讓數量能更新。
這整個流程，有經驗的開發者做一個複雜界面往往需要數天。而且一旦設計師改了稿，這個流程就要重來。
現有的AI輔助工具為什麼幫不上忙？關鍵原因在於，那些工具的"世界觀"里，界面就是一堆矩形盒子堆在一起，跟HTML網頁沒什麼兩樣。而遊戲引擎的邏輯完全不同：它用絕對坐標定位元素，用深度層級管理遮擋關係，元素的形狀可以是任意不規則的多邊形，根本沒有CSS那套"流式布局"的概念。哪怕是GPT-4V或者Gemini這樣的頂級多模態大模型
，面對遊戲界面時也只能框出一堆矩形框，無法真正理解它的結構。
於是，這個領域長期存在一道鴻溝：一邊是藝術家的創意視覺稿，一邊是工程師的引擎實現，中間靠人工苦苦銜接。
二、SPRITE的核心思路：先讀懂結構，再精確提取，最後生成代碼
SPRITE解決這個問題的方式，可以用"先看懂，再量准，再寫出來"這九個字來概括，對應三個依次進行的階段。
第一階段叫做"語義腳手架構建"。這裡的"語義"，指的是對界面內容的理解，而不僅僅是對像素顏色的識別。SPRITE首先請一個視覺語言大模型（簡單說，就是能同時理解圖片和文字的AI）來看這張截圖，但並不是讓它隨便說說自己看到了什麼，而是要求它按照一個預設好的格式填寫答案。這個格式是用YAML語言寫的——YAML是一種人讀起來很順眼、機器也容易處理的結構化文本格式，長得有點像帶縮進的購物清單。
研究團隊為這個AI設計了一個特殊的"角色提示"，稱為"UI大師"人格，要求它以資深遊戲UI開發者和系統架構師的身份來分析界面。這個提示背後有三個核心設計意圖：第一，讓AI專注於功能邏輯，過濾掉視覺上的裝飾性噪聲；第二，強制AI為每個元素填寫"父級"欄位，從而把一個平面的元素列表變成一棵真正的層級樹；第三，讓AI為每個元素寫一段視覺描述，這段描述將在下一階段指導精確的圖像分割模型。
為什麼選YAML而不是更常見的JSON格式？這裡有一個精心考量：YAML省去了大量的括號和引號，同樣的內容用YAML寫比用JSON寫要少20%到30%的字符，意味著AI可以用同樣的"思考額度"處理更密集的界面內容。更妙的是，YAML靠縮進來表示層級關係，這和Unity引擎的UXML格式（Unity用來描述界面結構的標記語言）在結構上天然吻合，為後面的代碼生成鋪好了路。
經過這一階段，系統得到的是一份"知道各個元素是什麼、它們怎麼嵌套、大概在哪裡"的結構草圖，但坐標還是模糊的估計值，資產文件也還沒有提取出來。
第二階段叫做"精準定位與資產提取"。大模型的優勢在於理解語義，但它的短板恰恰是精確的空間定位——讓它說"按鈕大概在右下角"沒問題，讓它給出精確到像素的坐標就力不從心了。所以第二階段引入了專門做圖像識別的"2D視覺基礎模型"來彌補這一短板。
具體來說，系統用第一階段生成的視覺描述作為查詢條件，驅動GroundingDINO模型在截圖上做開放詞彙目標檢測——簡單說，就是"找到那個帶金屬鉚釘的深色半透明面板在哪裡"這樣的任務。定位到大致區域之後，再用SAM2（Segment Anything Model 2，一個專門做精確圖像分割的模型）來描繪出元素的精確輪廓，哪怕是火焰紋樣的不規則邊緣也能準確勾勒出來，並導出帶透明通道的PNG文件。
但提取素材之後，還有一個容易被忽視的問題：被提取出來的元素原本是疊壓在背景上的，把它拿走之後，背景就會留下一個空洞。如果不處理這個空洞，背景圖就無法單獨使用。於是系統還調用了LaMa（一個專門做圖像修復的模型）來做"背景補全"，把那個空洞用合理的背景內容填滿，確保每一層資產都是乾淨、可用的獨立圖片。
完成這一階段後，YAML文檔里的坐標從模糊估計變成了精確的像素值，每個元素也都有了對應的資產文件路徑。這份文檔完成了從"知道結構"到"知道確切位置和對應文件"的升級。
第三階段叫做"引擎原生合成"。有了這份精確的YAML文檔，最後一步就是讓另一個大語言模型把它翻譯成Unity引擎能直接讀取的代碼。研究團隊使用了GPT-5和Claude 4.5 Sonnet兩個模型來完成這項工作，採用了"少樣本提示"（給模型幾個示範例子）加上"思維鏈推理"（讓模型一步步思考）的方式，確保生成的UXML和USS代碼嚴格遵循第二階段確定的層級結構。
系統不僅生成界面的靜態結構代碼，還會根據元素的語義標籤推斷出基本的交互行為——比如，被標記為"Button"的元素會自動獲得滑鼠懸停狀態的樣式，被標記為"Toggle"的元素會獲得開關邏輯。這樣生成出來的不只是一個靜態的界面骨架，而是一個可以立即在引擎里運行、響應用戶操作的功能性原型。
此外，團隊還集成了FLUX圖像生成模型，讓用戶可以用文字描述來改變某個素材的視覺風格，比如"把這個按鈕改成電馭叛客風格"，從而把整套系統從純粹的重建工具擴展成了創意輔助工具。
三、評測：用真實的工業級素材檢驗，結果如何？
為了測試SPRITE的實際效果，研究團隊沒有用現成的通用數據集，而是專門構建了一個面向遊戲場景的基準數據集，命名為GAMEUI Benchmark。
這個數據集收錄了來自多種遊戲類型的界面——包括角色扮演遊戲（RPG）的裝備背包、第一人稱射擊遊戲（FPS）的戰鬥抬頭顯示器、策略遊戲的城建面板，以及休閒遊戲的關卡選擇界面，覆蓋了從簡潔主菜單到密密麻麻的物品欄等各種複雜程度。這些都是從真實工業生產環境中篩選出來的高保真界面，每一個條目都配有完整的配套資料：Figma設計軟體導出的JSON結構文件（記錄了專業設計師定義的層級關係和交互元數據）、手工分割好的精靈圖素材、以及由有經驗的開發者手寫的Unity UXML和USS代碼（作為評判生成代碼質量的標準答案）。研究團隊表示，這個數據集目前還在持續擴充中，會逐步覆蓋更多遊戲UI功能模組。
在這個數據集上，團隊做了兩類評估。
第一類是素材提取質量的對比測試。研究團隊把SPRITE的提取結果和兩類現有方案做了直觀比較：一類是直接用Claude-4.5或Qwen3-VL這樣的視覺大模型來做目標檢測，另一類是不經過語義腳手架階段、直接用GroundingSAM做分割的基線方案。
結果相當清晰。直接用視覺大模型的方案，輸出的只是一堆矩形框，對於火焰按鈕、異形圖標這類不規則元素完全無能為力——矩形框切出來的要麼缺了一塊要麼多了一堆背景，根本不能直接用。不經語義引導直接分割的方案能勾出大致輪廓，但會出現嚴重的"碎片化"問題：本來一個完整的面板，因為沒有語義約束，模型不知道哪些像素應該歸為一組，於是把它切成了七零八落的幾十個碎片，完全不可用。SPRITE因為在分割之前先建立了語義層級，知道"這是一個整體的背景面板，不是很多個獨立的零件"，所以能夠輸出輪廓精確、語義完整、透明通道乾淨的素材文件。
第二類是專家評審。三位資深遊戲UI/UX設計師參與了這次評估，他們在GAMEUI Benchmark上實際操作了SPRITE生成的功能原型，並對自動分割出來的素材、界面的層級結構以及UXML源代碼進行了逐項審查。評分採用10分制，1分代表完全無法使用，10分代表可以直接投入生產。
在"視覺保真度"方面，SPRITE獲得了8.5分——專家們確認，重建出來的界面在視覺上與原始截圖高度吻合，素材質量符合行業標準。在"層級邏輯"方面，SPRITE獲得了8.0分，專家們認為自動生成的嵌套結構合理，符合專業開發者的預期。在"交互準確性"方面，SPRITE獲得了7.0分，這是三項中最低的，專家們指出系統目前只能推斷基礎交互行為，對於更複雜的時序邏輯無能為力。
這個7.0分背後對應的，是SPRITE目前已知的幾類局限性：當界面里有大量半透明元素相互疊壓時，分割模型難以確定遮擋關係；對於高度抽象的"敘事型界面"（比如那種把界面元素偽裝成遊戲世界裡真實物品的設計），視覺邊界本身就很模糊，系統也會犯錯；最關鍵的是，拖拽、複雜動畫曲線、狀態機跳轉這類需要時序推理的交互邏輯，完全超出了當前系統對單張靜態截圖的理解能力。不過，專家們仍然認可了這套系統作為快速原型工具的實用價值，並對團隊提出的改進方向表示期待。
四、這套系統是為誰設計的，以及它改變了什麼
SPRITE在設計之初，就明確了兩類目標用戶，而且這兩類用戶的需求幾乎截然相反。
對於沒有編程背景的設計師或獨立創作者來說，SPRITE提供的是一條"零代碼"通道：把自己的設計截圖或者手繪草圖丟進去，直接得到一個可以在引擎里跑起來的原型，不需要懂UXML是什麼，不需要知道怎麼配置錨點，不需要手動處理任何素材文件。這極大地降低了創意實現的門檻，讓那些"有想法但不會寫代碼"的人也能直接參與遊戲原型的疊代。
對於有經驗的專業開發者來說，SPRITE做的不是替代他們，而是消除那些重複性的、讓人精疲力竭的"體力活"。那些切圖、擺位置、搭基礎層級結構的工作，原本要占用大量時間，用SPRITE可以在幾分鐘內自動完成，讓開發者把精力集中在真正有技術含量的地方：複雜的狀態機邏輯、性能優化、精細的動畫曲線調整。
這種"既降低門檻又提升效率"的雙重設計，體現了團隊對遊戲開發生態的一個判斷：遊戲UI開發的痛點不只是技術門檻，更是流程中大量低效的手工勞動，而這兩個問題可以用同一套工具的不同使用方式來解決。
五、接下來打算做什麼：三個值得期待的方向
研究團隊在論文裡明確提出了三個後續研究方向，每一個都指向了當前系統的一個真實局限。
當前系統最顯眼的短板是只能處理靜態截圖，無法理解動態交互。團隊計劃引入影片大模型，讓系統能夠分析遊戲玩法錄像或者UI操作的錄屏，從中自動提取動畫時序、狀態機跳轉規則、條件性視覺反饋（比如滑鼠懸停時按鈕從灰色變成金色的效果）。這樣一來，系統輸出的就不僅僅是界面的靜態骨架，而是包含完整動畫控制器和交互事件腳本的運行時邏輯。
另一個方向是把界面的結構（UXML，決定有什么元素、怎麼排列）和樣式（USS，決定每個元素長什麼樣）徹底分離，分別映射到一個可以用文字描述來操控的"潛在語義空間"里。這意味著開發者可以說"把整個界面改成暗黑風格"，系統就自動重新生成符合這個描述的樣式，而不改動任何功能邏輯。這對於需要為同一個遊戲維護多個視覺主題的開發團隊來說極為實用，也為生成式A/B測試打開了大門。
第三個方向相對"軟性"，但同樣重要：研究團隊計劃通過長期跟蹤研究，考察SPRITE這類工具如何改變設計師和程序員之間的協作模式——誰負責什麼、信任如何建立、當自動生成結果出錯時人們如何應對、整個工作流程里的認知負擔發生了怎樣的變化。這個方向的答案，將決定類似工具在真實工業環境裡能走多遠。
說到底，SPRITE想解決的問題，是一個存在於"腦子裡的畫面"和"引擎里能跑的代碼"之間的古老鴻溝。遊戲開發這件事，本質上是把人對世界的想像轉化為電腦的語言，而現有流程里有太多的時間和精力消耗在純粹的機械轉換上，而不是真正的創造性工作。SPRITE用三步流水線——先讀懂結構、再量准位置、再寫出代碼——在一定程度上自動化了這個轉換過程，讓創作者可以更快地看到自己的想法在引擎里運轉起來。
當然，這套系統現在還遠不是"交稿即用"的完成品，7.0分的交互準確性說明它在複雜動態邏輯上仍然需要人工介入。但對於那些日復一日在截圖和代碼之間苦苦搭橋的開發者來說，有一個工具能把最枯燥的那部分工作自動化，已經足夠有價值了。對原論文感興趣的讀者，可以通過arXiv檢索編號2604.18591找到完整的技術細節和實驗數據。
Q&A
Q1：SPRITE系統能處理哪些遊戲類型的界面？
A：SPRITE的GAMEUI Benchmark數據集涵蓋了RPG、FPS、策略遊戲和休閒遊戲等多種類型，從簡單主菜單到密集物品欄都有覆蓋。由於系統採用無需重新訓練的設計，理論上對各種風格和類型的遊戲界面都有一定適應能力，不限於特定遊戲類型。
Q2：SPRITE生成的代碼能直接放進Unity項目用嗎？
A：基本結構和靜態布局部分可以直接使用，專家評分中視覺保真度達到8.5分、層級邏輯8.0分，達到了接近可用的水平。但交互邏輯部分只有7.0分，對於拖拽、複雜動畫這類需要時序邏輯的功能，目前仍需開發者手動補充完善，不能完全免除人工介入。
Q3：SPRITE為什麼不直接用現成的大模型做截圖轉代碼，而要多做一個YAML中間層？
A：直接用大模型生成代碼有兩個致命問題：一是大模型對像素坐標的估計非常不準確；二是無法處理遊戲界面的不規則形狀素材提取。YAML中間層的作用是先用AI理解結構和語義，再用專門的圖像分割模型做精確定位，兩步分工協作，才能同時解決"理解層級關係"和"精確提取素材"這兩個缺一不可的問題。
