AI+插件开发=效率x100

还在为复杂插件开发头疼？AI时代的编码规则彻底变了。

传统开发方式：资深开发者需要 1 周时间AI 辅助开发：不熟悉技术栈的我只需要 30 分钟

你信吗？一个功能完整的蓝图编辑器插件只需要 30 分钟，包含了：

• 蓝图创建、保存、导入、导出

• 节点创建、管理

• 内置30个常见节点

• 完整的蓝图编辑功能

这就是Cocos引擎团队推出的全新插件开发脚手架 create-cocos-plugin。

基于这个脚手架，你可以使用纯 Web 前端架构 + AI，快速开发复杂界面的插件。

比如：蓝图、行为树、配置文件可视化、策划数值编辑器等等。

这就是这个脚手架在 AI 时代，带来的极致的开发效率提升能力，完全碾压传统的引擎编辑器插件开发流程。

使用案例

它使用起来也非常简单，只需要执行下面的命令后，就可以获得一个新的插件模板。

// 注：Cocos Creator 3.8.7 中
// 插件模板选择会添加此流程。

//创建插件
npm create cocos-plugin@latest

//进入目录
cd 插件目录

//安装依赖
npm install

//编译
npm run build

使用 Cocos Creator 3.x 加载，就可以看到如下界面：

喏，下方这个插件，kylin-ai-terminal 也是我用 create-cocos-plugin + Cursor 写出来的。

开源地址：

• https://github.com/MrKylinGithub/kylin-ai-terminal

插件的核心功能如下：

• 提供了在 Cocos Creator 界面中使用命令行的能力

• 支持 Claude Code、Gemini CLI 等基于命令行的 AI 编码智能体

• 支持多标签窗口，方便让智能体和 Shell 同时工作

• 本插件 100% 由 Cursor 生成

技术要点

有小伙伴可能会觉得，AI 只能做一些简单的活，复杂一点的项目做不了。

为了方便大家理解这个插件有多复杂，我让 AI 帮忙画了一个架构图：

接下来，我们分享一些技术要点，这些技术要点，都是 Cursor 帮我发现并解决的，我只是陪他聊了三小时。

上下文感知

为了让 AI 了解我在做什么项目，我用 Cursor 打开了我用 npm create cocos-plugin@latest 创建的目录，然后输入下面的提示词：

“

请阅读当前项目源码，告诉我它是做什么的。

Cursor 读完后告诉我。

“

这是一个 Cocos Creator 插件项目，实现了一个 Hello World 界面，从项目名称 kylin-ai-terminal 来看，应该是想实现一个可以和 AI 交互的控制台，但目前并未查到相关代码。 需要我帮忙实现吗？

技术方案

由于我并不知道要使用什么技术栈，为了防止 AI 乱写，我让他先给我方案：

“

请先告诉你打算实现的方案，我确认后再编码。

Cursor 输出：

“

Cocos Creator 是基于 Electron 开发的编辑器，因此 Cocos Creator 插件也就是 Electron 插件。 在 Electron 中，通常使用 node-pty + xterm.js 来实现控制台窗口。 将 node-pty 在插件的主进程加载以获得系统命令访问能力，将 xterm.js 在渲染进程使用以渲染控制台窗口。

我对 node-pty 不太了解，于是追问道：

“

node-pty 是什么？为什么一定要放入主进程呢？

Cursor 回答道：

“

node-pty 是一个基于 C++ 实现的 NodeJS 模块......，之所以要放入主进程是因为 Electron 的渲染进程只拥有渲染权限，无法访问系统能力，如(fs、process、exec 等）。

三大进程

1. 主进程：负责启动插件以及其他子进程

2. Terminal 后端进程：基于 node-pty ，负责提供真正的系统控制台能力

3. 渲染进程：基于 xterm.js 负责窗口渲染和界面交互。

node-pty 环境依赖

其中 主进程和渲染进程 是 Cocos Creator 插件默认就有的。 通常插件只有这两个进程就可以了。

但我们发现 node-pty 是基于 C++ 编译的 NODEJS 模块，运行环境必须和 npm install 时的 NodeJS 版本保持一致。

比如，如果我们的 NodeJS 时 v20.15.1，当我们使用  npm install 安装这个插件后，node-pty 就会被这个版本编译。

如果我们用 Cocos Creator 主进程来加载它，就会提示 MODULES_VERSION 不匹配。

当 Cursor 发现了这个问题后，它随后给出了方案：

1. 让插件主进程启动一个子进程，在子进程中加载 node-pty，这样就可以将 node-pty 的 NodeJS 版本依赖与 Cocos Creator 解耦

2. 通过父子进程通信机制，将控制权转交给主进程，这样可以对外隐藏 node-pty 子进程的存在，让架构更稳定

3. 主程进通过 Electron 的 IPC 机制与渲染进程相互通信，实现前后端协同。

主进程脚本刷新机制

一开始，在写 node-pty 主进程服务时，需要反复修改。 但我发现修改了使用 CTRL + R 刷新没有用。咨询完 Cursor 后，得到的答案是：

“

Electron 中的插件主进程不会在刷新时被加载，必须重启 Electron 主进程。因此建议只在主进程。

“

技巧：对于某些应用，可以在开发模式时，将主体功能放进子进程里，并使用快捷键进行重启，发布模式时，以主进程方式启动，可避免反复重启 Cocos Creator。

相信如此复杂的插件架构，足以证明 AI 的能力完全能够编写复杂而实用的项目工具了。

Web 技术栈真的太强了

不得不说，在 Web 前端领域，AI 真的可以做到一马平川。 代码可以 100% 交由 AI 编写（前提是你用的 AI 足够聪明）。

这得益于 Web 技术栈是全世界开发者最多的技术栈，AI 训练数据最多，甚至大模型排行榜上还有专门的 WebDev 能力测评。

在以前，由于很多游戏开发者（比如我），并不熟悉 Web 技术栈，导致大家在制作过程中需要重新学习许多东西。

但是，AI 时代，一切都开始反转了，因为 AI 时代，即使你不会编程，也能通过 AI 帮你写出想要的 Web 技术栈产品。

在这个情况下，Cocos 当初的选择，又成为了当下的最优选，使我们在 AI 的加持下，可以快速为项目定制插件，飞一般提升项目的开发效率。

总结与期待

将插件机制向 AI 靠扰，只是 Cocos 团队尝试将游戏引擎与AI结合的过程中，获得的小小成果之一。

但这个小小的成果，却颠覆了游戏引擎行业中以往的开发模式，开发效率远远高于曾经的标杆做法：编辑器使用引擎 UI 来渲染这个方案。

Cocos 团队也还在摸索更多引擎与 AI 能够结合的方案，当某个方案达到实用级别时，便会开放给大家使用。

AI时代，机遇与挑战并存。

我们既要敏锐捕捉时代机遇，积极将AI技术融入实际项目。

又要保持冷静判断，坚持以解决问题为导向， 避免为了追新而追新，为了技术而技术。

真正的技术价值，在于实用与落地。

最后，送给所有 AI 时代的开发者：

仰望星空，脚踏实地，用技术改变世界，用实干成就梦想。