生成式 UI（Generative UI）是由 AI 在产品运行过程中，根据用户当前意图、会话上下文和可用数据，动态选择并组合组件形成的界面。它不是提前画好所有页面，也不是把一句提示词变成一张静态设计稿；真正的变化在于，界面的结构、内容和操作会随着任务推进而调整。
本文只讨论运行时动态界面。需要学习设计阶段如何用 AI 生成可编辑稿，可进入AI 生成 UI 的完整方法；如果关注聊天框、侧边栏等固定形态，则由AI 产品界面布局继续承接。
生成式 UI 和普通界面有什么区别
普通界面由产品和设计团队提前定义页面、组件与跳转，用户进入哪个状态，就显示对应的固定页面。生成式 UI 仍然需要设计系统和业务规则，但界面组合发生在运行时：系统先理解用户要完成什么，再从允许使用的组件中选择合适结构，把结果、输入项和下一步动作放到当前界面。
| 方式 | 界面何时确定 | 适合任务 | 主要风险 |
|---|---|---|---|
| 固定界面 | 设计与开发阶段 | 高频、稳定、规则明确 | 长尾任务需要不断新增页面 |
| AI 生成设计稿 | 设计阶段 | 探索结构、视觉和原型 | 生成结果不等于产品运行逻辑 |
| 生成式 UI | 产品运行阶段 | 目标明确但路径和内容会变化 | 不一致、误操作、权限与恢复问题 |
因此，“看起来像 AI 界面”并不是判断标准。一个带聊天框的固定页面可能不是生成式 UI；一个没有聊天框、却会根据任务即时生成表单、对比表或操作面板的产品，反而更符合这个概念。
为什么生成式 UI 正在成为产品设计趋势
大模型已经能处理自然语言、结构化数据和工具调用，用户不必先理解复杂导航，再逐层寻找功能。与此同时，纯文本回答难以承载确认、筛选、编辑和批量操作，产品需要把模型结果转成可看、可改、可执行的界面。Google Cloud 已将 Generative UI 定义为由 AI 按用户意图和会话上下文实时构建的界面；W3C China 也在讨论它对 Web 设计与标准化的影响。
这并不意味着固定页面会消失。高频导航、账户安全、支付确认、权限管理等任务更需要稳定结构；动态界面更适合解决长尾任务和信息组合问题。好的产品通常会采用“稳定外壳 + 动态任务区”，让用户始终知道自己在哪里、系统正在做什么。
生成式 UI 的运行机制：五层缺一不可
一个可用的生成式界面，不是让模型自由输出 HTML。它通常需要五层共同工作：意图层确认目标，上下文层提供数据，编排层决定步骤，组件层限制可用结构，校验层检查权限、数据和操作风险。
- 意图：识别用户要查询、比较、填写还是执行操作，并在信息不足时先追问。
- 上下文：读取当前对象、历史选择、角色权限、设备和任务进度，只使用完成当前任务所需的信息。
- 编排：把目标拆成步骤，决定先展示结果、先补输入，还是先请求授权。
- 组件：从经过验证的表单、表格、卡片、图表、确认框和状态组件中组合界面。
- 校验：检查字段、数据来源、权限、必填项和高风险动作，在真正执行前保留确认与回退。
如果缺少组件约束，同一个任务每次可能生成完全不同的布局；如果缺少校验层，界面即使漂亮，也可能把模型猜测变成真实操作。生成能力越强，组件契约和操作边界越需要明确。
哪些场景适合使用生成式 UI
判断是否适合，不看功能是否带 AI，而看任务是否同时具备三个特点：用户目标清楚、输入组合多、固定页面难以覆盖全部路径。生成式 UI 的价值是压缩寻找与配置步骤，不是为了让每次打开页面都变得不同。
- 多条件分析：用户提出“比较三个地区本季度退款原因”，系统可生成筛选结果、图表和继续追问入口。
- 复杂配置：用户说明活动目标、渠道和预算后，系统按缺失信息逐步生成配置表单。
- 任务型智能体：系统完成资料整理、文件处理或审批准备时，用进度、差异和待确认项代替一段长文本。
- 个性化工作台：根据角色与当前任务组合指标、待办和快捷操作，但稳定导航与核心权限保持不变。
登录、支付、删除、授权和不可逆操作不应完全交给自由生成。它们可以由动态任务触发，但最终确认界面、关键信息顺序和操作反馈应使用经过审核的稳定组件。
示例：把一句审批需求变成可控界面
假设用户输入：“帮我整理本月差旅报销，异常项目先不要提交。”系统不应立刻执行，而应先生成一个任务面板：顶部说明识别到的目标，中间列出已匹配票据、缺失字段和异常原因，底部提供“补充信息”“排除异常项”和“预览提交”三个动作。
当用户选择预览时，界面再生成汇总表和影响范围，清楚区分将提交、暂存和忽略的项目。只有用户确认后才进入真实操作；完成后显示结果、失败项和撤销或重新处理入口。这个例子中，界面可以动态组合，但数据来源、权限、确认顺序和恢复路径都不能动态猜测。
用组件约束动态界面，而不是让 AI 自由发挥
生成式 UI 需要一套既能被设计师理解，也能被模型和代码调用的组件契约。每个组件除了名称和视觉样式，还要说明适用任务、必填数据、允许动作、状态、无障碍要求和禁止组合。
| 组件契约 | 需要说明的问题 | 示例 |
|---|---|---|
| 使用条件 | 什么任务可以调用 | 比较表只用于同维度对象 |
| 输入要求 | 哪些字段必须真实存在 | 金额、币种和归属人不能为空 |
| 状态 | 加载、空、错、部分成功如何显示 | 失败项保留原因和重试入口 |
| 动作权限 | 谁能查看、编辑或执行 | 普通成员只能预览，管理员可提交 |
| 恢复方式 | 误操作后如何返回 | 提交前确认，提交后提供撤销条件 |
基础状态可以沿用组件状态与变体清单，再补充生成式界面特有的“等待模型、正在调用工具、需要确认、部分完成和人工接管”等状态。
让用户保持控制：六个关键交互
动态界面最容易损失的是可预测性。用户不只要看到结果，还要知道系统理解了什么、准备做什么、哪些信息来自真实数据，以及出错后如何恢复。
- 意图预览：执行前复述目标、对象和范围，允许用户修正。
- 必要追问：缺少关键条件时先询问，不用默认值悄悄补齐业务决策。
- 过程可见：长任务展示当前步骤、已完成项和等待项，避免只显示无法判断进度的加载动画。
- 来源区分：把系统数据、用户输入和模型推断分开呈现。
- 确认与授权：涉及发送、提交、删除、支付或权限变化时，在动作发生前展示影响范围。
- 撤销与人工接管：提供回退、重试、修改和转人工路径，不把用户锁在模型选择中。
生成式 UI 的设计流程
- 选定单一任务：先用一个边界清晰的长尾任务试点，不从“生成整个工作台”开始。
- 画出稳定骨架：确定导航、身份、权限、历史记录和全局反馈等不可随意变化的区域。
- 列出动态变量：标记哪些内容、组件和步骤可以随意图与上下文改变。
- 建立组件白名单：为每个动态组件补齐数据要求、状态、动作和组合限制。
- 制作多状态原型：覆盖信息充足、需要追问、执行中、部分失败、高风险确认和完成恢复。
- 用真实任务测试：观察用户能否理解生成结果、发现错误、修改范围并安全退出。
评审时不要只检查正常成功状态。可以使用AI 原型评审清单逐层核对结构、交互、状态和业务规则，但本页额外要求检查“同一意图在不同上下文下是否仍保持组件和操作一致”。
用墨刀验证生成式 UI 的多状态方案
生成式 UI 最终可能由模型与前端在运行时组合，但产品设计阶段仍需要先验证稳定骨架、动态区域和高风险状态。团队可以在墨刀设计中建立组件与页面规范，再在墨刀原型中串联追问、生成、确认、失败和恢复路径，把动态逻辑变成可点击、可评审的方案。
- 输入：用户任务、上下文变量、组件白名单和权限条件。
- 产物：稳定骨架、多状态页面、可点击任务路径与评审批注。
- 人工检查：生成内容是否真实、组件是否一致、危险动作是否确认、失败后能否恢复。
生成式 UI 上线前检查清单
- 页面明确区分固定区域和允许动态变化的区域。
- 每个动态组件都有使用条件、真实数据要求和完整状态。
- 系统在执行前展示识别到的意图、对象与影响范围。
- 模型推断不会被伪装成已确认的业务事实。
- 高风险动作使用稳定确认组件，并保留取消或撤销路径。
- 相同任务在不同上下文中仍保持术语、动作和结果一致。
- 加载、超时、部分失败、权限不足和人工接管均可完成。
- 键盘、屏幕阅读、颜色对比和移动端操作没有因动态组合失效。
常见问题
生成式 UI 会取代传统页面吗？
不会。稳定、高频和高风险任务仍需要固定界面；生成式 UI 更适合组合复杂、路径多变的长尾任务。多数产品会长期采用固定外壳与动态任务区并存的方式。
生成式 UI 就是聊天机器人加卡片吗？
不是。聊天只是输入方式之一。生成式 UI 的关键是系统能根据任务选择合适的表单、表格、图表、确认框或操作面板，并在任务变化时更新界面。
设计师还需要画页面吗？
需要，但工作重点会从穷举所有页面，转向定义稳定骨架、组件契约、动态规则、状态和安全边界。设计师决定系统允许生成什么，以及用户如何理解和控制它。
生成式 UI 的价值不是让界面无限变化，而是让复杂任务在需要时出现最合适的操作结构。先把任务、组件和权限约束清楚，再让 AI 负责组合；先保证用户能够理解、确认和恢复，再追求生成速度，动态界面才可能真正进入产品流程。
