Claude Opus 5.5 打造出靠聲音遊玩的即時戰略遊戲：深入解析 Battle Drones 的音訊數據機

桌上的兩支手機，沒有 Wi-Fi、沒有藍牙，哪裡都沒有伺服器。一支主持一場即時戰略對戰，另一支加入，而兩者之間傳遞的唯一東西是雜訊——約 10 kHz 的載波往一個方向傳，17 kHz 的往另一個方向傳，以每秒約 1,880 位元的速度承載玩家指令。這就是最新功能，現身於Claude Opus 5.5迄今最雄心勃勃的公開產物：Battle Drones，這是一款《Command & Conquer》風格的瀏覽器 RTS，由 Simon Willison 於 2026 年 10 月 20 日發布，歷經十二次重大迭代與 321 次提交，多數由編碼代理完成。Anthropic 於 2026 年 9 月 22 日推出 Claude Opus 5.5，每百萬輸入 token 收費 4 美元、每百萬輸出 token 收費 20 美元，因此模型本身已滿一個月；本週的新消息是它被用來打造的成果，以及隨附的開放規格。 像這樣的公開產物往往會略去模型在底層如何失敗，而記錄在案的事件則收錄於 OrcaRouter AI Incident Archive，其中每一條記錄都附有自己的來源、嚴重程度、信心等級與爭議標記。

那個說法的兩部分都可查證。這款遊戲運行於 simonw.github.io/battledrones/，原始碼在 GitHub 上以 Apache-2.0 授權釋出，而聲學連結並非黑箱——該儲存庫收錄了 SOUND-DUEL.md，一份完整的數據機規格，包含頻帶規劃、編碼率、封包格式與實測訊噪比數值。以下說明該文件與該貼文實際說了什麼，並區隔出它們沒說的部分。

10月20日發布了什麼？

Battle Drones 不是一支展示用的 demo reel。如文章所述，它有九種建築、七種地面載具、六種空中載具與三種步兵類型，全部都是透過 TypeScript 生成、而非從素材包載入的 3D 模型。遊戲具備戰爭迷霧，且防空與對地武器各有不同需求。六張地圖橫跨五種生態域，另外還有一個帶種子的隨機地圖產生器，可產生 108×108 的點對稱戰場——根據貼文所述，這是在作者發現每週 Claude 額度只剩 25%、距離重置還有 45 分鐘後，以 45 分鐘衝刺打造而成。

模式包括遭遇戰、Last Stand 生存波次、AI 對 AI 觀戰、八個任務的戰役，以及某種真正不尋常的東西：代理對代理模式，讓兩個語言模型透過一個僅暴露戰爭迷霧中可見、非視覺化遊戲狀態的工具互相對戰。這些對戰的錄製回放隨儲存庫一併提供，並附有一個顯示底層模型回應的除錯檢視器。

儲存庫自己的 README 中的數量已與文章的功能清單略有出入——README 寫的是十六個單位和十棟建築，而文章列出地面、空中與步兵共九棟建築和十六個單位。十六相符；建築數量則不符。雖然只是小事，但這正是當代理撰寫 README、卻無人稽核時會出現的那種偏差，而且作者明白表示他「幾乎沒有審查過任何程式碼」。

聲音連結，用數字看

這正是值得為此翻閱規格書的部分，因為「透過音訊進行多人連線」聽起來像噱頭，直到你看到它必須符合的工程限制。兩台裝置共用同一個房間與同一條聲學通道，因此設計採用分頻雙工：兩支手機都持續傳輸，主機端使用 9.525–12.5 kHz，來賓端使用 15.975–18.95 kHz，並將頻帶安排成主機端的二次諧波從 19.05 kHz 以上開始，且各頻帶產生的三階互調都遠離另一頻帶。

• 調變 — OFDM，子載波間距 25 Hz，40 ms 有效符號加上 10 ms 循環前綴，因此每個符號 50 ms，每秒 20 個符號

• 酬載 — 高頻段方案下每個封包為 188 位元，低頻備援方案下為 186 位元，兩種模式完全相同，因此切換模式絕不會改變可容納的內容

• 輸送量 — 高速快速模式為 1,880 bit/s，高速穩健模式為 940 bit/s，低速率方案則為 930 與 465；封包分別耗時 100、200、200 與 400 ms

• 錯誤控制 — K=7、碼率 ½、多項式 133/171 的卷積碼，軟判決 Viterbi 解碼，跨符號與音調交錯，CRC-16（多項式 0x1021），以及若重新編碼後的位元不一致超過 10% 即強制拒絕

• 訊框結構 — 每個超訊框包含一個同步符號加上 40 個資料符號，共 41 個符號或 2.05 秒，依方案與模式承載 20、10、10 或 5 個封包

• 實測鏈路 — 在 10–30 公分處，1 至 21 kHz 的每個 1 kHz 頻帶中，功率訊噪比為 40–70 dB；在計入回聲後，10 公分處的有效值降至 17–31 dB，30 公分處降至 9–19 dB，且反射聲較直達路徑晚 8–15 毫秒抵達

規格誠實的部分，在於它拒絕承諾什麼。這裡沒有 ARQ：遺失的封包不會重傳，下一個封包只會重新描述每一個未確認的回合；若積壓量超過一個封包，就會拆分到最多四個輪替區段。因此，大量積壓會變成鎖步停滯，而不是損壞。每個回合透過高水位標記只接受一次，而遊戲封包則由以雙方配對 nonce 作為金鑰的 CRC 保護，所以不同對局的錄製會無法通過檢查。正如規格所言，干擾可以撐過去，但無法防止：你會停滯，但絕不會無聲地失去同步。

房間模型測試的送達數據顯示：在穩健模式下，20 公分處可達 99% 或更佳，40 公分處為 95%；在快速模式下，20 公分處為 98%。這些是規格書中報告的模擬結果，並非實地研究——而且原貼文本身也說，這項功能推出時還非常新：「我才剛把這個弄好，所以還沒什麼時間實際測試它。」

比數據機更重要的程式錯誤

在結語觀察中藏著一個細節，對任何用代理建構具狀態軟體的人來說最可能有用。由於重播與鎖步多人遊戲都要求模擬在每台裝置上達到位元完全一致，Claude 必須停止呼叫 Math.sin() 和 Math.cos()——Chrome 與 Safari 傳回的值有極細微差異——並改用自身的實作。兩個瀏覽器在一個超越函數的最後幾個位元上不一致，就足以讓一場對局在幾分鐘後失去同步。

那是真正的工程限制，由模型發現並由模型修正，而且可推廣到遠超出遊戲的範疇。任何由代理建構、具有確定性核心的系統——排程器、財務帳本重放、模擬測試框架、可重現的建置——都會遇到同一類問題，而且會悄無聲息地遇到。對讀者而言，教訓不是「Claude 很擅長遊戲」，而是確定性必須在提示詞中成為明確要求，因為預設實作中沒有任何東西能讓它成立。

Radio Probe，以及一個值得偷學的提示模式

在撰寫數據機之前，模型先建立了一個量測頁面。文章描述了一個「Radio Probe」工具，它仍留在儲存庫中，檔名為 radio-probe.html，其任務是回答一個問題：在這個房間、這個距離下，兩台裝置之間實際能取得多少頻寬？完整實作只有在探測工具回傳的數字好到足以證明值得繼續之後才推進。同一個檔案也記錄了探測工具 尚未量測的兩件事——一支 iPhone 開著自己的麥克風進行傳輸，以及一支手機聽見自己的傳輸——而這正是在現場會造成影響的故障模式。

先量測、再動手，正是避免一整週的工作建立在沒人驗證過的假設上的做法。無論你用哪種模型，這個模式都值得照搬：要求代理先打造量測工具，再開發功能。它也會產出數據，讓「音訊多人連線可正常運作」這類說法可以被驗證，而不只是聽起來動人。

這對 Claude Opus 5.5 說明了什麼，以及沒有說明什麼

貼文中最強的說法都很具體。Willison 寫道，Claude Opus 5.5「在運用 Three.js 進行 3D 建模方面表現極為出色」——遊戲中的每棟建築、每輛載具和每片地景都是在程式碼中程序化建構而成，而他認為 GPT-6 Astra 也屬於同一等級。他還指出，這個模型會作曲：專案中沒有任何音訊檔案，配樂是在程式碼中生成，會隨地圖不同而變化，並在戰鬥升溫時增強。

另有兩項進一步結果是作者自行回報，而非經獨立重現，讀者應以此方式理解。「趣味更新」是單一提示詞——「這款遊戲還不夠有趣。讓它有趣得多。」——在動態工作流程模式下執行，該模式會協調許多子代理運作數小時，期間模型跑了超過一千次模擬試玩工作階段。回報結果來自 1,200 場普通難度下的 AI 對 AI 對戰：25 分鐘後仍未分勝負的對局從 14% 降至 0.9%；曾落後 800 以上廢料的一方獲勝比例從 24% 升至 46%。這些是作者對自己遊戲的測量，並非該模型的基準測試。

這篇文章沒有展示的部分同樣重要。沒有第三方對 Claude Opus 5.5 在遊戲開發上的評估，沒有在同一任務上與另一個模型的正面對決，也沒有對這些執行過程進行 token 或美元成本核算。作者自己的說法是，他對「遊戲開發幾乎一無所知」，「幾乎沒有審查過任何程式碼」，也不認為這個成果是一個認真的獨立專案。這是一組異常坦率的但書，也限制了這個結果能被推廣的程度：這只是一名實務工作者、一個程式碼庫、一個月。

運作這樣一個專案要花多少成本

Anthropic 為 Claude Opus 5.5 公布的費率表是：每百萬輸入 token 4.00 美元、每百萬輸出 token 20.00 美元，快取讀取則每百萬 0.20 美元。這類專案幾乎完全以輸出為瓶頸——模型是在撰寫 TypeScript，而不是在讀取龐大的固定語料庫——所以真正決定帳單的是每百萬 20.00 美元的輸出項目，而以高並行度進行、長達數小時的徹夜執行，正是讓「每個 token 都很便宜」變成實際數字的關鍵。Battle Drones 沒有公布總額，所以誠實的說法是：上限取決於你願意買多少個代理小時，而不是文中任何一個數字。

這也是不該只因一件令人驚豔的成果，就把生產路徑押在單一模型上的理由。Claude Opus 5.5 在 OrcaRouter 上以 Anthropic 的定價提供，零加成，因此供應商一調價，我們這邊當天就會同步生效，而自動容錯移轉意味著長時間的代理執行不會因為某個上游端點當天狀況不佳而中斷。如果你想測試像這樣的整夜建置能否在另一個模型上重現，用一個 API 存取 200 多個模型是最便宜的驗證方式——同樣的請求格式，換個模型名稱，不必再簽第二份合約。

什麼尚未確立？

• 熱度——在 2026 年 10 月 21 日、文章發布後一天查看時，該儲存庫顯示 4 顆星和 0 個分支。這不是什麼現象；這只是一個人已發布的專案。

• 音訊連結的實地可靠性——規格中的送達百分比來自房間模型測試，而作者表示他沒什麼時間實際測試這項功能。別把 99% 解讀成對你家餐桌的承諾。

• 先前技術——該文章引用 Alon Horesh 的 Siner 與 Georgi Gerganov 的 ggwave，作為其所能找到的唯一可比作品，並稱靜態 HTML 遊戲的音訊多人連線「就我所知，對 RTS 而言是首例」。那是作者的搜尋，而非文獻回顧。

• 程式碼的歸屬——Claude Opus 5.5 主導了後期大部分的迭代，但最初版本早在七月便是以 Claude Fable 5 打造，而 README 本身也說文件其餘部分是由 Claude 撰寫。請把這個 repo 視為混合來源的產物。

• 基準測試結果——沒有這種東西。這裡沒有任何內容是在有評分的任務上，拿 Claude Opus 5.5 與其他模型做比較。

真正該帶走的重點，比「AI 做出一款遊戲」更狹窄，也更有用。一款沒有後端的瀏覽器 RTS、一套確定性模擬，以及一個可用的聲學數據機，展示出由 AI 代理打造的軟體，其難點已從生成程式碼轉移到把限制條件——確定性、量測、錯誤行為——精確指定到足以讓生成的程式碼可被檢查。SOUND-DUEL.md 這份文件就是證據：它之所以存在，是因為有人讓模型在推出前先寫下這條連線能做什麼、不能做什麼。如果你想看看這種紀律是否能轉移到你自己的工作負載上，就拿同樣的提示詞去跑第二個模型，並比較規格，而不是比較螢幕截圖。