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