语音输出比语音输入更容易暴露内容
别名: 播报泄露 · 回读暴露 · TTS overhearing · loud readback
概念解释
酒店房间里人对着手机低声说「明天行程」。扬声器以客厅音量答：「明早七点四十分飞往虹桥的航班，三点与王律师见面，记得带合同。」走廊和隔壁听见的是后一句。语音输出比语音输入更容易暴露内容（speech output more exposing than input）：用户还能省略、含糊、压低；系统为了可懂，会把槽位读全、读响、读成完整名词短语。泄露的峰值往往在回复，不在请求。
机制
输入侧人还握着编码权：可以说「那个会」、可以气声、可以说到一半改用手打。输出侧的用词、句长和目标响度由合成器与产品策略写成，优化对象是识别确认和听清，不是对墙外保密。确认回读尤其危险——它把最敏感的槽（时间、人名、账号尾号、短信正文）用设计过的幅度再广播一次。输出还常比输入长：一条短命令换一段日程摘要。薄墙酒店、开放工位、车内免提，房间里的信噪比足够让回复成为更清晰的那一端。用户打断来得及的前提是已经听见开头；开头往往已经包含了那个槽。
怎么研究
在同一距离、同一房间里比较旁人对用户原句与系统回复的可懂度：脚本化一对「短命令 / 长回读」，让墙外或邻座听写，按槽位计分。自变量包括扬声器音量、是否耳机、回读是否全文。日记里问「你觉得被听见的是你说的还是它说的」——若多数指向回复，暴露不对称就已经在真实使用里出现。不要只用主人的「我觉得我说话很小声」当证据。
边界
全程耳机收听且系统不再走扬声器时，输出侧这条不对称被关掉，输入侧的暴露仍在。无屏、必须听确认的驾驶场景，回读的可懂度有安全理由，不能为了旁人把航向念成含糊词。对讲和公共广播的输出本来就是说给许多人听的。把所有长回复都改成「已处理」会把主人自己也蒙在鼓里。不对称成立的前提是：系统比用户更响或更完整；用户自己喊出来的命令，不对称可以反转。
怎么落地
- 含人名、地址、日程、消息正文的槽，默认不要用扬声器全文回读；改成「已加入明天三点的一项」或推到锁屏摘要。
- 公共场景或未插耳机时启用短确认；只有用户明确要求「读出来」才展开。
- 打断必须在第一个槽读完前就能掐掉扬声器，而不是等整段摘要结束。
- 验证：在酒店房门关着、走廊站人的条件下播报一条真实行程回复。若墙外能写下律师姓氏或航班号，而听不清用户那句短命令，输出侧就是暴露主通道，回读策略要改。