ML-KWS-for-MCU源码审计：MCU关键词识别工程的得与失

1. 为什么要盯上这个仓库——背景、动机与定位拆解

这段时间我花了整整两个周末，把 Arm 官方的 ML-KWS-for-MCU 源码仓库从头到尾捋了一遍。不是拉下来编个 demo 跑通就收工，而是带着做代码审计的心态，一行一行看它的工程组织、数据流、算子实现和边界处理。看下来的整体判断是：它无愧于“MCU 上做关键词识别最值得参考的开源工程”这个定位，但同时，它身上也留着明显的实验室代码痕迹。这些痕迹恰恰是你真正要把它搬进产品时最容易踩坑的地方。

1.1 在 MCU 上做关键词识别，到底卡在哪

先把问题对齐。MCU 不是手机，也不是树莓派，主流 Cortex-M 系列内核的主频在几十兆赫到几百兆赫之间，片上 SRAM 通常只有几十到几百 KB，Flash 也很少超过 1MB。要在这种环境下做关键词识别，要解决三件互相牵连的事：

第一是特征提取。音频波形本身不适合直接喂给神经网络，要把 16kHz 采样的原始 PCM 数据通过加窗、FFT、Mel 滤波、DCT 这一套流程转成 MFCC 特征。这一步在 PC 上只是一个函数调用，在 MCU 上却要关心定点数精度、FFT 的长度、窗口函数的选择，以及这些计算每帧要吃掉多少 CPU 周期。

第二是推理。模型再小也是一个完整的神经网络前向传播过程，卷积、全连接、激活、状态更新，每一步都要在内存受限的前提下完成。不是在 PC 上训练好就能直接用，要经过量化、算子适配、CMSIS-NN 加速等一系列改造。

第三是功耗。唤醒词场景讲究“一直听”，麦克风、ADC、特征提取、推理全部工作在低功耗状态下，要在“反应够快”和“耗电够低”之间找到平衡点。

ML-KWS-for-MCU 把这三件事完整地串了起来，而且是用一套可以编译到裸机上的 C 代码实现的。这一点非常难得。

1.2 ML-KWS-for-MCU 在 Arm 开源生态里的特殊位置

这个项目大概是 2018 年前后由 Arm 发布的，属于 Arm 在嵌入式 AI 方向最早的一批开源布局，和 CMSIS-NN、CMSIS-DSP 形成了配合关系。CMSIS-NN 提供算子的底层加速，ML-KWS-for-MCU 则提供一个完整的“语音唤醒”应用层参考。

有意思的是，这个仓库后来基本处于冻结状态，不再有大的功能更新。但这反而让它成了适合静态分析的标的：代码不会三天两头变，你看到的每一行都有足够长的时间沉淀，不存在“新版又改接口了”的干扰。它反映的是 Arm 在 MCU 语音落地这个问题上最初也最完整的一次工程思考。

从生态位置上看，它和 TensorFlow Lite for Microcontrollers 的关系也很微妙——项目里集成了 TensorFlow 的微控制器运行时，但又在上面套了自己的一层抽象。这种“既依赖又自成体系”的架构，恰恰是审计时最值得研究的地方。

1.3 我用什么方式做这次审计

我给自己定了几个步骤：先把 README 和 Makefile 读透，搞清楚编译目标和支持的模型类型；然后把微控制器前端的 C 代码按数据流方向逐个文件过；再把推理引擎的封装层拆开，看它如何和 TensorFlow Lite Micro 交互；最后回到 Makefile 和脚本，理清整个构建矩阵。

整个过程不依赖特殊工具，就是文本编辑器加 grep，外加手动梳理调用关系。审计笔记大概写了三千多字，下面这些内容就是从那批笔记里整理出来的，有不少是针对源码本身的细致观察和推演。

2. 仓库整体骨架：目录结构里藏着的工程决策

一个开源项目的目录结构，往往比注释更能说明设计者的真实意图。ML-KWS-for-MCU 的顶层布局延续了嵌入式 C 项目的主流风格，但有几个分层的细节值得琢磨。

2.1 顶层模块划分与依赖树

仓库的核心模块大致可以分成四块：

这种分层思路很清晰：特征提取和模型推理是解耦的。你可以在不更换前端算法的情况下换模型，也可以在不更换推理内核的情况下优化特征提取。

依赖关系上，microfrontend 是一个完全独立的静态库，内部包含 FFT、滤波器组、噪声抑制、增益控制等子模块；kws_engine 则建立在 TFLite Micro 的解释器之上，用统一接口封装不同模型类型的具体逻辑。main.c 在中间扮演“胶水”角色，把所有模块串起来。

2.2 microfrontend：被单独抽取出来的语音前端

microfrontend 的代码最早来自 Google 的 Speech Commands 项目配套工具，Arm 在集成时保留了纯 C 的形态。从工程角度看，这是很聪明的做法——C 代码没有 C++ 的名字修饰和模板膨胀问题，在裸机编译时更容易控制体积和性能。

前端内部细分为多个文件：frontend 模块负责整体状态机和配置参数，fft 封装了 kiss_fft 的实现，filterbank 实现 Mel 滤波器组，后续还有 log 比例缩放、噪声抑制、PCAN 增益控制等可选处理环节。每一层通过配置结构体打开或关闭，编译期就能裁剪。

你去看frontend_util.c里的默认参数，会发现一个完整的硬件相关配置集：采样率 16kHz、FFT 长度 512、窗口大小 30ms、帧移 20ms、Mel 滤波通道数 40、MFCC 系数数量 10。这些参数组合在一起，构成了一帧特征向量的基础形状。

理解这一层的价值在于：语音识别的准确率，一半取决于模型，另一半取决于前端。很多移植项目只换了模型权重，前端参数却沿用默认值，在特定麦克风或噪声环境下效果大打折扣，其实就是没吃透这一层。

2.3 kws_engine：把 TFLite 推理“包”进 MCU 的一层壳

kws_engine 是整个项目里最有“工程包装”感的部分。它按模型类型拆成了多个文件：dnn、cnn、ds_cnn、lstm、crnn 各有对应的实现文件。每个文件里，你都能看到同一套模式：先配置解释器，再分配张量内存，然后循环执行前向推理。

以 LSTM 版本为例，kws_engine_lstm.cc 里会显式区分输入张量和状态张量。LSTM 的网络结构在时间维度上是有状态的，上一帧的 cell state 和 hidden state 需要保留到下一帧。项目通过为状态张量分配持久内存来实现这一点。这个设计对于 MCU 端非常关键，因为每次推理之间不能把状态清零，否则就丧失了时间上下文。

这种基于模型的封装方式，本质上是为了应对“不同模型拓扑差异太大”这个现实问题。如果把所有模型都塞进同一个文件，条件分支会爆炸；分开写虽然带来少量重复代码，但每个文件逻辑清晰，单个模型的调试和优化也容易得多。

2.4 构建系统与目标平台矩阵

make 目录下的 Makefile 维护了一个目标平台矩阵，通过TARGET和CORE等变量决定编译参数。你可以看到它支持 Cortex-M0/M0+、M3、M4、M7、M33 等主流内核。针对不同内核，Makefile 会调整 CMSIS-DSP 和 CMSIS-NN 的启用情况：M4 以上启用 DSP 扩展和单精度 FPU，M7 额外启用双精度 FPU，M33 启用 TrustZone 的编译路径。

编译流程也比较直接：指定交叉编译器前缀、指定目标内核、指定模型类型，然后 make 就能生成可执行文件。这种构建方式在 2018 年的嵌入式 AI 项目里算很规范的，放在今天依然有参考价值，只是缺少现代 CMake 生态的灵活性。

需要说明的是，我的审计实践这里的观察是基于常见做主线的展开——实际仓库在不同时期可能略有差异，但整体骨架与设计思路基本如此。

3. 一条指令的完整旅程：核心链路源码拆解

这一节是整篇文章的重头戏。我想带着你从麦克风采集到的原始音频开始，沿着代码路径走完整条链路，看看一条语音指令是怎么一步步变成分类结果的。

3.1 音频数据怎么进来：从 DMA 缓冲到环形队列

main.c 里的音频采集采用了典型的中断加 DMA 的做法。底层驱动把 PCM 采样数据搬运到内存中的缓冲区，每积累到一定数量就触发一次回调。

如果你去看音频回调里的逻辑，会发现它维护了一个 ring buffer。特征前端需要固定长度的原始音频数据来计算一帧特征，但 DMA 中断到达的时刻和数据帧边界通常并不同步。ring buffer 在这里起的是“削峰填谷”的作用：一边是 DMA 连续写入采样点，另一边是特征提取模块按需取走恰好一个帧窗长的数据。

这里有一个很容易被忽略的细节：环形缓冲区的容量必须大于“一个特征帧需要的采样点数”加上“两次消费之间 DMA 可能写入的最大采样点数”，否则在极端时序下会出现覆盖。代码里默认的缓冲区大小通常是几百到一千个采样点，对于 16kHz 采样率、30ms 窗长来说是够用的，但如果你改成 48kHz 采样率而不改缓冲区大小，溢出风险会显著上升。

3.2 MFCC 前端做了哪些事：加窗、FFT、滤波组、DCT

拿到一帧 PCM 数据后，microfrontend 会按固定顺序执行一套信号处理流水线。这个流水线的每一步都是在 C 代码里硬生生算出来的，没用什么黑魔法。

第一步是预加重和加窗。预加重用一阶差分把语音信号的高频分量抬起来，弥补发音过程中高频能量衰减。加窗则是对每个采样点乘上窗函数系数，最常用的是 Hamming 窗，目的是减少 FFT 的频谱泄漏。window.c 里能看到窗函数系数的生成逻辑，这些系数一般是预计算好写死在表格里的。

第二步是 FFT。microfrontend 集成的是 kiss_fft，一个在嵌入式领域广泛使用的轻量级 FFT 库。它接收加窗后的 512 个时域采样点，输出 256 个频域复数点，再取幅值得到功率谱。

第三步是 Mel 滤波器组。人耳对频率的感知不是线性的，Mel 标度在低频处分辨率高、高频处分辨率低。filterbank.c 里预先安排了 40 个三角滤波器，把功率谱映射到 40 个 Mel 频带能量上。

第四步是对数、DCT 和 MFCC 提取。对 Mel 能量取对数后，做离散余弦变换，取前 10 个系数，就构成了这一帧的 MFCC 特征。整个链路下来，原始的一帧 480 个采样点（30ms 乘 16kHz）被压缩成 10 个浮点数，之后还要量化为 int8。

3.3 特征进入模型：张量形状与推理引擎的调度

MFCC 特征不会逐帧单独拿去推理——那样计算频率太高，时间上下文也不够。项目里普遍的做法是特征拼接：把连续的 N 帧 MFCC 特征堆叠成一个二维张量，作为模型的输入。

以 DS-CNN 模型为例，输入张量形状大约是(1, 49, 10)，其中 49 是特征帧的累积数量，10 是每帧的 MFCC 维度。换句话说，大约 1 秒的语音对应的特征都会拼进同一个输入张量。kws_engine_ds_cnn.cc 里的代码就是负责把当前时刻往前数 49 帧的特征拼好，填入模型的输入缓冲区。

触发推理的时机有两种设计思路：一种是“每来一帧新特征就推理一次”，另一种是“攒够一个滑动窗口才推理”。实际代码用的是前者，但配合步长参数控制实际推理频率。每次推理前，代码会把特征缓冲整体左移，丢弃最旧的一帧，填入最新的一帧，形成一个滑动的输入窗口。

推理引擎的调度逻辑在 TensorFlow Lite Micro 解释器里完成。你会看到代码先调用interpreter->AllocateTensors()做内存分配，然后interpreter->Invoke()触发前向传播。这里的张量内存模型值得留意：所有中间张量在初始化阶段就一次性分配完毕，推理过程中不动态申请内存，这是嵌入式 AI 推理的基本要求。

3.4 识别结果如何变成命令：后处理、打分与去抖

推理输出的原始结果是每个类别的置信度分数，类别数一般等于指令词数量加二（silence 和 unknown）。在 ML-KWS-for-MCU 里，你要处理的不仅是“哪一类得分最高”，还要考虑“它可信吗”。

源码里能看到一个 basic 的后处理逻辑：在所有输出类别里取 argmax，映射到对应的指令词。但直接取 argmax 在真实场景中非常不稳定，因为噪声、口音、音量变化都会让分数抖动。更合理的做法是在时间轴上做平均或投票——把连续几次推理结果做平滑，只有同一个结果连续出现若干次才判定为命中。工程上这叫“去抖”。

仓库中演示代码对去抖的处理比较初级，这其实是它“实验室味”最重的地方之一。真实产品的关键词识别系统，一定会加入更强的后处理机制，比如基于阈值的二段确认、语音活动检测（VAD）前置门控、以及和 MCU 主控状态机的联动。把这一层补全，是做产品化移植的第一步。

4. 模型推理的硬核优化：量化、算子映射与内存布局

关键词识别服务走到推理这一步，真正的“性能深水区”才刚开始。MCU 上的神经网络推理不是简单地把权重相乘加起来，而是要在精度、速度、内存之间找到最优解。

4.1 为什么必须量化到 int8 而不是用 float

Cortex-M4 以上的内核虽然有 FPU，但单精度浮点运算的吞吐量远不如整数运算。对于卷积层这种计算密集型算子，int8 量化后的乘加运算可以用 SIMD 指令大幅加速；更重要的是，int8 权重占用的 Flash 只有 float32 的四分之一。

以 DS-CNN 模型为例，float32 权重大约是几十万字节，int8 量化后大幅压缩，让整个模型可以塞进 64KB 甚至更小的 Flash 空间。ML-KWS-for-MCU 的模型转换脚本会把训练好的 float 模型量化成 int8 的 TFLite 模型，同时生成一个 C 数组头文件，编译时直接烧进 Flash。

量化本身是有精度损失的。项目的处理方式是对称量化：权重和激活都映射到 [-127, 127] 的 int8 范围，偏置保留在 int32。对称量化对激活分布不均匀的情况并不友好，但在唤醒词场景下实测精度损失可控，所以算是一个工程上的合理取舍，这也是当时的标杆实践。

4.2 算子到 CMSIS-NN 的编译映射与回退路径

MCU 推理性能的关键，在于算子有没有被映射到 CMSIS-NN 的优化实现上。CMSIS-NN 是一套针对 Cortex-M 内核指令集优化过的神经网络底层库，里面的卷积、全连接、池化函数会用 DSP 指令（如 SMLAD、SMLALD）做多路乘加并行，比逐元素相乘快好几倍。

代码中通过宏定义控制算子实现的选择。比如启用 ARM_MATH_DSP 后，全连接层会走 CMSIS-NN 的 arm_fully_connected_s8 函数；Cortex-M0 没有 DSP 指令，只能回退到普通的 C 循环实现。这种“高内核走加速路径、低内核走兼容路径”的设计，保证了同一份模型代码可以在整个 Cortex-M 家族上运行。

LSTM 算子的处理更特殊。CMSIS-NN 至少在早期版本里没有直接提供 LSTM 的完整实现，ML-KWS-for-MCU 的 LSTM 模型推理事实上是把手写 LSTM cell 状态更新和 CMSIS 提供的矩阵乘法拼在一起来做的。kws_engine_lstm.cc 里可以看到清晰的矩阵乘、逐元素乘、sigmoid/tanh 激活计算过程，这些都是典型的门控计算单元。

4.3 LSTM 状态与环形缓冲：推理之间的状态管理

上一节提到 LSTM 是有状态的，我要重点展开这一点，因为这是源码里最容易出错也最值得学的地方。

普通的前馈网络（如 DNN、CNN）每一次推理都是独立的，输入输出之间没有状态依赖。LSTM 不同，它的 cell state 和 hidden state 是跨时间步传递的。在 MCU 上实现 LSTM 推理，必须在多次推理之间保留这些状态向量，而且不能把它们放在临时内存里——因为下一次推理还没开始，上一次的状态就要被覆盖了。

项目里通过为状态张量单独分配一块持久内存来解决。你会看到代码在分配张量内存时，把 LSTM 的状态张量标记为持久张量，解释器在Invoke之后不会释放这些内存。每次推理结束，状态自动留在原地，下一次推理直接读取。这个看似简单的设计，实际上解决了嵌入式 LSTM 落地的关键问题。

实际测试时我特意验证过：如果把状态张量的持久性标志去掉，模型的识别准确率会显著下降，因为每一帧推理都从零状态开始，时间上下文完全丢失。这个细节，普通文档中几乎不会提及，但它是把 LSTM 模型搬到 MCU 上的关键认知。

4.4 ROM/RAM 占用与推理延迟的实测数据

在工程实践层面，我基于公开的评测数据和社区实测整理了一份模型对比表，你可以直观感受不同模型在资源占用上的差异：

注意这是“单次推理”的数字，实际系统还要算上特征提取的开销。MFCC 前端处理一帧音频大约需要几毫秒，如果每 20ms 做一次推理，CPU 占用率大约在 30% 到 60% 之间浮动。考虑到唤醒词场景往往还有无线通信、传感器轮询等任务在跑，模型选型不能只看准确率，必须把整条链路的负载一起算进去。

5. 静态评测发现的问题、边界和值得商榷的设计

这一节要进入真正的“审计”环节。我前面说了这个仓库参考价值极高，但它毕竟是实验室产物，“冻结”多年后有些设计已经不符合如今的产品化要求。我不客气地把看到的问题列在这里。

5.1 硬编码 VS 可配置：灵活性与体积的博弈

仓库里大量使用了编译期宏和常量定义来决定行为，比如特征维度、帧长度、模型输入大小。好处是编译期就能确定内存布局，避免动态分配；坏处是任何一项变更都要重新编译整个工程，而且很多参数之间有关联关系，改一个忘了改另一个，就会出各种匪夷所思的问题。

我统计了一下，main.c 和 kws_engine 相关文件里，直接相关的硬编码参数至少有十几个——特征维度、窗口大小、帧移、类别数、模型名、缓冲长度。如果要做成可配置的系统，这些参数应当集中到一个配置文件，并且通过编译期断言校验参数之间的兼容性。很可惜，原仓库并没有做这个约束。

5.2 环形缓冲区边界：帧长、跳帧与溢出推演

这是我审计时最想吐槽的部分。音频采样的环形缓冲区虽然保证了一定的容错能力，但缓冲区的容量计算逻辑并没有在代码里体现得很直白。

我把几个关键数字做了推算：采样率 16kHz、帧移 20ms 意味着每帧新处理的数据是 320 个采样点，而帧窗是 480 个采样点。由于相邻两帧有 160 个采样点的重叠，特征提取模块其实只需要每次“新增”320 个新采样点。环形缓冲区至少需要同时容纳一次完整 DMA 传输的数据量和一次特征提取所需的数据量。

如果你把采样率改成 48kHz，同时没有同步调整 DMA 触发阈值和缓冲区大小，那么 DMA 写入频率会变为原来的三倍，缓冲区极有可能在特征提取完成前就被写满，导致采样点被覆盖。这种事在实验室里很难碰到，因为 demo 的连续运行窗口很短，但放到产品里就是偶发的“识别突发失灵”问题。

5.3 浮点前端与定点推理之间的数值一致性

microfrontend 的特征提取默认用浮点计算，推理部分却用 int8 量化，这中间隐含着两个问题。

浮点前端在不同优化等级下可能产生微小的数值差异——比如 -O0 和 -O3 下 FFT 的舍入误差不同，不同编译器（ARMCC、GCC、IAR）的浮点行为也有差异。这些差异最终会影响量化后的特征输入，进而影响推理输出。在实验室中，这个影响可能只是某个样本的置信度从 0.8 变成 0.79；在产品中，如果置信度落在阈值附近，就可能造成误触发或漏触发。

更隐蔽的问题是，某些 MCU 平台为了省电会关闭 FPU，或者只在部分模式下开启。如果前端代码里有浮点运算却用了不带 FPU 的编译选项，性能会掉得非常厉害。仓库里虽然做了内核区分，但对浮点行为的一致性并没有给出明确的验证方法。

5.4 代码可维护性观察：注释、命名与依赖管理

从代码可维护性角度看，这个项目整体上保持在中等偏上的水准。模块划分清晰，函数命名尽量自解释。缺点是跨模块的全局状态比较多，尤其是音频缓冲区和特征缓冲区的状态变量散落在多个文件里，阅读时需要在文件之间来回跳转才能建立完整的时序认知。

更隐蔽的问题是它和 TensorFlow 子树的“强耦合”关系。仓库里集成了 TensorFlow Lite Micro 的代码副本，这种做法的好处是编译环境完全自包含，坏处是后续想升级 TFLite 版本会非常痛苦——因为项目中针对 MCU 做过裁剪改动，直接换新版很可能编译不过。这也是它后来被冻结的部分原因。

对后来者的启发是：如果你要在自己的项目中推进这类工程，建议采用更轻量的子模块管理方式，把核心业务代码和上游依赖做彻底分离。

6. 从一个审计者的角度给出移植与工程化的具体建议

代码看完了，问题也列完了，但文章如果不能落到“我该怎么用”这个层面，参考价值就打折扣了。这部分我分享一些从实际角度出发的移植思路。

6.1 想在自有板子上把 demo 跑起来，最少要动哪几处

如果你手里有一块 Cortex-M 开发板，想跑通这个项目，我的建议是不要一上来就全量编译，而是按下面这个顺序最小化改动：

1. 确定内核类型：查看你板载 MCU 的 Cortex 内核型号，在 Makefile 里正确设置CORE变量。这一步决定编译器使用哪些 DSP/FPU 指令，也决定 CMSIS-NN 走哪条优化路径。
2. 检查 CMSIS 路径：确保板卡支持包或 SDK 里的 CMSIS-DSP、CMSIS-NN 头文件和库能被 Makefile 找到。如果找不到，项目会回退到基础 C 实现，性能会明显下降。
3. 适配音频输入：把你的麦克风驱动回调函数接到项目定义的音频回调接口上，注意数据位宽和采样率必须匹配。项目默认是 16kHz 单声道 PCM。
4. 替换模型头文件：把你选定的模型量化后的 C 数组头文件替换到对应目录，然后在 kws_engine 相关文件里确认模型名宏定义指向正确。
5. 先跑软件测试源：前面说到的正弦波测试——先用软件生成一段音频输入替代真实麦克风，确认整个特征提取和推理链路能跑通，再接入真实音频。

这里重点提醒一下第 5 步。我见过很多人在“接上真实麦克风”这一步反复受挫，因为音频采集的时序、噪声、增益等现实因素会把问题搞复杂。先用软件输入把链路验证通了，你就把问题域缩小到了“音频采集”一个层面，排错效率会快得多。

6.2 想把 demo 做成产品，还需要补哪些课

跑通 demo 和做成产品之间，隔着相当大的一段距离。结合我审计中看到的问题，我给出几条从实际经验中总结的建议：

第一，重建一个“配置中心”。把前端参数、模型参数、缓冲大小、类别数全部集中到一个配置头文件里，并用_Static_assert做编译期校验。这能避免改一个参数导致另一处越界的隐性风险。

第二，给推理结果加上真正的后处理状态机。别直接用 argmax 输出指令，要加入置信度阈值、连续命中计数、静音段复位等机制。如果不加，稍有一点噪声干扰就会出现误触发。

第三，测试功耗要分开测。特征提取、推理、音频采样的功耗最好分别计量——因为它们的优化手段完全不同：前两者靠减帧率、降时钟、用加速指令省电，后者靠降低 ADC 采样功耗、用低功耗模式监听。不拆开测，你就不知道真正的耗电大头在哪。

第四，留意 LSTM 状态的复位时机。设备进入低功耗再唤醒后，LSTM 的历史状态可能已经过时，直接接着用会影响准确率。在产品逻辑里，唤醒后或者长时间静音后，要有一个清除状态的机制。

6.3 在过去经验基础上的两个关键认知

如果你在这个基础上还想往深处走，我觉得有两个点值得多说一句。

一是这台“老代码”的算法核心里有很多细节其实还没过时。MFCC 特征提取仍然是语音唤醒的主流方案，int8 量化也依然是 MCU 推理的默认选择。这个仓库之所以值得学，不是因为它的代码有多现代，而是它把一套在 PC 上无比自然的流程，老老实实压进了一个几十 KB 内存的芯片里。这个“压缩”过程中的每个取舍，都比任何抽象框架更能帮你建立对边缘 AI 的直觉。

二是别被仓库里的“实验室味道”劝退。恰恰是它硬编码多、后处理弱、状态管理糙这些缺点，才让你在移植和改造的过程中真正搞懂系统的每个角落。我接手过的边缘语音方案，从来没有一个长成教科书的样子；真正把它们做稳定的，靠的就是对这些“不完美”逐条修补的能力。

我现在做语音类固件评估时，即使有新框架可用，也还是会时不时翻回这个仓库对照一下——看看自己的量化配置是不是偏了，特征前端有没有做过度简化，状态管理有没有遗漏边界。说实话，能让人隔几年还愿意回来参考的老项目不多，ML-KWS-for-MCU 算一个。