隐式确认把确认嵌入下一句回应
别名: 隐式确认 · 嵌入式复述 · embedded acknowledgement
概念解释
隐式确认（implicit confirmation）不另开一轮问「对吗」，而把听到的内容嵌进下一句已经在做事的话里。校车调度说「好，改走隧道那条，五分钟后到西门」，边说边改路线。用户若听出「隧道」是错的，必须立刻插话；若不插，系统把沉默当同意。确认没有消失，它改成了默认继续，错了再拦。
机制
隐式确认把「复述」和「推进」压进同一句，省掉一次话轮交接。信息结构变成：已填槽作为已知信息出现在句子的预设或状语里，新动作作为焦点。听者要在推进的同时做一次校验扫描——把嵌进去的槽和自己刚才说的对照。扫到不一致，还要在系统继续往下走之前抢地板。
因此隐式确认的可靠不取决于系统有没有说出那个词，而取决于用户有没有注意到并来得及打断。嵌得太浅（「好的」然后直接改路线）等于没有确认；嵌得太深（把三个槽都塞进一句很快的合成语音）会让校验扫描来不及。沉默的含义也被改写了：显式确认里沉默是未决；隐式确认里沉默是放行。用户若把系统的下一句只当成进度广播，不会去扫槽，错就执行了。
怎么研究
把同一槽的错误识别做成两种呈现：单独问「是 X 吗」，对把 X 嵌进下一句动作。因变量是嵌入错误检出率（用户是否在执行前打断并纠正）、检出所需时间、以及未打断时错误执行是否真的发生。自变量包括嵌套槽的位置（句首预设、句中、句末焦点）、语速、是否允许打断。
眼动或双任务会压低检出率：人在看路或看屏幕进度条时，嵌入的专名更容易滑过去。Wizard-of-Oz 可以在内容轮故意换一个邻近值（西门对东门），看隐式句里有多少人拦住。不要把「用户后来没有投诉」当成检出成功——很多人发现时动作已经做完。
边界
用户听不清合成语音、或下一句同时在做别的事（地图已经开始画线、号码已经开始拨）时，校验扫描被动作本身抢走，隐式确认退化成通知。听力困难、非母语、噪声里，嵌进状语的专名是最先不可懂的部分。隐式句若在说完之前就不可逆地执行，打断来了也没有确认的意义。把所有槽都隐式确认，等于把整张表的校验负担一次性交给听者的一瞥。
怎么落地
- 低风险、可当场改口的推进用隐式：下一句里带一个用户听得见的槽，然后继续。槽放在句子里相对突出的位置，不要埋进很快的从句。
- 隐式句必须可打断，打断后停在可改的状态，而不是「已经在执行，只能听完」。
- 不要用光秃的「好的」充当隐式确认——那是接收，不是复述。
- 验证：在测试里故意把一个邻近值嵌进下一句，看打断是否发生在执行前。执行已经开始才纠正的，这句隐式确认没有工作。