Code World Model 的差距
Code World Model 是指语言模型被训练来模拟程序执行的系统——逐步预测运行时状态，而不仅仅是生成语法上合理的代码。当今的最先进技术集中在少数几篇论文上，包括 Debugging code world models、Meta FAIR 的 CWM: An Open-Weights LLM for Research on Code Generation with World Models 以及 Code World Models for General Game Playing。以下是这些差距的结构化梳理。
🧱 Gap 1：分词从根本上不适用于状态追踪
想想子词分词器的工作方式——它们将 “hello” 拆分成 hel、lo 这样的片段。现在想象追踪一个字符串变量经过 20 次操作的值。每一次字符级别的变更都会级联导致分词不匹配。
- 失败不成比例地集中在字符串类型的状态上，而非数值或布尔类型；其根本原因是子词分词，而非模型对程序逻辑的理解。
- 解决方案需要转向字节级或无分词器表示以实现稳定的字符级计算——但目前还没有 CWM 架构在大规模上做到这一点。
⏳ Gap 2：长程状态追踪崩溃
想象需要记住并更新 50 行代码中 20 个变量的所有变化而不遗忘任何信息——这就是长程问题。
- 当前的 CWM 在长执行轨迹上表现严重退化。关键是，这种退化主要由错误的动作（指令）生成驱动，而非局部状态更新的失败。
- 这意味着模型幻觉的是下一步应该执行哪条指令，而不是错误地应用了一条指令。解决方案可能需要更好的控制流建模，而不仅仅是改进状态更新规则。
💸 Gap 3：密集执行轨迹的 Token 效率低下
CWM 训练的每一步都需要在每一条命令后暴露完整的运行时状态。对于一个 100 行的程序，这意味着 100 次完整的状态转储。
- 这造成了严重的 token 预算耗尽问题，导致长历史程序的轨迹被截断。
- 一个关键的开放性问题是：CWM 能否在稀疏观测（即每 N 步才查看一次状态）下工作？当前的架构并非为此设计。超越密集监督可能需要线性循环或状态空间架构（如 SSM/Mamba），而非普通的 Transformer。
🌐 Gap 4：困在 Python / 单语言孤岛
当前最先进的技术（包括 Meta 的 32B CWM）本质上是一个纯英文、纯 Python 的模型。
“将代码世界建模数据集扩展到其他编程语言或符号执行留待未来工作。“——CWM: An Open-Weights LLM for Research on Code Generation with World Models
- 多语言泛化（例如扩展到 C、Rust、JavaScript）完全没有得到解决。
- 符号执行（一种形式化验证技术）作为互补信号也未被探索。
🎮 Gap 5：缺乏对部分可观测性或随机性的基础支持
游戏相关的 CWM 工作揭示了另一个根本性差距：现实世界的程序和环境通常具有隐藏状态（例如并发线程、随机种子、I/O）。
- 当前的 CWM 假设完全可观测、确定性的执行环境。
- 处理随机性或部分可观测的程序（例如多线程代码、I/O 依赖的分支）是一个开放性问题，文献中尚未提出解决方案。
🔁 Gap 6：缺乏基于执行的在线 / 主动学习
人类程序员通过运行代码并观察输出来学习——这是一个迭代的反馈循环。CWM 目前无法做到这一点。
- CWM 缺乏机制来主动查询解释器、发现新程序中的因果机制、或基于实时执行反馈更新其世界模型。
- 文献中最接近的类比是 What I cannot execute, I do not understand: Training and Evaluating LLMs on Program Execution Traces 论文（Meta/Edinburgh），但它关注的是在轨迹上_训练_，而非_在线交互_。
🔗 Gap 7：世界模型知识未在下游得到利用
这可能是最具战略意义的差距。CWM 的愿景是，一个_理解执行_的模型应该在代码生成、调试和验证方面表现得更好。
“在各种任务中稳健利用世界模型知识以及用代码世界模型进行规划，留待未来工作。“——CWM: An Open-Weights LLM for Research on Code Generation with World Models
- 我们还没有方法将训练好的 CWM 作为智能体的规划预言机来使用——类似于 Dreamer/MuZero 将世界模型用于强化学习中的规划。
- 论文本身做了一个类比：当前的 CWM 就像_思维链之前的 LLM_——核心能力已经存在，但部署它的脚手架尚未搭建起来。