L1.12.4mid-stream self-correction shows overturned content设计研究
流式过程中的自我修正会让用户看到随后被推翻的中间内容
别名: 流式改口 · 被划掉的中间句 · visible retraction
概念解释
模型先写出一个数，两秒后改成另一个；先答应「可以发」，后文变成「请先核对」。非流式里这些中间句死在缓冲区。流式把它们广播了。可见的改口（visible retraction）让人看见一份随后不被承认的文本，这份文本仍可能已经被读、被信、被抄走。
对着前缀下判断，是人主动提前评估。这里是系统把将被推翻的句子送上屏幕。
机制
解码是局部贪心加后期约束：工具结果返回、自我检查、安全层迟到，都会在已经发出去的前缀后面接一个转弯。流式协议通常只追加，不提供「收回第 17–23 个 token」的用户侧语义。即使后来用删除线或整段替换，第一眼的编码已经完成。记忆和剪贴板不自动跟随删除线。
信任伤害是不对称的。人看见系统否定自己刚才说的话，会把不确定读成不诚实，尤其当被推翻的是数字或承诺。非流式只交终稿，终稿内部的矛盾至少发生在同一时间切片里，人按一份文件审。
怎么研究
植入一次中途改口（数字、是否承诺），流式放出，允许复制。因变量：是否记住被推翻的版本、是否把旧数字带进下游、对系统诚实的评分。自变量：改口是否带删除线/说明、旧句是否还在 DOM 里可被复制。
要测剪贴板，不只测屏幕。旧句在 DOM 里是一条独立的泄漏路径。
边界
思考过程故意对外可见的产品，改口是功能，但必须视觉上属于「草稿/推理」，不能混进将要发出的答案层。代码补全里的闪烁建议是另一套，用户没把它当承诺。流式若只在句子边界提交，改口可以收在句内，代价是首字更慢。这条不处理长任务该不该流式。
怎么落地
- 答案层尽量在句或段边界提交。推理层若要可见，用另一套样式，且不可一键复制进「答案」。
- 发生改口时，明确收回：删除线加「更正为」，并让复制拿到的是更正后的版本。
- 数字和承诺尽量等约束到齐再写进答案层，宁可晚一秒，不要先许再悔。
- 验证：让一次流式先给出错误金额再改口。问金额是多少、剪贴板里是哪一个。旧的还在人口中或剪贴板里，改口在泄漏。再看 DOM 里旧 span 是否仍可被选中。