你有没有想过一个问题:大模型已经能写代码、能推理、能调用工具,几乎所有 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 安全设计的基石。从对话框到对话应用讲到这里,jboltai 想表达的核心理念就清楚了:AI 产品的未来,不应该是一个更聪明的输入框,而是一个能动态生长的界面。想象一下,当你问 AI帮我规划这周的项目排期,它给你的不是一段文字说明,而是一个可以拖拽的甘特图;当你问这几款手机怎么选,它给你的是一组可对比的参数卡片和一个能勾选的决策表;当你问我的订单到哪了,它直接渲染出物流时间线。这些不是科幻,这是 jboltai 现在就能做到的事。区别只在于,你是否愿意把那最后一公里修通。jboltai 已经把路铺好了,就等用户走上来。写在最后大模型的军备竞赛已经卷到了天上,参数从几十亿涨到几万亿,推理能力一年一个台阶。但回过头看用户真正用到的界面,十年没变过。jboltai 相信,下一波 AI 产品的差异化,不在模型本身,而在模型输出如何被呈现和交互。谁先把这最后一公里铺好,谁就能让用户真正感受到智能二字。如果你也在做 AI 产品,正在被模型输出怎么变成界面这个问题困扰,不妨看看 jboltai 的思路。这条路 jboltai 已经蹚过一遍了,jboltai 的经验可以帮你省下大量试错成本。—— jboltai,为 AI 对话而生。