大模型辅助搭建三维交互原型的实践教程

一、教程目标

本教程要帮助读者完成一件事：借助大模型，在较短时间内把一个文字需求转化为可以在浏览器中运行、可以交互、可以展示的三维原型。原型可以是一个简单的开放场景、一个可以展开和折叠的产品模型，或一段带有动态效果的展示画面。

完成本教程后，读者应当能够：

1. 把模糊的创意需求拆解成可验证的功能点；
2. 选择合适的技术路径，判断哪些部分交给模型生成，哪些部分需要人工把关；
3. 编写结构化提示词，并通过分阶段迭代得到可运行的代码；
4. 对生成结果做功能、性能和视觉层面的验证；
5. 记录用量，估算单个原型的调用成本。

本教程不讨论模型训练原理，也不涉及任何特定厂商的专有接口。文中涉及的模型调用、代码组织和部署方法均为通用做法，读者可以根据自己使用的模型服务替换具体接入方式。

二、适用读者与场景

适用读者

• 前端或全栈开发者：希望快速验证交互方案，减少从零搭建场景的时间。
• 产品与设计人员：需要把创意做成可点击、可旋转的演示稿，用于内部评审或方案提案。
• 技术负责人：需要评估大模型在原型开发中的实际效率与成本，为团队决策提供依据。
• 企业用户：计划将三维展示、产品预览或培训模拟纳入业务，需要先做小规模试点。

适用场景

• 产品外观预览：例如可折叠设备的展开与收起动画、按钮与屏幕内容的联动。
• 游戏或仿真原型：例如街道、车辆、角色的基础场景搭建，用于玩法验证。
• 宣传短片或演示动画：用网页三维画面生成短时长的动态展示。
• 数据可视化与三维交互看板：把数据映射到三维空间中，支持鼠标拖拽和点选。

不适用场景

本教程的方法不适合直接用于生产级游戏引擎开发、高精度工业仿真或需要严格物理一致性的工程计算。这类场景需要专业的工程流程和人工审核。

三、前置准备

1. 账号与额度

• 具备可调用大模型服务的账号，并确认该账号的调用额度、并发上限和有效期。
• 若在团队中使用，应为每位成员分配独立的密钥，便于追踪用量和回收权限。

2. 本地开发环境

• 一台可以运行现代浏览器的计算机，浏览器需支持WebGL标准接口，这是网页三维渲染的基础。
• 一个代码编辑器，用于编写和修改前端文件。
• 一个本地静态服务器或开发服务器。直接双击打开HTML文件时，部分资源加载会因浏览器安全策略失败，因此建议通过本地服务访问。
• 一套版本控制工具，用于保存每一轮迭代的版本，便于回退。

3. 三维素材与建模工具（按需）

• 若原型需要自定义模型，需要准备一款通用三维建模软件，或由大模型直接生成几何代码。
• 模型文件建议统一采用行业通用的交换格式，例如glTF，便于网页端加载。

4. 基础知识

• 了解HTML、CSS和基本的前端脚本语言。
• 理解三维场景的几个基本概念：场景、相机、光源、网格和材质。
• 了解异步请求的基本概念，因为模型调用通常是异步的。

5. 网络与安全

• 确保本地环境可以访问所选模型服务的接口地址。
• 密钥只能保存在环境变量或密钥管理服务中，不能写入前端源码或提交到代码仓库。

四、实施步骤

步骤1：拆解需求并定义验收标准

做什么：把原始需求拆成若干独立的功能点，并为每个功能点写出可以判断成功与否的条件。

为什么做：大模型对开放式描述的理解有较大空间，如果需求只写“做一个好看的三维场景”，生成结果很难稳定。明确的验收标准能让后续每一轮生成都有参照。

注意什么：

• 每个功能点只描述一件事，例如“车辆可以沿道路直线移动”，而不是“做一个完整的城市”。
• 验收标准要可以被观察或测量，例如“点击按钮后，手机在1秒内完成展开动画”，而不是“动画要自然”。

示例拆解：

功能点	验收标准
场景加载	页面打开后5秒内显示完整场景，无报错
角色移动	方向键控制角色移动，移动速度保持一致
相机跟随	角色移动时，相机始终保持在角色后方
帧率	在普通笔记本电脑上，画面帧率不低于30

步骤2：选择技术路径

做什么：根据目标选择实现路径。常见路径有三种。

• 路径一：纯网页三维。模型直接生成网页代码，在浏览器中用三维库渲染场景。适合交互原型和轻量展示。
• 路径二：建模加网页。先用建模工具或代码生成三维资产，导出为标准格式，再在网页中加载和控制。适合对模型外观要求较高的产品预览。
• 路径三：视频短片。由网页三维画面录制或截取动态片段，生成宣传视频。适合不需要实时交互的展示。

为什么做：三种路径的复杂度、可维护性和成本差异较大。先选对路径，能避免后期推倒重来。

注意什么：路径一的依赖较少，迭代最快，但对模型复杂度的上限较低。路径二的外观更可控，但资产导出和加载环节增加了失败点。

步骤3：编写结构化提示词

做什么：把功能点和验收标准转写为提示词。提示词建议包含以下五个部分：

1. 角色与目标：说明要生成的内容是什么。
2. 技术约束：说明使用的渲染方式、文件结构和依赖限制。
3. 功能清单：逐条列出功能点。
4. 输出格式：规定返回的代码应以什么结构呈现，例如单个HTML文件或多个模块文件。
5. 验收条件：列出步骤1中的验收标准。

为什么做：结构化提示词能减少模型自行补充的内容，降低生成结果偏离预期的概率。

注意什么：

• 不要在一次提示中要求模型完成全部功能，应分阶段进行。
• 技术约束要明确，例如“只使用浏览器内置接口和一个三维渲染库，不引入其他框架”，否则模型可能引入不必要的依赖。

步骤4：分阶段生成与增量迭代

做什么：按以下顺序推进。

1. 第一轮：只生成空场景，包括相机、光源和地面，确认渲染链路正常。
2. 第二轮：加入一个静态对象，例如立方体或简单车辆模型，确认对象显示和材质正确。
3. 第三轮：加入交互逻辑，例如鼠标点击或键盘控制。
4. 第四轮：加入动画，例如循环动画或状态切换动画。
5. 第五轮：整合和优化，处理资源加载、内存释放和界面布局。

为什么做：每一轮只引入少量改动，出现问题时能快速定位到具体环节。一次性生成的大段代码，往往会在多个位置同时出错，排查成本很高。

依赖关系：第二轮依赖第一轮的渲染链路正常；第四轮依赖第三轮中的状态管理。若前一轮未通过验证，不应进入下一轮。

步骤5：准备三维资产

做什么：若采用路径二，需要准备模型文件。可以使用三维建模工具手动制作，也可以让大模型生成建模脚本，再在建模工具中执行并导出。

为什么做：网页端直接加载模型文件，比在运行时生成复杂几何体更稳定，也便于复用。

注意什么：

• 模型面数应根据目标设备控制。移动端和低配设备上，面数过高会导致帧率下降。
• 贴图尺寸建议为2的幂次方，并压缩到合理大小，减少加载时间。
• 导出的文件要检查坐标轴方向和比例，避免加载后模型方向错误或尺寸异常。

依赖关系：资产导出完成后，才能在网页中加载。加载代码需要知道文件的访问路径，路径错误是常见的首次失败原因。

步骤6：搭建网页交互层

做什么：在网页中完成以下工作：

• 初始化渲染器、场景、相机和光源；
• 加载资产文件并添加到场景中；
• 绑定鼠标或键盘事件，把输入映射为对象状态的变化；
• 在循环中更新画面。

为什么做：交互层是原型可用性的关键。输入与状态之间的映射关系决定了操作是否直观。

注意什么：

• 事件处理函数应只修改状态，渲染逻辑统一放在动画循环中执行，避免事件与渲染相互干扰。
• 窗口尺寸变化时，需要同步更新相机比例和渲染器尺寸。

步骤7：动效与交互校验

做什么：逐条对照步骤1的验收标准，手动操作并记录结果。动效类功能需要关注起止状态、过渡时长和中间帧是否穿模。

为什么做：大模型生成的动画参数往往只是合理的估计，需要人工调整时间曲线和关键帧位置。

注意什么：折叠、展开、旋转等动作要检查是否存在部件重叠或穿插。若发现问题，应在提示词中明确指出具体部件和期望的运动方式，再进行下一轮修改。

步骤8：记录用量与成本

做什么：每次调用模型时，记录输入词元数、输出词元数、调用次数、耗时和对应费用。把每一轮迭代的记录整理成表格。

为什么做：没有用量记录，就无法判断哪一步最耗费资源，也无法在团队之间比较不同方案的成本。

注意什么：不同服务的计费单价和计费方式可能不同，应以所用服务的官方计费说明为准。

五、配置说明

1. 项目目录结构

建议采用以下结构，便于后续维护：

project/
├── index.html        页面入口
├── src/
│   ├── main.js       初始化与主循环
│   ├── scene.js      场景与光源配置
│   ├── controls.js   交互逻辑
│   └── assets.js     资源加载
├── assets/
│   ├── models/       三维模型文件
│   └── textures/     贴图文件
└── config/
    └── settings.json 运行参数

2. 运行参数

运行参数建议集中放在配置文件中，便于调整而不修改代码。常见参数包括：

• 目标帧率：用于判断性能是否达标，一般以30或60为常用取值；
• 渲染分辨率缩放比例：高分辨率设备可适当降低缩放比例以换取帧率；
• 阴影开关：阴影计算开销较大，低配设备可关闭；
• 资源路径前缀：便于在开发环境和生产环境之间切换资源地址。

3. 模型调用参数

多数大模型接口提供温度、最大输出长度等通用采样参数。这些参数的具体名称和取值范围应以所用接口文档为准。一般经验如下：

• 代码生成任务通常需要较低的随机性，以保证输出稳定；
• 创意类任务可以适当提高随机性，获取更多方案；
• 最大输出长度应足够容纳完整代码，过小会导致代码被截断。

4. 密钥配置

密钥应通过环境变量读取，例如在启动服务前设置MODEL_API_KEY。前端页面不应直接调用需要密钥的接口，建议通过后端代理转发请求。

配置风险：

• 密钥泄露会导致额度被盗用，需要定期轮换；
• 输出长度设置过大会增加费用；
• 资源路径写错会导致模型加载失败，但页面不一定报错，需要通过控制台日志确认。

六、示例说明

以下为通用流程示意，不依赖任何特定服务的接口名称，读者可按自己使用的接入方式替换。

调用模型生成代码的流程（伪代码）

function 生成原型(需求列表, 验收标准):
    阶段列表 = 按依赖关系拆分(需求列表)
    当前代码 = 空
    用量记录 = []
    for 阶段 in 阶段列表:
        提示词 = 组装提示词(阶段, 当前代码, 验收标准)
        响应 = 调用模型(提示词)
        用量记录.append(读取用量(响应))
        新代码 = 解析代码(响应)
        if 不能通过本地校验(新代码):
            记录错误并重试或人工介入
            continue
        运行结果 = 在浏览器中运行并采集日志(新代码)
        if 运行结果 未通过验收:
            修改提示词并回到循环
        else:
            当前代码 = 新代码
            保存版本(当前代码)
    return 当前代码, 用量记录

网页端的基本结构（伪代码）

初始化():
    渲染器 = 创建渲染器(画布)
    场景 = 创建场景()
    相机 = 创建透视相机(视角, 宽高比, 近裁剪面, 远裁剪面)
    添加光源(场景)
    加载资产(场景, 资源路径)
    绑定事件(输入处理函数)
主循环():
    每帧:
        根据输入更新对象状态
        渲染器.渲染(场景, 相机)
        请求下一帧(主循环)
窗口尺寸变化():
    相机.宽高比 = 新宽度 / 新高度
    渲染器.设置尺寸(新宽度, 新高度)

关键点说明：状态更新和渲染分离，是保证交互响应和画面稳定的基本结构。

七、结果验证

验证应从以下四个层面进行。

1. 功能验证

逐条对照步骤1的验收标准，记录通过或未通过的结果。每条标准应有对应的操作步骤和观察结果。

**2. 控制台验证