低代码

可视化搭建顾名思义就是使用GUI图形界面，通过拖拽元素，设置属性，编排内容的方式，自己来 DIY 出需要专业人士编码才能产出的作品。

类型

资源类型、页面类型、应用类型

设计资源型：通过一系列设置来形成理想中的资源文件，如活动海报、公众号首图等能够作用于其他地方的资源文件。大幅度提高了设计、运营的工作效率。比较典型的就是创客贴，稿定设计等平台；

页面类型: 通过预置的物料组件来灵活的搭配出我们的网页页面，保存发布后可以被其他人预览。具有通用性和业务性。大多数公司都会有自己的内容搭建系统，这是目前用处相对比较广泛的一个类型，大部分电商公司的活动页面和宣导页面都是好的实践；

应用类型: LowCode/NoCode 以编写少量代码甚至无需代码的情况下轻松的搭建一些应用或者是站点页面。与普通页面类型区别最大的点就是其拥有比较完善的工作流程和数据管理能力。拥有完善的版本控制与部署能力。

• 需求是无止境且多变的，作为技术不可能限制需求的类型；
• 不是所有的人都具备很高的逻辑思维与快速的学习能力；

如果是单纯将 Low Code 理解为“显著减少编写代码所需工作量的编程解决方案”，那么所有的高级语言其实都是一种低代码的产物，因为它们使开发不必编写大量晦涩难懂的机器代码来编写应用程序，所有的高级语言都将人与机器之间拉了更近的一步，这也是为什么越是底层的语言会比更高级的语言更难学，因为机器与人的理解是不一样的。

发展阶段

降低开发的学习成本、产品的研发成本为主要目标，并不是以是否写大量的代码来进行判断，这也是之前有段时间我感觉可以将 Low Code 改名为 Less Code 的原因。

第一阶段：直面开发的复杂交互形态

第二阶段：面向运营、产品等无技术背景的同学的简单交互形态

一个庞大而复杂的业务一定是没法通过节约代码量来完成既定的业务需求，业务复杂度不会凭空消失，只不过是将通用的复杂度通过工程化的手段转嫁到平台之中，而低代码的价值则是降低了其他团队的开发、维护、沟通与资源成本等。

MRD 产品目标与设计

无论技术方案是 No Code 还是 Less Code，目前市面大部分的低代码方案都在集中解决某个领域的问题，通用方案的实现就需要更多的方案适配与学习成本，虽然商业化的饼图确实非常大但这样无疑提高了产品设计、学习成本、推广成本，所以领域型的低代码也是技术产品与商业价值互相磨合妥协后的结果。

产品价值

成熟的业务领域可以快速地完成需求功能开发； 可视化的技术可以将低代码体系从研发的角色延伸到设计、产品、运营等角色，在项目开发初期的时候对项目就能做出一定的需求可行性分析与支持； 通过低代码生成的项目，从规范以及后续的基础模块升级等方面可以得到一定的保证； 全流程的自动化流程，减少研发成本以及提高项目质量。

商业价值

体现在商业价值中可以总结为下面 3 点：

效率：可以快速搭建基础项目，进行个性化定制，降低业务试错成本与竞争效率； 成本：从人力、机器资源等多方面缩减研发成本； 安全：规范化的流程可以保证线上的稳定性。

产品概述

市面上大部分的低代码产品都是运营、建站类型，但这些产品也有一些不足之处：

• 它们的 Pro Code 产物结构会比较复杂，臃肿的代码在性能体验上也会有所折扣，其次复杂的结构也不利于二次开发，导致产品无法保证可延续性；

• 一般这种低代码产物与自己的后端服务耦合比较多，一旦接入使用这些产品就会存在一定的业务约束

而中后台业务场景的需求量非常大但它们的布局加功能都比较固化，大部分可以基于物料 + 基础布局完成页面组装，即使存在多种不同系统之间的样式交互的略微差别，我们也可以通过主题配置的方式来兼容。

产品目标

MFF（Model For Frontend）

与常规的 Schema to View 的模式不一样，中台化产品的概念 MFF（Model For Frontend）有如下的一些特点：

无缝对接现有后端服务，尽可能减少后端业务逻辑改动，减少传统业务的改造成本； 解决业务复用能力设计、组件使用门槛问题以及减少现有组件接入成本； 减少对现有前端业务的侵入，提供 Pro Code 与 Less Code 模式，支持页面与组件级别的引入； 可以引入 AI 模型，可以针对不同的业务进行训练从而提供匹配度较高的 Schema。

C 端营销产品 C 端营销产品和大部分可视化搭建类的架构设计一样，整个系统也采用分层的设计，尽可能将责任细化。

整个系统将整个应用分为如下洋葱🧅图所示的几个模块：

最底层是搭建协议，基于标准化的协议，可以将区块、模版快速引入到当前编辑器的内容编排当中快速完成工作，也可以将定义好的页面组件保存为自定义的区块、模版后期直接一键使用； 第二层是编辑器层，这一层主要实现了根据底层协议来装填物料、页面内容编排、画布预览区域的渲染器显示； 第三层是针对编辑器的一些扩展开发，如组件平台可以管理远程的组件，资源管理可以控制编辑器设置器中的一些素材，页面管理可以对编辑器保存和发布的页面进行管理，应用服务可以将编辑器保存的数据存储起来下次再使用； 最顶层就是聚合前面几层组合的搭建平台，由于是分层设计的原因，可以在多个不同的项目中来扩展使用搭建服务。

项目骨架 整体的项目骨架先总结一下，后面在实现时会在单章中分别深入解释对应的作用与实现过程:

组件与功能区域：用于填充本地与远程的物料组件，提供给使用者不同的能力； 操作栏：针对画布级别的render的一些操作渲染，如常见的清空与回退。在所有的平台上都以看到它们的身影； 画布：所见即所得，负责承担用户编排组件时实时预览的效果，同时还要支持组件的操作； 属性面板：提供给用户编排的能力，操作选项和物料组件的属性支持是一切效果的基石。