OUI-1发布：AI开始直接生成界面

OpenUI近日发布 OUI-1，并将其定义为“全球首个面向 Generative UI 的模型”。这次更新的重点不在于让模型写出更多 HTML 或 React 代码，而在于让模型直接交付一个可以被用户操作的界面：输入一个需求，模型生成页面、组件、交互逻辑和视觉呈现，用户可以在结果里继续点击、拖动、筛选或修改。

**Generative UI 是一种由 AI 根据用户意图实时生成完整交互体验的技术，而不只是生成文字、图片或代码。**传统聊天机器人把答案放在对话气泡里，OUI-1试图把答案变成一个小型应用。问“帮我理解 DNA 转录”，它不只返回一段科普文字，还可以生成 DNA 链、RNA 聚合酶动画、步骤标注、差异对比和可拖动时间轴；问“比较三款相机”，它可以生成带筛选器、参数对比和购买决策入口的界面。

从“生成答案”到“生成使用答案的方式”

**OUI-1的核心变化，是把模型输出从内容层推进到了体验层。**过去的 AI 产品通常有一套预先设计好的页面：聊天页、表格页、搜索结果页、图表页，模型只负责把内容填进去。Generative UI 则反过来，页面形态本身也由模型根据任务决定。

这种区别看起来像是 UI 的变化，实际影响的是产品架构。一个固定界面需要产品经理提前定义流程，设计师绘制页面，工程师实现组件，再把数据接入其中。面对开放式问题时，产品只能在预设模板里寻找一个勉强合适的容器。OUI-1的设想是让模型在运行时完成部分“产品设计”：判断用户要比较、学习、规划还是执行，然后选择合适的布局和交互方式。

比如，同样是“帮我制定一周的健身计划”，传统聊天机器人会输出一张文字清单；普通 AI 应用可能打开一个固定的计划模板；Generative UI 则可以生成按天切换的卡片、动作演示、强度滑杆、替换动作按钮和完成状态。用户每点击一次，界面都可能根据新的意图继续调整，而不是重新开始一轮问答。

这也是 OUI-1 与“让大模型写前端代码”之间的关键差异。代码生成关注的是能不能产出可运行的实现，Generative UI 更关注用户能不能立刻理解并完成任务。前者像让 AI 交付工程文件，后者像让 AI 现场搭建一个可用工具。

OUI-1到底生成什么

**OUI-1生成的不是一张 UI 截图，而是包含视觉结构、组件状态和交互行为的动态界面。**从 OpenUI 发布信息来看，它面向的输出包括网页、工具、应用和交互式体验，用户可以直接在生成结果中进行操作。

这类系统至少需要处理四层内容：

1. 语义层：理解用户究竟想获得信息，还是想完成任务。例如“解释光合作用”和“帮我设计一个光合作用实验”对应的界面不应相同。
2. 结构层：决定页面由标题、卡片、表格、时间轴、图表、输入框还是按钮组成，并安排它们的层级关系。
3. 状态层：记录用户点击、拖动、选择和输入后的变化，让界面不是一次性渲染，而是可以持续响应。
4. 执行层：把交互动作连接到计算、检索、数据处理或其他工具上，否则生成的页面只能“看起来像应用”，却不能真正工作。

其中最难的是状态层和执行层。生成静态 HTML 并不算新鲜，真正的难点是让“点击按钮后发生什么”稳定、可预测，并且让下一轮生成能够理解当前页面已经处于什么状态。

从工程实现看，Generative UI大致有三条路线：

| 实现路线 | 工作方式 | 优点 | 主要问题 | 典型适用场景 | |---|---|---|---|---| | 组件映射 | 模型输出结构化意图，前端从组件库中选择并渲染 | 稳定、安全、性能可控 | 灵活性受组件库限制 | 企业助手、数据面板 | | 声明式 Schema | 模型输出符合预定义协议的页面结构和状态 | 比固定组件更灵活，便于校验 | Schema 设计复杂，表达能力有限 | 表单、流程、可视化工具 | | 运行时生成代码 | 模型直接生成 HTML、CSS、JavaScript 或 React 并在沙箱执行 | 自由度最高，能快速做出新形态 | 稳定性、安全性和一致性较差 | 原型、教育模拟、一次性工具 |

**OUI-1的产品价值，最终取决于它在自由生成与可控执行之间找到什么平衡。**如果完全依赖运行时生成代码，用户看到的可能是每次都不一样的页面，按钮失效、布局溢出和状态丢失都难以避免；如果严格限制在固定组件库里，它又会退化成更聪明的模板填充器。

它与 Claude Artifacts、Vercel AI SDK有什么不同

**OUI-1并不是第一个让 AI 生成可交互内容的产品，但它把“Generative UI”本身作为模型能力来定义。**目前行业里已经有几种相近实践，区别主要在生成对象和控制边界。

| 产品或方案 | 主要生成对象 | 交互方式 | 灵活性 | 稳定性判断 | |---|---|---|---|---| | OUI-1 | 面向任务动态生成的界面与体验 | 页面内直接操作，并可继续修改 | 目标是较高 | 取决于模型与运行时约束 | | Claude Artifacts | HTML、React、SVG、文档和小应用等产物 | 在独立产物区域预览和操作 | 高 | 代码质量决定稳定性 | | Vercel AI SDK Generative UI | 将模型输出映射到预先定义的 React 组件 | 由应用控制组件和数据流 | 中等 | 较高，工程可控 | | 固定模板式 AI 应用 | 预设页面中的动态内容 | 只能在既定流程内操作 | 较低 | 最高，但扩展慢 |

Claude Artifacts更像“AI 写完一个可以运行的项目，再把它展示出来”；Vercel AI SDK更像“开发者提供一套组件，模型决定什么时候调用它们”；OUI-1则试图让模型承担更多界面编排工作。三者不是简单的替代关系，开发者最终仍可能把模型生成能力放进一个受控的组件运行时里。

Google在近期发布的 Generative UI 研究与产品实践也说明，行业正在从“聊天窗口是否足够”转向“答案应该以什么形态呈现”。Google披露的评测中，生成式界面相较传统 Markdown 输出获得了 82.8% 的用户偏好；在与人工设计网站的比较中，约 44% 的案例达到相当或更优水平。需要注意的是，这些数字来自 Google 的研究语境，并不代表 OUI-1已经取得同样成绩，不能直接当作 OUI-1的性能数据。

OUI-1最有用的地方，不是替代设计师

Generative UI最先有价值的场景，是那些需求变化快、交互成本高、但不值得单独开发完整产品的任务。

第一类是教育和知识解释。复杂概念很难用一段文字讲清楚，交互式动画、可调参数和分步演示能让用户主动探索。比如物理实验可以让用户调整摩擦力和初速度，数据结构课程可以让用户拖动节点观察树的变化，医学科普可以用分层图展示器官结构。

第二类是数据分析。用户通常不是想“看一张固定图表”，而是想不断追问：按地区拆分会怎样？去掉异常值后呢？两个时间段能不能叠加比较？如果每个问题都要回到产品经理预设的筛选器，效率很低。动态生成界面可以根据分析路径即时添加图表、筛选条件和解释卡片。

第三类是个人决策。旅行规划、课程选择、硬件对比、财务预算等任务，本质上需要在多个变量之间反复权衡。表格、滑杆、权重设置和情景模拟，比一段“推荐理由”更接近真实决策过程。

第四类是内部工具和原型。公司里有大量只被几十个人使用的工具：排班、审批、数据清洗、设备配置、测试面板。它们通常不值得投入数周开发，但也不是一段脚本就能解决。让 AI 生成一个可操作的临时界面，可能比生成一份代码更快产生结果。

但它不太可能马上替代成熟软件。财务系统、医疗系统、生产控制台和高频协作工具需要权限、审计、可复现、性能和长期维护，这些要求与“每次按提示生成一个新界面”存在天然冲突。对这类场景，AI更适合生成界面草稿、辅助配置和解释层，而不是直接接管核心操作。

真正的门槛：可靠性，而不是视觉效果

**Generative UI的最大风险不是页面不好看，而是页面看起来合理却没有正确表达任务。**模型可以生成一套漂亮的仪表盘，但如果指标口径错了，交互结果就可能比纯文本更具误导性，因为视觉界面会给用户一种“这是经过系统验证的产品”的错觉。

至少有五个问题需要长期解决：

• 交互一致性：按钮、筛选器和拖动控件是否真的改变了正确的状态。
• 数据可信度：界面中的数字来自哪里，是否过期，是否经过权限校验。
• 状态持久化：用户离开页面后，设置、历史操作和结果能否恢复。
• 安全隔离：运行时生成的代码不能随意访问浏览器、文件系统或业务凭证。
• 可访问性：动态界面是否支持键盘操作、屏幕阅读器、移动端和不同语言。

对于开发者来说，最合理的架构不是把所有权限交给模型，而是让模型负责“提出界面和动作计划”，由运行时负责校验和执行。模型可以请求“创建一个日期范围选择器”或“调用销售数据查询”，但真正的工具权限、参数范围和数据访问仍应由服务端控制。

换句话说，OUI-1的落地形态大概率不是一个无边界的 AI 浏览器，而是“模型 + 组件协议 + 工具系统 + 沙箱”的组合。模型负责理解意图和编排，组件协议负责约束输出，工具系统负责连接真实数据，沙箱负责限制执行风险。

对开发者意味着什么

**OUI-1带来的变化，是前端开发的交付单位可能从“页面”变成“界面能力”。**过去开发者会设计一个固定的订单页、分析页或设置页；未来更重要的工作可能是定义一组可组合、可验证、可观测的 UI 原语。

这些原语不只是按钮和输入框，还包括：

• 带数据权限的查询组件；
• 支持撤销和回滚的操作组件；
• 能解释计算过程的图表组件；
• 记录状态变化的表单组件；
• 对模型输出进行 schema 校验的渲染器；
• 能被模型调用、但边界清晰的业务工具。

这对前端团队提出了新的要求。组件不能只考虑视觉一致性，还要描述自己的输入、输出、状态、错误和权限；设计系统不能只服务于人工设计稿，还要让模型能够理解何时使用、如何组合以及哪些参数不能修改。

同时，产品经理也需要重新思考“需求”。在固定应用里，需求通常是“做一个页面”；在 Generative UI 里，需求更像是“定义用户想完成什么，以及哪些动作必须可靠”。页面不再完全由设计稿提前决定，而是由目标、约束和组件能力共同决定。

现在值得不值得关注

**OUI-1值得关注，但目前更应该被看作 Generative UI 的方向性产品，而不是已经成熟的通用应用生成器。**它最重要的贡献，是把行业讨论从“AI 能不能写出前端代码”推进到“AI 能不能直接交付可用的交互体验”。

如果 OUI-1只能生成漂亮但脆弱的演示页面，它的价值会接近高级原型工具；如果它能够在多轮操作中保持状态、正确调用工具，并对生成结果提供稳定的安全边界，那么它可能成为 AI 助手产品的新基础设施。

判断它是否真正成立，建议重点观察四项指标：

1. 同一个任务重复生成时，界面和行为的一致性如何；
2. 用户修改需求后，模型能否局部更新，而不是整页重做；
3. 生成的交互是否能连接真实数据和业务工具；
4. 复杂任务中是否有错误提示、权限控制、撤销机制和审计记录。

这四项比首屏视觉效果更重要。因为 Generative UI 的终点不是“让 AI 做出一个看起来像产品的页面”，而是让页面成为完成任务的可靠工具。

结语：聊天框可能只是过渡形态

**OUI-1释放的信号是，AI产品的竞争正在从回答质量延伸到交互形态。**当模型可以根据每个问题即时生成不同的界面，固定的聊天框就不再是唯一入口：学习问题可能变成模拟器，分析问题可能变成工作台，规划问题可能变成可调整的决策面板。

这并不意味着所有软件都会消失。更现实的变化是，软件的固定外壳会逐渐变薄，模型、工具和组件会在其中动态组合。OUI-1是否能把这个愿景推进到可用阶段，还要看其公开能力、运行时稳定性和真实用户反馈。但至少在 2026 年 9 月这个时间点，Generative UI已经从研究概念进入了模型产品竞争，值得开发者开始重新设计自己的组件系统和 AI 交互架构。

参考来源

1. Google Research：Generative UI 研究介绍 —— 介绍 Google 对 Generative UI 的定义、实现方向及 Gemini 和 AI Mode 中的产品化实践。
2. Google Research 相关论文检索入口 —— 用于追踪 Generative UI 相关论文、项目实现与开源讨论。
3. GitHub：Generative UI 相关项目检索 —— 汇总组件映射、Schema 渲染和运行时代码生成等实现方向。

注：本文关于 OUI-1 的发布信息与产品定位，依据 OpenUI 官方博客《OUI-1: world's first model for Generative UI》整理；OUI-1的公开性能、价格、上下文窗口和完整技术规格，以官方后续披露为准。