就在 Claude Opus 5 推出兩天後，AI 投資者暨前 HyperWrite 執行長 Matt Shumer 發布了一段影片，展示了一個由該模型完全自主建構的、可完整遊玩的第一人稱射擊遊戲。

他寫道：「Claude Opus 5 一次就完成了這個遊戲。」並補充說，沒有任何外部資源被納入建構中。

現在，您可能會認為如此高品質的輸出，需要一個冗長、詳細且謹慎的提示來引導 AI 模型完成建構一款精良第一人稱射擊遊戲的複雜任務。

再想想看。

其背後的提示只有短短三段，並已完整發布在 GitHub 上。它告訴 Opus 5 製作一個達到最新《決勝時刻》（Call of Duty）遊戲水平的射擊遊戲，分派子代理（subagents）——每個子代理都有獨立記憶體和專門任務——來單獨處理各個部分，並不斷循環每個部分，由一位獨立且嚴苛的評論者進行評審，直到其在盲測對比真實《決勝時刻》遊戲畫面時能站穩腳跟。根據提示，最終結果應「全然完美」。

這與提示工程師過去教導人們的工作方式完全相反。在「vibe-coding」熱潮中，建議是指定標準而非形容詞：說明「好」的具體含義，而不是僅僅要求它，例如說明程式碼應該考量哪些點，而不是只說「AAA」。

Shumer 的版本則幾乎是反其道而行，要求其子代理「徹底驚嘆」，並將實際定義交給 Opus 5 為自己建構的評論者。

這幾乎就是整個簡報的內容。Shumer 後來寫道，他從未指定渲染器、列出遊戲系統，或定義「AAA 品質」需要包含什麼。他開始將這種方法稱為「試煉迴圈」（Gauntlet Loop）：給予一個代理一個真實、可檢視的標準，而非模糊的指令，讓它將任務分解為小部分，並將每個部分交給一個評論者進行評審，這個評論者永遠不會看到建造者對其選擇的理由。

Claude Code 的兩項功能實現了這個迴圈。子代理在獨立的上下文視窗中啟動，擁有自己的指令和工具存取權，因此評級武器模型的評論者不會繼承建造者解釋其外觀原因的藉口。Ultracode 則是 Claude Code 的一項設定，它能將模型推向其最高推理能力，並讓它編寫自己的編排計畫，將工作分散到多達 16 個代理中，每次運行最多可達 1,000 個。

Anthropic 內建的 /loop 技能，專為重複的修正-測試-調整循環而設計，正是它讓遊戲在看起來還不錯的時候沒有停止。Shumer 從未指定回合數。他讓評論者不斷指出新的不足之處，並讓建造者追逐這些不足之處長達數小時，直到他親自結束會話。

最終建構的遊戲運行在 Three.js 和純 WebGL2 上，大約有 55,000 行程式碼分佈在 11 個子系統中。所有紋理、網格、動畫和聲音都在載入時於瀏覽器內部生成，沒有下載任何模型、HDRIs、圖像檔案或音訊檔案。Shumer 公布的評論日誌顯示，分數從 10 分中的 3.59 分逐步攀升至略高於 5 分，但每一回合仍然落後於真實遊戲。

懷疑論者認為其中存在數小時的隱藏手動編碼，因此 Shumer 公布了完整的提示和程式碼庫。這時，模仿者便開始出現。

同樣的技巧，三種不同的建造者

前對沖基金經理兼播客 James Altucher，運行了相同的提示，並報告說在 Opus 5 上花費了「十個多小時」和約 130 萬個 token 來達到這個目標。他建構的遊戲《Operation Blackout》可以在瀏覽器中免費遊玩，看起來非常棒。

您可以在這裡玩這個遊戲。

Prompt Silo 的開發者則將相同的要求指向 OpenAI 的旗艦競爭模型，發布了「Sol 5.6 Ultra with same prompt」——Sol 是 OpenAI 在 7 月 9 日與較便宜的 Terra 和 Luna 版本一同普遍發布的三款 GPT-5.6 模型中的頂級款。

開發者 Leon Lin 則採取了相反的做法，採用了通常的詳細提示。他沒有複製 Shumer 的簡短版本，而是著手「逆向工程這個遊戲的提示」，製作了一份長達約 20 節的文件，詳述了從布娃娃物理（ragdoll physics）到級聯陰影貼圖（cascaded shadow maps）的一切。他將其輸入 Cursor，使用高效率的普通 Opus 5，沒有子代理也沒有 ultracode，結果是一款名為《Dust Corridor》的市場街射擊遊戲，它同樣可以在瀏覽器中遊玩，而且看起來也很棒。

這些後續建構的遊戲都沒有經歷 Shumer 對其專案進行的盲測。他的評論日誌仍然顯示，他記錄的每一回合中，真正的《決勝時刻》都勝出 — 這正是 Altucher 和 Atom Tan Studio 用他精確的三段提示所追求的目標，也是 Leon Lin 用他大約 20 節的提示所追求的目標。

其中有多少是真正全新的？

像 Claude Code 這樣的代理式編碼工具，其撰寫軟體的方式就像一個有主管監督的初級工程師：它們讀取檔案、運行程式碼、檢視生成的截圖，並將任務分配給子代理和評論者，這些代理和評論者會根據既定目標檢查結果。這個循環是真實存在的，而 Shumer 的「試煉迴圈」是一種有效的結構化方式。然而，僅憑這些並不能證明該模型是憑空想像設計遊戲，而非重新組合已吸收的程式碼模式。

Three.js 提供了自己的指標鎖定攝影機控制作為官方範例，而這種基本模式——滑鼠視角、WASD 移動、射線投射（raycasting）用於射擊——在 GitHub、Gists 和開發者論壇上已被分叉和教學超過十年。一個基於公共儲存庫訓練的編碼模型，在讀到 Shumer 的提示之前，幾乎肯定已經見過數百甚至數千個幾乎相同的射擊遊戲。

這並不表示《Claude of Duty》是假的，但這使得「從零開始打造」這個說法更難以完全採信，因此對這些結果抱持保留態度。

研究程式碼生成模型的研究人員對這個更廣泛的問題有一個術語：資料污染（data contamination），即當模型在某項任務上表現出色，主要是因為其訓練資料中已存在幾乎相同的範例，而不是因為它推理出新的東西。

已發布的第一人稱射擊遊戲建構中，沒有一個包含對這種污染的檢查。Shumer 自己的儲存庫確實包含 Claude 自身的創造力，如果這樣稱呼是公平的話。這就是為什麼將「一次成功地製作了 AAA 級遊戲」解讀為一個有能力的代理在程式設計中最常被記錄的類型之一中工作，而不是作為 AI 設計出一個沒有任何先例可依循的射擊遊戲的證明。