L3.06.3abort must be available throughout streaming设计研究
需支持随时中止
别名: 随时中止 · 生成可停 · stop generation
概念解释
代码已经跑偏进另一门语言，字还在往外冒。界面只有转圈，没有停。用户要么等它自己结束，要么关整个会话。随时中止（abort throughout streaming）要求：生成一旦开始占用时间与注意，人就必须能在任意时刻把它停掉，而不必等到自然结束，也不必拆掉整次会话。
中止是不是流式的主要收益、停下来的那一截算不算成果，是后面的问题。这里只要求：停得了。
机制
流式把人钉在屏幕前：注意被占用，等待被填满，离开的成本上升。若此时没有停，占用就从「降低等待感」翻成「强制看完」。跑偏、敏感内容、已经够用、网络在烧额度，都需要一个与「再等一会」相反的动作。没有这个动作，流式在交互上是单向的：系统决定何时结束，人只能接收。
中止还必须是生成过程中的一等控件。藏在取消会话、刷新页面、杀掉进程里，等于不提供——那些动作的粒度是整次任务，不是这一次生成。
怎么研究
设置明显跑偏或过长的生成，比较：无中止、中止藏在菜单、中止始终可见。因变量：是否停得下来、停下来的时刻、误用中止（本想复制却点了停）的次数、停不成而关会话的比例。自变量：控件位置、流开始后多久出现、停是否立即不再吐 token。
「立即不再吐」要单独测。按钮在、token 还在出，对用户来说等于没停。
边界
生成在百毫秒内结束，中止窗口小到点不到，不必为它单独做控件，但一旦超过可感知等待，控件就要在。批量离线任务的「停」是取消队列，不是流式中止，两者不要做成同一个按钮。误触中止的代价若极高（不可恢复的长任务），需要确认；日常对话生成不需要。这条不处理停下来之后文本归谁可用，也不把中止宣传成流式的主要价值。
怎么落地
- 流式一开始就把中止放在与输入框同级的位置，不要等跑偏之后再去菜单里找。
- 按下之后在一个反馈周期内停止新 token，并明确已经停下，而不是按钮变灰、字还在出。
- 中止不要绑定「清空会话」或「关闭页面」。粒度是这一次生成。
- 验证：故意让生成跑偏，计时到人把输出停住。找不到按钮、点了还在出、或只能靠刷新，都是未支持随时中止。