核心概念

Amazing Digital Dentures 是一個在 Hugging Face Build-Small Hackathon 中誕生的失敗專案實錄，作者毫不掩飾地記錄了從雄心壯志到務實妥協的完整過程，值得所有嘗試用 AI 生成程式碼的開發者閱讀。

起點：過度設計的幻想

靈感來自動畫《The Amazing Digital Circus》中名為 Caine 的 AI 牙套角色——一個住在虛擬馬戲團裡的人工智能。原始概念是打造一個數位寵物：

  • 替使用者發送冒險任務
  • 將任務與現實世界的生產力目標掛鉤
  • 本質上是一個「偽裝成遊戲的過度設計待辦事項清單」

作者自嘲地承認，這個想法從一開始就過於宏大。

核心技術選擇：Nemotron 30b

選用 NVIDIA 的 Nemotron 30b 模型作為生成引擎，目標是讓模型直接輸出可運行的 Three.js 3D 遊戲程式碼。

三次方案迭代與失敗

第一次（長提示方法）：撰寫詳細指令，解釋如何用 Three.js 建構遊戲。結果模型頻繁生成語法正確但邏輯錯誤的程式碼，執行後只有空白畫面。Nemotron 30b 在理解複雜的 3D 幾何邏輯和遊戲狀態機時力不從心。

第二次（Skill Cards）：借鑒 GitHub Copilot 的 skill cards 框架，將遊戲製作知識拆分成結構化的技能卡片讓模型按步生成。問題是上下文窗口很快溢出，增大窗口也無法根本解決生成品質問題。

第三次（RAG + Codex）：引入 Retrieval-Augmented Generation，用 Codex 將技能蒸餾成單一文字檔，再用 RAG 系統動態檢索相關程式片段。有所改善，但仍然無法生成完全可運行的複雜遊戲。

最終降級成品

放棄了「生成完整 3D 遊戲」的目標，改做單次 HTML 玩具製造機：

  • ✅ 成功生成：時鐘、待辦事項列表、Snake 遊戲、Breakout 遊戲
  • ❌ 失敗生成：Tetris、任何涉及複雜 3D 幾何的 Three.js 遊戲

關鍵要點

  • 模型在複雜度邊界面前並不優雅：模型能生成簡單玩具，但一遇到 Three.js 的 3D 空間推理或 Tetris 的多狀態邏輯，輸出品質斷崖式下跌。這不是 prompt 寫法問題，而是模型能力上限。

  • 增加上下文窗口不等於提升品質：給模型更多資訊不代表它能更好地整合使用。資訊密度過高時，模型反而失去焦點，skill cards 方案就是這個教訓的具體案例。

  • RAG 是可行方向，但不是萬能藥：RAG 確實改善了生成品質，但程式碼生成的特殊性在於「片段正確」不等於「整體可運行」——各部分能跑但拼在一起就壞掉是常態。

  • 務實降級比執念更有價值：最終成品穩定可用，能生成時鐘、待辦清單、Snake、Breakout 就是真實可交付的成果。「失敗」的標籤來自和原始目標的對比，而非絕對評價。

  • 公開記錄失敗有社群價值：Hugging Face 的 Build-Small Hackathon 鼓勵誠實記錄失敗。這篇文章讓後來者少走彎路，本身就是對開源社群的貢獻。

實務應用

對「想用 LLM 生成程式碼」的開發者的直接教訓：

  1. 先測試目標複雜度：在正式開發前，用少量樣本測試模型能否生成你需要的程式碼複雜度。複雜遊戲邏輯（Tetris、3D 物理）通常超出大多數非頂級模型的能力範圍。

  2. RAG 適合查文檔，不適合建構邏輯：RAG 在「查詢 API 用法」上表現好，在「推理如何把多個函數組合成正確邏輯」上表現弱。

  3. 接受能力邊界，設計 MVP 範疇：如果一開始就把目標設在「簡單 HTML 玩具機」，這就是一個成功專案。失敗往往是因為目標設定問題，不是技術問題。

Nemotron-Labs Diffusion：擴散語言模型突破自迴歸推論瓶頸 Hugging Face 推論供應商生態系：DeepInfra 整合實錄

延伸觀點

學術研究與這篇 hackathon 實錄的核心教訓高度吻合，並提供量化佐證。

複雜度是 LLM 程式碼生成的決定性門檻

Arxiv 2024 年針對七個主流模型的大規模研究發現，模型生成程式碼的準確率隨問題複雜度顯著下跌——特別是涉及多個 API 調用和高行數的任務。功能性邏輯錯誤（而非語法錯誤）是最常見的失敗模式，佔比達 54%，且主要集中在邊界條件處理不足。這直接解釋了為何 Nemotron 30b 能生成語法正確但執行後只有空白畫面的程式碼。

靜態通過率不等於真實能力

ProxyWar 框架（Arxiv 2026）透過競爭性遊戲環境評估 LLM，發現傳統 pass@k 指標無法預測實際動態表現——pass@1 最高的模型（97.3%）在競賽中僅排名中等，而 pass@1 較低的模型反而贏得更多比賽。簡單遊戲中模型表現趨同，複雜遊戲（如黑白棋）才能分出真正差距。這說明複雜任務的評估需要動態場景，而非靜態測試。

迭代修正是可行的工程解法

「What's Wrong」研究提出讓模型讀取編譯器反饋並自我修正的迭代方法，可將成功率提升 29.2%。這暗示 Amazing Digital Dentures 的 RAG 方案方向正確，但缺少了執行後反饋迴圈——如果加入「執行 → 檢查錯誤 → 修正提示 → 重新生成」的循環，最終結果可能有所不同。

反向連結

以下頁面引用了本頁：