用ESP32和麦克风DIY环境噪声监测提醒装置

1. 先说说为什么做Buzz：被“吵”出来的DIY项目

Buzz这个项目的起点特别朴素：我经常需要把一段代码一口心思啃到底，可办公区偏偏有微波炉“叮”、隔壁打电话、同事拖椅子的声音来回轰炸。反过来放假在家时，我泡杯咖啡想安静看书，楼下装修的电钻声又能把我从椅子上震起来。于是我决定给自己做一个小装置，它不录像、不录音、不联网偷窥隐私，只干一件事：盯着环境噪声，超过我设定的心里线，就用蜂鸣器轻轻“Buzz”几声提醒我，顺便用LED灯环把当前的吵闹程度可视化。项目名干脆就叫Buzz，既是蜂鸣器那个“嗡嗡”的拟声词，也是提醒你“注意，环境已经太吵了”的信号。

做这个项目的目标读者不是专业声学工程师，而是和我一样，有一点Arduino或ESP32基础、想用现成模块解决真实生活问题的人。它最核心的技术路径并不复杂：麦克风采集声音，ADC把模拟信号变成数字值，单片机算出一个代表“音量大小”的均方根值RMS，再和阈值比较，最终触发蜂鸣器。听起来简单，但把这一串链路做稳定、做准、做得不烦人，里面有大量文档里不会写清楚的细节。这篇文章会把我的完整思路、电路连接、代码实现和踩坑过程全部摊开。

1.1 一个真实痛点：为什么不能只靠手机App

很多人会问，手机上随便一个分贝计App就能看环境噪音，为什么还要单独做一个硬件？我用过一段时间后才明白，手机方案有几个天然短板：麦克风权限常驻耗电很凶，通知优先级一低就容易被忽略，而且每次看读数都得解锁屏幕，等于又给自己增加了一次注意力转移。更麻烦的是，手机放在口袋或桌上时，拾音方向和距离都不固定，同一环境读数忽高忽低，参考价值大打折扣。

Buzz选择了独立硬件形态，放在书桌固定位置，拾音方向和距离保持稳定，就能形成一套可比较、可校准的“环境噪声感知基准”。它不需要你主动掏出手机，LED灯环从绿色到橙红逐步变化，配合蜂鸣器短鸣，余光扫一眼就知道当前状态。这种“存在于环境里但不抢注意力”的感觉，手机很难做到。整个项目成本控制在五十元以内，一颗18650电池能撑一两天，属于典型的低成本高收益DIY。

1.2 目标形态和功能边界

我最初希望Buzz能做三件事：实时显示分贝近似值；在环境声超过阈值时给出蜂鸣提醒；同时统计一天里被“吵到”的次数和时间段，方便我复盘是不是该换工位。

后来和几个朋友聊了一圈，决定把功能边界先收窄，做稳定再扩展。第一版只保留四件事：OLED屏显示当前噪声等级和阈值；电位器调节触发阈值，现场拧就能改灵敏度；LED灯环用颜色提示状态；蜂鸣器在触发后按“短鸣两下、停三秒”的节奏提醒，避免一直响到人烦躁。Wi-Fi上报和远程通知作为选做项，放在基础版本跑通之后再接入。这样做的好处是，核心逻辑足够小，排错时不会一团乱麻。

1.3 方案选型：为什么是麦克风加蜂鸣器，而不是其他传感器

有人可能会说，环境噪声用麦克风采集不是理所当然吗？其实市面上还有一类方案用“振动传感器”贴在桌面或墙壁上，检测物体敲击带来的振动，好处是功耗极低，坏处是只能感知接触式噪音，隔壁装修那种通过空气传播的低频轰隆声基本测不到。还有方案用摄像头做人数和行为识别来间接判断“会不会吵”，但涉及隐私和光线条件，运行成本也更高。

麦克风加蜂鸣器是综合成本、准确性和功耗之后最务实的组合。麦克风模块负责感知空气声压波动，蜂鸣器负责把结果变成人体最容易察觉的听觉信号。整条链路没有复杂算法，也没有昂贵的专用芯片，任何一个能把杜邦线插明白的人都能复现。而真正决定项目体验的细节在于：怎么从原始ADC值里算出一个稳定的“音量”，以及怎么设计提醒逻辑让它既及时又不讨人厌。

2. 核心技术点拆解：从声音到蜂鸣之间发生了什么

别以为拿个麦克风模块接上单片机，就能直接“读出噪声等级”。我从第一次通电到数据稳定，前后折腾了一整个周末。这里面至少要解决传感器增益、直流偏置、采样抖动、算法平滑和触发防抖五个问题。逐一拆开看，其实每个都不难，但串在一起容易让人摸不着头脑。

2.1 声音采集的魔法：驻极体麦克风与放大

大多数市售麦克风模块用的是驻极体电容式麦克风，内部有一层驻极体薄膜，声压推动薄膜振动，改变电容，再通过场效应管转换成电压信号。这个原始信号非常微弱，通常只有几毫伏到几十毫伏，没法直接被单片机ADC有效采样，所以模块板上都集成了一级放大电路。常见模块有MAX9814和MAX4466两种，它们的最大区别在自动增益控制AGC。

做语音录音时，AGC是神器，它能把远处的小声音放大、近处的大声音压缩，让录音响度均匀。但做噪声监测时，AGC反而会毁掉数据：楼道里突然传来脚步声，AGC会把增益压低，你会看到输出值不升反降，完全违背直觉。所以我推荐固定增益设计的MAX4466模块，或者把MAX9814的AGC引脚拉低关闭自动增益。通俗地说，我们要的是“原汁原味”的声学信号，不是经过加工修饰的音乐效果。

2.2 数字世界里的“音量”：RMS和滑动平均

麦克风模块输出的是一个随时间快速波动的模拟电压，ESP32的ADC以12位精度把它转换成0到4095的数值。直接看这个值没有任何意义，因为声音波形在不断上下振荡，我们需要一个统计量来代表“当前响不响”。最常用的是均方根RMS：先把每个采样点减去直流偏置，得到真正的交流分量，再求平方、取平均、开根号。RMS和声音能量成正比，从物理直觉上说，更接近人耳感受到的响度。

实际实现时还有一个很关键的点：ADC采样时机不可能做到古人计算机那样绝对均匀，如果只是简单粗暴地循环analogRead，会出现相位噪声，导致RMS值抖动。我习惯用固定时间间隔配合micros计时，或者直接用一个定时器中断驱动采样。每次计算完RMS后，再叠加一级指数滑动平均，公式是smoothed = 0.9×smoothed + 0.1×newRMS。这样即使有人偶尔咳嗽一声，整体读数也不会瞬间飙到天花板。

2.3 不吵到崩溃的阈值判定：迟滞状态机

最朴素的判断方式是：RMS大于阈值就报警，小于阈值就安静。但真实环境里的声音有随机波动，尤其在阈值临界点附近，系统会像抽风一样在响与不响之间反复横跳。解决思路借用了模拟电路里“施密特触发器”的迟滞原理：设置两个阈值，一个是较高的触发阈值HIGH，一个是较低的释放阈值LOW，只有信号超过HIGH才进入提醒状态，只有信号回落到LOW以下才恢复安静。

举个例子，触发阈值设成55分贝，释放阈值设成48分贝。当环境声刚超过55时触发；之后即使降到54、53，也不会立刻关闭；必须等它真正低于48，才算彻底安静下来。这段迟滞区间能吸收掉大部分临界抖动。此外我还加了一个“提醒冷却时间”：每次蜂鸣之后至少间隔3秒才能再次触发，防止短促的关门声、水滴声连续轰炸。这个状态机代码很简单，但体验提升极其明显。

2.4 最后一步：让人感知到的蜂鸣输出

触发后的表现方式也有讲究。有源蜂鸣器内部自带振荡电路，通电就会以固定频率发声，优点是代码简单，缺点是无法改变音调。无源蜂鸣器则需要外部提供一定频率的方波信号，通过PWM可以自由控制音调，比如用1600Hz发出比较清脆的“嘀嘀”声，用800Hz发出低沉的“嗡嗡”声，听起来更柔和。

我的建议是第一版用有源蜂鸣器先把链路跑通，因为少一根线、少一个变量。等核心逻辑稳定后，再换无源蜂鸣器，用PWM输出一段两拍的“嘀-嘀-安静”短旋律。蜂鸣器音量不能开满，否则吵的是自己。所以我会在代码里限制PWM占空比，还要在物理上把蜂鸣器背对使用者，或者用外壳开孔让它声音有方向性散开，而不是正对耳朵。

3. 动手前先搞定硬件：元器件清单与接线图

很多人做硬件项目失败，不是代码写不对，而是接线时埋了坑。Buzz的硬件并不复杂，核心就五六个模块，但主控选择、供电方式和驱动电路会在源头决定后面省不省心。

3.1 主控和传感器怎么选：ESP32还是Arduino

如果你打算把Buzz做成一个每天开机的家用设备，我强烈建议直接上ESP32 DevKit，而不是Arduino Uno。原因有三个：ESP32的ADC分辨率12位，比Uno的10位更细腻；它自带Wi-Fi和蓝牙，后续想远程推送通知不用换主控；最重要的是它工作时还能用轻度休眠模式，配合定时唤醒采样，功耗比Uno纯跑循环低很多。Uno的优势是入门资料多、接线容错率高，如果手里正好有现成开发板，先用它跑通逻辑也完全可以，后续再迁移到ESP32。

麦克风模块我推荐MAX4466，理由前面已经讲过：固定增益，行为可预测。电源注意给麦克风模块提供干净的3.3V，不要直接怼5V给输出端，因为它的输出信号会超过ESP32 ADC的3.3V量程，导致削波失真。选MAX4466时还要看清模块背面的电位器，那是调增益用的，出厂默认值往往偏高，新手常常一上电就发现满量程打底，不要慌，先逆时针微调让静音时读数回到中间偏下。

3.2 完整元器件清单

我把BOM列成表格，方便采购时对照。全部从常见模块商家那里买齐，总价大约四五十元，部分元件如果你以前玩过Arduino，大概率抽屉里已经有存货。

如果没有18650方案，直接用USB供电也行，测试学习阶段最省事，一个充电宝加一根短USB线就能跑起来。电池方案更适合做完外壳后长期摆在家里。

3.3 接线要点与常见坑位

接线建议从ESP32和麦克风开始，先不要一次把所有外设都插满，否则一旦出问题很难定位。麦克风模块的VCC接3.3V，GND接GND，OUT接ESP32的GPIO34。GPIO34在ESP32上属于ADC1通道，采样时不受Wi-Fi射频干扰，这是很关键的选择。如果手一抖接到了ADC2相关的GPIO，Wi-Fi连上后ADC数据可能全乱，我已经踩过这个坑。

OLED和灯环都走I2C或单总线，OLED的SCL接GPIO18、SDA接GPIO23，也可以换用其他空闲引脚；WS2812的DATA接GPIO15，供电接5V，注意灯环全亮时电流不小，至少需要1A供电。蜂鸣器不能直接挂在GPIO上就完事，有源蜂鸣器工作时电流约23mA，虽然ESP32引脚勉强能承受，但长期运行容易发热，正确做法是用一只NPN三极管，基极串1K电阻接GPIO，集电极接蜂鸣器负极，蜂鸣器正极接5V，同时反并联一个1N4007续流二极管吸收关断时的反向电动势。

4. 从零实现一个能用的Buzz：四步走

这一章是真正的“抄作业”时间。我在调试过程中踩过的所有坑，都会体现在代码注释和每一步的说明里。建议你跟着做，每完成一步就验证一步，不要等四步全写完再统一上电。

4.1 第一步：让麦克风说话（ADC采样调试）

先写一个最小测试程序，把麦克风采样的原始值放到串口绘图器里看。你会发现一串乱跳的数字，这是正常的，我们要找的是“静音时的基准值”和“拍手时的突刺”。

// 第一步：原始ADC采样测试 #define MIC_PIN 34 // ADC1通道，GPIO34 #define SAMPLES 512 #define INTERVAL_US 1000 // 每1ms采一次，约1kHz采样率 void setup() { Serial.begin(115200); analogReadResolution(12); // ESP32默认12位 analogSetAttenuation(ADC_6db); // 设置衰减，输入范围约0-2.5V } void loop() { uint32_t sum = 0; for (int i = 0; i < SAMPLES; i++) { sum += analogRead(MIC_PIN); delayMicroseconds(INTERVAL_US); } float avg = sum / (float)SAMPLES; Serial.print("ADC平均: "); Serial.println(avg); delay(500); }

如果静音时平均读数在1600到2200之间（对应大约1.0V到1.3V的直流偏置），说明接线和供电正常。如果读数一直顶着4095或掉到0，先查共地和模块供电，再微调MAX4466背后的增益电位器。这里有个经验：不要对着麦克风哈气测试，哈气会产生大量低频气流噪声，容易误导调试方向，用手掌在模块前方轻轻扇动才是模拟环境声的好办法。

4.2 第二步：把原始信号变成稳定的噪声等级

拿到原始ADC值后，下一步就是计算直流偏置和均方根RMS。直流偏置就是静音时那串读数的平均值，我习惯在setup阶段先采样1000次取平均，把它保存为全局变量dcOffset。实际采样时，每次读到电压值后先用它减去dcOffset，剩下的才是真正的交流声音信号。

// 第二步：RMS计算 + 滑动平均 #define MIC_PIN 34 #define TOTAL_SAMPLES 512 #define INTERVAL_US 1000 float dcOffset = 0; float smoothedLevel = 0; const float ALPHA = 0.1; // 滑动平均系数，越小越顺滑 float computeRMS() { float sumSq = 0; for (int i = 0; i < TOTAL_SAMPLES; i++) { float v = analogReadMilliVolts(MIC_PIN) / 1000.0; // 单位转换为伏特 float diff = v - dcOffset; sumSq += diff * diff; delayMicroseconds(INTERVAL_US); } return sqrt(sumSq / TOTAL_SAMPLES); } void setup() { Serial.begin(115200); analogReadResolution(12); // 静音环境计算直流偏置 float sum = 0; for (int i = 0; i < 1000; i++) { sum += analogReadMilliVolts(MIC_PIN) / 1000.0; delayMicroseconds(1000); } dcOffset = sum / 1000.0; } void loop() { float rms = computeRMS(); if (smoothedLevel == 0) smoothedLevel = rms; smoothedLevel = (1.0 - ALPHA) * smoothedLevel + ALPHA * rms; // 串口输出rms和smoothedLevel，观察哪一个更接近人耳感受 Serial.print("RMS:"); Serial.print(rms, 4); Serial.print(" Smooth:"); Serial.println(smoothedLevel, 4); delay(100); }

在Serial Plotter里你应该能看到，smoothedLevel曲线的毛刺明显比raw RMS少很多。如果RMS值只有小数点后两位那么小，不要在意绝对大小，它只是一个相对量。后续我们要把这个相对量映射成一个“伪分贝值”显示在OLED上。

4.3 第三步：蜂鸣提醒与状态切换

有了平滑后的噪声等级，就可以写迟滞状态机了。我用一个名为alertState的变量表示当前状态，HIGH_THR和LOW_THR两个阈值则来自电位器读数和校准偏移。电位器读取ADC后映射到一个合理的“伪分贝”区间，比如30到70。

// 第三步：阈值判定、蜂鸣提醒和LED灯环联动 #define BUZZER_PIN 13 #define LED_PIN 15 #define POT_PIN 35 float HIGH_THR, LOW_THR; bool alertActive = false; unsigned long lastBeep = 0; const unsigned long BEEP_INTERVAL = 3000; // 冷却3秒 const float HYSTERESIS = 5; // 迟滞区间 float readThreshold() { int potVal = analogReadMilliVolts(POT_PIN); // 单位mV float thr = map(potVal, 0, 3300, 30, 70); // 映射到伪分贝 HIGH_THR = thr; LOW_THR = thr - HYSTERESIS; return thr; } void ringBuzzerPattern() { if (millis() - lastBeep < BEEP_INTERVAL) return; lastBeep = millis(); for (int i = 0; i < 2; i++) { digitalWrite(BUZZER_PIN, HIGH); delay(80); digitalWrite(BUZZER_PIN, LOW); delay(120); } } void updateLED(float level) { // WS2812控制见对应库，这里简化为逻辑描述 // 触发时红色，接近阈值时黄色，安静时绿色 } void loop() { // 继续调用computeRMS得到smoothedLevel float level = smoothedLevel; float thr = readThreshold(); if (!alertActive && level > HIGH_THR) { alertActive = true; } else if (alertActive && level < LOW_THR) { alertActive = false; } digitalWrite(BUZZER_PIN, LOW); // 默认低电平 if (alertActive) ringBuzzerPattern(); // 提醒时按冷却节奏驱动蜂鸣 updateLED(level); delay(100); }

这段代码里最重要的部分是蜂鸣器驱动逻辑。我刻意没有用“alertActive为真就持续响”，而是用循环加延时的方式模拟一短一长两拍，并在每次触发后设置3秒冷却。连续打键盘超过阈值是常见场景，如果没有冷却，Buzz就会变成一台完全停不下来的闹钟，用不了半天就会被扔进抽屉。

4.4 第四步：可选升级——Wi-Fi上报与自动化提醒

基础版本跑通后，可以考虑把噪声数据接入家庭自动化系统。ESP32连上Wi-Fi后，以固定时间间隔把最近一分钟的平均噪声等级和是否触发提醒上报到局域网内的HTTP端点，或者直接通过MQTT推给Home Assistant。一名合格从业者在这种场景下最常用的做法是：本地自建一个简单的Web服务，接收GET请求并把数据写入InfluxDB，再由Grafana画成曲线。

// 第四步（可选）：HTTP上报示例 #include <WiFi.h> #include <HTTPClient.h> const char* ssid = "你的WiFi名"; const char* password = "你的密码"; const char* endpoint = "http://192.168.1.20:8080/record"; WiFiClient client; void reportNoise(float level, bool triggered) { HTTPClient http; String url = endpoint; url += "?level=" + String(level, 3); url += "&triggered=" + String(triggered ? 1 : 0); http.begin(client, url); int code = http.GET(); // 状态码200说明服务端收到了 http.end(); }

有一点必须提醒：Wi-Fi连接会引入射频干扰，所以麦克风一定要接在ADC1通道（GPIO32-39），采样循环和Wi-Fi收发尽量分时进行。比如每10秒上报一次，其余时间保持Wi-Fi休眠。实测下来，Wi-Fi开启后噪声底噪会略微抬升，但不会离谱，如果你发现读数整体涨了0.5分贝以上，可以先查天线是否紧贴着麦克风模块。

5. 参数校准和日常使用心得

很多人把硬件跑通就算完工，但真正让Buzz好用的恰恰是校准。同一个硬件，放在图书馆和放在地铁站旁边完全是两个世界，盲目套用别人的阈值，结果只会是放着吃灰。

5.1 如何用一个手机App完成最简校准

我不建议你立刻花钱买专业声压计，先用手机上一款称手的噪音分贝App即可。校准过程中手机和Buzz放在同一个位置、同一个高度，保持麦克风朝向一致。播放一段稳定的白噪声，或者干脆让环境音自然存在，同时观察手机App显示值和Buzz在OLED上显示值，然后调整代码里的一个校准偏移常量。

// OLED上显示伪分贝：RMS映射到“可读数字” dbDisplay = 20 * log10(smoothedLevel + 0.0001) + CAL_OFFSET;

先把CAL_OFFSET设成0，记录下来Buzz显示数和手机显示数之间的差值，比如手机显示52dB时Buzz显示35，那么CAL_OFFSET就填17。再验证几个不同噪声水平的场景，如果差值基本恒定，说明校准成功；如果差值忽大忽小，多半是MAX4466增益电位器被AGC选项搞乱了，或者音量计算里没有正确扣除直流偏置。

5.2 我常用的几组场景阈值

从实际体验看，不同场景的阈值设定有明显的差别。具体数值会因你的麦克风增益和外壳开口不同而漂移，但方向可以参考：

我在代码里专门加了一个“学习模式”：连续两小时统计最大噪声值和75百分位噪声值，在OLED上显示这两组数据，而不是只显示瞬时噪声。很多用户抱怨阈值不好调，是因为他们看到的只是某一个瞬时的跳变值，完全不了解自己所在环境的噪声分布。用一晚数据作为依据去设置阈值，比瞎拧电位器科学得多。

5.3 功耗、续航和摆放位置

如果只用USB供电，功耗问题可以忽略，因为插座永远在那。但如果做成电池版，就要认真对待功耗。实测ESP32打开Wi-Fi跑正常循环时电流在80到130mA之间，关掉Wi-Fi但维持每100毫秒一次采样时大约30mA，加上蜂鸣器和OLED刷新平均到40mA。用一颗2000mAh的18650电池，续航大约40到50小时，两天一充基本可以接受。想进一步压低功耗，可以试着只让OLED每5秒刷新一次，平时进入light sleep，用定时器唤醒采样。

摆放位置比想象的更重要。不要把Buzz放在音箱旁边，否则它会被自己的播放声触发；也不要紧贴墙角，墙角会放大低频噪声导致读数偏高。正确的位置是桌面上离人约30到60厘米，麦克风开孔朝向房间中部，背面靠墙。经过一周观察，我发现读数稳定性提升远比换一个更高精度麦克风来得明显。

6. 常见问题与排错实录

如果只看前面的章节，你可能觉得链路很简单。但真实调试时，下面这几个问题我几乎全都遇到过，每个都能卡住半小时以上。把它们整理出来，希望能帮你少走弯路。

6.1 读数乱跳，根本没法用

最常见原因是供电不稳。ESP32瞬间拉电流较大，如果用面包板飞线给麦克风供电，麦克风会拾取电源纹波，导致静音时RMS不为零。处理办法是在麦克风模块的VCC和GND之间并一个100uF电解电容和0.1uF瓷片电容，或者干脆通过AMS1117稳压后再给传感器供电。另一个原因是采样间隔抖动，前面提过用delayMicroseconds并不能做到精确定时，建议改用定时器中断，至少确保每次采样的时间间隔误差小于20%。

如果两种方法都试过还是跳，就要检查是否有Wi-Fi天线靠近麦克风。ESP32的射频信号会在天线附近产生电磁干扰，被高增益麦克风拾取。物理上将麦克风放到远离天线的一侧，或者把Wi-Fi的发送时间压缩到每次上报前瞬间，问题就会有明显改善。

6.2 蜂鸣器不响、音调奇怪或音量太小

蜂鸣器不响，先检查是电源问题还是驱动问题。有源蜂鸣器接5V正极再接GND，正负极接反不会响。如果用的是三极管驱动，极有可能是基极电阻选太大导致基极电流不足，S8050的放大倍数很高，1K电阻加3.3V驱动完全够用，换成10K就可能会响得有气无力。无源蜂鸣器则必须给PWM波，直接digitalWrite高电平只会有“咔哒”一声，至少要调用analogWrite或者ledcSetup配置频率。

音量太小还有一个隐蔽原因：蜂鸣器被放在密封外壳里，腔体共振反而把声压抵消了。解决方法不是调大音量，而是在外壳对应位置开若干个3到5毫米的通气孔，让声音能“漏”出来。如果你想进一步控制方向性，可以给蜂鸣器套一个朝后的圆柱形导音管，让提醒声只传向墙面反射区，而不是正对耳朵。

6.3 OLED花屏、Wi-Fi掉线、上传失败

OLED花屏最常见是总线地址定义错误，SSD1306模块通常为0x3C，也有少数是0x3D。另一个原因是I2C上拉电阻缺失，可以开启ESP32内部上拉，或者在SDA和SCL上各接一个4.7K电阻到3.3V。Wi-Fi掉线和下载失败大多是电源问题：USB线太长、用了劣质数据线、板上稳压模块过热都会导致电压跌落。遇到ESP32上传失败时，按住BOOT键再插入USB，如果串口信息停留在“等待下载模式”，多半是EN引脚上的复位电容没有正确放电，试着在EN和GND之间加一个10uF电容。

6.4 阈值旋钮不好使、转速飞快也不线性

电位器读取值本身是线性的，但人的听觉对分贝并非线性，所以把电位器ADC值直接映射到“分贝”会让低端非常灵敏、高端非常迟钝。处理办法有两种：一是把映射关系改成指数型，先让电位器输出0到1，再映射为30 + potValue×potValue×40，这样低阻值区域对应操作空间更大。二是在电位器中心抽头对地加一个0.1uF电容，滤掉机械触点抖动，同时在代码里只每100ms读一次电位器并做滑动平均，手感会顺滑很多。

6.5 一点不成熟的调试哲学

所有阈值问题本质上是“你有多愿意被打扰”的判断题。我把Buzz开放给同事用过几天，有人把阈值调到60分贝以上，理由是键盘声不值得被提醒；有人调到40分贝以下，连空调风扇的呼呼声都触发。这说明Buzz真正的价值不是替你定义一个绝对标准，而是强迫你思考：在什么样的声音环境下，自己才最有产出？这台设备的意义是帮你量化环境干扰，让你有依据去换座位、戴耳机或者和室友沟通。一首歌里凡是把Buzz调成了一个好听的阈值，我都会觉得这个项目才算真正完成了闭环。