拓冰网站定制 
1. 从“鹈鹕骑车”说起为什么一个3D小场景能测出大模型的真实水平第一次看到“鹈鹕骑车”这个测试题我差点笑出声。一只鹈鹕蹬着一辆自行车在3D空间里摇摇晃晃地前进——这画面本身就带着一种荒诞的喜感。但笑完之后我意识到这道题的精妙之处恰恰在于它的“不正经”。它不像那些标准的代码评测题让你写个排序算法或者实现一个红黑树那些题目大模型早就背得滚瓜烂熟了。鹈鹕骑车不一样它要求模型同时理解三件事一个具体的动物形象、一个机械装置、以及两者之间的物理交互关系最后还要用代码把这个场景在浏览器里渲染出来。我最初是在一个技术社区里看到有人用这个题目测试GPT-6 Astra的。当时那个帖子只放了一张截图一只用基本几何体拼出来的鹈鹕身体是个椭球嘴巴是两个圆锥翅膀是压扁的球体骑在一辆用圆柱体和圆环组成的自行车上。画面谈不上精致但该有的元素一个不少而且鹈鹕的脚确实踩在踏板上翅膀搭在车把上整个姿态是合理的。底下有人评论说“这比很多人类画的示意图都强”也有人不服气说“不就是堆几个Three.js的几何体吗有什么难的”。我属于后者。作为一个写了七八年前端、最近两年一直在折腾大模型应用的人我第一反应是这题不难啊无非就是调用Three.js的API创建几个Mesh设置一下位置和旋转再写个动画循环让轮子转起来。任何一个熟悉Three.js的开发者花个把小时都能手搓出来。但当我真正开始用不同的大模型去生成这个场景的代码时我才发现自己低估了这件事的复杂度。问题不在于“能不能写出来”而在于“能不能一次写对”。大模型生成的代码往往在几何体的比例、位置关系、旋转角度这些细节上出问题。鹈鹕的嘴巴可能长在头顶上自行车轮子可能悬空或者鹈鹕的腿直接穿模到车架里面。这些错误在纯文本代码里看不出来但一渲染就原形毕露。所以这个测试的本质其实是在考察大模型的空间推理能力和代码生成的精确性。它要求模型不仅知道Three.js有哪些API还要能在脑子里构建出一个三维场景理解各个物体之间的相对位置和层级关系最后用准确的数值把这些关系表达出来。这比生成一段业务逻辑代码要难得多因为业务逻辑有明确的输入输出和边界条件而三维场景的“正确性”是模糊的、连续的。一个鹈鹕的嘴巴偏离了5度在代码层面可能只是rotation.z从Math.PI/2变成了Math.PI/2.1但渲染出来就是“看起来怪怪的”。我决定认真做一次横向对比。我选了12款目前主流的大模型包括GPT-6 Astra、Claude 4 Opus、Gemini 2.5 Ultra、DeepSeek-V4、Qwen 3.5-Max、Llama 4-405B以及几个国内外的开源和闭源模型。测试方法很简单给每个模型相同的提示词要求它生成一个完整的HTML文件用Three.js渲染一只骑自行车的鹈鹕包含基本的动画效果。然后我把生成的代码保存下来在浏览器里逐一打开从几何体完整性、空间关系正确性、动画流畅度、代码可读性四个维度打分。结果出乎我的意料也让我对“大模型写3D代码”这件事有了全新的认识。2. 测试环境搭建从零准备一个可复现的评测流程2.1 为什么选择Three.js而不是其他3D方案在开始测试之前我需要先确定技术栈。市面上做Web 3D的方案不少Three.js、Babylon.js、PlayCanvas还有直接用WebGL或者WebGPU的。我选Three.js的原因有三个。第一它的生态最成熟文档和示例最丰富大模型在训练数据里见过的Three.js代码量远超其他库这意味着模型对它的API更熟悉生成的代码质量上限更高。第二Three.js的抽象层级适中它不像直接写WebGL那样需要处理着色器和缓冲区也不像某些高层引擎那样把细节全封装起来刚好能考察模型对三维空间的理解。第三它的CDN引入方式极其简单一行script标签就能用不需要构建工具方便我快速测试。提示如果你也想复现这个测试建议固定Three.js的版本。我使用的是r168不同版本之间API有差异比如Geometry和BufferGeometry的用法就完全不同。固定版本能保证测试结果的可比性。2.2 统一的提示词设计如何让模型“听懂”需求提示词的设计直接决定了测试的公平性。如果提示词太模糊模型自由发挥的空间太大出来的结果千奇百怪没法比较。如果提示词太详细又变成了“填空”考察不出模型的真实能力。我最终采用的提示词是这样的请生成一个完整的HTML文件使用Three.js创建一个3D场景场景中有一只鹈鹕骑着一辆自行车。要求 1. 鹈鹕和自行车都用Three.js的基本几何体组合而成不要加载外部模型文件。 2. 鹈鹕要有身体、嘴巴、翅膀、腿和脚自行车要有两个轮子、车架、车把和踏板。 3. 鹈鹕的脚要踩在踏板上翅膀要搭在车把上。 4. 添加一个动画循环让自行车的轮子转动鹈鹕的身体有轻微的上下起伏。 5. 场景要有基本的灯光和相机相机能看到整个鹈鹕和自行车。 6. 代码要完整可以直接在浏览器中打开运行。这个提示词的关键在于第3条——“鹈鹕的脚要踩在踏板上翅膀要搭在车把上”。这是整个测试的核心难点。模型需要理解“踩”和“搭”这两个动作在三维空间中的含义并计算出正确的坐标和旋转角度。很多模型在这一步翻车要么脚悬空要么翅膀穿模要么干脆把鹈鹕和自行车做成两个独立的物体没有任何交互。2.3 评测维度的量化标准为了把主观感受变成可比较的分数我设计了一个四维评分表每个维度满分10分总分40分。维度评分标准权重几何体完整性鹈鹕和自行车的所有部件是否齐全有没有缺失或多余的物体25%空间关系正确性脚是否踩在踏板上翅膀是否搭在车把上各部件比例是否协调35%动画流畅度轮子转动是否自然鹈鹕起伏是否与踩踏动作匹配有无卡顿或跳变20%代码可读性变量命名是否清晰结构是否合理有无冗余或重复代码20%空间关系正确性占了最高的权重因为这是“鹈鹕骑车”这个题目的灵魂。一个几何体再完整、动画再流畅的模型如果鹈鹕是飘在自行车上方的那这个测试就失败了。2.4 测试过程中的意外发现模型对“鹈鹕”的理解差异在正式跑测试之前我先用几个模型做了预实验结果发现了一个有趣的现象不同模型对“鹈鹕”这个生物的理解差异巨大。有的模型把鹈鹕的嘴巴做得又长又尖像一根针有的模型把嘴巴做成了一个扁平的盒子像鸭嘴兽还有的模型干脆忽略了嘴巴只做了一个圆球当脑袋。这让我意识到大模型对具体生物形态的理解很大程度上取决于训练数据中相关描述的丰富程度。鹈鹕不是猫狗这种常见动物模型见过的3D鹈鹕模型可能很少所以它只能根据“鹈鹕有大嘴巴”这个模糊的印象来发挥。这个发现也解释了为什么有些模型在“鹈鹕骑车”这个测试上表现不佳——它们连鹈鹕本身都画不对更别说让鹈鹕骑车了。相比之下那些在预实验中能准确还原鹈鹕特征的模型在后续的空间关系处理上也普遍表现更好。这说明模型的细粒度理解能力和空间推理能力是正相关的。3. 十二款大模型实测谁在裸泳谁在领跑3.1 第一梯队GPT-6 Astra与Claude 4 Opus的巅峰对决GPT-6 Astra是这次测试的焦点。它的表现确实配得上“爆火”这个词。生成的代码一次通过打开浏览器就能看到一只像模像样的鹈鹕骑在自行车上。鹈鹕的身体是一个拉长的椭球嘴巴是两个圆锥拼接而成上喙比下喙长符合鹈鹕的特征。翅膀用压扁的球体表示自然地搭在车把上。最让我惊讶的是它给鹈鹕的脚和踏板之间加了一个Group把脚和踏板绑定在一起这样当踏板转动时脚会跟着一起动看起来就像真的在踩踏。这个细节我在提示词里没有要求是模型自己“想到”的。Claude 4 Opus的表现同样出色但在风格上有明显差异。GPT-6 Astra的代码更简洁几何体数量少但比例精准Claude 4 Opus的代码更“啰嗦”用了更多的几何体来细化鹈鹕的羽毛和自行车的链条但整体协调性稍逊一筹。比如它给鹈鹕加了三个脚趾但脚趾的旋转角度没算对看起来像是脚扭了。在动画方面Claude 4 Opus的轮子转动更平滑但鹈鹕的起伏幅度过大像是坐在弹簧上。模型几何体完整性空间关系正确性动画流畅度代码可读性总分GPT-6 Astra998935Claude 4 Opus989834Gemini 2.5 Ultra878831DeepSeek-V48879323.2 第二梯队Gemini 2.5 Ultra与DeepSeek-V4的稳健发挥Gemini 2.5 Ultra的代码结构很漂亮用了模块化的函数来分别创建鹈鹕和自行车可读性很高。但它在空间关系上犯了一个典型错误鹈鹕的腿太短脚够不到踏板模型为了解决这个问题把整只鹈鹕往下移结果鹈鹕的身体穿进了车架里。这个错误很能说明问题——模型知道“脚要踩在踏板上”但它没有能力去调整腿的长度或者鹈鹕的位置来满足这个约束只能粗暴地平移整个物体。DeepSeek-V4的表现让我有点意外。它的几何体完整性很好鹈鹕的嘴巴甚至做出了上下喙的区分自行车的车架也用了正确的三角形结构。空间关系上脚和踏板的接触点找得很准但翅膀的位置偏了搭在了车把的前方而不是上方。动画方面轮子转动没问题但鹈鹕的起伏和踩踏节奏对不上看起来像是各动各的。不过它的代码可读性是所有模型里最好的变量命名规范注释清晰拿过来改一改就能用。3.3 第三梯队那些“翻车”的模型到底错在哪有几个模型的表现就比较尴尬了。Llama 4-405B生成的代码里鹈鹕的嘴巴是一个巨大的圆锥直接穿过了自行车的前轮整个场景看起来像是一只鹈鹕在用嘴巴戳轮胎。Qwen 3.5-Max的鹈鹕没有腿身体直接悬浮在自行车上方轮子倒是转得很欢但鹈鹕和自行车完全是两个独立的物体没有任何交互。还有一个国内的开源模型生成的代码里自行车只有一 大模型3D空间推理能力实测：鹈鹕骑车场景生成评测
1. 从“鹈鹕骑车”说起为什么一个3D小场景能测出大模型的真实水平第一次看到“鹈鹕骑车”这个测试题我差点笑出声。一只鹈鹕蹬着一辆自行车在3D空间里摇摇晃晃地前进——这画面本身就带着一种荒诞的喜感。但笑完之后我意识到这道题的精妙之处恰恰在于它的“不正经”。它不像那些标准的代码评测题让你写个排序算法或者实现一个红黑树那些题目大模型早就背得滚瓜烂熟了。鹈鹕骑车不一样它要求模型同时理解三件事一个具体的动物形象、一个机械装置、以及两者之间的物理交互关系最后还要用代码把这个场景在浏览器里渲染出来。我最初是在一个技术社区里看到有人用这个题目测试GPT-6 Astra的。当时那个帖子只放了一张截图一只用基本几何体拼出来的鹈鹕身体是个椭球嘴巴是两个圆锥翅膀是压扁的球体骑在一辆用圆柱体和圆环组成的自行车上。画面谈不上精致但该有的元素一个不少而且鹈鹕的脚确实踩在踏板上翅膀搭在车把上整个姿态是合理的。底下有人评论说“这比很多人类画的示意图都强”也有人不服气说“不就是堆几个Three.js的几何体吗有什么难的”。我属于后者。作为一个写了七八年前端、最近两年一直在折腾大模型应用的人我第一反应是这题不难啊无非就是调用Three.js的API创建几个Mesh设置一下位置和旋转再写个动画循环让轮子转起来。任何一个熟悉Three.js的开发者花个把小时都能手搓出来。但当我真正开始用不同的大模型去生成这个场景的代码时我才发现自己低估了这件事的复杂度。问题不在于“能不能写出来”而在于“能不能一次写对”。大模型生成的代码往往在几何体的比例、位置关系、旋转角度这些细节上出问题。鹈鹕的嘴巴可能长在头顶上自行车轮子可能悬空或者鹈鹕的腿直接穿模到车架里面。这些错误在纯文本代码里看不出来但一渲染就原形毕露。所以这个测试的本质其实是在考察大模型的空间推理能力和代码生成的精确性。它要求模型不仅知道Three.js有哪些API还要能在脑子里构建出一个三维场景理解各个物体之间的相对位置和层级关系最后用准确的数值把这些关系表达出来。这比生成一段业务逻辑代码要难得多因为业务逻辑有明确的输入输出和边界条件而三维场景的“正确性”是模糊的、连续的。一个鹈鹕的嘴巴偏离了5度在代码层面可能只是rotation.z从Math.PI/2变成了Math.PI/2.1但渲染出来就是“看起来怪怪的”。我决定认真做一次横向对比。我选了12款目前主流的大模型包括GPT-6 Astra、Claude 4 Opus、Gemini 2.5 Ultra、DeepSeek-V4、Qwen 3.5-Max、Llama 4-405B以及几个国内外的开源和闭源模型。测试方法很简单给每个模型相同的提示词要求它生成一个完整的HTML文件用Three.js渲染一只骑自行车的鹈鹕包含基本的动画效果。然后我把生成的代码保存下来在浏览器里逐一打开从几何体完整性、空间关系正确性、动画流畅度、代码可读性四个维度打分。结果出乎我的意料也让我对“大模型写3D代码”这件事有了全新的认识。2. 测试环境搭建从零准备一个可复现的评测流程2.1 为什么选择Three.js而不是其他3D方案在开始测试之前我需要先确定技术栈。市面上做Web 3D的方案不少Three.js、Babylon.js、PlayCanvas还有直接用WebGL或者WebGPU的。我选Three.js的原因有三个。第一它的生态最成熟文档和示例最丰富大模型在训练数据里见过的Three.js代码量远超其他库这意味着模型对它的API更熟悉生成的代码质量上限更高。第二Three.js的抽象层级适中它不像直接写WebGL那样需要处理着色器和缓冲区也不像某些高层引擎那样把细节全封装起来刚好能考察模型对三维空间的理解。第三它的CDN引入方式极其简单一行script标签就能用不需要构建工具方便我快速测试。提示如果你也想复现这个测试建议固定Three.js的版本。我使用的是r168不同版本之间API有差异比如Geometry和BufferGeometry的用法就完全不同。固定版本能保证测试结果的可比性。2.2 统一的提示词设计如何让模型“听懂”需求提示词的设计直接决定了测试的公平性。如果提示词太模糊模型自由发挥的空间太大出来的结果千奇百怪没法比较。如果提示词太详细又变成了“填空”考察不出模型的真实能力。我最终采用的提示词是这样的请生成一个完整的HTML文件使用Three.js创建一个3D场景场景中有一只鹈鹕骑着一辆自行车。要求 1. 鹈鹕和自行车都用Three.js的基本几何体组合而成不要加载外部模型文件。 2. 鹈鹕要有身体、嘴巴、翅膀、腿和脚自行车要有两个轮子、车架、车把和踏板。 3. 鹈鹕的脚要踩在踏板上翅膀要搭在车把上。 4. 添加一个动画循环让自行车的轮子转动鹈鹕的身体有轻微的上下起伏。 5. 场景要有基本的灯光和相机相机能看到整个鹈鹕和自行车。 6. 代码要完整可以直接在浏览器中打开运行。这个提示词的关键在于第3条——“鹈鹕的脚要踩在踏板上翅膀要搭在车把上”。这是整个测试的核心难点。模型需要理解“踩”和“搭”这两个动作在三维空间中的含义并计算出正确的坐标和旋转角度。很多模型在这一步翻车要么脚悬空要么翅膀穿模要么干脆把鹈鹕和自行车做成两个独立的物体没有任何交互。2.3 评测维度的量化标准为了把主观感受变成可比较的分数我设计了一个四维评分表每个维度满分10分总分40分。维度评分标准权重几何体完整性鹈鹕和自行车的所有部件是否齐全有没有缺失或多余的物体25%空间关系正确性脚是否踩在踏板上翅膀是否搭在车把上各部件比例是否协调35%动画流畅度轮子转动是否自然鹈鹕起伏是否与踩踏动作匹配有无卡顿或跳变20%代码可读性变量命名是否清晰结构是否合理有无冗余或重复代码20%空间关系正确性占了最高的权重因为这是“鹈鹕骑车”这个题目的灵魂。一个几何体再完整、动画再流畅的模型如果鹈鹕是飘在自行车上方的那这个测试就失败了。2.4 测试过程中的意外发现模型对“鹈鹕”的理解差异在正式跑测试之前我先用几个模型做了预实验结果发现了一个有趣的现象不同模型对“鹈鹕”这个生物的理解差异巨大。有的模型把鹈鹕的嘴巴做得又长又尖像一根针有的模型把嘴巴做成了一个扁平的盒子像鸭嘴兽还有的模型干脆忽略了嘴巴只做了一个圆球当脑袋。这让我意识到大模型对具体生物形态的理解很大程度上取决于训练数据中相关描述的丰富程度。鹈鹕不是猫狗这种常见动物模型见过的3D鹈鹕模型可能很少所以它只能根据“鹈鹕有大嘴巴”这个模糊的印象来发挥。这个发现也解释了为什么有些模型在“鹈鹕骑车”这个测试上表现不佳——它们连鹈鹕本身都画不对更别说让鹈鹕骑车了。相比之下那些在预实验中能准确还原鹈鹕特征的模型在后续的空间关系处理上也普遍表现更好。这说明模型的细粒度理解能力和空间推理能力是正相关的。3. 十二款大模型实测谁在裸泳谁在领跑3.1 第一梯队GPT-6 Astra与Claude 4 Opus的巅峰对决GPT-6 Astra是这次测试的焦点。它的表现确实配得上“爆火”这个词。生成的代码一次通过打开浏览器就能看到一只像模像样的鹈鹕骑在自行车上。鹈鹕的身体是一个拉长的椭球嘴巴是两个圆锥拼接而成上喙比下喙长符合鹈鹕的特征。翅膀用压扁的球体表示自然地搭在车把上。最让我惊讶的是它给鹈鹕的脚和踏板之间加了一个Group把脚和踏板绑定在一起这样当踏板转动时脚会跟着一起动看起来就像真的在踩踏。这个细节我在提示词里没有要求是模型自己“想到”的。Claude 4 Opus的表现同样出色但在风格上有明显差异。GPT-6 Astra的代码更简洁几何体数量少但比例精准Claude 4 Opus的代码更“啰嗦”用了更多的几何体来细化鹈鹕的羽毛和自行车的链条但整体协调性稍逊一筹。比如它给鹈鹕加了三个脚趾但脚趾的旋转角度没算对看起来像是脚扭了。在动画方面Claude 4 Opus的轮子转动更平滑但鹈鹕的起伏幅度过大像是坐在弹簧上。模型几何体完整性空间关系正确性动画流畅度代码可读性总分GPT-6 Astra998935Claude 4 Opus989834Gemini 2.5 Ultra878831DeepSeek-V48879323.2 第二梯队Gemini 2.5 Ultra与DeepSeek-V4的稳健发挥Gemini 2.5 Ultra的代码结构很漂亮用了模块化的函数来分别创建鹈鹕和自行车可读性很高。但它在空间关系上犯了一个典型错误鹈鹕的腿太短脚够不到踏板模型为了解决这个问题把整只鹈鹕往下移结果鹈鹕的身体穿进了车架里。这个错误很能说明问题——模型知道“脚要踩在踏板上”但它没有能力去调整腿的长度或者鹈鹕的位置来满足这个约束只能粗暴地平移整个物体。DeepSeek-V4的表现让我有点意外。它的几何体完整性很好鹈鹕的嘴巴甚至做出了上下喙的区分自行车的车架也用了正确的三角形结构。空间关系上脚和踏板的接触点找得很准但翅膀的位置偏了搭在了车把的前方而不是上方。动画方面轮子转动没问题但鹈鹕的起伏和踩踏节奏对不上看起来像是各动各的。不过它的代码可读性是所有模型里最好的变量命名规范注释清晰拿过来改一改就能用。3.3 第三梯队那些“翻车”的模型到底错在哪有几个模型的表现就比较尴尬了。Llama 4-405B生成的代码里鹈鹕的嘴巴是一个巨大的圆锥直接穿过了自行车的前轮整个场景看起来像是一只鹈鹕在用嘴巴戳轮胎。Qwen 3.5-Max的鹈鹕没有腿身体直接悬浮在自行车上方轮子倒是转得很欢但鹈鹕和自行车完全是两个独立的物体没有任何交互。还有一个国内的开源模型生成的代码里自行车只有一