1、聚焦某个特定场景的低代码/无代码是很能提高效率的。代表如蓝盾，以及一些活动页发布平台（供运营同学使用），以及一些数据标注平台。它能让更多不懂代码的人参与进来。
@vast-开发工程师▼1.只要是低代码，就一定有代码编辑。本质是一种dsl，类似于一门简易编程语言，有一定的学习成本，需要详细的文档支持，或者经常使用。就我自己的经验，一套低代码的数据结构不常用的话，很快就忘了，回头还得查怎么实现的。
2.一般来讲， 外部使用越简单的系统，内部功能越复杂 ，因为内部耦合了大量功能（不需要外部输入即定义好的功能），灵活性就比较低，也就是所谓的适用于垂类场景作为特解。并且面对频繁需求变更的时候处理起来就很棘手。
3. 适合于预定义好90%功能的场景 ，例如对B按照合同交付那种，做完之后再改需求补功能都要加钱，这样甲方才可能在前期就给出详细的功能诉求，低代码的系统才好设计。对于受雇于公司的常规开发人员，提需求动动手，甚至只动动嘴的甲方（产品），一旦后期出现个现有方案无法覆盖的场景，可能就是大改，或者插入hack代码实现，会陷入疲于维护系统本身的状态。
@erpeng-开发工程师▼我工作中遇见推广低代码的人，他们背负着人力成本的压力，就想加快开发速度，而低代码平台完的PTT讲解，可以满足他们对于减少人力成本的需求。反倒是，遇见的程序员同行，对于低代码平台的接受度没那么高，甚至于维护低代码平台的程序员，都觉着不是很方便。
@vic-前端产品负责人▼一个需求是否要用低代码，只要考虑一点，就是该需求是否足够高频、同质化。
目前司内和业界最常见的低代码都是解决To B类需求的，比如管理系统、运营系统、企业OA系统等。这些系统非常多，一个业务里就有几十上百个，而且有很高的相似性，90%的页面都是表单和列表，这时候低代码就能大显身手。因为系统已经集成了所有业务无关的平台能力，包括网站框架、前端组件、后台服务调用、权限管理、监控日志，甚至发布运营都可以交给平台。公司的无极低代码就是做这个事情的。
对于使用者来说，评估是否要接入一个现成的低代码系统，只要看平台帮助解决的问题是否足够多，收益是否大于接入成本和学习成本。除了ToB类系统外，另一个很好的场景就是后台服务，足够高频，也有很高的相似性。而其他场景，比如APP、小程序，主要是不够高频。虽然公司内很多，但分散到各个团队，每个团队也只要做1款。如果一个团队要做10个小程序，那一定会产生一个做小程序的低代码系统。
@whinc-开发工程师▼很赞同你的观点，我也是秉持同样的想法，我只将低代码只用于局部垂直场景，这样兼顾性价比和灵活性，最少的投入获得最大的产出。做一套大而全的低代码，意味着需要专职团队来支撑，这是一般业务不可接受的人力投入，而且灵活性不一定能照顾到。如果投入人力过少，最终维护是个大问题，反而变成了历史包袱阻碍业务前行。
我开发的运营系统比较多，其中表单占比最高，这块使用低代码方式收益就很高，而且以 SDK 形式可以无缝接入各种业务系统，可以按需使用、局部使用、定制封装。如果使用大而全的低代码平台，意味着整个系统都需要与低代码平台耦合。
@vvdennis-前端开发工程师▼我自己的看法，低代码是更上一层的开发方式，可以减低应用的开发门槛。
这种开发方式的演进，本质就是不断抽象、封装底层的能力，让程序员可以更便携的管理内核，开发应用。以前学汇编，必须要了解硬件；现在学脚本语言，虽然也需要了解操作系统，但是对硬件相关的知识相对而言没那么重要；也就是说，有了更高级的语言，对程序员知识体系的要求就降低了。而低代码，我认为是在编程语言的下一层级，用低代码的方式开发，门槛更低，低代码用户（某种意义上，低代码的用户也是新一代的程序员）不用关心程序的性能、兼容性等等，仅关注应用开发本身。题外话，也许下一个迭代，会出现 AI 开发的概念，即程序员只负责提需求，不需要写代码、不需要拖拽，钢铁侠是工程师吗？我觉得是，但他好像从来没写过代码。
很多小公司使用低代码，也不一定是看中了开发这个环节，而且低代码一般都包含了全链路资源托管，省去了打包，代码托管，发布等各个环节。
再说下低代码的能力，在垂直领域，低代码的价值是非常大的，小公司省去了很多的人力成本，大公司也可以依托低代码提升产出，提高质量。部门内很多营销活动，都是通过星图配置的，其中超过 60% 的接口都是零代码，如果要纯代码开发，然后还是项目外包来搞，效率和质量很难保障。
@bear-前端开发负责人▼我来尝试回答下，设想有这么一个场景，你想送一座玩具城堡给小孩做圣诞礼物（需求），现在可以选择：
手搓法（纯手工打造）：你买各种原材料来进行裁切，打磨与搭建。你可以使用各种精致的工具（TDesign / antd ），可以自定义各种能力（比如甚至可以埋一个 WebLLM 进去），反正就是可以做任何 web 能做到事情，毕竟 js 有丰富的社区生态。
低代码的优势在于，它是介于两者之间，你想自己搭建，但又不想过多关注实现细节，只关注交互即可。至于你所说的复杂项目，得看是什么类型的复杂，是逻辑复杂还是交互复杂。比如，蓝盾流水线的编排就属于逻辑复杂，涉及拖拽能力，绘制svg，碰撞检测等。但是，如果把这个编排能力封装成一个积木，就瞬间变成交互复杂，所关注的点瞬间变成这个编排组件和其他组件的联动，此时低代码就变得合适，所以得具体场景具体分析。至于你说的大量 定制js & 定制ui ，这个就像前面说的，这些定制化的能力，是逻辑复杂还是交互复杂？逻辑复杂的话，能否组件化（抽成一个可被独立引用的js）？
另外，低代码的优势还在于产出的样式稳定以及人员的低培养成本，对于一些常见的表单+列表需要，低代码会是更好的选择。因为表单一般是关注选项间的联动，其它的都是现成的，直接套用积木即可。
@sarlmol-后台开发负责人▼低代码不见得只能处理简单逻辑，反而从我们后台低代码的实践中发现低代码更适合处理复杂逻辑，好处有几点：
2.复杂逻辑更安全的变更能力，降低了变更风险；3.统一的容灾范式，降低了开发稳定后台服务的门槛。
业务咨询
扫码，关注我们
