持续监听与持续记录需明确区分
别名: 常听不等于常录 · 关键词检测缓冲 · wake-word buffer
概念解释
合租厨房里的音箱整夜亮着一只小灯。室友问「它是不是一直在录音」。多数包装上的「始终在线」把两件不同的事焊在一块：持续监听（always-listening）是本地关键词检测在短缓冲上跑，未唤醒则覆盖写；持续记录（always-recording）是把音频写成可检索的对象，进盘或进云。对话系统要能把这两态分开说清楚。混用会让「为了唤醒必须开着麦」被听成「房间里每句话都存档」。
机制
远场对话的唤醒依赖一个一直转的检测器。工程上常见的是环形缓冲：几百毫秒到一两秒的音频在芯片上循环，命中唤醒词才把后续段送去识别。这一段「一直在听」不等于「一直在记」——未命中的样本按设计应被丢掉，没有文件名、没有会话 ID。持续记录则相反：有写入、有保留、有可能被训练队列取走。用户、客服话术和隐私说明若共用「在听」这个动词，两种数据流就无法被追问。区分的要点是对象生命周期：监听态的音频没有身份；记录态的音频有身份，因此才谈得上查看和删除。灯亮着只说明有一条声学通路，不说明走的是哪一种生命周期。
怎么研究
用隐私营养标签理解测验：给一段产品文案或标签，问「未说唤醒词时，这句话会不会变成一条可回放的记录」。计分按「听 / 录」是否被分对，不要按「觉不觉得安全」。再加一个卡片分类：把「环形缓冲覆盖写」「唤醒后云端识别」「用户同意的改进计划上传」分成三堆，看说明读完后三堆是否还黏在一起。走查设备：未唤醒时段是否产生带时间戳的音频对象——有，就是记录；没有，才是监听。包装上的「不录音」若与活动历史上的条目矛盾，理解测验的正确答案应以设备行为为准。
边界
有些产品把唤醒前后数秒一并上传做「改进」，监听与记录的边界被产品自己拆掉，不能再靠「只是关键词检测」来辩护。纯本地、音频从不离开芯片且从不写盘的检测，记录态可以不存在，仍要把监听态写明白。会议音箱、取证录音笔的工作定义就是持续记录，区分的意义变成「用户有没有把它当成助手」。法律文本里的「处理」比「听/录」更宽，标签若只说听/录，可能仍覆盖不了一次瞬时推理。区分解决的是数据流类别，不是房间里有人觉得安不安心。
怎么落地
- 在设置首页用两行分开写：「等待唤醒词时，音频在本地短缓冲中覆盖，不生成历史条目」以及「唤醒之后，本次请求是否保存、保存在哪」。禁止用一颗「始终在线」开关同时代表两态。
- 活动历史里不应出现未唤醒时段的可播放片段；若出现，就按记录态而不是监听态来标。
- 客服和开箱卡片准备一个对照句，专门回答「它是不是一直在录音」，答案必须点名缓冲覆盖写，而不是「我们很注重隐私」。
- 验证：找未读过内部文档的人读完标签，做三道是非题（未唤醒是否生成文件、唤醒后是否默认保存、改进计划是否另开同意）。任一题被文案带错，标签重写。再用未唤醒的一小时抓包/本地文件列表，确认没有新的音频对象。