为了找出家里储物间持续数周的间歇性蜂鸣声，知名开发者 Simon Willison 没有翻箱倒柜，而是在 2026 年 11 月 9 日用 Claude Code 写了一套开源声学三角定位系统 Beep Locator。他把 iPhone、两台 iPad、MacBook Pro 和 Surface Ultra 共 5 台闲置设备摆在房间里充当网页端麦克风，最终在 约 40 厘米（界面显示约 41 厘米）的精度范围内，从纸箱堆深处揪出了一个急需换电池的老旧一氧化碳探测器。与人类凭听觉盲目翻找相比，这套系统能锁死 3345 Hz 的特定声频；与 2007 年原版学术论文在实验室达到的 3 厘米定位精度 相比，它在真实杂物间里精度退化了十倍以上，却换来了零硬件改造、扫二维码即用的工程便利。
这场硬核抓虫表面看是一次极客炫技，实则捅破了 AI 辅助编程的一层新窗户纸。以 Claude Code 为代表的编码智能体，已经不再局限于帮程序员补全增删改查代码，而是能自主挖出近二十年前的学术文献、把复杂的信号处理公式改写成分布式全栈应用，并直接在物理房间里接管多台设备的实时联调。
几十毫秒的网页延迟，怎么抓出 1 毫秒的声波时间差
用手机和笔记本电脑的浏览器做声学定位（到达时间差 TDOA），横在面前的是一道物理鸿沟。声波在空气中走 40 厘米只需要约 1.2 毫秒，而各台设备的系统时钟根本不同步，WebSockets 网络通信与浏览器音频栈的录音延迟更是高达 几十毫秒。如果直接拿服务器收到报警的时间戳去算距离，误差能飞出几层楼远。
Willison 在 iPhone 上用 Claude Code Cloud（搭配开启 Extra thinking effort 模式的 Opus 5.5）启动项目时，AI 自己检索并研读了 2007 年发表于 SenSys 会议的经典论文《BeepBeep》。这篇由彭春义、沈国宾等人撰写的论文，早在多普达 PDA 年代就提出了一套不依赖基础设施的纯软件测距方案，核心靠双向传感、自录制与样本计数三大机制绕开时钟同步难题。
Claude 把这套十九年前的论文逻辑完整搬进了现代浏览器。每台监听设备在前端维护一个 60 秒的音频缓冲区，用快速傅里叶变换（FFT）和高通滤波器实时捕捉可疑蜂鸣。一旦某台设备抓到信号并通知 Python 服务器，服务器不会直接用网络时间算坐标，而是立刻命令当前网络往返延迟最低的那台设备外放一段短促的同步声（Chirp），再让所有设备把蜂鸣前 0.6 秒到同步声后 0.8 秒的录音切片传上来。
因为神秘蜂鸣和事后同步声都被录在了同一台设备的同一段音频流里，系统只需要在每段录音内部数出两个声音之间的采样点个数，就能用这个共同的同步声作标尺，把所有设备的录音对齐。服务器与设备之间几十毫秒的 ping/pong 误差只用来粗略框定截取哪一段录音，真正的微秒级时间差全靠音频文件内部的 样本计数 解决。
从论文的 3 厘米到储物间的 40 厘米，物理定律逼人类出手兜底
把论文算法变成代码只是第一步，真正在堆满搬家纸箱的房间里跑起来时，理论精度撞上了残酷的室内声学物理极限。
2007 年的 BeepBeep 论文（及 2012 年扩展发表的 ACM TECS 版本）在受控实验和已知锚点条件下，测距平均绝对误差只有 0.9 至 2.7 厘米，定位精度可达 3 厘米。但在 Willison 的储物间里，纸箱和墙壁构成了复杂的声波多径反射场。原论文早就警告过，室内反射声（回声）叠加后，往往会产生比直达声更强的信号峰值。
这种物理干扰直接废掉了系统的全自动设备校准。Willison 最初希望 5 台设备通过互相放声音，自动算出各自在房间里的二维坐标，但实测效果很差。即便代码库里已经用上了匹配滤波器（matched-filter）、首次到达（first-arrival）波峰检测 以及异常值剔除，界面日志里依然频频弹出警告，提示某次声音的到达时间在物理上不可能成立（疑似回声或杂音）。
全自动方案走不通，人机协同就成了绕不过去的妥协。Willison 让 AI 加上了手动拖拽设备图标的粗略模式（Rough mode），先由人眼把 5 台设备摆在网格图的大致位置上，再结合声学数据微调；为了验证系统没瞎算，他又加了拍手模式，绕着房间拍手看地图上跳出的菱形标记准不准。加上利用声压级每增加约 6 dB 距离大致减半的冷热条提示（Surface Ultra 录到的声音比基准高出 11.6 dB），40 厘米的精度虽然比不上实验室的 3 厘米，但足够帮人类把翻找范围缩小到一摞纸箱。
- 风险.这套系统在真实房间的表现高度依赖环境反射条件，代码仓库里的仿真测试虽然覆盖了时钟漂移、不同采样率和单次反射，但换一个回声更重的房间，并不能保证复现 40 厘米的定位精度。
给编码智能体装上耳朵，软件正在变成用完即扔的日用品
比声学算法本身更值得开发者警惕的，是 Willison 构建和调试这套系统的工作流。整套系统从零到跑通，人类程序员几乎没有亲手写业务代码，甚至没有守在那 5 台充当麦克风的设备前反复刷新网页。
在 iPhone 上用 Opus 5.5 搭好骨架并让它写下支持远程下发代码的 installModule() 机制后，Willison 把代码库克隆到笔记本电脑上，无缝切换到了刚发布的 Fable 5.2 模型。由于移动设备的浏览器一旦刷新页面就会重新弹窗索要麦克风权限，走传统的前端热重载等于每改一行代码都要跑去屋里点五次允许。
AI 编程的分水岭，是让模型自己看传感器日志并热替换在线代码。
因为 Opus 5.5 预先埋好了基于 WebSocket 的动态模块替换接口，接棒的 Fable 5.2 得以直接接管整个物理调试环路。Claude 虽然还没有原生音频输入能力，但它能自己查看后台收集的音频分析日志，判断哪里出了问题，再通过 WebSocket 把新写的 JavaScript 模块直接推送到 5 台正在录音的设备上 免刷新热替换。Willison 做的事情，只是坐在电脑前像产品经理一样提需求：加个时间戳、加个分段回放按钮（回放时自动暂停麦克风录音以防自激）、甚至让系统根据已有数据在地图上画个虚线十字，建议把多出来的闲置设备摆在哪里能再提升约 12% 的定位精度。
这和几周前 GitHub Universe 大会上开发者 Martin Woodward 展示的做法如出一辙：当时 Woodward 为了调试大会胸牌里的小电脑，把胸牌插上 USB-C 并用网络摄像头对准屏幕，让编码智能体自己看屏幕画面来判断刷机代码有没有跑通。
- 建议.硬件极客与独立开发者遇到涉及物理世界的棘手问题时，不妨先让高阶推理模型去检索二十年前的传感器或信号处理老论文，再让它写一套带 WebSocket 热更新的网页端调试底座，把闲置手机和平板变成零成本的验证阵列。
过去，为了找一个快没电的报警器去研读 2007 年的声学论文、手搓一套带 FFT 和匹配滤波器的分布式全栈软件，在投入产出比上是荒谬的。但当 Opus 5.5 和 Fable 5.2 把跨越学科门槛与多端联调的成本压到几个小时的闲聊时，这种用完即扔的一次性软件（Disposable Software）开始变得划算。接下来最值得紧盯的变量，不再是模型能不能把代码写对，而是开发者能用多快的速度，通过摄像头、麦克风和网页接口，把编码智能体放进真实的物理房间里自己干活。