前几天我在整理一份关于交互范式演进的资料时看到一句被截断的话。前半句写得锋芒毕露界面将变成超快速的实时扩散模型there is a future where interfaces are ultrafast live diffusion models后半句刚写到软件也是超快速的 L…… 就断了。断在哪个词上作者没有交代可能需要她自己来补全。但这句话本身就足够当作一道思考题来用了。我特意把这句话放在草稿箱里放了两天没有急着写。越看越觉得它不是在描述一个“AI 能生成界面”的功能而是在描述一种全新的界面本体论界面不再是被预先写好的组件拼盘不再由开发者提前决定按钮的位置、卡片的大小、导航的结构而是在用户抵达的那一刻由模型实时“算”出来的画面。这是一种从“写界面”到“算界面”的范式迁移。不过先别急着欢呼。真正让我警觉的是后半句里那个关键词ultrafast。如果只是让扩散模型生成界面今天已经有不少工具能做到如果要在用户点击、滚动、输入的过程中让界面像活物一样连续重算还能让用户感觉不到延迟这件事的难度就完全不在一个量级上。这篇博客想说的就是这种未来离我们到底还有多远以及如果想动手实验应该从哪条最小路径切入。1. 这句半截话指向的不只是一个“模型生成 UI”的功能1.1 先拆解一下这句话可能的两层含义“接口就是超快的实时扩散模型”这个说法的字面意思很诱人但也容易造成误读。我认为至少有两种完全不同的理解方式。第一种理解是工具层面的我们让扩散模型来生成界面的视觉草稿设计师或开发者在生成结果之上继续加工。这本质上是把扩散模型当成一个“更聪明的画图工具”产出的是 UI 截图、视觉稿或者切图素材。这种理解下业务逻辑依然是传统的前端代码来实现扩散模型只是辅助创意。第二种理解是本体层面的界面本身就是一个扩散模型。也就是说页面上的每一个视觉元素、每一次布局变化、每一种状态切换都是模型基于当前语境、用户意图和数据状态持续推理出来的结果。界面不是一个静态文件而是一个连续生成的实时过程。原话里出现了 live这个词在两种理解之间有本质差别。按第一种理解live 至多意味着“生成速度够快能现场出图”按第二种理解live 意味着界面是不间断运行着的生成循环——用户的鼠标、键盘、数据流的每一次扰动都会触发一次新的视觉推理。如果这句话真的要描述一个新的未来我认为指向第二种理解的可能性更大。1.2 界面已经历过三次迁移第四次可能不再是“更大屏”把这句话放进界面演进的历史里会更容易看出它的分量。人机界面从命令行走向图形界面是一次巨大的迁移从固定桌面走向触屏和移动端是第二次从原生控件走向 Web 化和组件化开发是第三次。这三次迁移有一个共同特点界面结构本身在某个时刻就被设计死了。你写下一个 Button 组件它在页面加载后就是那个样子数据变化改变的是文案和颜色状态但按钮的轮廓、位置、交互语义都已经由代码预先定义。界面的“壳”是确定的变化的只有“内容”。如果扩散模型成为界面本身情况就反过来了。壳和内容同时成为生成对象。同一个任务昨天可能需要用户先点“高级设置”再展开一个抽屉今天模型根据用户的历史行为可能会把这几个参数直接平铺在第一屏。在这个意义上界面不再是一个“被打开的文件”而是一个每次运行都会重新求解的“函数”。这才是那句截断的话真正让人兴奋的地方——它把界面从设计系统的成品变成了上下文环境的即时解。2. 为什么偏偏是“扩散模型”而不是“大语言模型生成前端代码”2.1 代码生成是把界面先翻译回去扩散模型是直接表达界面如果目标是让 AI 自动产出界面过去几年大家更熟悉的路径是大语言模型生成前端代码你告诉它要一个登录页它输出一段 React 或 HTML然后交给浏览器渲染。这条路径是可行的但它本质上是在“用语言描述界面”。语言是一种很优秀的抽象却也天然会丢失信息。你可能遇到过这种情况让模型生成一个表格页面代码结构完全正确但最终渲染出来的间距、比例、视觉重心总有那么一股“模板感”。这不是模型笨而是用语言去描述一个高度视觉化的对象中间有一层绕不过去的损耗。你得先想象一个完整的视觉画面再把它拆成文字指令再由代码还原成画面像一台复印机反复扫描总会丢细节。扩散模型的生成路径完全不同。它从噪声出发在去除噪声的过程中直接对像素分布建模天然擅长表达“整体构图是否和谐”“视觉重心在哪”“色彩之间是否冲突”这一类很难用文字描述的属性。所以它更适合生成那些没有固定模板、依赖视觉直觉、需要连续统一样式的界面。这可能是原话选择 diffusion 而不是 language model 的深层原因。2.2 “算出来的界面”和“写出来的界面”差异不在于劳动量有人可能会问界面由组件拼成还是由模型生成不都是给人看的有什么区别区别很大。组件化界面是一种离散系统元素与元素之间有清晰的边界、类型和层叠关系模型生成的界面是一种连续系统视觉元素之间的过渡是渐变的布局可以随着语境被连续地拉伸、压缩、重组。在离散系统里想让界面适配更多场景就得增加组件数量和排列条件所以前端越来越重设计系统越来越庞大。在连续系统里没有“需要预先准备多少种卡片”这个问题模型只要理解“卡片”这个概念就可以根据当前宽度、内容长度和数据重要程度现场算出它长什么样。这背后是一种完全不同的工程哲学——你维护的不再是一个组件库而是一组生成约束。当然这里有一个我必须提醒的边界上面这套逻辑目前更多是研究者和产品构想者在讨论的方向。真实产品里组件化带来的可预测性、可测试性和可访问性仍然是极其珍贵的资产。扩散模型走向界面不是要消灭组件而是要重新定义组件在什么层级上存在。3. ultrafast 才是真正的分水岭而不是“能不能生成界面”3.1 同样叫“生成界面”tolerable latency 差着几个数量级我见过不少演示视频里面的扩散模型能生成非常惊艳的界面图。如果只是生成一张静态图哪怕是几分钟的等待对设计稿场景也没有什么问题但如果它是用户正在使用的实体界面延迟的标准就完全变了。传统界面里从用户点击到视觉反馈出现行业普遍的经验阈值是 100 毫秒左右如果要做流畅的动画和拖拽这个数字还要更低逼近帧级。也就是说如果要让 diffusion 界面真正做到 live模型必须在一次点击的响应时间内完成至少一次完整的眼前区域的推理和渲染。注意这里说的不是“未来可以做到”而是要在用户没有感知的情况下持续做到。我在一个常见的技术讨论框架里把“界面生成”按可容忍延迟分成了三个层次放在一起看会更清楚生成场景可容忍延迟核心难点离可用状态离线设计稿生成秒级到分钟级画面美感、排版合理、文字准确已基本可用实时界面预览百毫秒级指令响应、布局自适应、跨尺寸稳定部分可用帧级交互界面16 到 100 毫秒连续状态、局部更新、时序一致性还在实验前沿很多人把注意力放在第一层以为“AI 能生成好看的界面”就等于“AI 界面时代来了”。但真正的分水岭在第三层。从秒级到帧级不是一个简单的“升级显卡”问题而是要从模型架构、推理策略和渲染管线整体重塑才能跨越的鸿沟。3.2 逼近实时工程上可能要同时处理三件事如果只是堆算力cost 会高到没有产品能承受所以工程上通常要考虑三条路。第一条是让单次推理更快。常见的努力方向包括更小的模型、更紧凑的隐空间、蒸馏出更少步数的采样器、量化推理以及为特定设备定制算子。这个方向解决的是“一次生成要多久”。第二条是避免整屏重算。真实的界面里大量区域在交互时是不变的你可能只是点了一下收藏按钮页面 99% 的视觉内容都应该保持原样只有图标和状态需要变化。如果每次交互都重新扩散整张画面既浪费算力也容易造成视觉闪烁。可行的思路是用图像编辑或局部重绘的方式来更新变化区域同时保留背景和上下文。这也是从“生成一张图”到“维护一个持续演变的画布”的重要转变。第三条是渐进式生成。理想情况下模型可以先输出一个模糊但正确的大结构再在剩余的可用时间内逐步细化细节。这样做的好处是哪怕时间不够用户看到的也是一个结构正确的画面而不是等了半秒后突然蹦出完整结果。这类策略在实时渲染里很常见放到扩散模型里也值得认真考虑。把这三条路放在一起看会更明白为什么 origin 句子里要把 ultrafast 放在 live 前面。没有 ultrafastlive 只能停留在 demo 状态。4. 界面变成“算出来”的东西之后会重新分配三类人的工作4.1 前端工程师从搭积木变成定义生成空间如果界面真的走向动态生成前端工程师的日常职责会有一次明显的位移。今天我们在写组件、维护状态管理、调试样式覆盖将来可能变成定义“生成空间的约束”哪些区域允许模型自由发挥哪些区域必须保持业务确定性哪些交互操作必须落在真实的事件系统上。那时候调试工具的形态也会变。今天你打开浏览器开发者工具看到的是 DOM 树和 CSS 规则将来你可能要看到的是模型的输入条件、种子参数、上下文窗口和一次生成推理的完整轨迹。于是有一个新的问题会浮出水面当界面变成概率过程的输出后我们怎么复制 bug这是一个现在很少有人认真回答的问题。4.2 设计师从“画稿子的人”变成“定义生成指纹的人”有一种担心是界面都能让模型生成了设计师岂不是要失业我倾向于认为短期看设计师反而会更重要但角色会变化。今天的设计师交付的是静态稿和设计规范在动态生成体系里他们交付的将是一个更抽象的东西一组美学先验、一套约束规则、一些“什么情况下绝不允许出现”的反面样本以及针对异常情况的降级策略。说得好理解一点设计师不再是给每个页面画脸的人而是定义“这个产品长得像谁”的人。品牌感、语气、视觉识别度这些属性很难指望一个通用扩散模型自动具备必须由人通过精心设计的数据和约束“教”给模型。这就像摄影术出现之后画家没有全部失业但肖像画师的任务从“画得像”转向“怎么拍才像、怎么选角度、怎么布光”。界面设计也会经历类似的迁移。4.3 产品经理从画线框图变成编排生成条件当界面可以根据语境实时变化产品设计里所谓“一个页面只解决一个核心任务”的静态逻辑会面临挑战。未来的交互流程更像是条件编排不同状态、不同用户、不同使用场景下系统会计算出最适合当前任务的界面形态。产品经理的核心能力也会从“画线框图讲故事”转向“定义哪些上下文值得被界面响应、哪些信息不应干扰生成结果”。不过这里有一个容易导致翻车的诱惑不能让所有东西都随着用户变化。如果一个页面对不同人呈现完全不同的结构团队将无法讨论它、测试它、迭代它。产品上通常需要保留一部分稳定框架动态生成的内容应集中在真正产生差异化价值的部分而不是为了变而变。5. 真正可用之前至少有五个绕不开的坑要逐个跳5.1 界面幻觉比文本幻觉更危险大语言模型的幻觉表现为一本正经地编造事实扩散模型的幻觉则表现为把按钮画得精致漂亮但你点下去没有任何反应。这是 AI 原生界面路线最大的风险之一。更危险的情况是模型“画错了语义”把一个危险操作画成了温和的灰色按钮或者把一个只读信息区域画得像可编辑区域。文本输错字还能通过上下文猜出来界面语义错了用户可能直接产生误操作。所以任何严肃产品都不能直接让扩散模型对“操作入口”和“确认/取消”这类核心控件做开放式生成必须要求模型生成结果先经过语义校验再由事件层接管。5.2 一致性问题同一个产品不能每天长一张新脸静态界面的优点之一是稳定。用户今天学会的流程明天依然有效同一品牌在不同页面上有统一的视觉语言。扩散模型是概率系统同样的 prompt不同时间可能生成不同结果哪怕是同一个用户刷新两次页面也可能看到布局上的细微差异。如果不加控制就会变成“每次打开都像换了一个 App”。要让界面在保持生成性的同时维持一致性通常需要把“稳定性”作为显式目标去设计生成流程而不是祈祷模型自己稳定。这包括同一个页面绑定相对稳定的语言向量或种子空间变化只在用户真正发出变更意图时才发生允许改变的是装饰层和内容层不允许改变的是操作逻辑和关键布局。5.3 可访问性和自动化测试会变得艰难现代 Web 能支持读屏软件、键盘导航、自动化测试依赖的是背后的语义结构。如果界面只是模型输出的像素读屏软件怎么知道这是一个按钮、那是一个链接自动化测试怎么知道某个元素在不在预期位置这不是不能解决但要在设计生成架构时就把语义导出作为一等公民模型在生成像素的同时也要同步生成一份结构语义层告诉辅助工具和测试框架这里有什么、它是什么、它做什么。如果只是把 UI 当图片交给浏览器这条路走不远。5.4 状态与数据绑定界面画得再好看数据错了就是事故界面不只是视觉。一个列表页如果展示的数据是错的哪怕生成得再精美也是产品事故。动态界面必须解决一个关键问题模型负责生成外观但外观背后的数据状态必须由确定的业务逻辑控制。这里我最关心的是两个场景空状态和异常状态。模型很擅长画“理想状态下的漂亮界面”但空列表、加载失败、权限不足、余额为零这类边角状态如果也用概率生成几乎必然出错。开发这类状态时我反而建议全部走确定性逻辑不要让模型自由发挥。5.5 责任归属和成本边界不能模糊最后一个坑偏治理层面。当界面是写出来的出现 bug 可以追溯到某一行代码当界面是模型算出来的问题出自训练数据、输入上下文、还是某一次随机采样定位会困难得多。真出了安全事故谁对那个不可预测的界面负责这类问题不会因为技术炫酷就消失。同时成本也必须重新估算。一次生成界面所消耗的计算量远高于将一个预写好的页面渲染到屏幕上。不管模型怎么压缩如果每个用户每次交互都要触发一次扩散推理服务端成本都很可观。这也是为什么我判断第一批真正可用的生成式界面大概率会先把任务卸载到端侧或者只应用于低成本、低风险、高视觉增益的场景。6. 现在就想动手实验可以先走这条最小验证路径6.1 把“生成一张界面图”和“生成一个界面系统”分开处理这是所有实验的第一步也是最重要的认知准备。用扩散模型生成一两张好看的界面草图现在并不困难难的是让这个结果稳定复现、可交互、可接入真实数据、能通过可访问性审查。我见过很多团队的误区兴致勃勃地跑通了一个 text-to-UI 的 demo然后直接把一堆“界面图”发给研发说照着实现。这样的流程本质上还是把 diffusion 当成“快速产线框图”的辅助工具没有触及真正的交互生成。这不是错但它还没有进入原话想要描述的那个方向。6.2 一个务实的实验流程先不碰实时先验证可控边界如果环境允许我会建议这样组织一次最小实验第一步固定一个相对简单的业务场景比如“任务管理首页”而不是直接挑战复杂的后台系统。第二步准备该场景的结构化约束必须出现哪些核心信息、哪些操作不允许被视觉弱化、有哪些明确的品牌色和间距规则。第三步使用可控扩散模型产出一批候选界面人工评估三个方面视觉是否协调、语义是否正确、不同次数的生成结果差异有多大。第四步只对“通过评估的布局”做二次加工把关键控件替换成真实组件完成数据绑定。第五步把结果做一轮可用性和可访问性检查重点不是好不好看而是读屏软件能否识别、键盘能否操作、异常状态是否有兜底。这套流程看起来保守但它的价值是逼你先回答“生成层的边界在哪里”。如果这一步都过不了一上来就追求实时生成、帧级更新只会收获一堆难以维护的技术债。6.3 实验期可以重点记录的四类指标把实验做成能积累经验的事而不是简单玩票。我建议每轮实验至少记录四类东西生成稳定性同一 prompt 重复十次布局发生明显变化的比例是多少。语义准确率生成的界面里按钮是否出现在预期位置、状态是否表达正确。调试可解释性当生成结果出问题时是否能通过输入、参数和采样过程定位原因。性价比对比传统组件渲染多消耗了多少计算资源换来了多少体验增量。在没有这批数据之前不要急着提“用 diffusion 替换现有界面”这种口号。先把小实验做扎实比任何宏大叙事都有用。7. 我的判断真正会到来的不是“全网实时生成”而是“分层协作”7.1 静态界面和动态生成会在不同层级共存很多讨论把“动态生成界面”和“传统组件界面”摆成对立关系好像一方必须取代另一方。我不太认同这种二元叙事。更现实的分层是底层的操作入口、数据展示、关键流程继续由确定性组件负责因为它们要求可预测和可审计上层的视觉风格、个性化布局、低风险装饰、探索性体验则逐渐交给生成模型现场计算。二者之间通过结构语义层相连。这个判断的底层原因是任何产品都存在稳定性刚需和灵活性需求两个方向。稳定性刚需由静态组件承担成本最低灵活性需求由生成模型承担价值最高。非要把所有界面都变成实时扩散模型等于放弃了系统最宝贵的可预测性那不是聪明是浪漫过了头。7.2 我会用什么指标来判断这个方向正在成熟当发生下面三件事时我会认为生成式界面真正走到了可以用在产品里的临界点第一同一业务界面重复生成一百次语义和布局关键差异小到用户无法察觉第二系统可以主动告诉使用者“为什么当前这个界面长这样”而不是只给一个无解释的结果第三一次局部界面更新的综合成本下降到与传统接口请求同一个数量级。三个指标衡量的是稳定性、可解释性和成本缺一个都会让 live diffusion 界面停留在演示层面。在那一天到来之前我认为最值得投入的不是追逐“全界面实时生成”的视觉奇观而是先积累一套约束和评估方法什么值得生成什么必须确定怎么判断生成结果是否越界。这套方法本身才是从“写界面”走向“算界面”这个过程中真正会沉淀下来的资产。7.3 回到那句截断的话现在再看开头那句没写完的英文我的理解已经清楚了它不是在预言某一天所有软件界面都会变成动态扩散的画面而是在提醒我们当界面从一块预先雕刻好的石板变成一股持续流动的溪流时我们围绕“确定性假设”建立起来的一整套开发、设计、测试和产品体系都需要被重新审视一遍。至于后半句 software is ultrafast L…… 到底缺一个什么词也许并不重要。因为真正重要的是“L”后面那种没有写出来的可能性——它说明未来还开着口还没有被定义死而定义权在正在阅读这篇文章的人手里。