AI 时代做 3D 场景的完整认知地图

写给没有建模、动画、游戏背景的人。文中提到的工具名称多为类别代表，具体版本请以官网为准——工具迭代极快，但本文梳理的分工关系基本不变。

一、两个流行说法，各对了一半

如果你最近关注过 AI 生成 3D，大概率见过两种说法。

第一种：“一个 HTML 文件就能跑 3D 场景。”这是真的。网上有大量单文件 demo，点开即转，转发只需一个链接，门槛低得惊人。

第二种：“现在用 AI 一键就能做出游戏。”这句话只有一半是真的。GPT、Claude、DeepSeek 这类模型确实能写出游戏代码、指挥建模软件、往编辑器里摆放物件。但它们本身不会建模，也不渲染画面，其核心能力在于读懂需求并调用外部工具。真正产出模型的是另一类模型，而让画面动起来、让按键产生反馈的，又是第三个东西。

因此，更准确的描述应当是：目前并没有“一个 AI 生成游戏”，而是存在一条由不同工具接力的流水线。 流水线上的每一环都有对应的工具，环与环之间是上下游关系，而非互相替代的竞争关系。

理解这一点至关重要。新手踩坑，绝大多数源于把上下游当成了竞品——纠结“Three.js 和 Tripo 选哪个”“Blender 能不能替代 CAD”。这些问题本身就不成立，就像在问“摄影机和剧本哪个更好”。

接下来的内容将围绕这条流水线展开。理清它，后续的所有选型都会迎刃而解。

二、核心模型：四道工序

制作任何 3D 场景或游戏，都绕不开四道工序。它们按固定顺序排列，前一道工序的产出即为后一道工序的原料。

第一道：造物件。 椅子、路灯、汽车、人物、树木，逐一制造出来。这一步相当于剧组的道具组。

第二道：搭世界。 将物件摆放到正确的位置，铺设道路，布置灯光，确立整体氛围。这一步相当于美术置景。

第三道：赋予生命。 设定按下按键后的反馈、物体碰撞的效果、车辆的行驶轨迹以及行人的移动逻辑。每秒六十次循环询问：发生了什么？该如何回应？这一步相当于舞台机关与现场导演。

第四道：交付给用户。 最终呈现为一个浏览器链接、一个安装包，抑或一段视频。这一步相当于电影院或快递盒。

这四道工序之所以重要，是因为它们构成了判断一切选型问题的坐标系。

同层可换，跨层不可换。 Tripo、Meshy、Rodin 同属第一道工序，可以互换；Unity、UE、Godot 同属第三道工序，也可以互换。但绝不能拿第三道的工具去做第一道的事，反之亦然。

此外，还有一个容易被忽略却至关重要的顺序：必须先确定第四道（交付形态），再倒推第三道，最后才考虑第一、二道。 这是整个流程中唯一不可逆的决定。中途从网页改为客户端，或者从客户端改为网页，代价极其高昂，几乎等同于重做。

记住这两条原则，后续的困惑便会减少大半。

把四道工序画成一张图，关系会更直观：

读图要点只有一句：同层可换、跨层不可换——同一道工序里的工具可以互相替换，跨道工序的工具则不能互相顶替，只能按箭头方向接力。

三、用这个模型，回答所有"XX 和 XX 什么关系"

Three.js 和 Tripo 是什么关系？

毫无关系，它们分属不同的工序。

Tripo 属于第一道，负责造物件。输入一段文字或一张图片，它会输出一个静态文件，包含顶点坐标与贴图。这个文件本身不会动，也不知道何为按键或碰撞。

Three.js 属于第三道，负责赋予生命。它是一个 JavaScript 库，自身无法建模，只能读取别人做好的文件并在网页上绘制出来。如果给它一个空场景，它什么也变不出来。

两者是接力关系：Tripo 生成椅子、桌子和台灯，Three.js 将它们读入、摆放、打光并实现交互。

打个比方：Tripo 如同 3D 打印机，Three.js 则是展厅的灯光与保安。 打印机无法直接提供展览体验，而灯光也照不出实物。

Blender 和 CAD 是什么关系？

同样分属不同工序，且数据流动是单向的。

CAD 关注尺寸的准确性。它存储的是精确几何体：直线、圆弧、参数化实体，精度可达毫米级。在 CAD 中，墙体是一个带有属性的数学对象，询问其长度，它能准确回答 8640 毫米。它的输出用于画图与施工。

Blender 关注视觉的美观度。它存储的是多边形网格：由顶点和三角面拼成的外壳。在 Blender 中，墙体不知道自己是一堵墙，只知道自身的坐标位置。它的输出用于画面表现与动画制作。

由此得出一个重要推论：从 CAD 进入 Blender 很容易，因为这是降维过程，损失的仅是属性信息；但从 Blender 返回 CAD 几乎不可能，因为升维所需的信息原本就不存在。 千万不要在 Blender 中建好模型后，指望导出 DWG 文件交给设计院，网格并非实体，无法进行标注与施工。

那么项目中是否需要学习 CAD？多数情况下不必。CAD 在此类项目中的核心价值仅是提供一张带有比例的底图。这个需求完全可以通过图片、SketchUp 或 GIS 框选工具来满足。只有当需要从图纸中提取精确坐标数据时，才值得去接触 CAD。顺带一提，如果手头没有图纸且城市是自行规划的，建议学习 SketchUp 而不是 AutoCAD——前者推拉成体的操作直观得多，半天即可上手，且能直接导出至 Blender 或 UE。

Unity、UE、Three.js 做出来的东西有什么不同？

区别主要体现在三个方面。

首先是是否存在运行时环境。Blender 内部没有“玩家按下 W 会发生什么”这套机制，它拥有动画时间轴，但缺乏游戏循环。引擎和 Three.js 则具备该机制，它们每秒运行六十帧，持续检测键盘输入、碰撞情况以及需要播放的动画。

其次是物理与碰撞是否为现成功能。要让球体滚落、人物站在地面上不掉落，Unity、UE 或 Godot 只需勾选一下；而 Three.js 则需要自行接入物理库并进行计算。

最后是交付形态的不同。需要一个链接发给他人查看，就选择 WebGL 体系；需要安装包、支持手柄、多人联机或上架平台，则选择 Unity 或 UE；如果只做美术资产交给他人，使用 Blender 即可。

四、它们靠什么对话：文件格式

既然各道工序由不同软件完成，它们之间必然需要一种通用语言。这就是文件格式的作用。

最常用的格式是 .glb 或 .gltf。它封装了模型、材质与动画，对网页友好，Three.js、Babylon、Unity、UE 都能读取。它是整个链条里最接近“万能插头”的东西。 其次是 .fbx，携带模型与动画，属于工业标准，Blender、Unity、UE 通用。贴图统一使用 .png 或 .jpg，声音采用 .mp3 或 .ogg。

需要补充一点：.glb 与 .gltf 是同一套规范的两个形态——.gltf 是 JSON 文本加外部贴图、二进制文件，便于阅读和版本管理；.glb 把这一切打包成单个二进制文件，便于分发。对外交付和网页加载优先用 .glb，能少掉一堆贴图路径丢失的问题。
还有两种格式需要特别留意。

.blend 是 Blender 的工程源文件，只有 Blender 能够读取。它属于开发态文件，不能作为交付物。如果在文档中看到“导出 .blend 给客户端”，说明撰写者缺乏实际项目经验。顺带一提，.blend 里可以勾选“打包资源”，把外部贴图一并塞进文件，否则换台机器打开就会满屏紫块——这是交接时最常见的翻车点。
.splat 或 3DGS（高斯泼溅）是另一回事。它呈现的照片级真实感令人惊艳，但本质是一团半透明椭球，既没有可供点击检测的实体网格，也无法修改几何结构。因此它适合用来制作视频中的唯美空镜，不适合用于可点击交互的场景。 将两者区分开，能省去大量麻烦。如果确实要在交互场景里用它，通常的做法是另建一层不可见的简化碰撞体来承接点击，视觉与逻辑分离。
一条典型的流水线大致如下：

AI 生成资产          →  椅子.glb
人工瘦身（Blender）   →  椅子_低模.glb ＋ 碰撞体
搭场景                →  摆好、打光
写交互逻辑            →  能走、能开门、能捡东西
打包发布              →  index.html 或 game.exe

注意第二步的存在。AI 生成的资产默认需要经过一道瘦身处理：减面、合并材质、重新展开 UV、添加碰撞体。跳过这一步，后期往往需要返工。另外，AI 生成的模型常见问题是比例与朝向不统一、原点不在底部中心，导入后需要统一做一次缩放与轴心校正，否则批量摆放时会非常痛苦。

五、“一个 HTML 就能跑”，那为什么会卡？

这是最容易产生误解的地方，值得单独探讨。

单文件 demo 的原理十分朴素：HTML 提供骨架，JavaScript 库负责绘制，模型数据转成字符串直接写在文件里。浏览器打开即运行，无需安装任何东西。它的优势在于传播成本极低，而非技术先进。

关键在于：卡顿与否跟文件数量几乎没有关系。 一个精心优化的 50MB 单 HTML 可以运行得很流畅；一个拆分成两百个文件但未经优化的场景照样会卡成幻灯片。决定流畅度的主要有五项指标。

一是面数，即三角面的数量。一个五万面的角色放置一百个，就是五百万面，显卡需要进行五百万次计算。

二是 Draw Call，即绘制调用次数。每个不同材质的物件都需要单独下单一次。一千个物件各带独立材质等于一千次调用，这是网页 3D 最常见的卡顿原因。解决办法称为合并网格或合批，即将同材质的物件粘合成一个整体。

三是贴图分辨率。一张 4K 贴图约占 16MB 显存，手机上放置十几张就会撑爆内存。

四是光照方式。实时光影开销最大；烘焙光照（提前算好存成贴图）几乎不消耗性能。

五是每帧的逻辑计算。浏览器的 JS 主线程是单线程的，计算过多就会导致掉帧。

由此可见，正经项目之所以包含几千个文件，完全是出于工程考量：便于缓存、并行下载、增量更新以及多人协作。上线时再用打包工具压回少数几个文件即可。开发态追求文件分散以便干活，发布态追求文件集中以便分发。 看到大量文件时不必惊慌，那通常是开发态的表现。

作为经验起点（非绝对标准），面向手机浏览器的网页项目可以参考以下预算：可见总面数控制在几十万级别，贴图尽量保持在 1K 以下，独立材质数量越少越好，Draw Call 压到一两百以内。AI 生成的模型动辄几万面还带多个材质槽，直接塞进网页必然卡顿，必须先进行瘦身处理。

六、把这些串起来：做一个带平面图的城市宣传场景

理论部分已经梳理完毕，接下来通过一个具体需求将所有环节串联起来。假设目标是制作一个 3D 城市场景，包含办公楼、公园、学校，配备行人和车辆，附带可点击切换镜头的平面图纸，并能导出讲解视频。

这个需求恰好暴露了一个关键判断，而这个判断会直接影响后续的所有决策：

可点击的平面图与导出的宣传视频，是两种不同的交付形态。

前者要求实时交互，后者追求画质上限。兼顾两者固然可行，但必须分清主次。

若以视频为主，建议使用 UE 作为主力，网页版作为简化副产品。视频质量直接决定项目的观感，而 UE 的序列器能精确控制每个镜头的时长、停顿与景深，这是网页端难以实现的。反过来，场景资产和镜头设计可以完全复用——后续若想补充网页版，只需将场景精简导出为 glb，重写交互层即可。

若客户更看重随时能点开链接，则以 Three.js 为主力，视频通过录屏妥协产出。

确定主次之后，再逐层推进。

资产层：城市千万别一栋一栋用 AI 生成。

Tripo、Meshy 这类工具的强项在于单体物件，如雕塑、道具、角色或一辆车。用来生成整片街区会面临三个问题：缺乏地理坐标、建筑容易悬浮且不贴合地形、每栋单独拼接导致面数失控。

合理的获取方式有三种，按优先级排列：

如果是真实地块，应使用 GIS 框选建模服务。在地图上框定区域后，系统会自动识别建筑轮廓、楼层数和地形高程，一次性输出分层的 GLB 文件，建筑、地形、植被分别导出。这种方式专为城市片区设计，坐标天然对齐，能有效避免建筑悬浮。

如果是虚构城市，应采用模块化套件配合程序化排布。利用现成的 CC0 建筑套件批量复制并调整高度，AI 仅用于生成几栋标志性建筑（如学校主楼、办公楼大堂）作为视觉焦点。少数精品加大量复用，是工业界的实际做法，这与许多教程展示的路线恰恰相反。

至于 HY-World、Marble 这类 AI 整场生成工具，适合用于制作背景氛围、概念图或快速初版布局参考。但其输出往往是静态的一张皮，几何结构较乱，难以精修，也不支持行人和车辆，因此不适合作为可交互的主场景。

行人车辆：别上真物理，用假动。

真实的交通仿真对新手而言是个深坑，而低成本方案已经足够逼真。

车辆可以通过几条样条线模拟道路，让车型沿线匀速行驶，在路口减速停顿。视觉上已足够可信，计算开销也几乎为零。行人则使用三千到五千面的低模人物，播放行走循环动画，沿人行道样条线移动，到达终点后销毁并重生，同屏保持二十到五十人即可。

这里有一个关键优化手段：同一种行人或车辆只加载一份模型，通过 GPU Instancing 技术批量绘制，能将几百个对象的 Draw Call 降至 1。这项技术成本低廉且效果显著，非常值得了解。

平面图点击切镜头：九成工作量在坐标对齐。

第一步，将平面图贴在地面上作为参照。在场景中创建一个水平面，把平面图当作贴图放上去，按比例缩放使其与 3D 建筑的占地范围吻合，并将世界原点定在图纸的某个固定角点。完成后可以隐藏该平面，但不要删除，后续调试仍需使用。

第二步，建立一张镜头表。无论是网页还是引擎，底层都是同一份配置数据：每个点位记录编号、名称、相机位置、朝向目标、视野角度以及到达后停留的秒数。停留秒数既管控交互节奏，也服务于视频剪辑的节奏。

第三步，实现点击飞行功能。网页端可以使用绝对定位的元素覆盖在画布上方，点击后读取配置，相机同时对位置和朝向目标进行插值，缓动函数选用三次方InOut，耗时一点五到二点五秒，飞行期间锁定鼠标拖拽。引擎端则建议使用预设好的摄影机演员直接切换，因为镜头可以预先在视口中精细调整，这比纯靠代码推算更为可靠。

可选的升级项是增加一个小地图：增设一台垂直向下的正交相机，将其画面实时渲染成小窗口，并在图上标出当前视角位置。这能大幅提升专业感，且实现难度并不高。

出片：这是引擎最稳的一环。

标准流程为：建立关卡序列，每一段对应镜头表中的一条记录；使用电影级摄影机，焦距设在 24 到 35 毫米，光圈开启轻微景深，曝光设为手动以防画面忽明忽暗；运镜遵循起幅停顿一秒、缓慢移动、落幅停顿两秒的节奏，停顿段是添加解说词和标注的天然位置。

输出时请选择序列帧而非直接导出 MP4。分辨率设为 1080p 或 4K，帧率 24 或 30，开启抗锯齿的时间采样以获得自然的运动模糊，同时关闭类似 DLSS 的功能，动态画面容易产生重影。最后将序列帧导入后期软件，添加配音、字幕、标注箭头和背景音乐，音频单独录制并与镜头时间点对齐。

网页版的妥协方案是利用画布捕获流结合媒体录制器，或逐帧捕获。这种方式受实时性能限制，达不到 4K 画质也没有运动模糊，仅适合作为演示草稿。

实施顺序，请按这个走，不要跳步：

先用方块搭建整个城区，对齐平面图，跑通相机飞行。点到任意一项，相机都能准确飞到对应方块前方。这一步值得投入最多时间，平面图与 3D 世界的坐标关系一旦确立，后续工作便只是替换资产；跳过去的话，后期修改布局会牵一发而动全身。

接着将八到十二个镜头排一遍，输出粗剪，直到视频节奏看着不觉得烦躁。然后替换资产，背景楼使用套件，标志性建筑由 AI 生成并经 Blender 修复，确保面数与 Draw Call 在预算之内。随后添加动效，让车上路、人走路、树摇晃、水面波动，保证同屏三十人不掉帧。之后处理光照与后期，进行烘焙或使用全局光照，添加雾效和色调查找表，分别渲染白天和黄昏两个版本，黄昏通常更具观赏性。紧接着输出序列帧并进行后期合成配音，制作 60 到 90 秒的成片。最后，如果需要网页版，再将场景减面导出 glb，重写交互层，确保手机浏览器稳定 30 帧。

七、边界：AI 现在做不到什么

诚实地认识边界，比多知道十个工具更有价值。

环境不等于游戏。 社区里有句泼冷水的话很中肯：你造了个 3D 环境，那不是游戏。敌人行为、物理互动、任务逻辑、数值平衡，AI 目前做得并不好。环境只是表皮，机制才是游戏的核心。

你造的是渲染器，不是仿真器。 这是一个专业区分。渲染器追求看起来正确，仿真器追求实际上正确。积木塔是否会按真实物理规律倾倒，是检验两者的简单标准。目前大多数 AI 场景属于前者，这对宣传片足够，但对机器人训练这类精度要求高的场景远远不够。

成本会滚雪球。 长时间的智能体循环，一天花费几百美元并不罕见。有些重度 agent 实测因为自主执行更多步骤，总消耗反而上升。务必设置步数上限和退出条件。

版权风险真实存在。 纯 AI 生成的内容在多地不受版权保护，平台对 AI 内容开放但通常需要声明。商用项目请把 AI 产出视为半成品，进行实质性加工，并保留过程文件。

实验性接口随时会变。 引擎侧的 AI 接口普遍标注为实验性，现在编写的自动化脚本下个版本可能就不兼容了。请为此预留时间。

瓶颈已经转移。 从菜单在哪、快捷键怎么按的操作熟练度，转移到了品味、判断力、验收速度和工具链设计上。派活之前就要写清怎样算做完，并要求交付时附上可直接核对的证据。

八、最后一句，和下一步

如果只带走一句话，请记住这句：

Tripo 造零件，Blender 修零件，引擎让零件动起来，CAD 只提供尺寸读数，大模型负责指挥这一整套流程。先定交付形态，再选工具；先让一个三角形动起来，再往里填东西。

最后一句提醒尤为重要，它也是新手最容易犯的顺序错误。许多人第一步就用 AI 生成一个超精细城市塞进网页，卡死后便得出 AI 不行的结论。其实并非 AI 能力不足，而是管线顺序错了。

如果要动手，建议的学习顺序是：先不碰 3D，用二维框架做一个方块能跳、能捡金币的小程序，先把玩法循环做出来；接着掌握 Blender 的五个操作——导入参照图、挤出墙体、减面、展 UV、导出，这就够用了；然后用 Three.js 加载一个 glb，加上轨道控制器和相机飞行，部署上线拿到链接；最后在 UE 里走一遍白盒场景、按钮切镜头、输出一段十五秒粗剪。走完从图纸到成片的全流程，这套认知才算真正落地。