廣東
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-bench
01
為什么不直接用現有的評測基準？
過去已經提出了一些與游戲生成相關的評估基準，那我們為什么還要重新確立一個新的評估基準 GameCraft-Bench 呢？核心原因是：現有的基準很難全面、真實地衡量端到端的可玩性。
表. GameCraft-Bench與已有的游戲生成評估基準的對比。
1. 真實引擎的整合難度被低估。 像 OpenGame-Bench 主要針對 Web 網頁游戲，缺乏對真實游戲引擎（如 Unity、Godot）生態的考察；
2. 缺乏端到端的產物完整性。 GameDevBench 確實引入了真實引擎（Godot），但它主要關注基于游戲的局部代碼修改和確定性測試，而非要求大模型從零交付一個完整的交互式游戲產物；
3. 動態交互的結果很難自動驗證。 評估一個游戲，不能只看代碼有沒有語法錯誤。攝像機偏移對不對？UI 有沒有重疊？按下跳躍鍵后角色是否真的起跳了？這些游玩過程中的“行動-響應”循環，傳統的靜態代碼測試根本無法捕捉。
所以，傳統的評測環境可能適合考察基礎編程能力，卻不適合考察復雜的交互式系統生成。
GameCraft-Bench 要解決的，就是如何將游戲生成的評測拉回到“引擎基礎”、“產物完整性”和“交互驗證”這三個游戲開發最核心的維度上。
02
GameCraft-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
大會報告全文
熱門論文解讀
學術新星訪談
未經「AI科技評論」授權，嚴禁以任何方式在網頁、論壇、社區進行轉載！
公眾號轉載請先在「AI科技評論」后臺留言取得授權，轉載時需標注來源并插入本公眾號名片。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
