写给技术管理者的低代码手册系列文章（7）——第二部分：低代码的概念、价值与发展现状（第三章）第三章低代码赛道的分类与价

第三章低代码赛道的分类与价值取向

在明确低代码是一种“重构软件生产经济模型”的商业概念之后，下一步需要回答的问题是：为什么市场上会同时存在多种看似差异巨大的低代码平台？

如果仍然沿用功能多少、能不能写代码、是不是拖拽等技术视角，这一问题往往会被简化为产品能力的强弱之争。但从企业实践看，这种解释并不能帮助企业做出正确选择。更合理的视角，是回到低代码试图解决的根本问题，如何在长期变化中，以可控成本持续产出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 前提一：开发者需要具备持续学习和理解平台抽象的意愿

与面向业务开发者的低代码不同，这类平台并不会把所有复杂性藏起来。相反，它会通过模型、约束、规范和平台机制，将复杂性重新组织并显性化。开发者需要理解这些抽象背后的设计逻辑，才能在变化发生时，正确地使用平台提供的能力，而不是绕开它。这意味着，低代码在这里并不是无需学习的工具，而是一种新的工程语言。如果团队仅将其视为写得更快的开发工具，而不愿投入时间理解其架构思想、运行机制和治理边界，那么平台所承诺的长期成本优势往往无法真正兑现。

3.2.2 前提二：企业需要具备一定程度的技术治理意识和管理机制

由于平台的目标是控制长期演进成本，它往往会引入统一的数据模型、服务边界、权限体系和扩展规范。这些机制并不会自动生效，而是需要通过制度、流程和角色分工来落地，例如：

明确哪些能力应以内建模型实现，哪些可以通过扩展完成
约束跨系统、跨模块的依赖方式，避免隐性耦合
对关键模型和服务的变更建立评审和演进规则

如果企业仍然以“项目交付完成即结束”为主要管理方式，缺乏对系统整体结构的长期治理，那么平台提供的工程抽象反而可能被不断侵蚀，最终退化为另一种形式的快速堆叠软件功能。

3.2.3 前提三：从组织层面看，这类低代码并不适合完全去中心化的开发模式

平台强调结构稳定性和可持续演进，天然需要一部分人对系统整体负责。这要求企业至少在核心系统层面，承认并保留架构责任和平台责任的角色，而不是将所有开发活动完全下沉、完全分散。在一些组织中，如果对统一技术路线和长期架构约束本身存在抵触情绪，那么这类低代码的优势往往难以发挥，甚至会被误解为“限制灵活性”。

3.2.4 前提四：管理层可以接受“初期投入感知更强，但回报周期更长”的模式

相较于以成果导向为核心的低代码，面向专业开发者的低代码在早期阶段未必能显著缩短单个应用的交付周期，其价值更多体现在：

多年运行后系统依然可维护
变化频率提升但成本曲线保持平缓
人员更替对系统影响可控

这要求企业在决策时，能够接受“不是所有价值都立即可见”，并将软件视为一项需要长期经营的资产，而非一次性交付的项目。

正因如此，面向专业开发者的低代码并不是“更高级的低代码”，而是一种以长期成本可控为前提的软件生产方式选择。它适合那些已经意识到隐性成本是软件成本的主要组成、并愿意为可持续演进投入组织能力的企业。

3.3 两类低代码的典型适用边界

在实践中，围绕低代码的争议往往集中在一个表面问题上，即某一类低代码平台能不能支撑复杂系统、核心系统或长期演进的业务。但从软件经济模型的角度看，这个问题本身并不关键。真正重要的不是能不能做，而是值不值得做，即在长期运行和持续变化的前提下，这样做是否仍然具有经济价值。

3.3.1 面向业务开发者低代码的合理边界

面向业务开发者的低代码平台，在以下场景中通常具有清晰且稳定的优势：

业务目标明确，交付周期短
系统生命周期可预期，变化频率有限
主要价值体现在“是否快速落地”，而非“是否长期演进”

在这些条件下，压缩一次性投入成本、快速产生成果是理性的选择。即使后续存在一定程度的隐性成本，其规模和持续时间也通常是可接受的。但当系统开始具备以下特征时，经济模型就会发生变化，典型的场景如下：

系统逐步成为多个部门的协同基础
业务规则持续细化，变化成为常态
数据开始被反复复用，并影响管理决策

此时，原本被压缩的显性成本，往往会以配置复杂度、治理难度和维护负担的形式重新出现。平台并没有失败，只是被使用到了不擅长的领域。

3.3.2 面向专业开发者低代码的适用前提

与之相对，面向专业开发者的低代码平台，适用的前提条件更加明确。此类低代码也并不是适合所有系统，而是更适合以下情况：

系统预期运行周期较长，且不可避免地持续变化
系统结构复杂，涉及跨流程、跨部门或核心数据
企业已经意识到“隐性成本是主账”，并希望对其进行系统性控制

在这些前提下，企业更关心的是随着时间推移，系统是否还能被理解、维护和扩展，而不是某一次交付是否足够快。但如果企业尚未建立基本的技术治理意识，或组织层面对“长期架构约束”缺乏共识，那么即使引入了成本导向的低代码平台，也很难真正发挥其价值，反而可能因前期学习和治理投入，产生“性价比不高”的主观感受。

3.3.3 边界冲突的本质：价值坐标不一致

在实际落地过程中，低代码项目失败的原因，往往并不在于技术能力不足，而在于价值坐标的错位。典型的冲突包括：

用面向业务开发者的低代码，却要承担需要长期演进的系统角色
用面向专业开发者的低代码，解决一次性、短周期的业务问题
在缺乏治理意愿的组织中，引入任何一种旨在“将管理固化为软件”的低代码平台

这些问题表面上看是选型失误，但本质上是没有先明确自己要算的是哪本账。在认识到低代码不是万能解法，而是一种明确立场的选择后，将两类低代码放回到企业软件的总账中，就可以得到一个更冷静、也更有解释力的结论，低代码并不是用来消除所有成本，而是帮助企业在特定场景下，把成本从不可见、不可控，转化为可预期、可管理。选择面向业务开发者的低代码，就是选择优先解决成果的不确定性，“先到咸阳为王上”；选择面向专业开发者的低代码，就是选择优先解决长期成本不确定性，“该省省该花花”。

理解这一边界，低代码就不再是一种模糊的效率工具，而成为企业在软件生产方式上的一次清晰表态。