先看证据
一款可玩的 RTS，先要回答“好玩”是什么
Simon Willison 发布了 Battle Drones，一款受《命令与征服》启发、可在手机和桌面浏览器运行的即时战略游戏。它试图解决两个相连的问题：代理编程能否把一个适合手机操作的 RTS 原型推进到可玩，以及两台相邻设备能否通过声音交换信息、同步游戏状态。项目历经 12 次主要迭代，编码代理累计提交 321 次代码改动，主要使用 Claude Code。
这组数字容易让人把故事读成“代理很快造出一款游戏”，但关键变化其实发生在可运行和可玩之间。早期版本已经能建造、选中并指挥单位，也有基础 AI 对手，作者仍认为它没什么乐趣。后来他直接要求 Claude 把游戏“变得有趣很多”，这不是一套可复现的游戏设计方法，却准确暴露了代理开发中的分工：模型能快速响应目标，人得先能辨认体验哪里不对。
Willison 把 Battle Drones 评价为自己此前实验中真正好玩的一个。这是作者经过试玩后的判断，不是独立玩家研究，也没有量化的留存或平衡数据。因此，这个案例更适合用来讨论如何把模糊的体验要求转成多轮工作，而不是拿来证明代理已经能独立设计出成功的游戏。对于技术负责人，差别在于评估对象：不是单次生成结果，而是人能否持续提供有用反馈、让系统朝目标修正。
迭代把功能清单变成体验约束
项目起点相当朴素。Willison 先让 Claude Code for Web 搭建一个移动友好的 RTS，并提供 OpenAI API 密钥，让它调用图像生成 API 制作基础素材。第一版有建筑机制、单位指挥和简单对手，接下来增加车辆精灵图与 AI 对 AI 模式，后者让作者可以观察对局，而不必每次都亲自操控。早期版本使用 Phaser 2D，作者直到几轮之后才发现这一实现细节，说明原型推进时，开发者未必掌握了每个技术选择。
到了 10 月，Willison 升级到 Claude Opus 5.5，并要求它大幅改善画面与玩法，同时保持移动端友好。之后项目不只增加内容，也逐渐形成体验上的约束：不同武器要能应对空中或地面目标，地图与生物群系要有变化，战斗强度要能反映在音乐中，控制方式仍要适合手机。模型生成素材、代码和变体的速度有价值，但哪些变化让游戏更易读、更有节奏，仍要靠试玩来判定。
最终版本的规模能说明代理参与的工作量，也能说明为什么人需要有结构地观察结果：游戏有 9 种建筑、7 种地面载具、6 种空中载具和 3 种步兵单位，包含 6 张地图、5 种生物群系、随机地图生成，以及 Skirmish 和 Last Stand 等模式。它还加入多种 AI 性格、区域效果武器、随战斗变化的音乐，以及可建立新基地的巨型机甲 Goliath。把这些看作一份功能清单会漏掉重点：迭代不是单纯不断加东西，而是把“更好玩”拆成可以观察的具体变化，再决定哪些变化值得保留。
试玩能看体验，不能替代工程验证
Willison 说自己几乎没有审查代码，而且 TypeScript 不是他熟悉的语言。他主要通过反复试玩判断项目是否向前走。这种做法把人的工作从逐行实现移向设定目标、观察行为和选择方向，确实能让个人实验更快展开；但它也把一部分代码理解和风险识别留在视野之外。玩起来顺手，不等于模块边界清楚，更不等于异常情况与回归问题已被覆盖。
这个区别对团队尤其重要。321 次代理提交和一长串单位、地图、模式，能够说明代理做了大量实现，不能说明代码经过了充分审查或测试。现有材料没有给出测试覆盖、缺陷数量、性能表现或长期稳定性数据，也没有说明多人同步在不同设备上的可靠程度。把“做出了一个可玩的作品”直接等同于“做出了可维护的系统”，会把体验验收和工程验收混成一个判断。
更稳妥的借鉴方式，是把反馈分成几种不同的问题。试玩用于判断操控、节奏和对局是否朝预期方向变化，自动测试用于发现已知行为是否被改坏，关键代码审查则用于理解状态管理、边界条件和后续维护成本。Battle Drones 的材料只充分呈现了前一类反馈和快速迭代的过程，没有证明后一类工作已经完成。技术负责人若借用这种工作流，应把代理的产出速度当作实验效率，而不是质量保证的替代品。
音频联机的价值在场景，不在替代网络
Battle Drones 的一个特别实验，是让两台处于麦克风范围内的设备通过音频消息同步游戏状态。它延续了 Willison 之前的 Chirp Pong 项目，把声音作为相邻设备间的数据通道，用在 RTS 对局中。这个做法的吸引力很具体：设备不必先通过常见的在线连接路径建立互动，也能尝试在近距离交换游戏信息。不过，材料没有说明音频消息如何编码、状态如何协调、延迟和丢失如何处理，不能据此推断它能承载什么规模或质量的对局。
作者后来又增加了在线多人模式，并指出音频多人游戏带来了头疼。这不是对音频方案的彻底否定，而是提醒工程团队区分“技术上可行”和“产品上合适”。如果目标场景就是两台附近设备的短时互动，音频可以作为有辨识度的实验；如果要求更广的距离、更稳定的同步或更可预测的体验，就需要先把这些要求写清楚，再比较音频与在线路径的复杂度和限制。现有证据不足以替这种比较给出普遍答案。
因此，Battle Drones 最可执行的判断不是照搬某种架构，而是把代理、试玩和系统验证分别放在它们擅长的位置。代理适合快速产生可试玩的实现，人类试玩者负责把模糊的体验问题转成反馈，测试与审查则要回答作品是否可靠、是否可维护。音频联机值得作为受场景约束的技术探索，而不是默认的网络替代品。对技术负责人来说，真正需要保留的不是“让模型多写代码”的口号，而是明确下一轮反馈由谁提供、要观察什么，以及哪些风险仍未验证。