小智唤醒词改了不生效？先别怀疑自己，这是个已知问题

你想让它叫「小鹿小鹿」，不想再叫「你好小智」。

你按教程进了 idf.py menuconfig，找到 ESP-SR 那一堆语音识别选项，把唤醒词换成想要的那个，按 S 保存、回车确认、Q 退出，重新编译、重新烧录，插上电，深吸一口气喊了声「小鹿小鹿」——

没反应。喊「你好小智」，它立刻醒了。

这一刻请先停下，不要开始怀疑自己。 你多半没做错任何事。

先确认你撞上的是不是它

这个现象在上游被记录为 issue #1190，标题就叫「按照官方说明修改唤醒词配置无法生效」。报告人的环境是：

• 硬件：ESP32-S3-LCD-EV-Board
• ESP-IDF：v5.5.0
• 项目版本：2.0.0

最关键的确认方法在串口日志里。 报告里给出的特征是：设备启动后，日志显示它仍在下载并加载 wn9_nihaoxiaozhi_tts 这个模型——注意看这个名字，nihaoxiaozhi 就是「你好小智」的拼音。

也就是说：你改的配置确实保存进 sdkconfig 了，但设备实际去加载的还是原来那个模型资源。 配置和实际行为脱节了。

所以自查只要一步：烧完之后接串口看日志，找加载的模型名。 如果它加载的模型名里带的还是 nihaoxiaozhi，而你配的是别的词，那就是这个问题，不用再往下折腾了。

这一步的价值在于止损。这类问题最耗人的不是问题本身，而是你在错误的方向上反复试——重装工具链、清 build 目录、换 ESP-IDF 版本、怀疑麦克风、怀疑板子。先看一眼日志，能把这些全省掉。

三层根因，为什么怎么改都没用

报告人把原因拆到了三层，我觉得拆得很准，值得原样理解一遍：

第一层：代码里硬编码。 资源文件的定义被写死成了 wn9_nihaoxiaozhi_tts，没有跟着你的配置动态变。这意味着无论你在 menuconfig 里选什么，那行代码指向的都是同一个东西。

第二层：云端资源缺不到。 报告里提到，访问目标唤醒词对应的资源文件 URL 时返回 404。这一层特别关键——它说明就算前面那层硬编码改对了，资源本身也未必拿得到。

第三层：配置传递链断了。 sdkconfig 里的值是正确的，但它没有被真正应用到"选哪个资源文件"这个逻辑上。配置存在，只是没人读它。

把这三层串起来看，你就明白为什么"改了不生效"这么顽固：问题不在配置界面，而在配置生效的那条路上，而且路上不止一处断点。你在 menuconfig 里怎么点，都改变不了后面两层。

顺带说一个认知：唤醒词识别是离线跑在芯片上的，靠的是乐鑫的 ESP-SR 框架和预先训练好的唤醒词模型。它不是"随便给个词就能识别"——每个唤醒词背后都得有一份对应的模型资源。这就是为什么资源文件拿不到，词就换不成。想通这一点，很多困惑会自己散掉。

别把两个问题搞混

排查前先分清楚，你遇到的到底是哪一种。这两种症状听起来像，原因和解法完全不同：

症状 A：喊新词没反应，喊「你好小智」有反应。 这是本文说的那个问题——设备是活的，识别是好的，只是词没换成。

症状 B：喊什么都没反应，原来的词也叫不醒。 这跟唤醒词配置没有关系，别往这上面查。这种情况的常见原因是另一批：

• 麦克风没接好或本身有问题——自定义板子接线错、焊虚，或者用了不匹配的麦克风；
• 音量太小、距离太远——离得远、说话轻，能量到不了触发线；
• 识别阈值设得太高——判定太严，正常说话也够不着；
• 环境噪音干扰——背景嘈杂会显著拉低唤醒成功率。

反过来，如果你遇到的是动不动就自己醒了，那多半是阈值设得太低，或者选的唤醒词太短、太常见，日常对话里就容易蹭到。

区分这两类的最快办法还是那条：接串口看日志。 症状 A 的日志里能看到模型正常加载、只是名字不对；症状 B 往往在更早的阶段就出问题了——音频链路根本没起来，或者压根没有识别事件被触发。日志停在哪一步，问题就在哪一步，这比凭感觉猜有效得多。

现在能怎么办

诚实说：这个 issue 到本文写作时还开着，没有被分配、没有打标签、也没有官方回复。所以下面几条都是绕路，不是修复。

路线一（推荐）：先用能用的词。 ESP-SR 提供了一批预置的唤醒词模型，其中总有能凑合的。先让你的小智完整跑起来——对话、MCP 控制、外设都调通，把唤醒词这件事往后放。这不是妥协，是优先级问题：唤醒词叫什么，对整个项目的完成度影响极小，而卡在这里会让你什么都推进不了。

路线二：换个思路定义"个性化"。 很多人想改唤醒词，真实诉求其实是"我想让它更像我的东西"。那更划算的做法是去改音色、人设、昵称和角色介绍——这些不在固件里改，在服务端配置，改起来轻松得多，感知上的个性化程度还更高。用户听到的是它的声音和性格，不是它的触发词。

路线三：盯上游。 去那个 issue 上点 subscribe。这类问题一旦有人修，通常就是一个 commit 的事。与其自己硬啃，不如让消息来找你。

不建议的路线：自己去改那处硬编码。 技术上你当然可以顺着 wn9_nihaoxiaozhi_tts 全局搜，把它换成目标模型名。但第二层那个 404 摆在那里——改完代码，资源照样可能下不来，你会从一个坑掉进另一个更难查的坑。除非你能自己解决模型资源从哪来的问题，否则这条路投入产出比很低。

这件事更值得记住的是方法

比"唤醒词怎么改"更有用的，是这次排查暴露出来的一个判断习惯：

照着官方文档做，结果不对——第一反应不该是"我做错了"，而是先去仓库搜一下 issue。

开源项目的文档和代码永远存在时间差。文档写的是"设计上应该怎样"，issue 区记的是"实际上发生了什么"。遇事先搜 issue，是我认为性价比最高的开源使用习惯，没有之一。它能把你从"我是不是太笨了"的自我怀疑里直接捞出来——很多时候答案是：不是你笨，是它确实坏了，而且别人早就发现了。

搜的时候有个小技巧：用报错原文或日志里的关键字符串搜，别用你自己总结的话搜。 比如这次，搜 wn9_nihaoxiaozhi 或者「唤醒词」，比搜"改了不生效"命中率高得多。

想继续往下走的话：编译并刷入小智固件是这条链路的上一环，把小智调成你自己的讲音色人设这些能真正改动的地方，小智固件现在要 ESP-IDF 6.0 了讲版本这条更大的坑。