用户说"打开客厅灯"，ASR只收到"开客厅灯"。设备日志显示VAD已触发，开发者第一反应往往是调低检测门槛。但那条日志只说明检测事件发生了，不说明整句音频从哪里开始交给ASR。首字丢失的排查，必须从"事件触发点"和"音频起点"分离这个基本事实出发。

来源说明：下文涉及的ESP-SR/AFE接口细节（VADNet延迟拆分、vad_min_speech_ms、vad_delay_ms、result->data/vad_state、vad_cache_size、AFE VAD cache等）均来自社区来源对乐鑫官方文档的引用与转述，本文未独立核验官方原文。读者应以对应版本的ESP-SR/AFE官方文档为准。

VAD的第一帧，未必是语音的第一帧

据社区来源引用乐鑫ESP32-S3 VADNet文档，VAD延迟可拆成两部分：算法本身可能晚若干帧触发；为减少误触发，连续语音还要达到vad_min_speech_ms才正式触发。该来源还提到，直接从VAD首次触发帧开始保存音频，可能把首字截掉；AFE V2.0因此提供了VAD cache。

这不是说VAD一定会丢字。问题出在应用把"现在确认有人声"误当作"现在才开始录这句话"。触发线之前可能已经有属于这句话的采样；如果上送ASR的片段从触发线才开始，识别端根本无从恢复被丢弃的开头。

社区来源引用的配置示例中vad_min_speech_ms = 128是连续语音门槛，不是"应该丢掉128 ms音频"，也不是任意设备的最优延迟。同一来源还单独给出vad_delay_ms。若只是把门槛调低，事件可能更早触发，也可能让噪声更易误触；应用没有接回触发前音频时，片段起点的错误依然存在。

有缓存时，先交前缀再交本次音频

据社区来源引用乐鑫AFE使用示例，代码从fetch结果读取result->data和vad_state，并检查vad_cache_size。该示例注明：若存在vad_cache，应把它接在处理后音频前面，以免丢失数据。

把这处交接写成可检查的顺序：非空的缓存前缀 → 本次处理后音频 → 后续音频 → ASR输入。如果日志只显示"cache存在"，发送路径却从result->data开始，首字仍会丢；如果同一前缀在两个位置各拼一次，ASR又会收到重复声音。应记录缓存大小、处理后数据大小、片段序号或时间戳，以及实际发送的字节范围，而不是仅记录一次VAD状态变化。

这里有一个实现边界：示例说明了拼接顺序，却不能替你的固件保证缓存指针可保留多久、当前版本每次fetch是否返回缓存、上游是否已把前缀消费。要按实际ESP-SR版本与业务代码核对生命周期，再决定是当场复制还是立即交付。vad_cache_size为零时也不能凭空补出前缀；先确认配置和取样位置，再判断是否需要另一个有界预录缓冲。

三处留样，找到首字第一次消失的位置

对同一句短语，在三个边界留下可对齐的音频：① 麦克风采集后的原始输入；② AFEfetch的缓存和处理后音频；③ 真正送给ASR的片段。每处记录采样率、通道数、位宽、序号或时间戳，以及固件和ESP-SR版本。这是排障设计，不是官方验收规范。

先听和看实际送入ASR的波形，再比较文字结果。选择短促或弱辅音开头的短句，在相同距离和噪声下重复，对照缓存已拼接与未拼接的入口音频；同时记录误触发和额外等待。若只看转写，ASR自身的错误会遮住前端问题；若只看一段录音，又可能把一次偶然识别结果当作修复。

只有证据表明缓存已正确接入，而AFE输出仍在开头缺声音时，才逐项对照VAD模式、vad_min_speech_ms、vad_delay_ms和唤醒后的启停时机。每次只改一个变量，并保留原始输入与ASR入口样本。参数变化要同时看首字保留、误触发和等待量；社区来源引用的文档没有给这块假设设备的最佳配置。

工程修复顺序与边界

修复首字丢失，建议按以下顺序推进：

1. 确认采集起点：检查麦克风采集是否在VAD触发前已持续运行，避免前端输入本身被截断。
2. 接入VAD cache：在AFEfetch路径中，若vad_cache_size非零，将缓存前缀拼接到处理后音频之前，并记录拼接字节数。
3. 对齐ASR入口：在发送给ASR的片段上打时间戳或序号，与原始输入、AFE输出做三方对齐，确认首字是否在传输或编码环节丢失。
4. 参数微调：仅在确认缓存已正确接入后，才考虑调整vad_min_speech_ms或vad_delay_ms，每次只改一个变量并保留对照样本。

需要明确的边界：本文给出的是一条基于社区来源转述接口的可核对排查思路，未在实体板卡上完成实测，现场效果仍需用目标板卡与真实语音验证。交付排障结论时，留下三处音频、缓存与发送顺序、版本和复测记录，才能说清首字第一次在哪一层消失，决定是修采集、补缓存、修传输，还是查识别。