Runway 发布 Solaris，要让操作系统一边用一边生成界面
2026 年 8 月 31 日，Runway 公布 Solaris，并称它是 Interface World Models（界面世界模型）这个新模型家族中的第一个模型。两个名字都出自 Runway 自己的表述：Solaris 是模型名，Interface World Models 是它自创的类目——目前没有其他机构采用这个术语。它要回答的问题很直接：如果操作系统在你使用的同时，把应用和网页生成出来，会是什么样。
Solaris 的做法是不预先生成页面。它每一帧都在你操作的那一刻被合成，界面本身由模型实时画出来，而不是由一份写好的代码把画面调出来。Runway 称 Solaris 建立在自家的 Gen-4.5 视频生成模型之上，沿着 GWM-1 通用世界模型的路线改造，目标有三条：实时交互、整场会话保持一致、画质在 720p 下站得住。
真正被删掉的是中间那一步。今天的设计稿再漂亮也跑不起来，它必须先被翻译成某种中间表示（intermediate representation），通常就是代码，然后才谈得上响应，才谈得上点击和拖拽。Solaris 押的是这次翻译不再必要：没有转换，就没有转换带来的损失，整帧画面本身就是界面。
类比中间表示像把一首歌先转成简谱再演奏：谱子能让人快速演奏，但演奏出来的已经不是原唱。
把界面翻译成代码，到底损失了什么？Runway 为此做了一组重建测试。
被翻译掉的到底是什么
Runway 的答案是保真度，而且它认为这种损失被长期低估。
它让当前的多模态语言模型做一件事：给一张界面截图，把界面重做出来。测试集按画面性质分成四档——纯网页、幻灯片、平面设计、自然图像——每档 30 个样本。衡量方式有三种。DINOv3 相似度把原图每个区域拿去和重建图里最相似的区域配对，判断底层视觉内容有没有活下来。CLIP 相似度从整体语义上比较重建结果与原图是否还对得上。结构相似度（SSIM）比较相同位置上的外观是否被复现。三条曲线画在同一张配图里，阴影带标注为 95% 置信区间。
结论是：所有被评测的语言模型在重建中都会损失信息，自然图像受影响最大，因为丰富的视觉细节很难被语言准确表示。界面越复杂，文字、布局或结构上的微小变化就越容易改变界面的实际行为。
配图上的数字是可以读出来的。以 DINOv3 相似度为例，Fable 5 从纯网页的约 0.91 降到自然图像的约 0.68，Gemini 2.5 Pro 从约 0.90 降到约 0.50，GPT-4o 从约 0.86 降到约 0.42。结构相似度那一栏整体更低，Fable 5 从约 0.74 降到约 0.32。四档之间，自然图像总是最低的一档，纯网页总是最高的一档，三条曲线的走向一致。
这些数字的出处需要说清楚。正文只写下结论，没有给出任何分数，读数全部来自配图；图例按发布年份把三个模型标为 GPT-4o（2024）、Gemini 2.5 Pro（2025）和 Fable 5（2026），其中 Fable 5 就是正文点名的 Claude Fable 5。四档怎么划、样本从哪里来，Runway 都没有说明；而三条曲线回答的是“重建得像不像”，不是“这个界面还能不能用”。
重建评测的三条曲线
| 衡量方式 | 测的是什么 | 边界 |
|---|---|---|
| DINOv3 相似度 | 把原图每个区域与重建图中最相似的区域配对，看底层视觉内容是否保留 | 对位置变化容忍度高，结构性错位可能不被惩罚 |
| CLIP 相似度 | 从整体语义上比较重建结果与原始界面是否还对得上 | 看整体语义，对局部文字与版式的具体偏差不敏感 |
| 结构相似度（SSIM） | 比较相同位置上外观是否一致，逐块对照结构、亮度与对比度 | 元素移动或布局变化时容易判为不同；不直接对应界面能不能用 |
把界面翻译成代码，会丢多少信息
当前多模态语言模型从单张截图重建界面时，保真度到底如何。
- 实验设置
- 给被评测的多模态语言模型一张界面截图，要求重建该界面；重建结果与原图分别用 DINOv3 相似度（区域最相似匹配）、CLIP 相似度（整体语义）和结构相似度 SSIM（原位外观）三条曲线比较。评测集按画面性质分为纯网页、幻灯片、平面设计、自然图像四档。
- 样本与轮次
- 四档各 30 个样本；每个模型的调用次数与提示词尝试次数未公布（未知）
- 模型
- Fable 5（配图标注 2026）、Gemini 2.5 Pro（配图标注 2025）、GPT-4o（配图标注 2024）
- 判定指标
- DINOv3 相似度、CLIP 相似度与结构相似度（SSIM）三条曲线，配图标注 95% 置信区间；正文没有给出阈值或任何评分线
- 对照或基线
- 以原始界面本身作为比较基准；除被评测模型外没有其他对照条件说明
结果：三条曲线都随界面复杂度上升而下降，自然图像一档最低：DINOv3 相似度上，Fable 5 由约 0.91 降至约 0.68，Gemini 2.5 Pro 由约 0.90 降至约 0.50，GPT-4o 由约 0.86 降至约 0.42；结构相似度一栏整体更低，Fable 5 由约 0.74 降至约 0.32。以上数值均由配图读出，为近似值。
边界：四档分类与样本由发布方划定，样本来源与选取标准未说明；正文没有给出任何数字，数值只出现在配图；没有模型版本与调用参数；DINOv3 与 CLIP 指标对元素位移容忍度高，结构性错位可能不被惩罚；结果衡量的是外观保真，不能推出生成界面在任务上更好用；由 Runway 设计并自跑，无第三方复核。
即便翻译确实有损，逐帧生成要顶上来，必须先跨过三道工程门槛。
半秒、整场会话、每一帧的成本
三道门槛分别是速度、会话一致性和成本，Runway 认为它们的组合正好把生成式界面挡在门外。
速度的问题是一条感受阈值：交互在半秒左右的延迟附近就不再像交互。视频扩散模型生成一段片段要花几秒到几分钟，这对做内容是可接受的，对做界面太慢。要跨过这条线，模型必须逐帧顺序生成，每一帧只依赖此前已经发生的东西，而且便宜到能跟上人的操作。
一致性的问题是时间尺度。界面得在整场会话里保持稳定，而不只是撑住一段短片。需要守住的东西——文字、布局、物体的身份——恰恰是生成视频历来最难维持的部分，而且生成越久，小错误越会叠加。
成本的问题更朴素：逐帧生成仍然比提供一个早就构建好的页面更贵。Runway 的辩护是，让 Solaris 变得实时的那套工作同时也让它比标准视频扩散模型便宜“数个数量级”，但公司没有给出金额、GPU 时长或比较口径，这个说法只能停留在定性层面。
具体做法上，Solaris 把用户输入当成下一帧的条件，和文本、图像一样对待。模型观察点击、拖拽等操作，把它们当作接下来该发生什么的信号。它只看到已经发生的交互，永远看不到未来的操作，于是学会动作与视觉结果之间的关系，不必为每种交互写死逻辑。从视频模型到实时引擎经过三步改造：先教会它自回归地逐帧生成；再把多步去噪蒸馏成少数几步；最后用这个快速模型自己的输出继续训练它，让长时间交互中的画质不塌。整套系统里，语言模型决定界面往哪走——理解请求、判断这次交互是修改当前场景还是切到新场景、给出渲染提示；世界模型负责把这个决定画出来。没有预定义屏幕，也没有模板可以退回。
三道门槛与 Runway 给出的解法
切换方案，查看它分别改变哪一层问题。
速度
作用对象 · 让交互在半秒左右的延迟线内不失去手感
- 它怎样起作用
- 改成逐帧自回归生成，每帧只依赖此前内容；再把多步去噪蒸馏成少数几步
- 希望带来什么变化
- 达到交互级生成速度，同时保留教师模型的画质
- 真正落地还缺什么
- 帧率、端到端延迟、码率与硬件条件均未公布
会话一致性
作用对象 · 整场会话保持文字、布局与物体身份稳定
- 它怎样起作用
- 用这个快速模型自己的输出继续训练它，抑制长时间生成中的误差累积
- 希望带来什么变化
- 避免小错误随生成时长叠加
- 真正落地还缺什么
- 没有给出连贯性的时间上限，也没有失效实例
成本
作用对象 · 让逐帧生成的运行成本可接受
- 它怎样起作用
- 让模型实时化的同一套改造也被认为降低了运行成本
- 希望带来什么变化
- 比标准视频扩散模型便宜“数个数量级”
- 真正落地还缺什么
- 无金额、GPU 时长与比较口径；逐帧生成仍贵于服务一个已构建页面
机制说得通，效果要看对比。Runway 的第二个实验把 Solaris 和被写成代码的界面放在了同一个起点上。
250 人、近 7500 次判断，测的是什么
测的是偏好，不是办事能力。
实验设计是：两套系统从同一张起始图像出发、接收相同的交互请求，一边由 Solaris 实时生成界面，另一边由当前最先进的语言模型 Claude Opus 5 生成编码界面。结果交给 250 名参与者、跨 30 个交互示例做二选一，共收集近 7500 次成对判断，每人回答两个问题——哪个结果更好地遵循了给定指令，哪个在场景里表现得更自然。
遵循指令一项，正文写的是 Solaris 61%、编码结果 24%，另有 13% 被判为等同。在“哪个在场景中表现得更自然”这一问上，Solaris 在 71% 的比较中被偏好，编码网站 21%，6% 被判为等同。但同一份研究的配图给的是 62%、25%、13% 与 72%、21%、7%：四个数字各差 1 个百分点，方向一致，看起来只是四舍五入的位置不同，Runway 没有说明。按正文的三项，两组各自相加都是 98%；按配图的三项，两组都刚好加到 100%。
Runway 对差距的解释是两种系统的行为方式不同。编码界面常常也能把被要求的那一处改动做出来，但它把这次交互当成对界面的孤立更新。界面世界模型已经理解物体、材质和环境怎么动，能做出在场景内自洽的响应。
证据强度需要说清楚。参与者怎么招募、来自哪里、是否知道哪一边是 Solaris、30 个示例怎么挑、评判者之间的一致性如何，都没有披露。这是一家发布方自己设计、自己运行、自己报告的偏好研究，而偏好“更自然”和“能真正把事办成”是两件事。
Runway 引用的 OSWorld 2.0 评测给出了同方向的数据：108 个长时程真实工作流，人类完成的中位时间约 1.6 小时，主口径是 500 步内的二元完成判定，得分最高的模型只完成 20.6% 的任务，GPT-5.5 约 13%。这篇论文与 Runway 无关，方向上支持“今天最好的模型仍不擅长电脑操作”，但它没有对 Solaris 做任何测试，评测的模型版本也与 Runway 提到的并不对应，因此只能说明大方向，不能替 Solaris 的性能背书。
250 人偏好研究：正文与配图的两组数字
遵循指令
哪个结果更好地遵循了给定指令？（正文数字）
Solaris61%配图写作 62%
编码界面（Claude Opus 5）24%配图写作 25%
被判为等同13%
自然行为
哪个在场景中表现得更自然？（正文数字）
Solaris71%配图写作 72%
编码界面（Claude Opus 5）21%
被判为等同6%配图写作 7%
数字取自正文；同一研究的配图给出的是 62%/25%/13% 与 72%/21%/7%
怎么读：两组数字回答不同问题，不能相加或混用；正文三项相加为 98%，配图三项相加为 100%，两处口径差 1 个百分点；均为发布方自跑的偏好比例，不是任务成功率，也无法跨场景外推。
同一张图、同一批请求，生成界面和编码界面谁更受欢迎
给定同一界面与同一用户交互，实时生成的界面与语言模型生成的编码界面，哪个在指令遵循和场景自然度上更受偏好。
- 实验设置
- 两套系统从同一张起始图像出发、接收相同的交互请求，记录各自响应；随后把成对结果呈现给参与者，要求回答“哪个结果更好地遵循了给定指令”和“哪个在场景中表现得更自然”。
- 样本与轮次
- 250 名参与者、30 个交互示例、近 7500 次成对判断
- 模型
- Solaris、Claude Opus 5（编码界面一侧的驱动模型）
- 判定指标
- 成对偏好比例（二选一加等同选项），按“指令遵循”与“自然行为”两个问题分别统计
- 对照或基线
- 对照为 Claude Opus 5 生成的编码界面，与 Solaris 使用相同起始图像和相同交互请求
结果：指令遵循：正文为 Solaris 61%、编码结果 24%、等同 13%；自然行为：正文为 71% 对 21%、等同 6%。同一研究的配图写作 62%、25%、13% 与 72%、21%、7%，与正文各差 1 个百分点。
边界：参与者招募方式、地域与筛选未知；是否盲评、呈现顺序是否随机化未说明；30 个示例由 Runway 选择；结果为主观偏好而非客观任务成功率，不能推出办事能力；正文三项相加为 98%、配图三项相加为 100%，同一研究的两处口径不一致且未作说明；参与者数、示例数与判断数均由发布方自报，无第三方复核。
哪个结果更好地遵循了给定指令？（正文数字）
Runway 列了四条它现在还做不到的事，其中一条直接关系到界面能不能被依赖。
文字、可信、长会话、无障碍
Runway 把 Solaris 目前的强项限定在环境动态、点击拖拽和场景切换上，其余列成待解问题。
文本最难。稳定、清晰的文字至今是视频生成里最麻烦的问题之一，而界面几乎比其他任何视觉场景都更依赖文字。Runway 提出的过渡办法是一个混合系统：文字密集的视图交给图像模型渲染，代价是允许一次短暂停顿；连续交互继续由视频模型处理。完全实时地生成文字仍然是开放问题。
第二条是可信度。对教学或商业体验来说，一个看起来很可信的错误答案比没有答案更糟。今天的 Solaris 靠你给它的起点保持锚定——起始帧可以由真实产品影像和参考资料组成，让场景扎在确实存在的东西上。把生成条件建立在更丰富的已验证上下文之上，比如参考图、产品数据、文档，是正在研究的方向；至于现在已经具备多少这种能力，Runway 没有说明。
第三条是长会话。在长时间、开放式的交互里维持视觉和语义一致，仍被列为活跃研究领域，既没有给出时间上限，也没有失效实例。
第四条是无障碍与集成。生成出来的界面还得在其余软件栈里工作，包括屏幕阅读器这类辅助技术和无障碍 API，否则灵活性会以可用性为代价。这四条不解决，生成的界面就只能在容错高的场景里停着。
四条未解问题的当前状态
| 对象 | 当前状态 | Runway 给出的方向 | 公开数据 |
|---|---|---|---|
| 文字渲染 | 未解决 | 文字密集视图改用图像模型渲染，允许短暂停顿；视频模型管连续交互 | 无效果数据 |
| 可信度 | 靠用户提供的起始帧锚定 | 把生成条件建立在参考图、产品数据、文档等已验证上下文上 | 未说明现阶段具备多少能力 |
| 长会话一致性 | 列为活跃研究领域 | 未给出路径 | 无时间上限、无失效实例 |
| 无障碍与集成 | 未说明进展 | 接入屏幕阅读器与无障碍 API | 无 |
按 Runway 公开表述归纳，强项被限定在环境动态、点击拖拽与场景切换
怎么读：定性覆盖不等于性能评分，也未披露任何量化指标或完成度；四行状态全部来自发布方自述，无第三方核验。
如果这些限制被解决，先变的可能不是画质，而是软件的计价方式和应用目录。
从“构建一次、服务很多次”到“每帧重来”
真正的结构变化在成本那一侧。网页今天之所以能服务海量用户，是因为它只被构建一次，之后打开几乎是廉价的复制。Solaris 的每一步都要重新生成一帧，Runway 自己承认这仍比服务一个早就建好的页面更贵，它的赌注是成本曲线继续往下走。
这条取舍决定了它最可能先出现在哪：个性化要求高、能容忍短暂停顿、不承担关键后果的展示型界面——店面、配置器、教程，而不是需要精确文字和可审计结果的场景。
四种被提到的新形态都从这个方向长出来。应用不再是被交互的单位。今天要办成一件事，得先找到为它预先写好的那个 app，购物一个、新闻一个、订餐一个。如果操作系统能根据你想做的事直接生成界面，把软件归进固定目录的理由就变弱了。视觉概念不必再翻译成 UI 框架、组件和代码，任何画面都可以直接变成可交互的界面。店面不再是每个访客看到的同一份固定布局，而是保留品牌识别、按个人意图实时重排产品和材质的环境。教程不再为所有人重放同一段，而是按你的进度渲染下一步，在你偏离脚本时自然恢复。
另一层变化藏在交互本身。如果交互可以用自然语言描述，它就不必提前固定下来，场景里的每个对象都可能变成一种新工具。点一下猫，接下来的点击会把它的毛色和质感带到你触碰的东西上。点一下油画，你可能就开始用它的风格画画。鼠标不再只是选择器，而是把任何对象临时变成工具的开关。
四种被设想的新形态
| 场景 | 今天 | 界面由模型生成时 |
|---|---|---|
| 应用的单位 | 每件事都要先有一个预先构建好的 app | 需要时直接生成界面，把软件归进固定目录的理由变弱 |
| 设计到界面 | 视觉稿必须翻译成 UI 框架、组件和代码 | 任何视觉概念可以直接变成可交互界面 |
| 店面 | 所有访客看到同一份固定布局 | 保留品牌识别，按个人意图实时重排产品与材质 |
| 教程 | 为所有人重放同一段流程 | 按你的进度渲染下一步，偏离脚本时自然恢复 |
证据支持到哪一步
Solaris 回答的是一个真问题：如果界面不用先被写出来，软件会长成什么样。它在机制上确实拿掉了那次翻译，代价是把正确性从一次性的编译搬到了每一帧——界面每一次都要重新挣得自己的正确性。
证据目前支持到哪一步，需要分开看。“翻译会丢信息”这个方向有 30 个界面的重建测试撑着，但没有任何分数；“生成界面更受欢迎”有 250 人和近 7500 次判断撑着，但那是主观偏好，而且全部由发布方自设自跑。至于逐帧生成能否在文字、可信度和长会话上稳定下来，Runway 自己把它们列成了未解问题。
更准确的判断是：这是一次在“像不像”和“顺不顺手”层面成立、在“靠不靠得住”层面尚未验证的转向。改变这个判断需要三件事同时出现。Solaris 公开发布，并有第三方在同样口径下复现那些数字；文字渲染这类硬约束出现可用的解法；逐帧生成的成本降到能长期服务真实用户的水平。在那之前，它更像一次把软件前提重新摆上桌的试探，而不是一次可以依赖的替换。
