小智没声音、听不见你说话：按链路分段查，别乱换硬件

板子开机了，网也连上了，控制台里设备显示在线——然后你对它说话，它一动不动。

或者更气人的：它明显有反应（灯变了、屏幕动了），但你什么都听不见。

音频问题最难受的地方在于它只有一个症状：没声音。而背后可能的原因分散在一整条链路上。见过太多人在这里开始换硬件——换麦克风、换喇叭、换板子，换了一圈还是老样子，因为问题压根不在硬件上。

先把问题劈成两半

这一步不做，后面全是乱猜。"没声音"其实是两个完全不同的问题：

A. 它听不见你（麦克风侧 / 输入链路）—— 你说话它毫无反应，唤醒不了。 B. 你听不见它（喇叭侧 / 输出链路）—— 它明显在工作，但没有声音出来。

怎么区分：看它有没有"被唤醒"的迹象。 多数板子唤醒时会有灯效、屏幕变化或者日志输出。如果喊唤醒词后有这些迹象，那输入链路是通的，问题在 B；完全没有，问题在 A。

这一刀切下去，排查范围直接减半。别跳过这一步。

完整链路长什么样

理解链路，才知道日志该看哪一段。一次完整对话大致是：

麦克风采集 → 本地唤醒词识别 → 音频编码 → 传到服务端 → 语音识别（ASR）→ 大模型（LLM）→ 语音合成（TTS）→ 传回设备 → 解码 → 喇叭播放

看清楚这条链的一个重要事实：中间有一大段在云上，不在你的板子里。 所以"没声音"完全可能是网络或服务端的问题，跟你的硬件毫无关系——这也是为什么盲目换硬件常常无效。

用日志定位卡在哪一段

接串口看日志，这是唯一靠谱的定位手段，比任何猜测都快。

看不到音频相关的初始化日志 → 音频硬件层就没起来。查 codec 型号、I2C 地址、引脚定义。这是自定义板子最常见的情况。

能初始化，但说话没有任何识别反应 → 采集这段有问题：麦克风接线、采样率、或者根本没采到数据。

能唤醒，但之后卡住 → 输入链路是通的，问题在编码或上云这段。查网络。

服务端明显有回应，但设备不出声 → 输出链路的问题：解码、功放使能、喇叭接线。

日志一切正常就是没声音 → 重点怀疑功放使能引脚和音量设置。

最后这条值得单说：很多板子的功放有独立的使能（EN/SD）引脚，不拉高就完全没有输出，而这在日志里通常什么都看不出来——一切正常，就是不响。自定义板子漏配这个引脚的情况相当多。

自定义板子上，三个最常见的配置原因

如果你的板子不是上游现成适配的，音频不工作的原因大概率在这三处，全都在 config.h 里：

一、codec 型号或 I2C 地址不对。 音频 codec 通常通过 I2C 配置。地址填错，codec 根本没被正确初始化——症状是彻底没声音，且日志里可能有 I2C 通信失败的痕迹。抄参考板时，如果你的 codec 型号和它不同，这里必须改。

二、I2S 引脚接错或写错。 音频数据走 I2S，涉及时钟、数据、片选好几根线。任何一根错了都是没声音，而且不会报错。这也是最需要拿着原理图逐根核对的地方。

三、采样率和硬件对不上。 参考配置里会有类似 AUDIO_INPUT_SAMPLE_RATE 这样的定义。这个值和你的硬件对不上，轻则音质异常、变调，重则完全不工作。

顺带提醒一个和版本有关的坑：上游的 ESP-IDF 6 迁移文档点名了 I2S 端口编号、LCD 的 I2C 配置、UHCI 的 DMA 依赖 这几处改动。I2S 正好就在音频链路上——如果你是从旧版本升上来、升完音频就坏了，八成落在这里，详见小智固件现在要 ESP-IDF 6.0 了。

什么时候才该怀疑硬件

在你把上面这些查完之前，基本不该怀疑硬件。判断硬件有嫌疑的信号是这几个：

• 换了好几组不同的配置，症状一模一样——说明变的东西没起作用，那问题在不变的那部分，也就是硬件；
• 同一份固件在别人的同款板子上是好的；
• 能看到明显的物理问题：虚焊、接触不良、器件发烫、供电电压不对。

尤其提一下供电：功放推喇叭是要电流的，用一根质量一般的 USB 线从电脑取电，很容易在放音瞬间掉压导致重启或者杂音。如果你的症状是"平时好好的，一说话就重启"，几乎可以断定是供电问题，换个像样的电源试试，别去查代码。

有声音但不对劲，各是什么毛病

比"完全没声音"更常见的其实是"有声音但很难听"。这类问题的指向性很强，基本能一一对应：

声音变调、像快放或慢放 —— 采样率对不上。播放端和数据实际的采样率不一致，就会整体变调。查 config.h 里的采样率定义。

破音、爆音，音量大时尤其明显 —— 优先怀疑供电。功放推喇叭的瞬间电流不小，供电跟不上就会破音，严重时直接重启。其次才是音量设太大导致削顶。

持续的电流声、底噪 —— 硬件层面的干扰。音频线走线离电源或高频信号太近、地线处理不好都会这样。这类问题改代码解决不了，得从布线和硬件下手。

断断续续、卡顿 —— 数据供应跟不上。可能是网络不稳（音频流从云端来），也可能是设备资源紧张。先看是不是只在联网差的时候出现，能区分开这两类。

有回声、它把自己的声音又听进去了 —— 麦克风和喇叭离得太近，或者缺少回声消除。这在结构设计上有讲究，把麦克风和喇叭分开、加隔离，比软件层折腾有效。

看清楚这个规律：这几类里有一半以上的根因在硬件和结构，不在代码。这也是为什么做 AI 硬件不能只当软件项目做——音频体验的上限，很大程度上在你把喇叭和麦克风摆在哪里的时候就定了。

一个建议的验证顺序

如果你正在做自定义板子，别等全部做完再一起测。按这个顺序，一段一段验：

先开机 → 确认没踩到危险引脚； 再麦克风 → 确认能唤醒； 再喇叭 → 确认有输出； 最后屏幕和其他外设。

每一步只引入一小段新配置，坏了立刻知道是刚加的那段。反过来，全接好了一次上电，出问题时你面对的是十几个变量，只能靠猜。

分段验证不是麻烦，是省时间。 做硬件的人越早养成这个习惯越好。

相关：小智接线和默认不一样讲引脚定义怎么改，小智自定义开发板怎么加讲板级配置的全貌，小智的音频之心讲 I2S 采集和编码的原理。