用过 ChatGPT 的人都知道那种体验------答案像打字一样一个个蹦出来，不必干等。纯文本的流式输出，今天已经不算新鲜事了。但问题在于：真实的 AI 应用远不止纯文本。
当 AI 需要返回表格、表单、图表、卡片等结构化 UI 时，"流式渲染"就从一个简单的技术细节，变成了一个棘手的工程难题。
一、结构化内容的"流式困境"
举一个最典型的场景：AI 智能问数（ChatBI）。
用户问了一句"查询上季度各区域的销售额排名"，AI 需要返回一张包含多行多列的表格。在传统方案中，这张表格只有等到后端完整拼装好全部 HTML 或 JSON 之后，才能一次性渲染到页面上。
问题出在哪里？
- Markdown 方案：Markdown 本身不支持复杂表格操作（排序、合并单元格等），更不用说表单、按钮这些交互组件了。而且 Markdown 的流式解析有天然缺陷------表格必须等整行数据到齐才能渲染，中间态会显示一堆残缺的竖线。
- JSON 方案：先返回完整的 JSON 结构，前端再解析渲染。流式传输 JSON 的问题更大------如果数据被截断在中间，JSON 直接解析失败，之前的全部白费。
- HTML 方案：虽然可以逐块发送，但 HTML 标签嵌套深、体积大，AI 生成大量 HTML 的 Token 消耗极高，而且未闭合的标签会导致页面布局错乱。
三种主流方案，在流式场景下都有硬伤。这就是行业长期存在的矛盾：大模型天生是逐 Token 流式输出的，但主流的 UI 描述格式都不是为流式设计的。
二、流式渲染的真正要求
要想真正实现"结构化 UI 的流式渲染"，技术方案需要同时满足几个条件：
- 首 Token 即渲染：收到第一个字符就要能开始工作，而不是等一个完整的"片段"
- 增量解析：不需要等完整语法块到达，边读边解析，发现可渲染的单元就立即渲染
- 容错性：Token 在传输中可能被截断在任意位置，截断态不能导致解析崩溃或布局错乱
- Token 效率：AI 生成 UI 描述的 Token 数量要尽量少，生成速度才不会成为瓶颈
这四个条件，任何一个做不到，流式渲染就会在真实场景中"露馅"。
三、TokUI 的思路：极简 DSL + 字符级状态机
TokUI 是一个专门为 AI 场景设计的流式 UI 引擎，它的核心思路是用一套极简的 DSL 来描述 UI 组件，然后通过字符级状态机实现增量解析和渲染。
具体来说：
1. 极简 DSL，降低 Token 消耗
TokUI 的 DSL 语法非常紧凑。渲染同样一个表格，HTML 可能需要几百个 Token，TokUI DSL 只需要几十个------Token 节省 90% 以上。这意味着 AI 生成 UI 描述的速度更快，用户感知到的"第一屏出现时间"更短。
2. 字符级增量解析
TokUI 前端内置了一个字符状态机（Character State Machine）。它不是等一段完整的 DSL 语法到达后再解析，而是逐字符读取------每收到一个字符，状态机就推进一步，一旦识别出一个可渲染的组件片段，就立即生成 DOM 节点。
这就像在读一行代码的时候，每读到一个分号就知道上一句结束了，而不是等整段代码写完才回头解析。
3. 截断友好设计
DSL 语法的设计保证了即使一个 Token 在任意位置被截断，也不会产生语法歧义。下一个 Token 到达后，解析自然继续。中间态可能是"半成品"，但绝不会是"错误品"。
4. 零依赖，前端即插即用
TokUI 前端没有任何第三方依赖，纯浏览器原生 API 实现。不管是 React 项目还是 Vue 项目，甚至是一个纯静态 HTML 页面，都可以直接引入使用，不冲突。
NPM 包：@jboltai/tokui，也可以通过 jsDelivr CDN 直接引入。
四、流式渲染背后的工程挑战
流式渲染看起来简单，真正落地时会碰到不少工程细节问题：
性能问题
大模型生成速度通常在每秒 20-60 个 Token 之间。每个 Token 到达都可能触发 DOM 的更新操作。如果不做优化，高频的 DOM 更新会导致页面频繁重排（reflow）和重绘（repaint），反而造成卡顿。
TokUI 的做法是把"解析"和"渲染"解耦------状态机负责增量解析，渲染层做批量更新，避免每个字符都触发一次 DOM 操作。
传输通道选择
流式传输主要有两种方式：SSE（Server-Sent Events） 和 WebSocket。SSE 是单向的，适合"后端推、前端收"的场景，接入简单；WebSocket 是双向的，适合需要前端实时交互的场景。TokUI 两种都支持，可以根据实际需求选择。
与后端的解耦
TokUI 的设计哲学是前端只负责接收 DSL 流并渲染，不关心后端用的是什么模型、什么框架。后端只要能以 SSE 或 WebSocket 的方式推送 TokUI DSL 格式的文本流，前端就能正常工作。这个解耦设计让 TokUI 可以和任何 AI 后端配合使用。
五、从"一次性渲染"到"流式渲染"的范式转变
在传统的 Web 开发中，页面的渲染模式一直是"请求-等待-一次性呈现"。即使有了 AJAX，本质上也是"等数据到齐再渲染"。
AI 时代的到来正在改变这个范式。大模型的流式输出特性，让"边生成、边传输、边渲染"成为可能。这不仅是一种技术优化，更是一种交互范式的转变------用户不再是等待一个"结果"，而是在观察一个"过程"。
从用户体验的角度看，这种转变的意义很大。心理学研究表明，当用户感知到"事情正在发生"时，等待的焦虑感会大幅降低------即使实际完成时间差不多。
TokUI 出自向量空间的 JBoltAI 生态体系。JBoltAI 是一个企业级 Java AI 应用框架，TokUI 在其中承担前端呈现层的角色，与后端的 AI 推理、知识检索、Agent 编排等能力配合，形成完整的 AI 应用技术栈。
流式渲染并不是一个新概念------视频流、音频流早就这么做了。但在 AI 生成结构化 UI 这个场景中，它确实是一个刚刚被认真对待的课题。TokUI 的 DSL 加字符状态机方案，是这个方向上一个值得关注的实践。随着 AI 应用的 UI 越来越复杂，"如何让结构化内容也能像文本一样流式呈现"，会越来越成为前端工程师需要面对的核心问题。