C7.08.2Inspectable deletable false-wake logs设计研究
误唤醒记录应可查可删
别名: 唤醒历史 · 录音删除 · activity log
概念解释
每次唤醒——无论有意无意——若产生了音频、转写或云端会话，就应留下主人可查、可删的记录。误唤醒尤其需要这条：当事人往往不在场，事后只能靠日志知道发生过什么。不可查等于无法审计；不可删等于把一次意外采集变成长期存档。
机制
关键词命中会生成时间戳、设备标识、有时还有音频片段和识别文本。这些对象若只存在于厂商后台，主人无法核对这些片段是不是误触发、里面有没有旁人的话。可查要求在用户控制面列出时间、设备和是否仍存音频，而不是一句“我们保护你的隐私”。可删要求删除同步到所有副本，包括用于改进模型的队列，否则界面上的删除是假的。真唤醒的记录同样应可管；误唤醒只是使“我不知道它听了”的需求更硬。保留期限到期自动删，不能替代用户主动删。
怎么研究
走查账户里的活动历史：误唤醒是否出现、音频能否播放、删除后是否还在别的端点。用厂商政策文件对照实际 API。用户研究看非技术用户能否在五分钟内找到并删掉一条。只读隐私政策不问产品里有没有按钮，会得到过好的结论。
边界
纯本地、从不写盘的关键词检测可能没有可查的音频对象，仍应有“今日触发次数”之类的计数，否则用户无法知道误唤醒是否发生过。企业设备可能限制删除，那要在部署政策里写明，而不是做成消费级默认。法律取证保留与用户删除权冲突时，需要单独的合规路径，不能把所有记录藏起来冒充保护。没有云账号的设备，记录必须在设备上可查可删。
怎么落地
- 活动历史按时间列出每次聆听，误唤醒与有意唤醒用同一套删除动作，并写清音频是否已不在服务器。
- 删除成功后回查设备、手机伴侣应用和网页控制台，三处都应消失。
- 没有历史界面就不该把音频默认上传；先做到可查，再谈用这些片段改进模型。