ab合用呗，多人合作独立功能分发，单个功能模块大体预制个人处理，通用小模块统一处理，无非就是预制的生成，层级的处理。
+1。我思考了差不多一个月。也觉得如果多人协作的话。最好强制用B。虽然对于个人会很不爽，但是对于整个项目来说，是有益的。
B方法最大的问题是代码依赖节点路径结构，如果你的项目里面美术同学或者有个专门的UE同学可能会修改节点的话，那就是灾难。
我尝试过B方法，不得不说是挺麻烦的，老板给的开发时间不够充足的情况下实在不敢使用。我现在算是AB混用。
很显然，可视化的效率高
A的缺点写的有点过了，稳定的项目没有必要升大版本，也没有人要把cocos引擎的代码切换到别的引擎上去，这种纯粹是极小概率的事情，预制件与脚本的名字保持一致，不需要去找，熟悉一个模块，先看运行一遍看看功能，然后看一下预制件，最后再去看代码，这样省事的多。你要先有图像功能再去想实现逻辑，先有整体，再去看局部，基础组件就那么多，写法也就那么多，还能写出花来？猜都猜到八九不离十。
2赞
这不好说哦，说不定你3.X开发了大半年，发现原生上有个致命bug。最后要降级到2.X。到时候就够你酸爽了。我真的和别人聊过。别人家用3.x开发了一个游戏。开发了大半年。结果在原生上的性能没法看。最后决定要用2.x重写。但是他说，大部分逻辑都可以复用。工作量不是很难想象。我估计他们是用了B的开发方式。
怎么可能，遇到问题首先就是找到问题，并尝试解决解决。怎么可能动不动就降级引擎呢？引擎组是开玩笑的？引擎开源是开玩笑的？
退一万步说，规避问题也比降级好的多。不管你用什么方式开发，遇到一个问题你以为降级了就没事了？想都不要想。
2赞
看了别人的评论，然后结合这几年开发的项目，我觉得框架和共用方面用B为主，具体开发界面时用A为主（提高效率），这样比较好
2赞
我们也降过一次 用3.0x.快开发完了 后面降到2.x再弄一遍 花了差不多一周的时候
那你们也太猛了。哈哈哈
我是 Unity 和 CocosCreator 都做过几年。
我主要用的是B方案。
个人觉得还是B方案靠谱些，不依赖编辑器。多人协议也方便
A方案主要用于写一些通用组件
2赞
项目小无所谓，项目大支持B派
这个和项目规模有关系。小项目周期短，比较追求效率，用A。大项目支持用B，因为大项目可维护性更重要，后期不方便维护带来的效率损失相比A带来的优势要严重的多。当然项目里与具体业务无关的通用组件用A开发是没问题的。至于基于路径找节点的问题，在上规模的项目里，资源不是随便放的，肯定项目组得有一套规范去约束。
使用B的时候一般都不会直接在代码里写死节点路径，而是有配套工具生成一个配置：
uiConfig里有： sureBtnUrl = “a/b/c/sureBtn”，这个配置文件是动态生成
具体的业务逻辑获取组件如下：
sureBtn = node.getNode(sureBtnUrl)
总结了一下上面的讨论，都认为A最大的缺陷就是不能根据代码逻辑追根溯源，不便于维护和代码阅读
我这里说说自己的看法
A，按照楼上说的统一预制名和脚本名，那么通过代码加载的资源名就能找到所属类，这样就可以追根溯源
B，我上面已经说过了，还是查找引起的问题，因为我觉得在工作中，修改预制体和对应的脚本逻辑是很频繁的事情，用B方案就需要 复制预制体名->搜索脚本->手动分辨对应脚本->打开脚本 ，而A只需要 点击组件->打开脚本，如果不通过插件实现，我觉得B浪费的时间积累起来是很多的
另外问问用B方案的各位，策划想要配置组件属性这些，请问各位是怎么操作的？
从配置转换到代码里对象的过程，我倾向于提取到组件脚本外部作为一层胶水代码。
这样A和B在组件脚本的写法上没有什么区别，都是暴露@property组件，区别是A用Editor绑定，B用胶水代码运行时绑定。
这个额外增加了很多配置的工作量，因为实际代码过程中，需要用到的引用还是挺频繁和复杂的，而且还涉及到多人同时修改表格的冲突问题。如果可以确保节点路径只有程序员会改动，那相对还好，但是如果是大项目，有专门的UI或者UE会修改节点的话就会有点麻烦。
不会有额外工作量啊，制作一个模块的时候都是顺手导出ui配置了，，，，
B, 否则多人开发的时候，甚至包括别人接手，以及规范化的codereview时候，A难看懂，或者说效率低。如果某些东西一定要程序员用代码写，那么我倾向与一定要考虑多人合作和接手问题。否则就是艺术家创作的范畴了，就应该变成资产文件
目前都是一个人做项目，个人觉得A用起来爽的，但一直感觉不是长久之计