L1.12.2streaming shortens time-to-first-token, not duration设计研究
流式输出缩短的是首字时间而非总时长，改变的是感知而非事实
别名: 首字时间 · 感知加速 · TTFT not wall time
概念解释
字一个个出来，人觉得「已经开始了」。墙上的钟并没有走得更快：最后一枚 token 的时刻几乎等于非流式的完成时刻，有时更晚（因为要维持长连接）。流式改的是感知，不是工期（streaming shortens time-to-first-token, not duration）。把它卖成「更快」，是在用首字时间冒充总时长。
定位延迟在哪一档之后，这条说明流式动的是档里的哪一根针。
机制
等待被切成「什么都没有」和「已经有东西」。人主要惩罚前者。流式把惩罚窗口从总时长压缩到首字时间，总时长的惩罚被阅读过程吃掉——人在等的同时也在读。这是注意力会计，不是加速。工程上为了流式还可能加缓冲、重试、限制批处理，工期偶尔更差。
营销和进度文案若写「秒回」，用户会拿总时长去对表。对不上，感知收益被「你们说了更快」的落空抵消。
怎么研究
同一完成时间，流式 vs. 一次性给出。测：感知等待、满意度、实际完成时刻、是否报告「更快」。自变量：首字时间、速率是否抖动、是否在结束时给「已全部完成」。因变量：感知与事实的差、提前离开率。
要报两个钟：首字和完成。只报感知等待会让流式永远赢。
边界
人要的就是边读边等（长文草稿），感知收益是真目标，不必为「工期没变」道歉，但文案仍不该说更快。任务以完成时刻为准（要下载整份、要跑校验），流式没有帮到任务，只帮到情绪。弱网下流式的首字也可能不短。这条不讨论人会不会对半成品下判断。
怎么落地
- 内部指标把 TTFT 和总时长分开。对外只说「先看到字」，不说「更快完成」。
- 结束必须有完成态，避免人把「还在出字」当成「还要很久」或反过来。
- 不要为了流式把总时长明显拉长。感知收益填不满被拉长的事实。
- 验证：问「这次比不流式快在哪」。答「整个跑完更快」而墙上的钟没有，文案在撒谎。再并排两条同等总时长、一条流式的记录，看感知差是否只来自首字。