在嘈杂环境里 Chatterfly 听错指令，先别急着换麦克风或重录唤醒词。多数情况下设备其实已经被唤醒，只是转写文本被噪音带偏；也有转写完全正确、但后面的意图理解跑偏的情况。这三种问题的处理动作完全不同，所以第一步是把转写文本调出来看，而不是凭回忆猜当时的识别结果。

判断顺序建议固定为三步：先确认唤醒状态，再看转写文本，最后看响应结果。唤醒灯或界面没进入聆听状态，问题在唤醒阶段；转写文本与所说内容有出入，问题在识别阶段；转写正确但响应不对，问题在意图理解或下游执行环节。自测时先在安静环境录同一条指令留基线，再在噪音下重复，逐字对比转写差异。看不到转写文本时，先找调试面板、会话记录或日志入口，不要靠回忆猜。

在安静环境录一段标准指令，作为识别基线

这一步先把麦克风硬件和发音习惯的干扰排除掉。如果安静环境下识别也不稳，嘈杂环境的表现就没有参考价值，得先解决设备和发音问题。

录音工具用手机自带录音机、Audacity，或者 Linux 上的 arecord 都可以，关键是和 Chatterfly 拾音的硬件保持一致：同一个麦克风、同一距离、同一角度。每条指令录 3 到 5 秒，说之前停半秒，说完再停半秒，方便之后把录音和转写文本对齐。

# Linux 示例，录 5 秒
arecord -f cd -d 5 baseline-01.wav

# 确认当前使用的是哪个录音设备
arecord -l

指令文本建议覆盖三种长度，每种各准备一到两条，避免只用自己最顺口的那一句：

• 短指令（2 到 4 个字）：暂停播放、打开客厅的灯。
• 中等指令：把音量调到百分之三十、明天上午十点提醒我开会。
• 带数字或专有名词：导航到中山路一百二十八号、给张三发一条消息。

记录方式用一张固定表，每条指令一行，语音说完后立刻把 Chatterfly 界面或日志里的转写文本抄进去，不要事后凭印象补写。

安静环境下「是否与指令一致」这一列应当全部为是。如果出现否，先检查麦克风增益、系统静音开关、默认输入设备这三处，修好之后再继续往下测。这条基线的意义是给出当前设备与发音习惯下的识别上限，后面噪声环境的结果只能和它比。

在嘈杂环境重复同一指令，记录转写文本差异

噪音模拟尽量用可复现的方式，不要用「在客厅随便走动」这类无法重复的场景，否则两次结果没有可比性。

• 白噪音或粉红噪声：用另一台设备播放，放在距 Chatterfly 拾音位置大约一到两米处，音量调到你正常说话时「能听见但听着不轻松」的程度。
• 人声背景：播放一段播客或多人对话音频。人声干扰对转写的影响通常比稳态噪声更明显，建议单独测一轮。
• 稳态噪声：风扇、空调、抽油烟机这类持续声音，音量波动小，最容易复现，适合作为长期对比条件。

每换一种噪声，把第一节的同一批指令按同样顺序、同样距离、同样语速重说一遍，不要临时改措辞，否则差异无法归因。然后把两次转写文本逐字对齐，逐条标出差异类型：

基线：把音量调到百分之三十
噪声：把音量调到百分之三千
差异类型：同音替换（十 → 千）

基线：明天上午十点提醒我开会
噪声：明天上午提醒我开会
差异类型：漏词（十点）

差异一般落在三类：漏词、同音或近音替换、多出无关词。同一句在噪声下重复三次以上，如果错误位置每次都差不多，说明是稳定受噪声影响的字词；如果错误位置随机，更可能是拾音电平和距离的问题。同时记录噪声下唤醒是否仍然触发，没有唤醒的那次不计入转写对比。

查看 Chatterfly 是否正确唤醒并开始转写

唤醒和识别是两件事。有些设备被噪声干扰时根本没进入聆听状态，用户却以为是「听错」，实际上连转写都没开始，这时候去调指令文本是白费功夫。

• 唤醒指示灯：常亮、呼吸、闪烁分别对应什么状态，先对照设备说明确认。说话时灯没有任何变化，基本可以判定唤醒没触发。
• 界面状态：App 或设备屏幕是否进入聆听或录音状态，有没有「正在听」之类的提示文字。
• 音频输入指示：系统设置里的输入电平条或设备上的拾音指示，说话时是否有明显跳动。
• 日志时间戳：能拿到日志时，看每次唤醒事件后面是否紧跟一条转写事件。只有唤醒没有转写，说明识别环节没启动。

日志是文本文件时，可以先用关键词粗略过滤。文件名和字段名需要换成你设备上的实际值：

grep -iE "wake|transcri|asr" chatterfly.log | tail -n 50

未唤醒的常见原因，按排查成本从低到高排：唤醒词发音与设备登记的不一致，或者语速过快把两个字连读；环境噪声把唤醒词盖住，人声背景尤其明显；麦克风增益太低、设备处于静音、默认输入设备被切到别的硬件；同一时间有其他程序占用麦克风，唤醒通道拿不到音频；说话距离超出设备标注的拾音范围。确认每次测试都能稳定唤醒之后，转写文本的对比才成立。

根据转写文本修正发音或改用短指令复测

如果噪声下的转写文本明显被拉长、粘连或漏词，先怀疑发音清晰度和指令长度，而不是立刻去改识别相关配置。做三组对照复测，每组只改一个变量，其他条件保持不变：

1. 分段说：把长指令拆成两步，例如先说「音量」，等设备反馈后再补「百分之三十」，看每一步的转写是否完整。
2. 放慢语速：在词与词之间留出明显停顿，但不逐字拖长，避免把数字读成两个音节。
3. 关键词优先：把核心动词和宾语提到前面说，带数字的指令把数字单独说一遍再复述确认。

记录时每个变体至少重复三次，写下每次的转写文本和是否与预期一致。重点不是算准确率，而是看哪一组变体下的转写明显更接近预期。

变体        次数   转写结果                是否一致
原句        3      把音量调到百分之三千       否
放慢语速    3      把音量调到百分之三十       是
拆成短句    3      音量 / 百分之三十          是

如果放慢语速后转写变准，问题偏向发音节奏；如果改成短指令后变准，说明长句在噪声中更容易被切碎；如果三种改法都错，回到上一节确认唤醒和拾音是否正常，别继续在措辞上打转。

如果转写正确但响应错误，检查意图理解环节

这一类最容易被误判成「听错」。转写文本和你说的一字不差，设备却执行了别的动作，问题不在语音识别，在后面的意图理解或下游执行。

验证方法是把界面或日志里的那条转写文本原样复制出来，用文字输入的方式再发一次，观察响应是否一致：

• 文字输入响应正确、语音输入响应错误：问题偏向语音通道的处理，比如语音流里带了额外的静音段或环境音标记，或者当次会话的上文被误带上。
• 文字输入同样响应错误：问题在意图理解或下游执行，与噪音无关，需要检查指令模板、实体词典、设备别名映射。
• 产品没有文字输入通道可供对照：只能固定同一句指令，在不同噪声条件下重复多次，看响应是否随转写文本变化，结论的确定性会低一些。

还有一种情况值得留意：同一句话在不同时间点说，响应结果不一样，而两个时间点的转写文本完全一致，那基本可以排除识别环节。

按这个顺序走一遍，通常能把问题落到具体环节上。需要提醒的是，不同设备、不同固件版本暴露的转写文本和日志字段并不一样；如果拿不到转写文本，只能靠固定指令、固定距离、固定噪声条件的重复测试间接判断，结论会保守一些，也不适合直接当成设备能力的定论。