作为中国图学界最高级别的学术会议，本次大会邀请了多位国内外知名学者和产业界领军人才作学术报告，会议期间举办了各领域方向的学术论坛、专题研讨会等学术活动。

 

SUD（忽然科技）总经理：周正龙，作为受邀嘉宾，也围绕“AI智能3D与Web3D引擎”，分享了COCOS引擎智能生成的一些进展。

 

 

以下内容来自周正龙的现场演讲，为方便阅读，内容和顺序有所调整。

 

各位专家、教授，大家好。很高兴有机会和大家交流。今天我围绕 AI 智能 3D 与 Web3D 引擎，分享 COCOS 引擎中智能生成的一些探索。

 

在 AI 领域有一句话叫“压缩即智能”，这是理解大模型学习的一种思路。如果我们关注内容生成，会有一种相反的想法：从大模型里解压出我们想要的内容。

 

先给大家看一段演示。这是我们面向 AI 3D 生成的一款编辑器 PinK，用户可以通过编辑器与大模型对话，生成 3D 内容以及游戏。

 

 

这一年发展得非常快，这对我们引擎和游戏公司来说也是很大的挑战，我们需要尽可能利用大模型的能力，来做好 Web3D 内容的生成。

 

先简单介绍一下 COCOS，它是一款游戏引擎，可以跑在 Web 环境上，比如 Web 和小游戏；也可以跑在原生平台上，比如手机和移动端。特点是轻量化、跨平台、组件化，可以为生成内容提供运行的承载。

 

 

从上到下：上层是游戏内容，包括场景、预制件、资产，以及用户写的脚本；核心是渲染器、动画系统、物理系统和 UI 系统；底层适配了各个平台——Web、移动、桌面以及小游戏。

 

有了这些引擎能力，接下来我们关心的就是：内容该怎么表达，才能让人和AI都方便使用这些能力？

 

传统的内容生产，主要有四个问题：

 

一、很多配置要靠人工逐项完成。

 

二、场景、资源和脚本分散在不同文件里，缺少统一的描述。

 

三、AI很难直接理解和修改这些内容。

 

四、Runtime偏重，简单内容也可能带上用不到的模块。

 

所以，要让AI更深入地参与，我们得把内容表达得更清楚，把操作能力开放出来，同时让运行环境更轻。

 

在驱动内容生成方面，COCOS做了很多工作。首先是PinK，或者说利用 VS Code 做的编辑器，前端开发者可以在编辑器中发起对话或操作，它是整个工具链的人机交互入口。

 

其次我们开发了对应的 MCP，用户可以通过 MCP 对引擎或编辑器进行操作，生成具体的内容。

 

我们的核心是 CLI-CORE，一款开源的、基于 MIT 协议的命令行工具，负责解析命令以及调度所有的操作，向上承接 MCP 的请求，向下驱动编辑器和引擎各个模块协同工作。

 

最底层是我们的基石——COCOS引擎，最后的内容都运行在游戏引擎之上，可以跨到各个平台。

 

 

为了更好地利用 AI 来生成——目前 AI 大多用 JS 做 Web3D 内容，而COCOS引擎其实也可以做到这件事，因此我们做了一个双路径。

 

第一条，我们希望 AI 和人工能够对项目进行联合编辑。

 

在它之下，我们会把引擎做一些精简，依靠 AI 来完全生成所有的内容，这样会使整个生成以及迭代变得更为快速。

 

通过这两条路径，确实可以做到整个游戏由 AI 来生成。

 

我们确实提供了很多工具，比如 MCP、CLI，用户也可以提供他们的 skill 来帮助大模型生成内容。但其中有很多生成的难点。

 

首先，大模型不一定能够完全正确地生成对应的内容。

 

其次，对于一些项目，复杂度难以扩充。

 

第三，大模型有时很难理解用户给它的输入以及要求，不知道如何把明确的需求转化成对应的实现，它缺乏一个约束。

 

所以为了解决这些问题，COCOS也做了一些探索，我们会有一个生成器的框架 Generator，来辅助减少大模型的一些问题。

 

 

核心思路是从“压缩”过渡到“解压缩”。大模型学习的时候，一般是根据用户的内容以及经验，形成可以用于生成的规律；反过来做生成，我们走一个逆向的过程：给定比较少的输入，通过一个既定的规则展开。

 

也就是一个紧凑的描述加上一套领域规则，生成实际可以运行的结构以及操作。

 

相当于我们有一个固定的解压算法，只要给定一个输入，它的输出就是确定、可预测的。大模型只要知道这个解压缩的工具如何使用，就可以达到一个规模很大的数据生成效果。

 

基本的思路，是把整个领域知识放进生成的规则里面，通过简短的描述展开成具体可用的代码。

 

我们会编辑一个 .spec 文件，用它来定义各种各样的规则；然后分析这个文件，理清其中的语义模型以及类型与关系；最后进行代码生成，生成对应的数据结构以及操作，直接应用到引擎当中。

 

它的好处是：大模型生成出的代码量非常大，多数人难以理解。如果我们可以把它压缩成一个比较紧凑的表达，不仅大模型可以生成，人也容易理解。

 

 

其实之前在 COCOS 已经有一套领域用的生成工具。之前是用 C++ 实现的一个内置语言，描述了内部 RenderGraph、ResourceGraph、LayoutGraph 等数据结构。

 

新版为了更加 AI-Native，已经改成一个独立的 .spec 描述，会对应生成一个 workspace 以及项目。

 

这两者有共同的生成机制，它的输入、语义模型、最后的输出和工程文件都是可以转换的，但对大模型来说，新版理解起来会更容易。

 

随着新一代模型的出现，大模型对比较困难的问题的理解能力有着非常明显的上升。之前一些相对困难的问题，如今已经变得较为容易，正确率有很大的提升。

 

这里展示一个例子：用 .spec 文件描述一个 graph 的数据结构。它可能是一个双向图，基于 vertex list，每个顶点会有一些数据。大模型在定义完这个描述之后，我们的生成器就会生成对应的 TypeScript 代码，以及写出来的数据结构，同时也可以生成 C++ 的代码。

 

 

像这样一个graph的描述，其实有很强的描述能力。在游戏引擎当中，包含大量的数据结构都是由graph描述的，像RenderGraph、SceneGraph 以及 AnimationGraph。这些基础的数据结构，对应的代码都可以生成出来。

 

这样就可以减少大模型的上下文负担，生成速度也非常快，它省去了直接操作各种 C++ 代码或 TS 代码的要求，直接修改 .spec 文件就可以。

 

同时它也不会写错，因为生成器的规则是固定的，所以能够做到一次修改展开为成套的实现，并且约束与维护的规则也保持一致。

 

它的代码放大倍数很多，一行代码就可以放大到十几二十倍的代码量，整体上在性能以及上下文上还是很有优势。

 

 

我们也会共用一些领域里面的语义，生成数据结构、生成不同的语言，然后生成对应的算法以及业务规则。

 

这样一个语言，其实都是在领域内自己进行设计的，每个领域有它自己不同的理解。比如一位资深的架构师，可以把他自己的理解投入到对应的实现当中，让目标更可控。而整个编译测试、运行反馈，以及人工的代码审查与核查，都是比较容易的。

 

这是我们其中的三个例子。

 

 

第一个，可以描述 RenderGraph 的结构，其实包含里边的流程以及节点。

 

第二个，可以描述我们的资源管理，它有不同资源以及状态，有它的视图，以及它们如何被操作、它们前后读写的依赖关系。

 

第三个，对于我们编写的 shader 文件，也可以通过 LayoutGraph 来进行布局，比如哪个阶段用到哪些资源，都可以在事前做好。

 

像这样的一些复杂的数据结构，都可以用生成器来生成。这样大模型只需要知道上层的结构。

 

 

这张图大致总结了我们整体的流程。在生成阶段，通过人工以及大模型编写领域声明，可以生成不同的类型以及能力；生成器来进行语义展开，生成 graph 的类型以及别的一些领域内的 API，这些都是可调用的基础。

 

在运行阶段，用户可以根据具体的需求实时地构建一些 graph，比如 RenderGraph，来调度具体的关系，最后在引擎之上进行分析与执行。

 

这样的话，领域生成、运行时构图、渲染执行，各自会承担一个明确的目标。

 

我们下一代的 WebGPU 渲染器的数据基础，都是通过生成器来生成的：通过图来描述整个流程的依赖，然后来组织整个场景数据。

 

比如RenderGraph描述了整个的渲染流程以及资源依赖，SceneGraph会描述整个场景的数据组织结构。整个游戏当中的内容还是相当复杂的，它包含动画、场景，以及各类的逻辑，这些其实都可以用比较简单的描述文件来描述，作为算法的基础输入。

 

最后就可以达到右边的一些渲染效果。右边是一个Meshlet的数据组织示意，可以实现 GPU-Driven、可编程GI等一系列的能力，这些都是可以围绕一个明确的数据接口来实现的。

 

 

整个面向 AI 的渲染管线，同样也可以这样做。我们新的WebGPU管线也是通过大模型来构建，整套流程已经落在了COCOS引擎当中，可以直接要求大模型来进行渲染管线的编写。

 

这样有利于大模型来构建复杂的渲染效果，通过领域表达来承接用户的意图，再进行构建的检查以及运行时的反馈验证。

 

 

除了渲染流程之外，对于整个Web3D的场景内容，也可以用同样的机制来完成。因为我们对整个世界的表达比较关注，还需要考虑数据的复用、嵌套以及局部的差异。

 

可以通过定义一个Prefab的资产格式，或者 glTF 这样的格式，将它们进行组合，这样尽可能通过组合来还原一个比较复杂的物理世界，或者说虚拟世界。

 

这样一个描述语言，如果它是比较可描述的一种格式，大模型生成起来会相对容易一些。COCOS 4之前主要是通过CLI来进行直接的场景操作，并不能直接生成一个描述文件，在生成方面其实遇到了一些问题，我们之后都会改成这样的方法来实现。

 

通过对整个场景的分层表达，以及组合结果的缓存，之后可以做成一个比较复杂的游戏场景。这也是我们正在探索的一个方向以及目标。

 

总结一下，这样的一个生成器框架，是可以辅助大模型进行内容生成的。大模型可以比较清楚地理解它需要的知识，然后表达意图；生成器可以落实这些领域规则以及基础实现，这样可以大幅降低上下文的压力。

 

将领域知识融入到生成规则当中，它的行为是可以重放的，结果是稳定的，不会出现同一个要求、每次结果都不一样的问题，这样也比较利于进行检查或者单元测试。它的行为是明确可控的，生成边界以及验证责任是清晰的。

 

 

生成器承接的是固化的领域知识，它自己其实也是可以自举的——比如可以通过生成器来生成生成器。有了这样的一个流程，实际操作起来的效率非常高。

 

整体来说，我们就是让领域知识来参与生成，通过一个紧凑的表达，做到一个确定性的展开，做到大型项目的一个可持续的编辑。

 

谢谢大家。