Gemini 4 Argon 一句话生成赛博朋克 3D 城市，浏览器 60 帧运行

一句话让 AI 造一座城

Google 的 Gemini 4 Argon 上线后，关于"Google 是否追上来了"的讨论就没停过。一位获得约一周内测权限的 YouTube 创作者做了一次直观测试：用几乎不加工的提示词，让模型直接生成一段赛博朋克风格的 3D 动画，并且明确要求跑在浏览器里、帧率至少 30fps、最好 60fps。

结果相当有说服力。整段动画在浏览器中轻松维持在 60 帧，而这个结果只用了一条非常朴素的提示词，生成耗时约 30 分钟。

用 3JS 构建超写实赛博朋克 3D 动画的提示词

这条提示词到底写了什么

创作者公开的提示词并不复杂，核心诉求可以拆成几层：用 3JS（Three.js）搭建超写实的赛博朋克 3D 场景，细节越多越好；帧率优先保证 30fps 以上，最好达到 60fps；画面里要有大量霓虹色，以及飞车穿梭于高楼之间的动态元素。

帧率要求被明确写进提示词

说个细节，这段提示词几乎没有涉及代码结构、渲染管线或性能优化的任何技术指令。创作者本人的评价是"非常简单、非常朴素"——这恰恰是这次演示最值得琢磨的地方。

Three.js 是什么

Three.js 是构建在 WebGL 之上的 JavaScript 3D 图形库，它把底层 WebGL 的着色器、缓冲区、矩阵运算等复杂接口封装成场景（Scene）、相机（Camera）、渲染器（Renderer）、网格（Mesh）等高层对象，让开发者用几十行代码就能在浏览器里渲染 3D 内容。它本身不是游戏引擎，不内置物理、动画状态机等系统，因此性能好坏高度依赖开发者如何组织几何体、控制绘制调用（draw call）数量、复用材质与纹理。

这也正是这条演示值得关注的原因：让模型直接产出能跑到 60 帧的 Three.js 代码，等于要求它同时理解渲染管线的基本约束——比如合并几何体以减少绘制调用、避免每帧重建对象、用实例化（InstancedMesh）渲染大量重复元素。这些通常属于中级前端 3D 工程师的经验范畴。

霓虹确实有点过头了

创作者也承认，成品在霓虹色的使用上"可能有点用力过猛"。赛博朋克本身就是高饱和、高对比的视觉风格，AI 在"越多细节越好"这类开放指令下，往往会倾向于堆叠视觉元素，导致色彩溢出或画面偏噪。

霓虹色彩与飞车穿越高楼的画面

不过从最终观感看，这一点色彩上的失控并没有破坏整体效果。创作者的原话是"整体来看非常棒"。对于一次近乎零调优的生成来说，能在风格化与可运行性之间取得这种平衡，已经超出预期。

60 帧背后的信号

真正让这次演示有分量的，不是画面好不好看，而是它在浏览器里跑到了 60 帧。

浏览器中稳定 60 帧运行

3D 动画的帧率直接反映代码质量：场景复杂度、几何体数量、光照与着色器开销，任何一环处理不当都会掉帧。模型不仅写出了能跑的 Three.js 代码，还满足了明确的性能约束。这意味着 Gemini 4 Argon 在"生成可执行、可落地的前端 3D 代码"这件事上，已经不只是能出结果，而是能出符合工程要求的结果。

创作者用"Google 追上来了"来概括这次体验，从这条测试看，这个判断有它的依据。

为什么 60 帧比画面好看更能说明问题

帧率是渲染性能的综合结果：浏览器每帧只有约 16.7 毫秒的预算（60fps 对应的时间窗口），场景中每个几何体的顶点数、光照数量、阴影贴图分辨率、着色器复杂度都会消耗这个预算。一旦超支，就会出现掉帧、卡顿。

因此"稳定 60 帧"意味着模型生成的代码在场景复杂度与渲染开销之间做了合理取舍——这不是靠视觉审美能蒙对的，而需要符合工程常识的实现方式。相较之下，"霓虹色过载"是纯风格问题，改一行配色即可；而性能不达标往往要重构代码结构。这也是为何创作者把帧率而非画面本身作为核心证据。

对开发者意味着什么

过去，从一句创意描述到一段可运行的 3D 场景，中间隔着建模、着色器编写、性能调优等一整套流程。Gemini 4 Argon 展示的路径是：用自然语言描述视觉目标和性能指标，由模型一次性产出可运行代码。

这并不代表专业 3D 开发会被取代，但它确实把原型验证的成本压到了极低。对于需要快速验证视觉概念、做交互 Demo 或生成营销页动效的场景，30 分钟换一个 60 帧的可跑原型，性价比相当可观。

至于"霓虹过头"这类风格问题，反倒是最容易通过追加一轮提示词修正的部分。

自然语言到可执行 3D 代码的路径变化

传统 Web 3D 开发链条是：概念设计 → 建模（Blender 等）→ 导出 glTF/OBJ → 编写 Three.js 加载与交互逻辑 → 反复用性能面板调优。其中建模与调优两段最耗时，也最依赖专业人员。

Gemini 4 Argon 展示的路径跳过了资产准备环节，直接用代码程序化生成几何体与材质。这对原型阶段的含义是：验证一个视觉概念不再需要先做模型资产，只需一段描述。不过程序化生成也有边界——需要精细美术资产、复杂骨骼动画或大世界场景时，仍要回到传统管线。它压缩的是"前期试错"成本，而非替代最终资产制作。