2026 年 10 月 15 日，开源开发者 Simon Willison 发布了一款名为 Chirp Pong 的实验性双人乒乓球游戏。这款完全运行在静态 HTML 中的小工具没有依赖任何后端服务器，也没有调用蓝牙、局域网或 WebRTC 信令，而是通过两部近距离摆放的手机，利用扬声器发出尖锐的音频噪声，再由麦克风解析还原出球体的运动状态。
代码由 Anthropic 旗下的 Claude Opus 5.5 Extra 在 Claude Code 编程环境中生成。Willison 给出的核心评语十分简练：“它确实能跑。”但这绝非只是一个怀旧的玩具演示。Chirp Pong 的真正价值，在于它以一种近乎极端的物理层通信方式，重新探讨了 Web 应用脱离云端基础设施的可能性，同时也把声音调制解调技术在现代移动设备上的物理瓶颈暴露无遗。
放弃网络协议：用扬声器重现 1980 年代调制解调器
在现代浏览器体系下，想要在两台移动设备之间实现近场对战，常规解法高度标准化：要么拉起 WebSocket 连接通过云端服务器中转，要么依靠 WebRTC 建立点对点直连。但无论哪一种，都需要外部网络介入，WebRTC 甚至需要独立的信令服务器来完成 NAT 穿透。
Chirp Pong 彻底跳过了这些软件层中介。它的通信链条直接扎根在底层声学硬件上：发送端将数据转化为 PCM 音频信号，驱动扬声器播放；接收端通过 Web 麦克风 API 捕获声音，再由软件解码器还原。这种机制在技术历史上并不新鲜，开源生态中早有类似 ggwave 或 Quiet.js 这样的纯声学通信库。但将其压缩进一个单一的静态 HTML 文件，并完全由大语言模型实现逻辑组装，依然提供了一个反常识的架构样本。
开源托管在 GitHub 上 tools 仓库中的 chirp-pong.html 文件，支持直接在线体验。为了方便调试，页面还内置了单独的扬声器与麦克风测试工具，以及一套离线的练习模式。但在看似轻巧的单文件背后，这种通信模式带来了极度严苛的工程折中。
离散事件障眼法与 16 字节的物理极限
让声波承载游戏对战，最大的鸿沟在于传输带宽。在参考 ggwave 等成熟开源库的测试指标时，浏览器可听声信道的有效吞吐量通常只有 8–16 bytes/s（即 64–128 bit/s）。
如果直接按照常规网络游戏的设计，每秒发送数十次球体坐标、球拍位置和碰撞状态，声学信道会瞬间瘫痪。即使仅仅传输 16 个字节的状态包，物理声波的编码与播放也需要消耗 1–2 秒延迟。
声波无法传输实时轨迹，它只能在临界点传递一次离散的击球快照。
Chirp Pong 解决这一问题的方式是精巧的玩法欺骗。两台手机并不共享同一个完整的球场视界，而是各自只渲染自己这一侧的半场。在本地半场内，所有的拖拽、切球、旋转、扣杀判定，以及道具宝石、眩晕炸弹和连击倍率计算，全部由本地 JavaScript 物理引擎独立完成。
只有当球体越过屏幕顶部边缘的那一瞬间，系统才会将球的角度、水平速度与旋转量打包成几个字节的声波脉冲发射出去。接收端设备在麦克风听到声音并解码完毕前，球体实际上已经进入了物理上的盲区。接收端一旦完成解调，立刻以接收到的参数生成新球并模拟飞行。用户在视觉上感知到的是球从一部手机飞进了另一部手机，但网络底层传递的仅仅是一次瞬时触发事件。
- 结论.在超窄带通信中，流畅度不来自网络吞吐，而来自本地预测与离散事件的割裂设计。
现代操作系统的降噪算法反噬
即便把数据量压缩到极限，Chirp Pong 在落地体验时依然面临严苛的物理限制。最直接的表现是物理摆放：为了确保麦克风能从信噪比极低的环境中抓出微弱的脉冲声，两台手机必须解除静音、音量调至最大，并且必须头对头相隔数厘米贴近放置。
这一限制的根本原因在于现代智能手机音频栈的演进方向。今天的手机操作系统和移动浏览器在调用 getUserMedia 获取音频流时，默认开启了大量针对人声通话优化的底层算法：回声消除（echoCancellation）、噪声抑制（noiseSuppression）以及自动增益控制（autoGainControl）。这些算法的唯一目的，就是滤除一切非人声的机器尖叫与规律脉冲。
对于声学调制应用而言，系统级降噪算法是致命的。Chirp Pong 必须在代码中显式关闭这些预处理特性，直接索取原始 PCM 流。与此同时，跨平台差异进一步放大了不确定性。iOS Safari 自 2017 年的 iOS 11 起才正式支持 getUserMedia，而不同厂商对扬声器高频响应的调校、麦克风拾音孔的物理位置以及硬件采样率的差异，极易导致跨设备联机时的高丢包率。哪怕是一次轻微的桌面摩擦声，都可能导致整包数据校验失败。
- 风险.手机越智能，针对声波通信的硬件滤网就越厚，通用纯 Web 调制难以形成跨机型稳定体验。
这也界定了声波通信的真正边界。Quiet.js 等先驱方案曾尝试使用 19 kHz 附近的近超声波频段来避开人耳干扰，但超声波对扬声器高频硬件的要求更为苛刻。Chirp Pong 证明了大模型已经能无缝调用这类冷门底层 API 并写出可运行的复杂调度逻辑，但它所逃避的云端网络成本，最终都原封不动地折算成了对物理环境和硬件摆放的严酷索求。