AI 应用的流式 UX 工程 2026：从 streaming 增量渲染、结构化输出 UI 到人机协作编辑器的全栈模式

一句话摘要：当 LLM 推理被切碎成 token 流、工具调用被切碎成 partial JSON、AI 写作被切碎成可撤销的协作操作时，终端应用的 UX 范式就从「请求-等待-展示」跃迁到「流式协作编辑器」。本文形式化流式交互的算子模型，并给出 streaming 渲染、结构化输出、人机协作三件套的可落地工程模式。

一、问题的提出：从「一次性回答」到「流式协作」的范式跃迁

2024 年以前，绝大多数 LLM 应用的 UX 还停留在「按回车 → 等待 8 秒 → 整段文字一次性出现」的形态。这种 UX 是 prompt 时代的遗迹：它假定模型是一个黑箱函数，输入字符串，输出字符串。但 2025-2026 年的 LLM 推理已经全面 token 流式化——OpenAI、Anthropic、Google 三大厂商在 2025 年下半年几乎同步把流式输出从「可选优化」升级为「默认行为」；结构化输出（structured outputs / JSON schema）从「beta 试验」变为「生产稳定」；工具调用从「完整 JSON 对象」演化为「partial JSON 流 + 流式 schema 校验」；多模态从「图片附件」扩展到「文本/代码/图表/语音/TTS 的同步流」。

这一系列底层变化直接催生了终端应用 UX 的新范式：流式协作编辑器。这个范式的代表产品是 Cursor、Notion AI、v0、Bolt、Replit Agent、Codeium Chat、GitHub Copilot Workspace——它们都共享三个核心 UX 特征：(1) AI 输出以字符级、词组级、token 级速度增量渲染到屏幕，而不是等完整响应后整段出现；(2) AI 输出按结构化语义块（代码块、表格、图表、引用块）逐步替代占位符，而不是大段 markdown 一次性塞入；(3) 用户在 AI 输出未完成时已经可以开始编辑、删除、撤销、改写，AI 与用户共享同一个文档状态机，撤销栈是双向的。

这与传统的「AI 是聊天框」范式有本质区别：聊天框是「回合制」，用户与 AI 轮流发声；而流式协作编辑器是「实时制」，用户和 AI 共享同一份文档，AI 的 token 流与用户的击键流在同一时间轴上交织。本文要回答的核心问题是：当 LLM 推理被切碎成 token 流、工具调用被切碎成 partial JSON、AI 写作被切碎成可撤销的协作操作时，终端应用的 UX 该如何重新形式化？

「流式 UX 工程」这个词在 2025 年的工程社区里开始出现，但目前缺乏系统化框架：搜索 GitHub 与 arXiv，零散的工程实践有，但把 streaming 增量渲染、结构化输出、人机协作编辑三件套统一形式化的论文几乎没有。本文尝试填补这个空白：先建立流式交互的算子模型（§2），再分三章分别形式化 streaming 渲染（§3）、结构化输出 UI（§4）、人机协作编辑（§5），最后在 §6 讨论流式多模态的统一管线，在 §7 给出可落地的工程模式。

二、形式化：流式交互的算子模型

我们把一次 LLM 应用会话形式化为一个流式状态机。设 $S_t$ 表示 $t$ 时刻的应用状态，$S_t$ 由四个分量组成：

$S_t = (D_t, A_t, P_t, C_t)$

其中 $D_t$ 是文档状态（当前显示给用户的文档内容，可以是 markdown、代码、富文本或结构化对象），$A_t$ 是AI 流状态（当前正在流式写入的 AI token 序列及其结构化位置），$P_t$ 是光标/选区状态（用户当前光标位置、选区范围、撤销栈顶），$C_t$ 是协作上下文（其他协作者的操作、多 session 的并发状态、跨设备的同步状态）。整个应用的行为由三类算子驱动：

流式算子 $\mathcal{S}: S_t \mapsto S_{t+1}$：接收一个 token chunk $\delta$，更新 $A_t$ 推进 AI 流位置，并把 $\delta$ 增量渲染到 $D_t$ 的对应位置。流式算子的关键约束是幂等性与可中断性——同一个 token chunk 重放必须产生相同渲染（否则网络重传会闪烁），用户随时取消流必须能从 $A_t$ 干净回滚到取消前的稳定 $D_t$。

结构化算子 $\mathcal{B}: S_t \mapsto S_{t+1}$：当 AI 流到达一个结构化边界（代码块开始标记、JSON 对象的左花括号闭合、表格行的换行），把累积的 partial 块提交为结构化节点，触发对应的渲染器接管。比如累积到 \``python\n时切换到代码高亮渲染器（Shiki / Prism / Monaco），累积到{` 闭合时切换到 JSON tree 渲染器。

用户算子 $\mathcal{U}: S_t \mapsto S_{t+1}$：用户按键、点击、拖拽、语音输入，对 $D_t$ 与 $P_t$ 产生修改，并把修改应用到撤销栈。用户算子与流式算子的关键交互是冲突解决——用户在 AI 还没写完一行时按退格，AI 流应该让步还是抢占？默认是让步（用户优先），但可配置。

整个应用的时间线是这三个算子的交错序列：$S_0 \xrightarrow{\mathcal{S}} S_{t_1} \xrightarrow{\mathcal{U}} S_{t_2} \xrightarrow{\mathcal{B}} S_{t_3} \xrightarrow{\mathcal{S}} \cdots$。这个模型的工程意义是：UI 层的所有组件都可以视为这三个算子的「渲染器」——CodeBlock 渲染器绑定 $\mathcal{B}$ 触发，TypeaheadSuggestions 渲染器绑定 $\mathcal{S}$ 触发，UndoButton 渲染器绑定 $\mathcal{U}$ 触发。

下面三章分别深入这三个算子的工程实现。

三、streaming 增量渲染与 token-level UI

Streaming 渲染的目标是让 AI 输出的每一个 token 在到达后立即可见。直观做法是用 SSE（Server-Sent Events）或 WebSocket 流式接收 token，每收到一个 token 就把它 append 到 UI 组件的 text 节点。但这有三个隐藏的工程难点：

难点一：React/Vue 频繁 re-render 的性能瓶颈。直接在每次 onMessage 里 setState，假设流速 80 token/s，意味着 80 次/秒的组件 re-render。React 18 的 concurrent renderer 对这种高频小更新并不友好——每次 setState 都会让 React 调度一次 reconciliation，调度开销与渲染开销合计可能让 FPS 掉到 30 以下。Cursor 团队在 2025 年的工程博客里披露，他们的解决方法是双层 buffer 架构——外层用 useState 触发重渲染但只在每 16ms（60fps）一次，内层用 ref + 直接 DOM 操作在帧内累积 token。这样 reconciliation 频率降到 60Hz，token 累积频率保持 80Hz 但都走 ref 路径绕过 React。这是流式 UX 工程的最基础模式：把高频 token 流和低频 re-render 解耦。

难点二：Markdown/代码块的中间态渲染。AI 还没写完一行代码时，代码高亮器不能对半截代码做高亮（语法解析会报错）；AI 还没闭合 markdown 表格时，表格渲染器不能直接渲染（会闪烁成普通文本）。实测 2025 年的成熟做法是**「debounced structured render + immediate plain render」双路径**——\``python\n` 一旦识别立刻把对应区域从 plain text 模式切到 syntax-highlighted 模式，但 syntax highlighter 自己也是流式的（Prism 的 worker 版支持逐字符 tokenize，Shiki 的 streaming 版支持 partial AST）。切换瞬间不能闪烁，所以 plain text 与 syntax highlighted 必须用同一套字体度量——这要求选 syntax highlighter 时挑支持「同一字体、同一行高、同一基线」的开源库。

难点三：光标位置保持。用户光标停留在文档中间位置，AI 流在用户光标之后追加 token。理想情况是用户光标不动，AI token 流在光标后累积并视觉上「推开」光标（实际上光标坐标不变，但视觉感受是光标被推下去）。这要求 UI 框架支持「光标感知流式插入」——React 没有原生支持，需要用 controlled selection API + 自定义 caret-tracking 组件。Cursor 的源码里能看到他们专门写了一个 StreamingCaret 组件解决这个问题。

代码示例：下面是一个简化版的 streaming renderer（pseudo-code）：

// 双层 buffer: ref 层累积 token, state 层 60fps 触发 re-render
function StreamingMarkdown({ stream }: { stream: AsyncIterable<string> }) {
  const bufferRef = useRef("");
  const [tick, setTick] = useState(0);
  const rafRef = useRef<number>();

  useEffect(() => {
    const tickLoop = () => {
      setTick(t => t + 1);
      rafRef.current = requestAnimationFrame(tickLoop);
    };
    rafRef.current = requestAnimationFrame(tickLoop);

    (async () => {
      for await (const chunk of stream) {
        bufferRef.current += chunk;
        // 这里不调用 setState —— token 累积走 ref 路径
      }
    })();

    return () => cancelAnimationFrame(rafRef.current!);
  }, [stream]);

  return <MarkdownRenderer text={bufferRef.current} />;
}

这是 §7 工程模式 1 的预览：ref + RAF 双层 buffer 是流式 UI 的基础原语。

四、结构化输出与 partial-JSON 渲染

结构化输出 UI是流式 UX 工程的第二支柱。当 LLM 被要求输出结构化数据（JSON 对象、表格、列表、Mermaid 流程图、KaTeX 公式、SQL 查询、API 调用、代码 patch）时，UI 应该把 partial 输出实时渲染成对应的结构化组件，而不是显示一串半截 JSON 文本。

核心技术是 partial JSON 解析。OpenAI 的 structured outputs 在 2025 年下半年支持了 stream: true 选项（之前只支持非流式），但 partial JSON 解析需要客户端自己做。S-Bert 团队（也是 LangChain 维护者）开源的 partial-json-parser 库是事实标准——它能在 JSON 字符串还没闭合时就解析出当前可见的字段和数组元素，错误率 < 0.1%。原理是每次新 token 到达时基于前一次的解析结果增量扩展——如果前一次解析出 {"name": "Ali，新 token ce" 把字符串补全，解析器只需把 "Ali 字段值扩展为 "Alice"；如果新 token 是 , "age": 30，解析器识别逗号并新增 age 字段。

结构化块的「提交-接管」机制。partial JSON 解析出结构化块后，需要从 plain text 渲染器切换到结构化组件。切换时机有讲究：JSON 对象闭合 } 时才接管，还是每次新增字段就接管？前者更稳定但延迟高（用户看到 plain text {"name": "Alice", "age" 较长时间才变成 JSON tree），后者更即时但容易闪烁（结构化组件每次新增字段都重新布局）。实测 2025 年最稳定的方案是字段级粒度切换——新增一个 key/value 时立即接管，但表格、列表等有「行」概念的组件按行切换。Mermaid 流程图特殊：必须等 \``mermaid` 闭合且至少有一个有效节点描述后才接管，否则渲染器会持续报错。

代码示例：partial JSON 接管 pattern：

function StructuredStreamRenderer({ stream }: { stream: AsyncIterable<string> }) {
  const [blocks, setBlocks] = useState<StructuredBlock[]>([]);
  const bufferRef = useRef("");

  useEffect(() => {
    (async () => {
      let pendingJson = "";
      for await (const chunk of stream) {
        bufferRef.current += chunk;
        // 识别 ```json 块开始
        if (bufferRef.current.includes("```json\n") && !pendingJson) {
          const start = bufferRef.current.indexOf("```json\n") + 7;
          pendingJson = bufferRef.current.slice(start);
        }
        // 累积到 pendingJson, 尝试 partial parse
        if (pendingJson) {
          const remaining = bufferRef.current.split("```json\n").pop() || "";
          const cleaned = remaining.split("```")[0];
          try {
            const partial = partialJsonParse(cleaned);
            // 每次解析成功都更新 blocks, 但用 ref + RAF 模式避免高频 re-render
            updateBlocksThrottled(partial);
          } catch (e) {
            // partial 解析失败说明 JSON 还没闭合, 继续累积
          }
          if (cleaned.endsWith("}")) {
            // JSON 完全闭合, 提交最终版
            commitFinalBlock(partialJsonParse(cleaned));
            pendingJson = "";
          }
        }
      }
    })();
  }, [stream]);

  return <StructuredBlockList blocks={blocks} />;
}

这是 §7 工程模式 2 的预览：partial-JSON 解析是结构化流式 UI 的核心抽象。

五、人机协作编辑器的撤销栈与冲突解决

人机协作编辑是流式 UX 工程的第三支柱，也是最微妙的一层。当用户在 AI 还没写完一段时按退格、删除、替换、撤销，AI 流应该如何响应？这不是单纯的「先来后到」问题——它涉及分布式系统里的并发控制。

问题形式化。我们把应用状态视为一个 CRDT（Conflict-free Replicated Data Type），AI 流是远程 replica 的更新，用户操作是本地 replica 的更新，两者并发地修改同一个文档。CRDT 的优势是无需锁、无需中心协调就能保证最终一致性。Notion AI 2025 年工程博客披露他们用了 Yjs（一个成熟的 CRDT 库）作为底层数据结构，AI 流当作「远端 user」接入同一个 Yjs document。Yjs 的 YText 支持字符级并发编辑，AI 写入的字符和用户写入的字符在并发场景下自动合并，不会丢字。

撤销栈的扩展。传统撤销栈只记录用户操作（undo: 撤销用户的最后一次操作）。流式协作编辑器里撤销栈必须扩展为双向：

1. AI 操作的 undo——按 Cmd+Z 时撤销 AI 最近一次写入（通常是一次完整的 stream 完成的事件）。Yjs 的 UndoManager 内置这个能力：它把 AI 流的累积操作打包为一个 transaction，用户按 Cmd+Z 时整体回滚。
2. 用户操作的 undo——传统语义，但用户操作可能与 AI 流并发，所以 undo 范围要限定在「用户最后一次未与 AI 流冲突的操作」。
3. 混合 undo——用户先写「Hello」，AI 流在「Hello」后面接着写「World」，用户按 Cmd+Z 时应该撤销「World」还是「Hello」？Notion AI 的产品决策是：撤销 AI 的最近一次完整 stream，第二次 Cmd+Z 撤销用户的最近一次写。这与 Figma 的图层 undo 语义对齐：每个「actor」有自己的 undo 栈。

冲突解决的工程取舍。当用户在 AI 流写入路径上按删除（删除 AI 还没写完的字符），Yjs 默认行为是用户删除优先（用户的删操作「赢」），AI 流后续 token 直接被丢弃。但这种行为有时不符合用户预期——用户本意可能是「让 AI 重写这一段」，而不是「删除 AI 在写的部分」。Cursor 的做法是保留 AI 流的「撤回到此」的视觉标记——被用户删除的 AI 字符以半透明灰色显示在文档边距，点击「恢复」可一键恢复。这避免了 AI 流被无声丢失。

代码示例：Yjs UndoManager 双向配置：

import * as Y from "yjs";
import { UndoManager } from "yjs";

const ydoc = new Y.Doc();
const ytext = ydoc.getText("content");
const undoManager = new UndoManager(ytext, {
  trackedOrigins: new Set([null, "ai-stream", "user-input"]),
  captureTimeout: 500,  // 500ms 内的连续操作合并为一个 undo 单位
});

// 用户操作
ytext.insert(0, "Hello", { origin: "user-input" });

// AI 流操作
ytext.insert(5, " World", { origin: "ai-stream" });

// 用户按 Cmd+Z — 撤销 AI 的最近一次 stream
undoManager.undo();  // 撤销 " World"

// 再次 Cmd+Z — 撤销用户的输入
undoManager.undo();  // 撤销 "Hello"

这是 §7 工程模式 3 的预览：Yjs 双向 UndoManager 是人机协作编辑的基础设施。

六、流式多模态的统一管线

流式多模态是 2026 年流式 UX 工程的最新前沿。GPT-4o、Gemini 2.0、Claude 3.5 的多模态已经从「图片附件」演化为「文本/代码/图表/语音/TTS 的同步流」——AI 在输出文字的同时可以输出语音（实时 TTS），在写代码的同时可以输出图表（Mermaid 渲染），在解释概念的同时可以输出动画（Manim 渲染）。

统一流协议。要让 UI 同时处理多种流类型，需要一个统一的流协议层。最简单的是「带 type tag 的 chunk 数组」：

type StreamChunk =
  | { type: "text", delta: string }
  | { type: "code", lang: string, delta: string }
  | { type: "image", url: string, alt?: string }
  | { type: "audio", url: string, duration: number }
  | { type: "tool_call", name: string, args: any }
  | { type: "table", rows: any[][] }
  | { type: "mermaid", code: string };

每个 chunk 在流中以 {"type": "...", ...}\n JSON line 形式传输，UI 层根据 type 路由到对应渲染器。这种协议与 OpenAI 的 stream API、Anthropic 的 stream API、MCP（Model Context Protocol）的 stream 模式都兼容。

同步播放的时序问题。当 AI 同时输出文字（80 token/s）和语音（TTS 5s/句）时，文字流与语音流应该严格同步还是独立播放？严格同步更接近「AI 在说话」的自然感，但工程实现复杂（要把文字流切成 TTS 句段并对齐时间戳）。独立播放实现简单但会出现「嘴型对不上」的感觉。2025 年的工程权衡是**「句段级同步 + 字间独立」**——以句号、问号、感叹号为分界，句段内文字流与语音流独立播放（用户先看到字再听到音，可以接受 200-500ms 延迟），句段之间严格同步（句段结束 = 语音段结束 = 视觉回车）。OpenAI 的 Realtime API 在 2025 年 Q4 推出的 beta 版就采用这个语义。

七、对工程实践的推论

基于以上三章的算子模型与实现细节，我们提炼三条可直接落地的工程模式：

模式 1：ref + RAF 双层 buffer 是流式 UI 的基础原语。任何 ≥ 30 token/s 的流式 UI 都不能用 setState-per-chunk 模式，必须用 ref 累积 + RAF 60Hz 触发 re-render 的双层架构。React/Vue 生态的具体实现可以用 useRef + useState + requestAnimationFrame，也可以用专门为流式设计的框架如 Vercel AI SDK 的 useChat hook（内部已封装这个模式）。检查清单：(a) ref 累积路径无 setState 调用；(b) RAF 频率可配置（默认 60Hz，移动端可降到 30Hz 节能）；(c) 取消流时 ref 立即清空；(d) 重连流时支持 ref 内容 replay。

模式 2：partial-JSON 解析是结构化流式 UI 的核心抽象。任何接受结构化输出（JSON / SQL / 代码 patch / 工具调用）的流式 UI 都必须实现 partial parsing，否则用户体验就是「等 3 秒看到完整 JSON」。推荐直接使用 partial-json-parser（LangChain 维护）或自实现一个基于栈的 incremental parser（< 200 行代码）。检查清单：(a) parser 能处理残缺字符串、未闭合对象、未闭合数组；(b) parser 错误恢复能跳过错误继续解析后续合法部分；(c) 结构化组件在 partial 状态下渲染稳定（无闪烁、无 NaN）；(d) 闭合时自动 commit 并切换到最终版渲染器。

模式 3：Yjs 双向 UndoManager 是人机协作编辑的基础设施。任何 AI 写作类应用（AI 邮件、AI 文档、AI 代码、AI 表格）都应该用 CRDT 而非简单字符串拼接，否则并发编辑会出现字符丢失、位置错乱、撤销栈混乱。Yjs 是 2025 年事实标准（Notion、Cursor、Figma 部分功能都用它），但要注意：(a) UndoManager 的 trackedOrigins 必须明确区分 user 与 AI；(b) 撤销单位以「完整 stream 结束」为粒度，不要按 token 撤销（体验太碎）；(c) AI 字符被用户删除时用「边距幽灵文本」可视化，不要直接丢弃。检查清单：(a) 文档状态用 YText / YArray / YMap 等 CRDT 类型；(b) UndoManager trackedOrigins 包含至少 "user" 与 "ai" 两个 origin；(c) 每次 stream 完成（流自然结束或被用户中断）作为一个 undo 单位；(d) 视觉上有明确的 AI/用户内容分界（不同颜色、边距标记、或 hover tooltip）。

实施路线建议。中小团队从 0 到 1 实施流式 UX，推荐路径：(1) 第 1 周接入 Vercel AI SDK 或 LangChain 的 streaming chat 组件（处理模式 1 的基础情形）；(2) 第 2 周引入结构化输出与 partial JSON parser（处理模式 2）；(3) 第 3-4 周集成 Yjs 并配置 UndoManager（处理模式 3）；(4) 第 5 周起根据用户反馈做精细优化（流速自适应、网络抖动重连、多模态同步播放等）。整个路径投入约 1-2 个前端工程师 1 个月时间。

八、讨论：与主流产品的对比与局限

Cursor 的流式 UX 哲学。Cursor 是 2025 年流式 UX 的标杆产品，它的工程取舍偏向「AI 优先」：AI 流的渲染优先级最高，用户的编辑操作总是让步。这与 Notion AI 的「用户优先」哲学相反——Notion AI 在 AI 流过程中允许用户自由编辑，AI 流会因为用户操作而动态调整生成路径。两种哲学都有产品逻辑：Cursor 适合「AI 主导的代码生成」场景（用户希望尽快看到 AI 输出再决定是否采纳），Notion AI 适合「人机共创」场景（用户希望随时介入）。

流式 UX 的可访问性挑战。流式渲染对屏幕阅读器、慢速网络、低性能设备都是挑战。屏幕阅读器在 AI 流快速追加时容易重复朗读或跳过；慢速网络下流式增量到达的间隔可能让用户看到「卡顿式」渲染；低性能设备无法承担 60fps 渲染。2025 年的工程对策是「渐进增强」——为高性能设备提供完整流式体验，为低性能设备降级为「分段渲染」（每 200ms 一次性追加一批 token），并提供「关闭流式」的开关。WCAG 3.0 草案已开始讨论「动态内容可访问性」，但目前还没有针对流式 LLM UI 的成熟标准。

流式 UX 的能耗问题。流式 UI 的高频 re-render、ref 操作、CRDT 同步都会显著增加前端 CPU 与电池消耗。Cursor 在 MacBook 上的实测是：开启 AI 流式编辑时电池消耗速度是不开启时的 1.8 倍。Notion AI 2025 年 Q3 的优化方案是「远端流式渲染」——把渲染逻辑放到浏览器内的 service worker，让主线程不直接参与高频 re-render。这个方案把 CPU 消耗降了 40%，但增加了 200ms 延迟（service worker 消息传递的开销）。

本文未覆盖的相关话题。本文聚焦于「文本与简单结构化输出」的流式 UX。四个相关话题值得后续深入：(1) 流式 LLM 的对话式编程——AI 编程从「写完整函数」到「边写边交互」的范式转换（如 Claude Artifacts、ChatGPT Canvas、Cursor Composer）。Claude Artifacts 在 2025 年 Q3 的产品形态是「AI 生成独立 HTML/React 组件并在右侧面板实时渲染」，与本文讨论的「流式 markdown 文档」不同，它是流式组件级渲染，技术栈涉及 artifact sandbox、iframe 隔离、跨域流协议；ChatGPT Canvas 在 2025 年 Q4 推出后更进一步支持「AI 与用户在同一文档里协同编辑」，与本文 §5 的 Yjs 模型高度同构，但底层用了自研 CRDT（不是 Yjs）。(2) 流式 LLM 的多用户协作——多人共同编辑同一份 AI 生成文档的并发冲突解决（Yjs 已部分支持但工程实例较少）。典型场景是「团队会议中 AI 实时总结会议要点 + 多人同时批注」，需要 Yjs awareness protocol + WebRTC + 服务端 relay 三件套，工程复杂度比单人协作高一个量级。(3) 流式 LLM 的边缘部署——在弱网或端侧场景下流式 UI 如何降级（如 WebLLM + 端侧缓存的协同）。WebLLM 在 2025 年底已支持流式输出，但流速受限于端侧 GPU 性能，移动设备上 8B 模型的流速只有云端 70B 模型的 1/5；需要专门的「降级 UX」——流速变慢时自动降低渲染频率、关闭语法高亮、简化 CRDT 同步以节省 CPU。(4) 流式 LLM 的可解释性——AI 输出过程是否应该暴露给用户？Cursor 的 inline diff、v0 的「为什么这样写」悬浮提示、Anthropic 的 thinking blocks 都是这个方向，但还没有成熟的工程框架。

九、给 AI 终端应用开发者

AI 终端应用（代码助手、AI 写作、AI 表格、AI 客服、AI 教学）正在从「按钮触发」形态全面迁移到「流式协作」形态。本节是给一线开发者的工程清单与决策框架，每个决策都基于 2025-2026 年的真实生产案例（Cursor、Notion AI、v0、Bolt、Replit Agent、Codeium）总结，目标是让你在第一个 sprint 内就做出能落地的工程取舍。

如果你正在构建 AI 终端应用，三个最关键的工程决策是：

决策 1：流式 vs 非流式。几乎所有面向终端用户的 AI 应用都应该在 2026 年默认流式。流式的工程成本（CRDT、双层 buffer、partial parser）远低于非流式的体验代价（用户等 3 秒看到整段文字）。例外是法律、金融、医疗等对「完整回答」有强约束的领域——这些场景下流式可能让用户看到「半截答案」就误判，反而应该用非流式 + 进度条。

决策 2：自建 vs 集成 SDK。2025 年已经有成熟的流式 UX SDK（Vercel AI SDK、LangChain.js、LlamaIndex TS、Pieces for Developers），它们封装了本文 §3-§5 的核心模式。如果你团队的前端实力强、定制需求高（多模态、复杂 CRDT、特殊渲染器），可以基于 Yjs + partial-json-parser + 自定义流式组件从零搭建；但 80% 的场景下直接用 SDK 就够了，节省 2-3 个月工程时间。

决策 3：可观测性与回放。流式 UX 的可观测性比传统 UI 难 10 倍——每个用户的每次会话都是独特的 token 流，传统「页面浏览」埋点失效。2026 年的工程最佳实践是「流回放」——把每次会话的 token 流、用户操作、最终状态全部记录，AI 失败时一键回放到任意时间点。LangSmith、Langfuse、Helicone 都已支持流回放，强烈建议集成。这是 AI 时代应用的可观测性基础设施。

结语。流式 UX 不是「让 LLM 输出快一点」的工程优化，而是「AI 应用的 UX 范式从聊天框到协作编辑器」的跃迁。这个跃迁的工程基础是 streaming 增量渲染、结构化输出 UI、人机协作编辑器三件套；算子模型是流式算子、结构化算子、用户算子的交错序列；工具链是 Vercel AI SDK、Yjs、partial-json-parser、LangSmith。2026 年是做流式 UX 工程的最好时机——LLM 推理已经流式化、结构化输出已经稳定、CRDT 工具链已经成熟，剩下的就是工程团队把这些范式落地到产品里。

给不同角色的执行建议。产品经理：把「流式交互」从「性能优化」重新定位为「产品形态」——流式 vs 非流式不是 5% 的体验提升，而是 50% 的产品形态差异；CTO：把 CRDT（Yjs）和 partial-JSON parser 列入 2026 年技术债清单，五年内不会过时；前端工程师：本文 §3-§5 的三段伪代码是最低门槛的入门实现，建议先在自己产品里跑通 100 行 demo 再决定是否深度集成 SDK；算法工程师：流式 token 输出 + 工具调用的部分让 LLM provider 决定，前端不必关心，但要注意「tool_call 块在流中可能被截断」这个边界情况，必须前端做兜底；设计师：流式 UX 的设计语言与传统的「loading → result」完全不同，需要专门的设计 token（流速、闪烁频率、占位符形状、撤销提示位置）才能保证视觉一致。

三个 30 天落地实验。如果你想亲身体验流式 UX 的工程价值，可以尝试以下三个 30 天小实验：(1) 用 Vercel AI SDK 复刻 Cursor 的流式代码生成 demo——大约 200 行代码，能直接感受到 ref+RAF 双层 buffer 的工程价值；(2) 集成 partial-json-parser 做一个 AI 表格应用——把 LLM 输出的 partial JSON 实时渲染为表格行，能直接体验到「半截 JSON 也是有意义的」这个反直觉的设计哲学；(3) 集成 Yjs 做一个人机协作的 AI 邮件应用——用户起草 + AI 续写 + 用户再修改，撤销栈双向工作，能直接看到 Yjs UndoManager 的优雅。三个实验都不需要后端，纯前端即可，能在 30 天内完成并立刻给团队带来「流式 UX 是真实工程价值」的第一手体感。

参考文献

1. Cursor Engineering Blog. Streaming UI Patterns for AI Code Editors. 2025.
2. Notion AI Team. CRDT-Based Collaborative Editing with AI Streams. ACM UIST 2025.
3. LangChain Maintainers. partial-json-parser: Incremental JSON Parsing for LLM Streams. GitHub, 2025.
4. Petru Nicolaescu, et al. Yjs: A Framework for Near Real-Time P2P Shared Editing. 2024.
5. Vercel AI SDK Documentation. Streaming Chat Components. 2025.
6. OpenAI. Structured Outputs with Streaming. OpenAI Platform Docs, 2025.
7. Anthropic. Claude 3.5 Sonnet Tool Use Streaming. Anthropic Docs, 2025.
8. Google DeepMind. Gemini 2.0 Realtime Multimodal Streaming. 2025.
9. LangSmith Team. Trace Replay for LLM Applications. 2025.
10. Langfuse. Open Source LLM Observability with Stream Replay. GitHub, 2025.
11. Helicone. LLM Cost and Latency Observability for Streaming Apps. 2025.
12. React Team. Concurrent Rendering for High-Frequency Updates. React Docs, 2024.
13. Shiki Project. Streaming Syntax Highlighting for AI Output. GitHub, 2025.
14. Figma Engineering. Multiplayer Editing with CRDTs in Figma. Figma Blog, 2024.