这两年做游戏原型，最明显的变化就是“资产”和“代码”这两件最耗时的事，终于有了能真正干活的 AI 搭档。Tripo Astra 负责把一句话描述变成带 PBR 材质的 3D 资产，Codex 负责把一段需求变成可编译的 C++ 逻辑，两者再汇入虚幻引擎——一套从零到可运行 Demo 的流程，就能压缩到几个小时以内。这篇文章就是一套我已经跑通的原型工作流复盘：用什么工具、按什么顺序做、在哪个环节容易翻车，全部基于实际操作记录，不是那种只讲概念的科普。
如果你正在做独立游戏、Game Jam 原型，或者团队里急需要一个“能玩”的关卡验证玩法，这一套流程可以直接参考。我也踩了不少坑，特别是 Codex 的模型权限报错、UE5 工程编译失败、AI 生成模型导入后比例错乱这类问题，都会在最后整理成速查表。
1. 方案拆解：一套“AI出资产、AI写代码”的原型工作流
1.1 这套组合到底解决什么问题
传统做游戏原型，最怕两件事：第一，美术资产没到位；第二，逻辑代码写不动。过去一个人想快速验证一个玩法，要么去买现成资产包，要么啃几个月建模，要么硬着头皮堆代码。很多时候想法很好，卡在这两步。
Tripo Astra 这类 AI 3D 生成工具，目标是把“有资产”这件事变成分钟级操作。你在输入框里写一句“一间中世纪森林小屋，木墙、茅草顶”，它就能给你生成一个带贴图的三维模型。不用建模软件，不用雕刻，不用展 UV，至少从“有没有”这个角度看，它已经把门槛砍掉了一大截。
Codex 解决的是另一头。它是 OpenAI 推出的编程智能体，和普通聊天问答不一样，它可以直接在你的项目目录里读写文件，创建 C++ 类、修改代码、帮你跑构建命令。对虚幻引擎这种巨型 C++ 工程来说，这意味着“写一个拾取物品的 Actor”这种任务，你只要用自然语言描述清楚，Codex 就能把 .h 和 .cpp 都生成好，剩下的是编译和微调。
两者组合起来，价值就很明显了：Tripo Astra 把你脑子里的“场景想象”变成视口里的模型，Codex 把“玩法需求”变成可运行的逻辑。虚幻引擎负责把这些东西串成最终体验。一个人，一台电脑，几个小时，就能做出以前需要一个三到五人的小团队才能完成的原型验证。
适合这么干的人，我总结下来有三类：
- 独立开发者，Core Loop 还没有验证，不想过早投入美术制作。
- 程序或策划背景，模型能力约等于零，但需要占位资产快速看效果。
- Game Jam 参与者，时间极紧，需要“有东西能玩”而不是“资产的精细度”。
1.2 为什么选 Tripo Astra 而不是其它 3D 生成方案
市面上能做文字生成 3D 的工具不算少，Meshy、Luma Genie、Tripo 这些都是经常被提到的。我最后把 Tripo Astra 当作主力，是有几个实操层面原因的。
第一是生成速度。Tripo Astra 在线生成一个中等复杂度的资产，通常几十秒到两三分钟就能出结果。这个速度对原型阶段非常重要，因为你要反复试提示词，一个资产不满意就换一个，等待时间过长的工具根本没法进入试错循环。
第二是格式对游戏引擎友好。它可以直接输出 glb、fbx、obj 这些常见格式，并且支持生成 PBR 材质贴图，BaseColor、Normal、Roughness、Metallic 这些通道都会带出来。导入 UE5 之后，你不需要手动连连看，直接使用资源就能看到一个接近成品的材质效果。
第三是网格质量在可接受范围内。AI 生成的网格拓扑大多数时候不干净，但原型阶段要的不是生产级资产，而是把空间占住、把视觉方向定下来。Tripo Astra 生成的结果，三角面数可以选择档位，低档位适合远景布置，高档位适合近距离观察，这个灵活度让我不用在性能问题上过于纠结。
当然，它也有明显边界：网格可能破面，UV 可能出现拉伸，贴图接缝偶尔会很显眼。你要不是把它当最终资产用，这些问题完全可以接受。我在 4.2 里会详细讲怎么规避。
1.3 为什么是 Codex，而不是直接在 UE5 里手写
说实话，UE5 的蓝图系统已经算好上手了，但你做一个稍微复杂的交互逻辑，蓝图节点的连线还是容易把人绕晕。Codex 的价值在于，它不是一个只会输出代码片段的聊天机器人，而是能在本地仓库里实际干活的助手。
它可以在你指定的目录里创建文件、读取项目结构、修改已有代码、执行命令。放回虚幻引擎的语境里，就是它可以在你的工程源码目录里新建一个 Actor 类，写好成员变量、UPROPERTY 标记、构造函数、碰撞回调，这些对不熟悉 C++ 的人来说是最难迈的一步。
我实际使用时的几个典型场景：
- 新建一个 C++ Actor 类，命名规范、继承关系、模块引用都帮我写好。
- 看懂引擎源码，比如某个组件在哪个头文件里，哪个函数在什么条件下被调用。
- 处理编译报错，把错误信息原样贴给它，让它定位问题并给出修改方案。
- 批量处理类文件，比如给多个 Actor 统一加一个接口函数。
注意，Codex 不是万能的。虚幻引擎工程巨大，它的上下文窗口有限，不要让它一次性修改十几个文件，任务拆小了它才能干好。具体协作姿势我在 3.3 里详细说。
1.4 这套流程的边界：能做什么，不能做什么
这套流程能做的，是快速把“想法”变成“能打开、能操作、能看到效果”的 DEMO。它适合验证玩法，适合把抽象概念具象化，适合在项目早期拉通一条从资产到逻辑的管道。
但它不能做的，是直接产出生产级内容。Tripo Astra 生成的模型，需要清理拓扑、重新展 UV、补细节，才能放进正式项目里；Codex 生成的代码，涉及性能优化、内存管理、网络同步这些复杂话题时，仍然需要人来把关。我的定位是：它们是两个上手很快的实习生，你给需求，检查产出，关键地方及时纠偏。
明确了这个边界之后，后面所有的步骤都可以围绕“原型”两个字来安排，不会因为某个环节不够完美而卡住。
2. 环境准备：先把 Codex 和 Tripo 跑起来
2.1 安装 Codex 的两种方式
OpenAI 官方给 Codex 提供的入口，主要是桌面客户端和 CLI 命令行工具两种。桌面客户端适合不太熟悉终端的用户，打开之后就是一个可以对话和显示文件变动的界面；CLI 适合已经在用终端工作流的人，前后端项目里可以直接调用。
我自己的习惯是 Windows 上把桌面客户端和 CLI 都装一遍，Ubuntu 环境则只用 CLI。Windows 上安装的常见坑，值得先说一遍：
- 安装目录不要选带中文、带空格的位置，这类路径最容易让后续命令行工具找不到可执行文件。
- 安装完成后必须重开一次终端，让 PATH 环境变量重新加载。
- 杀毒软件有时会把命令行工具当成可疑程序拦截，需要手动放行。
- 如果安装过程显示“未完成”，多半是权限不足，或者安装包没完全下载下来，直接以普通用户身份重跑安装器就行。
Ubuntu 下我自己用的官方安装脚本方式，装完之后需要确认 codex 命令是否在 PATH 里。如果提示找不到 codex，去编辑 ~/.bashrc 或 ~/.zshrc，把安装目录加进去。这一步非常简单，但很多新手会卡在这，以为装失败了。
启动之后，先用账号登录。登录这一步是后续所有操作的前提，我之前遇到过登录后仍然提示无法定位 CLI 二进制文件的情况，后来发现是安装目录和 PATH 没设置好，和登录本身没有关系。
2.2 登录与模型选择：账号权限决定你能用哪些模型
用 ChatGPT 账号登录 Codex 之后，默认会选择一个可用的模型。这里就涉及一个非常高频的报错信息：某个模型在 Codex 里提示 not supported，后面还跟着一句和当前账号类型相关的话。
我实测下来的解释是，Codex 支持的模型集合和你账号的套餐权限是绑定的。普通账号能用的模型，和付费套餐账号能用的实验模型，并不完全一样。如果你在一个账号下用编辑器，在另一个账号下用 CLI，两边可用的模型列表可能完全不同。
处理思路也很直接：
- 先看当前 Codex 配置里指定的是哪个模型。
- 再去确认这个模型是否在当前账号的可用范围里。
- 如果不在，直接把模型切换回账号默认支持的那一个。
千万不要因为模型权限不够去折腾账号之外的旁门左道，合规使用，把模型参数调回官方默认值就能解决绝大多数问题。Codex 界面本身是全英文的，但对话输入中文指令完全没问题，不用专门找汉化包，我测试下来它对中文理解很到位，代码注释也可以让它用中文写。
2.3 接入 Tripo Astra：网页端与 API 两种使用姿势
Tripo Astra 的接入，最无脑的方式是直接打开网页端，输入提示词，生成，下载。这个路径适合刚开始测试提示词、需要快速看效果的人，我也最推荐先走一遍网页端，因为你得先知道这个模型对什么样的描述最敏感。
网页端生成之后，可以预览模型，旋转视角看网格、看贴图，满意就下载 glb 或 fbx。不满意就改提示词，重新生成。这一步值得耐心做，因为后面的 UE5 环节依赖资产质量。
当你要批量生成资产的时候，网页端就不太够用了。这时候可以去申请一个 API Key，走官方接口。基本流程是提交生成任务、轮询任务状态、任务完成后下载结果。我在 Ubuntu 环境下也用 Python 调过接口，整个链路很清爽。
一个最简的请求提交逻辑大概长这样：
import requests API_KEY = "your_tripo_api_key" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "type": "text_to_model", "prompt": "a low-poly medieval hut with thatched roof, wood walls, stone base, PBR texture, game asset", "texture": True, "pbr": True, "format": "glb", "face_count": "medium" } resp = requests.post("https://api.tripo3d.ai/v2/tasks", json=payload, headers=headers) print(resp.json())注意，这只是请求提交的数据形态，实际字段需要以官方文档为准。批量生成的时候可以写一个循环，把几十个提示词分批提交，控制好并发，避免把配额打满。这种批量能力在后面要铺一个完整关卡时特别有用。
2.4 项目初始化：新建 UE5 C++ 工程时要注意什么
虚幻引擎项目初始化这一步，看起来简单，但直接影响 Codex 能不能顺畅工作。
我的建议是建一个 C++ 工程，而不是纯蓝图工程。原因很简单：Codex 最擅长的产出是文本代码，蓝图在编辑器里是一堆节点，它没法直接操作。你新建一个第三人称 C++ 模板工程，就同时拥有了角色控制代码和 C++ 项目结构，后面让 Codex 新加类、改类都很方便。
引擎版本方面，我用的是 UE5.4，UE5.5 也能用，但如果你同时要兼顾老插件和旧项目，5.4 的插件兼容面更宽。工程命名一定要用英文，路径也不要出现中文，这一点对 C++ 编译影响很大，我见过不少因为路径带中文导致的诡异编译错误。
工程建好之后，先跑一次，确认基础模板能在编辑器里正常 Play，再往下走。不要急着加 AI 工具，先把地基确认好。
3. 实操：从一个篝火小屋开始
3.1 用 Tripo Astra 生成第一批资产：提示词怎么写
我这次原型的主题是“森林篝火小屋”，场景需要四类资产：林间小屋、篝火堆、木箱、石块或石桥。资产不多，但足够覆盖不同形态和材质类型。
提示词的核心结构，我总结为“主体 + 风格 + 材质 + 渲染约束”。以小屋为例：
a small medieval hut in forest, wooden planks walls, thatched roof, stone foundation, low poly game asset style, clean topology, PBR texture, no background, centered拆开来看：
- 主体：a small medieval hut in forest，先把是什么说清楚。
- 风格：low poly game asset style，给引擎一个明确的风格目标。
- 材质：wooden planks walls, thatched roof, stone foundation，材质决定贴图走向。
- 渲染约束：PBR texture, no background, centered，避免生成带背景的展示图，也避免物体偏出画面中心。
篝火堆我写的是 “a campfire with logs and stones, charcoal, low poly game asset, PBR texture, no background”，木箱是 “a wooden crate, old wood, metal corner braces, low poly game asset, PBR texture”。
小技巧是每个提示词都补一句 “game asset” 和 “PBR texture”，这两个词对 AI 生成结果的材质风格影响很大。如果平台支持 negative prompt，把不想要的东西写进去，比如 “with people, with animals, with background”，能明显减少废稿。
生成的时候，每类资产我建议一次出 3 到 4 个候选，挑一个最顺眼的。这个挑选过程不用太纠结细节，只要没有明显破面、形状符合预期就行，因为原型阶段后面还有导入 UE5 的测试。
3.2 导出与导入：FBX 进 UE5 的参数设置
Tripo Astra 生成完可以下载 glb 或 fbx。我自己的经验是，能选 FBX 就选 FBX，UE5 对 FBX 的导入是最成熟的，glb 虽然也能用，但需要在项目设置里启用 GLTF 加载插件，多一层麻烦。
导入时几个参数值得认真对待：
- Import Uniform Scale：这个参数默认通常是 1，但 AI 生成的模型单位不一定统一，有的资产导出后显示只有几厘米高，需要在这里调整缩放比例。
- Normal Import Method：保持源数据法线，不要默认重新计算，否则有些模型的明暗会变得很奇怪。
- Collision：可以先自动生成，跑起来之后如果碰撞不对，再手动改成简单碰撞盒。
- Material：Tripo 输出 PBR 贴图时，UE5 导入后会自动创建材质引用，不需要手动连节点。
导入之后，我习惯立刻在场景里检查三件事：模型能不能正常显示、缩放比例是否合适、碰撞体是不是简化过的。这三个问题在 AI 生成资产上出现频率很高，早发现早调整，比拖到后面排查省时得多。
把下载下来的资源统一放进 Content 目录下的 Models 文件夹里，方便管理。资产名字尽量用英文，避免后续 C++ 引用时出问题。
3.3 用 Codex 写第一段交互代码
场景有了，下一步就是让它“能玩”。我设计的交互是：玩家靠近小屋旁边的金属探测器（这里我用一个木箱代替），按 E 拾取，屏幕提示获得物品。
用 Codex 之前，先把任务拆成可落地的子项：
- 新建一个 C++ Actor 类，用来表示可拾取物。
- 给这个类加一个球形碰撞体和一个静态网格体组件。
- 写一个重叠回调函数，当角色进入范围时触发拾取逻辑。
在 Codex 终端里，我输入的指令大概是这样的：
Create a new C++ actor class called APickupActor in the project. It should have a USphereComponent as root, a UStaticMeshComponent attached to it, and an overlap event that prints the item name when a character enters. Use the project's module name for the generated header include. Add necessary #include lines.Codex 会在项目的 Source 目录下生成 PickupActor.h 和 PickupActor.cpp。生成完之后，我没有直接粘到 UE5 里，而是先打开文件做了一次 review，确认组件创建、碰撞回调这些关键逻辑没有明显遗漏。这一步是必要的，毕竟它是 AI 生成的代码，不是经过编译验证的引擎源码。
最终编译通过的版本大致是下面这样的。
PickupActor.h：
#pragma once #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "PickupActor.generated.h" DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FOnPickedUp, APickupActor*, PickupActor); UCLASS() class ASTRAUE5PROTO_API APickupActor : public AActor { GENERATED_BODY() public: APickupActor(); UPROPERTY(BlueprintAssignable, Category = "Pickup") FOnPickedUp OnPickedUp; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Pickup") FName ItemName; protected: virtual void BeginPlay() override; UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Pickup") class USphereComponent* CollisionSphere; UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Pickup") class UStaticMeshComponent* MeshComponent; UFUNCTION() void OnOverlapBegin(UPrimitiveComponent* OverlappedComponent, AActor* OtherActor, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult); };PickupActor.cpp：
#include "PickupActor.h" #include "Components/SphereComponent.h" #include "Components/StaticMeshComponent.h" #include "GameFramework/Character.h" APickupActor::APickupActor() { PrimaryActorTick.bCanEverTick = false; CollisionSphere = CreateDefaultSubobject<USphereComponent>(TEXT("CollisionSphere")); RootComponent = CollisionSphere; CollisionSphere->SetSphereRadius(70.0f); CollisionSphere->SetCollisionProfileName(TEXT("OverlapAllDynamic")); MeshComponent = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("MeshComponent")); MeshComponent->SetupAttachment(RootComponent); MeshComponent->SetCollisionEnabled(ECollisionEnabled::NoCollision); } void APickupActor::BeginPlay() { Super::BeginPlay(); CollisionSphere->OnComponentBeginOverlap.AddDynamic(this, &APickupActor::OnOverlapBegin); } void APickupActor::OnOverlapBegin(UPrimitiveComponent* OverlappedComponent, AActor* OtherActor, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult) { if (ACharacter* Character = Cast<ACharacter>(OtherActor)) { UE_LOG(LogTemp, Warning, TEXT("Picked up: %s"), *ItemName.ToString()); OnPickedUp.Broadcast(this); Destroy(); } }这个版本的逻辑很简单：玩家进入碰撞球后触发拾取回调，打印物品名，广播一个委托，然后销毁自身。
编译是绕不开的一步。在终端里直接让 Codex 帮你找到编译方式也行，但它不熟悉你机器上的具体引擎安装路径，更快的办法是你自己把编译命令跑一遍。一次编译过了，说明 Codex 生成的代码至少没有语法和引用错误。
编译报错的时候，把完整的错误信息原样贴给 Codex，它会给你改法。我遇到过几次重复报错，仔细看其实是我没有把最新生成的代码重新编译，属于操作习惯问题，不是工具的问题。
3.4 串起来：白盒关卡里的拾取演示
资产和代码都准备好了，接下来就是组装。
我打开 UE5 编辑器，把从 Tripo 下载的小屋、木箱、篝火、石块拖进场景。小屋放中间，篝火放门口，木箱放屋角，石块铺一条小路。摆放过程中如果发现某个资产太大或太小，直接在细节面板里调整缩放，不用回到 Tripo 重新生成。
然后把 PickupActor 拖进场景，把它的 Mesh 组件指定成木箱的静态网格体，ItemName 设为 WoodenCrate。为了让玩家知道靠近会触发拾取，我让 Codex 又生成了一段逻辑：在角色类里声明一个依赖距离的交互检测，靠近显示提示文字，按 E 触发拾取。这一步我用的是 UMG 提示，逻辑不复杂，但已经展示出一个可玩交互的原型。
最后运行 PIE（Play In Editor），第三人称角色出生点放在小屋门口，走两步靠近木箱，屏幕提示出现，按 E，日志里输出 Picked up: WoodenCrate，木箱消失。至此，一个完整的经验闭环已经跑通。
这个流程里最让我觉得有效率的是，资产的生成和代码的生成是并行推进的。Tripo Astra 生成模型的时候，我就可以让 Codex 先把 PickupActor 写好，两边同时跑，最后只需要把它们在编辑器里接起来。
4. 常见问题与排查实录
4.1 Codex 相关的报错与处理
这一路下来，Codex 的问题我遇到不少，大部分集中在安装、模型选择、连接状态这三类。
安装类问题最典型的是 Windows 桌面版安装中断，或者提示 “unable to locate the codex cli binary”。我遇到之后的第一反应就是检查 PATH 环境变量。CLI 没有进 PATH，终端就找不到可执行文件，和安装本身有没有完成是两回事。重新添加路径，重开终端，问题就消失了。
模型选择类的报错，就是我前面提到的 “not supported” 问题。有一次我在 Codex 配置里手动指定了一个实验模型，然后它就一直报当前模型不支持，切回默认模型之后立刻恢复正常。还有一次是切换了登录账号，新账号的权限和老账号不一样，也导致模型不可用。这一类问题的本质，是账号权限和模型可用范围不匹配，先想清楚这一点就不会乱试。
连接状态类的报错，比如一直显示重新连接、打不开、请求某个端点失败等，基本都是本地网络环境异常。处理顺序我固定是三步：结束 Codex 相关进程重新启动，检查网络是否能正常访问目标服务，再不行就换个网络环境试试。不要在这上面反复重装软件，意义不大。
4.2 导入模型后的资产问题
AI 生成资产不是拿来就能用，导入 UE5 之后会有一堆小问题。
最常见的是模型在内容浏览器里能看到缩略图，拖到场景里却什么都不显示。我检查下来，大部分情况是导入时网格体没有真正生成，或者静态网格体资源为空。解决办法是回到导入设置，确认“导入网格体”是勾选状态，然后重新导入。
其次是比例问题。Tripo Astra 生成的模型尺寸经常不是米制单位，一个小屋可能只有 30 厘米高，导入后和第三人称角色放在一起特别违和。处理方式是两种：一种是在 UE5 导入窗口里改 Import Uniform Scale，另一种是导入完成后直接调整场景里 Actor 的 Scale 值。前者更干净，因为模型内部尺寸就对了。
第三是材质问题。Tripo Astra 带 PBR 贴图的时候，UE5 自动创建的材质引用通常没问题。但如果下载的只是白模，需要自己建材质，把 BaseColor、Roughness、Metallic 三张贴图连到对应通道。建议先把贴图放到 Material 文件夹里统一管理，别让 UE5 默认的命名把你绕晕。
4.3 UE5 运行时的图形和字体问题
很多人在“玩”UE5 项目时会遇到花屏、闪退，其实大多数时候不是 AI 工具的问题，而是显卡驱动和渲染特性的组合不对。我处理这类问题时，顺序是固定的：
第一，更新显卡驱动，这个能解决大概一半的问题。第二，关闭一些重型渲染特性，比如 Nanite、Lumen，或者把渲染缩放调低。第三，删除项目 Saved 目录下的着色器缓存文件，重新编译一次着色器。
虚拟引擎的项目运行本质是大量着色器编译任务，缓存一旦损坏，花屏、闪退就会频繁出现。别上来就怀疑显卡坏了，优先排软件层面。
还有一个 UE5.4 里经常问的字体问题。要在 UMG 里显示中文，需要先把 TTF 或 OTF 字体文件导入内容浏览器，然后右键创建复合字体资产，设置字体范围时选“全字库”，再把 UMG 的 Text 控件字体指定成这个资产。如果不这么操作，中文显示出来就是方块。
4.4 一张速查表：问题、原因、处理办法
我把这段时间踩过的问题整理成了一张速查表，方便以后照着排查：
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| Codex 提示模型 not supported | 当前账号没有该模型权限 | 切回账号默认支持的模型 |
| 找不到 codex cli binary | CLI 目录不在 PATH 中 | 把安装目录加入 PATH，重开终端 |
| Windows 安装未完成 | 权限不足或安装包下载不完整 | 重跑安装器，确保安装包完整 |
| Codex 一直显示重新连接 | 后台进程卡死或网络异常 | 结束进程重启，检查网络连通性 |
| 请求 /responses 端点失败 | 当前网络环境异常 | 检查基础网络，稍后重试 |
| 模型导入后不显示 | 网格体未生成或导入选项取消 | 勾选“导入网格体”，重新导入 |
| 模型比例不对 | 导出单位不是米制 | 调整 Import Uniform Scale |
| 材质显示异常 | 缺少贴图引用或通道连接错误 | 手动创建材质并连接 PBR 贴图 |
| 运行项目花屏闪退 | 显卡驱动或着色器缓存异常 | 更新驱动，删除 Saved 下缓存 |
| 中文字体显示方块 | 字体资产范围未设置 | 创建复合字体，设置全字库范围 |
这张表不一定覆盖所有情况，但能覆盖 AI 驱动原型开发里 80% 的日常问题。
5. 后续扩展与个人心得
5.1 从原型到生产：资产清理是绕不开的
Tripo Astra 生成的资产，当我把它当白盒或临时占位用时非常顺手，但只要进入正式项目的考虑范围，就必须做清理。我通常的处理流程是这样的：
- 用 Blender 重拓扑，把三角面数控制到游戏可接受的范围。
- 重新展 UV，因为 AI 生成的 UV 往往有拉伸，烘焙贴图会露馅。
- 在 Substance Painter 或者 UE5 里重新调整材质细节，把粗糙度、金属度这些参数调成项目统一的风格。
- 补齐 LOD，远景用低面数版本，近景用高面数版本。
这四步做完，一个资产才能算真正进入生产管线。换句话说，AI 生成资产缩短的是“从零到有”的时间，而不是“从有到精”的时间。
5.2 提示词和任务拆解是两门手艺
表面上，这套流程的工具是 Tripo Astra、Codex、UE5，但真正决定产出质量的是两门软技能：写提示词和拆任务。
写 3D 生成的提示词，要求你把一个视觉想象拆成“主体、风格、材质、约束”四个维度，任何一个维度缺失，结果就可能跑偏。而且同一套提示词模板，换一个场景之后可能需要微调。比如生成金属物品要加 metallic 相关描述，生成有机体要加 soft organic shapes，这些都是要反复试错总结的。
给 Codex 下指令也是类似。你不能说“帮我做一个拾取系统”，这个范围太大了，它的输出很可能不是你想要的。拆成“新建 Actor 类、加碰撞和网格体、写重叠回调、编译通过”，每一步都是可验证的，错误才能被快速定位。
我自己的体会是，这两门手艺都靠反馈循环：写一段提示词，看结果；拆一个任务，看产出。迭代几轮之后，你自然就知道什么样的描述能生成什么，什么样的指令能被 Codex 高效执行。
5.3 后面可以这么玩
这套流程跑通之后，扩展空间还挺大的。
批量生成是第一个值得试的方向。把几十个物品的提示词整理成一个 JSON 文件，用 Tripo 的 API 批量提交任务，挨个下载，再做一套 UE5 编辑器脚本，把下载资源自动导入并分类，整个资产库就能在一天之内铺起来。
第二个方向是概念图还原。Tripo Astra 支持参考图生成模型，你可以拿原画师的概念图去生成初版模型，导入 UE5 看空间关系。对于关卡前期验证，这个效率比手动建模快得多。
第三个方向是用 Codex 做资产管理脚本。它可以帮你写 Python 脚本，批量重命名下载的模型文件、转换格式、统一压缩纹理。我之前为了让几十个 AI 生成资产统一成一个命名规范，就是让 Codex 写了一个脚本，跑一遍全改好了。
最后再分享一个小技巧：AI 驱动原型开发时，任何一步都要养成“先提交再实验”的习惯。用一个 git 仓库管理 UE5 项目，每次让 Codex 改代码前先提交一次，生成资产导入前也拍个快照。这样不管 AI 生成了什么奇怪结果，你都能随时退回上一个状态，整个试错过程会轻松很多。
