上下文丢失需告知而非静默重置
别名: 别偷偷清空上下文 · 丢失要说出来 · silent context reset
概念解释
用户按共同基础还在的假设说「把那个取消」，系统这边对象已经过期，却用「你想做什么？」接——听起来像第一轮，像从来没有过「那个」。上下文丢失要告知（announce context loss）要求：共同基础少了一块，就说少了哪一块，而不是静默重置成空白会话。告知的对象是丢失这件事本身，不是再念一遍超时规则。人可以接受「我这边已经丢了刚才那单」，不能接受系统装作双方从未提起过。
机制
共同基础是双方各自以为对方还持有的那份集合。静默重置只清了系统侧，用户侧的指针还在，于是同一句话在两边的解释分裂：用户在做回指，系统在做冷启动意图分类。分类器面对「把那个取消」会落到一个无槽的取消意图，或猜一个热门可取消项去执行——两种都比承认丢失更糟。告知是一次接地行为：把「我不再持有对象 X」写进双方都能听见的位置，用户才能改用全称（「取消今天的 UA128」）或放弃。不告知的另一面是假装还在：用含糊的「好的」接一句已经无处可绑的话，随后执行空操作或错操作。丢失和从未建立不同：从未建立可以问「取消什么」；曾经建立过再问得像第一轮，是在否认共同历史。
怎么研究
对比两种过期处理：静默重置（下一句当新会话）与告知丢失（明确说不再持有刚才的对象，并请用全称）。先引入一个对象，强制过期，再让用户用代词发指令。因变量：用户改用全称并成功完成的比例、重复代词导致的错执行、以及用户事后是否认为「它忘了」还是「它没听见」。自变量包括丢失幅度（丢一个槽对丢掉整张单）和告知的具体程度（「我不确定你指什么」对「刚才那班航班我这边已经不记得了」）。
会话回放里标注「用户明显在回指、系统按新意图接」的回合，作为静默重置的现场指标。不要用满意度抹平：有人会给「反应很快」打高分，同时已经执行了错误取消。
边界
对象从未成功引入（识别在第一轮就失败），不存在可告知的丢失，该走的是当轮没听清，不是「我忘了刚才那单」。告知本身会暴露曾经存在过一份上下文——在共享空间、对内容敏感的任务上，大声说「你刚才那张处方我丢了」可能比静默更糟，这时告知要降到「我没接上刚才的对象，请用全称」，避免念出内容。连续多轮都在丢失态，反复告知会变成噪声，应在第一次告知后改收全称，而不是每句都道歉。把告知理解成再问一次「你想做什么」仍是静默重置，只是多包了一层礼貌。
怎么落地
- 过期或状态被清空时，下一句用户若仍像在回指，先承认丢失再要全称：「刚才那单我这边已经没有了，告诉我取消哪一班。」不要用开场白式的「我可以帮你做什么」。
- 告知里点出丢失的类型（哪张单、哪一场），不要只说「没听清」——那会把状态问题说成声学问题。
- 丢失后的第一轮禁止凭热门槽猜着执行；没有新的全称就停在询问。
- 验证：引入对象 → 强制过期 → 用户说「取消它」。系统若执行了某项取消、或回了一句可出现在第一轮的开场白，就是静默重置。应看到的是一次丢失声明，加上一次对全称的请求。