开源开发者 Simon Willison 在 2026 年 10 月 24 日发布了网页即时战略游戏 Battledrones v14 版本。表面上看，这是一场标准的氛围感编程（Vibe Coding）奇迹：Willison 只向 Claude Opus 4.5 输入了一句简短提示词，模型就交出了一张支持四人混战的全新冰原地图，并同步修改了底层网络通信逻辑。
但如果剥开社交媒体上常见的神话滤镜，就会发现这场看似轻盈的自动化跃迁，本质上是一个极其精细的工程妥协样本。从双人对抗演化到四人联机，大模型没有凭空解决分布式状态同步的底层顽疾，而是用一系列巧妙的架构降级与补丁，换取了网页端即时战略体验的可行性。
一条提示词与一张72×72的冰原地图
在最新发布的 v14 版本中，最直观的变动是名为 Compass Rose 的全新战场。这是一张 72×72 规格 的北极冰原主题地图，模型严格执行了四方旋转对称的出生点布局。为了容纳四位玩家同场竞技，系统在原有的红、蓝两军之外，新增了紫色与绿色的战斗机器人外观。胜负判定规则非常纯粹，四人各自为战，最后存活的一方摘得胜利。
在图形和玩法扩展的同时，v14 版本还顺带清理了此前的历史技术债。该版本修复了回放（Replay）工具此前无法正确恢复 Uplinks、补给箱以及 HUD 指示器的缺陷，纠正了赛后战报重复统计回放事件的错误，并将整套视角回放系统同步升级至四方观测视角。
这看起来确实像一次完美的模型能力展示。然而，高级编码智能体在面对网状系统时，并不是从真空中提炼出这些逻辑的。在此之前，整个项目已经在代码仓库中经历了密集的自我否定与推倒重来。
从刺耳超声波到无状态中继的折中之路
网页端即时战略游戏最棘手的关卡始终是多端同步。在 Battledrones 的早期探索中，联机方案一度走向过极其离奇的路径：尝试使用超声波或音频调制解调技术在设备间传递数据。这一极客尝试很快撞上了人体生理极限，高频尖锐的音频让联机测试人员头痛不已，开发者不得不挂出健康警告并放弃该方案。
随后团队尝试引入点对点的 WebRTC 通信，但多端穿透与连通率的复杂度再次击穿了原型开发的容忍度。最终，系统倒向了无状态 WebSocket 中继。在当前的四人联机架构中，房主（Host）与每一位加入战局的访客建立独立的双 Socket 房间，由房主向全员广播有序的回合日志。
这种简化设计的代价，是产生了一系列不可忽视的运行约束：
- 房主设备必须全程保持页面处于前台，一旦浏览器切入后台节流，整个联机时钟就会停滞；
- 联机状态下打开暂停菜单并不会真正暂停战局，仿真世界依然在向前滚动；
- 架构放弃了耗费算力的大规模全局状态归档，若有人掉线，系统会直接分配一个基础 AI 顶替操作，直到该玩家重新载入页面接管控制权。
单条提示词解决的只是调用封装，真正的架构弹性全是靠工程妥协买来的。
- 提醒.无状态 WebSocket 中继极大降低了部署门槛，但它将核心可靠性完全押注在房主设备上，只适合轻量对局，无法直接承载强竞技性的商业对战。
浮点数精度与321次提交背后的暗礁
在网页环境构建即时战略游戏，AI 遇到的最阴险对手并不是地图对称算法，而是各个浏览器底层的数学引擎。经典的锁步同步（Deterministic Lockstep）要求所有客户端在同一时刻执行完全相同的运算，但不同浏览器对原生三角函数（如 Math.sin 与 Math.cos）的微小浮点实现差异，会随着对局推移迅速放大，最终导致不同玩家屏幕上的战场走向脱节崩溃。
为了弥合这一鸿沟，项目此前不得不专门重写了跨端一致的自定义确定性数学函数库。大模型编写业务逻辑的速度极快，但这类横亘在浏览器标准缝隙中的暗礁，每一处都需要极高密度的试错。
从 10 月 20 日最初版本发布到 10 月 24 日 v14 面世，短短四天时间里，项目历经了 12 次重大版本迭代。Claude Code 等编码智能体在代码仓库中密集提交了 321 次 commit，并通过自动化脚本模拟了 超过 1000 场完整对局 来调校数值与状态一致性。
这种高密度的计算反哺，揭示了当前辅助编程工具的真实能力边界。Claude Opus 4.5 展现出的强大之处，不是免除了软件工程的复杂性，而是把原本需要数周的手工打磨过程，压缩进了一套高度自动化的生成与压测流水线。对于独立游戏制作者和开发者而言，这种模式大幅降低了制作多端联机原型的门槛；但在涉及跨端底层一致性、长连接保活和异常恢复等硬核场景时，开发者依然需要清楚地知道模型在哪里做了妥协，否则这些掩盖在简洁代码下的折中设计，迟早会在高并发或恶劣网络环境下集中反噬。