请承接上下文讨论：
你回复的是 “有人评价我们这样的完全开放的设置不够好” 太自由了，说自由不一定是好事。
你是基于他说的自由不是好事，来评论目前的方案也不够自由。
请就事论事，这边没有谈插件的拓展能力。
所以我想问你，对于配置的自由，你需要的是什么样的自由？
从官方来看， 引擎就是基于electron开发的， 使用前端开发模式也无可厚非。除非是重构ide，使用native来做了，这个几乎不可能。确实可以参考vscode的插件开发模式， 毕竟vscode已经很成熟了。
哦。我仅仅是回复他，不看上下文的，你觉得我时找事就是找事咯。反正你是官方，想怎么认为就怎么认为。如果击碎了你的玻璃心，我认错拉。不过论再插件用vite+vue，我觉得我是挺有发言权的，毕竟应该没几个比我早。
只回复，不看上下文，还不是无脑拉踩？
回到 vite + vue，如果你很有发言权，很有经验 ，那么就给出建设性建议，我也希望得到有建设性的建议。我从来没见过技术讨论是上来就秀优越感的 。（当然这句不针对你）
嗯嗯，后续会调研一下 vs code 的插件开发方式。
我拉谁了？而且我也不觉得这个叫踩，最多算调侃吧。我刚刚说的问题不属于插件范围？他给插件做贡献了，免费给大家参考，不像你们拿工资，他还不能秀优越感了？人总要图一样吧，而且我的技术文档早就发出来了。 Vue3单文档开发插件 - Creator 3.x - Cocos中文社区，如果你有关注，应该早就看过，正因为我做过，才晓得这玩意多么的蛋疼
关于插件开发，前面大家也说过还要学web开发，不能直接和游戏一套的问题，就不再说了。我从我开发几个工具插件的角度来聊一下。
我的工具插件一般没有面板，基本都是通过菜单项驱动的，在开发过程中，我发现消息API在精细操作一些资源的时候完全不够，如果可以的话，引擎组可以做一些类似的API库。
例如，我的插件里面，做过的事情是：
1.重新建立自己的AssetDB类。通过扫描全项目的meta文件，来做一个资源和uuid，以及meta数据的对应db。方便对资源的查找以及meta文件内容的修改与批量操作。
2.封装一个PrefabInfo类，读取Prefab文件内的各个节点，并且组织成对应的自己数据结构的数据树，以及修改Prefab内的内容并保存。
3.封装一个MaterialInfo类，读取Material文件内的各个数据并组织起来，以及修改内容并保存。
封装完了这些，我才能比较方便的去操作一些资源。
这些事情其实本来应该引擎组来提供类似的API或者类库来做，整个内容相对来说比较多比较杂，如果能提供一个类似的标准库，就方便我们这些操作资源的操作了。
此外当前场景，针对节点的细致修改，也最好能提供一个库，例如（点一下菜单触发）来查找到当前场景的节点，并改变其某个组件的某个值。目前我倒是用到不多，但是粗略看了一下功能还是不强。
1赞
明白你的需求了，就是目前只有最基础的ipc 机制，而且现在的 ipc 也不太好查，之前有看一些开发者通过 消息监听那个面板看ipc。你希望每个底层模块 可以提供一个封装好的class，让你调用。
这个是个体验提升的点 
除了封装好现有的消息，最好还是能提供一些对文件数据的修改类库，例如Prefab，Meta和Material这些文件，在修改里面内容的时候，往往都要先自己建立一套数据结构把内容读取出来，然后修改了保存。
举个例子：我做过比较复杂的资源操作 ，包括把以前非cocos项目的ui界面xml，（通过文本形式）转换成cocos的ui的prefab文件。对其中每种UI组件，我都要封一个数据结构去处理，整体再组织成一个Prefab文件进行保存。这点如果没有很好的Prefab文件数据封装，要做的事情就比较多。
其他功能里面资源操作依赖Prefab和Meta的也数不胜数。批量改配置，批量改纹理压缩，创建新Prefab保存全动画列表方便分段加载等。
还要学web开发这点就劝退很多人了，unity的编辑器开发实在太方便了
不必说再多，插件开发对99.9%的cocoser都是属于黑箱技术一样的存在，多少人动过开发插件的念头又无从下手的，能坚持下来的都实属不易，但是可能对他来说，给我们一条路开发插件已经属于大恩大德了，还敢抱怨，那是万万不行
1赞
cocos-plugin加油，真棒，祝cocos插件越来越好
想说很多，发现只能说这句话
1赞
你可以理解为借力，unity如果有更成熟的gui方案，估计也会考虑，反正你总要学习一套新的gui方案
想问问游戏脚本能不能收到编辑器的事件？比如编辑器中更新了一个文件，脚本中如何监听这种更新事件？
确实一开始确实很排斥web感觉有一堆东西要学，后来弄弄发现有很多现成的库比如element plus用起来还是蛮方便的
我自己也开发过几个插件的，也写过插件编译工具，也是翻过hook看过一点编辑器源码的。
我说的自由，是指，引擎提供的扩展方式，基于web和nodejs，有大把库和框架可用。ui想怎么写就怎么写。
为什么我说这个是代价呢。也许会让官方认为我都这么自由了，你们啥都可以搞，代价是缺乏心思去思考怎么提供更好的扩展方式。所以扩展也许只是引擎开发需要的副产品，开放给开发者，内部用可能舒服，但脱离了引擎编辑器源码，就没那么好用了。
对于开发者而言，自由意味着，什么轮子都要自己造。就跟放养一样。造轮子意味着要花更多时间学习，探索，踩坑，这是代价。
为什么有怨气？能在这个帖子发言的，大多都自己开发过插件，也难受过。看到官方下场发帖关注插件开发。之前可是少理的。觉得可能有人愿意管了，有思进取了。也想给些建议，让这件事可以成。变得更好。
还有就是，明珠在前(Unity的扩展)，后起之秀（Laya3）.看着别人好用的，花心思做的好用的插件扩展，心里酸溜溜的
Laya3虽然运行时和稳定性差一点，但它肯抄呀，肯花心思搞扩展，即使同样用electron，但他的扩展是用起来舒服很多很多。
还有就是提供了很多都很常用编辑器功能的接口，比如gizmo操作，场景操作，等等。
开发起来就跟Unity一莫一样 
希望Cocos的扩展系统越来越好。
4赞
明白了，自由意味着需要额外学习（主要是这个学习是对游戏开发无效，属于额外学习），如果官方可以提供一定的开发范式，哪怕不那么灵活，都是可以接受的，我后期尝试下约定面板的开发范式，让开发者写 panel。
比如告诉你 面板就写一个 render ，然后面板里面用的东西 就写在这个 data。 事件绑定就用 @
如果有可行的技术方案到时候可以放论坛供大家讨论。
1赞
是这样，先降低门槛，提供一个简单的规范让大家能快速上手开发一个简单的插件，至于后面想实现更多功能有兴趣的自然会去学习其他相关知识
我觉得你还是没明白，易用性不单单是范式的问题，可以先考虑有没有方法让大多数人更快的做自己想做的的简单功能，比如我刚刚说的，大多数时候开发者就想给项目里面加一个组件按钮，加一个菜单，做一些简单的事情。
然后再是少部分插件开发者，需要更多的复杂的功能需求，但是他们的需求很多时候需要引擎提供更多的，细小的，功能更全的接口，涉及方方面面。
unity我我也上架了近10款插件，里面的接口不用hack，基本你想到的功能都有一个接口等着你。
嗯，但是这个需要基础模块提供非常多的拓展接口啊， 插件只是去侨接这些基础模块。
你的诉求主要是无界面的，比如菜单这样，纯功能型的。
目前关于菜单类的拓展也只有 层级管理器和 asset 面板多些。
你可以具体提一些需求，比如你现在想拓展哪里的菜单，不方便，我们也可以考虑完善一下。