这项由Google DeepMind、Google研究院与南加州大学联合完成的研究，已于2026年5月31日发表在预印本平台arXiv上，论文编号为arXiv:2606.01057v1。如果你对技术细节感兴趣，不妨直接用这个编号去arXiv上搜索，完整的论文正在那里等待你的探索。

一、当AI遇见3D建模：一场意义深远的变革

你是否曾好奇，那些让你沉浸其中的电子游戏，或是电影中令人惊叹的特效场景，背后究竟隐藏着怎样的秘密？答案其实很简单——三维模型。这些模型并非凭空产生，每一件都需要专业设计师坐在电脑前，花费数小时甚至数天，使用专业软件一点一点地“捏”出来。这个过程不仅耗时费力，还对设计师的艺术审美和编程能力提出了双重挑战，入门门槛相当高。

然而，人工智能的迅猛发展，为这个行业带来了全新的可能性：让AI自己编写代码来生成三维模型。这种方式在专业领域被称为“程序化三维建模”（Procedural 3D Modeling）。简单来说，它不再依赖手动拖动鼠标或调整参数，而是通过一段可执行的程序代码，精确描述一个物体的构造方式。这样生成的模型，不仅能够精确修改，还能被各种专业软件直接使用。更酷的是，它可以随机生成无数个风格相似、细节各异的变体——这是传统AI图像生成技术无法实现的功能。

事实上，业界早已有人在探索这个方向。例如，知名AI公司Anthropic曾高调宣布，让旗下模型Claude直接操控Blender（一款流行的开源三维建模软件）；各种基于模型上下文协议（MCP）的工具也如雨后春笋般涌现。但问题是，没有人能真正说清楚，这些AI的表现究竟如何。缺什么？缺一个公认的、严格的评估标准。这就好比一场烹饪大赛，各路大厨纷纷亮出绝活，但既没有裁判，也没有评分标准，谁也不清楚哪道菜才是真正的佼佼者。

为了填补这一空白，研究团队搭建了一个名为3DCodeBench的基准测试平台，专门用于评估AI的程序化三维生成能力。与此同时，他们还推出了3DCodeArena——一个让真实用户通过投票来比较不同AI生成结果的公开平台。这两套工具紧密结合，成为目前该领域最全面的评测体系。

二、什么是程序化三维建模？为何它如此独特且令人着迷

在公布评测结果之前，我们有必要先搞清楚“程序化三维建模”这个核心概念。

大多数人熟悉的AI图像生成，比如用文字描述“一只金毛犬”，眨眼间就能得到一张照片。但这本质上是一张“照片”，是由像素组成的集合。好看归好看，但它并非真正的三维物体，无法放入游戏引擎，无法从任意角度旋转查看，更别提精确修改某个零件的尺寸了。

程序化三维建模则完全不同。研究团队使用的是Blender 5.0，一款功能强大的专业开源三维软件。在Blender中，你可以用Python代码精确描述一个物体的每一根骨骼、每一块肌肉、每一片叶子的排列方式。当AI写出这样一段代码时，Blender就能“读懂”它，并生成一个真实的三维网格模型。这个模型可以从任意角度旋转查看，可以导入到游戏中，可以用3D打印机打印出来，也可以随时通过修改代码来调整细节。

打个比方你就明白了：普通AI图像生成就像给你一张房子的照片，而程序化三维建模则是给你一份建筑图纸，外加详细的施工说明——你不仅能看清房子的样子，还能照着图纸把它真真切切地建出来，甚至随时修改，比如“把二楼改成三楼”。

这种能力在游戏开发、工业设计、机器人训练仿真等领域，价值不可估量。但要让AI做到这一点，它必须同时掌握三项技能：准确理解用户的指令（比如“帮我建一只螃蟹”），熟悉Blender软件的API（即那些接口命令），以及具备足够的三维空间几何推理能力。这三项能力叠加在一起，对任何AI来说都是一项不小的挑战。

三、26000个测试案例是如何产生的？一条流水线的幕后故事

要评估AI的能力，首先需要高质量的测试题。研究团队为此投入了大量心血，打造了一个包含26000个样本的数据集。

这些数据的来源，是一个名为Infinigen的开源程序化场景生成系统。该系统内部存储着大量用代码写成的自然物体“工厂”——每种物体（无论是一棵树、一只螃蟹，还是一朵花）都有对应的程序代码，能够按照随机参数生成无数个变体。研究团队的任务，就是将那些复杂的“工厂代码”转换为独立可执行、简洁明了的Blender Python脚本，并为每个脚本配上文字描述和参考图片。

可别小看这个转换过程，它绝不仅仅是复制粘贴那么简单。原始的Infinigen代码结构极其复杂，包含各种嵌套调用和依赖关系，直接使用根本无法运行。为此，研究团队设计了一套“智能流水线”，流水线上配备了多个专门的AI工具，彼此分工协作。

例如，代码简化器的任务是将冗长、嵌套的原始代码整理成干净独立的脚本，同时严格保证生成的三维形状不走样。模拟器则负责在沙盒环境中实际运行生成的代码，检查是否有报错，并提取网格数据。视觉评审员是一个视觉语言模型，它会将生成物体的多角度渲染图与原始参考图反复比对，一旦发现视觉差异，便立即反馈给前面的步骤。还有网格分析器，专门检查三维模型本身的质量，比如是否存在无效几何体、非流形面，或者顶点数量是否异常。

此外，系统还维护着一个“经验库”，持续积累已成功处理的类别信息、常见错误的修复策略、Blender 5.0的API变更记录，以及如何将各种独立零件拼装成完整物体的模板。随着处理过的物体越来越多，这个经验库也变得越来越智能。

即便有了这套自动化的流水线，研究团队也并未盲目信任机器。每一个最终进入数据集的样本，都必须经过人工审核：检查代码能否正常执行，文字描述是否准确，渲染图是否与参考图吻合。只有通过了这道关卡的数据，才有资格进入最终的数据集。

最终，这套体系产出了涵盖212个物体类别的评测集，以及完整的约26000个“文字提示/参考图——代码——三维模型”三元组数据集，供后来的研究者用于训练模型。这212个类别包罗万象，从自然界的动植物（鸟类、螃蟹、蜻蜓、仙人掌、龙舌兰），到日常家具（床、书柜、厨房橱柜），再到建筑构件，几乎覆盖了程序化建模的主要应用场景。

四、代码的复杂度：远超你的想象

在整理数据的过程中，研究团队发现了一个有趣的现象：这些测试案例的难度，远远超过了业界现有的其他基准测试。

数据集中，每段脚本的平均代码行数为531行，中位数为387行。而像鸟类、螃蟹这类复杂的生物，或者像树木、橱柜这样精细的室内物件，其代码长度甚至会超过1000行。每段代码的文件大小，平均为20.5KB，中位数为14.9KB，分布呈现出明显的“长尾”特征——大多数物体的代码不算太长，但极少数复杂物体的代码体量却惊人地庞大。

这与之前那些“简单版本”的三维代码基准测试形成了鲜明对比。有些基准测试，只是让AI用几个几何基本体（球、方块、圆柱）拼出简单的形状；有些只考察在体素网格（像乐高积木那种方格结构）中搭建模型。这些测试的难度，与真实的专业需求之间，差距不是一星半点。而3DCodeBench要求AI具备真正的几何推理能力，而不仅仅是记住几条API调用命令——难度不可同日而语。

五、如何评分？评测体系的设计思路

有了测试题，还需要评分标准。研究团队设计了两套互补的评分机制，就像一场考试同时涵盖了客观题和主观题。

客观评分部分由一系列自动化指标构成。第一道门槛是代码能否正常运行。给AI一段文字描述，让它编写Blender代码，如果代码能在Blender中顺利运行，并生成一个有效的三维网格，就算“通过执行测试”，否则直接判为失败。这个指标被称为“可执行率”（Executability）。

通过执行测试的模型，还需继续接受外观相似度评估。具体做法是，将AI生成的模型从四个固定角度（45度、135度、225度、315度）拍摄成渲染图，然后使用两种专业的图像相似度算法——SigLIP-2和DINOv3——与参考图进行比较。这两者各有侧重：SigLIP-2更擅长捕捉语义层面的相似性，比如“这看起来像一条鱼”；而DINOv3更关注形状和结构层面的相似性，比如“轮廓和结构像不像”。

除了外观，研究团队还直接比较三维几何结构。他们拿AI生成的三维模型与标准参考模型，各自采样8192个表面点，然后用“倒角距离”（Chamfer Distance）来衡量两个点云之间的差异——数值越小，说明模型形状越接近真实参考。另一套工具叫Uni3D，它能够将三维模型、文字和图片都映射到同一个“语义空间”中进行跨模态比较，既能评估AI生成模型与参考模型在三维形状上的相似程度，也能评估AI生成模型与文字描述的匹配程度。

所有指标都以两种方式汇报：一种是“条件均值”，只统计成功生成模型的那些案例的平均分，衡量的是“成功的案例做得有多好”；另一种是“惩罚均值”，将失败案例计为零分后再取平均，衡量的是“整体表现到底如何”。这两种视角各有侧重，放在一起才能给出一个全面的评价。

主观评分部分，则由3DCodeArena平台负责。研究团队将不同AI生成的模型两两配对，放在一个公开平台上展示，让真实用户在不知道是哪个AI生成的情况下，投票选出哪个模型更好看、更像真实物体。这种方式模仿了著名的LMArena（语言模型人类偏好评测）的机制，使用Bradley-Terry算法将投票结果转换成Elo分数（一种常见于国际象棋排名的评分方法），最终形成一个可靠的排行榜。截至论文写作时，该平台已收集了约3100票。

六、12个顶尖AI的成绩单：谁是三维建模的高手？

研究团队对12个当前最先进的视觉语言模型进行了系统评测。这些模型阵营分明：来自谷歌的Gemini系列（包括Gemini 3 Flash、Gemini 3.1 Flash Lite、Gemini 3.1 Pro、Gemini 3.5 Flash、Gemma 4 26B、Gemma 4 31B），来自Anthropic的Claude系列（Claude Haiku 4.5、Claude Sonnet 4.6、Claude Opus 4.7），以及来自OpenAI的GPT系列（GPT-5.4 Mini、GPT-5.4、GPT-5.5）。有两个模型值得一提——Gemini 2.5 Pro和GPT-5.4 Nano，因为它们在单次对话中的代码执行成功率低于10%，被排除在了主要评测之外。

从最重要的可执行率来看，差距还是相当明显的。Claude Opus 4.7以91%的可执行率拔得头筹，GPT-5.5以90.6%紧随其后，GPT-5.4以86.6%排名第三。相比之下，Gemini 3.5 Flash只有46.4%，Gemini 3 Flash为48.1%，Gemma 4 26B为51.7%。这意味着，Gemini那些轻量级模型生成的代码，超过一半都无法在Blender中正常运行。

再看人类偏好Elo排名，GPT-5.5以1163分高居榜首，Gemini 3.5 Flash以1119分位居第二，Gemini 3.1 Pro以1147分排在第三，GPT-5.4以1074分位列第四。Claude Opus 4.7得到1006分，Claude Sonnet 4.6得到1015分，两者成绩相近，但明显落后于顶尖选手。表现最差的是Claude Haiku 4.5，只拿到799分，Gemini 3.1 Flash Lite也好不到哪去，877分入账。

研究团队还专门计算了每个模型的性价比。他们发现，Gemini 3.5 Flash每次查询只需要大约0.04美元，而GPT-5.5需要大约0.32美元——前者的成本还不到后者的八分之一，但Elo分数只低了大约44分（1119对1163）。如果在Pareto前沿（即最高性价比曲线）上追踪，四个最具性价比的节点中，竟然有四个都是Gemini模型。

七、失败的原因与成功后的缺陷：两类核心问题

数据给出了排名，但更有价值的，是搞清楚为什么会失败，以及成功执行之后，模型的真实质量究竟如何。

研究团队发现，绝大多数执行失败（大约85%-90%）都源自同一个原因：AI写的代码使用了Blender 4.x版本的旧API，而测试环境是Blender 5.0，两者之间存在接口不兼容。举几个具体的例子：Blender 5.0已移除了BSDF材质节点中的“Specular”（高光）参数，有些模型还在用旧写法，结果报错；`Mesh.use_auto_smooth`这个属性在5.0中也不存在了；`create_cone`函数的参数名也发生了变化。这些问题的根源，都是AI的知识截止日期——它在训练时接触的，很可能是更老版本的Blender文档，所以对新版API变更一无所知。

换句话说，大多数失败不是因为AI不会建模，而是因为AI“用了过时的施工规范”。这个发现既道出了问题所在，也指出了改进方向：只要给AI提供最新的API文档，或者让它从错误信息中学习修正，执行成功率就能大幅提升。

然而，即便代码能够正常运行，生成的三维模型也并非十全十美。从质性比较来看，AI生成的模型普遍存在两类视觉缺陷：一是几何部件之间“悬浮”或者“断开”，就像把一只螃蟹的八条腿分别放在空中，彼此之间毫无连接；二是过度简化，用几个浮动的基本几何体草草代替复杂的有机形态。Gemini 3.1 Pro倾向于出现第一类问题（部件断开），而Claude Opus 4.7则更容易出现第二类问题（过度简化）。

这说明，现有的AI虽然能写出“语法正确”的代码，但在“语义正确”这个层面——也就是真正理解一个物体是如何在三维空间中有机地构成整体的——还有相当大的提升空间。

八、思考时间越长越好吗？多轮对话效果如何？

研究团队还进行了一系列“变量控制实验”，以探索哪些因素会影响AI的表现。

关于“思考时间”（Thinking Budget），不同级别的模型展现出截然不同的规律。对于轻量级模型，增加思考时间效果相当显著：Gemini 3.1 Flash Lite从“最小”思考量到“最高”思考量，可执行率提升了约19个百分点。原因不难理解：额外的思考让模型有机会在输出代码之前，先在脑子里“排查”一下可能的API兼容问题，进行自我纠错。然而对于顶尖模型来说，这种提升几乎可以忽略不计——Claude Opus 4.7在最低思考量时就已经达到了极限水平，继续增加思考时间并没有什么帮助。这是因为强模型已经“记住”了正确的API，只需略微确认一下，并不需要大量的推理。这个发现提示我们：将高思考量分配给弱模型，比分配给强模型要划算得多。在实际应用中，根据模型的级别来配置思考资源，可以在节省大量成本的同时，维持接近最优的效果。

关于“输入图片数量”，研究团队测试了给AI输入1到4张参考图片的效果差异。结论有些出人意料：增加参考图片的数量，对生成质量的提升几乎可以忽略。SigLIP-2相似度在1到4张图之间的变化幅度不超过0.012，统计上没有显著意义。Uni3D三维相似度略有提升，但依然在误差范围内。这意味着，哪怕只给一张参考图，AI提取到的有效信息已经接近饱和，多余的图片并没有带来多少额外的几何理解增量。

九、让AI看错误日志，效果惊艳

单次对话的评测结果固然重要，但研究团队更感兴趣的是：如果让AI在失败后进行多轮修改，它能补救多少？

多轮错误反馈实验的设计很直接：对于执行失败的案例，研究团队将Blender的错误日志（截取前70%和后30%，总共不超过3000字符）连同之前失败的代码一起，丢给同一个AI模型，让它尝试修正，最多允许三次机会。

结果相当令人振奋。所有11个模型、22个评测单元（文本到3D和图片到3D两个轨道）的平均可执行率，从单次对话的69.2%跃升至97.2%，整整提升了27个百分点。其中，Claude Opus 4.7、GPT-5.4和GPT-5.5在两个轨道上都达到了100%的可执行率。不仅如此，生成质量也同步提升：SigLIP-2惩罚均值平均提升了0.128，Chamfer距离平均下降了0.079，Uni3D三维相似度平均提升了0.069。

研究团队特别强调，这些质量提升的数字是在固定的212个测试案例上计算的（失败案例贡献零分），因此完全排除了“因为成功案例变多导致分母变大”的干扰，真实反映了整体水平的提升。

背后的原因其实很简单：大多数失败都属于“局部可修复”的API错误——只要AI看到了具体的报错信息，就知道是哪行代码出了问题，改一改就好。这和人类程序员调试代码的经验高度一致：很多时候，看到报错比在那儿盲目猜测要有用得多。

十、给AI配上“智能编程助手”，还能更上一层楼吗？

研究团队还尝试了一种更进一步的方案：给每个AI配上它对应的“原生智能编程助手”工具，让AI在一定时间预算内完全自主地编写代码、运行测试、读取报错、修改代码、再次运行……循环往复，直到成功或者超时。

具体操作方式是这样的：Gemini系列用Gemini CLI，Claude系列用Claude Code，GPT系列用Codex CLI，每个实例的时间预算设定为600到900秒。AI会在沙盒目录里自主操作，研究团队只提供任务描述，其余完全交给AI自己决定。

结果是：这些智能助手工具确实进一步提升了可执行率，平均从71.6%提升到99.5%，有三个模型甚至达到了100%的执行率上限。然而，对于那些单次对话就能成功执行的案例，加了智能助手之后，生成模型的质量几乎没有变化——SigLIP-2只变动了-0.010，Chamfer距离只变动了+0.001，Uni3D三维相似度只变动了-0.003，这些差异几乎都在统计误差范围之内。

这个发现揭示了一个值得深思的现象：自动化的“修修补补”能修复API报错，但没办法让AI真正理解三维几何。一旦代码成功编译，模型的三维形状质量就基本定型了——智能助手并没有能力在后期“雕塑”出更精细的几何细节。这就好比一个工人能熟练地修好施工过程中的管道漏水，但却没有设计师的能力，去重新规划整栋建筑的布局。

十一、视觉自我审查：让AI看自己的作品，有用吗？

研究团队还测试了一种更具创造性的改进路径：让AI查看自己生成模型的渲染图，然后与原始描述或参考图片进行比较，再决定是否需要重写代码。

结果呈现出一个有趣的“任务不对称性”。在文字到3D的轨道上，视觉自我审查普遍有效：四个测试模型的SigLIP-2相似度平均提升了0.003到0.009，大多数模型的“改进次数”多于“变差次数”，比例从1.24到2.63不等。其中，Gemma 4 26B表现最好，50次改进对应19次退步。

然而，在图片到3D的轨道上，同样的模型却普遍变差了：SigLIP-2平均下降了0.006到0.009，改进/退步比例下降到0.58到0.78。研究团队分析认为，这种“同一批模型、同一个方法、但在不同任务上结果相反”的现象，根本原因在于指标的天花板效应：图片到3D任务的SigLIP-2基准值已经在0.78到0.81之间，非常接近参考渲染图能够达到的上限。在这种情况下，任何轻微的几何改动都可能在渲染外观上引入噪声，被评分系统判定为变差。换句话说，并不是AI改坏了，而是评分尺子在这个区间不够精细。

值得注意的是，模型的能力越强，作为“自我审查者”就越保守。Gemma 4 31B（较强模型）只对41%的案例说“需要修改”，而较弱的模型则激进得多，经常不必要地大幅重写代码，结果往往弄巧成拙。

十二、自动评分能代替人工投票吗？

3DCodeArena的人工投票固然可靠，但每一票都需要真实用户花时间观察和判断，规模化的代价相当高昂。因此，研究团队研究了一个关键问题：能不能用AI来代替人工投票？

他们用四个谷歌模型（Gemini 3.1 Pro、Gemini 3 Flash、Gemini 3.1 Flash Lite、Gemma 4 31B）对2508个真实投票案例进行了重新判断，每个模型分别以“看渲染图”和“看代码”两种模式工作，然后将评估结果与人工投票进行比对。

看渲染图模式的表现还算令人满意：四个模型的总体准确率在62.5%到64.7%之间，如果只看那些双方都做出明确选择（而非选择“平局”）的案例，准确率进一步提升到72.6%到74.4%。其中，Gemini 3.1 Pro在剔除“弃权”案例后准确率最高（77.1%），Cohen's kappa系数（衡量超越随机概率的一致性）达到了0.542，属于“中等偏高”的一致性水平。

看代码模式的表现则明显逊色：准确率下降到51.7%到56.9%，kappa系数只有0.249到0.348，属于“一般”到“中等”的一致性水平。这说明，仅凭读代码无法可靠地预测生成三维模型的质量，渲染图依然是不可替代的评估媒介。

研究团队还发现，SigLIP-2视图相似度与人类偏好Elo的皮尔逊相关系数高达0.964，DINOv3的Spearman相关系数更是达到了0.972，两个指标都与人工偏好高度吻合。这意味着，在大多数情况下，用SigLIP-2和DINOv3作为自动化评估指标，能够相当准确地代表人类的审美判断，没必要每次都进行昂贵的人工投票。

归根结底，3DCodeBench做的这件事，是给“AI到底会不会写三维建模代码”这个问题，提供了一个真正科学的答案：会，但还不够好。当前最强的AI，已经能让90%的代码在Blender里正常运行，但生成的模型往往在几何连贯性上存在明显缺陷——部件悬浮、比例失调、细节简化的问题普遍存在。更深层的问题在于，现有AI缺乏对三维空间物理规律的真实理解，写出来的代码“语法正确但语义模糊”。

这项研究还揭示了一条清晰的改进路径：让AI在执行环境中得到真实反馈、进行迭代修正，是目前提升性能最有效的手段。这远比增加思考时间或增加输入图片数量要有效得多。而要根本性地提升AI的三维推理能力，则需要大量高质量的程序化三维代码训练数据——这正是3DCodeBench的另一重重要价值所在：它所提供的26000个数据样本，为未来训练出更懂三维空间的AI，奠定了一块坚实的基石。

对于关心AI发展走向的读者来说，一个有趣的思考题浮上了水面：当AI能够流畅地将文字或图片转化为精确、可编辑的三维模型时，谁会是最大的受益者？是游戏开发者、建筑师、机器人工程师，还是我们每一个普通人？这个问题的答案，或许比技术本身更值得期待。

Q&A

Q1：3DCodeBench评测的是什么能力？和普通AI图像生成有什么区别？

A：3DCodeBench评测的是，AI能不能用Python代码在Blender软件里生成真正的三维模型，而不是生成一张好看的图片。普通AI图像生成，产生的是像素图片，无法从任意角度旋转，不能导入游戏，也没办法3D打印；而程序化三维建模，生成的是可执行的代码，编译之后可以得到真实的三维网格，能够精确修改、从任意角度查看，并且直接用于游戏开发、工业设计等专业场景。

Q2：为什么Gemini 2.5 Pro和GPT-5.4 Nano没有出现在排行榜里？

A：这两个模型在单次对话中代码执行成功率太低了：Gemini 2.5 Pro只有7.1%，GPT-5.4 Nano只有6.1%。研究团队分析后发现，它们大约85%的失败案例，都是因为使用了已经被Blender 5.0废弃的旧版API命令，这属于训练数据知识截止日期导致的问题，并不是建模能力本身有什么缺陷。由于成功案例太少，统计数字不可靠，所以被排除在了主要评测之外。

Q3：多轮错误反馈为什么能大幅提升AI的代码执行成功率？

A：因为大多数失败都属于“API不兼容”这种局部可修复的错误，比如某个函数参数名在Blender 5.0里改了，或者某个属性被移除了。当AI看到具体的报错信息（就像程序员看调试日志一样），就能精准定位问题所在，把那行代码修改掉。这和盲目地重新生成代码完全不同——有了错误提示，修复的成功率极高。研究数据显示，11个模型的平均可执行率从69.2%跃升到了97.2%，足以说明这种“看错误日志改代码”的方法非常有效。