用户点发送后立刻看到第一个字，能边读边判断方向；不对就早点停止。首字快改善的是体验，不是算力——但用户体感「快得多」。
AI 与提示 · 模型与输出
流式输出Streaming
流式输出（streaming）把生成中的 delta / chunk 分片送达（常见传输是 SSE 或流式 HTTP），首字延迟低、用户能边出边看，也能取消并保留已收到的部分；它改善等待体验，不等于模型总生成更快。
同一个回复气泡：边到边看，也能中途停
客服回答已经送来第一个 SSE 片段。继续接收时文字会拼进同一个气泡；停止会保留半截回复并标为未完成；重新生成则沿用原问题恢复。
离开这页，只记这几条
上面面板已经把每件事演示过一遍，这里只给它们命名，方便复述。
- 流式 = 分片送达
- 模型边生成，服务端边把 delta / chunk 推给前端（SSE 或流式 HTTP）。一个片段可能包含一个或多个 token；用户不用等完整答案才看到开头。
- 批量 = 一次性返回
- 服务端算完整段再一次性返回 JSON。用户在末尾才看到任何字。两种模式算的是同一段话，总时长几乎相同。
- 首字延迟，不是总算力
- 流式赢在「感知延迟」——用户立刻看到开头，能早判断方向、少焦虑。它不会让模型算得更快，只是把等待切成可见的小段。
- 底层是 SSE / chunked
- HTTP 长连接：服务端持续把 token 当 chunk 推下来，前端边收边 decode。不是 WebSocket——SSE 是单向推送，足够聊天这种「服务端说、客户端听」的场景。
- 前端逐片段拼接
- 每收到一个 chunk 就增量 decode、追加到同一个输出区。要处理跨 chunk 的字节边界、结束信号（关闭 loading、跑校验）和错误中断。
- 可中断、可取消
- 流式过程中用户可点停止：前端用 AbortController 取消读取，后端也应把取消继续传给模型服务；已生成内容保留并标记「中断」。实际停止生成与计费规则以服务商为准。
什么时候用流式、怎么用
出现下面这些信号时，流式多半值得开；反之就该关。
- 聊天 / 长文生成：用户要即时反馈，首字快能显著降低焦虑、让用户早判断方向——开流式。
- 结构化 JSON 校验：要完整对象才能 parse 和校验，边收边拼容易出错——关流式，等完整结果。
- 短输出 / 计算密集：输出就几个字，或后处理比生成本身还久，首字优势消失——不必流式。
- 怎么用：后端开 stream: true（SSE 或 chunked），前端用 ReadableStream / EventSource 读 chunk，逐个 decode 追加；用 AbortController 支持取消；收到结束信号后关闭 loading 再跑格式 / 引用校验。
同一目标，差一个关键选择
都要给客服工单写回复。差别只在返回方式。
订单字段要完整对象才能 parse；边收边拼容易拿到半截 JSON 报错。这种场景该等完整结构再校验，流式只增加复杂度不增加价值。
快速自测
产品要在结账页生成一张「订单详情 JSON」给前端渲染校验。该用流式还是批量？为什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。