写在前面：

“无代码运动”是几千年以来驱动技术创新的核心原则的演变：

不断对以前仅一小部分人可用的过程工具或介质进行公民化拓展

并通过此倍增人类创造的潜力。

各个领域的公民化运动

在印刷机问世之前，批量生产书籍的唯一方法是手工制作，这使得传播信息和知识不仅很慢而且昂贵。一本羊皮纸的《圣经》在中世纪可是土豪才能拥有的资产，相当于一座葡萄园的价格。

书籍如此昂贵，你还会为中世纪大部分人是文盲而感到惊奇吗？

然而1440年印刷机的发明，以崭新的方式让大规模生产和发行成为可能。现如今，如果你想让文字发布到世界各地，只需要敲击几下键盘即可。

随着这些基础技术的公民化普及，世界范围内的出版数量与日俱增

（200年间每100万人中新书的出版数量增长）

同样的事情也发生在音乐和电影领域，技术及技术的使用方式对人的创作产生了巨大印象。过去我们需要专业的录音棚以及价格昂贵的录制设备才能进行相关创作。

如今更多的数字化分发渠道、线上流量的剧增、自媒体平台的兴起（BiliBili、抖音、youtube等）以及公民化设备的技术跃迁（移动手机的摄像头质量在过去几年有了大幅度提升）让人们可以在没有太多前期资源的情况下以自己的想法创作。

在B站，每天有10W条视频被发布，而在youtube上，每天上传的内容可以连续播放80年。

这里面90%的内容都是通过手机拍摄的。————《影视飓风》

更低成本、更多渠道的媒体技术使用让这个时代成为了创造力爆棚的时代

人们使用某种媒介的机会越多，我们越容易获得这种机会、创造力、产出和创新。

那么在“软件设计开发”这个领域，历史会重演吗？

软件研发的历史

回答前面的这个问题之前，让我们先回顾一下软件工程的大致发展历程：

1、汇编时代（1946 年—1953 年）

“远古时代”的软件是通过机器语言编写的，机器语言是内置在计算机电路中的指令，由 0 和 1 组成（二进制数字）。因此，只有少数专业人员能够为计算机编写程序。

2、高级程序语言时期（1954 年—1964 年）

该阶段软件开始使用高级语言（与之对应机器语言和汇编语言被称为低级语言）编写，高级语言的指令形式类似于自然语言和数学语言，不仅容易学习，方便编程，一定程度上提高了程序的可读性。

在这个时期，进行软件编写工作的人开始被称为：“程序员”。

3、结构化程序理论设计阶段（1965 年—1970 年）

该阶段处于结构化程序设计理论，伴随着的是处理器的运算速度大幅度的提高。因此需要编写一种程序，使所有计算机资源处于计算机的控制中，这种程序就是操作系统。数据库管理系统 DBMS（Database Management System）也是在这一时期出现的。

1968 年，北大西洋公约组织的计算机科学家在联邦德国召开国际会议并正式提出了：“软件工程”这个名词。

4、结构化程序时代（1971 年—1989 年）

这个阶段标志性的事件有：C语言的面世、Macintosh 机的可视化图形界面彻底改变了人机交互的方式、Pascal 及Modula-2 等基于结构化规则设计的语言面世。在这个时期，更多用途的软件逐渐面世，例如文字处理、电子制表、数据库管理软件等。

5、大发展阶段（1990 年—至今）

万维网（World Wide Web）的出现开启了万物互联的时代；面向对象的程序设计逐步代替了结构化程序设计，成为最流行的程序设计技术。这个时期，Microsoft 公司的崛起让软件工程进入到了大发展阶段。

开发模式的大升级下依然存在的问题

完善的系统软件、丰富的系统开发工具、商品化应用程序大量出现以及通信技术和计算机网络的飞速发展，不断降低了软件研发的门槛和成本。

从国内的研发生态角度看这个趋势，最具影响力的事件则是2018年微信小程序提出了“云开发”这个理念。“云开发”让前端工程师从前到后完成业务开发的闭环。“云开发”将“DB优化”、“弹性扩容”、“攻击防护”、“灾备处理”等进行了封装，让程序员可以专注于业务实现，这是一种开发模式的大升级。

即便如此，计算机、软件工程的门槛依然存在，对于大部分人来说是一项难以置信的专业任务。软件工程极高的壁垒所带来的问题包含但不限于以下几项：

• 问题1：生产模式在没有本质改变——高居不下的边际成本
• 问题2：需求增长速度与生产消化速度之间的矛盾
• 问题3：需求方与生产方之间难以逾越的沟通壁垒
• 问题4: 阶段性的信息化所带来的数据孤岛问题难以避免

问题1：生产模式在没有本质改变——高居不下的边际成本

虽然软件行业一直在高速发展，但是不得不承认，其标准化程度还是非常低的，低标准化的作业所带来的后果往往是：

• 更高的成本
• 更高的风险（不确定性）
• 更低的效率

软件研发的成本不仅仅是在一期交付上，也体现在后续不断地迭代成本上。需求的增删改导致研发的边际成本非常之高。项目复杂度与日俱增，随之而来的是需求变更的成本也呈指数级地上升。

高壁垒同时也带来了高风险（不确定性）。不少的企业级软件项目在多年的迭代维护后往往面临“举步维艰”的地步：代码维护的压力越来越大、关键的研发岗位经不起人员变动（在一些关键项目节点，研发人员的流失往往造成项目暂停甚至终止）。

追溯上述这些现象，我们很清楚的看到高居不下的边际成本往往发生在研发环节，而无代码平台则很好的将这个复杂度进行了前置。

可视化编辑器让让业务人员可以直接参与到系统搭建的过程中，从根本上降低了研发环节的成本及风险。更高的易用性同时也带了更高的可维护性，业务人员在不知不觉中参与到系统的全生命周期维护中。

问题2：需求增长速度与生产消化速度之间的矛盾

软件研发行业是高速发展，其根本原因是需求增长在各个阶段都要高于供给增长；通过微观经济学所提出的需求供给曲线我们可以看到，这种情况所导致的是行业整体定价的上升。（这也解释了为何互联网软件企业在全球最高市值的企业中占比如此之高。）

今年的疫情悄悄地改变了世界运作的规律，其中的一个趋势则是企业对于管理软件的需求剧增。需求的剧增推动了云计算相关行业的发展，但这过程中同样面临一个问题，已有的企业服务生态并不具备满足这些需求的能力。

在已有的生产模式下，这个差距将会越来越大。专业的评估机构gartner指出：2021年应用开发需求的增长，将超过企业IT交付能力的5倍。

无代码平台通过封装颗粒度合宜的乐高化模块来减少系统落地所需要耗费的时间，效率提升达到了10数倍之多。

问题3：需求方与生产方之间难以逾越的沟通壁垒

对于从业人员来说，以下观点几乎成为了共识：大部分的项目烂尾问题集中在各类协同人员的协作沟通问题上。

业务不懂技术、技术不理解业务，似乎成为了行业普遍的现象。不同职能有各自术语库和关注点，导致沟通中经常出现信息不对齐的问题。

为了尽可能好地解决（严格意义上说来应该是“适应”）上述这些问题，各种各样的团队提出了各个角度的解决方案（主要偏向于方法论）：

• 敏捷研发：快迭代、小版本的模式降低高边际成本所带来的风险；
• MVP：最小化的可行产品，在最小的范围测试客户群痛点，降低前期的验证成本；
• DevOps：通过促进开发、技术运营和质保部门之间的沟通、协作与整合从而提升开发效率的概念；
• ······

方法论及理念只能部分解决问题，核心的问题依然存在。如今，我们依然需要更好的解决方案、更快的迭代及反馈。

研发人员对于业务理解的不全面不深刻还会导致另外一个隐形但同样致命的问题——系统的可维护性问题。在没有全局理解的情况下设计的系统架构缺陷往往随着时间暴露无遗，业务的复杂度提升让系统近乎于无法拓展。长时间的使用使得系统迁移成本巨大，升级不得、换系统也不得————动弹不得；老旧系统低下的效率跟不上业务增长的问题还催生了一个很尴尬的领域：RPA。

传统意义上的RPA通过对系统页面元素的捕捉，使用脚本处理大量繁琐低效的系统操作从而提升用户的操作效率，其解决的本质问题是老旧系统设计跟不上需求变化的问题。

无代码平台极高的易用性，则是让业务人员从需求方转变为了生产方，自己设计自己落地成为了可能。完美诠释了什么叫：你行你上啊～

问题4: 阶段性的信息化所带来的数据孤岛问题难以避免

大部分的企业主认为将数据从线下转变为线上就解决了信息化的问题，但是没想到不同系统间数据无法互通却大大地限制了信息化的威力。

为了降低风险和并发成本，企业的信息化往往是阶段性，每个阶段的需求不一会影响采购决策，这往往演变成一个企业多套系统。系统的新旧程度不一样导致数据打通困难且成本高昂。

无代码平台的产品架构设计则恰恰解决了这个问题：

1、天然具备的“连接”属性可以对多个系统进行打通

2、不同阶段的业务需求可以直接通过无代码平台进行落地，系统从设计之初就可以纳入已有的系统生态中，完全不需要考虑数据孤岛的问题。

软件研发的公民化运动

在《人月神话》中，Brooks博士认为软件工程所要解决的任务分为两个：

主要任务 ：打造构成抽象软件实体的复杂概念结构

短短一句话中充满了复杂的定义，简单来说就是将抽象需求进行具象化地整理。产品经理每天的工作就是围绕这个“任务”展开的。

在《用户体验要素》这本书中，作者Garrett将这个命题进行了分解，通过5大要素及1个简洁的工作流清晰地讲解将抽象需求整合成具象模型的方法。（配图五大要素）

次要任务 ： 使用编程语言表达这些抽象实体映射成机器语言

紧接着的次要任务则不难理解了，根本目的则是主要任务所产出的具象化模型映射成为机器能够理解的语言。上文中我们提到的软件工程的历史则是“如何更好地解决次要任务”的历史。

而如今的无代码/低代码产品则是在新的时代背景下对于“次要任务”的新的解答，其核心是解决了两个任务关键节点之间的根本脱节。

更高模块化的场景中，无代码产品具备极高的可用性。

主要任务在漫长的历史上产生了极大的变化，例如toC和toB场景下的软件从一开始的需求开始就是迥异的；相比较toC场景，toB场景的主要任务在漫长的时间里并没有太多本质的区别，反而某种程度上逐步提炼出了最佳实践，模块化的程度更高了，这也直接影响了2B领域无代码低代码技术的逐渐成熟。

已经存在的一些单项能力去代码化无一例外都是围绕企业服务场景的：表单、报表、流程、数据库、页面、事件……的定义能力；这些能力在各自的领域大放异彩，具备极高的可用性。

公民化运动：从“编写”到“创建”

上世纪60年代，软件的编写者自身往往是使用者，几经波折，我们几乎迎来了“软件的使用者是设计者自身”的时代：

如果你需要一个个人网站，webflow（2017）可以满足你：

如果你需要一个业务数据库，airtable可以满足你：

如果你需要报表，PowerBI 可以满足你：

使用zapier，你可以生成一个工作流，并且串联多个系统：

在从前，当你有一些创意一些想法的时候，往往需要大量的准备和投入才能实现，过程中的内容一个环节都可能导致失败。

但如今，当你准备好的时候，一个个成熟的无代码平台也都准备好随时听候差遣了。软件消费者和软件生产者之间的界限越来越模糊，某种意义上来说我们正在经历一场变革。

无代码平台 —— 敏捷型企业信息化的最佳选择

敏捷型企业的优势

斯坦利•麦克里斯特尔在他的著作《赋能》中提到如今的世界环境从复杂逐渐转变为错综复杂。面对这样的不确定性，企业调整策略相应变化的能力受到了前所未有的挑战。

没有人会想到2020年的疫情一己之力改变了世界的轨迹，面对疫情的冲击，无代码平台“快速调整”的特性很好的支撑了突如其来的信息化需求。

上海中小企业服务网通过轻流的无代码平台2天完成口罩发放系统的搭建，在疫情防控最关键的日子里跑赢了时间。

在往后日趋复杂和多变的大环境下， 拥有更灵活响应变化能力的新型系统开发模式将会逐渐成为主流，这是历史的选择。

那么哪些类型的业务场景和企业在现阶段更适合使用无代码平台呢？

集成型业务：一个平台、多套系统

当你的企业有多个场景需要使用系统进行管理时，无代码平台天然的集成性可以很好的满足需求。更高的可拓展性可以直接在平台基础上部署多个场景的系统；不仅如此，通过基础板块“连接能力”可以对已有的其他系统进行数据打通。

成长型业务：快速响应业务变化

处于高速发展的企业在管理、业务、协作等各个维度都日新月异；能够响应环境的变化快速做出调整是新的时代背景下企业很重要的能力之一。

而传统业务系统的交付模式很难在第一时间响应这样的快速变化。但是通过无代码所带的效率跃升，企业可以在极短的时间内落地场景解决方案。

长尾型业务：满足非标准化需求

标准化的产品往往集中在使用量最大的业务场景里，比如销售管理、库存管理、项目管理、客户管理等等，占据了80%左右的企业应用市场；但是在企业管理中我们经常会遇到各种大大小小的特殊业务场景，例如智能制造场景中的TPM设备管理、CI合理化建议、andon快速响应系统……

由于它们标准化程度低、需求特殊且种类繁多，很难在市场上找到一款标准产品，这个时候每个企业基于自身熟悉的模式使用无代码平台即可快速实现信息化。

无代码和低代码存在本质上的区别

下面这个表格比较清晰的表述了两者之间的差异，其核心关键点在目标用户受众的差异。

低代码平台的出现其核心出发点是为了提升研发人员在2B业务中交付项目的效率，其手段是将一些重复使用的模块封装成“轮子”进行服用。

而无代码平台则更多地是为赋能业务人员直接进行企业管理需求落地而设计的。其手段是将“系统研发”封装成业务人员能够理解的自定义配置能力。让业务人员能够逃离代码的“牢笼”直接进行业务系统落地。面向用户的画像不同也直接导致了产品设计关注点的差异，无代码平台在考量系统搭建灵活度、健壮度的同时更加关注其易用性。

无代码的出现，这中间至少有两层价值：

• 价值一：解放研发人员的工具属性
• 价值二：赋能业务人员的创造属性

无代码平台让更多人更聪明地工作而非更辛苦的工作。

轻流的无代码框架介绍

无代码平台目前已经具备了极高的可用性。而轻流则是这中间产品矩阵完备，兼具健壮性和易用性的代表之一。

展现层（界面引擎）

轻流提供了丰富的页面框架及样式自定义能力，通过可视化的图形配置界面，减免了大量JS/CSS/HTML的代码。

• 多种业务组件
• 多端适配运行良好
• 访问权限控制（连接企业内外）

业务层（流程引擎、表单引擎、报表引擎、事件引擎）

通过业务人员最熟悉的表单界面为载体承载大量前端自定义事件。解决了大量业务逻辑问题，无代码的流程引擎支持串联自动化事件，我们称之为Q-Robot，帮助业务人员解放双手。

• 表单构建、前后端计算能力
• 流程模型可视化搭建
• 业务所需的报表构建
• 丰富的事件拓展、支持跨系统执行

模型层（数据库引擎）

高度封装的连接模块，简单地配置即可进行跨系统的数据连接，将ERP、CRM中的数据进行调用和同步，消灭数据孤岛，为遗留系统提供现代化的可能。

• 可视化的数据库建立、
• 支持业务所需的增删改查功能
• 基于权限角色分配数据权限

整合层（连接引擎）

高度封装的连接模块，简单地配置即可进行跨系统的数据连接，将ERP、CRM中的数据进行调用和同步，消灭数据孤岛，为遗留系统提供现代化的可能。

• Q-Source数据源自定义
• Q-Linker跨系统数据关联
• Q-Reminder 跨系统提醒推送
• Q-Authentication鉴权自定义
• SSO单点登录、webhook、openAPI

面向不同受众（用户画像）的无代码平台，设计出发点也是不同的。

• 从业务出发：表单交互模型入手（面向业务人员） —— 轻流的选择
• 从技术出发：数据库模型入手（面向技术人员）

轻流的产品设计初衷并非是要替代程序员原本的工作，就如前面我们讲到的 “对以前仅一小部分人可用的过程工具或介质进行公民化拓展，并通过此倍增人类创造的潜力 ” ，这才是轻流真正的目的。

（Give people wonderful tools and they'll do wonderful things————苹果对于上面这句话的理解）

基于这样一个愿景，我们眼下最重要要解决的则是“如何让业务人员可以尽可能快的体验到“亲手创造”业务系统的自在和快乐”这个问题。“易用性”的重要性在这个背景下被放大了。

与此同时，易用性和健壮度的对立统一则成了我们所面对最棘手的难题。我们在不断摸索中，也开始找到一些方法，后续慢慢会跟大家分享我们的思考。

让我们来聊聊破坏性创新

今年初去世的 克里斯坦森 毕生最伟大的著作《创新者的窘境》中提到一概念叫：破坏性创新。

这个理念深深影响了苹果、微软等巨头企业；书中所描述的“以下犯上”在整个商业史上比比皆是：个人计算机对于计算机市场的颠覆、小容量编写硬盘对大型企业级硬盘的颠覆……

甚至到如今，我们的身边所充斥着那些我们无法忽视的趋势：移动端计算平台的崛起、计算能力主导的影像系统、新能源汽车……每天都在为我们演示破坏性的创新如果通过“猥琐”的发育逐渐成为主流需求而改变历史轨迹。

近些年，在2B企业级市场，我们看到具备破坏性创新特点的模式或产品不断涌现：云计算、SaaS化……

我们认为无代码平台也是这个信息化浪潮中的一员。

一些无法忽视的趋势

“到2024年，无代码/低代码应用程序开发将占应用程序开发活动的65％以上。”

————Gartner预测

今年10月，大洋彼岸的北美，一个新的无代码独角兽悄悄地崛起——unqork宣布已完成20700万美元的C轮融资，估值为20亿美元。总融资达3.5亿美元。稍早一些的9月14日，业务数据库自定义工具Airtable宣布以26亿美元的估值募集了1.85亿美元的D轮融资，这个估值比2018年底的11亿美元又翻了一番还多。而轻流在疫情这样一个特殊时期下，也获得了来自源码资本领投的数千万A轮融资。

在最新发布的远景目标中提到在2035年之前基本完成信息化，建成现代化经济体系。中国拥有超过3000万的企业数量，在这个大浪潮中，大量的信息化诉求等待消化，而如何提升生产效率则是核心诉求之一。

很多人都觉得如今的无代码平台“噱头大于实际”、“更像是玩具”、“可用性还比较低”。对于从业的我们来说，我们也不否认通过“无代码平台”完全替代现有企业及软件交付模式在现阶段还不是很切实际。

不过在这样一个积累即是壁垒的赛道，明天总归是充满光明的~