Chirp Pong：用声波做联网，两部手机不连网也能对战

当"联网"靠的是声波

Simon Willison 又做了一个小实验：Chirp Pong。它要验证的问题很具体——能不能用静态 HTML，在两部彼此靠近的手机上跑一场双人对战游戏，而网络传输完全不用 Wi-Fi、蓝牙或数据线，改用麦克风接收的声波（chirp）来传游戏状态。

结论是：能跑起来。

这个实验有意思的地方不在于"又做了个 Pong"，而在于它把被我们默认依赖的网络层整个拿掉，换成了一条物理信道——空气。

实现方式：麦克风当网卡

从技术路径看，Chirp Pong 的架构非常克制：

• 纯静态 HTML，没有后端、没有 WebSocket、没有 WebRTC
• 两部手机放在彼此附近
• 游戏状态编码为音频信号，通过扬声器播出
• 另一端用 Web Microphone API 捕获音频、解码还原状态

这等于用声波替代了网络协议栈。延迟、误码、遮挡都会成为现实问题，但原文的判断是"It seems to work"——在近距离场景下，这套方案是可用的。

你可能没注意到，这类"声波通信"并非新概念，但把它塞进一个纯前端、零依赖的双人对战游戏里，工程上的取舍就变得很直观：你放弃了可靠性和通用性，换来的是完全不需要配对、不需要权限弹窗之外的任何基础设施。

chirp（啁啾信号）与音频调制

所谓 chirp，是指频率随时间线性（或其他规律）变化的短促音频信号。这类信号频谱特征鲜明、自相关性极强，接收端通过匹配滤波就能在嘈杂环境中精准定位其到达时刻，因此在雷达、声呐和早期的声波数据传输方案中都有广泛应用。把游戏状态编码进 chirp，核心难点不在发声本身，而在接收端如何从麦克风采样中切分出有效信号、纠正频移、还原比特流。常见的做法是采用频移键控（FSK）或正交频分复用（OFDM）式的多子载波编码，以换取更高的数据密度与抗噪能力。不过这些方案都需要把声音压进人耳几乎察觉不到的高频段或极短脉冲里，否则持续的"嘟嘟"声会严重影响游戏体验。

Web Microphone API 与音频采样

文中提到的 Web Microphone API，实际对应浏览器里的 MediaDevices.getUserMedia 与 Web Audio API 组合。前者负责申请麦克风权限并拿到原始音频轨道，后者通过 AudioContext 把音频流转成可编程处理的 PCM 数据——比如用 ScriptProcessorNode 或 AudioWorkletNode 逐帧读取样本，再交给自研的解调逻辑。扬声器一侧则用 AudioContext 生成振荡器或缓冲区音源把状态"播"出去。整套链路完全跑在页面的 JavaScript 沙箱里，不碰服务器、不碰原生层，这也是 Chirp Pong 能做成纯静态 HTML 的前提。

不只是 Pong：玩法上的改造

原文直接给出了它给模型（Claude Opus 5.5 Extra，运行在 Claude Code 中）的提示词，其中明确要求打破 Pong 的单调：

做一个双人竞技的类 Pong 游戏，两名玩家把手机靠在一起，游戏状态通过音频噪声传输、由 Web 麦克风 API 解析——但要加入图形和玩法上的变化，让它比 Pong 更有趣、更交织。

也就是说，作者本人对"复刻 Pong"并不满足。目标是一个双人强交互的体验，而不是各自盯着一半屏幕。"intertwine"这个词很关键——两个玩家的操作需要真正咬合在一起，而不是镜像对称的独立对局。

AI 编程助手在原型开发中的角色

Claude Code 是 Anthropic 推出的命令行形态 AI 编程代理，可以直接在终端里读写文件、执行命令、迭代运行项目；"Opus 5.5 Extra"指的是该系列中面向复杂推理任务的顶配型号。这类工具与传统代码补全的关键区别在于，它能围绕一个多文件、多步骤的目标自行组织实现顺序、调试运行，而不仅仅是逐行给出建议。Chirp Pong 这类项目正好体现了它的适用边界：约束非常规（音频信道、双机实时同步）、总代码量中小、没有既存依赖可循——这正是靠搜索和拼接现成库很难解决的场景，反而适合让模型从零构建一个自洽的小系统。

这更像是一次能力边界的探测

把 Chirp Pong 放在 Simon Willison 一贯的实验脉络里看，它同时测了三件事：

1. 浏览器能力的边界——纯静态页面 + 麦克风，能撑起多复杂的状态同步
2. 近场通信的替代方案——当系统级配对太麻烦时，声波是不是一条被低估的捷径
3. AI 辅助开发的效率——一个带有非常规约束（音频信道、双机、实时）的完整小游戏，从想法到可运行的原型的距离被压得很短

第 3 点尤其值得关注。原文只留了一句话交代模型和入口，没有任何关于调试过程的描述。这种"轻描淡写"本身就说明了现在的工具链状态：对这类中等复杂度的实验性项目，AI 编程助手已经能承担主要实现工作。

可以预见的限制

原文没有展开讲失败情况，但从方案本身能推出几个明确的约束：

• 距离：声波通信对两机的间距敏感，必须"close to each other"
• 噪声环境：嘈杂场所的可靠性会显著下降
• 带宽：音频编码能承载的状态量有限，这决定了游戏复杂度上限
• 对称性：两端都要同时收和发，自听回声（自己的扬声器被自己的麦克风收到）需要处理

这些限制意味着 Chirp Pong 短期内不会替代任何正经的多人联机方案。它的价值在于作为原型验证：当你只想快速验证一个双人交互构想，不想碰服务器和配对流程时，声波是一条真的能走通的路。

动手成本几乎为零

工具本身就是个网页，地址公开，点开即用。不需要安装、不需要账号、不需要配置网络。对于想研究 Web Audio API、Web Microphone API，或者单纯想试试"不联网的双人游戏"长什么样的人来说，这是一个可以直接上手拆解的样本。

把网络层换成空气，把配对流程换成"把手机拿近点"——Chirp Pong 的启发不在于游戏本身，而在于它提醒了一件事：很多被当作"必须"的基础设施，其实有更笨但更直接替代方案。