[控场AI]
· 5 分钟阅读· 2,508 字

14个月13款Claude模型同题实测:3D游戏网站进化史

14个月13款Claude模型同题实测:3D游戏网站进化史

开发者用14个月同题单次生成测试13代Claude的3D网站能力,记录真实进化曲线。

一位开发者从2025年7月起,用完全相同的提示词要求每一代Claude模型单次生成一个“无限程序化地形、镜头持续前进”的3D游戏风格网站,覆盖13个模型版本,全程零手动修改并在Chrome中实时捕获。实验发现进化曲线并非单调上升,Sonnet 5.5甚至带着树木无法渲染的着色器bug,作者选择原样保留。文章认为,开放式3D创意编程的评测应锚定可运行画面而非代码跑分,单次生成测的是首发生成质量;同时指出该实验为单一个案、单一提示词,适合定性参考而非严格基准排名。

一位开发者在Reddit上分享了一项持续14个月的实验:从2025年7月开始,他给每一款新发布的Claude模型输入完全相同的提示词,要求生成一个“无限程序化地形、镜头永远向前推进的3D游戏风格网站”,并记录下每个模型的实时渲染结果。实验覆盖了13个模型版本,全部采用全新对话、零手动修改、仅凭单次生成(one-shot)完成。

Reddit原帖截图

实验设计:一把尺子量到底

这个实验的价值在于控制变量做得足够彻底。同一段提示词、同样的浏览器环境(Chrome实时捕获)、每次都是全新会话、不允许任何人工修正。提示词本身就带有明确的复杂度要求:无限程序化地形、持续向前移动的摄像机、丰富的场景物体、着色器渲染、风格化视觉效果,以及“永远滚动下去”的无限性。

这实际上是在测试模型对复合型前端任务的综合能力——它同时涉及3D数学、程序化生成算法、着色器编写、性能优化和视觉设计。任何一环掉链子,最终画面都会暴露问题。

着色器(Shader) 是运行在GPU上的小程序,负责决定每个像素或顶点的最终颜色与位置。在Web 3D场景中,着色器通常用GLSL编写,通过WebGL或Three.js等库调用。树木无法渲染这类bug,往往源于顶点着色器中的变换矩阵错误、片元着色器中的光照计算异常,或几何体属性绑定缺失。由于着色器代码高度依赖GPU并行执行模型,一旦某处逻辑出错,表现通常是整类物体消失或颜色异常,而非程序崩溃,因此这类缺陷在静态代码审查中很难被发现,必须实际运行才能暴露。

程序化生成(Procedural Generation) 指用算法而非手工建模来动态产生内容。在无限地形场景中,常见做法是结合噪声函数(如Perlin噪声或Simplex噪声)生成高度图,再按摄像机位置分块加载和卸载地形网格。这种方法的核心挑战在于保证相邻区块无缝拼接、维持恒定帧率,以及让“无限”在视觉上不出现重复感。模型要在单次生成中同时处理噪声参数、区块调度和LOD(细节层次)策略,对代码组织能力要求很高。

13个版本,一条可见的进化曲线

作者在帖子中附上了一张对比图,横轴是模型版本号,展示各代模型生成结果的变化。他特别说明,图中的刻度只代表模型编号,不代表其他任何指标。

从实验者的描述来看,这条进化曲线并非单调上升。一个有趣的细节是:Sonnet 5.5生成的版本实际上带着一个着色器bug——树木无法渲染出来——但作者选择原样保留,没有修复。这个处理方式本身比结果更有信息量:它说明即便是较新的模型,在一次生成复杂3D场景时仍可能出现局部渲染错误,而模型的“进步”并不等于“零缺陷”。

需要强调的是,由于原始素材没有披露各版本的具体画面差异、代码质量或运行帧率等量化数据,本文不对代际提升幅度做数字层面的断言。可以确定的是,作者用14个月的时间跨度覆盖了Claude系列从早期到较新版本的完整迭代周期,这种纵向对比在AI编程评测中并不常见——大多数基准测试是横向的、静态的,而这里记录的是同一任务在时间轴上的真实演变。

为什么“同题多代”测试比跑分更有说服力

常规的代码基准测试通常给出通过率或相似度分数,但这类指标很难反映模型在开放式创意编程任务中的实际表现。一个能写出正确语法却渲染不出树木的模型,在单元测试里可能拿高分,在用户眼里却是不合格的。

这个实验的启示在于:生成式3D内容的评测需要看最终画面。程序化地形是否真的无限、镜头运动是否平滑、着色器是否生效、场景密度是否合理,这些只能通过实际运行来验证。作者选择在Chrome中实时捕获每个版本,正是把评测锚定在“可运行产物”而非“代码文本”上。

另一个值得注意的点是单次生成的约束。允许反复重试会掩盖模型的稳定性差异——有的模型第一次就能出可用结果,有的需要多轮修补。只给一次机会,测的是首发生成质量,这更接近真实用户在快速原型阶段的体验。

One-shot(单次生成) 在AI编程语境中,指模型只根据一次提示就直接输出完整可运行代码,不经过任何追问、纠错或迭代。与之相对的是多轮对话式开发,用户会逐步指出错误并让模型修补。One-shot评测的价值在于衡量模型的“首发生成质量”和指令遵循完整度,因为真实用户在快速原型阶段往往希望一次拿到可用结果。但它的局限也很明显:单次失败可能只是随机采样波动,而非能力上限,因此适合做定性对比,不宜直接换算为通过率分数。

对开发者的实际参考价值

如果你正在用Claude系列模型做3D或创意前端开发,这个实验提供了几个可操作的判断依据。

其一,复杂3D场景仍建议分步生成。即便是较新版本,一次性输出完整着色器管线也可能出现局部失效(如Sonnet 5.5的树木渲染问题)。把地形生成、物体布置、着色器逻辑拆成独立步骤,比赌一次成功更稳妥。

其二,模型版本升级带来的收益需要按任务类型评估。这个实验只覆盖了一类任务——程序化3D网站——不能直接外推到后端逻辑或数据处理场景。作者没有公布各版本的具体差异细节,因此无法判断哪些能力维度提升最明显。

其三,保留失败样本有诊断价值。作者没有修复Sonnet 5.5的bug,而是原样展示,这种做法让对比更诚实:进化曲线上的每个点都是模型的真实产出,而不是人工美化后的结果。

实验的边界

必须指出,这个实验是单一个案、单一提示词、单一评测者。13个模型版本的结果差异可能受到提示词措辞、浏览器环境、甚至生成时的服务状态影响。作者未披露每个版本的具体表现细节,因此它更适合作为定性参考,而非严格的基准排名。

但它的方向值得肯定:用长时间跨度的同题实测,把“模型进化”从抽象的宣传语变成了可以亲眼查看的画面序列。对于关注AI编程能力演进的人来说,这比任何跑分榜单都更直观。

(配乐信息:作者使用了Kevin MacLeod的《Raving Energy》,CC BY 4.0协议。)

#Claude模型对比#AI编程实测#3D网站生成#程序化地形#Claude进化#AI前端开发#单次生成测试
分享:

相关推荐