COCOS引擎智能生成探索：用解压算法让大模型精准产出Web3D内容

会议背景

2026年10月15日至19日，第十一届中国图学大会（China Graphics'2026）在福建厦门召开，主题为“智绘空间·图领未来”。作为中国图学界最高级别的学术会议，本次大会邀请了多位国内外知名学者与产业界领军人物作学术报告，同期举办了各领域的学术论坛与专题研讨会。

SUD（忽然科技）总经理周正龙博士受邀参会，围绕“AI智能3D与Web3D引擎”分享了COCOS引擎在智能生成方向的最新进展。

以下内容整理自周正龙博士的现场演讲，为方便阅读，结构与顺序有所调整。

从压缩到解压：一条逆向的生成思路

AI领域流传着一句话——“压缩即智能”，这是理解大模型学习机制的一种视角。但如果我们把目光转向内容生成，就会产生一个相反的念头：能不能从大模型里“解压”出我们真正想要的内容？

先看一段演示。这是我们面向 AI 3D 生成打造的一款编辑器 PinK，用户可以在编辑器里通过与大模型对话，生成 3D 内容乃至完整的游戏。

过去一年这个领域发展极快，对引擎和游戏公司而言都是巨大的挑战。我们需要尽可能利用大模型的能力，做好 Web3D 内容的生成。

COCOS引擎：轻量跨平台的运行承载

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

架构上从下往上看：底层适配了 Web、移动、桌面以及小游戏等平台；中间是核心系统，包含渲染器、动画系统、物理系统和 UI；上层是游戏内容，涵盖场景、预制件、资产以及用户编写的脚本。引擎提供能力，内容表达则决定人和 AI 如何使用这些能力。

那么接下来的问题就很自然了：内容到底应该怎么表达，才能让人和 AI 都方便地使用这些能力？

传统内容生产存在四个典型问题：

1. 大量配置依赖人工逐项完成；
2. 场景、资源和脚本分散在不同文件里，缺少统一描述；
3. AI 很难直接理解和修改这些内容；
4. Runtime 偏重，简单内容也可能引入用不到的模块。

要让 AI 更深入地参与进来，就得把内容表达得更清晰、把操作能力开放出来，同时让运行环境更轻。

双路径驱动：PinK、MCP与CLI-CORE

在驱动内容生成方面，COCOS 做了不少工作。整个工具链可以分成四层，最上层是 PinK，或者说利用 VS Code 打造的编辑器前端，开发者可以在编辑器中发起对话或操作，它是人机交互的入口。往下是 MCP，基于 Model Context Protocol，将编辑器与 AI 工具接入 CLI，让 AI 能够调用命令能力。核心是 CLI-CORE，一款基于 MIT 协议的开源命令行工具，负责解析命令并调度所有操作，向上承接 MCP 请求，向下驱动编辑器和引擎各模块协同工作。最底层是 COCOS 引擎本身，所有生成的内容最终都运行在引擎之上，可以跨到各个平台。

目前大模型大多用 JavaScript 做 Web3D 内容，而 COCOS 引擎同样可以做到这件事，因此我们设计了一个双路径方案：

• 第一条路径：AI 和人工对项目进行联合编辑；
• 第二条路径：对引擎做精简，完全依靠 AI 生成所有内容，使生成和迭代更加快速。

通过这两条路径，整款游戏由 AI 生成这件事确实是可以成立的。

生成难点：正确性、复杂度与用户意图

我们确实提供了不少工具，比如 MCP、CLI，用户也可以贡献自己的 skill 来帮助大模型生成内容。但生成过程中依然存在几个棘手的难点。

首先是正确性。大模型不一定能完全正确地生成对应内容，代码能不能运行、结果能不能验证，都是问题。其次是复杂度。当场景、组件与资源需要协同时，项目复杂度很难扩展。第三是用户意图。大模型有时很难理解用户输入的要求，不知道如何把模糊的需求转化成明确的实现约束。

为了解决这些问题，COCOS 做了一个生成器框架 Generator，用来辅助缓解大模型的各类局限。

Generator生成器：领域规则驱动的确定性解压

核心思路其实是从“压缩”过渡到“解压缩”。大模型在学习时，通常是基于用户的内容和经验，形成可以用于生成的规律；反过来做生成时，我们走一条逆向路径：给定较少的输入，通过既定的规则展开。也就是“一个紧凑的描述 + 一套领域规则 → 生成实际可运行的结构与操作”。

这相当于拥有一个固定的解压算法，只要给定输入，输出就是确定且可预测的。大模型只需要理解这个解压工具怎么用，就能达到大规模数据生成的效果。

基本流程是这样：先把整个领域知识放进生成规则里，通过简短的描述展开成具体可用的代码。具体步骤包括：

1. 编写一个 .spec 文件，用它定义各种规则；
2. 分析这个文件，理清其中的语义模型、类型与关系；
3. 进行代码生成，产出对应的数据结构与操作，直接应用到引擎中。

这个思路的好处非常明显：大模型生成的代码量通常非常大，多数人难以理解。如果把它压缩成一个紧凑表达，不仅大模型可以生成，人也容易看懂。

其实 COCOS 之前已经有一套领域生成工具，是用 C++ 实现的内置语言，描述了内部的 RenderGraph、ResourceGraph、LayoutGraph 等数据结构。新版为了更加 AI-Native，已将其改造成独立的 .spec 描述，对应生成 workspace 和项目。两者共用同一套生成机制——输入、语义模型、最终输出和工程文件都可以互相转换——但对大模型来说，新版理解起来要容易得多。

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

一个示例：用.spec描述图结构

下面展示一个例子：用 .spec 文件描述一个 graph 的数据结构。它可能是一个双向图，基于 vertex list，每个顶点携带若干数据。大模型完成描述后，生成器就会自动生成对应的 TypeScript 代码和数据结构，同时也能生成 C++ 代码。

module Demo;

struct WeightTag {}
struct ActiveTag {}

graph DemoGraph {
  vertex_descriptor Vertex = int;
  vertex_storage: indexed;
  bidirectional_graph;
  vertex_list_graph;
  mutable_graph;

  component weight: int { member: mWeights; tag: WeightTag; }
  component active: bool { member: mActive; tag: ActiveTag; }
}

同一个声明，同时约束了图结构、数据布局与可用操作。这样的 graph 描述具备非常强的表达能力。游戏引擎中大量数据结构本质上都是由 graph 描述的，比如 RenderGraph、SceneGraph、AnimationGraph，这些基础数据结构的代码全部可以通过生成器产出。

这样做有几个直接的好处：

• 降低上下文压力：大模型不再需要直接操作各种 C++ 或 TypeScript 代码，只需修改 .spec 文件即可；
• 不会写错：生成器的规则是固定的，一次修改就能展开为成套实现，约束与维护规则保持一致；
• 放大倍数高：一行描述可以放大到十几二十倍的代码量，在性能和上下文消耗上都有明显优势。

三大领域建模实例

我们也可以在不同领域共享语义模型，生成数据结构、不同语言的代码，以及对应的算法和业务规则。这样的语言其实都是在各自领域内部设计的，每个领域有它自己的理解方式。比如一位资深架构师，可以把自己的领域理解投入到实现中，让目标更可控。整个编译测试、运行反馈、人工代码审查与核查的流程也会相对顺畅。

这里举三个具体例子：

RenderGraph 描述渲染流程与节点，比如 Shadow → Forward，以及 Post、Raster、Compute、Copy 等操作类型。

ResourceGraph 描述资源与状态，比如 Texture、Buffer、View，以及它们如何被操作、前后读写的依赖关系。

LayoutGraph 用于 shader 文件的布局，比如哪个阶段用到哪些资源，都可以在事前安排好。

这些复杂的数据结构都可以通过生成器生成，大模型只需要理解上层结构即可。

生成阶段与运行阶段的职责划分

这张图总结了整体流程。在生成阶段，人工和大模型共同编写领域声明，产生不同的类型与能力；生成器进行语义展开，产出 graph 类型和其他领域内 API，这些都是可调用的基础。在运行阶段，用户根据具体需求实时构建 graph（比如 RenderGraph），调度具体的 Pass 与资源关系，最后在引擎之上进行分析与执行。

这样一来，领域生成、运行时构图、渲染执行三者各司其职。我们下一代 WebGPU 渲染器的数据基础，全部通过生成器生成：用图来描述整个流程的依赖关系，再组织整个场景数据。

面向AI的渲染管线与场景构建

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

比如一个具体的需求：在场景颜色输出之后，增加一个后处理 Pass。在这个框架里，你需要描述输入、输出与依赖关系——场景颜色（Color Texture）作为输入，后处理 Pass 定义效果、输入与输出，最终目标为屏幕输出。系统会检查资源匹配、依赖合法和输出可达三个状态，由领域表达承接意图，结合构建检查与运行反馈来完成验证。

这样有利于大模型构建复杂的渲染效果，而不是在缺乏约束的情况下盲目生成。

场景内容方面，Web3D 的世界表达还需要考虑复用、嵌套与局部差异。可以通过定义 Prefab 资产格式（如 glTF），将它们组合起来，尽可能用组合的方式还原一个复杂的虚拟世界。

如果描述语言本身就是一种可描述性较强的格式，大模型生成起来会相对容易。COCOS 4 之前主要通过 CLI 直接操作场景，并不能直接生成描述文件，在生成上确实遇到了一些问题。之后我们都会改成这样的方法来实现。通过对整个场景的分层表达以及组合结果的缓存，可以构建出比较复杂的游戏场景。这也是我们正在探索的方向和目标。

总结：确定性展开，可持续编辑

这套生成器框架可以辅助大模型进行内容生成，核心价值体现在三个层面：

1. 降低上下文压力：领域知识进入生成规则，AI 只需聚焦 .spec 中的意图与约束，其余由生成器展开；
2. 可重放，结果稳定：固定 .spec、生成器版本及依赖后重复执行，通过差异对比检查结果；
3. 行为可控：用类型与语义检查约束生成，算法和业务行为仍需人工审查、编译与测试，生成边界与验证责任清晰。

生成器承接的是固化的领域知识，而且它本身也可以自举——通过生成器来生成生成器。有了这样的流程，实际操作的效率非常高。

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

---

本文内容来自第十一届中国图学大会现场演讲整理，技术细节与架构图版权归 COCOS 及演讲者所有。如果你对 AI 驱动的内容生成与 Web3D 引擎实践有更多兴趣，欢迎在云栈社区交流讨论。