离线唤醒词：让硬件"听到名字才醒"
- 说清楚唤醒词为什么必须在本地离线做，而不是上云
- 理解本地唤醒模型在判断什么、和完整语音识别有什么区别
- 知道 ESP32 上用乐鑫 ESP-SR / WakeNet 做唤醒的大致思路
- 分清 VAD（语音活动检测）和唤醒词检测各管什么
你对着桌上那颗板子喊一声"小智"，它停了半秒，亮起灯，然后才开始听你接下来要说什么。这个"听到名字才醒"的动作，看着简单，却是整条 AI 硬件链路里唯一一个必须留在本地、不能交给云的环节。
为什么唯独这一步不能上云？因为唤醒意味着"耳朵一直开着"。如果把麦克风收到的每一帧声音都往服务器送、让云端去判断你有没有喊它，那等于你家这颗板子全天候在直播你客厅里的一切声音——又费流量、又是隐私灾难、还得一直占着网络。所以正确的做法是：让板子自己在本地判断"刚才那声有没有在叫我"，只有判断为"是"，才真正开始录音、上传、走后面的识别流程。
这一节讲清楚这个本地判断是怎么做的：它在判断什么、为什么能在 ESP32 这种小芯片上实时跑、乐鑫官方的方案大概长什么样，以及你想换个唤醒词的门槛在哪。读这篇前，你得先搞定板子怎么把麦克风的声音读进来——还没弄的，先看麦克风与 I2S 音频采集，那是这一切的输入端。
一个真正能用的离线唤醒，是一整套工程：麦克风采集、音频预处理、唤醒模型、之后接上录音与上传。本节只讲原理和思路，具体到能跑的代码、模型文件、参数调优，以乐鑫官方 ESP-SR 文档和小智项目里的实际实现为准。我不会编一段"复制就能唤醒"的代码骗你——离线语音没那么简单。
唤醒词在判断什么：一个极小的"只认一个词"的模型
先纠正一个常见的误解：唤醒不等于语音识别。 很多人以为板子得先听懂你说的整句话，才知道你有没有叫它——不是这样的。
完整的语音识别（ASR）是把任意一段语音转成文字，词汇量是整门语言，模型大、算力重，ESP32 本地根本扛不住，所以才要上云调大模型那一套。而唤醒做的事窄得多：它只需要回答一个是非题——"刚才这段声音里，有没有出现我被设定的那个特定词"。
不需要知道你说的别的话是什么，不需要转成文字，只判断"有/没有这个词"。因为目标这么窄，它可以用一个极小的模型来做：
- 模型只学了"那一个唤醒词长什么样"的声学特征，参数量很小，能塞进 ESP32 有限的内存和算力里。
- 它持续地、一小段一小段地"看"麦克风进来的声音，每一段都给一个判断：像不像那个词。
- 一旦某一段的"像"超过阈值，就触发唤醒——醒了，把后面的活儿交给录音和上云。
打个比方：语音识别像一个能听写整篇文章的速记员，又贵又累；而唤醒词检测像一只趴在门口、只对"自己名字"竖耳朵的猫——别的声音它一概不理会，专门只等那一个词。让一只猫趴着，比养一个速记员驻场便宜太多了，这正是唤醒能在小芯片上常驻的原因。
在 ESP32 上怎么实现：乐鑫的 ESP-SR / WakeNet 思路
你不需要自己从零训练一个唤醒模型——那是另一个领域的活。在 ESP32 这条线上，乐鑫（Espressif，做 ESP32 芯片的厂商）官方提供了一套离线语音方案 ESP-SR，里面专门负责唤醒词检测的部分叫 WakeNet。
概念上，它在板子里大致是这样一条流水线：
麦克风(I2S) ──→ 音频前端(降噪/增益) ──→ WakeNet(唤醒判断) ──→ 醒了?
│
否 ← 回去继续听
是 → 开始录音 / 上云
几个要点你先有个概念就够，细节以官方为准：
- 它是离线的：WakeNet 的判断完全在芯片本地完成，不联网、不上云，这正是它能保护隐私的根本。
- 它配套一个音频前端：唤醒之前通常还有一层信号处理（比如降噪、回声消除、增益控制），帮模型在嘈杂环境里更准地"听清"那个词。
- 它对芯片有要求：这类带 AI 加速的语音方案，通常更适合算力和内存更宽裕的型号（比如 ESP32-S3 这种带向量指令的芯片），老款的普通 ESP32 跑起来会吃力。具体哪些芯片支持到什么程度，以乐鑫官方文档为准，别凭印象拍板。
小智这类开源 AI 硬件项目，本地唤醒走的正是这条路：用乐鑫的离线方案在板子上常驻一个唤醒词，听到了才接通后面的云端对话。所以你看到小智"喊一声才醒"，背后就是 WakeNet 在干活。
别一上来就纠结模型参数和训练。先把目标拆成两段：第一段，让板子能稳定地把麦克风的声音读进来（这是 I2S 那一节的事）；第二段，把乐鑫官方示例里的唤醒例子原样跑通，先听到它对默认唤醒词有反应。两段都通了，再谈换词和调参——一次只验证一件事，出问题才知道是谁的锅。
自定义唤醒词：门槛在哪
很多人第一个想法就是"我要把唤醒词从'小智'换成我自己起的名字"。这件事能做，但不像改一个字符串那么轻松，你得先知道门槛在哪，免得抱着错的预期。
唤醒模型是"针对某个特定词训练出来的"——它认识的是那个词的声音特征，不是一段你随手改的文本。所以换唤醒词，本质上是要有一个"认识新词"的模型：
- 用官方现成的唤醒词最省事：乐鑫提供了一批已经训练好的唤醒词，直接选用，这是门槛最低的路，适合入门先跑通。
- 要全新的自定义词，通常得走"定制训练"：把你想要的词，通过厂商提供的定制流程去生成一个对应的唤醒模型。这一步涉及数据和训练，不是在你本地随手就能完成的，具体怎么申请、什么形式，以乐鑫官方的定制唤醒词流程为准。
所以现实建议是：入门阶段先用官方词把整条链路跑顺，等你真要做产品、需要专属唤醒词时，再去走定制流程。别让"换个名字"卡住你理解整套系统的进度。
VAD 是什么：它和唤醒不是一回事
学唤醒，你很快会撞见另一个缩写 VAD（Voice Activity Detection，语音活动检测）。新手容易把它和唤醒混为一谈，其实它俩管的是完全不同的两件事，配合起来用。
- VAD 只判断"现在有没有人在说话"：它不关心说的是什么词、是不是叫你，只回答"这段声音是人声，还是只是环境噪声/静音"。
- 唤醒词检测判断"说的是不是那个特定词"：它更挑剔，专门只认你设定的那个唤醒词。
它俩在一条链路里各司其职。典型配合是这样：
| 环节 | 谁负责 | 在判断什么 |
|---|---|---|
| 一直开着的耳朵 | 唤醒词检测 | 有没有人喊"小智" |
| 醒来后开始录音 | VAD | 你这句话说完了没（开始有声→说话→停下来静音） |
也就是说：唤醒负责"什么时候开始听"，VAD 负责"你这句话什么时候说完、该停止录音上传了"。 没有 VAD，板子不知道你哪句话讲完了，要么把你后面的沉默也录进去浪费流量，要么切得太早把你话切断。两者搭起来，才有一次干净的"喊它→它醒→你说→它知道你说完了→上云"的完整体验。
避坑：唤醒最常见的三类翻车
第一次玩离线唤醒，卡住几乎是必然。问题基本逃不出这三类，照着对号入座。
一、误唤醒（没叫它，它自己醒了）。 电视里有人说了个谐音、环境里一段噪声碰巧像那个词，板子就醒了。这通常是触发阈值设得太松，或者唤醒词本身太短太常见（越短、越接近日常词，越容易误触）。方向是：适当收紧阈值、选一个不那么"路边随处可闻"的唤醒词。
二、唤醒不灵（叫了半天没反应）。 反过来，阈值太严、或者你离麦克风太远、说得太轻，模型够不着那个"像"的门槛。也可能是音频前端没配好，声音进来就已经又糊又小。先确认麦克风采集那一环的音量和采样是正常的，再回头调唤醒。
三、环境噪声把它搞晕。 安静房间里好好的，一开电视/空调/放音乐就要么不醒要么乱醒。这恰恰是前面说的"音频前端"（降噪、回声消除）存在的意义——离线唤醒在真实嘈杂环境里好不好用，很大程度取决于这层预处理，而不只是唤醒模型本身。
新手最容易踩的坑：拿一款算力不够的老 ESP32 去硬跑带 AI 加速的离线唤醒，然后怪"方案不行"。 这类语音方案对芯片型号和内存是有门槛的——板子选错，再怎么调参也跑不顺，表现可能是卡顿、频繁重启、或干脆加载不起来。动手前先按乐鑫官方文档确认你这块板子在不在支持范围内，别用错硬件去试对方案。
动手挑战
别只看，在小智的基础上动手改一处：
- 先原样跑通默认唤醒：把小智（或乐鑫官方唤醒例子）烧进板子，确认你喊默认唤醒词时它能稳定醒来。这一步是地基，没跑通别往下走。
- 再换一个官方唤醒词：在它支持的现成唤醒词里换一个，重新烧录，验证新词能唤醒、旧词不再响应。先体会"换词"这件事到底改了什么，再去想自定义训练那条更深的路。
卡住了？把你的板子型号、用的方案、还有串口里的报错一起发给 AI，让它帮你对一下是硬件不支持还是参数没配对。
小结 · 你现在掌握了什么
- 你说得清唤醒词为什么必须离线在本地做：耳朵一直开着，不能把声音一直往云上送，那既费流量又毁隐私。
- 你理解了本地唤醒模型在判断什么：不做完整识别，只回答"有没有那个特定词"这一个是非题，所以才能塞进小芯片常驻。
- 你知道了 ESP32 上走乐鑫 ESP-SR / WakeNet 这套离线方案，以及它对芯片型号有门槛、要以官方文档为准。
- 你分清了 VAD 和唤醒：唤醒管"什么时候开始听"，VAD 管"你这句话什么时候说完"，两者配合才有干净的体验。
唤醒是整条 AI 硬件语音链路的第一道闸门——它本地、它省着干、它只认一个词。看懂了它，你就知道一台语音硬件的"耳朵"和"大脑"是怎么分工的：耳朵留在本地，大脑放在云端。
下一步：唤醒之后，板子要把你这句话录下来、转成文字、再把模型的回复念出来——这就是语音识别与语音合成（ASR / TTS）要解决的，整条对话链路的两头。把这一节和硬件调用大模型串起来，你就拼齐了一台会听会说的硬件的全貌。想看工业级的完整实现，去实战项目逐行拆小智；想看这一级还有哪些坑，回L4 总览或学习路线图找你的下一站。