事件与背景

2026 年 10 月 21 日，开发者 Simon Edw（simedw.com）发布实验项目 WorldTUI：他把 Qwen2.5-Coder-0.5B 微调成一个 360M 参数的「终端世界模型」。这个终端背后没有 shell，也没有文件系统——每次按键以真实终端会发出的原始字节输入，模型直接预测屏幕上有哪几行要改写、光标落在哪里。

它能建文件、开 vim 编辑保存、在 tmux 里分屏切换、跑 snake，还能维持环境变量和简单的变量展开。作者自己最看重的不是「像」，而是一致性：写一个文件、离开、跑十几条命令再回来，内容还在不在。

几个硬指标（均来自原文）：

• 训练数据是 336k 条 episode、约 2B token，全部由 Docker 里真实运行的 shell 录制而成——按键与屏幕逐帧对齐，公开数据集里找不到现成的，只能自己造。
• 最终模型 360M 参数（砍掉 15 万词表的 embedding 表后从 494M 降下来），int4 量化后 208MB。
• 训练与后续迭代合计 约 75 GPU 小时，单张 RTX 4090。
• 词表只有 333 个 token：256 个字节 token + 64 个行操作 token + 少量特殊符号，解码用语法约束，保证每次输出都是合法的屏幕更新。
• 浏览器 Demo 用自写的 WGSL compute shader 跑 Qwen 解码器，权重在 GPU 上解包，全部推理都在标签页里完成，不上传任何数据。

技术上最值得读的是两处优化。其一是按行并行解码：整屏重绘原本约 3000 个 token，逐 token 生成慢到不可用；因为行与行大多独立，作者用 batch 的每个元素生成一行，把 3000 步压到最长一行的约 100 步，再用同一个模型做投机验证修补行间冲突，大帧 p95 延迟从 6.7 秒降到 0.87 秒。其二是 DAgger 式自修复训练：让模型在自己的错误状态上继续预测，再构造「把它改回正确屏幕」的修正样本；只用了约三分之一的采样 session，就把 PresetBench 从 24/47 提到 38/47（int4）。作者特意加了一条限制——修正里出现的内容必须在此前真实屏幕或用户输入中出现过，否则等于在奖励幻觉。

来源（均已用 curl 验证返回 200）：

• WorldTUI: I trained a 360M model to pretend to be a terminal — SimEdw，2026-10-21
• 在线 Demo：粘贴任意终端画面，让模型接着往下演（建议桌面 Chrome/Edge）
• GameNGen：Diffusion Models Are Real-Time Game Engines（世界模型的对照系）
• Genie 3 — Google DeepMind（大规模交互式世界模型）
• NeuralOS：用神经生成模型模拟操作系统

为什么现在重要

1. 世界模型的成本地板被拉到了「一张消费级显卡」。 过去一年，交互式世界模型的公开代表是 Genie 3、GameNGen 这类大厂项目，隐含门槛是集群与海量视频。WorldTUI 证明：把世界从像素降到字符网格、把数据从视频换成可无限合成的真实会话，75 GPU 小时就能得到一个能维持局部一致性的世界模型。影响判断：世界模型不再是只能看 demo 的研究方向，小团队可以把它当工程问题来试。

2. 「预测下一个屏幕」是和「预测下一个 token」不同的接口契约。 它输入的是按键字节与光标状态，输出的是行级差分，天然贴合 GUI/终端自动化。影响判断：做 computer-use agent 的团队，未来可能不需要真开一台 VM 就能预测某步操作的界面结果，从而把「试错」放到模型里做。

3. 真正的资产是合成数据管线，不是模型。 作者随机化用户名、主机名、提示符、终端尺寸（32×96 为主，兼有 24×80、40×120），按人设生成目录与文件，以 1.2% 的 typo 率逐键输入，并让 35% 的 session 从「半途」开始。影响判断：任何有内部 CLI/后台系统的团队，都能用「Docker + 按键/屏幕对齐录制」复刻这条管线，数据规模不必从 33.6 万条起步。

4. 蒸馏的评估陷阱比蒸馏本身更值钱。 作者删掉第 7 层后，next-token 准确率只从 99.3% 掉到 98.9%，看起来无损；但精确记忆回读从 64/64 直接变成 0/64。另有一个 16 层学生模型在 ShellBench 上 65/106（教师 78/106），记忆测试却 64/64 全过。影响判断：用 loss 或 token 准确率验收小模型，会系统性地放过「看起来正常、其实已经失忆」的模型。

5. 它同时是一次诚实的边界展示。 嵌套目录里会突然「走到别的路径」，Python 稍复杂就退化成 GPT-3 级别的胡编，Firefox 比 Chrome 慢约 20 倍且原因未明。影响判断：这类系统的可靠区间目前是「熟悉的命令、短链路」，产品化必须自带失败检测，而不是假设它会一直对。

工程师/产品人今天能做什么

1. 用你自己的命令去压测 Demo，而不是看 benchmark。 在桌面 Chrome 打开 Demo，粘贴一段你日常的终端画面，按顺序敲 20 条你真实会用到的命令（尤其是 cd 嵌套、管道、git 状态切换），记录它第一次「编造输出」的位置。这份记录比任何分数都能告诉你它离你的场景有多远。
2. 给 agent/computer-use 项目加一条「屏幕差分」测试。 同一条操作序列，分别在真实环境和模型预测环境跑，比较最终屏幕的字符级差异。先只覆盖 20 条核心流程，就能量化「模型模拟器」是否值得引入。
3. 复用数据配方做小规模验证。 用 Docker 起你的内部工具，录 5k–10k 条按键到屏幕的 episode（不必 33.6 万条），先验证「模型能否学会你产品的状态机」，再决定要不要扩大。
4. 把状态一致性写进蒸馏/量化的验收标准。 至少加一组「写两个随机值 → 隔 18 条命令 → 读回」的测试，和 token 准确率并列。WorldTUI 的记忆基准只有 64 次回读，却直接暴露了层剪枝的致命损伤。
5. 盯权重发布。 作者写明权重「很快发布」，但截至 10 月 23 日其 GitHub 上还没有 worldtui 仓库。拿到 208MB 的 int4 权重后，可以完全离线地在 CI 里跑界面回归，不依赖任何云端推理。

待观察

• 权重尚未公开。 文章只说 “I’ll post the weights soon”，GitHub 账号下暂无对应仓库；在权重放出前，所有结论只能基于作者自述与在线 Demo。
• Firefox 慢 20 倍的原因未查明。 两边都走 WebGPU，作者明确写了「还没找到原因」。这决定它能否作为跨浏览器的稳定组件。
• 一致性的天花板在哪。 作者提出的下一步是「用成千上万个随机生成的应用训练，看模型能否预测从未见过的应用行为」，以及用 diffusion 替代自回归解码。这两条都还没有结果，也是这个方向最值得跟进的信号。