這篇文章要分享的是一個關於 AI 嘗試自動生成遊戲的開發紀錄。原作者受到動畫《數位馬戲團》的啟發，想要打造一個數位寵物，這個寵物能像是一個高度工程化的待辦清單，能將日常任務包裝成遊戲般的冒險任務交給使用者。但在開發過程中，作者發現讓 AI 直接生成可運行的遊戲程式碼，遠比想像中困難。
開發的核心目標是利用 Nemotron 30b 模型，讓 AI 能夠直接輸出使用 Three.js 的完整遊戲程式碼。Three.js 是一個基於 JavaScript 的 3D 繪圖函式庫，讓開發者能在網頁瀏覽器中建立複雜的 3D 場景。對於 AI 來說，生成這種涉及座標計算、渲染循環以及物件互動的程式碼，對邏輯嚴密性的要求極高。
在嘗試過程中，作者採取了三種不同的技術路徑，但都遇到了瓶頸。
首先是嘗試長提示詞（Long Prompting）。作者提供詳細的說明書，告訴 AI 該如何撰寫程式碼以及運作邏輯。然而，這種方式最容易失敗，因為 LLM 在處理長指令時，容易忽略部分細節，導致生成的程式碼雖然看起來像樣，但執行時經常報錯或無法運行。
接著，作者嘗試引入技能卡（Skill Cards）。技能卡是一種將特定領域的專業知識或程式碼模式模組化，再餵給 AI 的方式，目的是讓 AI 學習特定的開發規範。但這導致了另一個問題：Token 消耗過快。由於為了節省運算成本而設定了較短的上下文視窗（Context Window，即模型一次能記憶的文字量），大量技能卡的加入直接撐破了視窗上限。即便後來調大視窗，生成的程式碼依然不穩定。
最後，作者嘗試使用 Codex 模型將技能卡進行蒸餾（Distillation），將精華濃縮成單一文字檔，並搭配 RAG（Retrieval-Augmented Generation，檢索增強生成）技術。RAG 的作用是在 AI 回答前，先從外部知識庫中檢索出最相關的片段提供給模型參考。雖然 RAG 改善了生成品質，但依然無法保證 100% 的正確率，許多生成的遊戲最終仍以空白螢幕收場。
這個案例給工程師的啟示是，目前 LLM 在處理單一、簡單的 HTML 元件（如時鐘、簡單的貪食蛇遊戲）時表現良好，能實現一次性生成（One-shot generation）。但一旦涉及複雜的邏輯結構，例如俄羅斯方塊（Tetris）或完整的 3D 遊戲，AI 就容易在細節處出錯，導致整個程式崩潰。
目前的結論是，完全依賴 AI 生成複雜可執行程式碼的路徑依然充滿挑戰。對於想要開發類似功能的工程師來說，將大目標拆解成微小的模組，或是建立更嚴格的自動化測試驗證機制，會比單純調整 Prompt 或增加 RAG 知識庫更有效。
來源：huggingface.co
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。