Google发布Three-Live开发者预览：AI生成3D代码后，怎样让手机稳妥运行？

输入一句描述，AI生成一段3D场景代码，演示便能动起来。但如果要把这种能力交给网站访客或移动应用用户，开发者还要面对两个现实问题：生成的代码是否会失控，以及同一个场景怎样适配不同设备。

2026年11月3日，Google开源博客介绍了Three-Live v1.0.0开发者预览版。它采用Apache 2.0许可证，尝试把AI生成的Three.js场景描述转成可跨平台使用的3D资源。官方同时明确，Three-Live不是获得Google正式支持的产品。Google发布介绍

先把场景描述和执行环境分开

Three-Live使用Three.js接口的声明式子集描述场景，在受限制的环境中编译，再输出GLB、USDZ等资源供各平台渲染。它并非把任意Three.js应用原封不动搬到手机，也不意味着所有插件和脚本都能直接兼容。Google发布介绍

项目仓库说明，网页侧采用独立Worker或沙箱iframe，原生侧采用Rust与Boa运行环境，并对执行和几何资源设置限制。Three-Live官方仓库

可以把这条路线理解为“先生成受约束的场景，再交给显示端使用”。对开发者而言，关键价值是把生成过程与展示过程拆开管理，不必把模型输出直接放进拥有完整页面权限的执行环境。

为什么生成代码需要单独防护

如果一个应用允许访客输入描述，再直接执行模型生成的JavaScript，那么普通需求也可能产生异常代码。循环没有终止条件、几何对象数量失控，或不断分配纹理内存，都可能拖慢设备。恶意输入还会主动尝试利用执行环境提供的能力。

因此，编译成功、画面正确、安全可用，是三个不同的检查目标。沙箱可以缩小代码能够触及的范围，资源限制可以控制消耗，但都不能单独保证整个应用没有漏洞。用户上传的素材、外部链接、依赖版本，以及主应用开放的接口，也需要各自检查。

若应用还包含协作、联网或AI语音功能，应分别审查这些宿主能力的权限。不能因为生成场景的脚本受到限制，就推断整套产品从此不需要网络与隐私安全评估。

哪些场景值得先试

从产品设计角度看，参数明确、结构相对简单的场景更适合早期尝试。例如，教学中的几何体演示、商品尺寸与摆放预览、简单装配关系说明，或者一个可以旋转观察的交互原型。

这类任务便于设置验收标准：对象数量有限，尺寸范围明确，允许的交互可以列清楚。用户修改颜色或高度后，也容易检查是否只改变了指定参数。

如果项目依赖复杂美术资产、特定着色效果或大量现有Three.js扩展，应先验证支持范围。涉及工业测量或实际采购决策时，还要另行校准尺寸和展示误差，不能把视觉上“看起来合适”当成精确结果。

一个更容易落地的试点流程

第一步，选一个单一任务。比如做一件可调整宽高的展示柜原型，限制可用材料和几何类型，不从自由生成整个房间开始。

第二步，把需求写成结构化输入，明确单位、尺寸上下限、对象数量和允许交互。模型只生成这一范围内的场景描述。

第三步，在受控环境编译，检查输出大小、对象数量、错误信息和执行耗时。失败时返回明确提示，不把原始脚本切换到更宽松环境运行。

第四步，用目标浏览器和实际手机检查加载、交互与退出流程。设备不支持相应AR能力时，保留普通3D或静态图片回退，避免让关键业务页面失去可用性。

最后，保存通过验收的输入与输出版本。重复展示同一内容时，可以复用已验证资源；只有用户确实更改参数时，才重新生成和检查。这样既方便追踪，也能减少不必要的等待。

先把预览项目当作可验证的基础件

Three-Live的意义在于提供了一条清晰的工程路线：让AI负责产生场景描述，同时用运行环境和资源规则约束它。对于想试验生成式3D的小团队，这比单纯展示“模型能写3D代码”更接近可集成的能力。

但开发者预览仍需要团队自行承担兼容性测试、升级和维护。选用前应固定依赖版本，检查目标平台支持情况，并保留替换或退回预生成资源的方案。我们更看重的后续进展，是它能否持续提供可预测的错误处理和跨平台一致性，而不是某一个演示场景有多炫目。