大模型产品最常见的交互仍然是一个输入框加一串文字。即使回答里加入卡片、表格和引用，用户面对的依旧是一份被动阅读的结果，而不是为当前任务量身生成的工具。
Google Research 试验的生成式 UI 更进一步：收到提示后，模型会结合工具、系统指令和后处理逻辑，直接输出一张可以操作的网页。不同问题不必挤进同一套预制组件，答案可以变成穿搭建议页、分形教学器、数学练习游戏，甚至一段围绕当前主题组织起来的微型应用。
三个由模型为不同任务生成的交互界面：穿搭建议、分形教学与数学练习
这不是“给聊天回复换一个皮肤”。它把模型的输出对象从内容，扩大成了内容、结构、交互和视觉表达的组合。
#从生成回答变成生成体验
传统聊天界面在模型回答之后才决定如何展示：文字放进段落，代码放进代码块，数据最多转成一张固定样式的表格。展示层理解的是内容类型，却不了解用户此刻究竟想完成什么。
生成式 UI 把这项决定交给了推理过程。模型可以针对意图选择最合适的表达方式：需要比较时生成可筛选的列表，需要理解空间关系时生成可操作的图，需要练习时生成带反馈的交互题目。
因此，同一个模型不再只回答“是什么”，还要判断“用户接下来应该如何看、选、试和行动”。界面成为推理结果的一部分。
#页面是怎样现场生成的
Google 的实现以 Gemini 3 Pro 为核心。用户提示首先进入模型，模型可以调用搜索等工具补充信息，并遵循细致的系统指令决定页面结构。输出不是某个固定组件的参数，而是完整的 HTML、CSS 与 JavaScript；后处理器再检查和修整结果，最终交给浏览器运行。
Google 生成式 UI 的处理链路：提示、模型、工具、系统指令和后处理器共同生成浏览器页面
这里有三个关键点。
第一，工具调用与界面生成处于同一条链路 。模型不只是查完资料再写摘要，而是根据取得的数据决定界面应该具备哪些控件和关系。
第二，系统指令承担了产品设计约束 。品牌风格、信息层级、可访问性与交互规则不能只靠一句“做得好看”，而要作为稳定约束进入生成过程。
第三，浏览器代码是最终产物 。这给了模型足够大的表达空间，也把安全、性能和代码可靠性问题一并带进了运行时。
#开放生成不等于没有设计系统
模型可以为不同主题生成截然不同的页面，也可以在同一视觉方向下保持相对一致的设计语言。Google 展示的三个页面使用了统一的青绿色、卡片形态和字体气质，却分别服务于神话角色、披萨聚会和火烈鸟主题。
同一视觉风格下生成的三个不同主题页面
这说明生成式 UI 并不必然等于每次从零开始的随机设计。更现实的产品形态，是让模型在一套明确的品牌与交互边界内动态编排内容，而不是无限制地自由发挥。
设计系统在这里不会消失，反而会从“开发者手动调用的组件库”升级成“模型可以理解并遵守的生成约束”。
#用户更喜欢，但代价没有消失
Google 的人类偏好实验显示，人工设计页面仍然获得最高评价，生成式 UI 与它已经相当接近；普通文字或 Markdown 回答则明显落后。用户确实能感受到为当前问题定制的视觉与交互价值。
但这组比较主动排除了生成速度。研究中的页面有时需要一分钟以上才能完成，也会出现内容不准确或界面不够稳定的情况。换句话说，偏好结果证明了体验上限，却没有证明这套方式已经适合所有高频、低延迟任务。
对于产品团队，真正的问题不是“生成页面是否比文字好看”，而是额外的交互价值能否覆盖四种成本：等待时间、事实核验、运行安全和界面不确定性。
#最合理的落点是按任务选择生成深度
不是每个回答都值得生成一张完整网页。一个事实查询用两行文字即可完成；复杂比较、探索学习和多步骤决策，才更可能从动态界面中获得显著收益。
因此，成熟的生成式 UI 系统需要先路由，再生成：简单任务返回稳定组件或文字；结构明确的任务使用受约束的声明式界面；真正开放、需要高度定制的任务才生成完整应用。
Google 的实验展示的是这条光谱中最开放的一端。它证明模型可以把每个提示变成不同的交互体验，也同时提醒我们：当界面成为模型输出，设计质量、代码质量和答案质量就不再是三个独立问题，而是一项必须共同评测的系统能力。