AI 3D建模工具： Tripo 3D | Meshy AI

想给网页或 App 加一段 AI 生成的 3D 或 XR，第一个撞上的不是效果问题，是安全问题：运行期生成的代码是不可信代码。

Google 2026-11-03 开源了 Three-Live（Apache 2.0，v1.0.0 Developer Preview）来解决这段。有意思的是它自己的出身：整套代码由 Google Antigravity 写完，与一位"前工程师转产品经理"的人合作完成——官方特别注明，它不是 Google 的正式支持产品。

本文是那篇公告的完整编译，最后一节是我们的整理。

一、它把 Three.js 当成一种"场景描述语言"

关键设计决定只有一句：不让 Three.js 当"只在浏览器里跑的渲染循环"，而是把它的一个声明式子集当作可移植的场景描述格式。

这句话带来的后果是：同一段 LLM 写的脚本，可以在浏览器里跑，也可以在 Android / iOS / 命令行里编译成标准 3D 资产，然后交给各平台自己的渲染管线去画。

二、沙箱：先剥网络，再设几何上限

  • 网页端：不可信脚本跑在隔离的 Web Worker 里（可选再加一层不透明源 <iframe>），在用户代码执行第一行之前，fetch、XMLHttpRequest、WebSocket、动态 import() 这些网络原语已经被剥掉。
  • Android / iOS / macOS / 命令行：脚本跑在内嵌的 Rust 编译器里，引擎是 Boa（ECMAScript 引擎）。
  • 两套运行时都强制硬执行超时和几何配额——对顶点数、三角面数、网格数、程序化纹理都设上限，防止一段跑飞的脚本把宿主卡死。

这就是"AI 写的 3D 代码"和"AI 写的 3D 资产"之间那道门：代码可以跑，但跑不出去。

三、2–5 毫秒编成 GLB 和 USDZ

脚本在构建几何、PBR 材质、程序化 canvas 纹理、层级组、关键帧动画的同时，Three-Live 直接把场景图序列化成标准的二进制 glTF 2.0（.glb）和未压缩的 Apple USDZ（.usdz）内存字节流——官方给的典型耗时是 2 到 5 毫秒。

之后每个平台用它自带的图形管线渲染：

平台 交付形态 体积
Web 零依赖 WebGL2 PBR 渲染器 + <three-live> 自定义元素（参考 <model-viewer>），带程序化 Studio HDRI 反射、SSAO、bloom、阴影贴图，一键 AR 交给 Android Scene Viewer / Apple AR Quick Look / WebXR 约 45 KB gzip（含沙箱脚本与 AR）
Web（xr-live 套件） 空间计算套件 约 55 KB
Web（纯查看器） 只显示已有模型，去掉脚本编译器与 AR 约 23 KB
Android Kotlin SDK + 多架构 JNI（arm64-v8a / armeabi-v7a / x86_64），后台协程把 Three.js 字符串编成 ByteBuffer 资产，交给 Filament ModelViewer 与 Scene Viewer AR —
iOS / macOS Swift Package + 五切片 XCFramework，端上编译给 RealityKit ModelEntity 与 ARQuickLookPreviewController —

换成代码就一行：

<script src="https://cdn.jsdelivr.net/npm/three-live@1.0.0/dist/three-live.min.js"></script>
<three-live allow-client-scripts camera-controls ar shadow-intensity="1" environment-image="studio">
  <script type="text/three-live">
    const knot = new THREE.Mesh(
      new THREE.TorusKnotGeometry(0.6, 0.2, 128, 32),
      new THREE.MeshStandardMaterial({ color: 0x4285f4, metalness: 0.85, roughness: 0.15 })
    );
    scene.add(knot);
    scene.userData.animate = (t) => { knot.rotation.y = t * (Math.PI / 2); };
  </script>
</three-live>

注意 allow-client-scripts 这个显式开关：内联脚本是用户可改的，所以必须手动开启；服务端生成的脚本用 script-src 加载。

四、我们的整理

4.1 这套设计真正解决的是什么

程序化 3D 的老问题是"生成的东西不可信"，三种解法各有代价：

解法 代价
只让模型输出像素（图/视频） 没有可编辑几何，交互与空间关系全靠猜
只让模型输出 mesh（text-to-3D） 能看不能改；参数化、动画、层级全丢
让模型输出代码，再在沙箱里执行（Three-Live 这条路） 需要沙箱、配额、确定性序列化——这三样都要自己做对

第三条最像"程序化"，也最难：它要求把渲染引擎的声明面子集抽出来当接口。Three-Live 的贡献不是渲染，而是把这条接口固定下来并给出可移植的编译器。

4.2 三个可以直接抄的工程决定

  1. 执行前剥网络，而不是执行时拦网络——拦截总会漏，剥掉不会。
  2. 配额按"几何量"设，不按"代码行数"设：跑飞的 for 循环真正伤人的地方是三角面数。
  3. 输出标准二进制（GLB / USDZ）而不是自家场景格式：这样各平台用自己的管线渲染，手机端不用背一个 webview。

4.3 边界

  • 官方写明它是 Developer Preview，且不是 Google 正式支持产品；它对标的是更强的 XR Blocks，定位是"入门级配套"。
  • 它解决的是渲染与安全，不解决"AI 建的模型对不对"——拓扑、尺寸、物理属性都不在这套工具的职责里。
  • 45 KB 是启动体积，不等于你放进去的模型体积。

4.3 把三件事接到自己产品里的顺序

如果你的产品要"让用户/模型生成 3D 内容"，建议按这个顺序上：

  1. 先定输出格式（GLB + USDZ 双轨）：一旦定了自家场景格式，后边每个平台都要写一份渲染器；
  2. 再定沙箱策略：网页端 Web Worker（剥网络）+ 可选不透明源 iframe；原生端用可嵌入的 JS 引擎（Rust + Boa 是现成参考）；
  3. 最后定配额：顶点/三角面/网格/程序仪纹理四个上限，再配一个硬超时——顺序反了会一直在修"跑飞"。

4.4 三个容易踩的坑

  • 把 allow-client-scripts 当成默认开：内联脚本用户可改，官方要求必须显式开启；服务端生成的脚本走 script-src 加载。
  • 拿启动体积当性能指标：45 KB 是壳子，模型本身仍是你自己的纹理与几何，装不下就是装不下。
  • 以为"编成 GLB 就安全了"：沙箱管的是代码执行，GLB 的内容对不对（拓扑、尺寸、朝向）仍然要人工或程序验收。

五、先拿一段 GLB 看看结果

想直接看 Three-Live 产出的东西长什么样，把生成的 .glb 丢进 glTF Viewer 就能在浏览器里转、看材质与动画；需要看 STL / OBJ / FBX 就换 3D Viewer。没有模型可试的话，Text2STL 可以先给你一个能打开的实体。

同主题阅读

Sources