2016年,AlphaGo
打敗李世石那會兒,很多人第一次意識到一件事:如果一個系統能被清晰地判斷輸贏,它就能通過自我對弈瘋狂進步。
圍棋有規則,輸贏分明,這是它能被強化學習馴服的根本原因。
那問題來了:為什麼寫代碼的AI(比如各種Coding Agent)也進步神速,但生成3D場景、生成影片的AI卻總感覺卡在半山腰?
這篇來自新加坡國立大學、香港科技大學等機構聯合發布的論文,給出了一個挺扎心的答案:不是數據不夠多,也不是算力不夠猛,而是這類任務從根上就缺一個"判卷子的人"。
而他們找到的答案,有點意外:遊戲引擎。
一、代碼為什麼能進步這麼快
先說清楚一件事,寫代碼的AI能突飛猛進,靠的不是代碼本身有多特殊,而是代碼這個東西天生自帶"判官"。
你寫一段代碼,編譯器立刻能告訴你語法對不對,測試用例能告訴你邏輯對不對,運行時能告訴你會不會崩潰。
這套反饋機制被稱為RLVR(強化學習+可驗證獎勵):一種讓AI通過明確的對錯信號自我疊代的訓練方式,DeepSeek-R1等推理模型的爆發式進步都靠它。
這套機制的關鍵不在於"代碼"這兩個字,而在於它提供了兩層驗證:一層是廉價、客觀、可自動化的機器驗證(編譯器和測試跑一下就知道對不對),另一層是人類的主觀驗收(代碼跑通了,但架構爛、不符合產品需求,照樣被打回重寫)。
這兩層驗證疊加起來,才是代碼類AI進步飛快的真正原因。
反觀生成一段影片、一個3D場景,現在業內怎麼評分?
CLIP相似度、FVD(Fréchet影片距離)、MLLM當裁判(讓另一個大模型去評判生成質量好不好),這些指標本質上都是"看著順眼就給高分"的模糊代理指標,論文裡管這類信號叫Fuzzy Proxy(模糊代理)。
問題是,這些分數經常和真實質量對不上。
一個影片物理規律亂七八糟,但只要色彩鮮艷、構圖討喜,CLIP照樣能打高分。這就是典型的"獎勵作弊"(reward hacking):AI學會了討好評分標準,而不是真正把事情做對。
論文裡給出了一個很直白的數學解釋:假設你手頭的獎勵信號Rf和真實質量Q*之間存在偏差,這個偏差可以拆成兩部分,一部分是隨機噪聲,另一部分是系統性偏見。
噪聲只是讓訓練效率打折扣,但偏見是致命的:如果這個偏見方向恰好是可以被"鑽空子"的,那模型會拼命朝著這個方向優化,分數越沖越高,但真實質量反而越來越差。
這就好比一個學生發現,老師改作文只看字數和好詞好句的密度,壓根不細看邏輯。
那這個學生會怎麼做?瘋狂堆砌華麗辭藻,寫一堆語法通順但內容空洞的廢話。作文分數蹭蹭往上漲,但寫作能力其實原地踏步,甚至倒退了。如果一直用這套評分標準訓練下去,你培養出來的不是好作家,是"作弊高手"。
這就是當下3D生成、影片生成、世界模型領域正在發生的事。
二、遊戲引擎:一個被忽略的"裁判員"
論文提出的核心洞察是,遊戲開發這件事裡,其實天然存在著一套雙重驗證系統,而這套系統被行業忽視了。
想想開發一個遊戲是怎麼運作的。
你在Unity(一個主流的遊戲開發引擎)里擺一個箱子,如果這個箱子和椅子的碰撞體積重疊了,引擎立刻會報錯,這是碰撞檢測。
你想讓NPC(遊戲裡的非玩家角色)從A點走到B點,引擎的Navmesh系統(導航網格,決定角色能不能尋路通過某片區域)會告訴你這條路能不能走通。
你寫了一段腳本,引擎運行時會告訴你有沒有崩潰、有沒有死循環。
這些都是廉價、客觀、自動化的檢查,和代碼編譯器的角色一模一樣。
但遊戲開發不止於此。就算所有的物理檢查、碰撞檢測都通過了,一個真正的遊戲開發者還是可能拒絕這個場景:氛圍不對、和設計意圖不符、玩起來彆扭。
這一步是人類主觀的驗收,和代碼審查里"通過了測試但架構爛"被打回是同一個邏輯。
論文把這套組合拳命名為RLHEV(人類工程師聯合驗證的強化學習):一種把遊戲引擎的自動檢查和人類開發者的最終驗收結合起來的訓練方法,用公式表達就是在滿足引擎硬性門檻(比如碰撞不能穿模)的前提下,最大化"人類驗收得分減去各種物理違規的懲罰項"。
這個設計的巧妙之處在於分工:引擎負責密集、便宜、可重複的結構性檢查,人類只需要在這些檢查都通過之後,把關最後一道"這東西真的對嗎"的問題。
打個比方,這就像餐廳後廚的雙重把關:廚房質檢員會檢查每道菜有沒有超過保質期的食材、溫度夠不夠、分量對不對,這一層可以自動化、可以每分鐘檢查一次。
但最後端到客人面前的那道"這道菜好不好吃、符不符合這家餐廳的調性",還得靠主廚親自嘗一口。
如果沒有質檢員這一層,主廚每道菜都要從頭到尾盯著,根本忙不過來。如果沒有主廚最後把關,質檢合格的菜也可能難吃得要命。兩層缺一不可,這就是RLHEV想複製的結構。
三、把這套流程存下來:UWDP協議
光有驗證機制還不夠,論文還提出了一件更細緻的事:把整個開發過程完整記錄下來。
這裡有個很扎心的洞察:一個做完的遊戲場景,只能告訴你"結果是什麼",完全不能告訴你"為什麼這樣做是對的"。
一份最終交付的3D場景,你看不到設計師最初的意圖是什麼,看不到中間試了多少次失敗的方案,看不到引擎報了什麼錯、又是怎麼修復的,更看不到人類審核員當時提出了什麼批評意見。
這就好比只保留一份考卷的最終答案,而把演算過程全部撕掉。老師批改的時候,只能判斷這道題對不對,卻完全沒法知道學生是蒙對的,還是真的理解了解題步驟,更沒法知道這個學生上一次做錯的題是怎麼改對的。如果不保留演算過程,你就永遠沒法用這些數據去訓練下一個"更會做題"的模型,你能訓練的只是"更會蒙對答案"的模型。
論文提出了UWDP(統一世界開發協議):一套把遊戲開發全過程,包括設計意圖、場景狀態、編輯動作、引擎檢查結果、渲染證據、人類審核意見,全部結構化記錄下來的數據格式。
一條完整的UWDP記錄長這樣:設計簡報是什麼、涉及哪個物體、場景當前狀態如何、執行了什麼編輯動作、引擎返回了什麼檢查結果、渲染出來的畫面證據、人類審核員的決定,還有修復動作之間的關聯和風險備註。
整個採集流程也很樸素:解析設計簡報,生成候選編輯,記錄引擎快照和檢查結果,把失敗轉成具體的修復動作,不斷循環直到引擎測試通過並且人類審核通過,最後把整條軌跡連同監督信號一起存下來。
這條完整的軌跡數據,才是這篇論文認為真正值錢的東西,比最終那個"做好的場景"值錢得多。它記錄的是"怎麼把一件事做對"的完整過程,而不只是"做對了"這個結果。
四、AWoMo:讓世界模型在開發流程裡邊干邊學
有了RLHEV這套驗證邏輯和UWDP這套數據記錄格式,論文提出了具體的落地系統:AWoMo(智能體世界模型)。
AWoMo不是一個孤立的生成模型,而是嵌在一整套開發工作流里的角色組合:一個提議編輯的模型、一個執行動作的智能體控制器、一個負責檢查的遊戲引擎、一個負責驗收的審核者,再加上一個儲存軌跡的資料庫。
它的運行邏輯是一個五步循環:提議、渲染、驗證、修復、審核。
模型先提出一個編輯方案,引擎執行並渲染出結果,同時定位出哪裡出了問題;智能體根據引擎反饋的問題給出修復動作;這個循環持續進行,直到審核者最終點頭接受或者拒絕。
這個模型的底層核心是UnifiedGameAssetModel,一個基於Cosmos 3(一個面向物理世界的全模態基礎模型)持續預訓練出來的模型,擁有約28.9億參數,支持文本、圖像、3D高斯資產、網格、以及Unity、Unreal、Godot、MuJoCo這幾種遊戲引擎和物理仿真表示之間的轉換。
它的預訓練數據里包含87745條被接受的樣本和504條被拒絕的樣本,值得注意的是,被拒絕的樣本也被保留下來,因為它們提供了"驗收信號"里那一半負面案例,而這一半案例在傳統的最終成品數據集裡基本是缺失的。
論文裡有一個特別值得琢磨的細節:這套系統同時打通了"理解"和"生成"兩個方向。
生成是從設計意圖出發,正向映射到一個可執行的場景程序;理解則是反過來,從觀察到的圖像、影片或場景,反推出這個場景背後的結構和意圖。
論文的觀點是,這兩個方向本質上共享同一套監督信號:創造一個生成目標的那次編輯動作,同時也創造了理解這個目標所需要的大部分標註數據。這就好比學做菜和學品菜其實是同一套知識體系的正反兩面,一個廚師如果既會做菜又會精準地嘗出別人菜里少放了什麼調料,這兩種能力大概率是互相成就的。
五、實驗結果:全套驗證信號確實管用
理論講完了,接下來看數據。
論文首先在自建的UnitySceneBench(一個包含200個Unity資產編輯樣本的評測基準)上做了對比實驗,測試模型判斷一個資產編輯是該接受還是該拒絕的能力。
| 方法 | 主分數 | 準確率 |
|---|---|---|
| 零樣本CLIP | 約0.55 | - |
| 模糊代理基線 | 約0.53 | - |
| 監督微調基線 | 約0.53 | - |
| 離線RLHF(僅人類反饋) | 約0.51 | - |
| 僅引擎驗證的RLVR | 約0.58 | - |
| **完整RLHEV** | **0.681** | **0.665** |
完整RLHEV拿到了最高分,比第二名高出接近0.1個百分點,而且這不是運氣,論文還專門在不同訓練樣本規模下(從40條到720條)做了8個隨機種子的重複實驗,曲線顯示這個優勢是穩定的,不是某一次運氣好。
有意思的是,只用人類反饋的Offline RLHF,和只用引擎反饋的Engine-based RLVR,單獨拿出來都打不過全套組合,這恰好印證了論文最核心的假設:兩種信號必須疊加,少一種都不夠。
接下來是泛化能力測試,這才是真正考驗這套方法有沒有"真本事"的地方。
論文設計了兩種遷移場景,一種是同引擎內的分布偏移(比如Unity內部換一批風格差異較大的場景),另一種是跨引擎遷移(從Unity遷移到Unreal或者Godot)。
| 遷移場景 | 從零訓練 | 先在源域預訓練再遷移 |
|---|---|---|
| Unity內分布偏移 | 0.25 | **0.75** |
| Unity遷移到Unreal | 0.25 | **0.35** |
| Unity遷移到Godot | 0.15 | **0.35** |
同引擎內的遷移效果非常顯著,從0.25直接跳到0.75。跨引擎遷移的提升幅度小一些,但方向依然是正的,而且損失值和代理分數也同步在變好。
論文對這個現象給出的解釋是,不同引擎的碰撞語義、導入格式、導航系統天差地別,所以源域的經驗沒法完全平移過去,但至少提供了一個不錯的起點,再加上目標域的少量微調,就能把這個起點校準過來。
最後一組實驗測試的是這套體系生成的數據,能不能幫助其他任務的智能體表現得更好。
| 基準測試 | 原始基線 | 簡單數據增強 | AWoMo增強 |
|---|---|---|---|
| R2R(視覺語言導航) | 76.01% | 76.18% | **76.61%(+0.79%)** |
| Gymnasium MuJoCo(機器人控制) | 1568.44 | 1648.03 | **1724.73(+9.96%)** |
| D4RL Gym-MuJoCo(離線強化學習) | 18.30 | 25.56 | **27.16(+48.43%)** |
D4RL這個基準上的提升幅度最誇張,接近50%。這說明用AWoMo這套流程生成的輔助訓練數據,確實能讓下游的具身智能體(能感知環境並做出動作的AI系統)表現得更好,而不只是在遊戲資產分類這一個孤立任務上有效。
六、這套方法也有它的軟肋
論文自己也很坦誠地列了幾條最尖銳的質疑,值得拿出來說說。
第一條是最直接的:遊戲畢竟不是現實世界。
在遊戲引擎里訓練出來的經驗,能不能真的用到現實機器人身上?論文承認目前的實驗裡完全沒有真實掃描數據、沒有真實機器人,這個"從模擬到現實"的橋樑還沒搭起來,只是提出了遊戲引擎是一個"驗證信號豐富的訓練場",但離真正解決現實遷移問題還很遠。
第二條是引擎獎勵也能被鑽空子。一個設計粗糙的碰撞檢測閾值,同樣可以被AI找到漏洞、專門去討好這個閾值而不是真正把物理關係擺對。論文的應對策略是用多重驗證器、隨機化探針、加上人工審核兜底,而不是指望單一的引擎信號就能萬無一失。
第三條更微妙:不同遊戲引擎之間的經驗能不能互通?實驗數據顯示能,但幅度有限。這提醒我們,這套體系目前更像是一個"在同一套規則體系里進步很快"的機制,跨體系遷移仍然需要額外的校準成本。
寫在後面
讀完這篇論文,最讓我想不通又想通了的一點是:我們一直在討論怎麼讓AI"更聰明",但很少去討論"誰來告訴AI它做得對不對"這件事本身有多難。
代碼有編譯器,圍棋有輸贏,數學有對錯,這些領域進步飛快,不是因為AI在這些領域特別擅長,而是因為這些領域天生自帶裁判。而影片、3D、世界模型這些領域,長期以來都在用"看著順眼"當裁判,這本身就是一種偷懶,也難怪進步會卡殼。
遊戲引擎這個選擇挺妙的,它不是憑空造了一個新裁判,而是發現了一個早就存在、每天都在被無數遊戲開發者使用、卻從來沒被當成"AI訓練基礎設施"的現成系統。這種"重新發現已有資源的價值"的思路,比造一個全新工具更讓人覺得聰明。
另外一個讓我意外的細節是,論文特意強調了"被拒絕的樣本也要保留"。這其實是個反直覺的操作,大部分數據集的直覺是只留好的、扔掉差的,但這篇論文認為差的樣本恰恰是訓練"審美判斷力"最重要的負樣本。這讓我想起,教一個人分辨假幣,光看真幣是學不會的,必須見過大量假幣才行。
這套體系最終能不能真的接上現實世界,論文自己也沒給出答案,只是留了個開放性的問題:當AI開始大規模參與到人類的創造性勞動過程中,並且從這個過程本身學習,這會不會是比"AI訓練AI"更可靠的一條自我進化路徑?
Q&A
Q1：AWoMo是什麼?
A：AWoMo是論文提出的智能體世界模型,它嵌在遊戲開發工作流里,負責提議場景編輯、觀察引擎和人類的驗證反饋,並把這些開發軌跡轉化為訓練數據,持續自我提升。
Q2：RLHEV和普通的強化學習訓練有什麼不同?
A：RLHEV把遊戲引擎的自動化檢查(比如碰撞檢測、物理穩定性)和人類開發者的最終驗收結合起來,前者提供密集廉價的結構性獎勵,後者提供稀疏但更貼近真實需求的驗收信號,兩者缺一不可。
Q3：這套方法在跨遊戲引擎場景下效果怎麼樣?
A：論文測試了從Unity遷移到Unreal和Godot的效果,發現先在Unity上預訓練再做目標域適配,比從零訓練效果更好,分數從0.25/0.15提升到0.35,雖然提升幅度小於同引擎內遷移,但方向是正的。
