当视频模型开始生成界面：Runway Solaris 观察
先说结论
8 月 31 日，Runway 发布了 Solaris 研究预览，并把它称为 Interface World Model。
官方描述很大胆：这不是一个普通的视频生成器，而是一种新型“操作系统”，窗口、菜单、滑杆等界面由视频模型实时生成，方向包括场景化视频、游戏界面、创意工具和产品原型。
我对这件事的判断是：如果 Solaris 的可操作性能够成立，它改变的不是“视频能生成得更漂亮”，而是界面本身可能不再是预先写好的组件集合。
但现在还不能把它写成成熟产品。当前公开信号主要来自 Runway 官方账号和一个 X List 旁证，公测资格、API、状态持久化和独立测试都没有明确资料。下面是方向分析，不是能力评测。
过去的界面是什么样的
我们熟悉的软件界面有一个稳定假设：
固定组件 + 固定状态 + 固定事件处理 + 固定数据模型 = 可操作应用一个按钮是一个 DOM 节点，一个滑杆有明确的数值，一个菜单项对应一条路由。即使界面由游戏引擎或 Canvas 绘制，背后通常仍然有一套确定的 UI 状态机。
传统的生成式 AI 主要生成的是内容：
提示词 → 图片 / 视频 / 音频它可以生成一个看起来像软件的画面，但这个画面通常只是结果，不是一个可以持续操作、保存状态、撤销和再次打开的应用。
Solaris 想挑战的是中间那条边界：
意图 → 模型生成当前界面 → 用户动作 → 模型理解动作后的世界状态 → 生成下一帧界面如果这条循环稳定，界面就不再只是“渲染数据”，而变成了模型对世界状态的一种实时投影。
它和 GUI Agent 不是一回事
最近也有很多 GUI Agent：模型看屏幕，点击按钮，输入文字，拖动鼠标。这些系统通常是在已有界面上行动。
可以这样对比：
| GUI Agent | Interface World Model | |
|---|---|---|
| 界面从哪里来 | 人或程序预先构建 | 模型实时生成或重构 |
| 模型的主要动作 | 点击、输入、滚动 | 生成状态，同时响应动作 |
| 状态来源 | DOM、Accessibility Tree、截图、应用 API | 视觉/世界状态与动作反馈 |
| 主要难点 | 找到正确控件并执行 | 保持界面、状态和动作的一致性 |
| 失败形态 | 点错、找不到、权限不足 | 界面好看但状态不真实或不可持续 |
所以不能因为两者都“会用界面”，就把 Solaris 当成另一个 computer-use 模型。它更接近：模型不仅使用工作台，还参与生成工作台。
真正困难的不是画出一扇窗
从演示画面看，窗口、菜单和滑杆并不难想象。真正难的是这些东西必须具备软件的性质。
1. 状态要持久
用户拖动滑杆之后，数值应该进入某个可恢复的状态，而不是下一帧又随机回去。
动作 A → 状态 S1 → 关闭界面 → 重新打开 → 仍然得到 S1如果状态只存在模型的短期上下文里，它就更像一次互动幻觉，而不是应用。
2. 动作要可重复
同样的点击在同样的状态下，应该产生相同或可解释的结果。视频模型天然带有生成随机性，而软件交互依赖确定性。
这会要求系统把“视觉帧”和“真实状态”分开：
可生成的显示层 ↓可验证的状态层 ↓可执行的动作层如果没有状态层，用户看到的按钮和系统真正接受的动作可能不是一回事。
3. 界面要能被机器理解
固定 UI 有 DOM、Accessibility Tree、语义标签和键盘焦点。模型生成的界面如果只有像素，接入自动化、辅助功能和测试都会变得困难。
一个真正可用的 Interface World Model，至少需要回答：
- 当前有哪些控件
- 每个控件的语义是什么
- 哪些控件可以操作
- 操作会改变哪些状态
- 屏幕阅读器和键盘如何访问它们
“看起来像按钮”不等于“它是一个按钮”。
4. 延迟必须足够低
普通视频生成可以等几秒甚至几分钟。界面交互不能每次点击都等一段完整视频生成。
用户会期待：
按下按钮 → 立即看到反馈 → 状态逐步稳定因此 Solaris 更像实时世界模型，而不是离线视频模型。它要解决的不是单次画质，而是连续生成、状态更新和输入响应之间的延迟。
5. 失败要能撤销
固定应用里的错误操作通常可以 undo、回退或重新加载。生成式界面如果把每次状态变化都当成新一帧，就必须有明确的历史：
S0 → S1 → S2 → S3 ↑ undo / fork否则用户很难知道一次错误是模型生成错了，还是自己的操作真的改变了数据。
我会怎样评估它
如果 Solaris 之后开放试用，我不会先截几张好看的图，而会做一套重复性测试。
| 测试项 | 需要观察的结果 |
|---|---|
| 同一 prompt 重复生成 | 结构和交互是否稳定 |
| 连续拖动滑杆 | 状态是否连续、是否丢输入 |
| 关闭后重新打开 | 状态是否持久化 |
| 快速连续点击 | 是否丢事件或进入错误状态 |
| 断网后恢复 | 能否继续或明确失败 |
| 键盘操作 | 是否有焦点和可访问语义 |
| 自动化操作 | 是否能通过 API/语义层定位控件 |
| 撤销与分支 | 是否能回到之前的状态 |
| 长时间运行 | 延迟和状态漂移是否累积 |
我尤其关注“同一个任务跑十次”的成功率。生成界面最容易在单次演示里看起来惊艳，真正决定它是不是产品的是第十次还能不能找到同一个按钮。
它可能先在哪些地方成立
游戏
游戏本来就接受动态世界和非固定界面。模型生成一个场景化的控制层，可能比在办公软件里生成表单更自然。但游戏仍然需要物理规则、存档、碰撞和多人同步，视觉生成不能替代底层状态机。
创意工具
创作工具的界面本来就经常围绕当前任务变化。用户在做分镜、调色或构图时，需要的控件不一样，动态生成一个任务专用工作台有实际价值。
产品原型
这是最容易落地的方向：不是直接替代生产软件，而是让用户用自然语言快速得到一个可交互的原型。这里对确定性的要求相对低，但仍然需要能保存和分享。
场景化学习
教学界面、模拟实验和可视化解释也可能受益。模型不只是给一段答案，而是根据用户的理解程度生成一套可以探索的界面。
也要警惕一个误区
“界面由模型生成”不代表界面一定更好。
固定组件的价值就在于稳定、可预测、可测试。动态生成会带来新的成本：
- 用户每次打开都看到不同布局
- 团队无法复用操作教程
- 自动化脚本容易失效
- 产品问题难以复现
- 视觉一致性和品牌规范变复杂
- 安全敏感的操作可能被模型藏在不明显的位置
所以我不期待所有软件都变成生成界面。更现实的形态可能是：稳定的底层状态和权限 + 针对当前任务生成的工作台视图。
最后
Runway Solaris 目前还是研究预览，很多关键问题没有答案。它值得关注，不是因为一条视频里出现了会动的菜单，而是因为它把一个问题摆到了台面上：
界面究竟是程序的固定外壳，还是模型理解世界后生成的一种临时视图？
我暂时不会把它叫作“下一个操作系统”。但如果它能把生成画面、真实状态、语义操作和持久化历史接在一起，那它可能会成为一种新的软件入口。
现在先等它从演示里出来，给别人真正点几下。