专栏 · Agent 工程手艺 › 第 215 期 · AGENT 工程 · 收录于 2026 年 9 月 15 日
静态界面的终结:构建意图驱动的 UX 架构——Gus Iwanaga(commercetools)
GI
Gus Iwanaga · AI Engineer
TL;DR · 三句话
- 一40 年来是人迁就静态软件，AI 本该扭转这一点——但 commercetools 早期把界面排版全交给模型，同一句「生成一份 Q1 销售报告」连跑四轮就出了四种互不一致的界面，连标题都从 Q1 变成「1 月和 3 月」，Gus 的评语是「不行，不行，还是不行」。→ 详细
- 二生成式 UI 的分水岭是「你想对体验握住多大控制权」：在受控型（组件写死、agent 只管挑）和开放式（模型直接出 HTML）之间，他们选了声明式——orchestrator 抽意图、调工具，只下发一份 UI spec，按带 Zod schema 的组件目录渲染成原生 React 组件，再用「layout → slot → sub slot → 组件」的层级给 UX agent 搭 harness，「把我们的 UX 知识编码进 agent」。→ 详细
- 三最难的不是模型，是目录和人：「组件目录就是 agent 和 UI 之间的契约，所以每一个属性都很重要」；他的团队「不再逐像素做设计」，非技术背景的 PM 和 UX 设计师如今开会聊的是 schema、目录梳理、规则和合成数据。→ 详细
01
开场先改题：不讲 agent 编排，讲一支团队做「真·生成式 UX/UI」踩过的坑
- 大会最后一场，Gus 嫌自己报名时为吸睛起的标题不好，当场改题：不讲过去 3 天听腻了的 agentic 编排，改讲大会上讲得不够的——一支做真正生成式 UX/UI 的团队总结的经验教训，希望听众至少带走一个新的心智模型。→ 详细
- Gus Iwanaga，commercetools 总经理，管 0→1 新产品的产品、UX、工程三块；议程是问题空间 → 产品 demo → UI 协议的兴起（这周几个协议的创始人也在会上）→ 团队至今仍在面对的挑战与缓解手段。→ 详细
02
问题空间：40 年来一直是人迁就软件，AI 让交付变快了，交付物却还是静态的
- 起手判断：「我们至今仍在迁就自己交付的软件，而不是让软件来适应我们」。2022 年 11 月 GPT 让人瞥见过真正的个性化，但 40 年来交付的一直是静态体验，有了 AI 交付更快了，交付物「在很大程度上仍然是静态的」。→ 详细
- 客户日常要用好几个 SaaS，每个都有自己的一套心智模型和办事方式，债越积越多；本想转交给机器去扛的认知负担（cognitive load，脑子里要同时记住和处理的东西），「结果还是压在我们自己身上」。→ 详细
03
三个不点名的反面教材：塞满的 CRM、花哨表格，和漂亮 UI 背后的培训账
- 三个只露图标不报名的例子：「大概是有史以来最有名的 CRM」界面多到不知从哪看起，他反问光上线这一屏要牵扯多少功能、多少团队；一张「花哨」的表格同样无从下手；再加一个公认漂亮、超级直观的 UI。→ 详细
- 他要强调的代价是 onboarding（带新人上手）：这些公司得调配很多人、花大量时间培训新人，这是复杂度长期累积的「实打实的证据」；普通用户手上有五个应用，就得学五套导航和浏览方式。→ 详细
04
起点之问：一家 API 优先的公司，能不能借 AI 从根上改掉「人迁就软件」
- 去年 8 月，他和老板（公司创始人）提了一个问题：commercetools 是 API 优先的公司（300 多个 API，还在增加），从 AI 的视角看，如果彻底改变人与软件的交互方式、不再做静态体验，能带来哪些根本性的转变？答案就是后面演示的产品。→ 详细
05
先演砸给你看：「生成一份 Q1 销售报告」连跑四轮，出来四种互不一致的界面
- demo 先放的是早期失败版。query 是「生成一份 Q1 销售报告」，右边整块都是自动生成的——「由我们引导，但这是 AI 在做决定」：怎么摆放、信息架构怎么排、从组件目录（component catalog，团队预先做好、允许 AI 调用的一批界面组件）里调哪些组件，全由 AI 定。他身上做 UX 的那一面「一点都不喜欢」，而且同一个 query 跑了四轮，就出了四个版本。→ 详细
- 四轮逐个过：第一轮（数据是某个叫 Urban Thread 的，「管它是什么」）铺满 KPI 卡片，「直觉告诉我这根本对不上」；第二轮标题已经不是 Q1，变成了「1 月和 3 月」，完全没有一致性；第三轮右侧东西更多——KPI 卡片、一堆文字、一堆图表；第四轮回到 Q1，但看着还是乱。→ 详细
- 他点出这类失败的要害：如果这本该是为用户深度个性化的体验，结果是用户每次写 prompt，模型每次吐出点不一样的东西，那不是个性化，只是「制造困惑」——「而这才只是第二轮」。这一路都非常实验性，他说这只是一段旅程的开端。→ 详细
- 他当时给团队也给自己的反馈是「不行，不行，还是不行」：这种东西无论如何不可能发到生产环境，台下的同事可以作证。→ 详细
06
现在的版本：orchestrator 抽意图、找工具，给 UX agent 备足「弹药」再渲染
- 后来有了进展，现版本「成熟多了」。他换了一个「策划一场营销活动」的 query（领域细节全部略过），顺带讲原本想重点讲的 agentic 编排：底层是一个 orchestrator（编排器，负责理解请求、调度下游的总控 agent），先提取 query 的意图，再按意图找工具——第一方、第三方都行，输出可能来自别的 agent，也可能来自 MCP server（让模型调用外部工具和数据的标准接口）；这些输出合在一起，给 UX agent 提供足够的「弹药」和上下文，由它最终渲染出「有意义」的界面。→ 详细
- 效果对比：他说想尽量抛开偏见，但这次出来的整体美感和观感「确实挺打动我」，现场绝大多数人竖了大拇指——「跟前面几轮比，这个还算像样」。他再次强调这是「AI 在我们的引导下做出的决定」；他在界面上点一下批准，生成的东西就直接上线了（演示用的是 pre-prod 预发环境）。→ 详细
- 他也不回避怀疑：问台下是不是也不信这能做成——「我可以告诉你们，这是做得到的」；但他那几位同事每天都盯着他，质疑的正是这东西到底能不能规模化落地。→ 详细
07
生成式 UI 的分水岭只有一个问题：你想对体验握住多大控制权
- 讲 UI 协议之前，Gus 先给出整段的核心框架：各种渲染做法的区别，归根到底是「你想对体验施加多大程度的控制」——因为这是一种非确定性（non-deterministic，同样的输入每次输出可能不一样）的方案，控制放多少，直接决定用户看到什么。他把做法摆成一条光谱：左边「受控型」、右边「开放式」、中间「声明式」。三种他各备了代码片段，时间关系不展开，会后可分享演示文稿。→ 详细
08
受控型：组件原样交付、agent 只管挑——Booking 这类业务合适，配置繁重的 B2B SaaS 不合适
- 例子是 ChatGPT：他搜「帮我找一家旧金山的日料店，今天去」，出来的餐厅组件「非常有主见」（opinionated，长什么样、怎么交互都被设计方定死了）。这就是受控型（controlled）：你把组件原封不动地交付出去，agent 负责从你的组件目录里挑，并完全按你描述的样子展示——你对这个组件拥有完全控制权。→ 详细
- 但适不适合要看业务性质。commercetools 做的是 B2B SaaS，「配置项多得不得了」，所以他们不想规定得太死；他给的理由是客户反复提的同一句反馈：「这些流程太让人困惑了，配置项太多了。你们怎么才能帮我把认知负担去掉？」→ 详细
- 反过来，如果你是 Booking 这样的公司，这种做法就非常合适：agent 从组件目录里挑出组件、原样渲染，简单可控。→ 详细
09
开放式：全权交给 LLM——Claude 一句话画出组织架构图很惊艳，但换成公司产品就「祝你好运」
- 光谱右边是把完全自主权交给 LLM。他坦白，自家产品前面那几次失败尝试做的就是这个：跟 LLM 说「你手上有这些组件，你会怎么组合出这个体验？」——严格说那次还带了点他们的主观设定，因为给了它一部分现成组件；彻底的版本是整件事全权交给模型。→ 详细
- 例子：他在 Claude 里只说一句「做一张三层的组织架构图」，Claude 直接把图渲染出来，效果非常好。但站在公司角度，他不确定自己会完全放手——输出和最终结果都控制不了；作为 UX 负责人，「我身上 UX 的那一面永远会说不行，你必须把控制权握在自己手里」。他呼应这周好几场讲设计、品味、判断力的演讲：想用这些协议，就别把真正的体验过多交给 LLM，得找替代方案。→ 详细
- 运作方式：有一个 MCP tool 直接把 HTML 发出去，放进沙箱化的 iframe（嵌在页面里、与宿主隔离的小窗口）里，渲染到你选的宿主应用——Claude、ChatGPT、Perplexity 或任何别的聊天应用都行。他的评价只有一句：「如果你愿意把控制权完全交给 LLM，那祝你好运。」（MCP 把 HTML 交给宿主渲染的机制见 ep119；与 Gus 相反、主张「agent 只需要 HTML」的观点见 ep104。）→ 详细
10
他们选了中间的「声明式」：模型只下发一份 UI spec，前端按带 schema 的组件目录渲染成原生组件
- 光谱中间是声明式（declarative），也是 commercetools 最终的选择。打个比方：受控型是 agent 从货架上拿成品，开放式是让模型现场自己画，声明式则是模型写一份「装配单」，前端拿自家统一的零件去装。能提供这种折中的协议，他点了三个（各有特点，不逐个展开）：Google 的 A2UI、Vercel 的 JSON Render、Thesys 的 OpenUI。→ 详细
- 以他刚演示的产品为例，整条链路是：用户输入 query → 意图分类 → 按分类结果调用相应 tools、取回数据 → 在这中间某个环节，把组件目录里符合条件的组件，映射到 tools 返回的实体上 → orchestrator 下发一份 UI 描述，「就像一份 UI spec」（界面规格说明）→ 组件目录用 Zod schema（一种数据校验写法，规定每个组件能接收哪些字段、什么类型）定义，下发的内容必须符合协议规范——「这只是其中一项要求」→ 渲染出来，最终输出是原生 UI，在他们这里就是 React 组件。→ 详细
11
声明式的好处与代价：处处守住设计系统，但确定性更弱——组件怎么摆仍由 LLM 定，乱就从这里来
- 好处：它在任何地方都会遵循你的设计系统（design system，一套统一的组件、样式和交互规范），「这一点非常重要」。他们不想把体验交给 LLM，原因前面 demo 里大家都看到了：文案你左右不了——同样是 Q1，有时会写成「1 月到 3 月」，「这很要紧」。UX 由多个要素构成：整体体验、UI、文案与 UX 写作（UX writing，界面上每一个字怎么写）等等，声明式在这些要素上给了他们一个折中。→ 详细
- 代价：它的确定性要弱一些，这正好引出挑战。还拿他自己的产品说：orchestrator 只负责为这条 query 取来符合条件的组件，可这些组件在界面里怎么摆，全看 LLM——「这就可能变得非常非常乱」。他接下来讲的三个挑战，就从这里说起。→ 详细
12
挑战一：agent 挑好了组件，谁来排版？——借原子设计，给 UX agent 搭 harness、教它「什么才叫好」
- 第一个挑战：如果由 agent 来挑组件，那由谁、由哪个实体负责把它们编排好？这就是信息架构（information architecture，内容怎么分区、主次先后怎么排），「UX 里至关重要的一环」。站在普通客户的角度这一点非常要紧——放任不管，组件的摆放就可能完全是随机的。→ 详细
- 解法第一步，团队借用了原子设计（atomic design）——他幻灯片上的定义是「一种由五个不同阶段组成的方法论，这些阶段协同运作，以更有章法、更有层级的方式构建界面设计系统」，大白话就是把界面从最小的元素一级一级拼成整页。为什么帮助很大：页面上都是一个个独立元素，有了层级，考虑页面整体结构时「它让我能按自己认为合适的方式去掌控它」。→ 详细
- 第二步，给这个 UX agent 搭了一套 harness（套在模型外面的规则、示例与约束，相当于给它上的「缰绳」）：「最终我们教会了这个 UX agent 什么才叫好、在特定情境下最优的布局是什么」，另外还有一套收录各种模板的目录。（把品味编码进脚手架的另一种做法见 ep199。）→ 详细
13
排版的骨架：layout → slot → sub slot → 组件，而且因为有 orchestrator，顺序要倒着走
- 他特意停下来展示的「非常重要的细节」是这套层级：最外层是整个页面的布局（layout）；layout 里有不同的 slot（插槽，页面里预留给某类内容的位置），比如 header、main；slot 下面可以有 sub slot（子插槽），sub slot 里还能再套 sub slot；sub slot 里规定能放哪些「符合条件的组件类别」。有了这层规定，orchestrator 取回来的组件就能被引导到最优的位置上。→ 详细
- 他一句话点破本质：「这实际上就是我们把自己的 UX 知识编码进这个 agent 里。这样下一次，情况怎样都无所谓，它都会按同样的方法来。」换句话说，界面一致不再指望模型每次「发挥稳定」，而是靠写进结构里的规则兜住。→ 详细
- 设计时是 layout → slot → sub slot → 组件自上而下想；但因为 orchestrator 是先按意图把组件取回来的，他们把顺序反过来走：从组件出发，组件映射到 sub slot，sub slot 映射到 slot，slot 再映射到模板，然后按需编排。他坦言：「这真是个要命的挑战，到现在都还是。」→ 详细
14
挑战二：设计系统和组件目录是整件事的「心脏」——目录就是 agent 与 UI 之间的契约
- 第二个挑战是设计本身——你的设计系统和你的组件目录，「它会成为整件事的心脏」。他说怎么强调都不为过：如果你看到了在自己产品里用这些 UI 协议的潜力，这一块就是重中之重。他们一直在突破边界，持续测试前面提到的 A2UI、JSON Render、OpenUI 等协议，但一直相当吃力。→ 详细
- 吃力的原因是一句话：「组件目录就是 agent 和 UI 之间的契约，所以每一个属性都很重要。」不光组件目录如此，layout 也一样——layout 有自己的「组件」（slot 和 sub slot），每一个都有自己的属性，都得定义清楚。→ 详细
- 他把这一整摊活概括成一个词：curation（精心梳理——一项项挑选、定义、打磨）。这种梳理「绝对必要」，你才能交付真正有意义的东西，「而不是外面那种为了演示而演示的 demo」；梳理到位，你才有控制权，才能从 UX 的角度掌舵。→ 详细
15
挑战三：团队不再逐像素做设计——非技术 PM 和设计师改聊 schema、规则和合成数据
- 最后一个「重大」挑战是人：「我的团队不再逐像素做设计了」，也不再把整个流程一步步画出来——AI 已经能在很大程度上决定这些，工作性质随之大变。他说这是段很棒的旅程，但对非技术背景的 PM 和 UX 设计师来说是个不小的冲击。→ 详细
- 冲击具体在哪——他们现在开会聊的是：schema（数据结构定义，规定每样东西有哪些字段）、组件目录怎么梳理、规则、能生成哪些合成数据（synthetic data，专门造出来做测试和校准的样例）——比如「作为映射逻辑的一部分，怎么生成能映射到某个特定组件的查询？」——以及交互模式。换句话说，PM 和设计师交付的不再是一张张画好的界面，而是让 agent 每次都能把界面排对的那套规则和样例。→ 详细
- 他的提醒：打算走这条路，要意识到人的因素非常重要。他跟其他管理者交流时讲「三个 P」：people、product、process（人、产品、流程）——流程要非常轻量，但这件事非常重要。→ 详细
16
闪电问答 / 收尾
本期为大会演讲，无闪电问答。收尾时 Gus 留下一句判断：这件事「只是时间问题……它一定会到来」，并欢迎会后继续聊这个话题。→ 详细
17
联系方式
片中未念出具体账号：结尾幻灯片放了 Gus 的 LinkedIn（请观众截图），另列了几场 AIE（AI Engineer 大会）上反复讲这些 UI 协议的演讲作为延伸资源，转写里没有演讲题目。→ 详细