前言

相信过去几年在投资领域除了硬核高科技芯片、自动驾驶等之外，低代码绝对属于一股清流。2018年6月，低代码赛道跑出了超10亿美元估值的独角兽OutSystems，一时风头无两。

彼时，海外巨头企业AWS、Google、Microsoft、Oracle、西门子等也纷纷推出低代码开发平台或通过收购布局低代码。

BAT等巨头的纷纷入局更是用实际行动地表达了对低代码开发这一领域的看好，不仅参与投资低代码企业（如阿里战略投资奥哲网络，腾讯投资低代码厂商道一云等），而且还推出自己的明星产品（如阿里内部孵化的宜搭、百度推出的爱速搭、腾讯云推出云开发低代码平台等）。

同时，阿里钉钉低代码聚合平台“钉钉搭”还联合8家主流低代码厂商，共同宣布成立业界首个低代码联盟。

同期的国内市场同样战绩频频，从2018-2020年，中国无/低代码领域总体投融资事件共16起。

在总融资规模上，国内无/低代码平台商共获融资近15亿人民币，历史融资轮次共50轮，平均单次融资规模3000万人民币，融资企业总估值近70亿元。

据海比研究院数据表明，2021年中国低代码市场达到28.5亿元。未来五年，中国低代码市场复合增长率为49.5%，2022年达到42.6亿元，2025年达到142.2亿元。

笔者近半年时间一直在参与SRM SaaS这块产品的工作，期间也涉及到了表单引擎、审批流、权限等基础设施产品的设计与开发，近期也对整个低代码产品、技术、市场做了一些调研分析，正好昨天阅读了艾瑞咨询2021年的低代码分析报告，今天就写一篇关于低代码相关的文章，接下来和大家聊一下我对整个低代码平台的一些思路与想法，欢迎一起交流与学习。

低代码起源

实早在很久之前，低代码的概念就已经出现了，只不过它以前一直处于不温不火的状态。直到近两年，大量IT巨头和资本的加入，才引起了越来越多的人关注。

这个故事，还得从上世纪八十年代说起。1980年，IBM的快速应用程序开发工具（RAD）被冠以新的名称——低代码，由此，低代码的概念首次面向大众。低代码是英文“Low Code”的翻译，它意指一种快速开发的方式，使用最少的代码、以最快的速度来交付应用程序。

而Forrester，一家国际知名的技术和市场调研公司，敏锐地发现了这一问题，并在2014年首次提出低代码和零代码的概念：只需用很少甚至几乎不需要代码就可以快速开发出系统，并可以将其快速配置和部署的一种技术和工具。随后在2018年，Gartner提出aPaaS（应用平台即服务）和iPaaS（集成平台即服务）的概念。

在这两个概念出现并逐渐传播的时间里，国外软件厂商就陆续发布出低代码或零代码开发平台，探索并证明了这类产品成功的可能性。基于外国的成功初探，中国市场也掀起了“低代码/零代码”的热潮，并在近两年逐步形成完整的产品生态体系。

具体我们可以看下低代码概念衍生的历程！

什么是低代码

首先看一下百度百科对低代码的定义：

低代码开发平台（LCDP）是无需编码（0代码）或通过少量代码就可以快速生成应用程序的开发平台。通过可视化进行应用程序开发的方法（参考可视编程语言），使具有不同经验水平的开发人员可以通过图形化的用户界面，使用拖拽组件和模型驱动的逻辑来创建网页和移动应用程序。 [1] 低代码开发平台（LCDP）的正式名称直到2014年6月才正式确定，整个低代码开发领域却可以追溯到更早前第四代编程语言和快速应用开发工具。

百度百科

其次看下Wikipedia对于低代码定义：

从Wiki的这段定义中，我们可以提炼出几个关键信息：

• 低代码开发平台（LCDP）本身也是一种软件，它为开发者提供了一个创建应用软件的开发环境。看到“开发环境”几个字是不是很亲切？对于程序员而言，低代码开发平台的性质与IDEA、VS等代码IDE（集成开发环境）几乎一样，都是服务于开发者的生产力工具。

• 与传统代码IDE不同的是，低代码开发平台提供的是更高维和易用的可视化IDE。大多数情况下，开发者并不需要使用传统的手写代码方式进行编程，而是可以通过图形化拖拽、参数配置等更高效的方式完成开发工作。

按维基百科的说法，低代码这个称呼是 Forrester 在 2014 年提出的，指那些用可视化方式创建应用的平台，特点是代码量比传统开发少得多，甚至无代码，所以能显著提升开发效率。

这个定义比较模糊，使得低代码平台有各种各样的形式，我见到的就有以下几种：

1. 在线 IDE 和编辑器，界面方面虽然有可视化设计，但需要二次开发才能用。
2. 提供一站式开发平台，提供了持续集成、部署和运维等功能，包含开发全流程。
3. 简化前端开发，界面方面可以做到不用写 JavaScript。
4. 简化后端开发，可以在线设计数据结构，并实现增删改查功能。
5. 彻底简化前后端开发，甚至变成无代码平台，什么都可视化编辑，易用性好，但牺牲了灵活性，这里面有很多子分类，比如 BPM、OA 系统、APP 开发等。
6. 围绕某个成熟产品扩展功能，比如 CRM、ERP 之类的SaaS产品，为了满足定制需求，提供定制开发功能。

低代码应用场景

低代码作为软件开发工具之一，可覆盖制造业、金融、医疗、房地产、零售、餐饮、航空等众多行业的不同应用场景，但 根据场景类型和复杂程度大致可以划分为4类应用，分别是通用型业务场景、企业综合型管理系统、企业个性化场景应用 和中小企业细分应用场景。通用型场景相对其他场景通常行业属性较低，可以实现跨领域、跨企业应用，满足企业共性场 景需求。综合型管理系统通常用于中大型企业整个内部管理，属于企业级应用，场景相对复杂。通常会根据企业需求并利 用低代码平台提供定制化解决方案。企业个性化应用区别于综合型管理系统，可服务于各类型企业的个性化需求场景，并根据企业类型和行业属性的不同有所侧重。中小企业细分应用场景在低代码应用热度中后劲很足，或将成为行业应用中的 热门场景。

低代码在不同企业中模块的覆盖率不同。中小企业由于应用复杂度低、业务流程相对简单等原因，95%的应用场景均可用低代码来完成。且低代码产品灵活性高，便于企业应用功能拓展，能适应中小型企业快速发展中频繁的功能迭代需求，让 创新更快落地。中大型企业中低代码目前可覆盖70%的应用场景，中大型企业通常需要建立新系统时与企业原系统进行信息联通，或是对原有系统进行二次开发，其中的逻辑设计和结构较为复杂。低代码有大量场景应用模块和行业插件，可以帮助中大型企业进行个性化应用的搭建，打通企业内部数据连接。音视频、即时通信等垂直领域，在低代码搭建应用的基 础上还需要其他插件进行功能补充，目前在垂直应用场景照片那个低代码的功能可覆盖约50%。

低代码平台驱动模式

低代码平台主要有表单驱动和模型驱动两种模式

表单驱动

表单驱动是传统BPM的典型标志，为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

低代码平台主要实现工作过程管理的自动化、智能化和整合化。最主要的特征就是可以灵便的实现数据整合和数据统计，消除信息孤岛;低代码虽然看起来操作模式像BMP，实际上基于流程进行驱动的数据、数据格式、数据来源已经发生了根本变化。BPM是典型的表单驱动只能做企业内部工作流，而基于aPaaS的后端模式与MADP前端模式加上BPM，三者结合形成了低代码的一种展现，即是通过模型驱动进行实现。

模型驱动

模型驱动使用可视化建模技术来定义数据关系、流程逻辑和构建用户界面，使开发人员和业务用户能够快速交付应用程序，而不需要代码。

模型驱动的具体优势包括:

1. 通过去掉重新生成、重新构建、重新测试和重新部署步骤，可以更快地执行功能更改
2. 访问平台中的API层，以便使用自定义代码轻松控制模型扩展
3. 通过启动运行服务器并添加模型，可以轻松地进行部署
4. 使用更灵活、更动态的应用程序监视功能，并使较少的技术开发人员能够通过可视化应用程序模型进行分析和快速调试
5. 使用更灵活、更动态的应用程序监视功能，并使较少的技术开发人员能够通过可视化应用程序模型进行分析和快速调试

使用模型驱动的平台比如OutSystems、Mendix的手册会有很大一章讲怎么做数据建模和处理，包括怎么定义实体、实体间关系、主键、唯一性、索引、数据怎么访问、筛选、分组、统计等等，还提供SQL或类似扩展。使用表单驱动的产品则往往手册第一章就是说明怎么定义各种表单，都是各种和界面相关的控件，比如单选多选下拉框、文本日期数字等。

低代码平台开发模式

目前市面上的低代码开发平台主要分为两种模式。一种是引擎式开发模式，一种是快速生成代码模式。

引擎开发模式

引擎式开发模式是目前最先进的软件快速开发方式之一，只需在开发后台进行配置，即可完成软件开发的过程，由于过程中没有生成或修改底层源码，平台可以统一维护和升级，轻松实现复杂的业务逻辑。

源码生成模式

这种模式主要通过桌面式设计器来定义业务模块，辅助生成源代码框架，然后用户可以在生成的源代码的基础上去编写、修改自己的源代码来实现业务逻辑，因此生成源码模式也可认为是一种代码生成器。这种模式对开发人员的要求比较高。

低代码开发平台价值

对开发者而言

图形化操作，容易上手；提供成熟案例模板库，不用从零开始；支持所有主流应用服务器和数据库，降低开发难度；接口丰富，节省开发时间；强大的代码调试功能，提升开发效率；

对企业而言

优化流程，提升企业运作效率;节省成本，提升企业效益;维护方便，即改即用;一键升级，方便实用;

对使用者而言

操作简单、友好 、人性化;消息驱动，合理利用工作时间;即用即改，优化完善软件功能;多客户端入口，随时随地办公;

低代码平台的诱人之处在于它可视化的开发形式，为开发者提供了不同于传统编码的界面，通过拖放式操作即可将各个字段进行部署。另外，低代码开发平台可以使用可视化建模方式来验证应用逻辑，这无论对于IT人员、还是业务人员来说，都是一种极好的交流方式。

低代码工具虽谈不上万能，但它非常强大。对于一些流程复杂的系统来说，即使低代码会存在着一些局限性，它也可以作为系统开发的补充手段，在小范围、小规模、流程简单的场景下，根据业务需求去搭建应用程序。但千万不要因此被限制了想象力，比如特斯拉仅25人花了4个月就做出一套ERP系统，就是当时的CTO Vijayan在梳理完业务流程后，用低代码平台Mendix实现的。

低代码对于企业而言，无非是提升整个数字化转型的利器，当然一切以自身的实际需求而定，业务流程管理是第一要务，技术手段仅仅是应用的呈现方式。企业数字化转型不仅仅是企业IT部门的责任，整个过程会落在每一个人头上，低代码产品给所有人提供了都能看得懂的语言，在实际执行过程中减少阻碍，加快数字化转型进度，也未尝不是一件好事。

低代码平台核心能力

低代码的平台具备的核心能力要素，我认为有四点：

• 可视化开发
• 数据模型驱动
• 扩展性
• 工程化

图片

下面针对以上四点逐一分析：

(1) 可视化开发

业务人员基于可视化的页面或工具能够进行简单拖拉拽、可以形成一个页面信息。

他们也能够基于可视化界面来配置定义数据源和数据模型、简单定义一个流程，可以执行工作流。

总而言之，就是前端拖拉拽可以形成前端的交互语言，进而生成后端可以执行的计算机语言。

(2) 数据模型驱动

低代码平台，能够可以通过页面上的操作进行定义一个模型定义，可以灵活的定义模型中的字段、也可以进行相关数据表的关联操作，以及设置数据模型的规则和索引。

a. 模型定义

进行数据库模型的设计、添加字段，设置字段的类型以及索引

b. 模型关联

建立数据库表与表之间的关系，具体表现为 1 对 n，n 对 n，n 对 1、1 对 1 等关联关系

c. 数据操作

基于数据库表对外提供一个 CRUD 的操作，让应用能够操作该数据模型

(3) 扩展性

是指低代码平台是否可以提供一些机制来进行扩展。

具体的扩展方式有以下三点：

a. 扩展语言

低代码平台是否能够我熟悉的语言来扩展，假如我是前端开发者，能否提供前端熟悉的语言来扩展，假如我是后端开发者，能否基于写一些后端代码（Java 、Go 等）来扩展。

b. 逻辑扩展

低代码平台能否通过定义一些流程图也进行业务逻辑的扩展，来执行业务 if、else 的流程来做业务上的一些调用。

c. API 集成

低代码平台是否可以通过低码平台搭建的应用与第三方公司已有的系统或者服务做集成，能否在低码中通过 API 做集成过来，供我的应用来调用集成。

(4) 工程化

低代码平台是否可以进行本地开发调试、版本控制、自动构建发布上线、免运费以及监控的一些能力。简单来说是否在该平台上一站式配套的能力。

a. 扩展语言

低代码平台要能够进行本地的开发调试。

b. 版本管理

低代码平台可以进行版本回退操作，以及有能力可以预留体验，回退体验的时候不会影响到发布态的产物。

c. 自动化

低代码平台可以自动构建发布上线、免运费以及配套监控的一站式能力。

低代码平台设计核心要点

关于低代码的设计需要关心如下4点：

1. 业务数据如何存？如何实现自定义数据存储？

需要抽象出数据模型

2. 如何实现业务流程流转？

基于工作流来进行业务流程流转。

3. 业务数据和流程流转，那些人可以访问和控制？

建立了用户权限平台，来进行人员角色的控制。

4. 如何进行服务端逻辑的自定义扩展？

通过云函数来实现后端服务的自定义扩展能力。

数据模型

数据模型基于业界标准的能力 JSONSchema 来进行扩展，数据模型分为内部数据源和外部数据源两种。

数据模型 – 内部数据源：

为我们提供数据模型定义，索引、以及各种数据模型的关系。

我们可以灵活的来自定义数据字段，以及字段的索引功能。

也能过提供标准通用的能力，比如新增、删除、查询、更新等。

连接器：

连接器可以打通外部应用数据或调用外部应用开放的服务，开发者只需要对连接器完成授权或少量填写一些配置信息，即可使用对应产品的服务接口。

自定义连接器

自定义连接器支持调用第三方服务接口或使用代码来实现业务逻辑。开发者可以在应用、工作流、自定义数据模型中使用。

分为 http 和云函数模式：

http：开放式 API，用户来链接外部的服务，与外部 API 来做集成。

云函数模式：完全自定义，当用户以上所有的场景均不能满足的时候，可以通过云函数的来手动写一些代码来自定义一些逻辑，实现业务上的逻辑扩展。

工作流

工作流基于业界标准 bpmn 协议来扩展，数据展示和存储基于标准 JSON 来处理可读性更高。

市场上比较有名的开源流程引擎有osworkflow、jbpm、activiti、flowable、camunda。其中：Jbpm4、Activiti、Flowable、camunda四个框架同宗同源，祖先都是Jbpm4，开发者只要用过其中一个框架，基本上就会用其它三个，目前比较流行可以推荐使用的flowable、camunda。

flowable、camunda都是源于美国的一些审批模式，对于国内的一些审批模式支持不太友好，需要进行定制开发，比如会签、或签、转签、任意流程跳转等。

角色权限

角色权限整体遵循 RBAC 模型来进行设计的，业务上可灵活的支持扩展。具体用户能够访问哪些页面、数据源、以及流程权限等，同时也需要支持设置一些权限集，以便于灵活地进行业务上权限的扩展。

服务端扩展

服务端的扩展基于云函数(serverless)的能力，通过页面可视化编写代码来进行服务端逻辑的扩展。可以做一些数据表的聚合，以及 CRUD 等操作方法。

目前各大云厂商都提供了相应的serverless支持，包括AWS的Lambda、Google Cloud Function、Azure Function，可以充分借助云的力量实现对服务端的扩展。

低代码平台常见问题汇总

低代码和无代码是两回事

区分这个概念其实很简单，一个需要写代码，一个不需要写代码，其实国内目前对于这个概念比较混乱。

无代码和低代码完全不同：无代码面向业务人员，低代码面向开发人员；无代码泛指多种开发细分领域应用的工具，低代码特指一种通用开发工具；无代码不被国际头部分析机构认可，低代码被广泛认可。

无代码这个词通常用来形容一些细分领域的开发工具，最常见的是应用搭建平台（国外一般叫App Builder之类），如国外的Appy Pie、国内的宜搭、简道云等，还可以用来形容Airtable / AppSheet / Treelab这类在线表单工具或轻流这类的工作流工具。

对于低代码无论是Gartner还是Forrester都已经开始给出比较清晰的筛选标准，如要支持通用场景（如UI、逻辑和数据三层都要有）、要满足专业开发需求等，随着行业发展标准化程度肯定会进一步提高。

低代码不是一个想吸引业务用户的用语，业务人员见了“代码”两个字就吓跑了，再低也没用，如果业务人员写不了100行代码的话，那10行也一样写不了。无代码的“通用”开发平台，目前看并不存在，据我看将来也不会存在。因为开发软件必然要编写逻辑，就必然要写代码，除非哪一天人工智能可以做到自动写代码。

低代码真的是新瓶装旧酒吗

关于低代码的出现，业内其实也有一些争论，认为低代码是新瓶装旧酒，关说二十年多年前的Delphi、PowerBuiler（后称PB）早就是低代码，但早就被时代淘汰了，今天的低代码也没戏。

个人曾经在大学期间也用过VB可视化编程，也看到了一些低代码的影子，但和今天的低代码还是有很大的区别的。个人认为主要是因为时代变了，这些可视化编程没跟上。互联网时代来了后，软件架构很快就从桌面端的C / S变成Web端的B / S，再后来是移动App。Web应用和App对前后端的要求比桌面应用都要高很多，因为大家做网页或App都是要吸引用户主动来访问啊，不像桌面端的企业应用就算不好用你为了工作也得用。互联网的这二十年，技术栈发展的越来越复杂，新的低代码技术只能一直慢慢酝酿。

但OutSystems等厂商经过十多年的积累，今天的低代码技术已经远胜当年的Delphi和PB。今天的低代码要“低”得多，当年的Delph、PB等如果按今天的标准，连入门的资格都没有。

低代码能开发复杂的企业应用吗

这个问题其实一直也是一个争论的焦点，低代码到底适不适合开发复杂的企业应用。业内很多人士认为低代码只可以开发简单的工作流和表单流转的应用，不适合开发复杂逻辑的核心业务。

企业应用的复杂主要是领域模型和业务流程比较复杂，低代码平台在建模和逻辑方面的能力都是比较全面的，再通过脚本语言、开放集成等扩展机制，对于不方便低代码实现的地方，可以和专业代码开发协作实现，而且企业应用不存在高并发、智能算法之类场景，这恰恰是低代码平台的优势所在，所以用低代码开发复杂企业应用，本质上没问题，个人认为没有技术解决不了的复杂问题。

明道云CEO任向晖写过一篇《APaaS搞不定复杂的应用，是这样吗？》，把企业应用的复杂性分解为数据、权限、流程、算法、集成、报表等六个维度，然后逐一给出解决方案。这才是实事求是的态度。我觉得任总的分析已经比较充分，我也不再展开说了。我相信任何人但凡不带偏见，深入分析的，都会发现企业应用并没有什么复杂性是低代码一定搞不定的，我这里说的是低代码不是无代码。

OutSystems也有一些这方面的案例，做供应链、CRM、ERP的都有，国内的一些低代码平台都有对应的HR SaaS、CRM SaaS应用模板。从另外一个角度看，目前国内外知名的SaaS产品都有相应的低代码配套产品，低代码平台就是解决客户二开需求，提升交付效率、降低成本，这也解释了为什么Saleforce、ServiceNow这样的SaaS巨头都有自己的低代码平台，而西门子会收购Mendix。

低代码不适合开发哪些类型的应用

个人认为低代码不适合以下场景：

• 对算法和复杂数据结构要求比较高的：我想不会有人想到用低代码平台去刷LeetCode题、打ACM比赛的吧。这里有个细微的地方是要区分是业务逻辑比较复杂还是算法逻辑比较复杂，业务逻辑复杂对低代码来说不是问题，算法逻辑复杂才是问题。那啥叫业务逻辑复杂呢，就是业务人员总之是说得清楚，或者是能理解的；啥叫算法逻辑复杂呢，就是业务人员只能给个目标，具体怎么实现是不管的，就算解释也是一脸闷逼听不懂的。
• 对界面要求特别高的：比如游戏或抖音、云音乐这样的社交娱乐型的应用。目前主流的低代码平台都不擅长做酷炫的界面（也有一些特定类型的低代码平台如App Onboard是面向游戏开发的，不在本文讨论范围之内）。
• 头部互联网级应用：头部互联网应用用户量巨大，为了优化性能有很多很多trick，前后台技术架构非常复杂，低代码平台的实现是比较标准的数据库 / 逻辑 / 界面三层架构，无法满足性能需求。注意这不是说所有互联网应用都不合适，只是指那些用户量特大的头部应用，比如用低代码开发一个淘宝、天猫，肯定是不现实的。
• 分析和智能化应用：分析类应用自然应该用更专业的BI工具，智能化应用也应该用更专业的机器学习平台等工具。
• 系统软件、科学计算等其他专业性很强的应用。这个不多说了，估计也没谁想用低代码来做，但多说一句，虽然这些系统的内核肯定不适合低代码开发，但界面可是很适合，我们轻舟低代码产品正是脱胎于云计算平台的界面开发。

低代码不是银弹，不要过度神化

说低代码很适合开发典型的企业应用，优点明显，如开发人员上手快、开发效率高、增进沟通和集成等，但也不要认为低代码是银弹，用了什么问题都解决了。原因主要有以下三个方面。

• 开发工具只能解决软件研发的部分问题

作为开发工具，低代码可以加快在需求比较明确时的软件交付，也可以在大方向比较明确但具体需求不明时加快软件的迭代更新。但企业应用和企业的经营管理方式、业务方向、业务流程、组织架构密切相关，和人密切相关，这些方面如果有问题，软件都不知道怎么做，这都不是开发工具所能解决，该请咨询还是得请咨询。低代码就像特种兵，单兵作战能力是强，但如果将帅不行，战略战术拉垮，也打不了胜战。

• 低代码能提升多少开发效率缺乏权威数据，不要有太高预期

业界有很多对低代码开发效率的宣传，最多的是说什么提升10倍啦，这些一看就是胡扯。一些厂商和分析机构会发布提效数据，看似效果特别好，但因为前面说的无代码和低代码没分清问题，这些数据不可信。

比如阿里“宜搭”的数据说平均将应用开发成本从17.5人天提高到3.5人天，提效500%，但前面说过“宜搭”是无代码工具。无代码工具因为都是面向特定类型的应用高度优化的，提效明显很正常的，但不通用。

专业的低代码厂商如OutSystems、Mendix，反而不敢宣传提效多少倍，所以一个厂商宣传的效果越好，就越不可能是专业的低代码平台。个人觉得用低代码做一些小系统确实挺快，但上了规模后还能是不是有数倍提升，我觉得也不大可能，提升1到2倍是一个比较合理的预期。

• 行业典型的项目制限制了低代码的价值

低代码平台因为可视化、效率高，最适合业务和开发密切沟通合作，快速迭代。但当前甲乙方之间典型的项目制要求双方提前签订详细的合同和SOW，这就把本来可以敏捷开发的生生打回到瀑布模式，这样低代码快速迭代的价值就很难体现。项目制存在太久，不是一时半会改的了的。

低代码会让程序员失业吗

这个问题的答案是NO,个人认为低代码解决的是可抽象的，通用的且可复用的产品能力，程序员作为高级技术人才，是低代码平台的缔造者，低代码工具是将程序员从现有的重复的枯燥的接口开发中解放出来。程序员应该更关注业务创造方面的技术研究和开发。低代码是工具，低代码与程序员之间的关系就像翻译软件与译者，数据统计系统与数据分析师，工具的目的是减少重复的劳作而将人力投入更有意义、有价值的研究之中。技术不应该掌握在少数人手里，普通人不应该因为不会写代码，而失去在IT时代创新的权利。

低代码平台未来发展趋势

深扎平台完整度和自定义能力，提升产品易用性和灵活度

低代码平台是在各种组件和模块实现无代码化的基础上发展起来的，早期是数据库管理、报表管理等单点能力突破。随着 产品架构的设计能力和落地能力提升，低代码由组件的无代码化向平台形式转变。未来随着引擎种类和交付模块数量的增 加，低代码平台将会覆盖更多应用场景，实现更大范围的业务价值。除了集成性以外，产品的自定义能力也将是低代码厂 商未来重点关注的方向，在众多个性化和细分行业应用场景中，产品的灵活度和可拓展性是客户主要考虑因素之一。因此， 低代码厂商将更加关注低代码平台的完整度和自定义能力，提升低代码产品的易用性和灵活度。

产品由组件向平台化演进，嫁接高阶能力提供一体化服务

之前，低代码更多作为工具帮助研发人员降低软件开发过程中部分模块的可复用性，随着可复用性模块增加和云计算、微 服务架构等技术的发展，通过平台架构设计和引擎的开发逐渐抽象出低代码平台。目前，随着RPA、AI技术能力的应用普 及，将会有更多的泛自动化、智能化能力赋能到企业应用中。RPA可以帮助业务开发人员实现重复工作的替代，未来甚至 会有数字员工更多可以完成的工作。AI能力则可以提供ocr、nlp等工具辅助平台使用者进行商业决策，实现为客户提供一 体化服务的能力。

通用型平台竞争大于垂直场景，产业链生态强者恒强

在低代码市场发展早期，厂商类型多样化，传统软件厂商、SaaS厂商、云厂商等纷纷涉足低代码领域，希望借助低代码平 台完成对内和对外的高效开发。早期低代码平台依然依赖于服务，规模化效应较低，拓客速度相对较慢。通用型厂商相对 垂直型厂商应用场景更加广泛，因此厂商数量更多。但随着市场的孕育和成熟，通用型厂商竞争加剧，垂直型厂商在细分 领域的优势渐显，可以进一步深挖用户场景并不断提升客户满意度。在市场成熟期，用户对低代码厂商依赖度高，品牌效 应明显，前期知名度高、产品能力强的通用型厂商会跑出优势局面，市场集中度将会大幅提升。因此，及早布局低代码产 业链生态，多维度拓展厂商优势，才能在将来竞争中占据高地。

参考文献：

01：艾瑞咨询[低代码行业研究报告-2021]

02: 低代码是什么？有什么优势

03: 低代码平台开发应用场景和常见用例

04: 万字长文讲透低代码