L3.06.2streaming is not final until complete设计研究
流式内容在完成前不应被当作最终结果
别名: 未完成非终稿 · 半成品误用 · incomplete not final
概念解释
合同条款正往外冒，第三款刚出现，用户已经把当前可见的段落粘进待发邮件。后面还会改数字、补例外、甚至推翻第三款。被发出去的是一份尚未结束的稿。完成前非终稿（streaming is not final until complete）要求：流式过程中的可见文本默认不是可交付结果，采用、复制、发送这些动作必须等结束，或明确宣布「就用目前这一截」。
看起来像不像终稿、要不要用不同样式标「还在写」，是另一层。这里管的是状态：没结束，就还不是结果。
机制
人把已经出现在正文位置的句子当成稳定对象——能复制，就等于已经交付。流式把「正在写」和「写完了」叠在同一块正文里，中间没有状态跳变。下游动作（复制、插入文档、调用下一段流程）若在流尚未结束时可用，半成品会按成品的通道离开。
生成还可能在后续 token 里改前面的意思：补上否定、改掉数量、加上条件。半成品在语义上不是终稿的前缀，有时是会被推翻的中间句。把它当结果，等于把一次尚未闭合的承诺发出去。
怎么研究
在流式过程的前、中、后三个时刻开放或不开放复制/采用。记录过早采用的比例、采用内容与终稿的差异、发出后是否造成需要撤回的错误。自变量：结束前动作是否可用、是否有「尚未完成」的状态声明。因变量：过早交付率、终稿差异、撤回次数。
差异要按语义编码（被推翻、被补充、仅未写完），不要只报字数差。被推翻比未写完危害大。
边界
用户只要扫一眼方向（「是不是在写代码而不是在闲聊」），看半成品不等于当终稿。明确的「先用这一截」是有意识的截断，前提是界面把截断说成截断。一次性短回复在流结束前几乎没有可复制的稳定句，这条的对象变小。这条不处理等待好不好熬，也不处理中止之后那一截归谁。
怎么落地
- 复制、插入、发送、进入下一步，默认在流结束前不可用；要提前用，必须经过「就用目前这一截」的确认。
- 在流未结束时不要把文本放进「结果」区域的视觉地位；结果区在结束后再生效。
- 若后续 token 可能推翻已写内容，在采用前打出「后面还可能改前面」的警告。
- 验证：在流到一半时看复制是否仍可点。可点且有人把半截发出去，半成品已经被当成终稿。再看发出内容与终稿是否语义一致——不一致就是这条失败的现场。