生成式 UI 正式进入标准化讨论

10 月 9 日，W3C 生成式 UI 社区工作组发布了一场国际标准研讨会的总结。研讨会实际举行于 9 月 6 日，来自腾讯、百度、华为等企业的实践者围绕生成式界面的互操作性、性能、无障碍、安全与测试展开讨论。

界面不再固定

这里讨论的生成式 UI，不是让模型按照要求绘制一张页面，也不是从模板中选择一套现成布局。它会根据用户当前的任务、输入内容和系统状态，在产品运行过程中组织信息、选择组件，甚至生成相应的操作路径。同一个需求在不同时间、不同用户和不同上下文中，可能呈现为表格、表单、卡片或一组操作按钮。

传统设计流程建立在界面相对稳定的前提上。产品发布之前，团队可以确认页面包含哪些状态，按钮触发什么行为，错误如何提示，键盘能否访问，权限操作是否需要二次确认。即使产品拥有大量页面，这些页面依然属于可以枚举和检查的设计对象。生成式 UI 打破了这个前提。设计团队无法预先看到所有结果，也不能依靠逐页验收保证每一种组合都成立。

为生成划定边界

由此产生的风险并不只是视觉不一致。模型可能选用不适合当前任务的控件，也可能在压缩信息时遗漏关键说明。一个生成结果即使视觉完整、层级清楚，仍可能缺少错误状态、无障碍名称或撤销路径。更严重的情况是，同一种操作在不同界面中呈现出不同的权限含义，使用户无法稳定判断自己即将确认、提交或授权什么。

研讨会上出现的技术方案，都在尝试减少这种漂移。百度介绍的实践并未直接让模型自由生成最终网页，而是先通过自定义描述语言和 UIJSON 组织界面的结构与行为，再由系统将这些内容转化为实际页面。这个中间层的作用，是把模型提出的界面方案限制在产品可以识别和检查的范围内。W3C 社区工作组所关注的是则是跨平台表达、受约束的 Web 技术子集与自动测试。生成结果可以变化，但它必须以一种能够被系统理解、验证和追踪的方式变化。

生成式 UI 的标准化因此不应被理解为统一布局或限制视觉创造。首先需要保持稳定的，是界面背后的交互语义。删除操作无论以何种形式出现，都应明确说明后果；支付状态无论采用列表还是卡片，都必须能够追溯；权限提升不能因为界面重新组织而省略确认；无障碍信息也不能成为模型在压缩页面时可以舍弃的内容。这些要求不决定页面必须长成什么样，却规定了一个界面成立所必需的条件。

设计转向规则

对 UI 设计师而言，设计对象正在由页面扩展为生成边界。过去的规范主要说明组件如何构成、间距如何使用、不同状态如何呈现；面向生成系统的规范还要回答哪些内容允许变化，哪些关系必须保留，哪些组件可以互换，以及系统无法确认用户意图时应当退回什么状态。设计师交付的不再只有一套理想结果，还包括系统产生其他结果时仍需遵守的约束。

这也改变了设计评审的尺度。华为在研讨中提出从视觉结果与源代码两个层面评估生成质量，检查显示是否正确、需求是否得到满足、功能是否一致，以及操作能否完整执行。对于生成式界面，只审查一张代表性页面无法说明系统是否可靠。团队还需要反复输入相近任务，观察关键入口是否持续存在、同一操作是否保持相同含义，以及错误是否集中出现在某些用户条件和任务类型中。评审面对的已不是单个结果，而是一组结果的稳定程度。

自由止于责任

当 Agent 开始通过界面替用户执行操作，这套约束会更加重要。一个临时生成的按钮可能提交资料、修改权限或发起付款，它所代表的责任不能由模型临时决定。呈现方式可以适应当前情境，身份验证、授权范围、确认机制和撤销路径却必须由产品预先定义。否则，生成式 UI 获得的并不是适应性，而是在用户无法察觉的位置改写操作边界。

目前，W3C 社区工作组尚未提出可以直接实施的统一标准，会上讨论的中间表达、质量指标和测试方法也没有经过广泛的跨平台验证。这些材料更适合作为行业开始界定问题的信号，而不是已经成熟的解决方案。