GAIR Paper 107｜高校聯合騰訊發佈 GameCraft-Bench：AI已能端到端開發遊戲，Claude Opus 四成達到可玩水平

Coding Agent 的下一站，是動態交互系統的構建。 作者丨GameCraft-Bench Team 過去一年，代碼智能體（Coding Agent）發展迅速。從編寫簡單的單一腳本、修復局部 BUG，到跨文件完成長序開發任務，模型能力正在不斷提升。以“一句話生成遊戲”為代表，AI 正在大幅降低遊戲構建門檻。過去需要開發者熟練掌握引擎架構、手寫邏輯代碼的開發工作，現在可以通過自然語言快速生成原型，甚至生成可運行的遊戲項目。這也讓規模化由 AI 創造交互式體驗變得前所未有地現實。但問題是：這些從零自動生成的遊戲，真的“能玩”嗎？如果生成的代碼只是“看起來邏輯合理”，但在真實的引擎環境中根本跑不起來，或者視覺表現與玩家交互一塌糊塗，那麼在這些只看靜態代碼的基準裡刷出高分的 Agent，就很難真正勝任現實中的遊戲開發場景。香港中文大學（深圳）、深圳河套學院等高校聯合騰訊的最新研究 GameCraft-Bench 正是要解決這個問題：如何構建一個基於真實遊戲引擎、產物完整可運行、且能通過真實玩家多模態交互來驗證的 AI 遊戲生成評測基準。論文鏈接：https://arxiv.org/abs/2606.17861項目主頁：https://tongxuluo.github.io/gamecraft-bench-website評估代碼：https://github.com/tongxuluo/gamecraft-bench01為什麼不直接用現有的評測基準？過去已經提出了一些與遊戲生成相關的評估基準，那我們為什麼還要重新確立一個新的評估基準 GameCraft-Bench 呢？核心原因是：現有的基準很難全面、真實地衡量端到端的可玩性。表. GameCraft-Bench與已有的遊戲生成評估基準的對比。1. 真實引擎的整合難度被低估。 像 OpenGame-Bench 主要針對 Web 網頁遊戲，缺乏對真實遊戲引擎（如 Unity、Godot）生態的考察；2. 缺乏端到端的產物完整性。 GameDevBench 確實引入了真實引擎（Godot），但它主要關注基於遊戲的局部代碼修改和確定性測試，而非要求大模型從零交付一個完整的交互式遊戲產物；3. 動態交互的結果很難自動驗證。 評估一個遊戲，不能只看代碼有沒有語法錯誤。攝像機偏移對不對？UI 有沒有重疊？按下跳躍鍵后角色是否真的起跳了？這些遊玩過程中的“行動-響應”循環，傳統的靜態代碼測試根本無法捕捉。所以，傳統的評測環境可能適合考察基礎編程能力，卻不適合考察複雜的交互式系統生成。GameCraft-Bench 要解決的，就是如何將遊戲生成的評測拉回到“引擎基礎”、“產物完整性”和“交互驗證”這三個遊戲開發最核心的維度上。02GameCraft-Bench 如何把代碼測試變成真實遊戲評測？GameCraft-Bench 的構建思路可以概括為一句話：先在真實引擎中約束開發規範，再把生成的項目轉化為可運行、可觀察、可驗證的交互環境。圖. GameCraft-Bench 完整的端到端的評估過程。具體來說，GameCraft-Bench 選用了輕量級、節點樹結構清晰、且支持原生 2D 和無頭（headless）模式執行的 Godot 4 引擎作為底層環境。系統會首先向代碼智能體提供一份自然語言遊戲設計文檔（Game Design Document, GDD）。這份文檔相當於遊戲開發的“施工圖”：它會描述核心機制、操控方式、勝利條件以及視覺表現要求。隨後，智能體不能只提交零散的代碼片段，它必須根據說明，自動編寫 GDScript 腳本、配置場景樹（Scene Tree）、掛載美術資產，並最終交付一個包含入口場景和輸入映射的、可直接啟動的完整遊戲項目。GameCraft-Bench 不再“考算法題”，而是在回答一個更重要的問題：AI 到底能不能像人類開發者一樣，駕馭真實的引擎工具？03有了產物還不夠，關鍵是過程能交互、結果能驗證構建出完整的引擎項目只是第一步。對遊戲來說，產物真正有價值，是因為它能承載玩家的操作、記錄系統狀態，並給出實時的視覺反饋。因此，每個由 AI 生成的 Godot 項目都會被自動編譯啟動。GameCraft-Bench 配備了一套基於演示回放（Replay）與多模態模型的自動評測流程：Agent 需要隨遊戲項目一起提交演示軌跡（Demo Trace），記錄一系列鍵盤與鼠標操作（例如：按下“向右”和“跳躍”），用於展示關鍵遊戲功能和場景。評測系統會在全新的遊戲實例中重放這些操作軌跡，自動錄製遊戲運行過程，並從錄製視頻中採樣關鍵畫面作為評測證據。多模態大模型（VLM）作為裁判，根據遊戲設計要求，對回放過程中呈現出的遊戲行為、視覺反饋與狀態變化進行評分，判斷任務是否真正完成。這種設計避免了讓評測器自行探索遊戲玩法，從而將評測重點放在“Agent 是否成功構建並展示了目標遊戲能力”上，而不是“評測器是否能夠發現這些能力”。對於機制驗證任務，系統會檢查角色是否能夠按要求移動、跳躍、攻擊或觸發指定機制；對於表現驗證任務，系統通過回放錄像中的可見證據，判斷血條變化、狀態切換、勝負界面等要求是否得到滿足。表. GameCraft-Bench包含的140個遊戲的家族分佈。基於這套機制，GameCraft-Bench 形成了一套極其硬核的基準：覆蓋 15 個主流遊戲家族（從平臺跳躍、塔防策略到模擬經營等），共計 140 個深度的開發任務。04評估的不僅是機制骨架，還有完整的產物表現很多自動生成的遊戲原型，看起來有代碼、有循環，但對玩家來說根本沒法玩。因為一個真實的遊戲往往不是“按鍵能動”就結束了，而是要提供完整的心流體驗：要有明確的關卡內容、要處理複雜的碰撞判定、要有計分板和 UI 界面，還要有勝利與失敗的狀態流轉。因此，GameCraft-Bench 在構建評測體系時，不會盲目只看核心邏輯，而是將評估維度精細化：核心機制（Core Mechanics）： 角色移動、物理碰撞、核心動作是否符合預期？內容深度（Content Depth）： 遊戲是否有足夠的關卡元素？敵人生成是否合理？難度曲線是否存在？反饋與可讀性（Functional Visuals）： 遊戲在遊玩過程中的可讀性與即時視覺反饋是否完備（如可讀的遊戲狀態、警告提示、任務目標以及在 1280×720 分辨率下的 UI 穩定性）？美術與呈現（Art and Presentation）： 動畫是否流暢播放？視覺特效（如受擊特效）是否完整？UI 畫面是否風格一致且美觀？這些維度並不是通用打分項，而是會結合具體遊戲任務映射到對應的由人類專家標註的細粒度 Rubric 上進行評估。評測關注的不是“某個遊戲像不像另一類遊戲”，而是“它是否實現了自己設計文檔中承諾的玩法與體驗”。為了進一步驗證這套自動評測體系本身的可靠性，在基準構建完成後，團隊又專門對 Judge 的穩定性與一致性進行了分析。在固定遊戲項目、軌跡、視頻與 Rubric 的條件下，多次評測結果波動極小；而在引入人工評測進行校準後，Judge 與人工評測對比整體一致，僅在內容豐富度與表現質量上略偏寬鬆。這說明該 Judge 並非隨機主觀判斷，而是能夠穩定反映遊戲實際完成度。05真實評測揭示的殘酷真相：前沿模型在遊戲生成上依舊薄弱把評測標準拉到如此真實的維度後，前沿模型的真實表現到底怎麼樣？測試結果揭開了冰冷的現實：端到端複雜交互系統的生成，遠未被解決。 即使是當前最頂尖的代碼智能體，在這個基準上的總分也往往難以突破及格線。總分普遍未達及格線，端到端交互生成遠未解決。數據清晰地表明，即使是當前處於第一梯隊的最頂尖智能體組合（Opus-4.7 high），其系統生成的綜合總分也僅為 41.46% ；緊隨其後的 GPT-5.5 high 評分為 39.49% 。絕大多數模型的總分均在 40% 以下。這直接用數據揭示了在面對複雜的端到端閉環系統構建時，現有前沿模型的技術瓶頸。核心機制與後續系統擴展表現出嚴重的“數據疲軟”。對比各項細分指標可以發現，模型在“核心機制（Mechanics）”上的得分率是全場最高的 ，例如 Opus-4.7 high 和 GPT-5.5 high 分別能夠達到 55.34% 和 54.36% 。然而，一旦涉及到系統的深度擴展與綜合表現，數據便出現明顯下跌 — 在“內容深度（Depth）”維度上，兩者的得分分別降至 39.48% 和 38.61% ；在“藝術表現（Art）”上，更是進一步走低至 36.86% 和 32.94% 。這意味著模型僅能勉強寫出基礎的代碼邏輯框架，卻極度缺乏將系統做深、做完整的交付能力 。06典型模型行為診斷：Kimi-K2.6 與 MiMo-V2.5-Pro對開發鏈路中工具調用序列的量化統計表明，代碼智能體的工具使用偏好直接決定了系統級任務的收斂效率 。Kimi-K2.6 的視覺反饋閉環與 MiMo-V2.5-Pro 的重度執行形成了鮮明對照 ：高效的視覺反饋閉環（Kimi-K2.6）圖. Kimi-K2.6 在 Strategy-Skirmish 上的視覺反饋過程。數據特徵：在 140 項任務中，Kimi-K2.6 表現出極強的動態視覺自檢傾向 ，平均每項任務調用“渲染屏幕檢查工具”（Rendered-screen inspections）達 21.41 次（中位數 19 次） ，僅有 4 項任務完全未調用該工具 。行為模式：在 Strategy-Skirmish 實驗中，它通過高頻的渲染畫面回讀，成功將畫面轉化為有效的調試信號 。這使其精準定位了代碼編譯正常但實際運行錯位的邏輯缺陷（如單位放置偏離、狀態指示丟失），並逆向校正了網格系統與回合指示器佈局 。這種模式實現了視覺感知引導的精準迭代，有效擺脫了一次性代碼合成的隨機性 。低效的終端調試泥潭（MiMo-V2.5-Pro）圖. MiMo-V2.5-Pro 在 140 個任務中的工具使用情況。左圖： 得分與工具調用總次數之間的關係。右圖： 工具調用類型的總體構成。數據特徵：MiMo-V2.5-Pro 表現為典型的“前置代碼堆砌、後置重度執行”模式 。在其全部工具調用中，Shell 命令行執行（Bash）佔比高達 56.3% ，而代碼閱讀與編輯（Read + Edit）僅佔 16.5% 。統計表明，其工具調用總量與最終交付得分幾近無關聯（相關係數 r = +0.016） 。行為模式：MiMo 傾向於在缺少運行驗證前快速生成全量文件 ，導致後續階段陷入冗長的命令行修補路徑中 。在 5 個零分任務中，MiMo 雖然順利通過了工程編譯（Valid Build） ，卻由於將海量算力耗費在局部的 Bash 調試中，最終漏掉了閉環評測所必需的交互軌跡文件（Demo Traces）交付 。這用失敗實驗證明了單純堆砌命令行執行量無法確保全局任務的有效收斂 。07寫在最後：Coding Agent 的下一站，是動態交互系統的構建作為通向完全自主 AI 遊戲生成的第一步，GameCraft-Bench 依然有它的邊界（例如目前聚焦 2D 引擎，且裁判機制尚未接入音頻多模態評估）。但它指明瞭一個不可逆轉的趨勢：Coding Agent 的競爭，正在從“模型能不能把代碼寫對”，走向“模型能不能交付一個真正可運行、可交互、體驗連貫的軟件系統”。傳統的代碼評測（如 LeetCode 題目補全）最容易規模化，但與真實軟件工程存在巨大鴻溝；而直接評測真實遊戲產物足夠硬核，卻需要極高的多模態驗證和引擎打通成本。GameCraft-Bench 試圖走在這條難而正確的路上：從自然語言的 GDD 出發，約束在真實的 Godot 引擎中開發，再把最終產物轉化為可運行、可輸入、可多模態驗證的動態環境。所以，GameCraft-Bench 真正回答的不是“哪個模型寫腳本更快”，而是：當大模型試圖接管複雜軟件開發的全流程時，我們如何系統性地檢驗它們是否真的理解了“人機交互”的本質？AI 編程時代，模型會越來越強。但能讓模型真正走向工業級落地、甚至有一天獨立創造出 3A 大作的，可能正是這些不再妥協於靜態代碼、敢於直面引擎真實運行和多模態交互的殘酷世界。上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼關注雷峰網學術專區。