AI 对话为什么还在用 Markdown：流式富 UI 才是
如果你用过市面上的 AI 对话产品，大概率有过这样的体验：问 AI 一个数据分析问题，等了十几秒后，屏幕上开始缓缓铺开一段密密麻麻的 Markdown 文字。表格歪歪扭扭、图表无法渲染、交互按钮缺失。你只能用肉眼在文字堆里找信息。
这不是个别产品的体验问题。这是整个 AI 行业正在面临的一个结构性瓶颈——模型能力在飞速进化，但前端 UI 的表达方式还停留在 2015 年。
一、Markdown 不是为 AI 设计的
Markdown 最初被发明出来，是为了让人类用最简单的纯文本写出结构化文档。它的核心设计目标有两个：人类可读、轻量标记。
这个设计在博客写作、文档编写的场景下非常优秀。但 AI 对话和文档写作是完全不同的场景。AI 对话有四个 Markdown 根本无法满足的需求：
第一，AI 的输出是流式的，但 Markdown 不是。模型逐 Token 吐出文字，但 Markdown 的很多结构必须等到完整闭合才能正确渲染。一个表格在最后一行到达之前，渲染出来是错乱的。用户盯着半截表格等十几秒，体验极差。
第二，AI 对话需要交互组件，但 Markdown 不支持。用户问完问题后可能需要填一个表单、点击一个按钮、勾选一个选项。Markdown 是纯展示性标记语言，不具备任何交互能力。想让 AI 回复里出现一个可提交的表单，只能靠开发者自己在前端硬编码。
第三，AI 对话需要实时数据更新，但 Markdown 是静态的。Agent 调用了一个工具、完成了一步推理、更新了一个指标——这些动态变化需要在界面上实时反映。Markdown 渲染完就是一张静态"照片"，没有机制做局部更新。
第四，AI 对话的 Token 成本敏感，但 Markdown 的表达力有限。想在 Markdown 里描述一个稍微复杂的组件——比如一个带斑马纹的表格加一张折线图——需要大量嵌套语法和 HTML 内联，Token 消耗不低。
根因判断：Markdown 不是做错了，而是用错了场景。它是为人类写文档设计的，不是为 AI 生成界面设计的。把 Markdown 当作 AI 对话的唯一输出格式，就像用 Word 来做网页——能用，但极其别扭。
二、AI 产品的 UI 瓶颈：三层错配
把视角拉高，AI 对话产品的 UI 瓶颈本质上是三层错配叠加的结果。
第一层错配：模型输出节奏和前端渲染节奏不同步。模型是逐字符流式输出的，这是大语言模型的根本特性。但当前主流的前端渲染方案——无论是 Markdown 解析器还是 JSON 驱动的组件渲染——都假设输入是完整的、一次性的。两种节奏不对齐，用户就只能等。
这个问题不是"前端做得不够快"能解决的。它需要一个从协议层就为流式设计的全新方案。后端输出的内容格式本身必须是"流式安全的"——任何位置被切断都能正确处理，下一块到达后从断点继续。
第二层错配：内容描述能力和交互需求不匹配。模型已经能调用工具、执行多步任务、生成代码并预览结果。但把这些能力展示给用户的方式，几乎只有一种：写成一段文字描述。用户看不到 Agent 调用了哪个工具、推理过程是什么、执行到哪一步。
这不是模型能力不够，而是缺少一种"让 AI 描述界面"的语言。HTML 可以描述界面但太重、Token 消耗太大。JSON 可以描述结构但不能流式。Markdown 轻量但没有交互能力。
第三层错配：安全需求和渲染灵活性矛盾。AI 生成的内容直接渲染到用户浏览器，XSS 是头号风险。如果让 AI 直接输出 HTML，一次被污染的 prompt 就能在用户浏览器里执行恶意脚本。但如果为了安全只允许输出纯文本，交互能力就归零了。
传统方案在这两者之间摇摆：要么牺牲安全换交互（直接渲染 HTML），要么牺牲交互换安全（只渲染 Markdown）。两者之间缺少一个"既安全又可交互"的中间层。
三、从 Token 到 UI：一个被忽视的工程命题
这三层错配指向同一个结论：AI 时代需要一种全新的 UI 表达介质，它必须同时满足三个条件——流式友好、可交互、安全。
这个命题可以浓缩为一句话：From Token to UI——从 AI 输出的 Token 直接到可交互的富 UI，中间不应该存在那道鸿沟。
这意味着需要一套领域特定语言，它的设计目标不是"让人类写文档更方便"，而是"让 AI 用最少的 Token 描述出最丰富的界面"。它还需要一个前端渲染引擎，它的设计目标不是"接收完整数据后渲染"，而是"收到第一个字符就开始画"。
JBoltAI 团队开源的 TokUI 就是在做这件事。它用一套极简的 DSL 让后端以字符串形式描述组件，经 SSE 流式推送到前端，前端基于状态机对任意切片的输入进行增量解析，首个有效标签到达时就开始绘制真实 DOM。零运行时依赖，MIT 协议，内置 150+ 组件。
但 TokUI 的意义不在于它是一个"更好的组件库"。它的核心价值在于提出了一种新的思路：UI 的描述权可以交给 AI，渲染权交还给浏览器，中间用一套轻量协议连接。
四、流式富 UI 会改变什么
如果 AI 对话从"文字墙"进化到"流式富 UI"，产品体验会发生三个根本性变化。
变化一：用户从"读"变成"用"。今天用户和 AI 对话的核心动作是"读"——读文字、读代码、读表格。富 UI 之后，用户可以"用"——在对话中直接操作图表、填写表单、确认操作。AI 从"回答问题的工具"变成"在对话中构建微型应用的引擎"。
变化二：Agent 透明度从"黑盒"变成"白盒"。Agent 执行多步任务时，用户不再面对一个转圈等待。每一步的推理过程、工具调用、状态变化都通过专属组件实时展示。用户能看到完整的决策链路，信任度直接提升。
变化三：AI 产品的开发模式从"前端堆组件"变成"后端描述界面"。传统模式下，每新增一个 AI 功能，前端团队就要开发一套对应的组件。富 UI 协议模式下，后端直接输出界面描述，前端引擎自动渲染。前端开发工作量从"每个功能都要做"变成"做好引擎就够了"。
五、一个行业判断
AI 产品的竞争正在从"谁的模型更强"转向"谁的体验更好"。模型能力的差距在缩小——开源模型和商用模型的差距已经从十倍缩小到两三倍以内，未来还会继续缩小。
但产品体验的差距在拉大。同样是调用一个 Agent，有的产品让用户盯着文字墙等三十秒，有的产品让用户实时看到推理过程、工具调用和结果可视化。两种体验之间的差距，比模型能力的差距大得多。
从 Token 到 UI 这条路上，谁先解决"AI 输出到富界面"的工程闭环，谁就掌握了 AI 产品的体验壁垒。这不是前端工程的问题，而是 AI 应用层基础设施的问题——它需要一个新的协议、一个新的渲染引擎、一套新的组件语义。
TokUI 正是在这个方向上的一次开源实践。它不是终点，但它指出了一个被行业忽视的事实：AI 时代的 UI，不应该还是 Markdown