用户需能查看与删除历史录音
别名: 查看删除录音 · 会话历史可管 · activity history recordings
概念解释
合租的音箱在厨房里接了一周的请求：谁的外卖、谁的闹钟、谁对着它嘀咕过一句日程。主人打开账户，应该能看见这些历史录音，并删掉其中任何一条。用户需能查看与删除历史录音（inspect and delete voice history）：可查才知道集合里有什么，可删才使留存不是单向的。按钮在厂商后台、或只能关「以后不再保存」而动不了已经在的条目，都不算这条能力。对话系统的历史是房间里的共同生活痕迹，不是只有工程师能打开的日志。
机制
唤醒成功并写入之后，音频对象有了身份：时间、设备、有时还有可播放的波形。身份若只存在于服务端，主人无法核对本周厨房里到底留下了谁的声音。查看要求在用户控制面按时间列出，并能播放或至少读出这条是哪一次请求；删除要求对用户可见的那份对象消失。合租把这条需求变硬：一个人的请求会出现在另一个人也能打开的设备历史上，查与删是在场的人互相清理生活痕迹的工具。不可查的留存等于秘密档案；不可删的查看等于展览。关未来写入的开关不回溯，所以「停止保存」替代不了「删已经在的」。
怎么研究
走查账户、伴侣应用和设备本体三处：同一条厨房请求是否出现、能否播放、删除后是否还在另外两端。计时：非技术用户从打开应用到删掉指定一天的记录要多久。访谈合租的两个人是否知道对方能看见自己的请求。只读政策里有没有「您可以删除」的句子，会得到过好的结论——要看按钮在不在、删完对象在不在。实验室里给一份已填满的假历史，比空账户更能测出「找得到吗」。
边界
从不写盘的本地检测没有可查的音频对象，仍应有触发计数，否则人无法知道这周发生过什么。企业设备可能禁止删除，要在部署时写明，不能做成消费级默认。多人共用一个账户时，删除权会互相覆盖——需要的是按条目删，而不是一个「清空家庭」把别人还要的记录一并抹掉。查看本身会再次暴露内容：在开放工位上把历史念出来，等于第二轮播报。可查可删管的是已有对象，不回答对象该不该在第一秒被写下来。
怎么落地
- 活动历史按时间列出每次已保存的请求，合租场景允许在设备上或账户里播放并单条删除，不要求先找到隐藏很深的网页控制台。
- 删除成功后回查音箱、手机应用、网页三处，同一条目都应消失；只从一处列表里拿掉不算。
- 「停止保存新录音」与「删除已有录音」分成两个动作，不要用一个开关冒充两个。
- 验证：在合租厨房完成若干真实请求后，让另一位室友在五分钟内找到并删掉其中一条。找不到、删不掉、或删完音箱上仍能回放，这条能力就还没交付。