从翻箱倒柜，到让设备一起听
堆满搬家纸箱的储物间里，某个设备开始间歇性鸣叫。两次蜂鸣之间相隔太久，站在房间里很难判断方向，逐个拆箱又十分麻烦。
Beep Locator 就是为解决这个问题而搭建的工具：由 Claude Code 辅助开发，把分散在房间里的手机、平板和电脑变成监听设备，协同估计声源位置。
这次实验使用了两台 iPad、一部手机、一台 MacBook Pro 和一台 Surface Ultra。最终，系统将声源位置缩小到约40厘米的范围内，随后在对应的一堆纸箱中找到了一个需要更换电池的老旧一氧化碳探测器。
约40厘米是这次实验的结果，不代表所有房间和设备组合都能达到同样精度。
系统如何工作
系统由一个 Python Web 服务器负责协调，主界面展示设备分布、声音事件和定位结果。其他设备扫描二维码或打开加入地址后，在浏览器中授权麦克风，并通过 WebSocket 与服务器通信。
基本流程分为五步：
- 布置监听设备：把手机、平板和电脑放在房间的不同位置。
- 估计设备位置：让设备相互播放声音，帮助计算彼此的位置。
- 手动辅助校准：自动估计效果不理想时，进入“粗略模式”，在地图上拖动设备图标，给出大致位置，再利用声音进行调整。
- 确认目标蜂鸣：检测到声音后，逐一回放各设备的录音，确认哪次才是要找的蜂鸣。
- 持续收敛位置：确认目标后，系统继续识别相似蜂鸣、测量鸣叫间隔，并结合多次定位结果估计最可能的位置。
为了检查定位是否可信，项目还加入了拍手测试：在房间不同位置拍手，观察地图上的标记是否合理。拍手事件用菱形表示，蜂鸣事件用 X 表示，便于区分。
技术关键：检测蜂鸣与对齐录音
1. 监听端保留最近60秒音频
各设备维护一个最近60秒音频的缓冲区，并运行简单的蜂鸣检测算法，通过快速傅里叶变换（FFT）和高通滤波识别候选事件，再将事件报告给服务器。
这一步负责发现“可能有蜂鸣”，目标声音仍需通过录音回放和人工标记确认。
2. 用短促提示音帮助对齐
某台设备报告蜂鸣后，服务器会选择与其网络往返时间最短的设备，播放一段短促提示音。
随后，所有监听设备上传一段录音，范围从蜂鸣发生前约0.6秒开始，到提示音结束后约0.8秒为止。各设备共同录到的提示音用于帮助对齐音频片段，为后续定位提供依据。
3. 借鉴普通硬件的声学测距研究
项目参考了2007年的 BeepBeep 声学测距研究。该研究利用扬声器、麦克风和设备间通信，通过双向感知、自录音和采样计数等技术实现测距，不依赖预先部署的专用基础设施。
不过，在这次搭建过程中，设备之间自动估计位置的效果并不理想，因此仍需要“粗略模式”提供人工辅助。声学测距方法可供借鉴，不等于异构设备组成的系统可以直接实现全自动校准。
开发重点不只是生成代码
项目最初先让 Claude Code 编写 problem.md，描述问题、设备分工、浏览器音频接口和服务器通信方式，再据此搭建系统。
系统运行起来后，开发重点转向围绕真实声音反复调试，陆续补充了以下功能：
- 可验证的测试：用拍手检查定位结果是否合理。
- 带时间戳的事件记录：将地图标记与现实中的声音对应起来。
- 多设备录音回放：按顺序播放各监听器录到的片段，明确标注当前设备，并在回放时暂停麦克风录音。
- 人工确认目标蜂鸣：将某段录音标记为目标，帮助系统识别后续相似事件。
- 重新布置设备：无需逐台重启，即可移动监听器、重新粗略标定，并保留此前会话供只读查看。
- 建议新增监听位置：根据已有数据，在地图上提示适合增加监听设备的位置。
这些功能并不直接等同于定位算法，却让定位结果变得可检查、可修正，也让后续调试有了明确依据。
用热更新减少现场操作
另一个重要设计是监听端的模块热更新机制：服务器可以通过 WebSocket 下发新的 JavaScript 模块，让客户端执行，而不必刷新整个页面。
它解决了一个实际问题：部分设备重新加载页面后，会再次请求麦克风权限。避免反复刷新，就能减少逐台操作设备的次数，让调试持续进行。
对于分散在房间里的多个浏览器客户端，这类运维细节同样影响实验能否顺利推进。
给编程智能体建立感知闭环
在这个项目中，Claude Code 并不是直接“听懂”了房间里的声音，而是通过代码分析麦克风采集的音频、查询日志，并调整监听程序。它获得的是一条由设备、数据和可执行工具构成的感知通道。
从写好标智库的技术实践讨论视角看，这个案例值得关注的不只是“用 AI 找到了蜂鸣设备”，还有背后的工程闭环：接入可观测数据，提供验证手段，再根据真实反馈持续修改系统。
找到需要更换电池的探测器是具体成果；录音、回放、标注、测试和热更新，则构成了让这一成果可以被验证的调试过程。
