L3.11.2abort from early content is streaming’s main gain设计研究
用户可据早期内容提前中止，中止权是流式的主要收益
别名: 提前中止 · 中止权 · abort as payoff
概念解释
开头三个命题已经写错对象。人按停，后面两分钟的 token 没有生成，额度没烧，错误稿没有继续变长。流式值不值得做，主要看这件事能不能发生。中止权作为收益（abort as payoff）指的是：早期信号若不能变成停，信号只是让人更焦虑地看完；能变成停，流式才把浪费切掉。
停得了，是控件存在。这里问的是：停是不是流式被做出来的那个理由。
机制
早期信号的决策空间是继续 / 停 / 改提示。三个动作里，停对墙钟和额度的节省最大，也最依赖过程可见。整块出现时，人只能在结束后丢弃，成本已经付完。流式把「付完再丢」改成「看见征兆就停机」。若停不了，过程可见反而延长了与错误稿共处的时间，收益为负。
所以中止不是流式的附属安全功能，是把早期信号变现的那一步。没有这一步，早期信号没有产品出口。
怎么研究
设置前部即可判断失败的生成。比较：流式无中止、流式有中止、整块出现后可丢弃。因变量：浪费的 token / 时间、错误稿最终长度、改提示前的延迟。自变量：中止是否在早期就可用、征兆清晰度。
节省的时间和额度是主收益指标。满意度不能替代：有人会「看着错误出完」却评流式更爽，那是等待感，不是这条的收益。
边界
用户要的就是看过程（解题演示），中止不是目标，收益在别处。征兆不可靠、乱按停会切掉本会成功的生成时，中止权的净收益下降，需要「停 / 再等一句」的缓冲。中止后半截的归属未定时，人会不敢停——收益被下游的归属问题吃掉。这条不处理停的控件怎么画，只处理停是不是价值所在。
怎么落地
- 把中止放在早期信号能被读到的同一时刻、同一视区，让「看见错 → 停」中间没有找控件的间隙。
- 用中止率 × 平均节省时长来衡量流式是否在工作，不要用「感觉更快」。
- 跑偏模式（错语言、错对象）应在产品里当成功案例：人停得越早越好，而不是生成得越完整越好。
- 验证：前部必错的任务，看有多少人在总时长的前三分之一停掉。几乎没人停，中止权没有把早期信号变现。