OUI-1 让小模型生成界面，但通过解析器还不等于软件可用

作者：林岚｜OC 开发者生态编辑

据 Thesys 工程团队 9 月 8 日介绍，OUI-1 是基于 DiffusionGemma 微调的开放权重模型，专门生成 OpenUI Lang 界面描述。它拥有约 260 亿总参数、40 亿激活参数，团队称 FP8 版本可在 RTX 5090 运行。权重遵循 Gemma 使用条款，不能把“开放权重”简单理解成没有任何许可限制。

一句话结论：OUI-1 最有价值的不是又一段“一句话生成页面”的演示，而是把生成结果变成能够逐项检查的程序；不过，结构合法只跨过了软件可用性的第一道门。

它并不是让模型自由写一个网站

生成式 UI 很容易和 AI 写前端混在一起。两者都可能出现按钮和卡片，但工程目标不同。自由写代码要面对组件、样式、依赖和运行环境；受约束的界面语言则先划定可用积木，再让模型组合它们。这样，宿主应用可以掌握实际渲染和执行能力。

一个组件是否存在、参数是否齐全、引用的名称有没有定义，都能被解析器判断。模型不再仅凭“看起来像代码”获得奖励，而是有一部分错误会当场暴露。对于即时生成的界面，这种约束很重要：用户不应该每打开一次表单，就赌一次整个前端工程是否能编译。

但约束语言并不会消除业务风险。假如用户要“列出未付款订单”，界面正确生成了表格，数据筛选条件却反了，所有组件仍可能顺利渲染。支付按钮也可以长得很合理，却没有接上正确的审批条件。程序能被读取，和程序在替谁做什么，是两种不同检查。

训练中最有意思的是修错，而不是堆更多示例

团队描述了一条用解析器反馈筛选、修复生成样本，再继续训练的路线；最终又把方法扩展到多个组件库。在其生成式 UI 基准中，OUI-1 得分为 71.7%，基座为 13.0%。这说明特定任务适配有明显空间，但这个分数属于团队所用评测，不能解释成“真实网站有七成能上线”。来源：发布说明

这里可以抽出一个更普遍的工程启发：如果任务存在廉价、明确的失败信号，就应尽早接入，而不是等大模型写完后再让另一个模型笼统评价“是否优秀”。缺少字段就是缺少字段，悬空引用就是悬空引用，不需要用文学评论式提示词兜一圈。

然而，自动筛选也会产生新的盲区。如果奖励只覆盖容易机器检查的结构，模型可能越来越会过结构测试，却没有同等程度地理解用户意图。增加一个评判模型能补充信息，但评判模型也可能误判，不能因此把“意图已验证”当作绝对事实。

本地运行解决不了所有产品问题

小一些的激活参数量和消费级显卡支持，意味着更多团队可以研究自托管。但总权重、量化格式、上下文缓存和推理实现仍会决定实际资源需求。40 亿激活参数并不意味着只需存放一个 40 亿参数模型，FP8 能运行也不等于任意精度和任意并发都能运行。模型信息见 OUI-1 模型卡

对于产品，另一个更难的问题是稳定性。界面每次生成都变样，用户可能找不到上次的位置；刚准备点击时布局又流式变化，还可能误触。OC 认为，生成式 UI 应明确哪些部分允许变化，哪些操作必须固定，何时停止重排，以及如何保留用户已经输入的数据。

一个实际验收例子是报销表单。首先检查界面描述能否解析，其次检查字段是否符合报销制度，再检查键盘导航、必填提示、重复提交、网络失败和草稿恢复。最后还要确认“提交”只提交当前用户有权提交的内容。只有前两层过关，还不足以让它进入财务流程。

这也解释了为什么生成式 UI 未必会让前端工程消失。它更可能把一部分工作从“写每个页面”转向“设计组件契约与验收边界”。这份工作不那么适合演示视频，却决定了用户敢不敢真的点下按钮。

关键事实

• 来源：Thesys 发布说明、OUI-1 模型卡和 OpenUI 基准页面。
• 核心技术：扩散模型微调、OpenUI Lang、解析器反馈驱动的样本筛选与修复。
• 关键数字：约 260 亿总参数、40 亿激活参数；71.7% 为特定基准分数。
• 限制：开放权重有使用条款；结构合法、语义符合与实际交互可靠需要分别验收。

OC 判断

OUI-1 把一个值得推广的方向做得更具体：先缩小输出空间，再利用可验证反馈提升质量。但最危险的误读，是把“解析器没报错”当成产品已具备安全和可用性。真正可部署的系统，仍需让模型只能组合被批准的组件，并让重要操作经过稳定的权限与状态管理。

为什么重要

• 对开发者：组件契约和确定性校验可以成为生成式应用的重要资产。
• 对企业：本地部署应与许可、资源预算和业务验收一起评估。
• 对用户：界面可以动态生成，但操作含义和失败恢复不能跟着随机变化。

参考来源

• Thesys：Introducing OUI-1
• OUI-1 模型卡与权重
• OpenUI：Generative UI Benchmark