★ FEATURED ARTICLE 一张静态图片几秒钟之后变成一个有层次、有光影、能转能缩放的 3D 场景而且生成过程不是黑盒吐一个模型文件而是直接产出一段可读、可改、可版本管理的 Three.js 代码。这就是 img2threejs 这个项目最抓人的地方目前在 GitHub 上已经拿到 8.7k Star。它做的事情本质上是把图生 3D这件事从生成资产变成了生成代码流水线——输入一张图中间经过视觉理解、结构拆解、代码编排最后输出一个能直接跑在浏览器里的 Three.js 工程。我第一眼看到这个思路的时候是有点兴奋的因为它绕开了传统 3D 生成里最麻烦的一环模型格式转换和渲染管线适配。传统做法是图生 meshmesh 再导出 glTF/OBJ再塞进 Three.js 加载中间任何一步出问题都得从头查。而 img2threejs 直接把终点定在代码层模型是代码描述出来的改起来就是改几行 JS/TS这对前端和 Agent 开发者来说友好太多了。下面我就按自己的理解把这个项目的技术拆解、流水线设计、实操要点和踩坑经验完整讲一遍适合做 Three.js 的、做 AI Agent 的、以及想搞懂图生 3D 到底怎么落地的读者。1. 为什么图生代码比图生模型更适合 Web 3D1.1 传统图生 3D 的资产链路有多重先把这个行业的常规路径捋清楚。你给一张图想要在网页里看到一个 3D 效果标准链路大概是图像 → 深度估计/多视角重建 → 点云或网格 → 网格简化与 UV 展开 → 导出 glTF → Three.js 加载 → 材质与光照调优。这条链路上每一步都有独立的工具和参数深度估计用 MiDaS 或 Depth Anything重建用 NeRF 或 Gaussian Splatting网格化用 Marching Cubes简化用 Quadric Edge Collapse导出还得处理坐标系Y-up 还是 Z-up、单位缩放、贴图打包。问题在于这条链路里任何一环的误差都会累积。深度图边缘不准重建出来的模型就糊网格简化太狠细节就丢UV 展开不好贴图就拉伸。更麻烦的是最终产物是一个二进制资产你没法用 Git 做有意义的 diff改一个颜色可能要重新跑整条链路。对于 Web 场景来说模型文件体积还直接决定加载速度一个高精度 mesh 动辄几十 MB移动端直接劝退。1.2 代码作为 3D 的中间表示优势在哪img2threejs 的核心判断是与其生成一个不可读的资产不如生成一段可读的代码。Three.js 本身就是用代码描述场景的——几何体用BoxGeometry、SphereGeometry材质用MeshStandardMaterial光照用DirectionalLight、AmbientLight相机用PerspectiveCamera。这些 API 天然就是3D 场景的声明式描述。把代码当中间表示带来几个直接好处。第一可解释你打开生成的.ts文件能一眼看出这个场景由哪些几何体组成、用了什么材质、光源在哪而不是面对一个黑盒 mesh。第二可编辑想换个颜色、调个位置、加个动画直接改代码不需要重新生成。第三体积小一段描述场景的代码通常几 KB 到几十 KB比动辄几十 MB 的 mesh 小两三个数量级加载速度完全不是一个量级。第四可版本管理代码能 diff、能 review、能回滚这对团队协作是刚需。提示代码作为中间表示并不是万能的。对于高度有机的形体比如人脸、雕塑、复杂生物纯代码几何体很难还原细节这时候还是得回到 mesh 路线。img2threejs 更适合结构化、几何感强的场景比如建筑、产品、图标、低多边形风格。1.3 8.7k Star 背后反映的真实需求这个项目能拿到 8.7k Star我觉得不是偶然。它踩中了几个正在爆发的需求交叉点。一是AI Agent 的落地场景Agent 需要一个能产出可执行结果的任务图生 3D 代码正好是一个从感知到行动的完整闭环很适合做 Agent 的能力演示。二是Three.js 生态的成熟Three.js 已经是 Web 3D 事实标准围绕它的工具链、教程、社区都非常完善生成 Three.js 代码等于直接接入了一个巨大的生态。三是低门槛 3D 创作大量设计师、产品经理、运营同学想做 3D 效果但不会建模图生代码让他们用一张图就能起步。从热搜词也能看出来three.js、typescript、agent、3d网页渲染、ai agent这些词高频出现说明关注这个项目的人群正好是前端 AI 的交叉群体。他们不缺 Three.js 基础缺的是怎么把 AI 和 3D 串起来的工程范式而 img2threejs 给的正是这个范式。2. img2threejs 的流水线拆解从像素到可运行代码2.1 第一段图像理解与场景语义解析流水线的起点是图像理解。这一步的目标不是识别图里有什么物体这么简单而是要提取出可用于 3D 重建的结构化信息。具体来说需要拿到几类信息物体的类别与数量、每个物体的大致边界框、物体的空间层次关系谁在前谁在后、谁遮挡谁、主色调与材质倾向金属、木质、塑料、玻璃、以及整体的透视关系是正视、俯视还是斜视。这一步通常用多模态大模型来做把图片喂进去让它输出结构化的 JSON 描述。比如一张桌子的照片模型需要输出一张矩形桌面 四条圆柱桌腿 木质材质 暖色调 正视角度这样的语义。这里的关键是提示词设计要让模型输出机器可解析的字段而不是一段散文。实践中一般会约束输出格式比如要求返回包含objects、materials、camera、lighting字段的 JSON。我实测下来这一步最容易出问题的地方是空间关系判断。模型经常把前后关系搞反或者把遮挡关系描述错。一个缓解办法是让模型同时输出每个物体的深度排序depth order并在提示词里明确要求按从远到近的顺序列出物体。另一个坑是数量误判比如四条桌腿可能只识别出两条这时候可以在提示词里加一句仔细数清楚重复出现的结构件数量。2.2 第二段几何体映射与参数化拿到语义描述之后下一步是把语义映射成 Three.js 的几何体。这一步是 img2threejs 最核心的翻译环节。映射规则大致是这样的规则形状盒子、球、圆柱、圆锥、平面直接对应 Three.js 的内置几何体不规则形状则用组合几何体近似或者用ExtrudeGeometry、LatheGeometry这类参数化几何体来构造。这里有个很重要的设计取舍用内置几何体组合还是用参数化几何体内置几何体Box、Sphere、Cylinder性能好、代码简单但表现力有限参数化几何体Extrude、Lathe、Shape表现力强但代码复杂、容易出错。img2threejs 的常见做法是优先用内置几何体只有在内置几何体明显无法表达时才降级到参数化几何体。这个取舍的逻辑是生成代码的可读性和稳定性优先于几何精度因为用户拿到代码后大概率会手动微调一个简单可读的代码比一个复杂精确的代码更有价值。参数化这一步还需要处理尺寸与比例。图片是 2D 的没有绝对尺度所以需要建立一个相对坐标系。常见做法是设定一个基准尺寸比如场景整体宽度为 10 个单位然后按图片中的像素比例推算各物体的相对尺寸。这里要注意透视畸变如果图片是斜视角度直接按像素比例算尺寸会失真需要先做一次透视校正或者让模型直接输出估计的真实比例而不是像素比例。2.3 第三段材质、光照与相机配置生成几何体只是骨架材质和光照才是让场景活起来的部分。材质生成的关键是从图片中提取颜色和质感信息。颜色相对好办取区域主色即可质感则需要模型判断比如高光强的是金属或塑料漫反射均匀的是木质或布料半透明的是玻璃。Three.js 里对应的就是MeshStandardMaterial的metalness、roughness、transparent、opacity这几个参数。光照配置是很多人容易忽略但影响巨大的一环。一张图里的光照信息包括主光源方向、光源色温、环境光强度、是否有阴影。img2threejs 一般会生成一个三点光照的基础配置——一个主光DirectionalLight、一个补光DirectionalLight 或 HemisphereLight、一个环境光AmbientLight然后根据图片的明暗分布调整各光源的强度和方向。相机配置则根据图片的透视关系推断正视用较小的 FOV广角用较大的 FOV俯视则调整相机位置和朝向。注意材质参数不要一次调太满。我见过很多生成结果把metalness直接拉到 1结果场景一片死黑因为金属材质在没有环境贴图的情况下几乎不反射环境光。稳妥的做法是金属度控制在 0.3 到 0.7 之间配合一张环境贴图可以用RoomEnvironment生成来提供反射。2.4 第四段代码编排与工程化输出最后一段是把前面所有信息组装成可运行的 Three.js 工程。这一步的产物通常包括一个场景初始化文件创建 scene、camera、renderer、一个物体定义文件每个物体的几何体 材质 位置、一个光照配置文件、以及一个入口文件组装并启动渲染循环。如果项目用 TypeScript还会生成对应的类型定义。工程化输出这块有几个细节值得说。一是模块划分好的生成结果会把场景拆成多个模块而不是把所有代码堆在一个文件里这样便于维护。二是参数外置把可调参数颜色、尺寸、位置抽成常量或配置对象方便用户快速调整。三是渲染循环与响应式生成requestAnimationFrame循环和resize监听保证场景在不同屏幕尺寸下正常显示。四是资源清理在组件卸载时释放几何体和材质避免内存泄漏这在 React/Vue 项目里尤其重要。3. 把 img2threejs 跑起来环境、依赖与最小可运行示例3.1 环境准备里最容易被忽略的三件事第一件事是Node 版本。Three.js 生态和现代构建工具对 Node 版本有要求建议用 Node 18 LTS 或更高。低版本 Node 在装某些依赖时会报engine不匹配或者遇到 ESM/CJS 混用的问题。第二件事是包管理器选择。npm、pnpm、yarn 都能用但如果你要复现别人的项目最好跟对方保持一致因为 lock 文件不同可能导致依赖树差异。第三件事是TypeScript 配置。如果项目是 TS 写的tsconfig.json里的moduleResolution建议设为bundler或node16否则 Three.js 的类型声明可能解析不到。# 推荐的环境准备流程 node -v # 确认 18 npm create vitelatest my-img2threejs -- --template react-ts cd my-img2threejs npm install three npm install -D types/three3.2 一个最小可运行的 Three.js 场景骨架在接入 img2threejs 的生成结果之前先手写一个最小场景把渲染管线跑通这样后面出问题好定位。下面这段代码创建了一个带光照的旋转立方体是所有 Three.js 项目的Hello World。import * as THREE from three; const scene new THREE.Scene(); scene.background new THREE.Color(0x1a1a1a); const camera new THREE.PerspectiveCamera( 50, window.innerWidth / window.innerHeight, 0.1, 1000 ); camera.position.set(4, 3, 6); camera.lookAt(0, 0, 0); const renderer new THREE.WebGLRenderer({ antialias: true }); renderer.setSize(window.innerWidth, window.innerHeight); renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)); document.body.appendChild(renderer.domElement); // 光照环境光 主方向光 scene.add(new THREE.AmbientLight(0xffffff, 0.6)); const dirLight new THREE.DirectionalLight(0xffffff, 1.2); dirLight.position.set(5, 8, 6); scene.add(dirLight); // 物体 const geometry new THREE.BoxGeometry(1.5, 1.5, 1.5); const material new THREE.MeshStandardMaterial({ color: 0x4f9dff, metalness: 0.4, roughness: 0.35, }); const cube new THREE.Mesh(geometry, material); scene.add(cube); // 渲染循环 function animate() { requestAnimationFrame(animate); cube.rotation.y 0.01; renderer.render(scene, camera); } animate(); // 响应式 window.addEventListener(resize, () { camera.aspect window.innerWidth / window.innerHeight; camera.updateProjectionMatrix(); renderer.setSize(window.innerWidth, window.innerHeight); });这段代码跑通之后你就有了一个容器。img2threejs 生成的结果本质上就是把上面这段里的geometry、material、light部分替换成从图片解析出来的内容。理解这一点后面看生成代码就不会懵。3.3 接入生成结果时的目录组织建议生成结果不要直接往App.tsx里塞。建议按下面的结构组织这样后续维护和替换都方便src/ scene/ SceneRoot.ts // 场景初始化与渲染循环 objects/ Table.ts // 单个物体的定义 Chair.ts materials/ palette.ts // 统一色板与材质参数 lighting/ setup.ts // 光照配置 assets/ textures/ // 贴图资源把每个物体拆成独立文件的好处是改一个物体不影响其他物体也方便做懒加载。材质参数集中到palette.ts里改配色只需要动一个文件。光照单独抽出来是因为光照调整往往需要反复试独立文件便于快速迭代。4. 生成质量调优让能跑变成好看4.1 几何体比例失真的三种典型表现与修正生成结果最常见的毛病就是比例不对。第一种是整体过大或过小导致相机要么穿模要么看不清。修正方法是给场景加一个自动适配逻辑计算所有物体的包围盒Box3然后根据包围盒尺寸自动调整相机距离。第二种是物体之间比例失调比如桌腿比桌面还粗。这通常是语义解析阶段尺寸估计不准导致的修正方法是引入参考物概念——在提示词里让模型以某个已知物体为基准推算其他物体尺寸。第三种是位置错位物体之间该接触的没接触、该对齐的没对齐。修正方法是生成后做一次吸附对齐把相邻物体的边界对齐到同一平面。// 自动适配相机距离 const box new THREE.Box3().setFromObject(scene); const size box.getSize(new THREE.Vector3()); const center box.getCenter(new THREE.Vector3()); const maxDim Math.max(size.x, size.y, size.z); const fitDistance maxDim / (2 * Math.tan((camera.fov * Math.PI) / 360)); camera.position.copy(center).add(new THREE.Vector3(1, 0.8, 1).normalize().multiplyScalar(fitDistance * 1.6)); camera.lookAt(center);4.2 材质塑料感太重怎么破生成结果另一个高频问题是所有东西看起来都像塑料。根因是材质参数太单一roughness和metalness没有区分度。破解思路是按材质类别设置参数区间而不是所有物体用同一套参数。下面这张表是我实测下来比较稳的参数区间可以直接抄。材质类型metalnessroughness备注木质0.0 - 0.10.6 - 0.8可加轻微法线贴图增强纹理金属0.7 - 0.950.2 - 0.4必须配环境贴图否则发黑塑料0.0 - 0.10.3 - 0.5高光偏锐利玻璃0.00.05 - 0.15配合 transparent opacity布料0.00.85 - 1.0几乎无高光陶瓷0.0 - 0.10.2 - 0.4高光柔和除了参数环境贴图是提升质感的关键。没有环境贴图金属和玻璃就是死板的纯色。Three.js 提供了RoomEnvironment可以程序化生成一张环境贴图不需要外部 HDR 文件非常适合生成场景。import { RoomEnvironment } from three/examples/jsm/environments/RoomEnvironment.js; const pmrem new THREE.PMREMGenerator(renderer); scene.environment pmrem.fromScene(new RoomEnvironment(), 0.04).texture;4.3 光照太平、没有立体感的调整思路如果生成结果看起来扁扁的问题基本出在光照。三点光照是基础但很多人只加了环境光和一个方向光导致阴影缺失、明暗对比不足。我的调整顺序是先把环境光压到 0.3 到 0.5让暗部有层次但不死黑然后主光强度拉到 1.0 到 1.5方向从侧上方打制造明暗交界再加一个补光从另一侧以 0.3 到 0.5 的强度填充暗部最后开启阴影让物体在地面或彼此之间投下阴影立体感立刻就出来了。renderer.shadowMap.enabled true; renderer.shadowMap.type THREE.PCFSoftShadowMap; const keyLight new THREE.DirectionalLight(0xffffff, 1.3); keyLight.position.set(6, 10, 6); keyLight.castShadow true; keyLight.shadow.mapSize.set(2048, 2048); keyLight.shadow.camera.near 0.5; keyLight.shadow.camera.far 50; scene.add(keyLight); const fillLight new THREE.DirectionalLight(0xbfd4ff, 0.4); fillLight.position.set(-6, 4, -4); scene.add(fillLight);提示阴影贴图分辨率不是越高越好。2048 已经能满足大多数场景4096 会明显增加 GPU 开销移动端可能掉帧。如果场景很大优先调整shadow.camera的near/far和范围而不是一味提高分辨率。4.4 性能优化从 60 帧掉到 20 帧的排查路径生成场景跑起来之后如果帧率不理想按下面的顺序排查。第一步看几何体数量如果场景里有几百个独立 meshdraw call 会爆掉解决办法是用InstancedMesh合并重复物体或者用BufferGeometryUtils.mergeGeometries合并静态几何体。第二步看材质数量每个不同材质都是一次 draw call能复用就复用。第三步看阴影阴影是性能大户如果场景不需要阴影就关掉需要的话限制阴影相机范围。第四步看像素比setPixelRatio不要超过 2高分屏上 3 倍像素比会让渲染量翻倍还多。第五步看贴图尺寸贴图不要超过 2048能压缩就压缩。import { mergeGeometries } from three/examples/jsm/utils/BufferGeometryUtils.js; // 合并多个静态几何体减少 draw call const geometries meshes.map((m) m.geometry.clone().applyMatrix4(m.matrix)); const merged mergeGeometries(geometries); const mergedMesh new THREE.Mesh(merged, sharedMaterial); scene.add(mergedMesh);5. 把 img2threejs 接进 Agent从单次生成到自动化流水线5.1 为什么这个项目天然适合 Agent 架构img2threejs 的流水线本身就是多步骤、有中间产物、每步可校验的结构这正好是 Agent 擅长的场景。一个典型的 Agent 化改造是把图像理解、几何映射、材质生成、代码编排拆成四个工具tool由一个 Agent 负责调度。Agent 拿到图片后先调用图像理解工具拿到语义 JSON再调用几何映射工具拿到几何描述然后调用材质工具最后调用代码生成工具产出文件。每一步的中间产物都可以被 Agent 检查发现问题可以回退重试。这种架构的好处是可观测、可干预。传统端到端模型是黑盒出问题只能整体重跑Agent 化之后你能看到每一步的输出哪一步不对就修哪一步。比如图像理解把桌腿数量搞错了你只需要重跑这一步不用重新生成整个场景。5.2 工具函数的接口设计要点把每一步封装成工具时接口设计要遵循输入输出都是结构化数据的原则。图像理解工具的输入是图片 URL 或 base64输出是固定 schema 的 JSON几何映射工具的输入是语义 JSON输出是几何描述数组代码生成工具的输入是几何描述 材质描述输出是文件内容字符串。每个工具都应该是幂等的同样的输入给同样的输出这样便于缓存和重试。interface SceneSemantic { objects: Array{ id: string; category: string; bbox: [number, number, number, number]; depthOrder: number; materialHint: string; colorHint: string; }; camera: { angle: string; fov: number }; lighting: { direction: string; warmth: string }; } async function analyzeImage(imageUrl: string): PromiseSceneSemantic { // 调用多模态模型返回结构化语义 // 关键约束输出 schema失败时重试 }5.3 并发与重试Agent 跑批量任务时的坑如果你要用 Agent 批量处理图片并发控制是必须的。多模态模型的调用通常有速率限制无脑并发会触发限流。稳妥的做法是用一个并发池限制同时进行的请求数比如 3 到 5 个失败的请求进入重试队列重试时加指数退避。另外中间产物要落盘缓存同一张图重复处理时直接读缓存既省钱又快。还有一个容易被忽略的点是超时处理。图像理解这一步可能因为图片太大或模型响应慢而超时如果不设超时整个流水线会卡死。建议给每个工具调用设一个合理的超时比如 30 秒超时后走降级逻辑比如用更简单的提示词重试或者返回一个基础场景。6. 实操中踩过的坑与对应解法6.1 贴图不显示从加载路径到色彩空间Three.js 贴图不显示是新手高频问题我自己也踩过。排查顺序是这样的先看路径对不对浏览器控制台如果有 404那就是路径问题注意 Vite 项目里静态资源要放public目录或用import引入。再看加载时机贴图是异步加载的如果在加载完成前就渲染会显示成默认色解决办法是用TextureLoader的onLoad回调或者用LoadingManager统一管理。最后看色彩空间颜色贴图要设texture.colorSpace THREE.SRGBColorSpace否则颜色会发灰。const loader new THREE.TextureLoader(); const texture loader.load(/textures/wood.jpg, (tex) { tex.colorSpace THREE.SRGBColorSpace; tex.wrapS tex.wrapT THREE.RepeatWrapping; tex.repeat.set(2, 2); material.map tex; material.needsUpdate true; });6.2 生成代码里的类型报错怎么快速定位TypeScript 项目里生成代码经常有类型报错。最常见的几类Object3D和Mesh的类型不匹配scene.add接受Object3D但访问.material需要断言成MeshVector3的set参数数量不对Material的联合类型没收敛。快速定位的办法是看报错行号然后对照 Three.js 的类型定义。如果生成代码里大量用了any建议手动补类型因为any会掩盖真正的错误。注意不要为了消错而到处加as any。类型报错往往暴露的是真实的逻辑问题比如把一个Group当成Mesh用。花几分钟补对类型比后面运行时崩溃再回来查要划算得多。6.3 场景加载慢、首屏白屏的优化组合拳首屏白屏通常是因为场景初始化阻塞了主线程或者资源太大。优化组合拳是代码分割把 3D 场景做成懒加载组件首屏先渲染占位内容资源预加载用LoadingManager显示加载进度几何体简化生成阶段就控制几何体复杂度不要生成几十万面的球体贴图压缩用 WebP 替代 PNG/JPG体积能小一半以上渐进式渲染先渲染低精度版本再逐步替换成高精度。const manager new THREE.LoadingManager(); manager.onProgress (url, loaded, total) { console.log(加载进度: ${loaded}/${total}); }; manager.onLoad () { // 全部资源加载完成隐藏 loading };6.4 移动端适配触摸交互与性能降级移动端和桌面端差异很大。交互上桌面用OrbitControls的鼠标拖拽移动端要支持单指旋转、双指缩放OrbitControls本身支持触摸但要注意touch-action的 CSS 设置否则会和页面滚动冲突。性能上移动端 GPU 弱需要降级像素比限制到 1.5阴影贴图降到 1024 或直接关阴影几何体面数减半关闭抗锯齿或改用 FXAA。检测方式可以用navigator.hardwareConcurrency或简单的 UA 判断但更稳的是做一次性能探测根据首帧耗时动态调整。const isMobile /Mobi|Android/i.test(navigator.userAgent); renderer.setPixelRatio(isMobile ? Math.min(window.devicePixelRatio, 1.5) : Math.min(window.devicePixelRatio, 2)); if (isMobile) { renderer.shadowMap.enabled false; }7. 这套流水线还能往哪些方向延展7.1 从单图到多图多视角融合提升精度单张图的信息量有限尤其是深度信息。如果能提供同一物体的多张不同角度图片图像理解阶段就能做多视角融合几何估计会准很多。实现思路是让模型分别解析每张图然后做一次视角对齐把不同视角下的物体描述合并成一个统一的三维描述。这一步的难点在于视角对齐需要估计每张图的相机位姿或者让模型直接输出相对视角关系。7.2 加动画让生成的场景动起来静态场景只是起点加上动画才是会动的 3D。Three.js 的动画系统支持关键帧动画AnimationClipAnimationMixer和程序化动画在渲染循环里改属性。对于生成场景程序化动画更容易自动生成比如让物体缓慢旋转、让光源做周期性移动、让相机做环绕运动。这些都可以在代码生成阶段作为动画配置注入。const clock new THREE.Clock(); function animate() { requestAnimationFrame(animate); const t clock.getElapsedTime(); // 相机环绕 camera.position.x Math.sin(t * 0.3) * 8; camera.position.z Math.cos(t * 0.3) * 8; camera.lookAt(0, 0, 0); renderer.render(scene, camera); }7.3 与设计工具打通从 Figma 到 3D 场景一个很自然的延展是把输入从图片扩展到设计稿。Figma 里的图层结构本身就带有语义信息图层名、分组、层级比纯图片更容易解析。如果能读取 Figma 的图层树几何映射的准确率会大幅提升因为图层边界框直接就是物体的位置和尺寸。这条路线的工程价值很高适合做设计工具插件的团队。7.4 生成结果的可编辑性可视化编辑器生成代码之后如果用户不会写代码还是没法改。一个自然的延展是配一个可视化编辑器把生成的场景参数位置、旋转、缩放、颜色、材质暴露成 UI 控件用户拖拖拽拽就能调整调整结果实时反映到代码里。这本质上是把代码作为中间表示的优势进一步放大——因为场景是代码描述的所以任何参数都能被程序化修改。8. 我个人的几点实操体会做这类图生 3D 代码的项目我最大的体会是不要追求一步到位。生成结果第一版大概率是歪的、丑的、比例不对的这很正常。正确的做法是先把流水线跑通拿到一个能看的结果然后针对最影响观感的问题逐个优化。我通常的优化顺序是先修比例和位置影响最大再修材质和光照影响质感最后修细节和动画锦上添花。第二个体会是中间产物一定要可视化。图像理解输出的 JSON、几何映射输出的参数都应该能直观看到。我习惯在开发阶段把这些中间结果打印到页面上或者存成 JSON 文件这样出问题的时候能快速定位是哪一步的锅。纯黑盒调试的效率太低了。第三个体会是提示词的稳定性比提示词的聪明更重要。很多人喜欢把提示词写得很复杂很花哨但实际跑起来输出格式经常飘。我的经验是提示词要短、要明确、要带输出格式约束宁可让模型少做点推理也要保证输出能被程序稳定解析。格式飘了后面全白搭。最后一个体会是性能要一开始就考虑。生成场景很容易越加越多几何体、光源、贴图一路堆上去等到发现卡了再优化改动成本很高。我的做法是定一个性能预算比如 draw call 不超过 100、总面数不超过 50 万、贴图总大小不超过 5MB生成阶段就按这个预算控制超了就简化。这套流水线的价值不在于生成得多完美而在于它把 3D 创作的门槛降到了有一张图就行同时保留了代码的可编辑性。对于做 Web 3D 和 AI Agent 的人来说这是一个非常值得研究的工程范式里面的每一步拆解、每一个取舍都能迁移到其他AI 生成可执行产物的场景里。
阅读完成 · 觉得有帮助？
