共计 5298 个字符，预计需要花费 14 分钟才能阅读完成。
前言
低代码平台的呈现，是互联网疾速倒退的背景下，满足产品疾速迭代的理论需要。当初国内外都曾经领有十分多优良的开源我的项目（如：lowcode-engine）和成熟的商业产品（如：Mendix、PowerPlatform）。这篇文章会探讨 4 个和低代码无关，并且比拟值得摸索的方向。
因为低代码目前在业界并没有一个被广泛认同的定义，所以我想先形容一下我对于低代码的了解，以便大家可能更容易了解后续内容。
低代码能够别离从 业务和技术 两个角度去定义并了解它。
业务
基于 业务角度，我认为代码平台是：
低代码平台是一种容许用户通过 图形界面来设计和构建利用的工具。低代码平台通过简化代码编写（或无代码），使得非开发人员也可能疾速地构建和部署应用程序。
人类应用工具的目标在于进步生产效率，低代码作为一种生产利用的工具，不仅用户能通过可视化界面疾速地生产利用，还能够加重开发人员的工作量，解放开发人员的生产力。
通常来说，低代码有两种计划：
计划一：
对具体业务场景做极致地形象，组件专一于无限的业务场景，对于用户来说，通过配置面板提供的简略的配置项就能实现配置，学习成本低，配置效率高。尽管这个计划的组件只能在无限的业务场景中应用，但只有组件数量够多，也能满足少数场景。
计划二：
根底组件（节点）+ 性能简单的可视化编辑器，通过组件组合和配置，通常能满足绝大多数的场景，但对于用户来说，须要对业务细节足够相熟，并能形象并拆解业务过程，存在肯定的学习老本，并且在配置过程中所需的工夫老本通常更高。
我的抉择是计划二，尽管计划一对于用户来说学习老本更低，配置效率更高，但用户和开发人员的利益有时候是抵触的，对于开发人员来说，计划一会随着版本迭代会带来更高的保护老本，而且计划二带来的问题并不是没有解决方案，我提出的解决方案是 原子化 + 模板化，兼顾灵活性和高效率的需要。
技术
基于 技术角度，我认为低代码平台是：
低代码平台以 数据驱动为外围 。基于UI 和逻辑 这两个维度进行设计，并可拆解为 生产数据和生产数据 的两个关键环节。
以最常见的低代码场景：在可视化编辑器拖拽配置产生一个 H5 页面为例，进行进一步阐明：
UI
生产数据：用户在可视化编辑器内进行拖拽组件、调整配置等操作生产UI 数据（DSL for UI）。
生产数据： 依据我的项目理论需要，通过渲染引擎或出码引擎生产数据，并最终构建出残缺的利用。
流程如图所示：
逻辑
生产数据 ：用户在可视化编辑器内进行逻辑编排等操作生产 逻辑数据（DSL for Logic）。
生产数据： 依据我的项目理论需要，通过逻辑执行引擎或逻辑出码引擎生产数据，并最终构建出残缺的利用。
流程如图所示：
接下来会根据上述内容去做进一步阐明。
全链路
前后端拆散曾经是业界常见的合作模式，将前端界面与后端的业务逻辑和数据进行拆散。前端次要负责用户界面及交互；后端则负责解决业务逻辑、数据存储和提供 API 接口。开发人员能够更专一于各自畛域的开发，研发效率更高，但也因而产生了一些合作老本。
正如前文所述，低代码的 最典型利用场景是通过拖拽和配置来构建一个页面 。然而，如果咱们更深刻地思考，将页面拓展至整个利用，通常一个残缺的利用会蕴含前后端。低代码平台并不仅仅局限于在拖拽生成一个页面这样无限的场景中。因而，前文都是尽可能用 利用 一词来代替 页面。
这就意味着低代码平台应该从 Only for client 到 One-stop application generation，尝试买通前后端全链路，一站式构建残缺的利用。前端开发人员，甚至于产品经营等非开发人员都能够通过较低的学习老本，自助式地生成所需的后盾服务、接口；而后盾开发人员能够专一于开发更根底的一些后端服务 / 接口。这不仅进步前端的研发效率，还能加重后端开发人员的工作量。
和前端的交互逻辑有相似的中央，像是解决逻辑管制的条件判断，监听谬误的日志上报等；但后端的业务逻辑通常会更简单一些，体现在业务逻辑自身就比较复杂，以及对数据的解决，比如说参数校验、数组操作等。如，我须要实现每周优质博主举荐的页面，那么我只须要配置用户登录态校验、参数校验 - 博主 id 数组、数据读写、输入数据等逻辑节点即可。当然，还须要实现包含接口自动化测试等其余配套性能。
生产逻辑数据的计划有很多，如 Blocky、BPMN、表单等。其中流程图是一种还不错的计划，流程图在解决逻辑编排场景有肯定劣势，具体可参考低代码平台实际系列（一）：逻辑配置概述。逻辑不仅能够是前端的交互逻辑，也能够是后端的业务逻辑。
生产数据的计划同样也有很多，这里提供一种比拟容易了解和实现的计划：GraphQL，GraphQL 是一种为 API 设计的查询语言和运行时环境，可用于代替传统的 REST API，能够灵便地获取所需数据并防止适量获取信息。在生产数据的时候，将 DSL 转换成 GraphQL 的 Schema，再应用这份 Schema 去获取所需数据。
跨平台
置信大家对目前风行的 React、Vue 框架都比拟相熟了，Virtual DOM（虚构 DOM）能在保障性能上限的同时，升高保护老本，而且脱离浏览器 Real DOM 限度的 Virtual DOM，让前端不只是局限在浏览器中，在其余平台也能渲染 UI。
低代码和 React、Vue 是有相似之处的，都存在生产和生产数据（Virtual DOM）的过程，以 react 为例，React 为例，react 在生产数据，react-dom 和 react-native 就在生产数据。
所以晚期设计低代码的架构时，在 DSL for UI 的制订上，肯定水平上就是参考了 Virtual DOM 的数据结构，并根据 Virtual DOM 跨平台的理念，尝试为低代码平台实现不同平台的渲染器，如 H5、小程序等。渲染器的实现实质上是在生产数据，所以只有能解析 DSL 并动静地管制 UI，实践上所有平台都能够实现本人的渲染器。
D2C
D2C（Design to Code，设计稿生成代码）是一种将设计稿间接转换为代码的技术，它能够帮忙设计师和开发人员更高效地进行我的项目开发。通过应用 D2C 技术，设计师能够将他们的设计稿（如 Sketch、Photoshop、Figma 等）间接转换为可用的前端代码。
D2C 技术的长处有：
- 进步生产效率，通过自动化生成 UI 层面的代码，缩短开发周期。
- 放弃一致性，主动生成的代码能够确保设计和开发之间的一致性，缩小误差。
- 进步合作效率，缩小沟通老本。
因而 D2C 技术能使开发人员在实现 UI 方面破费更少工夫，从而能更专一于交互逻辑的实现。
那么在现实的状态下，页面的 UI 层面的工作可能齐全由设计师负责，交互逻辑层面的工作才由开发人员来开发。正如前文所述，交互逻辑层面是能够在低代码平台中配置进去的，也就是通过可视化编辑器生产来代替开发人员去开发；那么，D2C 这个步骤是不是也能利用到低代码平台呢？这样一来，用户不再须要手动地配置 UI，因为设计师在解决设计稿时就曾经实现了这一步骤的工作。
要实现这套计划，首先要对 D2C 有根本的意识，但 D2C 的实现原理比较复杂，包含解析设计稿提取原始结构化数据、设计元素辨认、计算布局信息等过程，就不开展阐明了，咱们只须要了解 设计稿是能够通过结构化数据的模式来形容的，实质上是不同数据之间转换和解决的过程。
惯例的业务流程是通过可视化编辑器来生产数据的，将 D2C 技术接入平台后，咱们就能够间接上传设计稿，再由 D2C 技术依据设计稿自动生产出 UI 数据。新流程如图所示：
但目前的 D2C 技术并不完满，在用户不参加的状况下，满足所有场景并生成完全符合预期的 UI 是比拟艰难的，所以 D2C 生产的数据能够作为可视化编辑器的根底数据，提供给用户做进一步地调整。
P2C
P2C（PRD to Code，产品需要文档生成代码）。这是一种更加激进的技术，通过 PRD 就能够间接生成利用。
实质上是在无限的场景下 通过和 AI 对话（如 ChatGPT）或者通过 NLP 辨认生产 DSL，但并不是说在 PRD 所形容的所有内容都能被了解，同时为了帮忙 AI 进行了解，通常有比拟严格 PRD 标准，对 PD（Product Design，产品策划人员）的要求更高。也就说，目前还不具备解决所有场景的能力。
正如我在 D2C 所说，D2C 技术的接入扭转了惯例的低代码业务流程，让设计师在设计时就实现 UI 层面的配置工作。而 P2C 技术的利用将会影响逻辑配置的形式，既D2C 使得 UI 层面由设计师在设计时实现，P2C 使得交互逻辑层面由 PD 在写 PRD 时实现。
那么在最现实状态下，生成利用这个过程对于 PD 和设计师来说是无感知的，PD 和设计师在实现本职工作后，只须要略微期待一段时间，就能体验到残缺利用。
以往年上半年最火的 AI 技术 ChatGPT 为例，形容一下根本流程和实现计划。
根本流程
- 同步 PRD 文本内容（比方贴个 PRD 链接），生成根本数据。
- 同步设计稿（通常会在 PRD 中获取），生成根本数据。
- 和 ChatGPT 对话，修改数据。
现实状态下的根本流程其实就 3 步。对于用户来说，流程约简略约好，但实际上，无论是 D2C 还是 P2C 技术都存在缺点，很难说一步到位，在实现计划中会进一步阐明。
实现计划
存在 2 种计划：
齐全信赖 AI
齐全信赖 AI，AI 主导利用的生产，具体有 2 种：
PRD+Chat
将 PRD 同步给 ChatGPT 后，用户就能够和 ChatGPT 对话一直地修改数据，既全程只通过 ChatGPT 实现利用的生产。
尽管难以满足对 UI 要求比拟高的场景，因为用户不可能节约大量的工夫和精力去和 ChatGPT 形容这些细节（如某个组件的大小）。但对于局部 toB 页面（如各类图表）来说是足够的。
这种实现起来也绝对容易，通常只须要设置好 prompt 就行。
Design+PRD+Chat
如根本流程所形容的那样，有了 D2C 技术的反对，ChatGPT 能够基于 D2C 生产的数据再进一步解析 PRD 生产新的数据，可能满足局部对 UI 要求比拟高的场景。
然而交互逻辑齐全靠 ChatGPT 去了解真的会更好吗？
对于原先的低代码业务流程来说，的确不须要在平台手动配置了，但 PD 在 PRD 投入的工夫和精力会变多，PD 不仅要依据严格标准去编写，还须要对一些细节足够相熟，并且能对具体逻辑拆解，最初还须要组织好语言，并以文字的模式进行输入。所以整体来看效率会是否会更高，我是持狐疑态度的。
基于此，我认为流程图在形容具体逻辑时会比文字要好，比拟起来有以下长处：
- 清晰性：流程图通过明确的形态、箭头和连接线示意步骤、事件和决策，逻辑关系高深莫测。相比之下，文字描述可能较难一眼看清整个逻辑构造。
- 易于了解：流程图能够帮忙在简单的产品逻辑中进行简化。它们不仅有助于更快地了解整体流程，还能够直观地示意各个局部。这让其他人能更容易了解简单的逻辑。
- 高效沟通：对于大多数人来说，视觉信息容易传递排汇。流程图能够作为团队成员间沟通的枢纽，帮忙他们共享和解说想法、需要和解决方案。
- 易于跟踪：流程图通过直观的形式展现了产品的各个阶段及其互相关系，便于在我的项目执行过程中追踪进度和问题点。
- 规范化表白：流程图采纳标准化的符号和图标，使得不同的用户能够更容易地了解和遵循那些曾经制订好的逻辑流程。
- 结构化数据：基于规范化表白的长处，流程图更容易被转换成标准化的数据结构，比文字描述这种比拟含糊的表达方式，更容易被计算机了解。
总的来说，就是 流程图相比于文字通常更容易被人和计算机所了解。PRD 的目标不仅是为了领导开发人员进行开发，更重要的是它须要足够清晰和直观，确保大家都能比拟容易了解，并能在原始产品逻辑的根底上进行进一步的迭代或扩大。所以 PRD 不应该只局限于用文字和图表去形容，而应该尝试用流程图去形容一些具体逻辑，这是有肯定的帮忙的。
辅助型 AI
辅助型 AI 是 将 AI 接入到低代码平台中，和齐全信赖 AI 不同，AI 只是低代码平台的一部分，用户的次要操作还是在低代码平台中，是对传统低代码平台的革新，用互联网黑话叫 AI 赋能低代码。这是一种绝对激进计划，相比于齐全信赖 AI，我认为这种计划更加求实一些。
作为低代码平台的辅助工具，在创立利用时，将 PRD 和设计稿上传和辨认生成页面一些根底数据，再通过平台提供的编辑能力进行调整，最初生成利用。
这样做的劣势在于，流程中的第三步：须要和 ChatGPT 进行对话修改数据，能够被代替成更高效的形式，让用户通过可视化编辑器去调整，而不是让用户耗费工夫和精力去思考和组织语言。
无论是哪种计划，须要留神点是：
- temperature 的值应该设置的低一点，咱们只须要 AI 精确地了解咱们须要什么，也就是更多是基于事实登程。
- 节约 token 的数量，比方让 ChatGPT 以 patch 的形式生产新的 DSL。
总结
冲破前后端的边界，买通全链路，是基于低代码逻辑配置的扩大，解放后端开发人员的生产力；借鉴 Virtual DOM 的思维，实现不同平台的渲染器，低代码不止是局限于 web，而是能笼罩不同平台的各种场景；D2C 优化 UI 层面的配置过程；P2C 优化交互逻辑层面的配置过程。将四个方向联合起来，我认为就是低代码平台比拟现实的状态：以构建全链路的跨平台利用为指标，通过 AI 解决配置过程中的大部分工作，再由用户进行大量配置，甚至不做任何配置。
