世界模型、AI 3D场景生成和游戏引擎都能呈现"一个世界"，但交付能力并不相同。场景生成擅长快速探索空间候选，游戏引擎与DCC擅长编辑对象、编写规则和运行交互，世界模型则更关注环境表示、状态预测与动作后果。选型时不要只看演示画面，而要用同一张任务卡检查一致性、可控性、物理证据、对象结构和导出回读。
一、先按交付目标选，不按演示画面选
面对同一条街道，生成一张街景、生成可浏览空间、让车辆按规则运行，以及预测车辆执行动作后的下一状态，是四件不同的事。画面相似，不代表底层能力相同。
先给出一个简化结论：
- 需要快速比较空间、构图和风格候选，优先评估 3D场景生成。
- 需要精确修改对象、配置碰撞和制作交互，优先使用 DCC与游戏引擎。
- 需要根据历史观测和动作预测环境变化，或服务机器人、自动驾驶等训练任务，再评估 世界模型。
DCC是Blender等数字内容制作软件，负责建模、材质、动画等资产制作；游戏引擎则把资产、输入、规则和渲染组织成可运行程序。两者经常配合使用。
世界模型是一个广义技术概念，并非所有世界模型都会生成图像，也并非都能输出3D资产。产品宣传中的"生成世界"，也不能直接等同于研究语境中的世界模型。三条路径可以组合，真正的选择标准应是最终要交付什么。
图注：街区白模可用于讨论道路、建筑体量、遮挡和观察路线，但不能证明场景具备对象语义、连续状态、物理规律、交互逻辑或可导出的3D资产。
二、三类能力分别解决什么问题？
先问系统"记住什么、改变什么、交付什么"，再判断它属于哪条技术路径。
某一时刻的位置、速度等信息可以称为状态 ；状态如何随动作和时间变化，可以称为动力学 。道路、车辆和建筑的类别及身份属于对象语义。开发者在引擎中写下的红灯停车、碰撞减速等内容，则是显式规则。
规则能正确运行，不代表系统从数据中学会了环境变化；模型能生成逼真视频，也不代表它提供了可读取、可复现的物理状态。
| 路径 | 常见输入与输出 | 主要优势 | 需要拿出的证据 | 常见误解 |
|---|---|---|---|---|
| 世界模型 | 观测、历史状态，部分系统还接收动作；输出未来状态、观测或内部表示 | 学习环境变化，预测动作后果 | 动作条件、连续运行记录、状态或任务误差 | 都会生成视频，或天然遵守真实物理 |
| 3D场景生成 | 文本、图像、草图、布局；输出图像、视频、可浏览空间或3D资产候选 | 快速探索空间与视觉方案 | 多视角结果、实际文件、对象拆分和编辑测试 | 能浏览就一定有可编辑Mesh |
| DCC与游戏引擎 | 网格、材质、对象、规则和业务数据；输出可编辑资产或可运行场景 | 精确编辑对象并实现交互 | 层级、脚本、运行日志、构建包和回读结果 | 引擎只是把画面显示出来 |
有些系统把空间编码在模型参数或特征中，这类结果可称为隐式表示。它可以用于渲染或生成新视角，却未必能直接交付为Mesh，也就是由顶点、边和面组成的常规网格。
因此，"支持3D"至少还要追问三件事：输出是视频、可浏览表示还是Mesh？对象能否独立选择？目标软件能否重新导入并继续修改？
三、按5类任务选择优先路径
先写清交付物，再选择工具。下面的路径不是互斥答案，而是不同任务的优先起点。
| 任务 | 优先路径 | 必须补充的输入 | 核心验收动作 | 主要风险 |
|---|---|---|---|---|
| 视觉概念探索 | 3D场景生成 | 风格、参考图、空间意图 | 对照多视角和布局关系 | 单张画面好看，但空间并不成立 |
| 可浏览3D展示 | 场景生成＋网页或实时展示端 | 路线、尺度、目标设备 | 沿路线检查遮挡、穿帮和加载 | 可浏览不等于对象可编辑 |
| 交互原型 | 游戏引擎＋DCC，生成资产作辅助 | 对象规则、输入方式、重置条件 | 修改车速、触发事件并恢复初始状态 | 视觉反馈正常，但状态逻辑错误 |
| 机器人或自动驾驶训练 | 经验证的仿真环境，按需结合世界模型 | 传感器、动作、状态和边界工况 | 检查任务成功率、碰撞和状态误差 | 逼真画面被误当作可靠训练环境 |
| 数字孪生或长期业务系统 | 数据管线＋显式场景／引擎，按需加入预测模型 | 坐标、对象身份、真实数据和更新机制 | 回放数据更新并核对现实对象映射 | 只有3D外观，没有持续现实关联 |
同一段街道，用于公众展示时，重点是浏览路线、加载时间和可见瑕疵；用于车辆训练时，还要验证车道边界、传感器观测和动作后果；用于运营管理时，则要确认车辆与建筑能否关联真实记录。
场景内容可以相似，合格标准必须随任务变化。项目也可以分阶段推进：概念阶段接受近似空间，交互阶段补齐对象和规则，运营阶段建立数据更新链。但每一阶段都要写明哪些成果可复用、哪些内容需要重建，避免把展示原型直接当成生产基础。
四、评估世界模型，重点检查4类证据
1. 一致性：离开视野后，世界还是否成立？
沿街走到拐角，再返回起点，比较建筑位置、道路连接和固定车辆身份。测试应保留同一次运行中的连续记录，不能用多个片段拼接出"稳定世界"。
短时间一致，不代表长时间一致。遮挡、转弯、离开后重返和长序列运行，应分别检查。若对象重新出现后颜色、位置或身份发生变化，应记录发生条件，而不是只保留最稳定的一次结果。
2. 物理：看起来合理，不等于能够验证
车轮似乎贴地、箱子似乎下落，只能说明画面在视觉上合理。要声称支持某类物理，需要先明确变量、单位、初始条件和允许误差，再检查碰撞、接触、运动或守恒关系。
"没有明显穿模"不能证明存在可读取的碰撞状态；"车辆沿路行驶"也不能证明轮胎、摩擦和动力学已经建模。不同任务需要的物理精度不同，不应使用一段漂亮视频概括全部能力。
3. 可控性：能不能只改变目标对象？
测试能否指定某辆车的速度、初始位置或行驶方向。修改后，是只有目标车辆改变，还是道路和建筑也一起漂移？自然语言提示是一种控制入口，但不自动等于对象级约束。
建议记录命令、初始状态、实际变化、失败条件和重复运行差异。若任务要求稳定回放，还要检查随机种子、重置方式或其他复现条件。
4. 输出：到底交付视频、空间还是资产？
视频、隐式表示、3DGS、可浏览空间和可编辑Mesh属于不同输出。要求候选系统提供实际文件、接口返回或可操作环境，再检查格式、对象结构、材质、尺度及后续工具能否接收。
"可以导出"也要继续追问：导出的是媒体文件、场景表示、独立资产，还是完整工程？一次导出成功，只证明当前样本和设置可用，不代表所有材质、对象语义和交互逻辑都能无损保留。
最后补做一次失败恢复：把车辆放到边界附近，制造遮挡或输入异常，再尝试恢复约定初始状态。记录系统能否重置、错误是否累积，以及复现问题需要哪些条件。
五、3D场景生成什么时候更合适？
如果目标是快速比较街区布局、建筑风格和浏览路线，场景生成通常比先搭完整引擎工程更高效。它可以帮助团队筛选空间候选，再把确认后的结果交给DCC和引擎继续处理。
但生成结果可能只是图像、视频、3DGS、隐式空间或合并网格。进入生产前至少检查：
- 道路、建筑和车辆能否独立选择；
- 单位、原点和坐标轴是否明确；
- 背面与遮挡区是否存在可靠几何；
- 材质与贴图能否随文件完整交付；
- 导入目标软件后，能否完成一次真实修改。
若只能在原平台旋转或漫游，应如实写"可浏览"；只有完成对象级修改与回读，才适合写"可编辑"。
六、游戏引擎什么时候不可替代？
需要输入响应、碰撞、车辆规则、UI、网络同步或目标设备构建时，游戏引擎仍是主要运行端。它的优势不是自动理解世界，而是把显式对象和规则组织成可测试系统。
例如"红灯停车"可以由脚本、状态机或行为系统实现。验收时要查看车辆状态、触发条件和重置结果，不能只看刹车动画。若需要从数据中预测其他车辆行为，可以把学习模型接入引擎，但模型输出仍要经过接口、规则和安全边界管理。
DCC则负责清理网格、修正比例、整理材质和拆分对象。生成资产进入引擎前，通常仍需要完成这一步。建筑没有动画需求时，不必为了"流程完整"强行绑骨；高密度模型能在工作站渲染，也不代表适合手机或实时项目。
七、一条可落地的组合流程
可以采用"场景生成 → 对象拆分 → DCC清理 → 引擎交互 → 导出回读"的组合流程：
- 场景生成： 产出道路、建筑和构图候选，确认空间方向。
- 对象与语义拆分： 区分道路、建筑、车辆和交互区域，保留稳定命名。
- DCC清理： 检查破面、贴图、比例、拓扑、坐标轴和单位。
- 引擎实现： 增加碰撞、输入、状态、车辆逻辑和性能配置。
- 目标端回读： 重新导入交付文件，验证结构、材质、尺度和运行结果。
每一步都应设置检查点，上一环节的预览不能替下一环节验收。格式转换通常有损，可能丢失材质效果、实例关系、对象语义或生成历史。先用一段道路、两栋楼和一辆车跑通小样本，再统计人工修复时间，最后估算整条街的成本。
网页上能浏览，也不代表拥有下载权限、适用许可或可接入接口。涉及商业交付，还要分别核对输入素材、生成结果、第三方资产和目标平台的使用条款。
八、用同一张任务卡比较候选方案
任务卡不必很大，但条件必须一致。建议固定一段道路、两栋楼和一辆车，并统一参考输入、时间预算、目标设备和交付格式。
第一轮：对象与空间
检查道路、楼房和车辆是否存在，车辆能否被单独选中或通过接口定位；记录坐标、单位和对象身份。
第二轮：连续一致性
沿道路前进、转弯，再返回起点。比较固定建筑、路口连接和车辆身份是否变化，并保留连续录像。
第三轮：交互与状态
修改车辆速度，触发一次定义明确的碰撞或停车事件，再执行重置。既看画面，也保存状态日志；没有可读取状态时，不能只凭动画宣布约束通过。
第四轮：导出与回读
输出约定文件，重新导入目标工具，检查比例、材质、对象层级和可编辑性。没有交付文件时，导出项应保持"待验证"。
可从了解AI世界模型与场景生成整理候选入口。该页面只能作为功能了解和测试起点，不能替代当前版本核对、真实文件检查与目标端验收。
任务卡还应写明"不要求什么"。若只交付视觉方案，车辆没有可读取速度不一定导致整项失败；若目标是交互原型，这就是关键缺口。把关键项、非目标项和加分项分开，可以避免为不需要的复杂能力付费。
可复制的测试记录
| 字段 | 填写内容 |
|---|---|
| task_goal | 任务目标、关键项和明确不要求的能力 |
| input_version | 参考图、布局、数据和输入版本 |
| state_access | 可读取状态、单位、频率及缺失项 |
| control_result | 控制指令、目标对象、实际变化和重复结果 |
| consistency_result | 测试时长、路线、遮挡与返回后的变化 |
| physics_evidence | 变量、工况、误差及证据；未测写待验证 |
| export_result | 输出类型、格式、对象结构和许可范围 |
| reimport_result | 目标工具、回读结果及人工修复成本 |
最终按"通过／未通过／待验证"逐项记录。运行录像说明过程，状态日志说明变量变化，文件与回读结果说明交付；三类证据不能互相替代。
九、5个最容易混淆的问题
1. 世界模型与游戏引擎的主要区别是什么？
世界模型通常关注从数据中学习环境表示及变化规律，但定义和实现范围很广；游戏引擎主要把显式对象、规则、渲染和输入组织成可运行程序。两者可以集成，不是新技术对旧工具的简单替代。
2. 世界模型一定具备物理能力吗？
不一定。视觉规律、统计预测与可验证物理不能画等号。先限定任务和工况，再检查变量、约束、单位和误差。"看起来真实"可以作为观察结果，不能单独作为物理验证结论。
3. 世界模型或场景生成工具能导出3D资产吗？
要按具体输出实测。视频不等于网格，可浏览空间也未必包含独立对象。需要取得真实文件，检查格式、材质、层级、尺度和许可，并在目标软件中重新导入。
4. 生成的3D街区适合做数字孪生吗？
它可以成为空间展示或预测环节的一部分，但数字孪生还需要真实数据、可靠坐标、对象身份、持续更新和业务映射。只有外观相似而没有现实关联，更适合称为展示或概念预演。
5. 世界模型与3D Agent是什么关系？
世界模型侧重环境表示与变化预测；3D Agent侧重任务规划、工具调用和迭代执行。Agent可以调用场景生成器、DCC或引擎，也可能使用世界模型，两者不属于同一分类维度。
十、发布前收藏清单
☐ 最终要交付视频、可浏览空间、可编辑资产，还是运行系统？
☐ 控制需要到提示词、对象参数，还是可读取状态？
☐ 一致性覆盖了多长时间，是否包含遮挡、转弯和返回？
☐ 物理结论是否有变量、工况、单位和误差支撑？
☐ 道路、建筑和车辆的对象身份是否保留？
☐ 实际输出格式是否匹配目标工具？
☐ 已完成导出回读，并记录人工修复成本？
☐ 目标设备、运行预算和使用许可是否核对？
不要拿世界模型的视频、游戏引擎编辑器和资产预览图直接比较谁"更强"。先对齐交付目标，再比较同一任务下的证据和成本，选型才有意义。
你的项目更需要快速生成空间、精确控制交互，还是预测环境变化？