Runway Solaris 把应用当成实时视频生成：界面世界模型对开发者意味着什么

2026 年 8 月 31 日，Runway 发布了 Solaris，把它定义为「界面世界模型」（Interface World Models）这一全新类别的第一个模型。过去的 AI 编程工具是让模型写 HTML、CSS、JavaScript，再由浏览器渲染；Solaris 完全跳过了代码这一步——模型直接逐帧生成应用界面本身，用户的每次点击、拖拽、输入，都只是下一帧画面的条件信号。软件不再「运行」，而是「生成」：它只作为一条持续的图像流存在。The New Stack 与 CMSWire 在 9 月初的报道都强调同一个反直觉点：这个应用底下没有任何代码。本文拆解 Solaris 的工作原理、它对开发者角色意味着什么，以及当界面生成沿着图像/视频生成的老路变快、变稳时，你该提前准备什么。

1. Solaris 到底是什么

Runway 给 Solaris 的定义是 Interface World Model：一个把渲染与交互整合进单一世界模型的系统，直接逐帧输出动态交互界面，而不是先产出中间代码层。用户在虚拟服装店里浏览，把自己的照片拖到衣架上的衣服上试穿，系统实时给出连贯的下一帧。Runway CEO Anastasis Germanidis 在发布材料里强调，这绕开了 HTML 与 CSS 的约束——因为不再有「文档对象模型」，界面只是模型想象出来的画面流。The New Stack 与 CMSWire 的报道都指出，关键区别在于这不是「AI 写代码更快」，而是「交互本身成为生成过程的输入」。

# Concept: an Interface World Model maps (state, action) -> next frame.
# No DOM, no CSS, no code: the frame IS the software.
def next_frame(model, current_frame, user_action):
    return model.generate(current_frame, user_action)

frame = load_frame("checkout.png")
action = {"type": "click", "x": 420, "y": 310}   # "Pay now" button
frame = next_frame(model, frame, action)          # frame changes

2. 与 AI 编程工具的架构差异

主流 AI 编程（Claude Code、Codex、Cursor）的范式是：模型生成代码 → 构建工具编译 → 运行时执行 → 用户看到界面。Solaris 的范式是：模型接收界面状态与用户动作 → 直接生成下一帧。前者里代码是可审计、可测试、可版本控制的中间产物；后者里中间产物消失了，剩下的是帧序列与交互流。这个差异带来双刃剑：好处是视觉一致性可以做到像素级——模型从图像/视频生成继承了画面连贯性；代价是你失去了传统工程里的「源码」，所有测试、审查、回滚都要围绕动作流与帧哈希来设计，而不是围绕代码 diff。

# The prompt that drives a Solaris-style interface session.
PROMPT = {
    "task": "Build an e-commerce checkout flow",
    "constraints": {
        "style": "minimal, high contrast",
        "locale": "en-US",
        "payment": ["card", "wallet"],
    },
    "state": {"cart": ["item-1", "item-2"], "total": 89.90},
}

# Every user action becomes conditioning for the next generated frame.

3. 开发者还需要写代码吗

短期答案：需要，而且可能更需要。Solaris 这类系统擅长的是「界面外观与交互手感」，但软件不只是界面：购物车要算钱、订单要落库、库存要扣减、支付要过网关——这些业务逻辑仍然要由传统代码与 API 承担。生成式界面更像一个「前端壳」，壳下面还是你熟悉的架构：后端服务、数据库、第三方集成。真正变化的是前端岗位的技能结构：从「手写响应式布局」转向「设计好的提示词、约束与状态契约」，以及「验证模型生成的界面没有破坏业务状态」。AI 图像生成没有消灭设计师，界面生成也不会消灭前端，但会重写前端的工作内容。

# Latency is the make-or-break metric for frame-based UIs.
# Human perception wants <100ms per interaction -> frame.
def is_responsive(frame_ms, threshold_ms=100):
    return frame_ms < threshold_ms

print(is_responsive(45))    # feels instant
print(is_responsive(320))   # feels laggy, unusable for input

4. 测试与可靠性：没有 DOM 之后怎么验证

传统 UI 测试断言 DOM 元素、类名与事件；没有 DOM 时，断言对象变成帧与动作流：点击坐标后帧是否按预期变化、总价是否与商品行一致、支付成功后是否进入确认画面。截图对比、帧哈希与动作回放会成为主力的回归手段，而业务状态一致性（购物车总价 = 商品价格之和）依然要靠 API 层测试来兜底。换句话说，E2E 测试从「浏览器自动化」转向「动作流 + 帧校验」；可访问性测试也更难——屏幕阅读器依赖语义树，而生成式画面流可能根本没有语义树，这是无障碍社区接下来要盯的最大风险。

5. 延迟、成本与内容安全：三道坎

界面生成要走向生产，先要过三道坎。第一道是延迟：人类能感知 100ms 左右的交互卡顿，逐帧生成必须逼近实时，这对推理基础设施是巨大压力，也解释了为什么这类模型必然先跑在云端而非端侧。第二道是成本：每一帧都是一次推理，长时间会话的 token 或帧计费会快速累积，需要按会话做成本预算。第三道是内容安全与一致性：生成式系统可能把错误信息画得很漂亮，也可能在长会话中慢慢「漂移」出与业务状态不符的画面；你需要帧级审计日志与状态一致性校验，把「看起来对」和「真的对」区分开。

# In a code-free interface, testability moves to the action stream.
def log_interaction(session_id, action, frame_hash, ok):
    entry = {
        "session": session_id,
        "action": action,
        "frame_hash": frame_hash,
        "ok": ok,
    }
    # persist entry for replay and regression checks
    return entry

print(log_interaction("s-42", {"type": "drag", "dx": 120}, "a1b2c3", True))

6. 现在该做什么

给团队的落地建议分三层。第一层（今天就能做）：把前后端 JSON 契约与 API 测试做扎实——无论界面由谁生成，业务边界都要稳；用 JSON 格式化工具与 API 测试工具把这块基础打牢。第二层（未来 6-12 个月）：把「界面 = 帧流 + 状态契约」的思维引入设计规范，开始积累动作流录制与回放能力，为生成式 UI 的回归测试做准备。第三层（保持关注）：盯住延迟与成本曲线——当单帧生成成本降到某个阈值，交互式生成界面会从演示品变成真产品，就像视频生成曾经走过的路。别急着重构你的前端，但一定要重构你的认知：软件可能不再是被「写」出来，而是被「生成」出来，而你作为工程师的价值，会越来越体现在定义约束与守护状态上。

# Classic reliability concerns still apply to generated apps.
def check_state_consistency(cart_total, line_items):
    expected = sum(i["price"] for i in line_items)
    if abs(cart_total - expected) > 0.001:
        return "BUG: total does not match line items"
    return "OK"

print(check_state_consistency(89.90, [{"price": 49.95}, {"price": 39.95}]))