AI 3D 游戏制作工作流：从概念图、Tripo 资产到 Blender 与 Unity

本文依据 Sac 的 X 帖子及其指向的 X Article《手把手教你用 Opus 5.5 / Astra + Tripo 制作 3D 游戏》整理。原作者称其《小王子》主题的可探索 3D 游戏获得近 300 万浏览；这是作者自述，本文未独立核实。下文侧重归纳制作方法，不代表相同工具版本、模型能力或结果承诺。

把一个游戏想法做成可玩的 3D 场景，通常要跨过好几种工作：把故事变成需求、定视觉方向、制作模型、搭场景、给角色绑定骨骼、接入动画，最后还要在游戏引擎里反复检查。Sac 分享的流程展示了 AI 如何参与这些环节，让创作者能用自然语言驱动一部分 Blender 和 Unity 操作。

这类流程的关键不是让一个模型“包办游戏”，而是把任务分给合适的工具，再用参考图、截图和实际运行结果逐步验收。

先看完整流程

原文列出的工具组合包括 Fable 5.1、GPT Image 2.5、Tripo、Opus 5.5、Astra、Blender 和 Unity。文章标题强调 Opus 5.5 / Astra，但正文流程也把 Fable 5.1 用于 PRD。更稳妥的理解是按职责拆分，而不是把某个工具名称当成固定技术栈：

阶段	主要产物	AI 与工具可以承担的工作	人工需要确认的内容
需求规划	PRD、场景清单、角色设定、交互目标	整理剧情、核心玩法、场景和验收条件	游戏是否好玩、范围是否可实现
视觉探索	场景图、角色设定图、多视角参考	生成构图、风格、配色和角色视图	视觉一致性、比例和版权来源
资产制作	道具与角色 3D 模型	按参考图生成候选 3D 资产	网格、拓扑、比例、材质和授权
场景搭建	Blender 场景与 Unity 关卡	导入资产、按参考图布置、执行重复操作	尺度、层级、碰撞、光照和性能
角色动画	骨架、蒙皮、动作和交互	辅助绑定、动作接入与迭代修正	关节变形、接触关系和动画节奏
游戏验收	可运行关卡与交互	修复具体问题、重复执行检查	真实运行、输入响应、性能和可玩性

具体模型名称、功能和 CLI/MCP 接入方式可能随版本变化。原文提到的 Unity MCP、Blender CLI 等属于作者当时的配置描述，实施前应查看各工具当前的官方文档和授权要求。

一、先把想法变成可检查的需求

在生成模型和搭场景之前，先写一份简短 PRD，至少回答这些问题：

• 玩家扮演谁，要完成什么目标？
• 玩家会进入哪些场景，每个场景承担什么叙事或玩法功能？
• 需要哪些角色、道具和可交互物体？
• 哪些动作必须在第一版实现，哪些可以暂缓？
• 怎么判断第一版已经可玩？

例如，不要只写“做一个小王子的星际旅行游戏”，而应拆成可执行的描述：玩家从星球表面出发，能观察环境、移动到几个关键位置、与角色或道具互动，并在一个明确的目标处结束本轮体验。

可以让模型先整理结构，再由开发者确认：

请把这个游戏概念整理成一页 PRD，包含目标玩家、核心体验、场景列表、角色与道具、必要交互、第一版范围和验收条件。把不确定的内容单独列出，不要替我补成已经确定的事实。

好的 PRD 会限制首版范围。它还会为后续图片和模型生成提供统一的场景、角色和比例依据，减少每个资产单独生成后彼此不匹配的问题。

二、场景构建：先定画面，再拆资产

1. 用参考图固定构图和风格

先生成一张最能代表场景的主参考图，确认整体色彩、镜头、主要物体位置和空间层次。需要建模时，再补充俯视图、侧视图或室内外的不同角度。俯视图适合说明布局，斜侧视图可以帮助判断高度与遮挡关系。

场景参考提示词可以这样组织：

根据已确认的场景设定，生成一张统一风格的 3D 游戏场景参考图。包含整体环境、主要物体的位置关系、空间层次和材质方向；另外给出俯视布局与斜侧视角。保持场景中的建筑和道具在各视图里一致，不添加设定中没有的关键物体。

多视角图是建模参考，不是几何真值。AI 生成图中常会出现透视不一致、物体结构互相矛盾或细节在不同角度漂移，重要尺寸仍需在 Blender 或 Unity 里设定和测量。

2. 判断哪些物体值得单独生成

参考图确定后，把资产分为两类：

• 适合单独制作的标志性资产：主角、特殊道具、反复出现的物体，或需要较高造型细节的物件。
• 适合在 Blender/Unity 组合的基础元素：地面、简单墙体、平台、低细节装饰、重复模块和规则结构。

这种分类能让 3D 生成工具集中处理最能体现视觉特色的部分，同时避免为每一个简单几何体都增加生成、修模和导入成本。

可以让 AI 先列出候选项，再人工确认：

根据场景参考图和玩法需求，列出需要单独制作的 3D 资产，以及适合用基础几何体或模块化方式搭建的部分。逐项说明判断理由、尺寸关系、是否需要动画或碰撞，并标记需要我确认的事项。

原作者提到了使用 Tripo 生成道具，再将模型导出供后续场景搭建。不同生成模型对拓扑、细节和可编辑性的支持不一样，导入前应实际检查网格、比例、材质、面数、许可和后续编辑成本。

3. 在 Blender 与 Unity 中按镜头迭代

将已确认的场景参考图和独立 3D 资产放入项目后，先搭出空间和物体的大致关系，再逐项校正位置、大小、方向、光照与材质。不要只从一个视角检查：正面、侧面、斜侧和玩家实际移动视角都可能暴露问题。

给 AI 的任务应该能被检查，例如：

按照已确认的场景参考图，在 Blender 中搭建当前关卡的灰盒。先放置地面、主要建筑和关键道具，保持可编辑的对象层级，并输出正面、侧面和玩家视角截图。暂时不要添加未经确认的装饰。完成后列出与参考图无法确定的尺寸或结构。

这比“完美复刻”更适合实际协作：先让布局和尺度正确，再逐轮增加细节。截图反馈也应指向具体问题，例如“入口太窄”“道具遮挡了目标”“从玩家高度看不到星球边缘”，而不是只说“更有质感”。

三、角色建模：从一致的多视图到能动起来

1. 先固定角色外观

原文以小王子为例，建议先生成角色多视角参考，统一服装、发型、配色和身体比例，再把这些视图送入 3D 生成流程。角色设定图应包含正面、侧面和背面；若要做绑定，T-pose 或 A-pose 通常更便于检查肢体结构。

生成前先列出不能变化的特征，例如围巾颜色、发型轮廓、服装层次和身高比例。多视图中如果这些要素不一致，先修正参考图，不要期待后续绑定自动解决造型差异。

2. 检查网格与材质

3D 人物生成后，先看白模和网格结构，再决定是否生成纹理或局部重做。重点检查：

• 手指、耳朵、衣摆和关节是否连成合理结构；
• 网格是否适合动画变形，是否有明显破面或重叠；
• 面数是否符合目标设备和场景规模；
• 纹理是否与设定图一致，是否有接缝或错误颜色；
• 导出格式、单位和坐标轴是否符合 Blender/Unity 的导入设置。

漂亮的静帧不等于可用于实时游戏的模型。先用一个基础动作做变形检查，往往比在静止姿势里放大看材质更早发现问题。

3. 绑骨、接入动作，再修正特殊交互

原文描述的角色流程是：在 Blender 中用 Auto-Rig Pro 进行绑定和蒙皮，再从 Mixamo 选择适合的动作并适配到角色骨架。实际执行时，应先用抬手、弯腿、转身等简单动作检查骨骼位置、权重和关节变形。

如果角色要拿起水壶、握住工具或触碰按钮，现成动作往往只能提供大致动作。可以从一个接近的基础动画开始，再在 Blender 里调整手臂 IK、手掌朝向、手指姿势和道具位置。

交互验收提示词可写成：

基于当前角色骨架和参考动作，调整角色完成指定道具交互。逐帧检查手掌与道具的接触位置、动作开始和结束姿势、穿模与滑动。先报告发现的问题，再提出需要调整的骨骼控制器和关键帧；完成修改后输出正面与侧面预览供人工确认。

最终仍要在实际游戏中检查动作速度、碰撞、输入响应和相机距离。模型可以帮助修正动作，但不能替代开发者确认操作是否自然、清楚且可玩。

四、让 AI 操作 Blender/Unity 时设好工作边界

当模型可以通过 CLI、MCP 或其他自动化接口操作项目时，任务边界很重要。开始前先保存版本控制提交或项目副本；每次只交给它一个可验收的小任务，并要求说明修改文件、执行的操作和剩余问题。

建议采用这样的协作循环：

设定任务与验收条件
        ↓
AI 修改一个小范围
        ↓
运行场景并导出截图或日志
        ↓
人工按具体差异反馈
        ↓
再次修改并回归检查

对 Unity 项目，验收不应停留在“脚本生成成功”。至少要验证场景能打开、资源引用有效、玩家能完成关键交互、控制台没有新增错误，并在目标画面比例或设备上检查性能。对 Blender 文件，也要确认对象层级、材质、骨架和导出结果没有因自动化操作被意外破坏。

五、从文章里的案例能学到什么

1. 视觉参考越具体，返工越少

场景图、多视角和对象标注把“做得像一点”转化为可比较的目标。重点是让参考图支持判断比例、布局和接触关系，而不只是追求一张漂亮概念图。

2. 资产生成与场景组装应该分开

Tripo 这类工具适合生成候选独立资产；Blender 和 Unity 更适合组织对象、调整场景并验证运行效果。把两类任务混在一个指令里，会让问题难以定位。

3. AI 适合加快迭代，人仍要负责验收

模型能帮忙生成、导入、修改和排查，但资产是否可用、交互是否自然、项目是否能运行，都要回到真实文件和引擎中检查。视觉生成结果不能证明游戏机制或性能已经成立。

六、开始前的简短检查清单

项目准备

• 是否写清玩家目标、核心交互和第一版范围？
• 是否确认 Blender、Unity、插件和模型的当前版本与许可？
• 是否建立版本控制或可恢复的项目副本？

资产制作

• 是否有统一的场景和角色参考图？
• 是否区分独立生成资产与基础模块？
• 是否检查拓扑、比例、面数、材质和导入设置？
• 角色是否通过基础动作变形测试？

引擎验收

• 场景能否打开并运行？
• 关键资源引用、碰撞和输入是否正常？
• 玩家视角是否能看清场景目标？
• 特殊动作是否存在穿模、滑动或道具脱手？
• 是否检查控制台错误和目标设备性能？

来源与核验说明

• Sac 的 X 帖子，发布于 2026-10-15。
• X Article《手把手教你用 Opus 5.5 / Astra + Tripo 制作 3D 游戏》。公开正文包含 PRD、场景参考图、Tripo 资产、Blender/Unity 场景搭建、角色多视图、绑定和动作调整等描述。
• 原作者称项目获得近 300 万浏览，并表示之后会公开 GitHub 代码和更完整制作细节；这些说法未独立核实，本文不据此推断项目实际可复现程度。
• 原文含有 Tripo 邀请链接，本文不保留推广参数。工具版本、价格、功能、MCP/CLI 可用性和资产许可请以各工具当前文档及项目实际配置为准。