如何為遊戲開發設計 AI 輔助框架

遊戲即框架：建構 AI 輔助開發的核心架構

2026 年 9 月 12 日，講者在卡爾加里舉辦的 Indie Rodeo 活動上發表演講「Your Game Is A Harness」，之後把內容整理成部落格文章。講者強調，他雖然常談人工智慧，但這篇文章完全由人類撰寫，只參考了演講簡報，並非 AI 生成。他的核心觀點是：要讓大型語言模型（LLM）有效參與遊戲開發，必須把遊戲本身變成 AI 讀得懂的「框架」（Harness），不能只靠現有的程式碼生成工具。

LLM 在遊戲開發中的局限性與誤區

講者回顧自己使用 LLM 的經驗。早期他建立 mood.site 網站時，發現 LLM 能協助完成約 20 小時的程式碼工作，大幅縮短開發時間。但把 LLM 用在傳統遊戲開發時，他卻碰了很大的釘子。講者指出，LLM 擅長處理網頁應用程式，是因為網路生態系有大量高品質的開源程式碼可供訓練。相較之下，遊戲領域的訓練資料較少，而且遊戲除了程式碼，還包含大量非程式碼的資產與系統。

許多開發者會用 Three.js 等技術，把資產簡化成幾何圖元，藉此避開複雜的資產處理。但這樣做往往讓作品缺乏獨特的創作風格，只呈現 LLM 訓練資料的統計平均值。根本問題在於，傳統遊戲架構對 LLM 來說是不透明的黑盒子。LLM 能看到的大多只是已寫成的程式碼，若遊戲依賴對這些不透明內容的操控，LLM 在處理時就容易出錯。因此關鍵不在 LLM 能力不足，而在於如何讓遊戲狀態對 AI「可讀取」。

上下文工程與確定性狀態

要解決這些問題，必須引入「上下文工程」（Context Engineering）的概念。LLM 的對話上下文會隨互動不斷累積，若夾雜太多無關資訊，就會造成上下文污染，影響 AI 的判斷。講者提出，遊戲開發應從一開始就建立「確定性狀態」（Deterministic State），也就是遊戲必須能精確重現特定狀態。例如透過單一來源的種子隨機數產生器，確保任何非確定性的呼叫都能重現。

此外，講者建議採用「截圖可比對」機制。多模態 LLM 雖然具備視覺能力，但直接比較前後截圖，會因背景雜訊而難以精確評估變更。講者推薦使用免費命令列工具 `odiff` 做影像差異比對，產生量化的相似度數值（如 85% 相似）。這能給 AI 一個穩定的評估基準，讓它精確判斷每次修改是否更接近目標，也減少上下文中的無效資訊。

單一物件類型與命令模式

為了讓 AI 更容易理解遊戲物件，講者主張採用「Thing-Driven Development」架構。傳統物件導向設計中，樹木、狗等物件各有複雜的繼承體系，增加 AI 推理的難度。講者建議把所有遊戲物件統一成單一結構（如 `Thing`），包含基本屬性與類型列舉。這種「胖結構」設計讓序列化與反序列化變簡單，避開多型反序列化的麻煩，也讓 AI 清楚知道要改哪個物件、改在哪裡，不會產生歧義。

搭配這個架構，應實施「命令模式」（Command Pattern）：把遊戲狀態的變更封裝成可序列化的命令物件，而不是直接呼叫函式。這些命令可以被記錄、回放，甚至由 AI 直接生成並執行。這種設計讓開發者不必重新編譯，只要播放命令序列就能測試狀態變更，大幅縮短 AI 的測試迴圈。講者以自己的專案 Cantata 為例，團隊用自訂工具 Depot 管理外部資料，非程式人員可以直接修改資料，並即時在遊戲建置版中生效，不用等編譯。

獨立模擬核心與效能分析

講者還建議把遊戲邏輯與引擎渲染分開，採用「黑盒子遊戲架構」（Blackbox Game Architecture）。做法是把遊戲模擬核心獨立成 DLL 或程式庫，引擎則把命令送給模擬核心，再根據收到的更新狀態採取行動。這種解耦設計不只簡化網路程式開發，也能在沒有引擎的環境下進行純邏輯測試，例如用標準 C# 工具做單元測試，提高測試效率。

效能評估方面，傳統 Profiler 工具的輸出對 AI 而言很難解析。講者推薦免費工具 `samply`，它能把效能分析資料以純文字格式輸出。AI 可以輕鬆讀取這些文字資料，自行分析效能瓶頸並調整程式碼，形成高效的自動化迭代迴圈。

結論：遊戲即框架

綜合上述技術，講者描繪出一套高效的 AI 輔助開發流程：從確定性輸入開始，透過單一物件類型與命令模式進行免編譯的狀態修改，再用影像差異比對與文字化的效能資料驗證。整個迭代迴圈可在數秒內完成，讓 AI 能持續理解遊戲結構並執行修改。講者最後指出，任何遊戲只要採用這套架構，都能成為自己的 AI 框架，實現高度自動化的開發輔助。他也補充，這套架構適用於大型專案，小型專案可能不需要這麼複雜的設定，但對追求效率的開發者來說，這提供了具體的技術參考路徑。