
用 AI 幫我開發睡眠分析工具 — 一個週末專案的完整紀錄
用 AI 快速打造夜間睡眠監控系統 — 8 小時搞定個人專案
> Patch Note
最近發現 AI 開發工具改變了個人專案的投入產出比。以前覺得「太麻煩,算了」的想法,現在會變成「其實可以試試看」。這次用週末 8 小時,跟 AI 協作打造了一個睡眠監控系統,用來分析半夜被吵醒的原因。雖然問題很日常,但實作過程蠻有意思的,值得記錄一下。
住在吵雜的城市,半夜被莫名其妙的聲音弄醒是常態。最煩的是你永遠不知道是什麼把你吵醒的 — 腦袋還在睡眠模式,等你完全清醒,聲音早就停了。沒辦法定位問題,就沒辦法解決問題。結果就是亂猜:換隔音窗?買白噪音機?搬家?全都是賭博。
所以我決定做個工具來搞清楚這件事。
環境與前置
這個專案其實建立在我現有的 smart home 基礎上。本來就有 Home Assistant 在跑,配了一堆感應器:motion、door、temperature、humidity、CO₂、air quality 什麼的。這次只需要加上音訊收集和睡眠數據整合。
新增的硬體:
- 兩支便宜的 USB 麥克風,一支放室內,一支面向街道
- 一台 Raspberry Pi 4 做音訊處理
- 現有的 Garmin 手錶提供睡眠數據
軟體 stack:
- Home Assistant 做設備整合和自動化
- Python + pyaudio 做音訊檢測
- Node.js + Express 做後端 API
- React 做前端(Progressive Web App)
- SQLite 存資料
選 Raspberry Pi 是因為便宜、省電,而且可以 24/7 跑。pyaudio 處理音訊算是標配,雖然文檔不太友善,但社群支援度高。前端用 React 是因為想做成像音樂編輯器的 timeline UI,需要比較複雜的互動。
重點是整套系統只在我在家睡覺時才啟動。透過 Home Assistant 的 automation,偵測到我在家、在床上、而且是睡眠時間,才會開始錄音。其他時候完全關閉,連麥克風權限都沒有。
實作步驟
Step 1: 音訊檢測
最核心的是音量檢測邏輯。不能一直錄音(隱私問題),也不能錯過重要聲音。我的做法是即時監控音量,超過閾值才開始錄音,並且會包含觸發前後幾秒的內容:
import pyaudio
import numpy as np
import wave
import threading
from collections import deque
class AudioDetector:
def __init__(self, threshold=0.01, pre_record_time=3, post_record_time=2):
self.threshold = threshold
self.pre_record_time = pre_record_time
self.post_record_time = post_record_time
self.buffer = deque(maxlen=int(44100 * pre_record_time)) # 3秒緩衝
def detect_sound(self):
p = pyaudio.PyAudio()
stream = p.open(
format=pyaudio.paInt16,
channels=1,
rate=44100,
input=True,
frames_per_buffer=1024
)
while self.is_active:
data = stream.read(1024)
audio_data = np.frombuffer(data, dtype=np.int16)
volume = np.sqrt(np.mean(audio_data**2))
self.buffer.append(audio_data)
if volume > self.threshold:
self.save_audio_clip(list(self.buffer))
stream.stop_stream()
stream.close()
一開始我設定的閾值太低,結果冰箱運轉、空調切換都會觸發。後來調高到只有比較明顯的聲音才會記錄。這個數值需要根據環境調整,沒有標準答案。
Step 2: Home Assistant 整合
讓 Raspberry Pi 跟 Home Assistant 溝通,這樣才能做到「只在睡眠時間啟動」的邏輯:
import requests
import json
class HomeAssistantClient:
def __init__(self, ha_url, access_token):
self.ha_url = ha_url
self.headers = {
'Authorization': f'Bearer {access_token}',
'Content-Type': 'application/json'
}
def get_person_state(self, person_id):
response = requests.get(
f'{self.ha_url}/api/states/{person_id}',
headers=self.headers
)
return response.json()['state']
def is_bedtime(self):
# 檢查是否在家、在臥室、且是睡眠時間
person_state = self.get_person_state('person.waiting7777')
current_time = datetime.now().time()
sleep_start = time(22, 30) # 10:30 PM
sleep_end = time(8, 0) # 8:00 AM
is_home = person_state == 'home'
is_sleep_time = current_time >= sleep_start or current_time <= sleep_end
return is_home and is_sleep_time
Home Assistant 的 REST API 還算好用,就是 bearer token 要記得定期更新。我一開始偷懶用 long-lived access token,後來改成 OAuth 比較安全。
Step 3: 睡眠數據整合
Garmin Connect 有 API 可以拿睡眠數據,包含睡眠階段、心率、HRV 這些:
// 後端 API 整合 Garmin 數據
const axios = require('axios');
class GarminClient {
constructor(clientId, clientSecret) {
this.clientId = clientId;
this.clientSecret = clientSecret;
this.accessToken = null;
}
async getSleepData(date) {
const response = await axios.get(
`https://apis.garmin.com/wellness-api/rest/sleepData`,
{
headers: {
'Authorization': `Bearer ${this.accessToken}`
},
params: {
uploadStartTimeInSeconds: Math.floor(date.getTime() / 1000),
uploadEndTimeInSeconds: Math.floor((date.getTime() + 86400000) / 1000)
}
}
);
return response.data.sleepMovement;
}
}
Garmin 的睡眠數據結構還蠻詳細的,會標記每個時間點的睡眠階段(deep、light、REM、awake),這是整個專案最關鍵的數據。
Step 4: Timeline UI
前端最有挑戰性的是做出類似音樂編輯器的 timeline。需要多軌道顯示、縮放、同步捲動:
import React, { useState, useRef, useEffect } from 'react';
const SleepTimeline = ({ sleepData, audioEvents, sensorEvents }) => {
const [zoom, setZoom] = useState(1);
const [currentTime, setCurrentTime] = useState(0);
const timelineRef = useRef(null);
const renderSleepStages = () => {
return sleepData.map((stage, index) => (
<div
key={index}
className={`sleep-stage sleep-${stage.stage}`}
style={{
left: stage.startTime * zoom,
width: stage.duration * zoom,
backgroundColor: stage.stage === 'awake' ? '#ff4444' :
stage.stage === 'deep' ? '#2196f3' : '#90caf9'
}}
onClick={() => handleStageClick(stage)}
>
{stage.stage}
</div>
));
};
const renderAudioEvents = () => {
return audioEvents.map((event, index) => (
<div
key={index}
className="audio-event"
style={{ left: event.timestamp * zoom }}
onClick={() => playAudio(event.audioFile)}
>
🔊
</div>
));
};
return (
<div className="timeline-container" ref={timelineRef}>
<div className="track sleep-track">
<div className="track-label">Sleep Stages</div>
<div className="track-content">
{renderSleepStages()}
</div>
</div>
<div className="track audio-track">
<div className="track-label">Audio Events</div>
<div className="track-content">
{renderAudioEvents()}
</div>
</div>
</div>
);
};
最有用的功能是會自動標記睡眠階段轉換的時間點。當我從深度睡眠轉到淺眠,或者直接醒來,時間軸上會用紅色標示。點擊這些時間點就能聽到當下的環境音。
我一開始想用 Canvas 做動畫,後來發現用 CSS transform 配合 React state 就夠了,而且手機上也跑得順。
效果與數據
週末花了大概 8 小時完成核心功能,之後幾天陸續加了一些改進。用了兩個星期後,有些有趣的發現:
睡眠干擾統計:
- 60% 是外面的交通噪音(特別是垃圾車和機車)
- 25% 是樓上鄰居(主要是腳步聲和椅子移動)
- 10% 是室內設備(冰箱、空調、熱水器)
- 5% 查不出原因(可能是太輕微的聲音)
最有價值的發現是垃圾車固定在凌晨 3:15 經過,而且會連續吵醒我三天。知道原因後解決方案就很明確了:換個朝向的房間睡覺,或者用耳塞。
系統運作狀況:
- 每晚平均記錄 8-12 個音訊事件
- 儲存空間每天大概 50MB(音訊檔案)
- Raspberry Pi CPU 使用率平均 15%
- 電池續航力對整體系統沒影響(都是插電設備)
Progressive Web App 的推播通知很實用,早上起床滑手機就能馬上看昨晚的分析報告。
Meta 判讀
這種個人專案在目前的 AI 工具 meta 裡算是很典型的例子。以前會因為「工程量太大」而放棄的想法,現在變成週末可以搞定的 side project。
AI 輔助開發降低了很多門檻:
- 不熟悉的 API 整合(Garmin Connect、Home Assistant)
- UI 元件的實作細節(timeline、audio player)
- 數據處理邏輯(音訊分析、時間同步)
但核心的系統架構、產品設計、debug 還是要自己來。AI 更像是把「Google + StackOverflow + 文檔閱讀」的流程加速了 5-10 倍。
這類工具的投資價值不高(用戶基數太小),但對於 prototype 和 MVP 開發來說,現在是最好的時代。個人開發者可以用很低的成本驗證想法。
結論
整體來說很值得做。不只是因為解決了睡眠問題,更重要的是驗證了一個想法:AI 工具已經把個人專案的門檻降低到「有想法就能快速實作」的程度。
推薦給有類似困擾的人試試。如果你已經有 smart home 設備,加上音訊監控的成本很低(一台 Pi + 麥克風大概 3000 塊)。沒有現成系統的話,可能要先評估一下投入產出比。
下一步打算加上 AI 音訊識別,自動分類噪音類型。不過目前手動分析已經夠用了,先把基本功能穩定下來再說。
延伸閱讀
Waiting7777
WoW Arena 冠軍轉前端,用電競 meta 思維拆解技術趨勢。
相關文章
GitHub CopilotAI Agents+5GitHub 用 AI 自動跑 fuzzing — 資安測試要被取代了嗎?
AI 做 fuzzing 這件事的意義不只是「測試更快」,而是把過去需要資安專家才能做的事民主化了。拆解 Taskflow Agent 的工作流程,評估它實際上能取代多少人工、局限在哪。
2026年9月25日 · Waiting7777 · 7 分鐘閱讀
繼續閱讀 →
GPTAI+2AI 第三時代:「永遠在線的 AI 同事」這個概念是真的嗎?
從「AI 同事」這個框架切入,評估這個概念是真實趨勢還是產品行銷話術 — 什麼樣的工作場景真的需要 persistent AI,什麼場景還是用工具就夠了。
2026年9月20日 · Waiting7777 · 7 分鐘閱讀
繼續閱讀 →
AI監管+3AI 大老們喊了幾年「管管我們吧」,然後呢?一份帶點諷刺的時間軸
從「說一套做一套」的角度切入:AI 高管喊監管不是新鮮事,但每次都有具體的時機背景。整理這條時間軸背後的商業動機 — 喊監管,往往是為了鞏固自己的護城河。
2026年9月18日 · HW SHU · 5 分鐘閱讀
繼續閱讀 →這篇文章對你有幫助嗎?
每週一篇 — 技術趨勢背後的商業邏輯
AI 產業在變什麼、工程師該注意什麼——拆清楚寄到你的信箱。