用Claude Code打造声源定位系统，找到神秘滴滴声

房间里有个设备一直在间歇性地滴滴响，但每次响的间隔太长，站在房间里根本判断不出声音从哪来。Simon Willison 遇到的正是这个场景——一个堆满搬家后还没拆封纸箱的储物间里，某样东西正在断断续续地叫。他不想把每个箱子都翻一遍，于是让 Claude Code 做了一个叫 Beep Locator 的系统：用多台设备当麦克风，通过三角定位找出声源位置。

最终系统把声音位置锁定在约 40 厘米范围内，他照着那个位置翻箱子，找到了一台急需换电池的老式一氧化碳探测器。

系统怎么工作

Beep Locator 的核心是一个 Python Web 应用服务器。用户在电脑上启动服务器，主界面会显示二维码和加入链接，其他设备扫码或打开链接后成为「监听器」。作者当时用了两台 iPad、一部手机、一台 MacBook Pro 和一台 Surface Ultra 共五台设备。

监听端的浏览器会申请麦克风权限，持续录制一段长约 60 秒的音频缓冲，同时在本地跑一个简单的蜂鸣检测算法（detector.js），用快速傅里叶变换加高通滤波识别疑似蜂鸣，再把事件上报给服务器。

这里的关键难点是时间同步。当某个监听器报告听到蜂鸣后，服务器会让往返延迟最低的那台设备播放一声短促的啁啾（chirp），然后要求所有监听器上传从蜂鸣前约 0.6 秒到啁啾后约 0.8 秒的音频片段。这段啁啾声让各设备的录音能够互相对齐——这是定位精度的基础。

Claude 在项目初期就检索到了 2007 年的论文 BeepBeep: A High-Accuracy Acoustic-Based System for Ranging and Localization Using COTS Devices。这套方案只用扬声器、麦克风和设备间通信这些最基础的商用硬件，通过双向感知、自录音和采样计数三种技术实现高精度测距，正好契合需求。

三角定位（Trilateration）：文中所谓的「三角定位」在声学领域通常指三边测量——利用声源到多个已知位置接收器的距离来确定声源坐标。声波在空气中的传播速度约 340 m/s，因此 1 毫秒的到达时间误差就对应约 34 厘米的距离误差，这正是文中反复强调时间同步的原因。实际系统中，每个监听器与声源的距离通过到达时间差（TDOA）间接求得，再在两个或三个维度上联立方程求交。设备数量越多、几何分布越分散（避免共线或共面），解算越稳健；这也是作者最后加入「建议位置」功能的理论依据。

啁啾声（chirp）与音频对齐：啁啾是一种频率随时间线性或指数变化的短促信号，其自相关函数非常尖锐，因而在互相关计算中能给出极高的时间分辨率。系统让各设备录下同一段啁啾，再通过互相关找出各自录音中啁啾的峰值位置，就能把不同设备的时间轴对齐到同一参考系。这比依赖设备系统时钟同步更可靠，因为浏览器环境的时钟精度和网络延迟都不可控。BeepBeep 论文采用的正是类似的「自录音」思路：设备录下自己发出的声音，用扬声器到麦克风的固有延迟做校准。

WebAudio 与 FFT 蜂鸣检测：浏览器端的 WebAudio API 提供 AnalyserNode，可对麦克风流做实时频谱分析，getByteFrequencyData 返回的即是经快速傅里叶变换后的频域能量分布。一氧化碳探测器常见的警报是 3–4 kHz 附近的高频脉冲音，因此检测器先做高通滤波去除人声和低频环境噪声，再在目标频段上寻找能量突增。仅靠频域阈值容易误报（例如键盘敲击声），所以系统最终以多设备同时上报作为交叉验证，并由服务端用对齐后的音频片段做二次确认。

从粗糙定位到可信结果

设备之间的互相发声测距效果并不理想，作者于是加了「Rough mode」：手动把设备图标拖到房间里的大致位置，系统再基于声音数据做修正。

他还加了拍手模式用于验证——在房间不同位置拍手，地图上会以菱形标记显示定位结果。这让他对系统定位声音的能力建立了信心。蜂鸣则显示为 X 标记，并写入「Sounds located」日志。

确认目标频率后，系统会专门监听这个频率，测量蜂鸣间隔，并利用已三角定位的位置收敛到地图上最可能的一个点。界面上还有一个「冷暖」面板展示各设备听到的响度——材料里给出的说法是，响度大约高 6 dB 意味着距离大致减半，这是判断声源远近的直观依据。

系统也保留了怀疑机制：当各设备的到达时间在物理上不可能成立时，会提示「可能是回声或另一个声音」。

开发过程：让 Claude 自己迭代

项目起始于 iPhone 上的 Claude Code Cloud，用的是 Opus 5.5 的 Extra thinking effort 模式，第一条提示词只是要求写一个 problem.md 描述问题。随后作者让 Claude 加入一个机制：能把新代码推送到监听端自动执行——这样他可以把设备摆好，然后放手让 Claude 持续改造，自己去做别的事。

这个热更新机制后来被证明是效率关键。部分设备在页面刷新时会重新请求麦克风权限，需要人工操作；而通过 WebSocket 推送新代码，就不必逐台设备手动交互。

之后项目切换到 Fable 5.2 继续推进。作者的参与方式变成了坐在电脑旁和模型讨论现状、偶尔提需求。他提出的功能包括：拖拽式粗糙定位、拍手测试与不同符号区分、地图符号带时间戳、带播放按钮的声音回放（回放时临时关闭麦克风录制）、给录音标注「这就是那个神秘蜂鸣」，以及一个「Reposition the devices」按钮——无需重启设备就能重新布点，用更精细的几何关系提升精度。最后还加了一个建议位置：根据已有数据在地图上提示在哪里再放一台监听器最有用。

给编码智能体装上「耳朵」

作者认为这个项目最有意思的部分，是它证明了可以给 Claude Code 装上耳朵。Claude 本身没有原生音频输入，但它能运行 JavaScript 和 Python 代码去分析麦克风采集的音频。让 Claude 启动带 WebSocket 的服务器、在设备上跑 WebAudio 麦克风、并允许通过连接推送新代码执行，这套组合让它能反复查询音频日志、重新配置自己的「听觉」来推进问题。

他提到在 GitHub Universe 上听 Martin Woodward 讲过类似做法：把 GitHub Badge 电脑通过 USB-C 接到电脑上，再用摄像头对着它的屏幕，这样编码智能体就能判断更新是否生效。给智能体创造感知现实世界的通道，本身就是一个很有想象空间的探索方向。

关键要点

• 用多台普通设备 + Python 服务器 + 浏览器 WebAudio 就能搭出一套可用的声源三角定位系统，无需专用硬件
• 定位精度的核心是时间对齐：借由一台设备播放啁啾声，让各监听器的录音片段可以互相对齐
• 音频分析代码可以在监听端热更新推送，避免因麦克风权限弹窗而逐台操作设备
• 视觉与听觉等感知通道可以被「外挂」给编码智能体，显著扩展其自主解决问题的能力
• 粗糙定位 + 拍手验证 + 声音回放的组合，让系统既好用又能让人建立信任