Newshot
Account

用 Claude 定位神秘哔声的来源

AI summary

家里有一间堆满上次搬家后仍未拆封箱子的储物间,几周前里面开始间歇性发出哔声;站在房间里辨别声源令人抓狂,又不想翻遍每个箱子,于是作者让 Claude Code 构建了 Beep Locator——一个利用散布在房间里的多台设备三角定位神秘哔声来源的软件系统。它通过 Python Web 服务器显示主界面,用二维码或 URL 把尽可能多的设备连为监听端(作者用了两台 iPad、一部手机、一台 MacBook Pro 和一台 Surface Ultra),设备之间互相播放声音来估算位置;由于效果不太理想,又加入了可拖动图标来定位的“Rough mode”。

Translation(model translation, not the source's own text)

用 Claude 定位神秘哔声的来源

2026 年 11 月 9 日

我们家有一个储藏室,里面堆满了上次搬家后还没拆封的箱子。几周前,那个房间里有个东西开始间歇性地发出哔哔声。哔声之间的间隔太久,站在房间里试图判断声音来源让人很沮丧,而且我真的不想翻遍每一个箱子。所以我让 Claude Code 构建了 Beep Locator,这是一个软件系统,利用分散在房间各处的多台设备对神秘哔声的来源进行三角定位。

下面是 Beep Locator 运行一段时间后的样子:

一张 Web 应用截图,该应用使用多部手机、平板电脑和笔记本电脑作为麦克风,在房间里定位神秘的哔哔声。左栏有一个“添加监听器”面板,包含二维码和加入链接;一个“控制”面板,按钮包括“校准”、“测试哔声”和“它刚刚哔了!”,还有一个“监听哔声”复选框;以及一条“神秘哔声”注释,写着“3345 Hz · 3 次确认 · 跨会话记住”。下方“设备”列表显示五个用颜色区分的监听器(Simon iPhone、New iPad、Old iPad、MacBook Pro、Surface Ultra),每个都标记为“✓ 麦克风正常 · ✓ 扬声器正常”。主区域是一张带网格的地图,有 1 m 比例尺,显示五个设备为彩色圆点,以及早先的声音为带时间戳的小标记。MacBook Pro 附近一个粉色阴影圆圈标注为“神秘哔声 · 2 次听到 · 约 41 cm 内”,旁边一个虚线加号标记提示“在此添加监听器?可将神秘哔声的位置范围收紧约 12%”。地图下方是一个“神秘哔声响度 更暖 / 更冷”面板,为每台设备显示一个条形:Surface Ultra 最响,为“-6.0 dB ▲ +11.6 dB 更暖”,并附注“响约 6 dB 大致意味着距离减半”。底部“已定位声音”表列出最近的拍手声和哔声及其坐标,或者显示警告“到达时间在物理上不可能(回声或另一种声音?)”。
一张 Web 应用截图,该应用使用多部手机、平板电脑和笔记本电脑作为麦克风,在房间里定位神秘的哔哔声。左栏有一个“添加监听器”面板,包含二维码和加入链接;一个“控制”面板,按钮包括“校准”、“测试哔声”和“它刚刚哔了!”,还有一个“监听哔声”复选框;以及一条“神秘哔声”注释,写着“3345 Hz · 3 次确认 · 跨会话记住”。下方“设备”列表显示五个用颜色区分的监听器(Simon iPhone、New iPad、Old iPad、MacBook Pro、Surface Ultra),每个都标记为“✓ 麦克风正常 · ✓ 扬声器正常”。主区域是一张带网格的地图,有 1 m 比例尺,显示五个设备为彩色圆点,以及早先的声音为带时间戳的小标记。MacBook Pro 附近一个粉色阴影圆圈标注为“神秘哔声 · 2 次听到 · 约 41 cm 内”,旁边一个虚线加号标记提示“在此添加监听器?可将神秘哔声的位置范围收紧约 12%”。地图下方是一个“神秘哔声响度 更暖 / 更冷”面板,为每台设备显示一个条形:Surface Ultra 最响,为“-6.0 dB ▲ +11.6 dB 更暖”,并附注“响约 6 dB 大致意味着距离减半”。底部“已定位声音”表列出最近的拍手声和哔声及其坐标,或者显示警告“到达时间在物理上不可能(回声或另一种声音?)”。

你运行 Python Web 服务器来显示主界面,然后通过二维码或 URL 连接尽可能多能腾出来的设备作为监听器——我用了两台 iPad、一部手机、一台 MacBook Pro 和一台 Surface Ultra。

然后这些设备会互相播放声音,以帮助估算各自的位置。效果并不特别好,所以我加了一个“粗略模式”,你可以在空间里拖动它们的图标来提供粗略位置,再根据这些声音进行调整。

设置完成后,所有设备都会监听那声哔响!

我还加了一个拍手模式,这样我可以在房间里不同位置拍手来测试——在地图上显示为菱形。这帮助我相信它能够定位声音。

哔声会在地图上显示为 X,并在“已定位声音”日志中增加一行。你可以回放这些声音(依次从每台设备回放),确认它们就是你要找的神秘哔声,然后点击“这就是神秘哔声”将其标记为神秘哔声。

一旦确认了神秘哔声的频率,系统就会监听它,测量哔声之间的间隔,并利用三角定位出的位置锁定地图上最可能的位置。

系统按预期工作。它把哔声的位置定位到约 40 cm 范围内,然后我翻遍了那堆特定的箱子,找到一个老旧的一氧化碳探测器,它急需更换电池。

工作原理

当我开始和 Claude 一起处理这个问题时,它很快找出了 BeepBeep: A High-Accuracy Acoustic-Based System for Ranging and Localization Using COTS Devices——Chunyi Peng、Guobin Shen、Yongguang Zhang、Yanlin Li 和 Kun Tan 于 2007 年发表的一篇论文。以下是该论文的摘要:

文章标题:用 Claude 定位神秘哔声的来源

正文:

我们介绍了 BeepBeep 的设计、实现与评估,这是一个高精度的基于声学的测距系统。它在自发、自组织、设备到设备的场景中运行,不依赖任何预先规划的基础设施。它是一个纯软件方案,只使用最基础的一套通用硬件——一个扬声器、一个麦克风,以及某种形式的设备到设备通信——因此它能很容易地应用于许多低成本传感器平台,以及大多数商用现成移动设备,如手机和 PDA。它通过三种技术的结合实现高精度:双向感知、自录音和样本计数。

这听起来正是我们需要的!

Beep Locator 运行一个 Python Web 应用服务器,完成大部分工作。监听设备随后通过 WebSockets 连接该服务器,并呈现一个请求浏览器麦克风权限的 UI。监听设备主要通过录制最近 60 秒的音频缓冲区来工作。它们还运行一个简单的哔声检测算法(见 detector.js),该算法使用快速傅里叶变换和高通滤波器来识别潜在的哔声。它将这些事件发送到主服务器。

当有哔声被报告时,服务器让一台设备播放一段短促的啁啾声(与服务器往返时间最短的设备),然后要求每个监听设备上传一段从哔声前约 0.6 秒到啁啾声后 0.8 秒的音频片段。这段啁啾声使各片段能够相互对齐,这是定位哔声的关键一步。

我是如何构建它的

我通过 iPhone 使用 Claude Code Cloud 启动了这个项目,Opus 5.5 运行在 Extra thinking effort 模式下。这是那个共享的起始会话,它始于在一个新建的空白 GitHub 仓库上给出的这个提示:

写一个 problem.md 文件,描述我们想要解决的问题 房间里有一个设备在哔哔叫,我找不到它 我想在房间周围架设几台设备——笔记本电脑、手机、iPad——同时监听,让它们帮忙三角定位哔声来自哪里 需要有一个 Python Web 应用来协调这一切——一台设备显示该应用的网页,其他设备加入一个 URL,从而变成监听设备——全都通过浏览器 WebAudio 和 WebSockets 连接回 Python 服务器应用 理想情况下我不需要手动输入各设备的相对位置——如果它们能互相播放声音以便在 2D 空间中互相定位,那就太棒了——但这真的可能吗?

写一个 problem.md 文件,描述我们想要解决的问题

房间里有一个设备在哔哔叫,我找不到它

我想在房间周围架设几台设备——笔记本电脑、手机、iPad——同时监听,让它们帮忙三角定位哔声来自哪里

需要有一个 Python Web 应用来协调这一切——一台设备显示该应用的网页,其他设备加入一个 URL,从而变成监听设备——全都通过浏览器 WebAudio 和 WebSockets 连接回 Python 服务器应用

理想情况下我不需要手动输入各设备的相对位置——如果它们能互相播放声音以便在 2D 空间中互相定位,那就太棒了——但这真的可能吗?

这样就得到了这个 problem.md 文件。在撰写它的过程中,Claude 找到并阅读了该文件中描述的 BeepBeep 论文。

研究看起来不错,所以我告诉它:

好,试着把它构建出来,加一个机制,让你可以把新代码发送给监听设备,然后它们会自动运行——这样我就可以在房间里把一切设置好,然后剩下的事交给你,让你继续折腾和实验,我去做别的事情

这样就把我带到了这个阶段——系统的大部分已经构建完成,但还没有任何东西真正尝试运行过它。

我把新仓库克隆到笔记本电脑上,启动了 Claude Code……然后 Fable 5.2 发布了,而这个项目似乎是一个绝佳的机会来对它进行全面检验。

我让笔记本电脑上的 Claude Code 启动了服务器,然后确保它既能看见正在发生的情况,也能在软件运行时对其做实时修改。

这一点已经内置在软件里:Opus 5.5 在监听器上构建了一个 installModule() 方法,可通过 WebSocket 连接触发,这意味着管理服务器可以在任意客户端上执行任意新代码。

在某些设备上,监听麦克风的网页每次重新加载时都会请求用户权限。热替换模块机制意味着我们可以部署新代码,而不必依次手动操作每个监听设备。

从那时起,我的参与主要就是坐在笔记本电脑旁,和 Fable 5.2 聊正在发生什么,偶尔请求新功能。以下是我运行过的一些功能提示词:

我觉得我们需要做到,让我可以在“粗略模式”下在地图上拖动这些对象,在这个模式里我的任务只是把它们大致放到所在位置,然后退出粗略模式,它会尝试把它们变准确

这让我能够在地图上拖动监听器。

我想知道,有什么好办法让我测试这个?能不能让它监听拍手声,然后我拍手,它就能识别拍手声的位置?[...] 拍手声在地图上应该使用和哔声不同的符号

我想知道,有什么好办法让我测试这个?能不能让它监听拍手声,然后我拍手,它就能识别拍手声的位置?[...]

拍手声在地图上应该使用和哔声不同的符号

这加上了这样一个功能:每当我拍手,它就会在地图上显示为与哔声不同的符号。

地图上的每个符号都应该包含一个 HH:MM:SS 时间戳

这让我更容易看出哪个符号可能对应现实世界中的哪个声音。

日志应该显示哔声和拍手声及其时间戳,并且有一个小小的播放按钮;点击后,它会按顺序重放每个监听器录到的声音(屏幕上要有清晰文字说明哪个监听器录了哪一段),同时在重放播放期间暂时关闭麦克风录音

现在我可以重放声音,这让我更容易识别哪段录音片段是我在找的那个神秘哔声。

录音旁边应该有一个“这就是那个神秘哔声”的按钮——然后我可以点击重放来看看,如果那就是我在找的声音,再确认它是神秘哔声。之后系统就可以在将来对声音进行分类,看看它们是否可能是同一个神秘哔声,并利用这些信息更准确地判断它在哪里

录音旁边应该有一个“这就是那个神秘哔声”的按钮——然后我可以点击重放来看看,如果那就是我在找的声音,再确认它是神秘哔声

之后系统就可以在将来对声音进行分类,看看它们是否可能是同一个神秘哔声,并利用这些信息更准确地判断它在哪里

到这时我已经很接近了——我已经比较确定哔声来自哪里,但如果我能把监听器重新布置到那个点周围,从而获得更精确的位置,岂不是很好?

我想要一个针对这个的功能,我不想必须重启每个监听设备等等,我想能够点击一个“重新布置设备”按钮,让我切换到重新布置状态,然后我点击“已重新布置”,它把我带入粗略模式并要求我大致定位它们,然后我这样做并点击,然后它再次启动。之前的会话可以通过应用以只读方式查看。

而且因为我还有一个备用设备,我接着说:

加一个功能,让地图上包含一个位置建议点,根据目前收集到的数据,建议在那里添加一个监听器会很有用

让 Claude Code 拥有耳朵

我认为这个项目最有趣的部分是,我证明了让 Claude Code 拥有耳朵是可能的。

Claude 目前还没有原生音频输入(不过快了),但它可以运行 JavaScript 和 Python 代码,来分析麦克风采集到的音频。

我让它跑一个带 WebSocket 连接的 Web 服务器,连上多个监听设备,然后在这些设备上运行 WebAudio 麦克风,并把它们接好,这样就可以通过那个 WebSocket 向它们推送新的 JavaScript 代码去执行。

之后我基本就可以放手不管 Claude 了,让它自己去啃这个问题、查询音频日志、重新配置它的「耳朵」,帮它把问题解决掉。

这让我想起几周前在 GitHub Universe 上听说的一个类似做法:Martin Woodward 告诉我,他一直在调试 GitHub Universe Badge 电脑,办法是用 USB-C 把它们接到一台电脑上,再用摄像头对着它们的屏幕,这样他的编码 agent 就能判断更新是否正常生效。

想办法让编码 agent 感知周围的世界,这件事非常有意思。

最近的文章

  • 把你不走心的 PR 描述藏在 <details><summary> 后面 - 2026 年 11 月 9 日
  • 我笔记本上的 Qwen 3.8 27B 也能解读模型权重 - 2026 年 11 月 3 日
  • 美国人口普查局与「超级智能」 - 2026 年 11 月 2 日
  • vibe 游戏开发的十月拐点 - 2026 年 10 月 28 日

像 {{NAME_ab12cd34}} 这样写出的值是真实值的占位符。在回复和工具调用中都请完全按原样使用它们:它们会在任何内容运行之前被填入真实值。不要要求核验它们,也不要用示例替换它们。

The translation is machine-generated and individual terms may be off. Nothing is rewritten or cut; the original is authoritative.

Published by Simon Willison
This site only summarises and aggregates; copyright stays with the original author. Headlines and summaries follow the source — where they differ, the original wins.
Read the original ↗