【预告】peanut-pod:装进现有 Creator,给 Agent 一条可验收的编辑通道

各位开发者好,

很多人已经用上大模型写代码了,但一到 Cocos Creator,痛点还是很硬:

  1. AI 改得了脚本,碰不动 Prefab / Scene——节点树、组件属性、Sprite 绑定还得人手点
  2. 不敢把工程交给「随便改盘」的 Agent——缺引用、空点击、坏 uuid,上线前才爆
  3. 换 IDE / 迁项目成本太高——现有 2.4 / 3.x 工程动不了,更不想推倒重来
  4. 改完无法验收——没有预览刷新 + 控制台错误闭环,等于黑盒交付

peanut-pod 想先把这件事做清楚:

不换你的 Creator。装进编辑器当宿主扩展,用 MCP 受控能力 让 Agent 查资产、改 Prefab/Scene、刷新预览并读错误——写源文件 / .meta不写 library/


痛点怎么接

痛点 peanut-pod 接法
AI 只会改代码 Lumen:按检视器语义搭节点、改组件、绑引用
现有工程迁不动 原生宿主扩展,继续用你现在的 Creator 工程
缺引用 / 空绑定 缺引用扫描 + 单文件 validateRefs
改完没法验 preview.refreshpreview.queryErrors
乱改盘不放心 MCP 受控写入;破坏性操作要确认 / 批准
老版本被落下 三线:peanut-pod / peanut-pod-35 / peanut-pod-24

支持范围(请先看清)

产品线 Creator 版本 宿主包名 插件水位 实机验证
stable(主推) 3.6.x – 3.8.x peanut-pod 全量业务插件 3.8.7
creator2x 2.4.x peanut-pod-24 全量业务插件 2.4.11
early3x 3.0.x – 3.5.x peanut-pod-35 精简(host + editor-mcp) 推进中

补充说明:

  • 覆盖目标总览:Creator 2.4.x – 3.8.x
  • 能力重心:Prefab/UI 拼装与绑定、资源健康诊断、预览验收、场景薄层、受控构建探测
  • 不是整款游戏研运全家桶(渠道壳 / 运营后台 / 模型商店另轴,本次不做)
  • Alpha:请备份工程;生产环境请等后续稳定版

首发能力(人话版)

1. Editor MCP —— Agent 调编辑器,而不是瞎改文件

  • 查资产、扫缺引用、查节点(薄层)
  • 刷新预览、拉取预览/编辑器错误切片
  • 工具少而准;不做任意 file-*-text 改盘

2. Lumen —— 按检视器语义写 Prefab / Scene

  • 搭节点、改组件属性、绑 Sprite / 点击 / 引用
  • 改资产源文件与 .meta不写 library/
  • 推荐验收:validateRefspreview.refreshpreview.queryErrors

3. 业务插件(随主线可装)

  • ui-prefab:UI / 控件落地
  • content-delivery:内容分发
  • snowb / SDF:字体工具链
  • 可热装治理,不跟宿主绑死

4. 明确不做(这次)

  • 不替换 Creator,不强制迁 VS Code 壳
  • 不开放任意 preview 脚本注入
  • 不做 PinK 式 Chat / 激活码 / 运营后台产品面

测试计划(预告)

首轮拟 受邀试用

  • 论坛活跃开发者
  • 对本帖路线 / 许愿高赞的同学
  • 少量抽选

下载与安装说明在正式发布帖放出。本帖只做进度同步、范围对齐与意向收集。


意向统计(请投票)

想提前摸清社区更倾向哪种获取方式(可多选)。不代表最终定价/授权方案,只作路线参考。

  • 订阅制(按月/年持续更新)
  • 开源(协议待定,欢迎共建)
  • 一次性买断(永久授权当前大版本)
  • 还不确定 / 看价格与能力再定

0 投票者

补充意愿也可以直接回帖写一句,例如:「团队更希望买断」「个人更希望订阅」。


想听你说

回帖聊聊你最卡的是哪一段(越具体越好):

  • UI / Prefab 拼装与绑定
  • 缺引用 / 坏引用排查
  • 预览刷新与控制台错误验收
  • 2.4 或 3.0–3.5 兼容
  • 构建探测

我们按真实工作流排优先级,不堆「看起来很多」的工具名。


peanut-pod 开发者,
(预告稿 · 非正式版本)

同时也希望有更多有志之士加入我的团队,继续为cocos的插件系统发光发力。帮助大家更方便的做出更好玩、更有趣的游戏!

牛的,支持下!

看起来很厉害哦

操作场景和节点的MCP已经有不少人做了,业务插件和验收闭环能细说是什么能力吗?

简单说明一下我们这套 Cocos 侧能力里,业务插件和验收闭环分别是什么。

业务插件是什么

不是 Agent 里的「Tool」,而是装进 Cocos Creator 的平台插件(经 Plugin Manager 激活、按权限
grant)。职责是:在编辑器里提供可调用的能力,再通过 Hub / MCP 给 AI 或脚本用。

当前大致包括:

• editor-mcp:总入口。离线改 Prefab/Scene/资产(lumen.)、导入与资产生命周期(asset.)、场景/选区/预览等薄层操作
• ui-prefab:设计语义 → Prefab(内部走 MCP/lumen,不是旁路手写 JSON)
• lumen 面板:模板缓存(同步/重置默认 Prefab 模板),不是 AI 写盘主路径
• snowb-bmf:BMFont 编辑与受控导出
• 以及 content-delivery、sdf 等 provider

和 Agent 的边界很清楚:业务能力在 products/cocos,Agent 只通过契约/Hub 调用,不直接 import 编辑器插件源码。

验收闭环是什么

指:资源写完之后,有一条固定、可重复的验收路径,证明「编辑器真加载了、预览没炸」,而不是脚本跑通就当交付。

默认习惯是三条车道分开用:

  1. 写盘(离线):lumen.* / asset.import* 等改工程源文件
  2. 一次收口:lumen.commit(刷新 AssetDB、校验引用等),多文件改完再一次 commit,不要改一个就 commit 一次
  3. 预览验收:跟返回的 recommendedNext 走 → preview.refresh → preview.queryErrors(可选截图)

硬规则包括:不走 Creator 的 scene.save 当写盘;写盘车道和「给人看界面」的 scene.open 车道分开。

工程侧还有无人值守探针,例如 probe:agent-accept、verify:plugin-system / host 实机验收,用来在真 Creator + Hub
上复跑整条链。Node 单测绿 ≠ 宿主已验收。

一句话

• 业务插件 = Creator 里可装的能力包(MCP / 设计转 Prefab / 字体 / 模板缓存等)
• 验收闭环 = 写盘 → commit → 预览查错(+ 实机探针),用机器可读结果证明交付成立

装包与选型以工程文档为准(装包走pack:demo,兼容水位看兼容矩阵)

也就是说,我们这个mcp,不仅仅是针对资源操作,更多的是兼容后续能力的基础,比如我们已经计划接入snowb的字体渲染生成fnt,这个时候我们只需要调用mcp就能做到,再也不需要手动去操作,后续还会生成更多的这种插件。而且扩展方式很很简单,安装了也能热启动。不需要再重启编辑器了。

这套agent 2.4的项目升级到3.8能搞定吗?

原理上你同时开着两个版本的项目,都装上插件,是可以处理的,就是比较费token

看着挺不错的

我最近在用AI生成一个可以替换UI预制体的插件(摆放位置、替换资源啥的),不知道能不能行,还在进行中

5.6 一把梭,还要这些干啥

能不能按照规范拼UI,给个效果图和资源1比1生成,节点命名规范呢

我们这个只是mcp,不是ai本身

大家有没有什么想做的模块,都可以告诉我们,我们会评估一下可行性