用 AI IDE + 引擎 MCP 做自動化遊戲測試:推薦路徑
面向 Unity / Godot / Cocos 專案:用 Cursor 等 AI IDE 結合引擎 MCP,建立可重複的冒煙檢查、約定巡檢與測試腳手架。
- game testing
- MCP
- AI IDE
- automation
- QA
遊戲專案的自動化測試通常兩線並行:倉庫內的單元/編輯器模式斷言,以及需要引擎上下文的場景與預製體檢查。錄製腳本易因 UI 與層級變動失效。更穩的做法:在 Cursor、Claude Code 等 AI IDE 中,透過 引擎 MCP 讓模型直接讀寫場景樹、元件與腳本,把測試意圖變成可重複步驟。
適合自動化的範圍
- 結構冒煙——關鍵場景可載入;玩家/敵人預製體元件齊全;UI 根節點完整
- 約定巡檢——目錄與命名;禁止深層硬編碼路徑;對外介面與信號是否仍在
- 測試腳手架——Unity Test Framework、Godot 測試場景、Cocos 單元測試樣板
- 變更後復檢——玩法改完後對照同一清單復跑
真機矩陣、深度效能剖析、大規模探索式 QA 仍用專門工具與人工。MCP 路徑加速的是編輯器側可結構化檢查。
推薦路徑
1. 把測試意圖寫成清單
與模型共用,例如:主場景存在 Player 且移動已啟用;背包預設關閉;敵人含碰撞與生命並完成事件接線。建議落盤 TESTING.md。
2. 接通引擎 MCP
本機 localhost 連接。參考:Unity、Godot、Cocos 3.x/2.x。測試輔助與發行建置分離。
3. 用對話執行檢查與生成腳手架
打開主場景,列出 Hierarchy 根物件;確認
Player及必要元件。缺失則列缺口,不要靜默新建完整系統。
為背包開關生成 Test Runner 斷言草稿;失敗訊息需可讀。
審閱 diff、本地跑測後再合入。
4. 穩定後接入 CI
將已跑通的本地測試命令掛入 CI。MCP 用於開發機上編寫與維護;CI 執行倉庫內腳本。
工作節奏
意圖清單 → MCP 唯讀巡檢 → 生成/更新斷言 → 本地跑通 →(可選)CI
↑__________________________________|
玩法或場景變更後復跑
下一步
寫 5~10 條冒煙意圖 → 完成 MCP 連接並做一次唯讀巡檢 → 第一版斷言本地跑通後再接 CI。延伸:Godot MCP vs 手寫、Unity MCP + Cursor。
繼續閱讀
你可能還會喜歡這些文章
Godot MCP vs 手寫腳本:什麼時候該讓 AI 操控編輯器
對照 Godot 場景組織與信號規範,說明 VberAI Godot MCP 適合加速原型與樣板,以及何時應堅持手寫 GDScript。
- godot-mcp
- vberai
- comparison
- GDScript
Figma 到 Unity UI:用 VberAI AI Studio 從設計稿到預製體
將 Figma 設計導入 Unity UI 層級:在 VberAI AI Studio 中導入、以自然語言微調後導出預製體,並說明與 Figma MCP、Unity MCP 的分工。
- figma-to-unity
- figma-to-code
- figma-ai
- figma-design
2026 遊戲開發 AI 怎麼選:Google AI Studio 和 VberAI 有什麼區別
2026 年遊戲開發 AI 選型:對比 Google AI Studio 與 VberAI 的定位、架構、成本與適用階段,依專案階段與技術棧選擇。
- Google AI Studio
- VberAI
- comparison
- game development