VoxelCodeBench¶
VoxelCodeBench: Benchmarking 3D World Modeling Through Code Generation
VoxelCodeBench 的定位很明确：它是一个用来测量大模型空间推理能力的基准。任务被定义为：给定文本说明和少量 API 文档，模型需要写出 Python 代码，在 Unreal Engine 体素环境中构建正确的 3D 场景。
核心问题¶
论文关注的问题很直接：
当大模型可以写代码时，它是否也真的具备了 3D 空间构造能力？
作者的判断是，现有代码基准多半测算法题或通用编程，但很少真正检验：
- 坐标映射是否正确
- 几何组合是否成立
- 多物体布局是否合理
- 生成场景是否在空间上满足文字描述
于是论文选择把“3D 世界建模”改写成 API 驱动的代码生成问题，并显式执行代码看结果，而不只检查语法表面正确性。
1. VoxelCode 平台¶
VoxelCodeBench 建立在配套环境 VoxelCode 之上。
其核心设置是：
- 用 Unreal Engine 作为执行与渲染后端
- 用体素 API 作为建模接口
- 模型输入为自然语言任务说明、API 文档和少量示例
- 模型输出为 Python 代码
- 平台执行代码并渲染结果，用于人工和自动评估
论文特意使用并不常见的专用体素环境，而不是互联网上随处可见的 3D Python 库，目的就是尽量避免模型依赖训练集中已有代码模板。
2. 任务设计¶
整个 benchmark 包含 220 个任务，围绕三类能力展开。
Symbolic reasoning¶
约 80 个任务，主要检查：
- 坐标理解
- 基本 API 调用
- primitive 放置
- 规则图案和文字重建
Geometric construction¶
约 50 个任务，主要检查：
- 参数化几何构造
- 布尔操作
- 循环 / 递归构建
- 复杂形状组合
Artistic composition¶
约 90 个任务，主要检查：
- 多物体场景组织
- 风格化构图
- 主题场景搭建
- 具有功能语义的结构布局
这种划分很重要，因为它把“会不会写 API”与“有没有真正的空间推理能力”分开了。
3. 为什么这个基准有意义¶
VoxelCodeBench 的关键点在于：它不把“代码是否能运行”当成充分条件，而是继续问：
- 输出里有没有可见对象
- 位置是否正确
- 材质是否正确
- 形状是否正确
- 整体观感是否合理
这和很多传统代码基准不同。后者往往只需要程序通过测试；这里则要求程序真正生成空间上正确的结果。
因此，这个基准特别适合检验 code-as-3D-representation 这条路线里的一个薄弱点：
从文本到代码并不难，从代码到正确 3D 世界才难。
4. 实验结果透露了什么¶
论文评估了多种通用和代码模型。结果显示：
- 顶尖模型可以较稳定地产生可执行输出
- 但几何构造和多物体组合仍明显更难
- artistic prompts 有时反而更容易，因为允许一定解释自由度
以文中结果看，GPT-5 在总体 shape correctness 上达到约 87.9%，但在 geometric construction 类任务中下降到约 66.7%。这说明模型在：
- 基本 API 使用
- 简单对象搭建
方面问题不大，但一旦涉及更严格的几何关系和组合推理，性能会明显掉下去。
论文的核心结论可以概括成一句话：
可执行代码比空间正确代码容易得多。
5. 常见错误类型¶
论文还分析了几类典型错误：
- hallucinated API 名称
- 执行超时或崩溃
- 类型解包错误
- 基本语法错误
其中最有代表性的是第一类：模型会写出“看起来像真的”但实际并不存在的 API。也就是说，它在做语言层面的合理猜测，而不是严格服从文档。
这类错误说明空间推理问题里还有一个额外困难：模型不仅要规划 3D 结构，还要稳定地服从一个陌生 API 的约束。
6. 在这条技术路线中的位置¶
如果说 GeoCode 和 MeshCoder 研究的是“如何得到程序化表示”，VoxelCodeBench 研究的则是：
当程序表示被用作 3D 输出时，模型到底在多大程度上真的理解了空间？
因此它更像一把“量尺”。
它不直接提升生成质量，但能帮助我们区分：
- 模型只是会写几行能跑的代码
- 还是已经具备较强的三维空间构造能力
这对后续程序化 3D 代理、场景生成代理和 CAD-aware 代理都很重要。
一句话总结¶
VoxelCodeBench 的价值，在于把 3D 空间推理问题变成可执行代码评测，并清楚地表明：当前模型离“真正写对 3D 世界代码”还有距离，尤其在复杂几何和多物体组合上。