以下是个人做低代码平台这几年的一些总结
-
现有业务结合低代码有没有必要？
资本市场需要，低代码平台主打的是一个科技创新。至于是“降本增效”，还是“增本降效”其实都不重要，能讲出故事最重要。 -
通用低代码平台有没有市场？
有，无论B端，C端，G端项目拿补贴都有科技创新绩效考核，采购低代码系统平时可以不使用，但不能没有；功能好不好用不重要，但不能没有，并且要堆的多，皮肤自定义与国际化有时候比核心功能重要。 -
垂直领域&通用低代码平台
-
其实很多公司自研低代码平台起初都是希望结合自己的现有业务和客户，比如解决80%或90%场景，但是一旦面向业务，就要通过低代码解决100%的需求，逼迫下那道边界线根本就守不住。
-
如果从一个行业开始切入，你会发现同一个行业下的不同客户的系统差异，有时候比跨行业的系统差异还要大。垂直平台只会被迫变成通用平台。
-
-
为什么通用低代码平台难做？
-
这里有一个认知问题，大部分人都是从UI侧去理解低代码，聚焦在组件的排列组合上。其实“拖拉拽”在前端领域是一个非常简单的技术，逻辑编排与运行时是低代码平台的核心，却一直被忽视。
-
一套严谨的低代码平台，通常是一个模块联系十分紧密的“大型单体系统”，逻辑几乎全部在前端，跟传统业务开发有本质区别，精密的设计与评估在很多公司很难保证，投入的资源也很少，但时间却很急。
-
-
部署占了一半的环节
部署，灰度，与现有系统结合，被其它系统集成，跨平台，跨小程序、私有化、混合云是剩余的50%，但却也需要占据大量资源投入 -
从产品经理层面 由于技术专业度太高，沟通成本很大
-
大厂很难做好低代码
一个绩效周期短一点3个月，最多6个月团队成员可能轮换了一半，我在阿里待过几年，出来后作为面试官，也聊过阿里不同事业部的前端，总的感觉是每个事业部都在搞自己的低代码 -
需求方
伪需求方真的有，一堆内部不想维护的、重要性很低、通用性很低、一次性的、很急的、需求都会砸过来。又或者“使用低代码完成需求”本身就是一个需求，这样的需求主要以“走通流程”为主。 好多的低代码团队面向业务的时候都比较弱势，通常都是乙方处境 -
低代码用户
目前还没形成，很多都是平台开发者“代运营”，自己开发一个平台自己用，如果走无代码化，程序员做出来的“可视化”编程界面实际上比代码还糟糕。
目前各厂的低代码平台都比较封闭，几乎都是把自己现有能力重新api化。所产生的应用本身的互联互通都是个问题。在AI的加持下，结合了一堆花里胡哨的的大模型能力，娱乐性比较高。
以上是当前阶段的认识，从长远看对低代码还是比较乐观
