不对哦，应该把更多的逻辑关系放在代码文本里面，AI无需什么MCP就可以知道，而不是编辑器拖过来绑定，这种AI才不能一次性读取解析。
我是标准的B方式, 远古引擎都只有API没有编辑器的,习惯这种风格了,而且喜欢一目了然的代码关系,各种挂在组件上的代码复杂的多人项目看着太累了,我用creator就一个root节点,其他都手戳,只要不是复杂的预制体,我可能也用手搓了,用creator就为了一个,打包发布方便…
4年半了啊。你们还在挖我这老帖子啊。
不是吧，我感觉都不用手动挂脚本了，我自己创好预制体，其他脚本都让AI动态挂了，就是场景里我会挂一个启动脚本。
现在谁还用手动在prefab上挂脚本拖拽节点啊，太慢了。我们都是需要使用的节点做好命名规范（也能方便AI），节点数据统一脚本导出，运行时动态绑定，使用时代码里this.节点名 直接使用就行了。prefab改路径换皮 脚本重新统一导出一下，代码都不用改
我一直用的都是B，后来公司垮掉了，去了两个小公司，发现都是A写法，一个类都是上万行代码，而且没有注释，头都大。后来基于以前积累的多个项目经验，积累的框架经验，改写了一套B这样子的框架。我自己就用B这种，架构搭好，后续调整也方便。其他同事用A，我自己用B，两套可以混用
我也是，十多年用的B方式，而且中间直接架了一层引擎适配的中间层，因为只是2D项目，中间这一层全部把这些组件重新实现一遍 
，相当于适配了一层UI的架构。所有的节点直接用一个对象包装起来，直接用这个对象点出来，因为是ts，所以再做一个预制体生成接口的插件就可以了。因为也是不习惯绑定脚本，然后所有的生命周期，都是这个框架里面管理。就差把预制体重新解析成自己定义的二进制文件格式了、外加一个加载解析逻辑（加载目前也是中间加一层的）。。。。后来想着算了，直接序列化、和反序列化cocos组件属性
现在已经躺平了, 不管是A还是B, 都是claude大哥给我看.
2赞
流派可不只是A和B，流派很多，我用的就既不是A也不是B，没有单纯的哪一种，具体问题具体分析，编辑器本身的可视化编辑以及组件系统本身就具有设计上的优势，我会基于组件系统搭建项目结构和框架，分层实现最终需求目的。UI交互层充分利用编辑器和组件脚本的优点做通用交互逻辑，自动做最基础的UI绑定和交互。功能逻辑就是完全脱离编辑器甚至引擎的模块设计代码，每个模块都是独立的，不依赖引擎。逻辑层没有UI也能跑，换个引擎也能用。
1赞
都四年半了，这个帖子还被挖出来，我真是受宠若惊啊。不过时代变了。现在只有一个流派了。 codex帮我实现一下这个。
多人开发就选B，提交冲突会简单很多，如果确定主场景和里面的显示器只有一个人维护，不会有提交冲突那倒还好。公司的话肯定都建议B
简直离谱，改起来不得爽死了
也还行，架构前期支持麻烦、复杂，后续稳定了就问题不大。反正也只是做2D的多，而且中间层可以随时增加、或优化功能，就算cocos引擎升级修改、或增加了什么大批接口，也就架构适配层跟着改，上层完全不需要处理。这样子就算UI哪个组件有问题，完全不需要等Cocos版本升级更新。可以自己本地先修复。