企业官网建设流程全解析

今年年初开始，越来越多开发者讨论“AI 做 3D 游戏”的话题。但多数人的预期很容易走偏，以为未来做游戏就是把一句“给我做一个开放世界”甩给大模型，然后 Unreal 窗口里自动生成一个可以玩的关卡。真实情况远没有这么浪漫，真正值得关注的变化，是一套可执行的工程流水线：大模型负责写代码、写脚本、规划逻辑，Unreal 负责渲染与装配，Blender 负责生成和精修 3D 资产，再由 AI Agent 把这些步骤串起来，自动跑出一个又一个可验证的结果。

本文想讲清楚的核心判断是：AI 做 3D 游戏的关键不在于“哪个模型更聪明”，而在于“多模型分工 + 工具链强制校验”。GPT6Sol、Opus5.5 这类模型之所以经常被放在一起讨论，不是因为单一模型已经强大到能端到端输出一个游戏工程，而是因为它们恰好覆盖了 3D 游戏制作里最消耗人力的两类能力：方案规划与编码实现。再加上 Unreal 和 Blender 提供的可编程接口，AI 的产出才从“看起来对”变成“真正能跑”。

读完这篇文章，你会得到一套可以落地的思路：如何拆解 AI 做 3D 游戏的任务，如何用 Blender Python API 批量生成资产，如何把资产自动导入 Unreal，如何用 Agent 编排整个迭代闭环，以及在真正动手时会遇到哪些坑、怎样排错、怎样避免让 AI 的幻觉破坏整个项目。

1. 这篇文章真正要解决的问题

做 3D 游戏的成本一直高在三个地方：美术资产、关卡设计、工程调试。

传统流程里，这三部分几乎是互相隔离的。模型师在 Blender 里建资产，导出 FBX 给 TA，TA 再导入 Unreal 调材质、设碰撞；关卡策划在编辑器里拼场景，反复摆放和测试；程序则负责写玩法逻辑和修复各种崩溃。三个人之间的沟通成本，经常超过实际制作时间。

AI 介入之后，我们可以把“人”的环节替换成“模型 + 工具脚本”，但三块内容依然需要互相咬合。真正难的不是让 AI 写一段 Python 代码，而是让这段代码能在 Blender 里无错运行、能导出符合 Unreal 规则的资产、能被后续流程自动识别并装配进关卡。

这篇文章要解决的问题，就是帮你搭起这样一条最小闭环：

1. 用自然语言描述需求，比如“一片有 10 块巨石和 3 座破旧石屋的废弃营地”。
2. AI 根据需求生成 Blender Python 脚本，批量建模并导出 FBX。
3. 自动化脚本把 FBX 导入 Unreal，并设置好碰撞、LOD、材质。
4. AI Agent 读取运行日志和截图，判断是否达到预期，再决定调整参数重新生成。

换句话说，这不是一篇教你“点按钮生成游戏”的文章，而是一篇教你“如何把大模型接入 DCC 与游戏引擎工作流”的工程实践文章。

2. 角色分工：GPT6Sol、Opus5.5、Unreal 与 Blender 各自该干什么

先给一个直接结论：别指望一个模型从头干到尾。真正可用的工作流，必须让每个工具做它最擅长的事。

这里暂且用 GPT6Sol 和 Opus5.5 作为两个模型代称，重点不是它们的具体版本或发布方，而是它们在流程中承担的角色。

2.1 GPT6Sol：负责规划、拆解和工具选择

GPT6Sol 更适合处理“下一步该做什么”的问题。比如收到“做一个 200 米见方的废土营地”之后，它需要输出一份任务清单：

• 地形基础：生成一片带起伏的地面，限定面数；
• 主体建筑：3 座风格统一的破旧石屋；
• 周边道具：10 块巨岩、散落的木箱和篝火；
• 导出规范：所有静态网格统一使用 FBX，坐标单位统一；
• 性能约束：单资产建议不超过 8 万三角面，碰撞体用简化形状。

这份清单的价值，是让后面的生成步骤有明确边界。没有规划，直接把复杂需求扔给代码生成模型，结果通常是一堆拼不起来的半成品。

2.2 Opus5.5：负责代码生成与表达细节

Opus5.5 更适合承担“把规划变成代码”的角色。Blender Python 脚本、Unreal Python 脚本、数据格式转换脚本，都应该由这一类表达能力强、代码生成稳定的模型来完成。

要注意的是，代码模型产出的质量高度依赖上下文。所以实践中最稳妥的分工是：规划模型先生成结构化的任务描述，代码模型再基于任务描述编写脚本，而不是让同一个模型既做长篇规划又写底层代码，那样很容易丢失细节。

2.3 Unreal：最终装配与实时验证

Unreal 是整个流程的终点。它负责接收 FBX 资产、把资产布置进关卡、检查碰撞和光照效果，并通过 PIE（Play In Editor）验证玩法能否跑通。Unreal 的 Python 插件和编辑器脚本系统，让我们可以绕过手动拖拽，把导入和装配过程变成代码。

这一步的重要性经常被低估。很多 AI 生成的资产在 Blender 里看着正常，一进 Unreal 就出现缩放异常、贴图丢失、碰撞错误。如果不能用代码自动完成导入并立刻反馈日志，AI 就很难自我修正。

2.4 Blender：资产制造车间

Blender 在整个流程里承担“资产制造”的角色。它的价值在于：完全可编程、支持 Python 批量生成、内置建模与雕刻能力、能导出 Unreal 认可的 FBX 文件。

对 AI 工作流来说，Blender 提供了一个非常好的抽象层：AI 不必直接操作 3D 模型文件，只需生成操作 Blender 的 Python 代码，Blender 会在本地执行并输出结果。

2.5 传统流程与 AI 辅助流程的差异

传统流程中，从一个“想法”到“引擎里的可玩资产”，至少经过需求沟通、概念设计、建模、导出、导入、引擎设置六步。每一步之间都存在信息损耗。

AI 辅助流程把这些差异压缩为“描述、生成、执行、反馈”四步。损耗依然存在，但转移到了模型意图理解上。这也是为什么提示词工程仍然重要，AI 不是消除了沟通，而是把沟通对象从“人”换成了“模型”。

3. 跑图闭环：从文本需求到 Unreal 场景的自动迭代

我之前看到有开发者讨论“AI 跑图”，听起来像游戏自动化测试，实际上在 AI 生成 3D 场景的工作流里，“跑图”指的是一个完整的自动迭代循环。

一个典型的跑图闭环是这样的：

文本需求 -> Agent 规划 -> 生成 Blender 脚本 -> 执行脚本产出 FBX -> 导入 Unreal -> 自动布局 -> PIE 运行 -> 读取截图/日志 -> 对比预期 -> 调整参数 -> 再次生成

在这个闭环里，最有价值的设计是“反馈回路”。AI 生成资产之后，如果只是看一眼结果、然后让用户自己手动调整，那就还是传统人工流程。真正让 AI 产生工程价值的是：它能通过 Unreal 运行日志、关卡截图、资源导入结果，判断自己的产出是否符合要求，然后决定重跑还是接受。

3.1 Agent 如何拆解一个 3D 游戏任务

一个 3D 游戏任务可以拆成四层：

• 需求层：玩家会在什么场景里活动，场景的视觉风格是什么；
• 资产层：需要哪些静态网格、材质、贴图；
• 逻辑层：玩法事件、碰撞、触发区域；
• 验证层：如何在引擎里证明这个场景能正常进入和游玩。

AI Agent 的作用是把需求层的自然语言翻译成资产层和逻辑层的具体指令。翻译得越清晰，后续代码生成的成功率越高。

例如“废弃营地”这个需求，Agent 会给资产层下达指令：地面用 512x512 像素的粗糙石砖贴图，建筑使用 6 面墙体加 1 个斜面屋顶，所有碰撞体用凸包近似。给逻辑层下达指令：在营地中心放置一个火把触发区域，玩家进入后触发光照变化。

3.2 MCP 与本地工具桥接的必要性

大模型天然无法直接操作 Blender 或 Unreal，所以必须有一层“桥接”。目前社区比较常见的有两类方案：

第一类是命令行桥接。模型生成脚本文件，Agent 调用blender -b -P xxx.py在后台执行，再把日志和产物路径返回给模型。这种方式最简单、最可控，也适合本文的最小工作流。

第二类是 MCP（Model Context Protocol）桥接，通过本地服务把模型请求转成 Blender/Unreal 的命令。比如有团队在做 Unreal 的 MCP 服务，让模型可以读写关卡、移动 Actor、查询资产路径。这种方式更接近“AI 直接操作编辑器”的体验，但稳定性通常弱于命令行方案，版本升级也可能导致接口失效。

本文后面的实操以第一种方案为主。先把流程跑通，再决定要不要引入更复杂的桥接。

4. 环境准备与前置条件

开始实操之前，先确认你的环境。

4.1 软件清单

• Unreal Engine：使用 5.x 系列即可，不同小版本差异不大。本文不绑定某个具体版本，重点是通用思路。
• Blender：推荐 4.x 系列，Python API 相对稳定。
• Python 3.x：用于编写 Agent 调度脚本。注意 Blender 内置的 Python 是独立的，不需要与系统 Python 混用。

Unreal 侧需要确保安装了 Python Editor Script Plugin：

Edit -> Plugins -> 搜索 Python -> 启用 Python Editor Script Plugin

启用后重启编辑器，你才能在 UE 里执行 Python 脚本。

4.2 目录结构建议

建议在任何 AI 自动生成工作流里都使用固定目录，否则 Agent 很容易找不到文件。

D:/GameProject/ /prompts # 各类提示词模板 /scripts # Blender 和 Unreal 的 Python 脚本 /exports # Blender 生成的 FBX 和贴图 /content # Unreal 工程 Content 目录 /logs # 自动化日志

目录结构也是给 AI 的上下文的一部分。Agent 看到这样一个结构后，就不用猜测导出文件放到哪里了。

4.3 Blender 的无头运行模式

Blender 支持在命令行下以后台模式运行 Python 脚本：

blender -b --python D:/GameProject/scripts/generate_assets.py -- D:/GameProject/exports

这个-b参数表示后台模式，不弹出窗口，适合自动化和 Agent 调用。--后面的参数会传入脚本，脚本可以通过sys.argv读取。

4.4 版本控制的准备

Blender 的.blend文件是二进制格式，不适合普通 Git 对比。建议：

• 源文件.blend放入 Git LFS；
• 导出文件.fbx也放入 Git LFS；
• 生成的 Python 脚本和配置文件走普通 Git 管理；
• 关键操作日志必须入库，方便回溯。

这样做的原因是：AI 生成的脚本经常需要回滚。没有版本控制，你会很难区分“这次生成结果变差”是脚本改坏了还是模型描述变了。

5. 用 Blender Python 批量生成 3D 资产

现在进入核心实操。我们用 Blender Python 写一个批量生成“石头堆”资产的脚本，并导出 FBX。这一步是 AI 生成 3D 游戏资产最常见的起点。

新建文件D:/GameProject/scripts/generate_assets.py：

import bpy import bmesh import os import sys import random # 读取命令行参数 argv = sys.argv[sys.argv.index("--") + 1:] if "--" in sys.argv else [] output_dir = argv[0] if argv else "//exports" output_dir = bpy.path.abspath(output_dir) # 清理默认场景，留空场景开始 bpy.ops.wm.read_factory_settings(use_empty=True) def create_rock(name, location, size=1.0, seed=0): random.seed(seed) bpy.ops.mesh.primitive_ico_sphere_add( radius=size, location=location, subdivisions=2 ) obj = bpy.context.object obj.name = name # 用 bmesh 调整顶点，让石头不规则 bm = bmesh.new() bm.from_mesh(obj.data) bmesh.ops.subdivide_edges(bm, edges=list(bm.edges), cuts=2) for v in bm.verts: v.co.x += random.uniform(-0.2, 0.2) * size v.co.y += random.uniform(-0.2, 0.2) * size v.co.z += random.uniform(-0.1, 0.25) * size bm.to_mesh(obj.data) bm.free() obj.data.update() return obj # 生成 10 块石头 for i in range(1, 11): create_rock( name=f"Rock_{i:02d}", location=(i * 3.0, random.uniform(-2.0, 2.0), 0.0), size=random.uniform(0.8, 1.6), seed=i ) # 确保导出目录存在 if not os.path.exists(output_dir): os.makedirs(output_dir) # 保存源文件 bpy.ops.wm.save_as_mainfile(filepath=os.path.join(output_dir, "assets.blend")) # 导出 FBX，Unreal 通常使用嵌入材质 bpy.ops.export_scene.fbx( filepath=os.path.join(output_dir, "rocks.fbx"), use_selection=False, add_leaf_bones=False, path_mode="COPY" ) print("FBX_EXPORT_DONE:", os.path.join(output_dir, "rocks.fbx"))

这段脚本的逻辑可以这样理解：

1. 用wm.read_factory_settings(use_empty=True)清空 Blender 默认场景，保证每次执行从干净状态开始。
2. create_rock函数基于二十面体生成石头，通过 bmesh 细分并随机扰动顶点位置，让每个石头看起来自然。
3. 输出路径通过命令行参数传入，避免硬编码到某个开发者电脑上。
4. 导出 FBX 时使用path_mode="COPY"，让贴图和材质尽量跟随文件复制，避免引擎端找不到资源。

运行命令：

blender -b --python D:/GameProject/scripts/generate_assets.py -- D:/GameProject/exports

执行成功后，终端里会打印类似这样的日志：

FBX_EXPORT_DONE: D:/GameProject/exports/rocks.fbx

同时D:/GameProject/exports/下会出现assets.blend和rocks.fbx。

5.1 这一步容易踩的坑

Blender 脚本最常见的错误，是用户直接用系统 Python 运行：

python generate_assets.py

这样会直接报ModuleNotFoundError: No module named 'bpy'。因为bpy只存在于 Blender 自带的 Python 环境里。切记通过blender -b --python运行，而不是系统 Python。

另一个坑是对random.seed的使用。如果你希望 AI 多次生成的结果稳定，必须为每个资产固定 seed。否则每次执行石头形状都会变化，后续验证和目标对齐会非常困难。

6. 把 Blender 资产导入 Unreal 并自动装配

FBX 导出只是第一步。接下来需要用 Unreal Python 脚本把这些资产自动导入工程，并配置碰撞和 LOD 设置。

先在 Unreal 编辑器里打开你的项目，然后执行下面的脚本。可以通过 Unreal 的菜单Tools -> Execute Python Script打开执行窗口，或者把脚本保存到项目目录后用命令行执行。

新建文件D:/GameProject/scripts/import_rocks.py：

import unreal import os fbx_root = "D:/GameProject/exports" destination_path = "/Game/Assets/Rocks" # 清理之前的导入记录，避免同名资产冲突 asset_names = unreal.EditorAssetLibrary.list_assets( destination_path, recursive=True ) for asset_path in asset_names: unreal.EditorAssetLibrary.delete_asset(asset_path) # 创建导入任务 tasks = [] fbx_files = [ f for f in os.listdir(fbx_root) if f.endswith(".fbx") ] for fbx_file in fbx_files: task = unreal.AssetImportTask() task.set_editor_property("filename", os.path.join(fbx_root, fbx_file)) task.set_editor_property("destination_path", destination_path) task.set_editor_property("automated", True) task.set_editor_property("save", True) task.set_editor_property("replace_existing", True) tasks.append(task) unreal.AssetImportHelpers.import_asset_tasks(tasks) # 导入后遍历生成资产清单 imported_assets = unreal.EditorAssetLibrary.list_assets( destination_path, recursive=False ) for asset_path in imported_assets: unreal.log("IMPORTED_ASSET: " + asset_path) unreal.log("ASSET_IMPORT_DONE")

这段脚本做的事情是：

• 删除目标目录下旧资产，保证重复导入不会残留多余版本；
• 创建AssetImportTask并批量导入 FBX；
• 导入完成后输出资产清单，方便 Agent 读取结果。

需要说明的是，unreal.EditorAssetLibrary.list_assets、unreal.AssetImportHelpers.import_asset_tasks这些 API 是 Unreal Python 插件里的通用接口。如果你的 Unreal 版本较旧或 API 名称有变化，请以当前版本的 Python API 文档为准。

6.1 如何验证导入结果

脚本执行完后，可以在 Unreal 内容浏览器中打开/Game/Assets/Rocks，确认 10 个静态网格是否存在。

更自动化的验证方式是控制台日志。脚本已经输出了IMPORTED_ASSET和ASSET_IMPORT_DONE，Agent 可以读取日志，判断导入是否成功。

如果在导入后还需要设置碰撞，可以在 Unreal Python 里继续处理。通常更常用的做法是直接在 Unreal 中设置默认导入设置，或者在 FBX 导出时就把碰撞体一并导出。这里建议简化方案：在 Unreal 的 Static Mesh 编辑器中，通过Collision -> Auto Convex Collision为每个资产生成碰撞体。虽然是引擎自动计算，但对 AI 生成的资产来说，已经足够稳定。

6.2 关卡装配

光有资产还不够，还需要把它们摆放到关卡中。下面是一个简单的 Unreal Python 放置代码：

import unreal world = unreal.EditorLevelLibrary.get_editor_world() spawn_location = unreal.Vector(0.0, 0.0, 0.0) spawn_rotation = unreal.Rotator(0.0, 0.0, 0.0) asset_path = "/Game/Assets/Rocks/Rock_01.Rock_01" asset = unreal.load_asset(asset_path) if asset: actor = unreal.EditorLevelLibrary.spawn_actor_from_object( asset, spawn_location, spawn_rotation ) if actor: actor.set_actor_label("AI_Rock_01") unreal.log("SPAWN_ACTOR_OK") else: unreal.log_warning("SPAWN_ACTOR_FAILED")

这个例子演示了 Unreal 脚本编辑器的基本能力：加载资产、生成 Actor、设置标签。实际项目中，Agent 可以通过遍历资产清单，自动把一组石头摆成预设布局。

7. 用 AI Agent 串联完整工作流

环境准备好了，脚本能跑了，接下来要解决“谁来调度”的问题。

在 3D 游戏生成场景里，Agent 的本质是“把长任务拆成多个短步骤，并在每一步验证结果”。一个最小 Agent 流程可以这样设计：

1. 用户输入需求：废弃营地，3 间石屋，10 块石头 2. Agent A（规划） -> 输出任务 JSON：资产尺寸、数量、命名规则、导出路径 3. Agent B（代码生成） -> 根据任务 JSON 生成 Blender 脚本 4. 执行器 -> 运行 blender -b --python generate_assets.py -> 检查日志是否出现 FBX_EXPORT_DONE 5. Agent B（导入代码） -> 生成 Unreal 导入脚本 6. 执行器 -> 在 Unreal 中运行 import_rocks.py -> 检查日志是否出现 ASSET_IMPORT_DONE 7. Agent A（评估） -> 读取资产列表和 PIE 运行截图 -> 决定任务是否完成，或是否需要修改

不要小看每一步里的“检查日志”动作。这正是 AI 工作流和“AI 写了个脚本给你跑”之间的关键区别。没有日志校验，Agent 无法知道自己的代码出了什么问题，也就无法进入下一步。

7.1 Agent 调用的提示词模板

规划模型和代码模型需要不同的提示词。规划模型侧重约束，代码模型侧重实现。

规划模型示例：

你是一名 3D 游戏场景规划师，请把以下需求拆解为结构化任务。 需求：废弃工业营地，包含 3 座破旧厂房、10 块混凝土碎块、 一条贯穿营地的土路。 输出要求： - 资产类型清单和数量 - 每个资产的尺寸范围 - 命名规则，使用 Snake_Case - 性能限制：单资产三角面数不超过 80000 - 导出路径：D:/GameProject/exports - 验证标准：Unreal 中能正常生成静态网格并放置到地图

代码模型示例：

你是 Blender Python 专家，请根据以下任务编写脚本。 任务 JSON： {"asset_type":"rock","count":10,"size_range":[0.8,1.6],"output_dir":"D:/GameProject/exports"} 要求： - 使用 bpy 和 bmesh - 随机种子固定，保证可复现 - 导出 FBX 时使用 path_mode="COPY" - 只在后台模式运行 - 打印关键日志，包含 FBX_EXPORT_DONE

7.2 人工审核点的设置

即使全流程自动化，仍然要设置至少一个人工审核点：

• 第一次导入 Unreal 后，人工检查资产是否符合预期；
• 每次修改生成策略后，人工检查之前已生成的资产是否会受影响；
• 任何“删除资产”操作，先备份，再执行。

AI Agent 自动删除或覆盖资产是非常危险的操作。上面的导入脚本里，我展示了删除旧资产的逻辑，但它只适用于你已经明确“目标目录里的资产全部由脚本生成、不包含手工资产”的场景。如果目录里混有人工制作的资产，就不应该允许 Agent 直接删除。

8. 常见问题与排查方法

这个流程里的坑主要集中在“环境、坐标、API、资源规范”四个方面，下面用表格列出。

以上排错路径的通用原则是：先看日志，再对照脚本里每一步的执行权限和路径，最后再怀疑模型生成的逻辑。大多数情况下，是环境问题或规格问题，而不是模型能力问题。

9. 最佳实践与工程建议

AI 辅助 3D 游戏开发的工程化，远比单个脚本生成资产复杂。下面是几条经过实际项目验证的经验。

9.1 命名规范比想象中重要

AI 生成的资产命名如果不一致，Unreal 导入后就会变成一堆难以识别的StaticMesh_0、StaticMesh_1。建议一开始就在提示词里强制命名规则：

• 资产类型前缀：SM_Rock_01、SM_Building_Wall_02；
• 材质前缀：M_Rock_Gray；
• 纹理前缀：T_Rock_Albedo。

统一命名不仅便于人工排查，还能让 Agent 后续自动布局时更容易按类型筛选资产。

9.2 一次只验证一个变量

AI 生成 3D 资产时，如果同时改变石头数量、形状、材质、导入配置，一旦结果出错，你很难判断究竟是哪一步出了问题。

更稳妥的做法是分阶段验证：

1. 先生成 3 块石头，不设置复杂材质，只验证 Blender 脚本能跑通；
2. 再导入 Unreal，只验证导入链路；
3. 然后增加数量，验证批量生成的稳定性；
4. 最后加入材质和随机扰动，验证风格一致性。

每一阶段都保留通过验证的脚本版本。不要用“重新全部生成一次”来解决问题，否则会因为随机种子不同而引入新问题。

9.3 给 AI 生成的代码加安全围栏

大模型生成的代码可能包含错误 API，也可能尝试读取或删除不相关文件。建议在自动化执行前做几层保护：

• 脚本运行目录固定，不使用相对路径遍历；
• 删除资产操作必须显式声明目标目录和文件前缀；
• 所有写入操作限制在exports和logs目录内；
• 执行前先备份已有资产。

对单个脚本可以设置最大运行时间，比如 Blender 后台运行超过 10 分钟就终止。这样可以防止模型生成死循环脚本。

9.4 把“日志”当成一等公民

在 Agent 工作流里，日志不是给人看的技术输出，而是模型自我评估的输入。建议在所有脚本里加入明确的成功标记：

FBX_EXPORT_DONE ASSET_IMPORT_DONE SPAWN_ACTOR_OK

Agent 只需要检查日志是否包含这些标记，即可决定下一步怎么走。失败时也要输出明确的失败标记和错误类型，否则模型只能通过报错堆栈猜原因，效率极低。

9.5 建立资产验收清单

每次生成后，建议用一份清单自动检查资产质量：

• 资产是否存在于预期目录；
• 三角面数是否在阈值内；
• 是否有碰撞体；
• 是否在 Unreal 中正常加载；
• 是否能在关卡中生成 Actor；
• 截图对比是否符合视觉描述。

这些检查项不需要一次性做到完美，但每一项都应该存在。Agent 会基于这些结果决定是否需要重新生成。

9.6 关注 AI 输入数据的合规风险

AI 生成资产时，如果模型基于真实版权图片或商业模型进行模仿，会造成潜在版权风险。建议在项目中明确要求：所有生成资产必须为原创或基于开源授权资源，并在发布前检查资产来源。

这一点对商业化项目尤其重要。AI 的效率优势不应当以不可控的法律风险为代价。

10. 总结与后续学习方向

整篇文章的核心观点可以浓缩为一句话：AI 做 3D 游戏的成功率，取决于你能否把“模型思考”转成“工具可执行、引擎可验证、Agent 可反馈”的闭环。GPT6Sol、Opus5.5、Unreal、Blender 这四者的组合，本质上是把大模型的规划与生成能力，接入了 3D 美术和游戏引擎这两套成熟工具。

如果你想继续深入，建议按下面的顺序实践：

1. 先跑通本文演示的 Blender 批量生成资产流程，不着急接 Agent；
2. 再把 FBX 导入 Unreal 的脚本跑通，确保资产能进引擎；
3. 然后加入简单的 Agent 编排，只串联“生成-导入-记录日志”三个环节；
4. 最后再加入 PIE 验证、截图反馈、参数迭代等进阶能力。

这个方向最值得关注的是 Unreal 对 Python 生态的持续完善，以及 Blender 与引擎之间协作规范的统一。模型能力本身还在快速迭代，但工具链的稳定性和工程约束，才是决定 AI 真正能替代多少重复劳动的关键。手里没跑通一条可复现的流水线之前，再强的模型也只是“看起来会做游戏”。