误唤醒产生的录音需默认丢弃
别名: 误唤醒不留录音 · drop false-accept buffer · 无意会话不归档
概念解释
下班后的开放工位，会议音箱被隔壁电视广告里的近邻词叫醒，把还在加班的两个人的谈话采进缓冲。没有人说过唤醒词当指令。这段音频若写成历史条目，一次检测错误就变成一份可回放的档案。误唤醒产生的录音需默认丢弃（default discard of false-wake audio）：默认动作是丢掉缓冲，而不是先归档再等人来删。当事人当时往往不在场或没注意到灯，删的机会从来没有发生过。
机制
关键词命中会打开与真唤醒相同的缓冲和上行路径。真唤醒有一个事后可识别的主人意图：有人接着下了命令或明确取消。误唤醒缺少这个意图，却很容易沿用「先保存以便改进 / 以便用户回顾」的写入策略。写入把一次状态机错误物化成对象，对象会进入历史、可能离开设备。默认丢弃把「没有用户意图」当成留存的否定条件：可以记一次触发计数，不生成可播放文件。可查可删救不了这条，因为删除以「知道有过这一条」为前提；误唤醒的当事人常常要到很久以后才知道，或永远不知道。默认留存等于要求一位缺席的审计员。丢弃发生在写入之前，不是发生在有人事后翻到那一条的时候。
怎么研究
给误唤醒路径做一次写入审计：在有电视人声的工位过夜或数小时，标出每一次无用户后续命令的唤醒，看缓冲是否变成历史里的可播放条目、是否离开本机。对比「默认丢弃」与「默认写入历史」两种固件。因变量是无意图会话产生的音频对象数，不是误唤醒次数本身——次数是输入事件，对象数才是留存事件。访谈第二天在场的人：知不知道夜里留下过录音。不知道却有对象，就是默认写入已经把错误做成了档案。不要用「用户可以去活动历史里删」作为这组条件的通过标准。
边界
用户说了唤醒词又改主意，那是有意打开后的取消，缓冲策略可以不同，不应混进误唤醒默认丢弃。本地检测若严格不写盘，丢弃已经发生，仍建议留触发计数，否则误唤醒是否发生过无法被知道。取证或监管要求保留每一次唤醒的场景，默认丢弃会被政策覆盖，必须在部署时写明，不能假装消费级默认。把误唤醒只当成烦人的出声，会漏掉缓冲已经被写成文件这一层；反过来，丢弃音频不等于这次误唤醒没有打断正在做的事。
怎么落地
- 无后续用户命令、或被明确标成误接受的唤醒，缓冲默认不写入历史、不上传；允许留下不可播放的触发计数。
- 不要把「帮助改进」的默认勾选接在误唤醒片段上；改进计划只应收有意会话且另开同意。
- 若产品仍提供「我要听误唤醒」的调试开关，默认必须是关，并且开关在专家设置里。
- 验证：会议室或工位置一夜电视，第二天账户里不得出现无用户命令的可播放条目。出现了，就还在用「先存再删」处理一次本不该成为记录的错误，改成写入前丢弃。