第 1 章　低代码平台全景：概念、演进与生态

低代码平台全景：概念、演进与生态

低代码的本质，是把"软件开发"这件原本需要专业工程师长时间编码的工作，拆解为可视化搭建、配置化编排与少量胶水代码，从而让业务人员与开发者能在同一个平台上协同完成系统交付。这个看似简单的理念，背后却涉及 60 余年的编程语言演化、企业 IT 架构变迁以及云原生与生成式 AI 的最新冲击。本章从 Forrester 与 Gartner 的标准定义出发，沿时间轴梳理四代低代码平台的演进脉络，横向对比国内外代表性产品，并把"为什么开发者要亲手实现低代码"这个问题讲透——它的价值边界在哪里，工程陷阱在哪里，分类坐标系如何建立，以及它如何重新定义开发者本身的角色。

1.1 什么是低代码：定义、要素与边界

1.1.1 两大权威机构的定义

2014 年，Forrester Research 在《The Rise of Low-Code Development Platforms》报告中首次正式提出"Low-Code Development Platform（LCDP）"这一术语，并给出学界至今仍频繁引用的定义：

> A low-code development platform is a software development environment that allows citizen developers (业务人员、运营、领域专家等非专业程序员) and professional developers to work together on the creation of business applications through graphical drag-and-drop modeling, declarative configuration, and minimal hand-coding.

中文译意为：低代码开发平台是一种通过图形化拖拽建模、声明式配置与少量手写代码，让业务开发者与专业开发者能够协同完成业务应用构建的软件开发环境。

Forrester 的定义里藏着三个关键要素，缺一不可：

1. 可视化建模（Visual Modeling）：使用拖拽方式组装 UI、流程、数据模型，而非逐行编写 HTML、CSS、JavaScript。 2. 声明式配置（Declarative Configuration）：通过表单、规则、属性面板描述"想要什么"，而不是"如何做"，平台据此推导行为。 3. 少量手写代码（Minimal Hand-Coding）：保留可扩展点，允许在平台无法覆盖的场景下插入脚本或函数。

Gartner 则从企业 IT 治理的角度补充了第二份定义，出现在其 2019 年发布的《Magic Quadrant for Enterprise Low-Code Application Platforms》报告中：

> Low-code application platforms (LCAP) provide a platform-as-a-service (PaaS) abstraction with declarative programming, event-driven logic, and integration capabilities to enable rapid application development, deployment, and runtime management.

Gartner 的定义把低代码定位为一种"企业级应用平台"，强调三件事——PaaS 抽象、声明式编程、事件驱动，以及它们服务于"快速开发、部署与运行时管理"这一整套生命周期。这一视角提醒我们：低代码不是单纯的"前端搭建工具"，而是一种覆盖开发、部署、运维全链路的平台型基础设施。

1.1.2 低代码的三个不可妥协的要素

把两大权威定义拆开揉碎，我们可以提炼出低代码区别于"传统代码框架"或"传统零代码工具"的三个不可妥协要素：

要素一：可视化 + 模型驱动

低代码平台必须拥有可视化的画布（Canvas）与模型层（Model）。画布负责 UI 与流程的呈现，模型层负责实体（Entity）、字段（Field）、关系（Relation）的描述。模型可以是数据库表、JSON Schema、GraphQL Schema、或者平台私有的内部模型。无论采用何种形式，必须存在一个"图形可读、可被画布引用"的数据结构。

要素二：可声明与可编程的双轨

平台的 GUI 部分使用声明式语言（DSL 或配置）描述意图，而对平台表达不出来的复杂逻辑，必须提供"逃逸口"（Escape Hatch）——例如 JavaScript 表达式、Python 函数、Java 类扩展、外部 Webhook。该逃逸口不能成为主流，否则就退化为"表单生成器 + IDE"。

要素三：贯穿生命周期的平台能力

平台必须覆盖：开发态（Designer）、构建态（Builder）、部署态（Deployer）、运行态（Runtime）、治理态（Governance）。如果产品只解决"画 UI"，运行还需要程序员另行部署，则不能称为完整的低代码平台。

1.1.3 低代码 vs 零代码 vs 传统开发

理解定义后，还需要分辨三个常被混用的概念：

• **零代码（No-Code）**：面向完全无编程经验的业务人员，所有逻辑必须通过平台已有模板实现，禁止手写代码。代表产品：Notion、Airtable、Bubble。
• **低代码（Low-Code）**：允许少量手写代码，目标是扩大开发者池（从专业程序员扩展到"懂业务的开发者"）。
• **传统开发（Pro-Code）**：所有逻辑由专业工程师逐行编码。

三者关系并非线性升级，而是面向不同人群的不同形态。一个企业内部常常需要三者并存：HR 用零代码搭建请假流程，后端团队用低代码搭建 BFF + 业务编排，核心交易系统仍用 Pro-Code 实现。

---

1.2 四代演进：从 4GL 到 AI-Native

低代码并非 2020 年后才出现的新概念。它是计算机科学四十年演进的自然结果。把它拉成时间轴，可以看到四代清晰可辨的形态：

1.2.1 第一代：4GL 时代（1980s–1990s）

第四代语言（4GL, Fourth-Generation Language）的代表是 Powerbuilder、Oracle Forms、Visual Basic、Delphi 等。其核心理念是"用更少的代码完成更多的事"。开发者拖拽控件、配置属性、绑定数据库表即可生成表单与报表。

4GL 的局限在于：

1. 客户端绑定严重：Oracle Forms 与 Powerbuilder 强绑定 Oracle / Sybase 数据库，几乎无法迁移到云。 2. 闭源与黑盒：GUI 工具虽然好用，但底层生成代码不可见，定制能力受限于厂商。 3. Web 化失败：4GL 大多停留在 C/S 架构，未能跟上 Web 浪潮。

虽然 4GL 多已淡出主流，但它的精神遗产——"拖拽式 GUI + 数据绑定"——被现代低代码平台完整继承。

1.2.2 第二代：BPMS 时代（2000s）

业务流程管理系统（BPMS, Business Process Management System）的代表是 IBM Lombardi、Appian、Pega、jBPM、Activiti。BPMS 的核心模型是 BPMN（Business Process Model and Notation），它用泳道图（Swimlane）、网关（Gateway）、事件（Event）等可视化元素描述企业流程。

BPMS 的突破在于把"流程建模"与"执行引擎"打通：画图不再是文档，而是可以直接运行的 BPMN 描述。其架构通常包括：

• **流程引擎（Process Engine）**：解析 BPMN、调度任务、处理分支。
• **规则引擎（Rule Engine）**：Drools、Jess 等用于表达复杂业务规则。
• **表单引擎（Form Engine）**：动态渲染流程表单。
• **集成层（Integration Layer）**：与 ERP、CRM 等系统互联。

BPMS 的局限是过于"流程中心"：流程画布很强大，但 UI 搭建、数据建模、API 编排相对薄弱。适合审批流、工单流等场景，但难做复杂业务系统。

1.2.3 第三代：aPaaS 时代（2010s）

应用平台即服务（aPaaS, application Platform as a Service）的代表是 Salesforce Lightning Platform、OutSystems、Mendix、Microsoft Power Platform。aPaaS 把 BPMS 的"流程建模 + 规则引擎"扩展为完整的应用开发平台：

• **统一建模**：实体、页面、流程、报表、权限都在一个模型空间内。
• **多端生成**：一次建模，多端发布（Web、iOS、Android、桌面）。
• **云原生**：底层依赖 Kubernetes、容器、Serverless，开发者无需关心基础设施。
• **DevOps 内建**：内置 CI/CD、版本管理、灰度发布、监控。

OutSystems 与 Mendix 被 Forrester 评为"低代码平台的标杆"，两者共同特点是企业级、安全合规、可扩展。Power Platform 则与 Microsoft 365、Azure 深度整合，成为 Office 生态的一部分。

aPaaS 的局限是"重"，单个许可证动辄数十万美元、实施周期长、需要专业团队。这为下一代产品的差异化留下了空间。

1.2.4 第四代：AI-Native Low-Code 时代（2023—）

2023 年生成式 AI 爆发后，低代码平台进入第四代——AI 原生（AI-Native）。其典型形态包括：

• **Copilot 类**：微软 Power Apps 的 Copilot、Salesforce Einstein Copilot、OutSystems AI Assistant。开发者用自然语言描述需求，平台生成应用骨架、字段、表单、流程。
• **Agent 类**：腾讯微搭、钉钉宜搭均推出 AI Agent，能基于业务知识库自动搭建页面、填充数据。
• **私有化大模型接入**：国内政企客户要求"大模型不能出境"，于是低代码厂商开始支持接入 DeepSeek、Qwen、ChatGLM 等私有模型。

第四代的核心变化是"从工具到协作者"：低代码平台不再只是被动执行配置，而是具备理解需求、生成代码、解释错误的能力。这对开发者既是机会（效率倍增器），也是挑战（如何让 AI 生成的内容可控、可审计、可维护）。

---

1.3 主流产品横向对比

要把"低代码"从抽象概念变成可落地的选择，必须把它放进具体产品的坐标系里。本节选取 OutSystems、Microsoft Power Platform、Appsmith、Budibase、JVS、JeecgBoot 六款代表性产品，从定位、技术栈、适用场景、许可证模式四个维度展开对比。

1.3.1 商业级标杆：OutSystems

• **定位**：企业级 aPaaS，2017 年起被 Forrester 评为低代码领导者象限。
• **技术栈**：.NET Core + 自研可视化建模引擎，部署支持本地、私有云、AWS、Azure。
• **核心优势**：成熟的移动端、复杂业务逻辑编排、企业级安全合规（GDPR、HIPAA、SOC2）。
• **适用场景**：大型企业核心业务系统（如银行信贷、保险公司理赔）。
• **许可证模式**：按用户数 + 应用数订阅，起步价约每年 $5,000/用户。

OutSystems 的可学习曲线较为陡峭，但它代表"完整的工程化"——从建模到运维一站式，适合预算充足、需要长期维护的项目。

1.3.2 生态融合代表：Microsoft Power Platform

• **定位**：Microsoft 365 + Azure 生态内的低代码套件，包括 Power Apps（应用）、Power Automate（流程）、Power BI（分析）、Power Pages（门户）。
• **技术栈**：Dataverse（数据底座，原 Common Data Service）、Azure Logic Apps（流程引擎）。
• **核心优势**：与 Teams、SharePoint、Outlook、Excel 深度集成，企业用户上手成本极低。
• **适用场景**：中大型企业的内部工具、审批流程、自助 BI。
• **许可证模式**：按用户订阅，与 Microsoft 365 E3/E5 捆绑，附加 Power Platform 许可约 $15/用户/月。

Power Platform 的扩展能力来自 Power Platform Creator Kit 与 ALM（Application Lifecycle Management）工具链，是目前"用户基数最大"的低代码生态。

1.3.3 开源易用之选：Appsmith

• **定位**：开源低代码平台，专注内部工具（Internal Tools）与 CRUD 页面快速搭建。
• **技术栈**：Java + React + MongoDB/PostgreSQL，支持 Docker、Kubernetes 一键部署。
• **核心优势**：100% 开源（Apache 2.0），无供应商锁定；社区活跃、插件丰富。
• **适用场景**：中小团队搭建运营后台、数据看板、API 聚合页面。
• **许可证模式**：社区版免费，云托管版按用户付费。

Appsmith 适合"想要自己掌控数据与代码"的开发者，是本书后续章节实现自定义可视化编辑器时的重要参考对象。

1.3.4 自托管轻量之选：Budibase

• **定位**：开源、自托管的低代码平台，专注内部系统与表单驱动应用。
• **技术栈**：Budibase 自研框架 + Node.js + Svelte + PostgreSQL/SQLite/MongoDB。
• **核心优势**：支持多种数据源（Rest API、Postgres、Mongo、Arango、S3）；单二进制部署，适合边缘场景。
• **适用场景**：零售门店、制造车间的本地化数据采集系统。
• **许可证模式**：社区版开源（SPL），企业版付费。

Budibase 与 Appsmith 常被一同对比：前者更轻量、表单驱动更强；后者更复杂、CRUD 与 JS 逻辑更强。

1.3.5 国产表单驱动：JVS 低代码

• **定位**：JVS（Joint Visual System）是一款国产开源低代码平台，专注表单驱动 + 业务流程。
• **技术栈**：Spring Boot + Vue + ELK，支持私有化部署。
• **核心优势**：开箱即用的审批流、字段权限、打印模板；中文化文档完整。
• **适用场景**：政府、国企、大中型企业的 OA、审批、报表系统。

1.3.6 国产代码生成型：JeecgBoot

• **定位**：JeecgBoot 定位为"低代码 + 代码生成器"平台，介于传统开发与低代码之间。
• **技术栈**：Spring Boot + Vue + Ant Design Vue。
• **核心优势**：单表/树表/主子表自动生成前后端代码；可在线配置 ERP、CRM、OA。
• **适用场景**：Java 生态内做信息化系统，需要快速起步又保留深度定制空间的团队。

下表把上述六款产品做横向对照。需要说明的是：下表中的评分采用 1–5 分制（5 分为最强），旨在帮助读者快速建立认知，不构成权威测试结果。

| 维度 | OutSystems | Power Platform | Appsmith | Budibase | JVS | JeecgBoot | |------|-----------|----------------|----------|----------|-----|-----------| | 定位 | 企业级 aPaaS | Microsoft 生态套件 | 开源内部工具 | 自托管轻量平台 | 国产生态工具 | 代码生成器 | | 数据源 | 数据库 + API + 自定义 | Dataverse + 连接器 | 数据库 + RestAPI | 多种数据源 | 数据库 + Rest | 数据库为主 | | 建模方式 | 实体 + 页面 + 流程 + 规则 | 表单 + 流程 + 数据 | 表单 + JS | 表单 + 自动化 | 表单 + 流程 | 单表生成代码 | | 扩展能力 | 自定义代码 + 集成 SDK | 自定义连接器 + Azure Function | JS 函数 + API | JS + 钩子 | 代码扩展 | 直接修改生成代码 | | 私有化 | 强 | 需 Azure Stack | 强 | 强 | 强 | 强 | | 学习曲线 | 中–高 | 低 | 低–中 | 低 | 低 | 中 | | 许可证 | 商业付费 | 商业订阅 | 开源 / 云付费 | 开源 / 商业付费 | 开源 / 商业付费 | 开源 / 商业付费 |

从表格可以看出，没有任何一款产品是"全维度满分"。选型本质上是把业务需求映射到合适的产品形态。

---

1.4 核心价值与工程局限

低代码被追捧的核心原因，是它确实在多个维度上带来了可量化的价值。但硬币的另一面是：它也存在不可回避的工程边界。本节把"价值"与"局限"对称摆出，帮助读者建立平衡判断。

1.4.1 六大核心价值

价值一：提效

低代码的最大直接收益是开发效率提升。Forrester 调研数据显示，规范使用低代码平台的项目，平均交付周期从传统 6 个月缩短至 6–8 周，提效约 3–5 倍。本书 1.7 节将用一个零售案例展示这一对比。

价值二：降本

低代码通过"扩大开发者池"——让业务人员也能参与开发——显著降低对纯程序员的依赖。一个内部工具项目，传统开发需要 2 人×3 个月，使用低代码可缩减为 0.5 人×1 个月，约节省 75% 的人力成本。

价值三：敏捷

业务需求变化时，传统开发需要重新走一遍需求评审、设计、编码、测试、部署的完整周期，2–4 周才能上线。低代码通常只需修改配置，2 天内即可完成。迭代速度的提升直接转化为业务响应能力。

价值四：统一治理

企业 IT 的痛点之一是