从"文本墙"到"无限临时界面"

过去两年，大模型已经能推理、规划、调用工具、完成相当复杂的任务，但它面向用户的输出却几乎总是被压扁成一大段文字或标准 Markdown。一个能力极强的模型，最终只能用"段落"和用户对话——这是巨大的体验浪费。

生成式 UI（Generative UI，简称 GenUI）就是为了解决这个错配：界面的一部分不再由开发者预先写死，而是由 AI 在运行时根据用户的意图和上下文动态生成、挑选与编排。模型自己决定该展示什么界面、需要向用户索取哪些输入、状态如何随任务推进而更新。Google 把这种愿景概括为"无限临时界面"（infinite ephemeral interfaces）——每一次提问都可以得到一个为它量身定做、用完即弃的界面。

Google 的奠基性研究

2025 年 Google Research 的论文《Generative UI: LLMs are Effective UI Generators》给这个方向提供了关键的实证支撑。论文里几个数据很有说服力：

• 在人类评测中，生成式 UI 拿到了 1736.2 的 ELO 分数，强烈优于除"人类专家"之外的所有输出形式。
• 在 83% 的情况下，用户更偏好模型生成的 HTML/CSS/JS 界面，而不是 Markdown 文本。
• 最关键的结论：UI 生成是一种涌现能力（emergent capability），不需要针对 UI 做专门训练，新模型相比旧模型有显著提升。

这项研究并没有停留在论文里。它已经落地到 Gemini App 的 "dynamic view" 实验，以及 Google 搜索的 AI Mode 中。

一条从"全自由"到"全受控"的光谱

GenUI 设计里最微妙、也最容易踩坑的问题是：到底谁来决定界面的表示形式——是 Agent（LLM），还是程序员？ 围绕这个问题，业界形成了一条清晰的光谱：

1. 开放式 / 原始 HTML：Agent 直接返回完整的 HTML 或 iframe，渲染任意界面。自由度最高，但安全与性能风险也最大，通常是 Web 优先、很难移植到原生端，品牌一致性也难保证。

2. 声明式 GenUI：Agent 不返回可执行代码，而是返回一份结构化的界面描述（如 JSON）。在结构与灵活之间取得平衡，这也是 A2UI、AG-UI 这类协议走的路线。

3. 静态 / 组件目录式：界面从一组手工打磨好的组件里挑选。目录定义了系统的"词汇表"——只有这些经过审批的组件、模式和交互能被 GenUI 使用，从而保证每一个生成的界面都是品牌安全、视觉一致的。

这条光谱也重新定义了设计师的角色：设计师不再画一块块静态屏幕，而是去设计"能力的系统"——通过系统提示词、用户意图模型、精选组件目录这些护栏，规定界面如何自适应，而不是规定它长什么样。

主要挑战

把 GenUI 推向生产，会遇到几类绕不开的问题：

• 一致性：同一个查询，生成的界面每次可能都不一样。
• 性能：生成需要时间，当前实现有时要花一分钟甚至更久才出结果——流式渲染是主要缓解手段。
• 安全：一旦允许生成可执行代码，提示注入就可能演变成 UI 注入。
• 幻觉：界面内容也可能"一本正经地胡说八道"。

测试方式同样要变。传统的视觉回归测试在非确定性界面上很容易误报，更务实的做法是转向概率性断言：只验证"意图和功能组件存在且可交互"，而不纠结于它们的精确位置。

小结

到 2025–2026 年，GenUI 已经从一个愿景收敛成了清晰的工程范式：一条从开放式 HTML 到安全的目录/声明式方案的光谱，加上弹性流式渲染作为对抗延迟的标准答案。下一篇我们会深入 A2UI 协议，看看 Google 是如何用"传数据而非传代码"的思路，让 Agent 安全地把界面投送到任意客户端的。