第三章 低代码赛道的分类与价值取向
在明确低代码是一种'重构软件生产经济模型'的商业概念之后，下一步需要回答的问题是：为什么市场上会同时存在多种看似差异巨大的低代码平台？
如果仅从功能多寡、是否支持编码或拖拽等纯技术视角审视，这一问题往往会被简化为产品能力的强弱之争。但从企业实践看，这种解释并不能帮助企业做出正确选择。更合理的视角，是回到低代码试图解决的根本问题：如何在长期变化中，以可控成本持续产出 IT 成果、支撑业务发展。为此，低代码概念的提出者 Forrester 将低代码平台明确区分为两类：
- LCDP for Business Developers（面向业务开发者的低代码平台）
- LCDP for Professional Developers（面向专业开发者的低代码平台）
这里需要明确的是，这里的'业务开发者'与'专业开发者'的差异并不首先体现在软件开发技术能力上，而体现在其在企业组织中的角色定位、责任边界与管理方式上。这一差异，直接决定了两类低代码平台在价值主张上的根本不同。
3.1 LCDP for Business Developers：控制一次性投入成本
面向业务开发者的低代码平台通常是将数据与业务逻辑合一的表单驱动型产品，衍生于 ERP、OA 中广泛使用的可配置化技术，使用体验类似于成品软件的实施。市场宣传中常将其称为'无代码'。
业务开发者指的是不向 IT 部门负责，但构建软件提供给其他人使用的人员，与 Gartner 提出的平民开发者概念相同。在企业组织中，业务开发者往往承担的是流程负责人、业务负责人、运营负责人等角色。他们对业务规则、流程细节和管理目标高度熟悉，但并不对系统的长期技术演进负责。所以，此类低代码平台的出发点并不是'如何构建一个长期演进的软件系统'，而是让业务部门在最短路径内，把明确的业务目标转化为可用的系统成果。在这种前提下，软件的价值衡量方式天然偏向于成果导向：
- 是否解决了当下明确的问题
- 是否快速支撑了某个管理动作或流程改造
- 是否在有限时间内产生了可见效果
实践中，这类低代码平台往往通过高度封装的方式，将软件生产过程压缩为一系列可配置的业务动作，使业务人员能够在既定框架内快速产出应用，与 ERP、OA 等成品软件提供的配置能力类似。从软件经济模型的角度看，这类平台的价值在于以较低的初始投入和组织摩擦成本，快速产生成果。
但这种成果导向，本身也意味着边界的存在。当系统开始承载更复杂、跨部门、长期演进的业务规则时，其隐性成本往往会以另一种形式显现出来，例如配置规则逐渐复杂，但缺乏系统化治理手段，可维护性和数据质量风险持续提升；应用数量快速增长，却难以形成统一架构，数据孤岛普遍性存在；成果以'应用数量'累积，但系统整体可持续性下降等。这并非平台能力不足，而是其设计初衷本就聚焦于压缩显性成本，控制一次性投入成本，服务于阶段性成果最大化，而非长期软件资产的持续演进。
3.2 LCDP for Professional Developers：控制变化的长期成本
与此相对，面向专业开发者的低代码平台通常是数据与逻辑完全分离、各自独立的模型驱动型产品，是可视化开发技术发展的产物，体验上承袭了传统软件开发的生命周期，有明确区分的开发工作界面和最终用户使用界面，也被称为'狭义的低代码'。
此类低代码的价值起点并不在于更快产出一个应用，而是在长期变化中控制软件系统的演进成本。与业务开发者的概念相对应，专业开发者并不一定在 IT 技术上拥有显著优势，但因为其必须向 IT 部门汇报的管理性质，决定了他们拥有业务开发者无法比拟的学习开发技术和提升可持续性的驱动力。在企业中，专业开发者以及由他们组成的 IT 团队承担的是系统负责人和技术治理者的角色。他们需要对系统的稳定性、可扩展性、安全性和长期维护成本负责。这意味着，他们衡量软件价值的核心标准，天然偏向于成本导向：
- 每一次业务变化的边际成本是否可控
- 系统规模扩大后，复杂度是否线性增长
- 人员变动是否会导致系统不可维护
因此，这类低代码平台并不试图屏蔽复杂性，而是通过适度的工程抽象，将通用的中间件能力与工程规范内建为平台能力，将重复出现的系统结构固化为模型与约束，将变化的影响范围限制在可治理的边界之内，最终实现将复杂性集中、结构化处理的效果。
在这种模式下，低代码并不是为了减少代码本身，而是将重点放在压缩变化的长期成本，从而实现持续提升 IT 团队成果产出能力的目标。它通过重构软件生产方式，使系统能够在持续变化中保持结构稳定，从而支撑真正意义上的可持续演进。作为代价，此类低代码平台通常对组织和人员提出了更高的前置要求，可以概括为'四大前提'。
3.2.1 前提一：开发者需要具备持续学习和理解平台抽象的意愿
与面向业务开发者的低代码不同，这类平台并不会把所有复杂性藏起来。相反，它会通过模型、约束、规范和平台机制，将复杂性重新组织并显性化。开发者需要理解这些抽象背后的设计逻辑，才能在变化发生时，正确地使用平台提供的能力，而不是绕开它。这意味着，低代码在这里并不是无需学习的工具，而是一种新的工程语言。如果团队仅将其视为写得更快的开发工具，而不愿投入时间理解其架构思想、运行机制和治理边界，那么平台所承诺的长期成本优势往往无法真正兑现。
