C7.09.4Endpoint errors lack post-hoc repair设计研究
端点判定错误无法在事后修正，只能靠用户重新说一遍或手动确认结束
别名: 端点不可逆 · 手动结束 · 重说恢复
概念解释
端点一旦提交，这一轮的“何时结束”就定了。判早了，后半句不在缓冲里；判晚了，等待已经花掉，后续的插入噪声也可能被收进假设。与替换一个词不同，端点错误不能在同一假设上事后改正。用户能做的是重新说一遍，或下次用按钮、手势手动确认结束，把判决权从检测器手里拿回来。这是操作层的不可逆，不只是音频被切掉这一事实。
机制
提交触发解码终态、可能的执行和 UI 进入“已完成”。没有“把终点往后挪 400 毫秒再解一次”的标准控件，因为产品已经把该轮当成关闭的请求。晚结束虽然理论上还能从更长的缓冲重解，但交互时钟已经向前走，用户可能已开始听回复。因此工程上把端点当成一次性动作。恢复路径只剩下：新的一轮（重说），或在检测器不可靠时提供显式结束（点完成、松开 PTT、说一个结束词）。结束词本身又要被识别，会叠一层错误。不可逆是交互协议的属性：协议没有“修订终点”这种原语。
怎么研究
在过早和过晚两种注入下，测量用户选择重说、尝试口头补一句、还是去找完成按钮。记录从发现端点错到恢复成功的时间。比较有无显式结束控件。不要只测截断丢失的词数——那是内容层；这里要测协议层有没有修复原语。
边界
流式系统若在宣布结束前保留可撤销的“软终点”，短窗口内可以收回，那是尚未提交。会议转录的切段可以在离线后重新切，用户不在回路里等。按住说话从一开始就手动结束，不存在检测器误判要事后修。把“无法事后修正”理解成禁止提供重说，说反了：重说正是因为不能修才成为主路径。
怎么落地
- 在自动端点旁边始终放一个明确的完成/取消控件，让用户能覆盖检测器。
- 提交后若马上检测到声音又起来，优先提供“追加到上一句”而不是当成无关的新命令，减少整句重说。
- 验收故意制造过早封口，确认用户能在两步内重说或手动结束，而不是卡在一条已执行的错误命令上。