低代码平台公共素材

使用说明

• 低代码平台怎么讲 统一从本页引用公共口径。
• 如果要改定性、短讲法或高频追问，优先改本页。

一句话定性

我不会把低代码平台讲成“一个拖拖拽拽的页面编辑器”，而会讲成“用稳定的数据模型和运行时机制，把页面搭建和业务联动产品化”。

30 秒版本

如果面试里让我讲低代码平台，我会先讲清楚它不是单纯的搭页面工具，而是一套把页面结构、组件物料、事件编排和数据联动统一起来的系统。前端在里面做的也不只是 UI，而是协议设计、编排引擎、渲染机制、状态联动和扩展体系。真正的难点不是拖拽本身，而是怎么让这套系统既能扩展，又能在复杂业务里保持稳定。

1 分钟版本

低代码平台这个题，我一般不会从界面编辑器开始讲，而是先讲它的本质。对我来说，低代码平台本质上是两件事：第一，用一套稳定的数据结构去描述页面和组件；第二，用一套运行机制去承接这些数据，让页面、事件和数据联动真的跑起来。

所以它不是“拖一个按钮上去”这么简单，而是后面要有 schema、组件注册机制、渲染引擎、事件编排、全局变量和数据绑定这些东西一起配合。前端在这里做的，也不仅是编辑器交互，还包括协议设计、运行时设计和可扩展性设计。

如果让我总结低代码平台最值得讲的点，我会说不是页面搭得多快，而是你能不能把复杂业务抽成一套稳定的模型，并且让这套模型在编辑态和运行态都成立。

2 到 3 分钟版本

我理解低代码平台，不是一个“所见即所得”的拖拽工具，而是一套把页面搭建能力、配置能力和业务联动能力工程化的系统。

它的核心不在于有没有一个可视化画布，而在于你有没有一套稳定的数据模型去描述页面。比如页面上有哪些组件、组件之间怎么嵌套、组件属性怎么存、事件和数据源怎么挂接。这些东西如果没有统一 schema，后面就很难做版本管理、回滚、多人协作和运行时渲染。

所以我通常会把低代码平台拆成几层来看。第一层是协议层，也就是 schema / DSL，定义组件树、属性、事件和数据源。第二层是物料层，也就是组件注册中心，负责把 type 映射到真正的渲染器和配置面板。第三层是编排层，也就是编辑器和拖拽引擎，负责插入、移动、删除和布局调整。第四层是运行时层，负责把 schema 真的渲染出来，并处理事件流和数据联动。

真正难的地方在两块。第一块是数据模型要足够稳定，因为整个系统都压在它上面。第二块是编辑态和运行态的边界要清楚。编辑态需要选中、高亮、拖拽、配置面板；运行态只关心真实业务逻辑和页面表现。如果这两层混在一起，系统会越来越难维护。

所以如果让我讲低代码平台，我会重点讲“协议、编排、运行时”这三件事，而不是只讲拖拽交互。因为拖拽只是入口，真正决定平台能不能做大的，是背后的模型和机制。

更口语化的 2 到 3 分钟逐字稿

如果这个项目在面试里让我稍微展开一点讲，我一般不会直接说“我做了一个低代码编辑器”，因为那样很容易把项目讲浅。我会先讲，这个项目本质上是在做一套配置化平台，核心是把页面结构、组件配置、事件联动和数据绑定，统一抽象成一套稳定的 schema 和运行机制。

具体一点说，它服务的不是单一业务页面，而是企业移动办公、CRM、HRM、CMS、ERP 这类通用 SaaS 场景。所以这里真正难的不是拖拽，而是三件事。第一，schema 要足够稳定，因为表单、表格、仪表盘这些能力最后都要落到同一套描述模型上；第二，编辑态和运行态要分清楚，编辑器里有选中、高亮、拖拽和配置面板，但运行时只关心页面怎么渲染、事件怎么触发、数据怎么联动；第三，整套机制要能扩展，不然业务一复杂，平台很快就会变成一堆特判。

所以我在这个项目里更关注的是平台抽象。比如复杂表单的 schema 怎么设计，怎么通过插件化机制去接更多表单项和规则；表格和表单之间怎么围绕同一份 JSON/schema 去交互，尽量做到“一个 JSON 走天下”；还有仪表盘编辑器和渲染引擎，怎么把配置真正变成运行时的数据展示能力。这些表面上看是不同模块，但本质上都在解决同一个问题，就是怎么把复杂业务沉淀成稳定、可配置、可复用的平台能力。

所以如果让我用一句话收一下，我会说这个项目最能体现能力的地方，不是拖拽做得多炫，而是有没有把 schema、运行时和扩展机制真正打通。

结合轻流项目的 1 分钟讲法

如果结合我做过的轻流低代码平台来讲，我一般会把它讲成一个服务通用 SaaS 场景的配置化底座，而不是一个页面拖拽工具。这个平台覆盖企业移动办公、CRM、HRM、CMS、ERP 等业务，我做得比较深的有三块：第一是复杂表单 schema 和插件化机制，第二是表格和表单之间统一 JSON/schema 的交互模型，第三是仪表盘编辑器和渲染引擎。它们本质上都在解决同一个问题，就是怎么把复杂业务抽象成平台可复用、可扩展、可运行的稳定模型。除此之外我也参与了权限和多租户体系设计，并引入 Nx 做 monorepo 治理，所以这个项目我一般会从“schema 抽象、运行时承接、工程治理”三个层次来讲。

结合轻流项目的 2 分钟讲法

我当时做的是轻流低代码平台，服务企业移动办公、CRM、HRM、CMS、ERP 等通用 SaaS 场景。这个项目我最想讲的不是拖拽交互，而是平台底层抽象怎么统一。

第一块是表单 schema。因为业务表单不只是字段录入，还会涉及动态显隐、复杂校验、跨字段联动和业务扩展，所以我主导做了通用表单 schema 和插件化机制，让表单项、规则和扩展能力可以按统一协议接入。这样平台不是靠堆 if else 接需求，而是靠稳定 schema 和插件机制承接变化。

第二块是表格和表单的统一建模。我主导抽象了通用表格以及表格和表单之间的交互约定，核心目标是尽量做到“一个 JSON 走天下”，让配置、渲染和交互围绕同一份模型展开，减少多处重复定义和前端硬编码，这对平台长期演进非常重要。

第三块是仪表盘编辑器和渲染引擎。这里既要支持编辑态的配置和布局，也要支持运行态的数据展示，所以我结合 d3 做了一些定制图表能力，让业务方可以通过配置快速搭建数据看板。

除了这些功能层能力，我也参与了权限和多租户体系设计，并引入 Nx 做 monorepo 治理，推动统一规范、统一文档和统一业务口径。所以这个项目我通常会讲成一个“以 schema 为核心、以运行时和工程治理为支撑的低代码平台建设”项目，而不是只做了一个编辑器。

代表性工作

• 主导复杂表单 schema 与插件化机制设计，让表单项、规则和扩展能力可以按统一协议插拔式接入。
• 主导通用表格体系以及表格和表单交互规范抽象，尽量把配置、渲染和联动收敛到同一份 JSON/schema 模型上。
• 主导仪表盘编辑器和渲染引擎建设，结合 d3 支撑定制图表和数据看板配置。
• 参与系统权限体系和多租户用户体系设计，补齐平台在通用 SaaS 场景下的账号、组织、角色和数据隔离能力。
• 引入 Nx 落地 monorepo 工程体系，推动统一规范、统一文档和统一业务口径，降低循环依赖和重复建设问题。

价值为什么不只是 UI

我在这个项目里真正做的不是把组件摆到画布上，而是参与定义 schema、插件机制、表格和表单的交互协议，以及编辑态和运行态怎么承接同一份配置模型。换句话说，我做的是平台抽象层和底座层，不是单点页面交付。

最难的点

我觉得最难的不是把页面拖出来，而是怎么把复杂业务抽象成平台可以承接的稳定模型。因为平台一旦做通用化，就很容易在扩展性和复杂度之间失衡。模型太松，系统会乱；模型太死，业务又接不住。

前端价值

我觉得前端在低代码平台里的价值，不是单点页面开发，而是把页面能力、状态能力和运行机制抽象成平台能力。也就是说，前端做的是一套能不断复用和扩展的基础设施，而不是一张业务页面。

最后一句收尾

所以低代码平台真正能体现能力的地方，不是做了一个编辑器，而是能不能把页面、事件、数据和运行时统一成一套稳定系统。