AI 对话的最后一公里:为什么大模型输出还停留在纯文本-深圳市維司達科技有限公司

你有没有想过一个问题:大模型已经能写代码、能推理、能调用工具,几乎所有 AI 产品的对话界面却依然是上世纪的形态——一个气泡,里面装着一坨 Markdown 文本。

我们花了无数精力把模型做得更聪明,却几乎没人认真想过:模型产出的东西,到底应该长什么样。这篇文章就聊这件事,也是我们在做 jboltai 时反复纠结的核心命题。

一个被忽视的事实:输出形态限制了交互天花板

先说一个 jboltai 团队早就在内部达成的共识——模型的能力和用户能感知到的能力,中间隔着一层"渲染"。

举个最常见的例子。你让 AI 帮你做一份销售数据对比,模型其实完全有能力把数字算清楚,但它能给你的只有一段文字:

text

一季度北京区销售额 120 万,上海区 98 万,环比分别增长 15% 和下降 3%……

用户读到这段话,要在脑子里自己重建那张图。这不是模型不行,是输出通道太窄。在 jboltai 的实践中我们发现,只要把同一个结果换成一张柱状图加一张对比卡片,用户的理解速度能快三倍以上,信任度也显著提升。

这就是 jboltai 想解决的第一类问题:让模型的输出从"可读"变成"可看、可点、可交互"。jboltai 把它当成产品级目标,而不只是个渲染玩具。

为什么大家还在用 Markdown 凑合

很多人会问,不是有 Markdown 吗,渲染成富文本不就行了?

在 jboltai 看来,Markdown 是上一个时代的产物,它解决的是"文档"问题,不是"界面"问题。它有三个根本性的硬伤:

第一,没有交互。Markdown 写不出一个能点击的按钮、一个能提交的表单、一个能切换的 Tab。而真实的 AI 对话里,用户常常需要"边聊边操作"——确认订单、勾选选项、触发动作。这些 Markdown 全都做不到。

第二,不是为流式设计的。大模型是一个 token 一个 token 吐出来的,Markdown 的语法结构(尤其是表格、代码块)在没说完之前是残缺的、无法渲染的。你在 jboltai 早期版本里就踩过这个坑:用户盯着屏幕看模型一个字一个字蹦,前半段表格是乱的,直到最后一个|出来才成形。这种体验是灾难级的。

第三,结构太松散。Markdown 没有组件的概念,你没法说"这是一个卡片""这是一个数据面板"。模型输出的可预测性差,前端也很难做稳定的布局。

正是这三个痛点,直接催生了 jboltai 要做的事:为 AI 重新设计一套输出协议。

最后一公里到底卡在哪

我们把从"模型生成内容"到"用户看到界面"这条链路,称为 AI 对话的最后一公里。jboltai 认为,这条路上目前堵着三辆车。

第一辆:协议缺失。大家都在各自发明轮子。有的团队让模型直接吐 HTML(危险,会 XSS),有的让它吐 JSON 再用固定模板套(僵化,模板写死了就不够灵活),有的干脆只支持文本。整个行业没有一个统一的、为流式而生的 UI 描述标准。jboltai 想做的,就是把这个标准立起来。

第二辆:渲染层落后。即便有了描述方式,前端的渲染也得跟上。传统的渲染是"拿到完整数据再画",但流式场景是"边来边画"。jboltai 在底层用了一个基于状态机的增量解析器,模型吐第一个字符,前端就开始画 DOM,真正做到所见即所得。

第三辆:安全顾虑。让模型生成可执行的界面,听起来就很危险。如果模型吐一段<script>,整页就废了。jboltai 的做法是,事件用命名引用而不是代码注入——模型只能说"这个按钮点了调用叫 submit 的处理器",真正的处理器在前端用registerHandler预先注册。模型永远碰不到真实代码。这套机制是 jboltai 安全设计的基石。