跨国深谈← 返回←别再让人适应软件:让 AI 现场为你生成界面

别再让人适应软件:让 AI 现场为你生成界面

关联

人物 Gus Iwanaga

公司 Commerce Tools

概念 生成式 UI · 编排器 · UX 智能体 · UI 协议 · A2UI · 组件目录 · 原子设计 · MCP

过去 40 年，我们一直在推送静态的软件体验——人去适应软件，而不是软件适应人。一个普通用户的日常要用好几个 SaaS 应用，每个都有自己的心智模型、自己的操作逻辑，认知负担全都压在用户身上。

这是 Commerce Tools 总经理 Gus 的开场判断。他负责公司 0 到 1 产品的产品 UX 和工程，这家公司是 API 优先的电商平台，有 300 多个 API 还在增加。

GPT 问世时，我们窥见了真正个性化的样子，但其他一切都还是静态的；即使有了 AI，我们发布东西快了很多，界面本身在很大程度上仍然是死的。他的问题是：为什么？

去年八月，他和公司创始人坐下来问了一个问题：透过人工智能的视角，如果能彻底改变我们与软件交互的方式，可以做出哪些根本性转变？答案就是他要演示的产品。

最初的尝试：完全放手给 AI,结果是灾难

第一版产品的做法很自然：用户输入一个查询，比如「创建一份 Q1 的销售报告」，让 AI 自主决定布局、信息架构、从组件目录里检索哪些组件。结果呢？

同一个查询换四种措辞，生成了四个完全不同的变体：这一个满屏 KPI 卡片，下一个「Q1」变成了「一月到三月」，第三个塞了更多文字和图表——完全没有一致性。 他给团队的反馈是「不、不、还有不」，无论如何不可能把这个发布到生产环境。

这暴露了生成式 UI 的核心矛盾：非确定性的模型，每次输出都不一样。如果这是一个高度个性化的体验，用户每次提问模型都生成不同的界面，只会制造混乱。

演示现在的版本：编排器 + UX 智能体的分工

现在的方案精致多了。用户说「我想策划一个营销活动」，底层有一条编排链路：编排器先提取查询的意图；基于意图定位工具——可以是一方工具、第三方工具，甚至 MCP 服务器上的智能体；这些输出组合起来，为 UX 智能体提供足够的「弹药」和上下文，最终渲染出有意义的界面。 关键是：界面由 AI 决定，但由人引导——他要反复强调这一点。

三条路线：你对体验要多少控制权

渲染这类界面有三种 UI 协议路线，选择的依据是你想对体验施加多少控制。

一是完全控制：组件原样交付，智能体只能从目录里选取并按你描述的方式展示。ChatGPT 里帮你找餐厅的那种卡片组件就是这样，非常「固执己见」。如果业务像订房网站那样场景固定，这条路效果很好。

二是完全开放：把全部自主权交给 LLM。一个 MCP 工具直接发送 HTML,在沙箱 iframe 环境里渲染到任意宿主——可以是 Claude、ChatGPT 或任何聊天工具。

他现场让 Claude「创建一个三层的组织架构图」，一句提示就渲染得很好。但站在公司立场，他不建议这么做：你无法控制输出和结果。

作为 UX 负责人，他的态度很明确：「你必须掌控。」本周会上好几场演讲都在讲设计、品味和判断力——如果你想走这条协议之路，不能把太多实际体验委托给 LLM。

三是声明式，他们的选择，居于中间：Google 的 A2UI、Vercel 的 JSON render、Thesis 的 OpenUI 等协议都提供这种中间态。流程是：编排智能体完成意图分类、调用工具、检索数据之后，把目录中符合条件的组件映射到工具的实体上，然后广播一份 UI 描述——像一个 UI 规范。

组件目录用 ZOD schema 定义，必须符合协议要求，最终渲染成原生 UI(他们的例子里是 React 组件)。声明式方法最大的好处：在任何地方都符合你的设计系统。 对 B2B SaaS 来说这很关键——客户一直在抱怨流程困惑、配置太多，你不想过于僵化死板，但也不能放任 LLM 随意改文案、改时间表述。

挑战一：谁负责摆放组件？

即使编排器取对了组件，怎么在 UI 里摆放完全取决于 LLM,而放任不管，摆放可能完全是随机的。这是信息架构问题，是 UX 的关键一环。

他们的解法是借用**原子设计**(一种把界面拆成从最小元素到完整页面、分层级组织的方法论)，并教 UX 智能体「什么是好的样子」——给定情况下的最优布局是什么。具体做法是定义一个层级结构：整体页面即布局，布局包含槽位，槽位里有子槽位，子槽位可以再嵌套子槽位，子槽位里放符合条件的组件类别。

因为有了编排器，他们把顺序颠倒：从组件出发，组件映射到子槽位，子槽位映射到槽位，槽位映射到模板，然后按需排布。 用他的话说，这「实际上就是把我们团队积累多年的 UX 知识编码进这个智能体」——之后不管什么查询，都遵循同样的方法。他坦承这是一个极其艰难的挑战，现在仍然是。

挑战二：组件目录成了整个系统的心脏

设计系统和组件目录变成了整个东西的「心脏」。他怎么强调都不为过：如果你看到了在自己产品里用这些 UI 协议的潜力，目录这件事会是一件大事。

因为目录是智能体和 UI 之间的契约——每一个属性都很重要，布局组件(槽位、子槽位)也一样，各有各的属性。他把这些统称为「策展」：这种策展是绝对必需的，这样你交付的才是有意义的东西，而不是外面那些「为了演示而演示」的 demo。他们持续在测试 A2UI、JSON render、OpenUI 这些协议，但目录的维护一直相当有挑战性。

挑战三：团队不再画像素了

一个容易被忽视的重大挑战：他的团队不再设计像素了，不再手工设计整个流程，AI 在很大程度上决定这些。工作的性质发生了相当大的转变，即使对非技术背景的 PM 和 UX 设计师也是一次很大的冲击。

因为现在大家谈的是 schema、目录策展、规则、可以生成什么合成数据、如何生成能映射到特定组件的查询、交互模式——全是过去设计师不碰的东西。他的提醒是：如果你们要走这条路，人的因素非常重要。他和其他领导者交流时常说「三个 P」——人员、产品和流程，外加一个非常轻量的流程。

他的收尾判断很直接：生成式 UX 和 UI 的普及「这只是时间问题」，它正在到来。

本集带走

• 别把体验全权交给 LLM:完全开放的路线(直接生成 HTML 渲染)demo 好看，但输出不可控、每次不一致；业务场景固定的(如订房卡片)可以用完全控制的预制组件。
• 中间态最实用：用声明式 UI 协议(如 Google 的 A2UI、Vercel 的 JSON render)让 AI 组装、但组件必须来自你的目录、符合你的 schema——好处是输出在任何地方都符合设计系统。
• 用槽位层级约束 AI 的摆放：布局→槽位→子槽位→组件的层级，再从组件反推映射到模板，等于把团队的 UX 知识编码进智能体，解决「组件随机摆放」的问题。
• 把组件目录当契约来维护：目录是智能体和 UI 之间的契约，每个属性都重要；这份「策展」工作是交付可用产品、而非玩具 demo 的分水岭。
• 提前管理团队转型：设计师和 PM 的工作从画像素转向 schema、规则和合成数据；用「人员、产品、流程」三个 P 配一个轻量流程来承接这场转变。

这实际上就是把我们的 UX 知识编码进这个智能体。
This is literally us codifying our UX knowledge into this agent.
—— Gus Iwanaga · [19:32]

目录是智能体和 UI 之间的契约。
The catalog is the contract between the agent and the UI.
—— Gus Iwanaga · [20:40]

我的团队不再设计像素了。
My teams do not design the pixel anymore.
—— Gus Iwanaga · [21:26]