低代码与业务搭建边界研究报告

基本信息

阅读时间：约 29 分钟

字数：约 13,327 字

摘要：市场共识：低代码的边界就是「能搭什么」。只要平台把组件做够、把模型做对，业务人员的搭建能力就会持续向上扩张，最终覆盖大部分企业应用。支持这一判断的读数确实存在——公开报道引用的第三方数据显示，2025年上半年中国低代码和零代码软件市场规模达到21.1亿元、同比增长21.4% [4]；另一组公开调研给出开发效率提升300%至500%的区间 [5]，并称非技术人员可完成约80%的基础开发工作 [5]。把这些读数连起来，很容易得出一个结论：边界在向上移动，而且移动得很快。

市场共识：低代码的边界就是「能搭什么」。只要平台把组件做够、把模型做对，业务人员的搭建能力就会持续向上扩张，最终覆盖大部分企业应用。支持这一判断的读数确实存在——公开报道引用的第三方数据显示，2025年上半年中国低代码和零代码软件市场规模达到21.1亿元、同比增长21.4% [4]；另一组公开调研给出开发效率提升300%至500%的区间 [5]，并称非技术人员可完成约80%的基础开发工作 [5]。把这些读数连起来，很容易得出一个结论：边界在向上移动，而且移动得很快。

我们认为：把「能搭出来」等同于「值得留在平台上」，是低代码讨论中最常见的一次口径替换。搭建时长只是成本的一侧，另一侧是迁移成本——当业务在平台上跑起来之后，想把它挪走需要付出多少。这两项成本的方向恰好相反：平台为了降低搭建时长，倾向于把逻辑沉淀到平台自身的模型、组件与流程引擎里；而迁移成本恰恰由这些沉淀决定。因此搭建越容易的应用，往往越难离开平台；搭建时长与迁移成本不是两个独立的指标，而是同一枚硬币的两面。

1. 第一，公开市场读数的口径差异接近三倍。按2025年上半年21.1亿元的年化口径推算全年约42.2亿元（测算，分子21.1亿元、乘数2、单位为亿元、年份2025年）[4]，而同期另一些公开报道引用的中国低代码市场规模读数为118.4亿元与131亿元 [4]，后者约为前者的2.81倍与3.10倍（测算）[8]。这一差距不是增速分歧，而是统计范围分歧——是否包含零代码、是否包含平台配套服务、是否包含已并入其他产品线的收入，都会显著改变结果；
2. 第二，效率提升的区间上限与下限相差近一倍，且测的是搭建环节而非全生命周期。公开调研给出的300%至500%提升 [5]，换算到搭建时长上相当于把时长压缩到原来的四分之一至六分之一（测算）[9]。但迁移成本发生在生命周期末端，不在这一区间的测量范围内；
3. 第三，产业底座的条件已经相对完备。截至2025年6月底，全国工业企业数字化研发设计工具普及率达到84.0%、关键工序数控化率达到66.8%，具有一定影响力的工业互联网平台超过340家、重点平台设备连接数超1亿台（套）、服务企业近400万家次并覆盖41个工业大类 [7]。这意味着搭建类工具面对的不是「有没有数据」的问题，而是「这些数据被谁承载」的问题——而承载方一旦确定，迁移成本随之确定。

要理解这一反向关系，先要看搭建类工具降低时长的三条具体路径。第一条是组件复用：把常见的表单、列表、报表、流程节点做成可拖拽的组件，业务人员通过组合而非编写实现功能。第二条是模型内嵌：把数据关系、权限规则、审批流向定义在平台的元数据模型中，由平台负责执行。第三条是逻辑下沉：把校验、计算、触发等业务逻辑写进平台的表达式中，而不是写在独立的代码里。三条路径都真实地缩短了搭建时间，但它们的共同特征是——业务知识被翻译成平台自己的语言。

迁移成本恰恰由这一翻译过程决定。如果业务逻辑以通用代码或开放标准描述，迁移意味着搬走一份可读的文本；如果业务逻辑以平台元数据与专有表达式描述，迁移意味着重新理解一遍业务、再用目标平台的语法重写一次。重写的成本与原来搭建的成本同量级，甚至更高——因为原搭建过程中的隐性决策（为什么这样拆表、为什么这样设权限）通常不会被完整记录下来。

由此可以给出一条可操作的判别标准：一项应用的迁移成本，约等于它在平台内积累的自定义逻辑量的函数。表单字段与列表视图这类结构性配置的迁移成本低，因为它们的语义在平台之间基本一致；而审批流分支、校验表达式与自动触发这类逻辑性配置的迁移成本高，因为它们的语义高度依赖具体平台的执行模型。这个判别标准不需要知道平台的技术细节，只需要数一数业务逻辑中有多少条自定义规则。

还需要区分两类不同的「迁移」。第一类是横向迁移，即从一个平台搬到另一个同类平台，成本主要由逻辑重写决定。第二类是纵向迁出，即从低代码平台搬到自研系统或标准软件产品，成本除了逻辑重写之外，还包含数据模型的重构与既有流程的再设计。公开报道中关于平台选型的讨论多集中在横向迁移 [4]，但实践中成本更高的往往是纵向迁出，因为后者的目标形态与原平台的抽象层级不同。

把两项成本做成可比较的量，需要各自的一个度量口径。搭建时长的度量相对直接：以「从需求确认到应用上线」的自然日或工时计，并规定起点与终点的判定标准，避免把需求反复算进时长。迁移成本的度量更复杂，本报告把它拆成三项：逻辑重写工时、数据模型重构工时、以及并行运行期间的双轨维护工时。三项之和与原始搭建工时之比，即为迁移的相对成本。

这张表里的最后一列是本报告认为最需要留意的地方。四项度量中，只有搭建时长容易被精确测量，其余三项都容易在事前被低估，其中双轨维护工时的低估幅度最大——并行期通常由业务节奏而非技术进度决定，而技术侧往往无法控制并行期的长度。这意味着在选型阶段用搭建时长做比较，会系统性地偏向「搭建最快」的方案，而忽略生命周期末端的成本。

度量还需要一个产业底座的口径。截至2025年6月底，全国工业企业数字化研发设计工具普及率为84.0%、关键工序数控化率为66.8%；具有一定影响力的工业互联网平台超过340家，重点平台设备连接数超1亿台（套），服务企业近400万家次，覆盖41个工业大类 [7]。按前三家平台的非官方口径份额合计76.4%计算（测算，27.2%加26.7%加22.5%），头部集中度处于较高水平 [7][10]。这一结构说明搭建类工具面对的是一个已经有主干承载方的市场，新进入者更多是在主干之上补充场景，而不是从零构建。

接入与研发层面的背景读数同样需要给出。世界银行年度序列口径下，2025年个人使用互联网的比例为91.6%、2024年为92%、2023年为90.6% [1]；2024年每百人移动电话订阅数为131.754 [2]；2023年研发支出占国内生产总值比重为2.577%、2022年为2.494% [3]。这组数字给出两个含义：其一是使用者侧的接入条件已经完备，搭建类工具的推广不受终端与网络约束；其二是研发投入强度逐年上升，说明需要被承载与管理的业务复杂度仍在增长。两者合起来意味着，搭建类工具的需求来源不会消失，问题只在于这些需求最终由谁承载。

第一条证据是市场规模的口径差异。公开报道引用的第三方数据显示，2025年上半年中国低代码和零代码软件市场规模为21.1亿元、同比增长21.4% [4]；同一篇报道中另引两家机构的预测，中国低代码市场规模将分别达到118.4亿元与131.0亿元 [4]。把半年读数年化得到约42.2亿元（测算）[4][8]，与后两个读数相比分别相差2.81倍与3.10倍（测算）[8]。三个读数同时出现在同一篇报道中，说明口径差异在业内是公开事实，而不是某一家机构的估算偏差。

第二条证据是效率区间。公开调研给出的开发效率提升为300%至500% [5]，并称非技术人员可完成约80%的基础开发工作 [5]。这两个读数需要一起看：效率提升的区间下限与上限之间相差近一倍，说明「提升多少」高度依赖具体场景；而80%这一比例同样是一个区间性的经验值，其含义是剩余约20%的工作仍需专业人员介入。把两个读数放在一起，可以得出一个谨慎的表述——低代码压缩的是标准场景的搭建时长，而不是整个交付链条的时长。

第三条证据是项目结构。公开资料显示，某头部平台已服务超过500家国内外大型头部企业客户，其中中国《财富》500强企业中有154家与其合作、中国制造业500强企业中有167家与其合作，累计实现1000多个项目落地 [6]。按这一组读数推算，平均每家客户对应的项目数约为2.0个（测算，分子1000余个项目、分母500余家客户、单位为个项目每家、年份截至2026年）[6][15]。这一比例说明头部平台的项目以定制化交付为主，而非标准化产品的批量复制——如果以产品复制为主，单客户项目数会更低而客户数会更高。

第四条证据是产业侧的技术底座。截至2025年6月底，全国工业企业数字化研发设计工具普及率84.0%、关键工序数控化率66.8%；工业互联网平台超过340家，重点平台设备连接数超1亿台（套），服务企业近400万家次，覆盖41个工业大类；2025年上半年软件业务收入70585亿元、同比增长11.9%，其中云计算与大数据服务收入7434亿元、同比增长12.1% [7]。这组读数的意义在于界定了搭建类工具的市场位置——它不是一个待开发的新市场，而是在既有数字化底座上增加的一层配置能力。

把四条证据连起来可以看到一个共同特征：所有公开读数都是「供给侧读数」——市场规模、厂商份额、效率提升、平台数量，全部描述的是供给方能够提供什么。而判断适用边界所需要的「需求侧读数」——企业把应用搭出来之后是否长期留在平台上、迁移过多少次、迁移后返工多少——在公开渠道中几乎不可得。这一不对称决定了本报告的方法选择：用结构测算表达关系方向，并明确标注全部参数的假设性质。

在把业务放到平台上之前，需要回答三个问题，它们共同决定这项应用是否适合用搭建类工具承载。第一个问题是生命周期：这项业务逻辑预计使用多久。若短于一年，迁移成本的折现价值很低，可以放心使用搭建设施；若长于三年，迁移成本会在生命周期内至少出现一次，需要在选型时纳入考量。第二个问题是逻辑密度：业务规则中有多少条是自定义的、平台无法用标准组件表达。逻辑密度越高，迁移成本越高。第三个问题是数据边界：应用涉及的数据是否会与外部系统交互，交互越多，纵向迁出的成本越高。

三个问题的答案可以用一张二维表来组织：横轴是生命周期长度，纵轴是逻辑密度。落在「长周期、高逻辑密度」格位的应用应当谨慎使用深度绑定平台的方式承载；落在「短周期、低逻辑密度」格位的应用则可以优先考虑搭建类工具，因为它们的主要价值在于快速响应。中间两个格位需要按数据边界进一步判断。

这张表的价值在于把选型讨论从「平台功能够不够」转向「这类应用适不适合」。同一家企业在不同格位上会得出不同结论：把临时活动报名放到平台上是最优选择，把跨部门结算流程全部放到平台上则需要在选型阶段就考虑退出路径。多数选型失误来自把两类应用放进同一套评价标准里。

落到执行层面，还需要一张检查表，用来在搭建完成后评估这项应用的迁移成本。检查表的判据是「不问平台、只问配置」：数一数应用中有多少条自定义规则、多少处调用了平台的专有表达式、多少个流程节点的条件由平台内嵌逻辑判断。这三类配置的数量之和即为逻辑密度的一个代理值。

检查表的用途不是给应用打分，而是在搭建过程中留下可迁移的痕迹。具体做法有两条：一是把自定义规则的文本单独留存一份，不依赖平台的展示界面；二是把关键业务规则同时写在应用之外的文档中，并在每次迭代时更新。两条做法的成本很低，但它们把迁移时的「重新理解业务」变成了「读取已有记录」，直接削减了逻辑重写工时中最难估量的部分。

本报告有三处边界需要先说明。第一处是行业边界。本报告讨论的是企业业务应用的搭建，不包括面向消费者的应用与嵌入式系统——后两类的生命周期、性能要求与合规约束与本报告的框架不同。第二处是规模边界。中小企业的应用结构相对简单，逻辑密度低，本报告关于迁移成本的判断在中小企业场景下权重较低。第三处是时间边界。平台能力在快速变化，今天的迁移成本不等于三年后的迁移成本，本报告的判断基于当前公开可得的平台能力描述。

第一类反面证据针对「迁移成本由平台绑定决定」这一判断。如果企业在搭建之初就把业务规则以文本形式独立留存，并且把应用的边界切得足够小（每个应用只承载一段独立流程），那么迁移时可以逐个应用替换，单次迁移的重写工作量被压缩到很小。这一情形在实践中确实存在，本报告把它视为对判断的重要限定——迁移成本并非完全由平台决定，应用设计与文档习惯同样起作用。

第二类反面证据针对效率区间。公开调研给出的300%至500%提升 [5] 对应的是标准场景；如果企业的业务规则以例外处理为主，那么组件复用与模型内嵌的收益都会显著下降。更麻烦的是，这类应用在被拆解为平台配置时，可能会把原本可以灵活处理的例外情况固化下来，反而降低业务响应速度。也就是说，效率提升的反面不是「提升得少」，而可能是「负提升」。

第三类反面证据针对口径差异的解释。本报告把公开市场读数的2.81至3.10倍差异归因于统计范围不同（测算）[8]，但如果差异实际来自增速假设的不同（例如其中一组读数包含了更长的预测期），那么本报告关于「口径分歧」的表述需要修正。公开报道没有给出每个读数所采用的统计范围细节 [4]，因此这一归因的强度属于中等，本报告把它标注为需要后续核对的判断。

这张表把四处反面证据与它们各自要推翻的判断、所需的观察以及现有读数的支持程度列在一起。可以看到，四处之中有三处都指向同一个信息缺口：迁移相关的实测数据。这意味着本报告第五章的判断虽然是全文的支点，却是证据强度最弱的一章；读者在使用时应把它当作方向性表述，而不是已证事实。

第一组测算把公开的效率区间换算成时长。以原始搭建时长为100个基准单位，效率提升300%对应时长降至25个单位，提升500%对应降至约16.7个单位（测算，分子100个单位、分母分别为4与6、单位为基准单位、年份2025年）[5][9]。这一换算的意义在于把「提升几倍」这个容易混淆的表述转换为可直接比较的时长。需要注意的是，300%提升与500%提升对应的时长分别是四分之一与六分之一，两者相差约1.5倍，而不是表面上看起来的两倍。

第二组测算给出迁移的相对成本。把迁移成本拆成逻辑重写、模型重构与双轨维护三项，并按三档假设取值：逻辑重写分别取原搭建时长的30%、60%与100%，模型重构取10%、25%与45%，双轨维护取10%、20%与35%。三档合计的相对成本分别为50%、105%与180%（测算）[10]。中档情景下迁移成本已经略高于原始搭建成本，高档情景下接近两倍。这一结果解释了为什么企业即便对平台不满意，也倾向于继续使用而不是更换。

第三组测算给出逻辑留存的收益。如果企业把自定义业务规则以独立文本形式留存，逻辑重写环节中「重新理解业务」这一部分的工作量可以被压缩。按结构假设，理解环节占逻辑重写工时的比重按三档分别取30%与50%以及70%，对应迁移总成本的下降幅度约为15%、30%与42%（测算）[11]。这一测算说明文档习惯的收益是真实但有限的——它能削减理解成本，不能削减重写与验证成本。

第四组测算把视角转到产业侧的目标距离。截至2025年6月底关键工序数控化率为66.8% [7]，若以75%作为中期目标，需要提升8.2个百分点（测算，75%减66.8%）；若以两年为达成期，年均需要提升约4.1个百分点（测算，分子8.2个百分点、分母2年）[12]。这一读数与搭建类工具的关系在于：数控化率的提升意味着更多工序具备了被配置化承载的条件，搭建类工具的潜在对象随之扩大；但对象扩大不改变迁移成本的结构，只是把这个问题暴露在更多的业务场景中。

这张表把四组测算的参数、结论方向与适用限制列在一起，读者可以按自己的参数替换后重新计算。需要再次强调，除效率区间与数控化率来自公开读数外，其余参数均为结构假设；其中三项迁移成本的取值、理解环节占比以及75%的中期目标值都没有公开数据支撑。因此四组测算的作用限于说明关系的方向与量级，不能用于推导任何具体项目的成本预算。

跟踪这套判断需要五个指标。第一个是平台导出能力的实际范围，包括能否导出流程逻辑而不仅是数据，可得性高且直接改变迁移成本的分母。第二个是逻辑密度，即单个应用中自定义规则的数量，可得性高但需要企业自己统计。第三个是应用的更换率，即每年被替换或迁移的应用占存量的比例，可得性低但验证力最高。第四个是迁移返工量，可得性低。第五个是统计口径的统一程度，即可比的市场规模读数是否趋于一致，可得性中等。

五个指标中，第一个与第二个构成一组：前者是平台侧的条件，后者是应用侧的现状，两者相乘决定迁移的实际难度。第三与第四个指标虽然验证力最高，但只能通过企业内部记录获得，公开渠道无法观测。第五个指标用于校准本报告引用的市场读数的可比性。

还需要提示两处口径风险。第一处是市场规模读数的可比性：本报告引用的三个读数分别来自不同机构的不同统计范围 [4]，把它们放在同一张图上比较时必须标注口径来源，否则会得出错误的增速结论。第二处是效率区间的适用性：300%至500%这一区间针对的是标准场景 [5]，把它当作普遍水平会高估搭建类工具在例外密集场景下的价值。

把跟踪指标与风险提示放在一起，可以得到一个关于这条赛道的基本判断：搭建类工具的价值在于压缩响应时间，这一点在公开读数中得到了支持 [4][5]；而它的代价在于把业务知识转化为平台专属的形态，这一点在公开读数中几乎没有对应数据。因此选型决策的实质不是比较功能，而是判断这项业务的知识值得以什么形式沉淀。

最后需要说明本报告的适用与不适用情形。本报告适用于企业业务应用在搭建类工具与独立开发之间的承载方式选择，也适用于既有应用的迁移成本评估；不适用于面向消费者的应用开发、不适用于嵌入式与工业控制场景，也不适用于对外提供的标准化软件产品的技术选型 [4][7]。

本报告的核心判断是：低代码的边界不在「能搭什么」，而在「搭完之后能不能走」。公开读数充分支持搭建能力的扩张——市场规模以两位数增长 [4]，效率提升区间达到300%至500% [5]，产业侧的数控化率与平台承载规模已经相当可观 [7]。但支撑这一扩张的机制本身，就是把业务知识翻译成平台专属形态的过程，而翻译的深度决定了迁移的成本。

从机制看，压缩搭建时长的三条路径（组件复用、模型内嵌、逻辑下沉）同时抬高了迁移成本，两者由同一个动作产生，因此不会自动分离。这一机制解释了为什么企业在平台不满意时仍倾向于继续使用。

从度量看，迁移成本可以拆成逻辑重写、模型重构与双轨维护三项，其中双轨维护最容易在事前被低估，因为它由业务节奏而非技术进度决定。

从测算看，三档假设下迁移成本相对原始搭建成本的比值分别约为50%、105%与180%（测算）[10]；逻辑留存带来的成本下降约为15%至42%（测算）[11]。

从方案看，选型前应当回答生命周期、逻辑密度与数据边界三个问题，并把答案落在二维表上；搭建完成后应当把自定义规则独立留存，以削减迁移时的理解成本。

从跟踪看，平台导出能力与逻辑密度是可得性最高的两个指标，应用更换率与迁移返工量验证力最高但不可公开观测 [13]。

最后需要重复一处重要限定：本报告的全部迁移成本数值均为结构测算，参数来自结构假设而非实测 [10][11]。读者在使用这些数值时，应把它们当作关系方向的说明，而不是可直接引用的成本预算。真正可靠的判断只能来自企业自身的迁移记录。

本报告的判断建立在两类材料之上。第一类是公开可得的外部读数，包括世界银行的年度序列数据、公开报道转引的第三方机构市场规模与份额读数、公开调研给出的效率区间，以及主管机关公开的产业数字化读数。第二类是本报告自身的结构测算，其参数取值与单位在附录 C 中逐条列出。

需要特别说明的是市场类读数的口径问题。本报告引用的三个市场规模读数来自不同机构的公开披露，其统计范围可能分别包含或排除零代码产品、平台配套服务与已并入其他产品线的收入，因此不能直接相减或比较增速 [4]。本报告在使用这些读数时，只把它们作为量级的参照，不用于推导任何具体厂商的份额或增长。

本报告在引用公开调研的效率区间时，只引用区间本身，不引用其调查方法细节；在引用企业项目结构时，只引用公开资料载明的客户数与项目数，不据此推断单个项目的规模或价格 [5][6]。

表中的每一组口径都对应一处容易混淆的表达。最常见的混淆是把搭建时长当作总交付成本，以及把数据搬迁当作迁移的全部内容——实际上数据搬迁在多数项目中是可自动化的部分，真正耗时的是业务逻辑的重写与验证。

表中标记为结构假设的参数全部由本报告设定，没有外部数据来源。它们的取值依据是使关系方向可被清晰表达。读者若采用不同的取值，结论的方向不变，具体数值会随之变化。

还需说明一处对称性处理。本报告在迁移成本三项上使用了不同的三档取值，而不是统一比例，原因是三项成本的驱动因素不同——逻辑重写取决于定制程度，模型重构取决于数据结构，双轨维护取决于业务连续性要求。这一差异在第六章的适用限制中已有说明 [10][11]。