用 Claude Code 把多台设备变成寻声阵列

储物室里偶尔响一声的电子提示音，怎么找到源头？开发者 Simon Willison 借助 Claude Code 做了一个 Beep Locator，让五台手机、平板和电脑通过网页一起「听声辨位」，最终找到了纸箱里的旧一氧化碳探测器。报道给出的定位范围约为 40 厘米。

这个项目值得程序员看，不只是因为 AI 帮忙写了程序。更有参考价值的是：作者如何把现实问题拆成声音识别、录音同步和位置估算，又如何在自动化不够准时，用手动操作把流程跑通。

五台设备为什么比一双耳朵更容易找到声音

据 IT之家 11 月 11 日报道，作者在 11 月 9 日发布博文，介绍了这次寻找异响的过程。搬家后，储物室堆着未拆封的纸箱，短促的「哔哔」声隔很久才响一次，靠耳朵很难持续追踪。

Beep Locator 的做法是把五台设备分散摆放，通过网页调用各自的麦克风，捕捉同一个声音，再比较声音抵达不同设备的时间差。

这里的关键不是哪台设备听起来更响，而是哪台先收到声音。声源到不同设备的距离不同，声音到达的时间也会不同，系统据此估算声源位置。

不过，时间差必须和设备位置配合使用。只知道某台手机先听见，却不知道它摆在哪里，还不足以推算声音来自哪个纸箱。

自动测位置不够准，就让人把位置标出来

开发过程中，作者尝试过自动测定设备的相对位置，但精度不足。随后，他加入了地图界面，让用户手动拖动图标、标注设备位置。

这个项目跑通的关键之一，是接受手动输入来补足自动测量的短板。

系统还要解决另一个问题：各台设备录到的，必须是同一次目标提示音，而且录音需要能放到同一条时间线上比较。

为此，程序利用快速傅里叶变换（FFT）分析声音频率，从环境杂音中识别目标提示音；再由一台设备发出短音，用来同步各端录音。前者帮助确认「找的是哪个声音」，后者帮助比较「这个声音什么时候到」。

原文没有展开短音同步的具体算法，也没有说明不同设备的录音延迟如何处理，不能据此推断它已经解决了所有跨设备同步问题。

功能完善后，系统还能建议新增设备的摆放位置，帮助进一步缩小搜索范围。作者最终按照定位结果检查纸箱，找到了旧一氧化碳探测器。项目代码已在 GitHub 公开，但所给原文没有附上可用的仓库地址。

我的判断

这个案例最有价值的地方，是展示了一条能落地的 AI 编程路径：先围绕具体问题搭出工具，再根据现场结果调整方案。网页负责连接现有设备，频率分析负责识别声音，时间差负责估算位置，手动地图补上不可靠的自动测量。

但「约 40 厘米」需要带着条件看。

报道给出了成功找到设备的结果，却没有提供测试次数、房间条件、设备型号或误差分布。因此，这更适合作为一次成功实践的报道，不能直接当作任意房间、任意设备组合下的精度承诺。

同样，原文没有给出开发耗时、AI 生成代码的占比，也没有和人工独立开发做对照。它能证明作者借助 Claude Code 完成了这个项目，不能证明某个效率提升幅度。

和逐箱排查相比，这套方案把听觉线索变成了可操作的位置提示；代价则是布置设备、标注位置和完成同步。如果箱子很少，直接找可能更省事。设备较多、提示音间隔又长时，这类工具的价值才更容易体现。

能拿来做什么

• 做浏览器音频实验时，可以沿用「多端采集、识别同一声音、同步录音、比较时间差」的拆分顺序，先验证每一环是否可靠，再组合定位功能。
• 用 AI 开发现场小工具时，可以参考作者的取舍：自动测量达不到要求，就先提供手动标注入口，让核心流程能够完成。
• 评估类似开源项目时，除了看演示效果，还应核对设备位置如何输入、录音如何同步，以及精度数字对应什么测试条件。原文没交代的部分，需要进一步检查项目代码和说明。