需说明没听清什么而非仅重复请求
别名: 指出听不清的部分 · 修复发起 · trouble-source repair
概念解释
识别失败之后，系统要开口要的不是「请再说一遍」，而是把没抓住的那一块说出来。「航班号我没听清」和「请重复」看起来都在要重说，前者指定了麻烦源（trouble source），后者把整句重新变成负担。行李托运柱已经听到了姓名和航班日，只丢了目的地城市——还要整句重说，是话术没有对准缺口。
机制
会话分析里，他人发起的修复可以停留在不同精度：开放式的「嗯？」只标记「上一轮有问题」；限定式的「哪个城市？」把问题钉在一个槽上。精度决定对方下一句要重建多大一片。整句重说会把已经对的槽再送进识别器，新的替换错误可能污染刚填好的值。指定缺口则让用户只重做那一块，已接地的内容保持接地。
「请重复」还有一个指称问题：重复什么？上一整句、最后一个词、还是系统刚才念错的那一段？用户经常重说整句或只重说句末，和系统丢掉的部位对不齐。说出没听清的槽，等于把修复的靶子放到公共场地上。这是这一轮要说哪句话的问题；用户是该改一个词还是重说整句、连续失败后要不要换通道，是另一套决定。
怎么研究
把同一失败做成两种恢复句：通指（「请再说一遍」）对指定槽（「目的地城市没听清」）。因变量：下一轮用户话语是整句还是局部、已填槽是否被意外覆盖、这一轮是否填上缺口、修复轮次。自变量：丢掉的是句首、句中还是句末的槽（句末更容易被当成「要重复的那个」）。
语料上按 Schegloff 一派的修复分类给系统话术编码：开放发起还是限定发起。现场日志看「请重复」之后用户重说了哪些词，与系统实际低置信的槽是否相交。不相交就是话术没对准麻烦源。实验室若在失败后弹出文字稿，测到的是阅读修复，不是听觉话术。
边界
系统并不知道丢的是哪一块时，硬指定一个槽会指错靶，用户会去重说一个其实已经对的项。这时宁可承认「整句都没抓住」，也不要假装精确。多个槽同时低置信，指定一个会让其余的静默错误留下；应点名所有低置信槽，或改成一次只要一个。用户主动在纠正（「不是巴黎，是里昂」）时，系统再问「请重复」是忽略已经提供的麻烦源。
怎么落地
- 失败轮先读置信：只一个槽低，就点这个槽；整句低，再说没听清整句。禁止在已有槽置信的情况下一律「请再说一遍」。
- 指定槽时带上已听清的部分作锚：「去巴黎的航班号没听清」，不要只丢一个孤立的「航班号？」。
- 用户已经在局部纠正时，跟上那一块，不要把地板拉回整句重说。
- 验证：抽样「请重复」类话术，标下一轮用户重说的词与低置信槽的交集。交集经常为空，就改成点名槽，再测交集是否上升、已填槽被覆盖是否下降。