這項由Alaya Lab主導的研究發表於2026年7月，論文編號為arXiv:2607.14076v1，有興趣深入了解的讀者可以通過該編號查詢完整論文。
你有沒有想過，當你在遊戲裡按下攻擊鍵的那一刻，背後究竟發生了什麼？螢幕上的角色不是直接就揮出了拳頭——遊戲引擎要先偷偷查一遍你的體力值夠不夠、技能有沒有在冷卻、敵人此刻的姿勢是不是可以被擊中，確認所有條件都符合規則之後，才把對應的畫面渲染出來。這套"先查規則、再出畫面"的流程，是傳統遊戲引擎幾十年來運轉的核心秘密。
然而，人工智慧領域正在興起一種截然不同的思路：能不能訓練一個AI模型，讓它直接從大量遊戲影片中學會這套規律，然後自己充當一個遊戲引擎，實時生成玩家操作後應該看到的畫面？這種被稱為"交互式世界模型"的技術，近年來引發了學術界和工業界的廣泛關注，許多人認為它代表著下一代遊戲引擎的雛形。
但問題也隨之而來：這類AI模型到底做到了什麼，又在哪些地方還差得遠？Alaya Lab的研究團隊決定系統性地審視這個問題。他們以傳統遊戲引擎的運轉邏輯為參照系，把"一個合格的AI遊戲引擎應該具備哪些能力"這件事拆解成四個維度，逐一檢視現有的各類方法，分析每種方法的優勢和局限。與此同時，他們還圍繞知名動作遊戲《黑神話：悟空》構建了一套數據採集系統，收錄了超過90小時的實戰遊戲錄像，每一幀都附帶玩家的鍵鼠操作記錄、遊戲引擎導出的真實狀態數據以及視覺畫面，為未來研究提供了一份難得的資源。
---
一、遊戲引擎的"運轉秘籍"：一個被大多數AI忽視的循環
要理解這篇研究在說什麼，先要搞清楚傳統遊戲引擎是怎麼工作的。可以把它的運轉方式比作一場不停歇的接力賽：玩家輸入動作，動作傳給裁判（遊戲狀態系統），裁判根據規則判斷結果並更新比賽局面，最後畫師（渲染系統）把更新後的局面畫出來給玩家看。這三個環節——動作、狀態、畫面——構成一個反覆循環的閉環，遊戲世界就在這個循環里一刻不停地演進。
關鍵在於中間那個"狀態"環節。遊戲引擎始終維護著一份精確的賬本，記錄著場景中每一個角色的血量、體力、所處位置、當前動畫幀、裝備屬性等等。玩家按下攻擊鍵，引擎不是直接生成攻擊畫面，而是先翻開賬本核查——你的體力夠發動這個技能嗎？對方正處於可被打斷的狀態嗎？攻擊判定框和對方的碰撞體積有沒有重疊？一切核查通過之後，賬本上的數字發生變化，對方的血量減少，動畫狀態切換，然後渲染系統才把這一切畫成畫面呈現給你。
現有的AI世界模型，大多數繞過了這個"賬本"環節。它們直接用最近幾幀的畫面作為參考，預測下一幀應該長什麼樣。這種方式確實能生成看起來連貫的畫面，但它把所有的"規則"都壓縮進了像素之間的統計關聯，而不是真正理解底層的邏輯。於是就出現了一些根本性的問題：同樣是按攻擊鍵，血量充足時和血量耗盡時理應有截然不同的結果，但基於像素預測的模型往往分不清這兩種情況；敵人離開視野之後，它的狀態在真實遊戲中還在持續演變，但AI模型根本不知道螢幕外正在發生什麼；某個技能擊中之後，傷害結果應該在規定的動畫幀數之後才顯現，而不是立即跳出數字，但AI的生成時機往往和遊戲規則對不上。
Alaya Lab的研究團隊把這些問題歸結為四個維度：玩家動作控制、遊戲狀態動態、狀態與畫面的持久一致性、實時交互生成。以下的內容，就是沿著這四個維度展開的。
---
二、玩家怎麼"說話"，AI才能聽懂——動作控制的三種語言
遊戲裡的玩家輸入，其實遠比看起來複雜。移動、轉鏡頭，這些是空間幾何上的操作；普通攻擊、閃避，這些是設備上的按鍵信號；而"在boss即將發動大招時找準時機完成反擊"，這種意圖根本沒有對應的按鍵，它需要結合當前的戰場狀態才能被理解。現有的研究方法，基本上沿著三條不同的路線來處理這個問題。
第一條路線可以叫做"幾何語言"。這類方法把玩家的操作理解為攝像機在空間中的運動軌跡，用數學上的旋轉矩陣、平移向量或者光線方向來表達"鏡頭往左轉了多少度"。這種方式對於控制視角非常精確，生成出來的畫面在鏡頭移動上表現得相當一致。但問題也很明顯：它只解決了"看哪裡"的問題，對於"做什麼"完全無能為力。而且，要求普通玩家提供精確的攝像機軌跡數據，本身就是一件不切實際的事情。
第二條路線叫做"信號語言"。這類方法直接接收鍵盤和滑鼠的原始輸入狀態——哪些鍵按下了、滑鼠移動了多遠——然後把這些信號編碼成向量，作為生成下一幀畫面的條件。Oasis、Matrix-Game等系統都採用了這個思路。這種方式更接近玩家的真實操作方式，而且對於簡單、原子性的操作，比如"前進"或者"射擊"，效果相當不錯。然而，原始信號本身是語義模糊的。同樣是按了某個攻擊鍵，在不同的遊戲狀態下，它可能觸發普通連擊、也可能觸發技能爆發、還可能因為體力不足而什麼都不發生。這種"同一個輸入，多種可能結果"的模糊性，讓模型很難學到正確的映射關係，尤其是那些需要多鍵組合的連招技能。
第三條路線叫做"語義語言"。這類方法用自然語言描述玩家的意圖，比如"向右閃避並發動反擊技能"，讓語言模型來理解這段文字並驅動畫面生成。GameGen-X、Yume等系統走的就是這條路。這種方式最為靈活，甚至可以描述一些傳統按鍵根本無法表達的複雜意圖。但隨著控制粒度越來越細，所需的語言描述也越來越長、越來越複雜，計算代價會急速上升，實時交互變得困難重重。
三種路線各有其擅長的場景，也各有無法迴避的缺陷。幾何語言精準但局限，信號語言自然但語義模糊，語義語言靈活但代價高昂。一個真正完備的交互式遊戲世界，需要能同時處理這三種層次的控制——這目前還是一個未被解決的問題。
---
三、AI的"賬本"在哪裡——遊戲狀態的三種存在形式
如果說動作控制是遊戲引擎的"輸入端"，那麼遊戲狀態就是其"核心處理器"。它決定了同樣的動作在不同條件下會產生什麼不同的結果。現有的AI世界模型，在處理這個問題時大體上走了三條不同的路。
最主流的做法是把狀態"藏進像素里"。這類模型完全不維護任何獨立的狀態表示，只是把最近若干幀的畫面作為歷史記錄，然後根據這些畫面加上當前的動作輸入，預測下一幀畫面應該長什麼樣。Sora、Wan這樣的頂尖影片生成模型，以及遊戲專用的GameNGen、DIAMOND等，都走的是這條路。這種做法的好處是簡單粗暴、效果驚艷——因為繼承了影片生成領域海量數據訓練出來的視覺理解能力，生成的畫面質量相當高。但壞處同樣明顯：遊戲規則被壓縮成了像素與像素之間的統計關係，而不是顯式的邏輯判斷。血量只剩一格和血量滿格時，同一個攻擊的結果理應截然不同，但對於一個只看像素的模型來說，這兩種情況下的畫面輸入看起來可能非常相似，模型很難區分。
第二種做法是維護一個"壓縮的潛藏狀態"。這類方法在模型內部保留一個緊湊的向量表示，專門用來跟蹤遊戲世界的整體狀況，然後隨著每一步操作不斷更新這個向量。強化學習領域的世界模型研究，比如著名的Dreamer系列，就是沿著這條路發展起來的。這種方式不需要遊戲內部的狀態標註數據，可以純粹從影片中學習，因此擴展性比較好。但問題在於，這個內部向量是什麼含義，連訓練它的研究者都說不清楚——它捕捉到的是視覺層面的規律，對於那些由非視覺原因（比如血量數值）驅動的視覺變化，它的表現往往不可靠。
第三種做法是用文字或符號把狀態"寫出來"。這類方法用結構化的文本直接記錄遊戲狀態，比如"玩家當前血量720/1000，體力85/100，正在執行重攻擊第二段動作"，然後把狀態的演變轉化為一個語言推理問題，讓語言模型來預測下一時刻的狀態文本。這種方式的優點是高度可讀、可驗證——任何人都能看懂這些數字代表什麼，也能核查推理是否合理。然而，維護這樣的顯式狀態需要大量帶有精確狀態標註的遊戲數據，而這類數據目前極度稀缺。此外，用離散的文字記錄連續動態的遊戲畫面，本身就存在資訊損失，如何把文字狀態和高質量的視覺生成真正打通，目前還基本上是一片空白。
---
四、"離開畫面之後，世界還在轉"——長時記憶的兩種思路
在真實的遊戲裡，一旦某件事情發生了，它的影響就會永久留存。你把boss打掉了一半血，然後跑開躲避追擊，等你回頭，boss的血量絕對不會自己悄悄恢復。但對於大多數基於畫面預測的AI世界模型來說，畫面內能看到的資訊才是它所知道的全部——一旦某個物體離開了視野，模型就對它發生的事情一無所知，等它再次出現在畫面里時，很可能已經被"悄悄復原"了。
研究人員在這個問題上提出了兩大類解決方案，區別在於記憶里存的是"過去發生了什麼"還是"現在是什麼狀態"。
第一類方法存的是"過去的照片"。它們把歷史幀畫面保存下來，當模型需要參考過去時，就從這個照片庫里檢索出相關的幀。有些方法按時間順序索引，越久遠的幀存得越壓縮；有些方法按空間位置索引，回頭看之前去過的地方時，就把當時拍下的照片調出來作為參考。WorldMem、Infinite-World等系統都採用了類似思路。這類方法在場景相對靜態的情況下表現不錯——你之前看到的那扇門，下次回來還是那扇門。但在動態交互豐富的遊戲裡，這種方法會遇到根本性的困境：你上次看到那棟建築時它完好無損，但在你離開的這段時間裡，一場技能爆炸把它炸掉了一半，照片庫里存的還是完好狀態，一旦你回頭，模型就可能把那棟完好的建築"還原"出來，而不是呈現它應有的殘垣斷壁。
第二類方法存的是"當前的推測"。這類方法的出發點是：既然世界在你看不見的時候還在變化，那就不能只靠存照片，得主動推斷那段時間裡發生了什麼，並更新記憶里的狀態。ActWorld、Hybrid Memory等系統走的就是這條路——它們嘗試跟蹤那些暫時離開視野的動態物體，推算它們在不可見期間的狀態演變。這種方式理論上更符合遊戲世界的運轉邏輯，但代價也更高：推斷需要消耗計算資源，推斷的準確性也難以保證，而且遊戲裡的高頻交互會產生大量細小的狀態變化，每一次都要做出正確的更新決策，這個要求目前還沒有令人滿意的解決方案。
---
五、"快"和"准"的兩難困境——實時生成的速度與時機
一個遊戲世界模型，不只要生成正確的內容，還要在正確的時刻生成出來。這裡面其實藏著兩個截然相反的要求，很少有研究把它們同時說清楚。
第一個要求是"快"：從玩家按鍵到螢幕上看到反應，這個延遲必須極短，否則遊戲會有明顯的遲滯感，影響操控手感。這部分的研究非常活躍，CausVid等工作通過把"需要正向反向同時計算才能生成結果"的雙向擴散模型，蒸餾成"只需正向一步步預測"的快速版本，大幅降低了生成每一幀所需的時間。Matrix-Game 2.0等系統進一步把這套技術和遊戲動作輸入結合起來，在實時速率下完成了交互式畫面生成。
第二個要求則更微妙，可以叫做"準時"：不同的遊戲事件，有它們各自被設計好的發生時機。一次重攻擊，要經歷起手動作、判定激活、收招三個階段，最終的傷害數字不應該在按鍵瞬間就彈出來，而應該在判定幀結束時才顯現。如果AI模型的生成邏輯對這種"事件發生的規定時機"一無所知，它就可能把結果提前展示，或者延遲展示，都會讓玩家覺得遊戲感覺不對勁。
目前的研究幾乎全部集中在縮短生成延遲上，而對"讓效果在正確時機出現"這件事幾乎沒有涉及。Yume-1.5等系統展示了在滾動生成的影片流中動態切換文本指令的能力，但事件觸發的具體時機仍然由模型自身的生成先驗決定，沒有任何機制把它和遊戲規則定義的判定時機對齊。這是一個被大多數研究者忽略、卻對實際遊戲體驗影響深遠的問題。
---
六、一套專門為《黑神話：悟空》打造的數據採集系統
研究團隊不只是提出了理論框架，他們還針對現有數據的不足，親手構建了一套數據採集系統。選擇《黑神話：悟空》作為目標並非偶然——這款基於虛幻引擎開發的3A動作角色扮演遊戲，擁有極高的畫面質量和豐富的戰鬥機制，boss戰場景中頻繁的攻防交互和持續的狀態演變，正是研究遊戲世界模型最理想的實驗場。
數據採集的核心難題在於如何把遊戲畫面和遊戲內部狀態同步對齊。研究團隊對遊戲引擎進行了插樁改造，讓引擎在每一個計算幀（tick）都導出一條結構化的數據記錄，涵蓋當前幀的玩家輸入、攝像機位置和旋轉參數、玩家角色與boss的位置、朝向、當前動畫狀態、技能激活情況，以及血量、體力、攻擊力、防禦力、裝備資訊等遊戲屬性。這些數據以JSON格式實時寫入本地文件，每一幀都帶有系統時間戳。
在畫面記錄方面，研究團隊採用了一套基於ReShade和OBS Studio的分割畫面錄製方案。ReShade著色器把顯示區域分割成若干子窗口，分別呈現RGB彩色幀和深度圖，同時通過禁用相關渲染通道把遊戲UI界面剝離，保留乾淨的遊戲世界畫面。OBS Studio被改造為同步記錄每一幀畫面對應的系統時間戳，從而和引擎側的數據記錄建立共同的時間基準，實現幀級別的精確對齊。
數據來源是眾包玩家群體，他們技術水平參差不齊、遊戲風格各異，自然地產生了多樣化的行為數據，避免了單一風格導致的數據偏差。最終收集到的數據集包含超過90小時的1280×720解析度、30幀每秒的遊戲錄像，並經過時間戳對齊、異常幀過濾、卡頓檢測和跨流一致性校驗等處理流程，形成了可直接用於模型訓練的樣本。
在數據標註層面，研究團隊還設計了兩種形式的文本化描述。第一種叫"槽位標註"，把固定長度時間窗口內的動作和狀態記錄按照結構化模板轉寫成文字，保留了所有精確的數值資訊，但用結構化文本替代了引擎內部的數字編號。第二種叫"語義標註"，由Qwen3系列的大型視覺語言模型結合採樣幀畫面和對應的動作狀態記錄自動生成，用流暢的自然語言描述玩家在這段時間裡做了什麼以及遊戲狀態發生了怎樣的演變。這兩種標註可以分別用作下一狀態預測的監督信號和視覺生成的狀態條件輸入，為未來的狀態感知遊戲世界模型提供了現成的訓練材料。
---
七、這一切意味著什麼——現狀的客觀評估與未來的方向
說到底，這篇研究做的事情，是在一片熱火朝天的領域裡冷靜地畫出一張地圖——告訴大家，哪些山頭已經被占領了，哪些山頭還根本沒人去過。
在已經取得顯著進展的方向上，玩家動作的接入方式越來越自然，從最早只能處理離散的Atari按鍵，到現在能夠理解鍵鼠信號和自然語言指令，覆蓋範圍大幅擴展。可探索的場景質量也在快速提升，最新的影片生成骨幹模型已經能夠產出接近真實遊戲截圖水準的畫面。生成速度方面，通過蒸餾和流式生成技術的組合，已經有系統實現了接近實時的幀率，這在幾年前是不可想像的。
然而，最核心的那個問題——讓AI真正理解並執行遊戲規則——依然基本上懸而未決。絕大多數模型把遊戲狀態埋進像素里，把規則壓縮成視覺統計，這意味著它們在處理"結果取決於當前狀態"這類邏輯時，表現相當不可靠。如何把顯式的遊戲狀態真正納入生成循環，如何讓記憶系統在狀態發生變化時做出正確的更新，如何讓事件結果在規則要求的時刻而不是模型認為合適的時刻出現，這三件事構成了當前這個領域最迫切需要解決的核心挑戰。
研究團隊構建的《黑神話：悟空》數據集，正是為攻克這些挑戰預備的彈藥。在此之前，帶有精確狀態標註的遊戲數據極度稀缺，使得所有想要探索顯式狀態建模的研究都缺乏充足的訓練素材。這個數據集的價值，在於它把遊戲引擎內部的完整狀態資訊和畫面錄像進行了幀級別的對齊記錄，使得研究者第一次可以在一個高質量的真實遊戲環境中，直接訓練和評估那些把狀態作為顯式變量的模型。
歸根結底，這項研究想說明的是：讓AI真正讀懂遊戲世界的規則，不是一個影片質量的問題，而是一個邏輯理解的問題。生成漂亮的畫面已經不再困難，但讓AI知道在什麼條件下應該生成什麼樣的畫面，仍然是一段相當漫長的路。如果有一天，AI世界模型能夠真正復現出"按攻擊鍵 → 查體力 → 判斷結果 → 渲染畫面"這套遊戲引擎的核心邏輯，那才算是真正意義上的下一代遊戲引擎。現在的技術，還停在學習遊戲"長什麼樣"的階段，距離真正理解遊戲"為什麼這樣"，還有一段關鍵的距離需要跨越。
---
Q&A
Q1：交互式遊戲世界模型和傳統遊戲引擎有什麼本質區別？
A：傳統遊戲引擎依靠工程師手寫的規則運轉，每一種遊戲邏輯都需要明確編程。交互式遊戲世界模型則是通過大量遊戲錄像訓練AI，讓模型自己摸索出規律來預測玩家操作後應該出現的畫面。前者的規則精確可控，後者免去了手工編程，但目前的AI模型大多只學到了"視覺上應該長什麼樣"，還沒真正學會"在什麼條件下應該發生什麼"，比如血量不足時攻擊應該失敗這類邏輯判斷仍然不可靠。
Q2：《黑神話：悟空》的數據集和普通遊戲錄像有什麼不同？
A：普通遊戲錄像只有畫面。這個數據集的特殊之處在於，每一幀畫面都同步附帶了遊戲引擎內部導出的完整狀態數據，包括角色血量、體力、位置、當前動畫狀態等精確數值，以及玩家當時的鍵鼠輸入記錄。這種"畫面加狀態加操作"的三元對齊，讓研究者可以訓練那些需要理解遊戲狀態才能做出正確預測的模型，而不只是學習畫面之間的視覺規律。
Q3：遊戲狀態"藏進像素里"和"寫出來"這兩種方式各自有什麼問題？
A：把狀態藏進像素里的方式，優點是不需要任何額外標註，可以直接從大量影片裡學習，視覺質量高，但模型無法真正區分"血量充足"和"血量耗盡"這類只有數值差異的情況，導致相同輸入在不同狀態下應有不同結果時表現混亂。用文字把狀態寫出來的方式，優點是邏輯清晰可驗證，但需要大量精確的狀態標註數據，而且離散的文字描述和連續動態的遊戲畫面之間如何打通，目前還基本上沒有成熟的方案。
