Claude Opus 5.5 打造了一款用声音玩的 RTS：探秘 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 次提交，其中大部分来自编码代理。A​nthropic 于 2026 年 9 月 22 日推出 Claude Opus 5.5，定价为每百万输入 token 4 美元、每百万输出 token 20 美元，因此模型本身已经发布一个月了；本周的新鲜之处在于它被用来构建的东西，以及随之提供的开放规范。像这样的公开产物往往会略去模型在底层是如何失败的，而记录在案的事件则编目在OrcaRouter AI 事件档案中，每条记录都带有自己的来源、严重程度、置信度等级和争议标记。

这个说法的两部分都是可核实的。游戏运行在 simonw.github.io/battledrones/，源代码在 GitHub 上以 Apache-2.0 许可发布，而且声学链路并非黑箱——仓库里带有 SOUND-DUEL.md，一份完整的调制解调器规范，包含频段规划、编码速率、数据包格式以及实测的信噪比数据。下文是该文档和那篇文章实际所说的内容，并与它们没有说的内容区分开来。

10月20日发布了什么

{{1}}Battle Drones{{/1}} 并不是演示片。正如{{2}}文章{{/2}}所述，它包含九座建筑、七种地面载具、六种空中载具和三种步兵类型，全部都是以 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 比特/秒，高速稳健模式为 940 比特/秒，低速率方案下分别为 930 和 465；数据包时延分别为 100、200、200 和 400 毫秒

• 错误控制——K=7、码率 ½、多项式 133/171 的卷积码，软判决 Viterbi 译码，跨符号和频点的交织，多项式为 0x1021 的 CRC-16，以及若超过 10% 的重编码比特不一致则硬拒绝

• 帧结构 — 每个超帧包含 1 个同步符号和 40 个数据符号，共 41 个符号或 2.05 秒，根据计划和模式承载 20、10、10 或 5 个数据包

• 实测链路——在 10–30 cm 距离下，1 至 21 kHz 范围内每个 1 kHz 频段的功率信噪比为 40–70 dB；在计入回声后，10 cm 处降至有效 17–31 dB，30 cm 处降至 9–19 dB，反射声比直达路径晚 8–15 ms 到达

规范中诚实的那部分，正是它拒绝承诺的内容。没有 ARQ：丢失的数据包不会重传，下一个包只会重新描述每一个未确认的回合；如果积压超出一个包，就会被拆分到最多四个轮转分段中。因此，大量积压会变成锁步停滞，而不是数据损坏。回合按高水位标记各只接受一次，游戏数据包由以双方配对 nonce 为密钥的 CRC 保护，所以对另一场比赛的录制无法通过其校验。正如规范所说，干扰可以被承受，但无法被阻止：你会停滞，但绝不会静默失步。

房间模型测试中的交付数据为：在稳健模式下，20 cm 处达到 99% 或更好，40 cm 处达到 95%；在快速模式下，20 cm 处达到 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 美元，缓存读取每百万 token 0.20 美元。这种形态的项目几乎完全受输出端驱动——模型是在写 TypeScript，而不是读取一个大型固定语料库——因此决定账单的是 20 美元的输出项，而在高并行度下持续多小时的夜间运行，正是把“每 token 便宜”变成真实数字的原因。Battle Drones 没有公布总额，所以诚实的说法是：上限取决于你愿意购买多少智能体小时，而不是文中任何数字。

这也是为什么不应仅凭一个令人印象深刻的成果，就把生产路径固定到单一模型上。Claude Opus 5.5 在 OrcaRouter 上按 Anthropic 的标价提供，零加价，因此供应商的价格变动当天就会在我们这边生效，并且 自动故障转移意味着长时间的智能体运行不会因为某个上游端点一时状态不佳而中断。如果你想测试像这样通宵完成的构建能否在不同模型上复现，一个 API 覆盖 200+ 个模型是找出答案的最便宜方式——相同的请求形态，不同的模型名称，无需第二份合同。

什么尚未确立？

• 热度——在 2026 年 10 月 21 日（帖子发布后的第二天）查看时，该仓库显示有 4 个 star 和 0 个 fork。这算不上什么现象；这只是一个被发布出来的个人项目而已。

音频链路的现场可靠性——规格中的送达百分比来自房间模型测试，而且作者表示他并没有太多时间主动测试该功能。不要把 99% 理解为对你家厨房餐桌的承诺。

• 现有技术——文章将 Alon Horesh 的 Siner 和 Georgi Gerganov 的 ggwave 列为它能找到的唯一可比工作，并将静态 HTML 游戏的音频多人称为“据我所知，这在 RTS 中尚属首次”。那是作者的检索，而非文献综述。

• 代码归属——Claude Opus 5.5 推动了后续大部分迭代，但第一个版本早在 7 月就是用 Claude Fable 5 构建的，而且 README 本身也说明文档的其余部分由 Claude 撰写。应将该仓库视为混合来源的产物。

• 基准测试结果——并没有。这里没有任何内容是在带评分的任务上将 Claude Opus 5.5 与另一个模型进行对比衡量。

真正值得带走的结论，比“一个 AI 做出了一个游戏”更具体也更实用。一个无后端的浏览器 RTS、一个确定性模拟，以及一个能工作的声学调制解调器，展示出：由智能体构建的软件，其难点已从生成代码转移到把约束——确定性、可测量性、错误行为——规定得足够精确，使生成的代码可以被检查。这份 SOUND-DUEL.md 文档就是证据：它之所以存在，是因为有人让模型在发布之前写清楚这条链路能做什么、不能做什么。如果你想看看这种纪律是否能迁移到你自己的工作负载上，就用同一个提示词去跑第二个模型，并比较规格说明，而不是比较截图。