白码低代码开发平台
普通程序员使用白码低代码平台即可变成高级程序员！点击右方“点击测试”马上使用吧！
免费试用
低代码是一种语言或环境，可以帮助那些缺乏编码经验的人创建和开发软件。低代码使用复杂的可视化模板和拖放框架，而不是复杂的后端代码和库，从而向非软件开发人员开放了开发功能。你知道低代码平台在什么情况下适用吗？下面一起来了解一下相关的知识吧！
什么是低代码平台：
低代码平台允许非技术人员无需IT参与即可创建自己的应用程序，而几乎不需要编程知识。通过使用图形用户界面，拖放模块和其他用户友好的结构，非程序员可以根据自己的特殊需求创建自己的应用程序。这些应用程序填补了业务用户所遇到的特殊缺陷，但尚无标准解决方案。
这似乎是商界数十年来一直期待的解决方案，但重要的是对低代码方法采取正确的看法，并意识到有时低代码平台是合适的，而有时是不合适的。
低代码平台在什么情况下适用：
在以下情况下，低代码平台是理想的解决方案：
1.业务用户希望创建自己的应用程序。
2.没有同类解决方案可以解决该问题。
3.该应用程序是正常的业务用例。
这些是抽象准则，在现实世界中对业务的关注和决策的背景下进行构想是很有用的，因此这里有一些来自业务运营不同方面的示例。
首先，让我们考虑一下销售，不同公司如何生成销售发票差异很大。当然，发票需要连接到CRM系统，但通常还具有需要记录的批准链。由于没有人比销售人员更了解这些问题，因此销售团队最适合创建和设计软件驱动的销售发票管理。由于生成发票的应用程序不需要复杂，因此它们可以使用低代码平台自己创建应用程序。
第二，考虑营销。您的营销团队需要在内容审批领域中工作，需要一群不同的同事在内容上线之前进行签名。如果手动处理该过程，则很容易出现延迟和错误，因此使用软件进行自动化非常有益。但是，大多数营销团队都依赖于手工获得批准（主要是通过电子邮件），因为大多数任务管理系统都不容易以自动化的方式进行。
由于每个营销团队都有自己的流程，因此无法轻松使用现成的解决方案。相反，使用低代码开发平台，营销团队可以根据需要构建和重建批准工作流，而无需IT参与。
最后，考虑人力资源部门。员工入职是所有企业中一个极其复杂且关键任务的操作。尽管它具有普遍的重要性，但几乎不可能创建一种标准的入门方法。每个公司都有不同的要求，培训和文书工作流程。但是，雇用人员和其他人员的变动通常需要及时处理。在IT部门完成更为紧急和重要的工作时，HR当然不能等待数周。因此，人力资源团队成员可以自行更新其自动入职流程的低代码解决方案，使客户可以严格控制他们所需的产品，以快速有效地完成工作。
例如，人力资源经理可以构建该应用程序，创建一个表单来收集候选人所需的所有信息，并创建一个工作流程，该流程包括他或她将与之互动的所有部门。每个部门的人员完成相关任务后，数据将自动移至下一步，从而无需中间人，从而提高了入职效率。
低代码平台在什么情况下不起作用：
在任何组织中，您都会发现两种过程：结构化的过程和开放性更高的过程。通常严格执行的结构化流程大约占组织所有操作的三分之二，这些通常是任何公司或大型集团的“生命支持”功能，例如休假管理，出勤和采购等。
例如，杂志可能具有定义文章发布方式的明确过程，假设它是先由贡献者编写的，然后由子编辑者审阅的。然后，主编辑检查文章，然后再批准将其提交给设计团队。最后，将其交给发布者，然后客户团队处理所有必要的付款。为避免混乱，此工作流程应每周，甚至每个季度保持一致，给定清晰的结构和明显的目标，可以通过低代码解决方案很好地处理这些过程。
但是开放式流程很难定义，目标也并不总是那么清晰。想象一下举办一次活动，您可能对最终结果会有所了解，但是您无法预先定义计划过程，因为您不会一直安排这些事件。这些不确定的过程（如为异地会议制定议程）往往更加协作，随着来自多个利益相关者的投入形成空间，它们通常会有机地演化。考虑到这些类型的任务定义不明确，因此很难为使用低代码平台制定解决方案。
当然，这些非结构化的活动通常是在组织中产生最大价值的活动。因此，至关重要的是，他们要获得应有的时间和精力。通过将组织的重复、严格但必要的流程卸载到由内部人员制定的低代码解决方案上，您可以腾出所有人员来寻求创新的解决方案，以推动变革性的创新。
使用低代码开发平台时需要遵循的原则：
1.愿意接受SaaS
在您尝试利用低代码方法的应用程序平台即服务系统之前，必须确保整个团队愿意超越传统的企业工具来利用生产力。这里，“超越”是指一般的SaaS行业，尤其是APaaS（应用程序平台即服务）。
这些在线平台显然不是在技术前沿，它们将保留并正在改变企业保持竞争力的方式。对于任何组织而言，变革都可能很难，但是那些不愿意随着技术格局的发展而变化的人将被甩在后面。因此，在进行任何操作之前，请确保您的组织愿意采用在线平台作为解决方案。如果您犹豫不决，则必须说服相关的主要利益相关者，此升级不仅是为了方便，而且在运营效率方面也将改变游戏规则。
2.消除对安全的恐惧
SaaS和云解决方案供应商都意识到，要保持竞争力，安全性必须是其主要优先事项之一。一项公开的漏洞可能意味着其组织的终结，因此，大多数SaaS产品都内置了安全功能也就不足为奇了。越来越严格的标准（例如通用数据保护法规）使SaaS产品在安全性方面比本地解决方案更加强大，IT专业人员也知道这一点。
不要让安全性出现问题或延迟采用低代码平台。确保向供应商咨询安全实践，并就这些问题进行公开坦诚的交谈。在大多数情况下，您会发现云解决方案将安全性作为其首要任务之一，从而使您的公司可以专注于在您的域中创造价值，而不必担心安全性。
3.让专业人士使用所需的工具
让专业人员使用最佳工具，而不是限制他们可以使用和不能使用的工具，就可以释放创新。因此，请利用他们的见解并赋予他们权力，而不是制定阻碍他们的政策。决定不咨询IT部门和您的技术的其他日常用户就采取行动，这是将会导致出现一系列的问题。在技术解决方案上存在一些分歧是很正常的，但有时在面对大胆的新解决方案时旷日持久的竞争会使现有问题变得更糟。
当专家可以控制自己的专业领域并且可以快速而轻松地进行更改以增强其运营时，组织将立即受益。通过采用低代码平台，公司可以使从人力资源到市场营销再到IT的每个人都能在他们最了解的领域工作，并发挥他们独特的技能和才华。
低代码平台的出现帮助企业实现了应用程序开发的自主性，让业务人员可以根据自己的需求开发出可以解决自己工作中难题的应用程序，而无需过渡依赖专业技术人员。
未经允许不得转载，或转载时需注明出处
上一篇：低代码平台的优势 下一篇：什么是零代码开发 零代码开发有哪些优点

现在市面上的很多开发工具更侧重代码编辑，针对数据库增删改查（CRUD）类的Web系统开发，在界面设计、前后端数据交互等环节主要还是靠写代码，效率比较低；而现在市面上很多所谓的低代码开发平台，大多数都是基于OA系统的工作流引擎，虽然可以自定义表单和流程，但无法实现复杂的业务需求。
所以我们团队用了一年多的时间，潜心研发了一款面向IT技术人员和程序员的低代码开发工具–TaskBuilder（中文名：任构，任务的任，构造的构），通过组件化、可视化、向导化、模板化等多种手段，可以大幅提升开发CRUD类应用的效率，开发人员不用再把大量时间浪费在界面设计、数据绑定等一些没有技术含量的工作上，可以有更多的时间专注实现用户具体的业务逻辑需求。上线一个月，就得到了广大用户的好评，大家的认可是我们前进的动力，更是我们永恒的追求，我们定将持续优化产品，继续为大家提供最真诚、最贴心的、最满意的服务。下面来看看TaskBuilder都有哪些核心功能吧。
基础功能组件化
TaskBuilder 将常用的功能封装成了组件，包括前端UI组件、后台业务操作等，开发业务功能时，可以像搭积木一样，通过鼠标拖拽就能快速实现前端界面设计和后台功能开发。
功能设计可视化
使用 TaskBuilder 开发应用时，基本上大多数操作都可以使用图形化的工具实现，包括数据结构设计、界面设计、样式设置、业务逻辑设置等，尽量减少代码的编写。
应用创建向导化
TaskBuilder 提供了丰富的开发向导，按照向导一步一步操作，就可以快速创建增删改查应用（CRUD）。
多端适配一体化
TaskBuilder 目前已支持开发电脑端Web应用、手机端H5应用，很快会支持微信小程序。
前后端分离
使用 TaskBuilder 开发的应用，前端界面和后台服务代码不是混杂在一起、强依赖的，是彻底分开的，采用JSON格式进行数据传输，一套前端界面可以支持多种后端语言，一套服务也可以给多套界面使用，只要传输的数据格式满足要求即可。
而且，前端界面设计和前端业务逻辑代码也是分离的，易于设计和维护。简单的业务功能，通过可视化拖拽设计即可完成，如果前端有复杂的业务逻辑，可以在独立的代码编辑器内编写前端脚本，所有前端组件都封装成了JavaScript对象，在前端脚本内，可以用面向对象的形式获取或设置组件的属性，调用组件方法，处理组件事件。
应用代码中性化
使用 TaskBuilder 开发的应用，前后端的代码都可以存储为中性的JSON格式，然后可以根据需要编译为目标环境支持的代码格式。
使用 TaskBuilder 开发前端页面时，不用每个页面都自己想办法兼容各种浏览器， TaskBuilder 开发的前端页面（扩展名为.tfp）是中性的JSON格式，可以根据客户端浏览器情况在 Tasgine（任擎）服务器上统一配置具体要支持哪些浏览器以及支持到哪个版本等，用户在访问 tfp 页面时，
Tasgine（任擎）服务器会自动编译为可以兼容适配这些浏览器的代码。
使用 TaskBuilder 开发后台服务时，也可以将后台服务保存为中性的JSON格式（扩展名为.tbs），然后通过 Tasgine（任擎）服务器编译为 JavaScript、java或c#等具体的编程语言（目前仅支持编译为 JavaScript ，其他语言待开发）。

大家好，我是TT。
这篇内容我们来说一说低代码，与某种具体技术不同，对于低代码的概念，业界至今没有达成一致意见（我估计以后也不会，这是低代码被赋予的职能决定的）。
但作为低代码的接触着，甚至是架构者，我们需要对低代码平台到底是什么有一个清晰且深入的了解。这篇内容里，我会通过对低代码平台进行归类带你厘清低代码的概念，并带你分析当前低代码的发展现状，让你在脑海里建立起对低代码的直观印象。
在这里所说的内容都侧重于低代码的架构、策略和技术的实现。所以，对低代码是啥理解得越清楚，相应地，你就越容易理解我所作出的架构和策略的选择，以及为啥要采用特定的技术实现选型。反之，在概念理解有误的情况下，后续的内容有可能使你陷入目标与执行相互矛盾的困境，难以自拔。
什么是低代码？
要讲清楚一个模糊的概念，一个有效的手段就是先应该尝试对它，以及相关的概念进行归类，然后比对，从比对中得出关键差异。
但要对低代码做分类，并不容易。由于低代码概念和内涵未达成一致，业界对它进行归类的方式也多种多样。这里，我以我理解的低代码的几个重要特征作为维度，对低代码进行归类，同时你也能通过这些分析，了解我们这门课要实现的低代码平台到底是啥样的。
按代码量的维度来分类
这个维度下，App 的开发模式可以分为三种：纯代码（Pro Code）、低代码（Low Code）、无代码（No Code）。
这三者有着巨大的差别，我们需要非常准确地将它们分开。纯代码是这个维度下的一个基准概念，它指的是传统的手工编码的模式开发应用。而低代码和无代码比较容易搞混。
从中英文字面上说，无代码意味着 App 的开发过程没有代码的参与。但是这样的理解比较粗浅，为了获取更加权威的理解，我尝试从头部分析机构 Forrester 和 Gartner 所发布的报告中，查找与无代码相关的调查报告，但一无所获，不知道是不是这些头部机构并不认可无代码这个概念。
低代码模式下的 App 开发过程是需要有代码参与的，特别是面对一些复杂的业务逻辑，通过表达式或者直接编码的方式来表达，反而更加清晰。而无代码模式开发 App 的全过程，没有任何代码的参与，不仅是从开发者角度看是这样的，从无代码内部的实现方式看，也是这样的。
严格来说，把采用无代码模式生成 App 的过程称为开发是不恰当的，因为它只是对已有原子业务能力进行二次组合，形成具有特定功能的新业务而已。因此从这个角度来说，低代码和无代码完全不是一种东西，切不可将这两者混为一谈。
但有一个情况非常容易混淆低代码和无代码。当低代码的成熟度到一定高度时，在某些细分场合下也是可以实现零代码开发的。在这个情况下，从 App
开发过程的表现看，这二者差异微小，此时最容易将两者混淆。当然，我们也不排除一些低代码解决方案提供商为了夸大其低代码的效果，而故意将二者混为一谈，把无代码当做一个噱头来宣传。实际上，低代码模式要将一个场景做到零代码，难度是非常大的，并且有诸多的业务前提。
在代码量这个维度下，我们专栏所说的低代码是指这 3 个分类中的“低代码（Low Code）”这一类。
按适用范围的维度来分类
这个维度下，低代码平台可以分为专用型和通用型两种。
所谓通用，指的是开发平台不事先假设自身只能应用在特定的场景、业务、行业，而是具有广泛的适用范围。
具有这样特征的开发平台往往需要有一个通用的底座。这个底座是纯技术性的，它不依赖于特定的业务功能，而只与业界广泛使用的标准协议、技术标准产生耦合。不过，这个时候，我们只有深入平台架构实现的细节，才能判断平台到底是低代码还是无代码，这就导致平台的使用者难以甄别。（注意，我这里的目的不是想告诉你如何甄别，而是为了告诉你这里所说的低代码平台具有的特征）
但是，通用是有代价的，越通用就往往意味着在特定业务场景下的效率越低，越通用就意味着默认配置里的个性化信息越少，为形成某个具体场景所需的配置量就越大，从这个具体场景的角度看，效率相应也就越低。
所以通用型的低代码平台往往伴生着这个特征：有相对完善的有插件（或类似）机制。这一点相对来说比较好识别，相对高通用性的技术底座来说，插件是廉价的，因此通用性低代码平台往往会有数量众多的插件。这些插件可以定制出各式各样具体的业务场景，通过插件的定制化和扩展性来解决效率问题。
这个维度下，这门课所说的低代码指的是通用型开发平台，它具有一个通用性非常高的底座，和一个相对完善的插件机制。
按输出的 App 的类型来分类
其实，在一个具有较高通用适用范围的低代码平台来说，按照输出 App 类型分类几乎是没有意义的。之所以不得不按输出 App 类型分类，是因为开发平台的通用性不足，而在有了足够高的通用适用性之后，支持开发各种类型 App 的问题，就不在于能不能了，而只是时间问题。
尽管我们这门课所说的低代码指的是“通用型”这一类，但这并不影响我们看看现在业界其他低代码平台都可以输出哪些类型的 App，大概有流程驱动型、表单驱动型、模型驱动（ORM）型、BI 分析类型这几种，具体你可以看看这张表格（5 星为满分）：
这里，我主要给你区分一下表单驱动型和模型驱动型这两个类型，因为它们比较容易被混淆。
所谓模型驱动型 App，它的模型指的是数据模型，或是数据关系。而这里所说的关系，指的就是符合三范式的关系型数据库的关系，也就是你数据库中各个数据表之间的关系，比如表 1 的 a 字段和表 2 的 a 字段是相同的，但与表 3 中的 a 字段没有关系。在正确配置了各种数据关系之后（这个过程一般称为数据建模），页面上就可以很容易创建各种 CRUD 类 App 了。
表单类 App 则是仅以数据为中心，创造各种表单来收集或呈现数据。这里的关键点在于，这类 App 并不关注数据之间的关系。所以表单类的 App 非常容易形成数据孤岛，并存在大量冗余数据，以及大量数据不一致性等问题。如果我们将表单类 App 做得比较完善的话，实际上它就会逐渐转型成模型驱动类 App
了。在完成数据建模之后，我们就分不清楚它到底是模型驱动还是表单驱动了，差异只是前端是用表单展示，还是表格展示而已。
按使用者的类型来分类
如果按照使用者的类型进行分类，我们可以将开发平台的使用者分为 3 类：专业技术人员，业务技术员，相关无专业技能人员。
这里所说的业务技术员是一种正在兴起的角色，它是指构建供内部和外部业务使用的技术或分析功能的非 IT 部门员工。他们担任着装备和赋能非 IT 资源以构建数字化能力的战略角色。
根据 Gartner 的研究：41% 的员工可以被称为业务技术人员，不过这一比例在不同的行业可能存在很大的差异。例如在政府部门等技术密集度较低的行业，这一比例接近 25%，但在能源等 IT 密集型行业，这一比例接近 50%。
多数的无代码开发平台将业务技术员作为主要的用户群，为他们提供对已有业务的二次组合为主的基础开发能力，一般具有专业技能的开发人员是不会使用无代码开发平台的，因为专业技能者要面对的问题域已经大大超出了无代码平台的能力范围。
而低代码开发平台一般会将专业技术人员和业务技术员同时作为他们的客户群，并以专业技术人员为主要用户群，业务技术员为次要用户群。
随着低代码开发平台的成熟度上升，业务技术员用户群的占比会有所上升，因为成熟度高的低代码平台，不仅有各式各样的可视化工具来降低业务研发的难度和代码量，同时对业务研发生命周期各个环节的覆盖也越来越完整。从开发到测试，从测试到上线，再到高容错运行时自动化部署 / 恢复、运行时自动化运维等各个环节的可视化、自动化完成，这为无 IT
技能的业务技术员独立开发提供了可能性。同时，越发完善的可视化自动化能力不仅会牢牢抓住已有的专业技能用户，还会吸引更多的专业技能用户的加入。
这个维度下，这里所说的低代码是以专业技术人员为主要用户群的一类平台。不过，在写这篇文稿的时候，我负责的低代码平台正在努力将业务技术员纳入到它的用户群中，但是这项工作才刚起步不久，当前尚没有特别成熟的经验可以分享。但这是一个动态专栏，在未来几年会保持更新，我会在合适时机，及时把我在拓展更多用户群方面的经验分享给你。
现在我们来总结一下，这篇内容要实现的低代码平台到底是怎么样的。它是一个以专业技术人员为主要用户群的通用型低代码平台，它会有一个通用性非常高的底座，和一个相对完善的插件机制。
我这里还要再解释一下，在后续的内容中，我可能还会提到低代码工具和低代码平台，对于这两个概念，我所指的内涵是一致的，区别就在于规模和成熟度。低代码工具指代规模较小、成熟度较低的低代码实现，而低代码平台则指代规模较大、功能较完善、程度较高的低代码实现。
了解了行业内对低代码的几个分类，以及我们这门课的低代码平台的定义后，我们再来简单看看低代码的历史演进和现状，让你对低代码和低代码行业有更进一步的理解。
低代码的发展
在低代码的发展上，我们可以从基础设施的演进、时间和地域，以及中台的演进这三个方面一探究竟。
我们先从基础设施演进看低代码的发展，你可以先看看下面这张图：
长久以来，软件的基础设施都是纯物理设备，自当虚拟技术被引进，IaaS（基础设施即服务）时代就开始了。紧随着虚拟技术继续蓬勃发展，没过多久，软件技术便历经了 PaaS（平台即服务）时代、SaaS（软件即服务）时代。关于这几个概念更具体的解释，你可以看下补充材料的内容。
SaaS 类产品高度封装的软件服务为行业提供了巨大便利的同时，人们也渐渐发现这种形式的短板：定制性太弱。因此在 SaaS 的基础上，又演进出了一种被称为 aPaaS 的软件服务体系。
根据 Gartner 的说法，aPaaS 是应用程序平台即服务的缩写，它是一种云服务，可为应用程序服务提供开发和部署环境。aPaaS 平台提供的功能包括：迭代构建应用程序、即时提供应用软件、按需扩展应用程序，以及集成应用程序与其他服务。
很明显，Gartner 把这里的 a 作为 application 理解了。但我个人认为，这里的 a 当做 ability 来理解更为恰当，借用文言文的使动用法，将它翻译为赋能。因为很明显的，aPaaS 体系相比其他架构就是多出来了一个开发和部署应用程序的能力，即 aPaaS 赋予了原来的软件服务体系开发和部署的能力。
我们再换个角度，从时间和地域来看低代码的发展。
下面这张来自艾瑞咨询的图片总结了这个过程，图中信息量比较大，你可以点开仔细阅读。
我们可以从这组比对数据中明显看到，国内的低代码平台要落后于美国一个时代。现在低代码头部解决方案中已经有类似 OutSystem、Microsoft 这样的通用型低代码巨无霸，而国内多数提供商还在探索如何有效地为某个垂直行业、细分领域提供低代码服务。但这对你我这样的低代码人来说，实际上是一个好事，这仍是一片蓝海，大有可为。
第三种角度就是从中台演进来看低代码的发展。这里你可能会觉得很奇怪，为啥低代码又和中台扯到一起了呢？
这是因为，低代码可以将多个“烟囱系统”归整为一个集大成者，更灵活敏捷地创建中台架构。在传统的企业系统中，每个部门有不同的系统需求，于是会各自采购自己的系统。但这些系统彼此孤立，独立运作，导致企业采购的软件系统冗杂。而低代码平台能让绝大部分部门的业务系统都能在一个平台里搭建，彼此联系，打破信息系统孤岛，同时降本增效，提升内部生产力。
低代码有助于横向打破传统企业的烟囱系统，将它们串联到一起，这与中台的目标不约而同。此外，低代码对外赋能的职能，也是中台建设目标之一。因此中台的发展过程，有相当一部分线路与低代码是重合的，二者可以起到相互促进，良性共生的关系。所以，如果你所在的企业同时在架构中台和低代码这两者，不妨尝试将他们放到一起来考虑。
行业状态速读
了解了低代码的发展和演进之后，作为低代码的研究者，我们总得关心下当前低代码的行业现状吧？
不过，网上这方面的信息实在太多了，多数说的有鼻子有眼，但不知道真假，所以我只看专业调查机构输出的报告。其中我主要关注 Forrester 和 Gartner，以及国内的艾瑞咨询，相关的报告链接我都统一附在了文末的补充材料中。
在这么多报告里面，我首先要向你推荐的就是 Gartner 绘制的关于低代码的魔力四象限报告，关键部分就是下面这张图，概括性非常强。
作为低代码的实现者，一般看这种报告都是以竞品调研为目的的，因此我们一般只研究 Leader 象限里的提供商就可以了。Leaders 这个象限显示的是技术能力较强、对未来的规划很清晰的厂商，其产品被市场广泛认可，对我们有极强的参考价值。
其次我想向你推荐的是 Forrester 的 Forrester Wave 报告。与分析 Garter 的魔力四象限相似，我们仍以 Leader 这一波里的厂家作为我们的调研对象。与魔力四象限的结果比对，你发现了啥？
两家机构对低代码的 Leaders 给出了几乎一样的结论，对吧？在 Leaders 里，头部机构取得了一致意见。这两份报告为我们低代码平台的竞品调研给出了一个非常明确的指引，所以如果你现在还在头疼不知道如何下手做调研的话，他们就是极佳的研究和参考对象。
那么国内的厂商是啥样的状态呢？
我同样有两份报告可以推荐给你：一个来自 Forrester 的报告《The State Of Low-Code Platforms In China》（下文简称中国报告），另一个来自艾瑞咨询的《艾瑞咨询 -2021 年低代码行业研究报告》（下文简称艾瑞报告），你可以在这一讲的补充材料中找到原文。
在《中国报告》中，Forrester 第一次将视角聚焦在中国，它认为，低代码目前在国内主要应用于银行、保险、零售、医疗、政府、制造、电信和建筑行业。Forrester 认为，国内低代码目前主要集中在如下 9 个领域，分别有：
而《艾瑞报告》的信息量就更大了，主要包含了概念界定、应用场景、竞争要素、市场规模、趋势洞察四大块的内容。下图是《艾瑞报告》绘制的低代码厂商图谱，非常概要地整理出了国内外低代码厂商的分类。
大体上，《艾瑞报告》把低代码厂商分成了通用型和垂直型两种，垂直型和我前文所说的专用型是类似的，均指只能应用在某个业务领域的低代码解决方案，无法运用到其他领域。
无论你是要做竞调，还是打算采购，这个图都可以提供不错的指引。
大小厂商这么多，也从一个侧面反映了低代码在国内的发展仍处于早期的状态，按照“惯例”，风口褪去后，各个厂商会快速聚集，要么大鱼吃小鱼、要么抱团取暖，形成寡头化的局面，当前还处于“百花齐放”的状态，说明低代码仍处于投资风口，风投时不时来“奶”上一口，所以大家都还能坚持得住。
不过，这份《艾瑞报告》是 2021 年 3 月出的，有点老了。目前我和负责竞调的团队还没找到新版，一旦获得一手信息，在商业合规的前提下，我会第一时间分享给你。
举报/反馈