"静态 UI" 的终结：为何生成式 UI 不可避免

“点击”的时代正在终结，“意图”的时代已经开启。

在过去的 20 年里，软件开发遵循着一个可预测的模式：开发者设想用户故事，设计屏幕，编写 HTML/CSS，然后发布。 这就是 静态 UI (Static UI)。它假设你知道用户可能采取的所有路径。

但随着大语言模型 (LLM) 的兴起，用户不再遵循预设路径。他们正在开辟自己的路。

聊天机器人的瓶颈

今天，大多数 AI Agent（如 ChatGPT 或 Claude）都被困在基于文本的牢笼中。你查询航班，它们给你一个文本列表。你要求数据可视化，它们可能会写 Python 代码来生成一张静态图片。

这就是 字符带宽瓶颈。对于复杂任务，文本是一种低带宽的交互方式。

类比：想象一下仅用对讲机办理酒店入住。 “你有看得见风景的房间吗？” “有的，402房。” “我能看看吗？” “我可以给你描述一下…”

A2UI 相当于直接给你看一张 照片。

为什么不直接用 HTML？

如果 Agent 需要 UI，为什么不让它们写 HTML？它们不是很擅长写代码吗？

我们尝试过。这被称为 HTML 注入，它是安全的噩梦。

允许一个 LLM（本质上是一个“随机鹦鹉”）将原始 HTML/JS 注入你的银行应用，就像把车钥匙交给一个陌生人，仅仅因为他“看起来值得信任”。

• XSS 攻击：一个幻觉产生的 script 标签可能会窃取会话令牌。
• 破坏 UI：注入的 CSS 可能会与你的全局样式冲突，导致应用无法使用。
• “恐怖谷”效应：Agent 生成的按钮如果与你的品牌风格有细微差别，会严重破坏信任感。

A2UI 的方案：声明式抽象

这就是 A2UI 改变游戏规则的地方。

我们不让 Agent “画像素” (HTML)，而是强迫它“协商意图” (JSON)。

1. 严格 Schema：Agent 发出一个结构化的 JSON 对象，例如 { type: "FlightCard", props: { ... } }。
2. 宿主控制：你的应用接收这个 JSON。它在本地注册表中查找 “FlightCard”。
3. 原生渲染：你的应用渲染你的受信任 <FlightCard /> React/Flutter 组件。

// Agent 发送这些数据 (安全且语义化)
{
  "type": "flight-card",
  "props": {
    "airline": "AA",
    "price": 450,
    "departure": "10:00 AM"
  }
}

未来是生成式的

我们正在走向 “即时 UI (Just-in-Time UI)”。 你不需要为“航班搜索”构建一个页面，再为“酒店搜索”构建另一个。你将为你的 Agent 提供一个“旅行组件包”，Agent 将根据用户的具体查询，实时组合出完美的界面。

A2UI 正是让这种协商成为可能的协议。它是下一代软件的语言。

深度阅读

想要了解其底层工作原理？

• 数据绑定：A2UI 如何处理动态更新。
• AG-UI vs A2UI：理解协议与规范的区别。