Claude of Duty 在做什麼？把「單一 prompt 做出 FPS」變成一套可量測的 AI 遊戲開發實驗

Claude of Duty GitHub repo

Claude of Duty 的亮點，並非僅是「用 AI 寫出瀏覽器版 FPS」。

如果只看專案名稱或那句 A Call of Duty-quality FPS in Three.js, built from a single prompt，很容易讓人以為這又是一個技術 Demo：用大型語言模型拼湊出一個勉強能跑的第一人稱射擊遊戲樣板，再以吸睛的行銷詞彙博取眼球。

然而，這個專案真正值得深入探討之處在於，它將這套流程推向了更嚴謹的工程化階段。

它所要證明的不是「AI 能憑空創造出 3A 大作」，而是：

當你嘗試讓多個 Agent 協作開發一款具備一定質感的 Three.js FPS 時，單憑 Prompt 是遠遠不夠的；你必須建立一套清晰的架構契約、回歸測試、視覺基線與效能量測工具。

因此，Claude of Duty 更像是一個探討 Agent 協作遊戲開發 (agentic game-dev) 的工程實驗，而非單純的技術展示頁面。

先講定位：它不是成品遊戲，重點是 AI 代理怎麼被管起來

README 開宗明義就拉高了格局：

• 瀏覽器內運行的第一人稱射擊遊戲
• 基於 Three.js r180 與 WebGL2
• 程式碼約 5.5 萬行，劃分為 11 個子系統
• 由一組 AI Agent 協作撰寫
• 完全沒有外部美術資產
• 貼圖、模型、動畫與音效皆在載入時動態程式生成
• 執行期依賴僅有 three

在這些特色中，最關鍵的並非程式碼行數或「單一 Prompt 生成」，而是背後的兩個核心設計：

1. 將遊戲解構成定義清晰的子系統
2. 將 Agent 的協作關係寫進架構規範中

有了這兩點，這套專案才不至於淪為空洞的炫技 Demo。

它實際上做了什麼

從 README 與 ARCHITECTURE.md 來看，專案將架構切分為 11 個主要子系統：

• render
• materials
• sky
• world
• physics
• player
• weapons
• fx
• ai
• ui
• audio

這些劃分並非虛設，README 對每個子系統的職責都有具體描述：

• render：負責 HDR 渲染管線、GTAO、TAA、動態模糊、綻光、曝光控制、色彩查找表與 AgX 色彩對映。
• materials：負責程式生成表面與 PBR 材質。
• world：建構一個約 120×120m 的市集街景場景。
• physics：強調完全由核心程式碼實現，不引入外部物理引擎。
• weapons：涵蓋槍枝幾何、後座力、裝彈與彈道模擬。
• audio：直接透過 Web Audio API 進行聲音合成，不載入任何外部音效檔。

這代表開發者並非只想堆疊出一個勉強能動的半成品，而是認真將「第一人稱射擊遊戲」這項複雜任務，拆解為可獨立分工的工程模組。

真正有意思的地方：它先寫的是協作規則，不是先寫功能

整個專案最值得探討的檔案，不是 src/ 底下的任何程式碼，而是 ARCHITECTURE.md。

這份文件本質上就是所有 Agent 的「施工契約」。

規範中嚴格限制了幾項開發邊界：

1. 各個 Agent 僅擁有自身目錄的修改權限
2. 禁止直接載入其他子系統的模組
3. 禁止新增 npm 依賴套件
4. 禁止在遊戲邏輯或視覺表現中呼叫 Math.random()
5. 禁止在每影格更新路徑上隨意配置記憶體空間
6. 所有建立的幾何體、材質、貼圖及渲染目標都必須手動釋放
7. 必須確保建置通過，且截圖工具能正常運作

這些規則的出發點很明確：

這並非讓 Agent 自由發揮，而是將 Agent 視為容易在協作中相互干擾的工程成員，因此必須透過架構規範將影響範圍最小化。

甚至連跨子系統的溝通也被收斂至特定的事件詞彙：

• weapon:fire
• weapon:reload
• bullet:impact
• damage:dealt
• damage:taken
• actor:death
• player:footstep
• explosion
• resize

這樣的架構設計透露出一個核心思維：

與其期待 AI Agent 能夠完美無瑕，不如在它們出錯前，先把系統邊界築得足夠堅固。

這個 repo 在秀的，不只是遊戲，還有一整套驗證 harness

README 中的一句話點出了精髓：

The interesting part of this repo is arguably the harness, not the game.

這套測試框架並非裝飾，而是一條完整的驗證鏈：

• tools/capture.mjs：擷取單張畫面截圖
• tools/shotset.mjs：批次執行 11 組畫面擷取
• tools/baseline.mjs：在隔離的頁面環境中，固定每格時間預算，進行具重現性的畫面擷取
• tools/imagediff.mjs：進行逐像素比對，一旦畫面產生非預期變化便判定失敗
• tools/profile.mjs：量測遊戲運行的影格時間分佈與卡頓歸因
• tools/playtest.mjs：以指令碼驅動進行冒煙測試

這些工具的集結，背後指向了一個非常實際的工程痛點：

當 Agent 修改程式後，要如何驗證它是帶來了優化，還是不小心弄壞了畫面、效能或時序？

作者的解答並非仰賴人工驗證，而是將以下環節自動化：

• 定義視覺基準
• 像素級圖像比對
• 實際遊戲效能分析
• 固定影格下的重現截圖

這也正是 Claude of Duty 與市面上許多「跑起來就收工」的 AI 生成專案最大的不同。它更在乎可重現性、可量測性，以及是否能精確揪出拖慢影格時間的子系統。

它最誠實的地方：作者自己承認，結果還不到 Call of Duty

這項專案令人激賞的地方，在於它並未刻意吹噓「AI 已能做出 AAA 級 FPS」。README 中直接坦承：

The goal was to match a modern Call of Duty. It does not.

文中詳細列出了目前的限制：

• 手部建模仍顯粗糙
• 材質細節與紋理不夠豐富
• 敵人的外觀依然像假人
• 間接光照僅為粗略近似，而非全域光照
• 影格率仍有提升空間

專案甚至附帶了對抗性評審的評分紀錄，最終最高得分僅為 5.05 / 10，且評審在盲測中能輕易辨識出真實的 Call of Duty 畫面。

這份坦白讓整個專案更具實踐參考價值。它沒有停留在宣傳詞彙，而是把 AI 生成工作流面臨的技術瓶頸攤在陽光下：

• 程式生成貼圖的品質極限
• 角色模型為何依然擺脫不了假人感
• 光照設定的不一致如何破壞第一人稱視角模型的協調性
• 在提升畫面品質的同時，效能開銷可能隨之失控

它給的一個很強結論：平行 fan-out 不一定比單人順序修更有效

除了技術成果，專案也對 Agent 工作流提出了極具價值的實證觀察。README 指出：

• 進行三輪「由 6 個 Agent 平行各自負責單一目錄」的嘗試，僅讓評分提升了 +0.46，且遺留了更多破壞畫面的瑕疵。
• 隨後調整為「高度耦合的問題由單一 Owner 循序處理」，評分隨即上升了 +1.00。

這項經驗指出了目前許多 Agent 工作流的盲點：

能平行擴展，並不代表就應該平行擴展。

諸如色調對映、天空盒與間接光照等高度耦合的系統，若強行切分給不同的 Agent 獨立開發，極易導致各自局部合理、整體卻相互衝突的窘境。這正是該實驗的啟發之處——它不只展示了協作的可能性，更定義了「哪些任務不適合被強行平行化」。

我怎麼看這個 repo

如果僅將其視為「憑藉單一 Prompt 產出 FPS 遊戲」的實例，無疑低估了它的價值。這套專案真正的精髓在於 Prompt 後面構築的工程流水線：

• 架構合約
• 子系統權責劃分
• 共享事件語彙
• 具重現性的畫面擷取
• 圖像比對閘門
• 遊戲效能剖析器
• Agent 工作流的反思與檢討

因此，它本質上是將「AI 代理開發遊戲」從概念驗證推向正規工程化流程的嘗試。它所證明的並非「AI 已能穩定產出 3A 遊戲」，而是：

1. AI 確實有能力將複雜的網頁 FPS 專案推進到可運作、可量測且可優化的階段。
2. 開發的痛點不再是功能生成，而是如何確保多個 Agent 協作後的產出具備可控性、可驗證性與回歸防護。
3. 面對視覺、效能、物理、材質與光照等高度耦合的系統，嚴格的工程規範遠比 Prompt 技巧來得重要。

幾個邊界也要先講清楚

1. 效能數據源自專案報告，而非筆者實測

README 中提及的一系列優化數據，包括：

• p50 / p99 影格率
• 最差影格時間
• 著色器編譯次數
• 啟動時間

這些皆是作者使用其分析工具量測的結果。由於本篇評析基於靜態程式碼研究，並未實際運行該專案進行驗證。因此上述指標應視為作者宣稱的成果，而非筆者獨立實測所得。

2. 「單一 Prompt」雖有其檔，但實踐裝備絕非一步到位

專案中確實包含了一份 prompt.md，其核心指導方針大致為：

• 打造一款貼近現代 Call of Duty 的第一人稱射擊遊戲。
• 將子任務分配給多個子代理執行。
• 各子代理進行循環疊代。
• 引入嚴格的評審機制審查視覺呈現。
• 若未達 AAA 質感則持續修正。

然而縱觀整個專案，真正支撐起開發流程的，是其後配套的架構規範、測試工具鏈與審查機制。僅憑 prompt.md 便宣稱能「一鍵生成 3A 遊戲」顯然言過其實。

3. 授權宣告的不一致

根據 GitHub API 及根目錄下的 LICENSE 檔案，該專案採用的是 MIT 授權，然而在 package.json 的 license 欄位中卻標示為 ISC。雖然這並不影響核心技術的評估，但撰寫報告時仍需持保留態度。保守的描述方式為：專案根目錄附帶 MIT 授權條款，但其 package.json 宣告為 ISC，存在些微不一致。

總結

Claude of Duty 的核心價值並非「展示 Claude 如何幫你搓出射擊遊戲」。更精確地說，它驗證了一件事：

當面臨體量龐大、高度耦合，且極度要求視覺與效能品質的專案時，決定成敗的關鍵不在於 Prompt，而在於明確的規格、系統邊界、基準建立、效能度量與回歸驗證。

這份專案之所以值得關注，不僅是因為它在瀏覽器中實現了 FPS，更是將流於概念的 Agent 開發模式，朝向正規的軟體工程實戰推進了一步。

如果你正在思考：

• 如何避免協作的 Agent 彼此衝突？
• 如何針對視覺產出進行確定性審查？
• AI 生成的大型前端或遊戲專案該如何設計回歸測試？
• 邊界重疊的高耦合問題該如何循序解決？

那麼，Claude of Duty 最值得玩味的，或許不是它的遊戲畫面，而是它所建構的專案結構與驗證哲學。

參考資料

1. GitHub repo：<https://github.com/mshumer/Claude-of-Duty>
2. README：README.md
3. 架構契約：ARCHITECTURE.md
4. 原始 prompt：prompt.md
5. 入口與系統註冊：src/main.js
6. Engine：src/core/engine.js
7. baseline capture：tools/baseline.mjs
8. image diff gate：tools/imagediff.mjs
9. gameplay profiler：tools/profile.mjs
10. AI 子系統成本探針：src/ai/aicost.mjs