這項由香港中文大學電腦科學與工程系主導的研究，於2026年7月13日以預印本形式發布在arXiv平台，編號為arXiv:2607.11594。研究尚未正式發表於特定期刊，已提交IEEE待審。有興趣深入了解技術細節的讀者，可通過上述編號查閱完整論文。
**當遊戲世界的搭建變成一件苦差事**
做過遊戲的人都知道，哪怕是最簡單的"闖關類"遊戲，也要面對一個令人頭疼的工程問題：你得精心設計每一個場景，還要保證從一個場景跳轉到下一個場景的"門"兩邊完全對得上——目的地對、位置對、視覺特效對——哪一環出錯，玩家就會卡住，或者穿越到一個莫名其妙的地方。更麻煩的是，這種"過場銜接"需要手動維護大量的腳本文件和連接表格，稍有疏漏，整個遊戲世界就會四分五裂。
近年來，藉助大型語言模型（LLM，可以理解為像ChatGPT這樣能讀懂人類語言、並生成各種內容的AI），研究者已經能夠讓AI自動生成單個室內場景——你告訴它"幫我造一間中世紀圖書館"，它就能給你生成一整套帶家具的三維空間。問題是，這些AI每次只能生成一個場景，把它反覆運行幾次，你得到的是一堆互相不認識的"孤島"，根本拼不成一個玩家可以穿行其中的完整世界。
香港中文大學的研究團隊為此設計了一套名為MAGIC的系統——全稱是"Multi-scene Automated Game worlds generator with Intelligent Connectivity"，直譯過來就是"帶智能連接能力的多場景自動遊戲世界生成器"。它的目標很直接：你只需要用普通的語言描述你想要的遊戲世界，MAGIC就會自動幫你生成多個場景，並把它們用可以正常使用的"傳送門"連接起來，最終打包成一個可以直接在Unity遊戲引擎里運行的項目。
---
一、三塊絆腳石：為什麼簡單地重複用AI生成場景行不通
要理解MAGIC解決了什麼問題，先得搞清楚"重複生成"到底會出哪些岔子。
第一個麻煩是"兩邊對不上"。一扇門，在A場景叫"通往地牢的鐵門"，在B場景可能根本就沒有這扇門，或者被叫成了完全不同的名字。這就好比你跟朋友約好"從北京南站坐高鐵過來"，結果朋友去的是北京西站，兩人根本碰不上面。AI在處理多個場景時，隨著資訊越來越多，很容易"忘記"之前說過的約定，導致跨場景的門口資訊對不上。
第二個麻煩是"門被家具堵住了"。即便兩個場景里的門名字一樣、位置一樣，但等到AI把家具、桌椅、書架都擺進去之後，門口可能正好被一張大沙發擋住了。玩家根本走不到門跟前，場景之間的跳轉就徹底失效。這個問題用現有的評估工具完全檢測不出來，因為那些工具只看場景好不好看、對不對題，從不管"門能不能走進去"。
第三個麻煩是"沒有人真的去測"。目前所有評估AI生成3D場景好壞的工具，都只是拿生成結果和參考圖片比一比，或者看看場景是否符合文字描述。沒有任何工具會真正"進入"這個遊戲世界，操控角色走到門口，踢一腳，看看到底能不能跳轉到下一個場景。所以哪怕門被堵死了、跳轉腳本寫錯了，評估系統依然可能給出"優秀"的成績。
MAGIC的設計目標，就是把這三塊絆腳石一塊一塊地搬開。
---
二、MAGIC的四步流水線：一句話變成一個完整遊戲項目
MAGIC的工作方式可以用"建築施工"來理解。建一棟大樓，你需要先畫總平面圖，再細化每個房間的圖紙，再按圖施工，最後把各樓層合併成一棟完整的建築。MAGIC的四個階段，做的是完全類似的事情。
**第一步：規劃階段——畫出整個世界的藍圖**
用戶輸入一段自然語言描述，比如"我想要一個由圖書館、密室和地牢三個區域組成的逃脫遊戲，圖書館和密室之間有一扇滑動書架門，密室和地牢之間有一扇鐵柵欄門"。MAGIC的規劃模組會把這段描述"拆開"，分別提煉出每個場景應該是什麼樣的，同時建立一張"過場地圖"——用數學的方式表達哪兩個場景之間有門、這扇門叫什麼名字、穿越時會有什麼視覺特效（目前支持"漸入漸出"和"光圈收縮"兩種效果）。
這張過場地圖被稱為"過渡感知自動機"，它就像建築師手裡的總平面圖，所有後續步驟都要參照它。為了確保這張圖的準確性，系統會用第二個AI模型反覆校驗：每個場景里應有的門的數量和類型，都會被統計一遍，有缺漏的話就重新生成，直到完全吻合。這一步直接解決了"兩邊對不上"的問題——因為所有場景都必須以這張共同的藍圖為準。
**第二步：場景規格化——把每個房間細化到每一件家具**
有了總藍圖之後，MAGIC開始針對每個場景分別展開設計。這一步相當於設計師把總平面圖細化成每個房間的詳細裝修方案。
系統首先把場景描述擴展成包含8到12件物品的詳細清單，然後把場景劃分成若干區域（比如圖書館可以分成閱覽區、書架區、入口區），給每個區域分配合適的家具。所有家具的擺放位置，會按照一套領域專用語言（可以理解為一種專門描述"誰在哪裡、朝哪個方向"的格式化語言）生成初稿，再由校驗模組逐條檢查是否違反規則，有問題就重新生成，直到所有約束都滿足為止。
門和窗戶的處理有額外講究。系統會精確計算AI給出的門的位置和牆壁之間的距離，然後把門"推"到離牆最近的位置，再向內側偏移半個門厚度，讓門看起來更自然地嵌在牆裡。所有被標記為"傳送門"的門，都會被打上特殊的"isPortal"標籤，後續各階段可以通過這個標籤精準找到它們。
這一步最關鍵的設計，是用來檢測"門有沒有被堵住"的洪水填充算法。這個算法的工作原理類似於在房間地圖上"倒水"：從傳送門的位置開始，讓"水"向四面八方流動，經過所有沒被家具占據的空格。如果水能流遍整個房間，說明傳送門從任何位置都能走到；如果有些地方水流不進去，說明那裡被家具堵死了，需要重新調整擺放方案。
具體來說，算法會把整個場景轉換成一張細密的網格地圖，每個網格格子的邊長只有0.05個單位（大約是一根手指的寬度），標記出哪些格子被家具占用、哪些是可以行走的空地。然後從傳送門出發，用"廣度優先搜索"（一種電腦找路的方式，類似於水往低處流）擴展可達區域。最終，可到達格子數占全部可走格子數的比例，就是這個場景的"連通率"。連通率達到100%，才算通過；否則，系統會重新調整家具擺放，直到達標或者嘗試次數耗盡——耗盡時，會保留連通率最高的那個方案。
這一步直接解決了"門被家具堵住"的問題。
**第三步：場景生成——把圖紙變成真實的3D項目**
有了詳細的場景規格之後，MAGIC調用Scenethesis（一個專門根據規格生成3D模型的系統）來生成所有家具、牆壁、地板的三維網格。與此同時，系統會根據場景規格里的傳送門資訊，自動生成對應的"關卡加載腳本"（LevelLoader script）——這是Unity遊戲引擎里負責"當玩家走到這扇門時，跳轉到哪個場景"的程序代碼。
這裡有一個工程細節值得一提：系統是把關卡加載腳本掛在門這個物體上，而不是掛在玩家角色上。原因是如果掛在玩家角色上，觸發機制會變得不穩定，容易出現"明明走到門口了卻沒反應"的情況。掛在門上之後，只要檢測到玩家的攝像機碰撞了這扇門，就自動觸發跳轉，穩定性大大提高。
這個階段用的是模板填充方式，而不是讓AI"自由發揮"寫代碼。這樣做的好處是：生成出來的腳本保證能運行，不會因為AI寫了個語法錯誤的代碼而導致整個項目崩潰。
**第四步：整合——把散件拼成完整的遊戲**
前三步對每個場景分別執行一遍，最終得到若干個獨立的Unity項目文件。第四步做的事情，就是把這些散件合併成一個完整的Unity多場景項目，讓場景之間的跳轉腳本能夠正確引用彼此。這一步本質上是文件管理和路徑整合，技術上相對簡單，但對於用戶來說是最直觀的——你打開最終項目，就是一個可以運行、可以在場景之間穿梭的完整遊戲世界。
---
三、那個"真正進入遊戲測試"的評估探員
MAGIC不只是生成工具，研究團隊還為它配套設計了一個全新的評估機制——一個真正會"進入遊戲、走到門口、踢一腳看看能不能過去"的自動化評估探員。
這個探員的工作流程分四個階段。第一步，它掃描遊戲項目里所有可能是傳送門的物體，列出候選名單。第二步，它挨個測試這些候選傳送門——讓遊戲角色去碰一下，看看有沒有觸發場景跳轉，如果有，就記下跳到了哪裡。第三步，對於那些真實有效的傳送門，探員讓角色從出生點出發，嘗試走到傳送門跟前，檢驗它在實際遊戲中是否能被玩家接近；同時對傳送門拍一圈環繞照片，把照片送給多模態大語言模型（能同時理解文字和圖片的AI）判斷，這扇門的外觀是不是和描述的"滑動書架門"或"鐵柵欄門"相符。第四步，把所有場景的測試結果匯總，對照預先設定的"標準答案"（即規劃階段生成的過場地圖），計算精確率、召回率、F1分數、接近率和傳送門外觀匹配率五項指標。
這五個指標可以這樣理解：精確率是"AI生成的傳送門中，有多少是真實需要的"；召回率是"所有應該有的傳送門中，有多少被正確生成了"；F1分數是這兩者的綜合評分；接近率是"生成的傳送門中，有多少是玩家實際上能走到的"；傳送門外觀匹配率是"傳送門的長相和描述是否相符"。
為了驗證這個探員靠不靠譜，研究團隊讓兩名人工評審員對20個測試案例逐一手動檢查，然後把人工結果和探員結果做對比。結果顯示，探員和人工判斷的差距極小，各項指標的平均絕對差僅為0.0299——換句話說，這個探員的判斷和人類幾乎一致。
研究團隊還額外做了兩組對比實驗。第一組（消融實驗1）去掉了"候選傳送門提取"這一步，直接讓探員檢查所有物體——結果是探員被大量無關物體淹沒，耗時暴增到每個場景超過1000秒，而且判斷準確性嚴重下降。第二組（消融實驗2）保留了候選提取，但把"拍照送給AI看外觀"換成"只看傳送門的名字來判斷外觀"——結果在外觀匹配率上明顯差於完整版探員。完整版探員每個場景只需約40秒，各項指標也最接近人類判斷。
---
四、測試場地：100個多場景案例的擂台
研究團隊構建了一個包含100個測試案例的專用基準數據集。這些案例來自兩個公開數據集的組合：一個是MIT 67室內場景數據集，包含廚房、臥室、圖書館、健身房等67類功能各異的室內場景；另一個是MMIS多模態室內場景數據集，提供了不同設計風格的室內圖像和文字描述。
每個測試案例是一張"場景圖"，節點是具體的室內場景，邊是場景之間應有的跳轉關係。案例規模從單個場景到五個場景互聯不等，跳轉模式涵蓋線性、環形和樹狀分支等多種拓撲結構，傳送門類型也有統一類型和混合類型兩種。最終，每個結構化案例都被轉化為一段自然語言描述，作為MAGIC和對比方法的輸入。
---
五、和競爭對手比，MAGIC贏在哪裡
MAGIC在每個階段都和兩類對比方法做了比較：一類是直接用GPT-4.1提問（LLM基線），另一類是Holodeck（一個已有的單場景生成系統）。
在規劃階段，MAGIC生成的場景描述準確率達到0.97，過場地圖的圖結構準確率達到0.97，均優於LLM基線的0.92和0.91。兩者都依賴語言模型的理解能力，但MAGIC額外加入了驗證循環，使得過場地圖更加可靠。
在場景規格化階段，三種方法在傳送門生成的精確率上相差不大，但在召回率（即"應該有的傳送門有沒有全生成出來"）上差距明顯：MAGIC的召回率達到0.95，LLM基線為0.92，Holodeck只有0.60。連通率（即"傳送門有沒有被家具堵死"）上的差距更大：MAGIC達到0.9952，幾近完美；LLM基線為0.87；Holodeck最低，只有0.85，而且它的場景密度最高（占用率接近40%），說明它放了很多家具但通道卻最差。MAGIC的場景密度接近28%，屬於"不太稀疏、也不太擁擠"的平衡狀態。
在場景生成階段，MAGIC對所有100個測試案例均成功生成了可運行的Unity項目，成功率100%。LLM基線則一個都沒成功——原因在於它對Unity的文件結構和腳本規範了解不足，哪怕只是文件命名出了一點點差錯，整個項目就無法打開。此外，LLM基線在將近一半的案例中生成了"多餘的跳轉腳本"，導致玩家走到某個地方會意外彈到一個不該去的場景。
在端到端評估中，MAGIC的最終表現是：精確率0.99、召回率0.95、F1分數0.96、接近率0.95、傳送門外觀匹配率0.79。前三項都超過了0.9，說明絕大多數該有的跳轉都被正確生成，且幾乎沒有多餘的錯誤跳轉。接近率同樣接近0.95，意味著生成的傳送門中大約95%是玩家實際上能走到的。外觀匹配率稍低，是因為AI的外觀判斷標準比較嚴格，比如"指示牌"這個傳送門，AI生成了一塊普通的板子，但判斷模型認為板子上沒有明顯的"指示"功能證據，所以判定不匹配——這屬於物體模型庫覆蓋範圍的局限，而不是流水線本身的問題。
值得一提的是，研究團隊發現，測試案例的場景數量從一個增加到五個，MAGIC的各項表現並未出現明顯下滑。這說明在測試範圍內，流水線的質量不會隨著項目規模增大而急劇惡化。不過研究團隊也坦誠地指出，由於測試範圍僅到五個場景，更大規模的外推還需要更多驗證。
---
六、MAGIC目前還做不到什麼
研究團隊對系統的局限性做了誠實的陳述，這些邊界同樣值得了解。
目前MAGIC只支持室內場景，戶外或大型開放世界不在它的能力範圍之內。它只能在Unity引擎上運行，其他引擎（如Unreal Engine）尚不支持。過場特效只有兩種（漸入漸出和光圈收縮），如果遊戲設計需要更豐富的過場動畫，還得另外開發。輸入語言只支持英文。傳送門的外觀受限於物體模型庫的覆蓋範圍，庫里沒有的東西生成出來可能"形似而神不似"。家具擺放是盡力而為，當重試預算耗盡時，系統會返回當前連通率最高的方案，所以少數情況下仍可能有極小區域的遮擋。
在研究方法層面，測試案例的"標準答案"是用程序腳本自動生成的，而不是由人工設計師手動創建，這意味著標準答案本身可能存在一定的人工設計偏差。每個案例只跑了一遍，沒有重複多次取平均，也沒有做統計顯著性檢驗，所以給出的數字是單次運行的點估計，存在一定的隨機波動。人工評審只參與了20個案例的對比驗證，兩名評審員的樣本量也偏小。
---
歸根結底，MAGIC做的這件事，是把一個通常需要遊戲開發團隊花費大量時間手工維護的工作——設計多個室內場景並保證它們之間的門全部可以正常穿行——變成了一個任何人輸入一句話就能啟動的自動流程。
從實際效果看，100個測試案例中每一個都能生成可運行的項目，超過95%的該有的傳送門被正確生成，且絕大多數傳送門都沒有被家具堵死，玩家能夠順利走到。這對於一個完全自動化的系統來說，已經是相當可靠的表現。
當然，目前的版本還有不少約束：只在室內、只在Unity、只有英文、只有兩種特效。如果你是一位獨立遊戲開發者，這些限制可能會讓你覺得"離我能直接用還有點距離"。但如果你只是想快速做個遊戲原型，或者想看看AI能不能幫你搭出一個可以"走進去轉一圈"的三維草稿，MAGIC已經能給出一個完整的、可以打開運行的答案。
未來的可能方向，研究團隊提到了幾個：支持玩家主動觸發傳送的動作（比如按鍵而不只是走到門口），允許人工在某個中間階段介入修改（比如調整場景規格再讓後面的步驟繼續執行），以及把整套流程推廣到室外場景和其他遊戲引擎。這些方向每一個都足以支撐一篇獨立的論文，足見這個領域還有相當大的探索空間。
對AI輔助遊戲開發感興趣的讀者，可以通過arXiv編號2607.11594查閱完整論文，也可以訪問論文中提供的代碼倉庫，直接跑起來試一試。
---
Q&A
Q1：MAGIC生成的遊戲場景可以直接在Unity里打開玩嗎？
A：可以。MAGIC的最終輸出就是一個完整的Unity項目文件，用Unity打開後可以直接運行，玩家操控攝像機在場景里走動，走到傳送門就會跳轉到下一個場景，不需要額外的手動配置。在100個測試案例中，每一個都成功生成了可以運行的項目。
Q2：MAGIC用的洪水填充算法是怎麼判斷門有沒有被堵住的？
A：算法把整個場景轉成一張細密的網格地圖，把家具占用的格子標成"障礙"，其餘的標成"可走"。然後從傳送門的位置出發，像倒水一樣讓標記向四周擴散，只能流過可走的格子。擴散結束後，如果擴散覆蓋了所有可走格子，說明門沒有被堵死；如果有死角擴散不到，說明有障礙擋路，系統就會重新調整家具擺放。
Q3：MAGIC的評估探員和人工檢查相比準確性怎麼樣？
A：研究團隊用20個測試案例做了對比，讓人工評審員逐場景手動檢查每扇門能否正常觸發跳轉，然後和探員的結果做對比。各項指標的平均絕對差只有0.0299，說明探員的判斷和人類幾乎一致，同時每個場景只需約40秒，遠比人工高效。
