在传统计算领域，界面都是预先定义的。每个按钮、菜单和窗口都由开发者精心编写而成。但如果界面能够实时生成，并根据用户每次互动的情境进行调整，那会怎样？为了探索这个问题，我们构建了一个研究原型（在 Google AI Studio 中查看演示版应用）以实现生成式、无限延伸的计算体验。
我们的原型模拟了一个操作系统，其中每个界面都由一个大型语言模型动态生成。这个操作系统使用了 Gemini 2.5 Flash-Lite，该模型的低延迟对于创建即时响应式互动至关重要。用户不是在浏览静态文件系统，而是在模型随每次点击持续构建的动态环境中互动。本博文概述了该原型背后的核心技术概念。
为了即时生成界面，我们需要为模型提供清晰的结构和每个请求的上下文。我们通过将模型的输入分为两部分来设计我们的提示：“界面构成”和“界面互动”。
界面构成是一种系统提示，其中包含了一套固定的界面生成规则。这些规则定义了一致的元素，例如操作系统级别的样式、主屏幕格式以及地图等元素的嵌入逻辑。
界面互动是一个 JSON 对象，用于捕获用户最近的操作，例如鼠标点击图标。此对象会用作提示模型生成下一个界面的特定查询。例如，在 Notepad 应用中点击“保存笔记”图标可能会生成如下对象：
{
//“id”：按钮的“data-interaction-id”属性的唯一 ID。
id: 'save_note_action',
//“type”：“data-interaction-type”的互动类型。
type: 'button_press',
//“value”：由于按钮具有“data-value-from”属性，系统会
// 从 ID 为“notepad_main_textarea”的文本区域中检索内容。
value: 'Meeting notes\n- Discuss Q3 roadmap\n- Finalize budget',
//“elementType”：被点击元素的 HTML 标记。
elementType: 'button',
//“elementText”：按钮中显示的文本。
elementText: 'Save Note',
//“appContext”：用户当前所用应用的 ID。
// 位于“App.tsx”中的“activeApp”状态。
appContext: 'notepad_app'
}这种由两部分组成的上下文设置方法可令模型保持一致的外观和风格，同时会根据特定的实时用户输入生成新颖的界面。
单次互动能够提供即时情境，但一系列互动则能够讲述更丰富的故事。我们的原型可以利用过去 N 次互动的跟踪记录来生成更具情境相关性的界面。例如，计算器应用中生成的内容可能会根据用户之前访问的是购物车还是旅行预订应用而有所不同。通过调整这种互动跟踪记录的长度，我们可以在情境准确率和界面多样性之间取得平衡。
为了提升系统运行速度，我们不能等到模型生成完整的界面画面后再进行渲染。我们的原型利用模型流式传输和浏览器的原生解析器来实现渐进式渲染。由于模型以分块形式生成 HTML 代码，我们会将其不断添加到组件的状态中。然后，React 会重新渲染内容，使得浏览器在接收到这些元素时就能立即显示有效的 HTML 元素。对于用户而言，这会带来一种界面几乎瞬间在屏幕上呈现出来的体验。
默认情况下，我们的模型会根据每个用户输入从头生成一个新界面。这意味着两次访问同一个文件夹可能会产生完全不同的内容。考虑到我们习惯的 GUI 是静态的，这种非确定性、无状态的体验可能并非总是理想之选。为了将有状态性引入原型，我们的演示版系统提供了一个选项，可以构建内存缓存，用于针对会话特定的界面图建模。当用户访问已生成的界面时，系统会提供图中存储的版本，而无需再次查询 Gemini。当用户请求缓存中不存在的新画面时，界面图会逐步增长。这种方法在提供状态的同时，不会损害生成输出的质量，而降低模型采样温度可能会带来副作用。
虽然这是一个概念原型，但底层框架可以应用于更实际的用例。
探索此类新颖概念有助于我们理解人机交互的新范式的演变过程。随着模型速度越来越快、功能越来越强大，我们相信生成式界面是未来研究和开发的一个极具前景的领域。
