我用 AI 做了一个睡眠追踪工具，找出半夜到底什么吵醒了我

原文来源：I Let AI Build a Tool to Help Me Figure Out What Was Waking Me Up at Night — 一位开发者用 AI 编码工具在周末打造了个人睡眠追踪系统

我住在一个吵闹的城市里。有些晚上凌晨三点莫名其妙醒了，不知道是什么吵醒的。有时候没有完全醒过来，但第二天手表显示深睡在 3:32 被打断了。

最让人恼火的是你几乎永远不知道原因。被声音吵醒的时候，大脑还处在睡眠和清醒的过渡状态，等你能反应过来，噪音已经没了。除非它一直在响（比如雷声、停不下来的汽车警报），或者事后留下线索（闪电接着雷声），不然你只能在困惑中继续睡，而原因始终是个谜。

不知道原因就没法解决。是屋里还是屋外？邻居还是卡车？门还是马路？你想出的任何"解决方案"都只是猜测，而猜测往往是昂贵的。

所以，我开始了 😏

我做了什么

先交代一下背景：我家里已经有 Home Assistant 和一堆传感器（人体感应、门窗、灯光、温湿度、CO₂、空气质量）。大部分需要的数据已经在采集了，只差音频这块和睡眠数据。

需要补的东西其实不多：

• 两个便宜的 USB 麦克风，一个放在室内，一个伸出窗外对着街道
• 一台 Raspberry Pi（微型电脑），只在我在家且上床睡觉的时候才开始监听
• Garmin 手表的睡眠数据
• 一个跑在家庭服务器上的 Web 应用，整合音频、睡眠数据和传感器事件

当 Pi 听到足够响的声音时，会保存一段短音频，前后各留几秒上下文作为缓冲。整个监听模式通过 Home Assistant 控制：Pi 把自己暴露为一个 Home Assistant 集成，自动化只有在我在家、在床上、且在睡眠时间附近时才开启它。其他时间完全不工作，麦克风不会录音。这就是我想要的行为——即使是我自己的内网，也不需要一直监听。

Web 应用是真正发挥作用的部分。每个晚上的数据像音乐编辑器的音轨一样排列：一条睡眠阶段轨道，一条心率和 HRV 轨道，几条传感器事件轨道，还有一条噪音事件轨道，音频可以直接在浏览器里播放。

最有用的功能是它会在睡眠阶段发生变化或者你醒来的地方做视觉标记。早上看一眼昨晚的时间线，找到标红的那些瞬间，点一下就能听听当时发生了什么。

前端是个 PWA，带 Web Push 通知，只在我的家庭内网里提供服务。早上醒来看看手机，就能收到一条通知说昨晚的数据已经可以查看了。所有数据都不出内网。

AI 做了什么，没做什么

先说清楚：AI 是让我能在周末搞定这件事的原因。 整件事大概花了 8 个小时，加上接下来几天的零碎改进。没有 AI 工具，我根本不会开始。

但我没有用 AI 来识别具体的声音（至少目前还没有）。分辨是关门声还是洗碗声还是摩托车声，还是我戴着耳机自己听。工具只是告诉我哪些瞬间值得去听。

工作流上，我没有去读代码（有意识的选择）。我测试结果，发现不对就直接反馈，让 AI 通过截取浏览器截图来验证自己的输出。

在树莓派这边我还往前走了一步。Pi 是全新的空系统，我直接给了编码代理 SSH 访问权限，让它直接在设备上做实验。它会搭建一个测试方案，让我喊一声、扔个东西或者开水龙头，录下样本然后分析给我看，有时候还会拉出频谱图。我得明确跟它说要这样工作，但说清楚之后，这个迭代循环说实话还挺好玩的。

有趣的变化不在于 AI 解决了我的问题，而在于 AI 降低了建造解决问题的工具的成本。

关于睡眠数据

Garmin 手表的睡眠数据——说实话我不完全信任任何手表或戒指对睡眠阶段的精确判断。但它们有一个共同的优势：检测你什么时候真的醒了很准。

这些醒来事件加上粗略的阶段过渡就是我真正关心的东西。它们不是临床真理，是指示"这个瞬间值得查一下"的视觉标记。没有它们，我得坐着一小时一小时地听冰箱的嗡嗡声和邻居无所事事的动静。

我不是在做睡眠科学。我是想找到那些早上让我不舒服的原因。

发现的问题和解决办法

开始用这个工具之后，模式很快就浮现出来了。

常见的噪音源：

• 门。邻居用力关门的声音，或者屋里有人去洗手间时不太注意关门的声音
• 餐具。瓷器碰撞的高频尖锐声音在公寓里传播得惊人地远
• 街道。摩托车、踏板车、卡车、垃圾回收车——你猜我住在哪个国家
• 有时候，我以为是室外的噪音其实是室内的，反过来也一样

有了实际数据，我终于可以有针对性地行动而不是猜测了：

• 加装了隔音板（宜家那种办公室用的隔音板效果出人意料地好）
• 在卧室门和窗户周围加了额外的隔音条（硅胶、橡胶等）
• 对于一些室内噪音，解决方案不是硬件而是聊一聊 😄

不是完美解决方案（城市就是城市），但早上醒来时的感受和 Garmin 的数据都显示了改善。

技术细节

如果你对实现细节感兴趣：

Pi 持续录制到循环内存缓冲区（只在 Home Assistant 启用检测时）。音量超过阈值前不会写入任何内容。音频输入上加了噪声抑制，尽量压低环境底噪（远处车流的嗡嗡声、冰箱声等），减少误触发。

当阈值被触发时，带前后上下文的音频片段加上时间戳保存，同时一个 JSON 文件记录事件。片段被压缩成更小的音频文件以便存储多晚的数据。

Pi 上跑了一个微型 Web 服务器，向 Web 应用暴露噪音事件和音频片段，还有一个独立的带 token 认证的控制端点用于改变录音状态。这个控制端点被编码代理写的一个小 Home Assistant 集成消费，让自动化可以开关检测。

Garmin 的睡眠数据获取：有很好的开源库处理 Garmin Connect 认证。一个小脚本执行认证请求，拉取当天的活动存档，从中提取睡眠阶段、心率、HRV 和其他生物标记，同样显示为数据轨道。

Web 应用从三个来源拉数据：Garmin（睡眠）、Home Assistant（传感器事件）、Pi（噪音事件和音频）。全部拼接到同步时间线上，每个来源一条视觉轨道。市面上现成的音频播放器不支持我想要的多轨同步，所以我自己写了一个。

前端是 PWA + Web Push，只在家庭网络中提供服务。

还没做但想做的

现在的工具已经够用了，但有几个扩展方向：

• 只在有值得看的内容时通知我——现在不管有没有东西，每晚早上都会推送
• 用模型对相似的声音做聚类，然后一次性打标签（门、碗碟、摩托车），时间久了工具甚至可以自动判断新事件的声音来源
• 可视化聚类结果——即使不分类，看到噪音怎么聚合也会大大加快收听过程
• 条件告警——只有可能影响睡眠时才通知

这些大概每个又是一个周末。这也是这篇文章想说的事——我会慢慢做，也可能不做，因为现在的已经够用了。

为什么分享这个故事

具体的项目不重要，重要的是背后的模式。

有一整类很小的个人问题，以前属于"做出来是挺好，但不值得花时间造"。有了 AI 工具，很多这样的项目已经跨过了"好，周末试试"的门槛。

几个收获：

先测量再修。 我差点就下单了新床垫，还开始研究加厚窗帘。它们没准也有用，但没有数据，我无法确定正确的修复目标，也没法在事后知道效果。

上下文比原始数据重要。 一个噪音日志本身没什么用。同一个事件在不同的上下文里意义完全不同——是心率飙升了还是开门了还是深睡期。

选一个足够好的信号。 Garmin 的睡眠阶段不完美，但它的醒来检测已经够好用，足以把我指向值得听的那些瞬间。我要的就是这个。

AI 工具降低了个人的制造门槛。 现在每当有什么小事开始困扰我，我的第一个念头就是"有没有一个小系统可以帮我更好地理解这个？"答案从"可能不值得"变成了越来越经常的"可以"。

有一点要说清楚：我的软件工程背景是能在 8 小时内搞定的主要原因。我知道该问什么，也知道什么时候该对返回的结果保持怀疑。但这个项目的音频处理部分我是新手，之前没用过什么相关知识，大部分是零基础搭出来的。

不过这个代码我不会公开发布——它只基于结果测试过，没有经过正式的代码审查。在我的家庭内网里可以锁好它，但放到外面就不行。

如果你也住在吵闹的城市，睡眠追踪器总告诉你"你的睡眠不好"却不告诉你为什么——我推荐你试试类似的思路。不需要复刻我做的这套东西。就算只是在床头放个麦克风，早上回听那些峰值，你已经能学到很多 🤗

剧情反转：给门窗加完隔音之后，现在我得想办法智能地降低 CO₂ 浓度了……