简介：这份头豹研究院2022年中国低代码无代码平台行业研究报告，面向企业数字化选型人员、低代码厂商从业者及行业研究者，系统回答低代码/无代码平台如何快速构建企业数字化应用。报告从定义与分类切入，辨析低代码与无代码在用户群体、开发效率、技术要求及适用企业上的差异，并梳理发展历程、平台架构、四种商业模式、公有云与私有化部署的收费及维护差异，进一步分析产业链参与者、投融资情况与盈利挑战，提及简道云、伙伴云、轻流等头部厂商的微利现象。资源包内含1个PDF文件，大小3.43MB，便于检索、引用和离线阅读。已有111人学习，可作为数字化选型、竞品研究与投资判断的案头参考，帮助读者快速建立行业分析框架，理解厂商分类、部署方式、续费率与成本压力等关键问题。

1. 30%、266.7%、71.4%：三个数字先划出低代码行业的真实地形

2022年11月，一份题为《2022年中国低代码无代码平台行业研究报告》的材料把低代码无代码平台行业的家底摊开在几十页里，三个数字最扎眼：制造业在低代码应用场景中的占比达到30%，排在所有行业第一；2021年国内低代码赛道投融资事件11起，同比增长266.7%；A轮及以前的融资占比从2017年的66.7%走到2022年的71.4%，五年几乎没挪位置。第一个数字说明需求最实在的行业，恰恰是标准化最难落地的行业；第二个说明资本在疫情之后集体押注；第三个说明热度归热度，这个赛道至今仍停在早期。三者拼在一起，是一条从「概念热」转向「交付考验」的分水岭。值得从业者关注的原因不在于报告列了多少厂商，而在于它给了一套能判断厂商活不活得下去、采购方会不会踩坑的坐标系。

2. 定义与分野：低代码和无代码不是同一门生意

2.1 快2倍与快8倍：被混卖的两种工具

报告对低代码开发平台的定义是「通过少量代码快速生成应用程序的开发平台」，用户借助图形化界面、拖拽组件和模型驱动的逻辑来创建网页应用和移动应用。广义上的低代码包含两层：低代码是少量代码即可搭建，无代码是完全不写代码即可搭建。这两者在销售话术里经常被揉成一团，但在产品逻辑、用户画像和交付方式上差异很大，把它们当成一件事去谈，后面的预算、周期、续费都会跟着错位。

报告中给出的一组对比很直白：低代码面向有编程基础的IT人员，速度约为传统开发的2倍，易用性相对较低，需要具备代码知识，个性化程度相对较高，适合有资金、有研发团队的中大型企业，也更适合较复杂的应用场景；无代码面向没有编程基础的业务人员，速度约为传统开发的8倍，易用性高，无需代码知识，个性化程度相对较低，适合没有研发团队、软件需求紧急、业务变化较快的中小企业，或者中大型企业里的某个部门、某个项目。速度差出四倍，本质上不是引擎强弱，而是「谁在定义逻辑」的差别——一个把逻辑留给懂代码的人，一个把逻辑封装进控件里。

两类产品的主要变现形式都是aPaaS，也就是应用程序平台即服务。开发过程中不需要自建服务器、中间件等IT基础设施，用户通过「拖、拉、拽」创建应用，把应用程序的开发成本压下来。这里有个容易被忽略的细节：aPaaS的交付形态决定了厂商必须持续在线更新，客户买到的不是一个可以封存的软件包，而是一段持续被维护的能力。这也是后面续费率问题会如此致命的原因。

从行业角度看，低代码和无代码的分野，其实是两门生意的分野。低代码卖的是「专业开发者的效率杠杆」，客户内部有技术判断力，能自己对结果负责；无代码卖的是「业务人员的自助能力」，客户内部往往没有技术判断力，厂商和渠道要替客户承担一部分「把流程想清楚」的工作。前者的交付物是工具，后者的交付物是工具加方法。行业里常见的一种翻车现场，就是把无代码产品卖给了一个流程尚未梳理清楚的部门，最后客户觉得「搭不出来」，厂商觉得「需求不清」，双方都不满意。

2.2 平台层六大引擎：采购时该看的那张清单

各厂商的低代码平台产品形态各异，但架构大体自下而上分为基础层、平台层和应用层，低代码、无代码技术主要作用在平台层，这一层是应用生产的引擎。报告以某低代码平台的架构为例，把平台层拆成六大运行引擎，这套拆法值得拿来当选型的检查表。

数据模型引擎负责内建小型数据库、直连主流数据库，提供可视化的数据模型与查询视图设计能力；业务逻辑引擎提供可视化逻辑设计与调试，可以自由编排运行于服务器和页面的业务逻辑，实现前后端分离；工作流引擎支持自由定制流程中各节点的规则和关联业务处理，支持流程的编排与调整；页面渲染引擎用可视化页面设计器集成开箱即用的UI组件和外观样式，支持固定布局与响应式布局，页面元素位置和样式可任意调整；智能报表引擎提供专业级报表设计能力，支持定制统计报表、复杂报表、类Word报告；系统集成引擎提供数据库直连、WebAPI构建与调用、用户认证与权限同步机制等能力。

基础层对应的是物理机、云主机、操作系统、关系型数据库与国产数据库，以及基于容器编排的云原生架构；应用层对应大屏展示、PC端、移动端、第三方协同平台内的入口，以及嵌入ERP、CRM、OA、MES、物流管理、设备运维、客服工单等业务系统的页面。三层的关系不难理解：基础层决定跑在哪，平台层决定能做什么，应用层决定交付成什么样。

这六个引擎在标准化难度上完全不是一个量级。页面渲染引擎最容易同质化，组件库里堆得足够多，演示效果就足够好；智能报表引擎的差异体现在复杂报表和中国式报表这类细节上；而工作流引擎和系统集成引擎最难标准化，因为它们必须贴着企业既有的流程和既有的系统走，每家企业的审批链路、权限体系、历史数据结构都不一样。数据模型引擎和业务逻辑引擎处在中间，做深了很值钱，做浅了也能用。

提示：评估一个平台，看演示界面只能判断页面渲染引擎的水平。真正决定项目能不能落地的是集成引擎和工作流引擎，而这两个恰好最难在演示里看清。

有个实操中的判断方法：让对方拿你企业真实的一条流程走一遍，从建表、配权限、设节点规则，到调用一个外部系统的接口取数回填。整个过程不需要写太多代码，但一定会暴露集成引擎的深浅。能做通的平台，后续大概率不会在「数据进不来、权限对不上」这类问题上反复折腾；做不通的平台，销售会告诉你「这个可以定制」，而定制就意味着项目制的报价和周期。

2.3 五十年时间线：概念比技术晚了很久才落地

报告梳理的发展脉络值得单独看一眼，因为它解释了为什么这个行业的产品成熟度和市场期待之间存在落差。「低代码」这个概念是某知名市场研究机构在2014年提出的，但背后的逻辑可以追到上世纪70年代。

1970年至1990年是萌芽期。第四代编程语言出现，包括支持数据库管理、报告生成、数学优化、图形界面开发和Web开发的非过程化高级语言，把一批重复性的编码工作收进了语言层。1990年前后，通过可视化编程工具「组装」桌面应用程序开始流行，快速应用程序开发（RAD）获得势头，核心理念是让最终用户先关注界面，再逐步添加业务逻辑。但RAD的局限也很明显：开发环境特定，缺乏模块化，多人协作困难。

2001年，对象管理组织推出模型驱动架构（MDA），把开发过程拆成需求捕获、需求分析、设计、编码、测试、部署发布，为提升软件复用性、可移植性和可维护性指明了方向。2007年至2008年，移动设备市场起来，各类移动平台涌现，开发者用本地可视化编辑器开发移动应用。2014年概念正式命名，低代码在云计算加持下加速。2020年疫情把企业数字化转型的紧迫性顶到台前，应用程序开发和升级的需求激增，低代码普及率随之抬升，同时互联网大厂开始入局。

这条时间线给出的信号是：低代码不是新技术，而是旧思路在新基础设施上的重新打包。第四代语言解决的是「少写代码」，RAD解决的是「可视化拖拉」，MDA解决的是「流程分段」，云解决的是「交付与运维」。四件事拼齐，才有了今天的产品形态。理解这一点，就能理解为什么很多平台在演示时看着都差不多——它们共用了同一套思想源头，差别在于哪一段被做深了。

对从业者的实际影响在于，评估供应商时要问清楚它继承的是哪条脉络。偏语言的团队往往在数据模型和业务逻辑上更强，适合复杂应用；偏可视化编辑器的团队往往在页面和表单上更顺，适合轻量场景；偏模型驱动的团队通常在流程和集成上更成体系，适合和既有系统对接。问一句「你们最早做的是哪一块」，往往比看二十页PPT更能判断产品的重心在哪。

3. 商业模式与部署：四种打法、两条交付路径背后的账

3.1 四种模式：谁赚产品钱，谁赚服务钱，谁赚授权钱

低代码厂商的商业模式是向企业客户提供平台产品和服务，通过按年付费的形式实现营收，并追求一个良好的续费率。报告把这门生意拆成四种模式，这个拆法对判断一家厂商的定位很有用。

直接面向客户模式是厂商直接对企业客户交付，用付费订阅提供产品，满足通用性开发需求；如果平台上的通用模块满足不了场景需求，就叠加定制化开发服务，用「产品+项目实施」的方式交付。这是当下的主流模式。它的优点是客户关系在自己手里，续费路径清晰；缺点是实施人力会随客户数线性增长，毛利被服务吃掉一块。

间接面向客户模式是厂商把相对通用的产品直接卖给企业客户，定制化需求交给第三方ISV、咨询公司等合作伙伴实施。厂商赚产品费，伙伴赚实施服务费。这种模式的杠杆更高，但厂商对交付质量的控制力会下降，一旦伙伴实施翻车，客户记住的是平台的名字。

前后端开发平台模式是面向软件开发商，提供前端或后端开发所需的框架、插件、控件、组件，用云原生、微服务架构、DevOps等理念帮软件公司提升效率，减少开发人员的编码量。这类客户技术能力强，对产品缺陷的容忍度低，但对价格相对不敏感，一旦嵌入开发流程就很难替换。

生态型平台模式是厂商不直接交付产品给最终客户，而是赚取授权费用，在平台上集结专业开发者、软件开发商、ISV等伙伴，制定开发标准和交易规则，由生态去服务下游。报告明确提到这一模式尚处早期，对厂商的低代码产品能力和生态建设能力要求都高。

从行业角度看，这四种模式的差别，本质是「服务密度」由谁承担。直接模式自己扛，间接模式分给伙伴，前后端模式把服务推给软件公司，生态模式试图用规则替代人力。服务密度越高的模式，早期收入越稳，规模化越难；服务密度越低的模式，规模化越快，对产品成熟度的要求越苛刻。一家厂商在什么阶段选什么模式，基本能看出它对自己的产品有多少信心。

对采购方来说，这套拆法有一个直接用处：签合同前先弄清楚自己买的是产品还是项目。如果销售在演示时讲的是标准模块，报价单上写的却是实施人天，那本质上买的是项目，续费时考核的应该是「这套东西有没有长在自己的流程上」，而不是「功能列表对没对上」。

3.2 公有云几千元一年、私有化百万级：部署是一次成本结构选择

部署方式分公有云和私有化两条路，报告给出的对比相当具体。公有云SaaS部署前期投入低，通常按低代码模块数量和使用时长周期付费，后续增加模块要额外付费；私有化部署价格较高，企业需自购服务器等硬件，但后续再度开发不再额外收费。价格量级上，公有云产品通常在几千元人民币每年，私有化则因定制化开发和对接，费用在百万级人民币不等，包含平台打包安装费用和按年更新费用。

报告里有个判断值得留意：目前大多数成功交付的低代码平台产品是公有云方式部署。得益于低成本和短部署周期，公有云形态在国内发展更快，企业希望通过它快速开发应用来拓展业务。这句话的反面是，私有化项目的失败率往往被低估——周期长、对接多、责任边界模糊，任何一环出问题都会拖成交付泥潭。

要把这笔账算清楚，光看年费乘年数是不够的。下面这段粗算把两类部署的三年总拥有成本放在一起对比，参数可以按自己企业的实际情况改：

# 低代码平台三年总拥有成本（TCO）粗算，仅示意口径，不代表任何厂商报价 def tco_public_cloud(modules, price_per_module_year, years, addon_rate=0.15): """公有云：按模块数 x 单模块年费 x 年数，假设每年有 addon_rate 比例的模块增购""" total = 0.0 current = modules for _ in range(years): total += current * price_per_module_year # 当年订阅费 current *= (1 + addon_rate) # 模块逐年增购 return round(total, 2) def tco_private(license_fee, hardware_fee, impl_days, day_rate, ops_fte, ops_cost_year, years, upgrade_fee=0.0): """私有化：许可证 + 硬件 + 实施人天 + 每年运维人力 + 年度升级费""" impl = impl_days * day_rate # 实施与对接成本 ops = ops_fte * ops_cost_year * years # 运维人力，常被漏算 upgrade = upgrade_fee * (years - 1) # 升级费，首年通常不收 return round(license_fee + hardware_fee + impl + ops + upgrade, 2) # 示例参数：20 个模块、单模块 3000 元/年、3 年 print(tco_public_cloud(20, 3000, 3)) # -> 约 20.8 万 # 示例参数：许可 80 万、硬件 30 万、实施 60 人天 x 2500 元、0.5 个运维人力 x 25 万/年 print(tco_private(800000, 300000, 60, 2500, 0.5, 250000, 3, 50000))

这段代码的关键不在算得准，而在把容易被忽略的成本项显性化。公有云侧要关注的是模块增购率，业务一旦跑起来，模块数往往每年往上走，三年账不能按第一年的模块数乘三。私有化侧的三个坑更隐蔽：实施人天会随对接系统数量膨胀；运维人力几乎必然要占掉半个人；年度升级费在合同里常常以「按年更新」的名义出现。把这三项填进去，很多看起来「私有化更划算」的方案会立刻反转。

注意：拿公有云年费乘三年，去和私有化的许可证报价对比，是最常见的一种算错账方式。私有化的真实成本大头在实施和运维，这两项不在报价单首页。

反过来，只算钱也不算完整。报告提到，对数据安全要求高、希望平台稳定可靠、内部有其他系统需要对接集成、业务场景复杂且有自主服务器和技术团队的企业，更偏好私有化，这类企业大多集中在金融和电信领域。也就是说，私有化的合理性来自集成深度和数据边界，不是来自「更高级」。一家流程简单、没有技术团队的中小企业选私有化，通常会在第二年发现没人维护、没人迭代，平台慢慢变成一套昂贵的静态资产。

3.3 30%—40%研发、40%—50%服务：厂商盈利的算术题

报告对成本结构的拆解很直接：产品成本主要涵盖研发成本和服务售后成本。研发成本并非来自极高的技术难度，而是来自日常的更新和迭代。随着客户数量增加和业务场景拓宽，客户对平台场景覆盖度的要求同步抬升，研发团队必须保证一定频率的更新和功能改动，才能满足需求。如果更新进度跟不上企业业务的变化，续费率就难以保障。服务与售后成本则体现在对企业管理员的培训，以及对企业搭建应用的协助上。人员结构上，研发人员团队占比约30%—40%，服务人员团队占比约40%—50%。

这个比例说明一件事：低代码厂商不是典型的软件产品公司。纯软件产品公司的服务人力占比通常在个位数到十几个百分点，而这里接近一半。服务密度这么高，意味着收入必须靠客户数摊薄，客户数又受制于实施人力，形成一个不太好破的循环。

续费率低的三个原因，报告写得很坦白：企业采购后发现业务场景不匹配；自主搭建应用不顺利；于是不再续费，或者更换供应商。加上经济下行让中小企业采购预算下滑，新客增量近两年逐渐减少。高成本和低营收叠加，多数厂商处于亏损状态，仅少数头部厂商能实现轻微盈利。

从行业角度看，这是一门需要跨过规模拐点才能盈利的生意，而拐点的位置取决于两件事：产品能不能把服务人力占比压下来，客户能不能把使用深度提上去。前者靠引擎成熟度和模板沉淀，后者靠场景匹配度和咨询能力。两者互为因果——产品越成熟，客户越容易搭出东西；客户用得越深，反馈越能推动产品迭代。反过来的负循环同样成立，而且更快：场景不匹配导致搭建失败，搭建失败导致不续费，不续费导致研发投入受限，研发受限导致场景覆盖更窄。

对厂商的实际建议是，把服务人力的投入前置到售前的场景匹配环节，而不是后置到售后的救火环节。一单签下来但场景不匹配，收入是短期的，成本是长期的。对采购方来说，反过来看也有用：一家厂商愿意在签约前花时间帮你梳理流程、判断场景是否适配，通常说明它的续费率压力来自产品而不是销售，这类厂商更值得谈。

4. 产业链与需求侧：制造业30%的应用占比说明了什么

4.1 三类厂商的站位：独立、生态、云

报告从微观视角把厂商分成三类。独立厂商也叫原生厂商，自创立之初就专注低代码平台的研发与销售。生态厂商包含众多传统软件厂商，主营业务多为ERP、CRM、OA等企业管理软件，在发展过程中把产品线拓展到低代码，用来完善产品生态。互联网与云厂商则通过推出低代码平台，为自家的协同办公产品做功能补充。

按宏观视角还能再切一刀：低代码厂商服务中大型以及IT成熟度较高的企业，产品路径更偏开放，容器功能多但未必精细，用户需要用少量代码改到想要的形态，代表形态是云厂商和协同平台推出的平台型产品；无代码厂商服务缺乏IT支持的中小企业，把基础功能封装起来，用户只能调用已做好的能力，包括字段设定和数据处理，场景覆盖少但垂直功能精细，即拿即用。

这两刀切下去，地图就清楚了：独立厂商在中间地带最难受，往上打不过生态厂商的存量客户，往下打不过云厂商的入口；但它们也是最可能把平台做深的群体。对采购方的启示是，选独立厂商要看它的存活能力，选生态厂商要看低代码在其产品矩阵里的优先级，选云厂商要看复杂场景能不能撑住。

4.2 制造业30%背后的非标悖论

制造业以30%的应用占比排在第一位，零售20%，服务15%，国企、建筑、教育合计约5%，其余约30%分散在其他行业。这个分布乍看合理，细看有个明显的悖论：制造业生产过程中存在大量非标环节，从某种程度上并不适合标准化控件的低代码开发，但它偏偏是应用占比最高的行业。

报告给出的解释分两层。对中小微制造企业来说，采购传统ERP的费用极高，难以承受；传统ERP流程过于固化，找原厂改进功能又是一笔高昂成本。所以这类企业采购和续费低代码产品的关键点在于高性价比——他们要的不是功能最强，而是「够用且买得起、改得动」。对大型制造企业来说，ERP系统功能完善，不需要用低代码做复杂应用开发；如果有功能改进需求，通过API接口把低代码搭的应用和原有ERP连接起来，作为功能补充即可。

这个分层解释很关键，它说明制造业的30%里，真正做核心生产系统的是少数，大量是边缘应用：生产报工与跟踪、协同型供应商管理、进销存与订单管理、设备巡检、仓储盘点。这些场景的共同特点是流程相对固定、参与者不多、和核心系统的耦合度低，正好落在低代码的能力半径内。反过来，一旦碰上排产、工艺路线、质量追溯这类强耦合、强非标的环节，标准化控件就会顶不住。

从行业角度看，这30%更像是一个「缺口指标」而不是「成熟度指标」。它衡量的不是制造业数字化做得多好，而是传统软件在这个价位段留下的空白有多大。低代码填的是这块空白，填的方式是牺牲一部分深度换成本和速度。理解这一点，就能理解为什么制造业客户续费率的波动会那么大——当企业把边缘应用搭完之后，如果没有向深水区走的能力，需求就会阶段性饱和。

4.3 场景清单：从进销存到工程资金管理

报告列出的典型场景分布得相当散，可以当作一张需求地图来看。制造业侧有CRM、生产报工与跟踪、协同型供应商管理、进销存与订单管理；建筑业侧有工程进度管理、工程物资管理、工程资金管理、工程招标管理；零售侧有销售提成计算、通用仓库管理、订单售后服务、会员充值消费；教育侧有教师考勤、校园宿舍管理、校园公物报修；服务业侧有报修派单、电梯维修保养、门店巡检、餐饮管理系统；国企与政务侧有社区网格化管理、防控通知、防汛信息、政策查询；互联网侧有项目实施、售后服务、产品研发、目标管理；物流侧有仓储物流管理、进销存、车辆管理、订单管理。

把这张清单横着看，会发现一个规律：绝大多数场景都是「表单+流程+报表」的三件套，差别只在字段和节点。这也解释了为什么低代码产品的演示总能打动业务部门——业务部门看到的正是自己每天在用的那些表格和审批。而 IT 部门看到的则是另一面：这些应用一旦多起来，权限怎么统一、数据怎么打通、上线之后谁维护。

这也是选型时最容易分歧的地方。业务部门评估的是「能不能快速搭出来」，IT 部门评估的是「搭出来之后能不能管住」。两个问题都合理，但答案指向不同的产品。前者看页面渲染引擎和模板库，后者看数据模型引擎、系统集成引擎和权限体系。一个可行的折中是把首批试点场景限定在跨部门、有一定复杂度、但不碰核心交易链的位置，让两边都能在三个月内看到结果。

5. 五个容易被误读的判断

5.1 误判一：政策点名就等于市场爆发

误判点：2022年10月至11月，多份文件集中提到低代码。某部委印发的《中小企业数字化转型指南》提出细分行业数字化转型服务商研发推广具备行业特性的产品服务，低代码服务商持续提升产品的可拓展性，帮助业务人员自主高效构建数字化应用，满足即时个性化需求；同时提出服务商聚焦中小企业转型痛点难点，提供「小快轻准」的产品和解决方案，研发推广低代码产品服务，帮助中小企业自行创建、部署、使用和调整数字化应用，提升二次开发能力和需求响应能力。同期，某制造业大省的行动方案提出推进低代码开发等关键技术突破和产品研发应用，某一线城市的软件产业措施提出支持低代码、小程序、快应用等新型轻量化平台发展。很多人据此判断行业马上要起量。

为什么：政策文本里的动词是「研发推广」「提升」「支持」，指向的是供给端能力建设，不是采购预算。而且这份指南的落点是中小企业，而中小企业恰恰是预算最紧、续费率最低的那一端。政策给的是方向和口径，订单要靠场景和付费能力兑现。

怎么看：把政策当成交付标准来看，而不是当订单来看。「小快轻准」「可拓展性」「二次开发能力」「需求响应能力」这四个词，其实就是采购方可以写进验收条款的四条指标。厂商如果能把产品对接到这四条上，政策红利才会落到自己头上；接不上，政策只是新闻。

5.2 误判二：A轮占比高说明赛道年轻有活力

误判点：A轮及以前占比从2017年的66.7%到2022年的71.4%，看起来是典型的早期赛道特征，很多人读成「还有大量机会」。

为什么：这个数字五年基本没动，说明的不是「年轻」，而是「没有往后走」。正常的赛道演进里，早期项目占比应该逐年下降，B轮、C轮占比抬升，头部开始分化。占比停在七成，意味着大部分厂商没跨过A轮之后的关口，行业没有形成稳定的梯队。同期投融资事件数从2017年到2019年稳步增长，2020年降到低点，2021年回升到11起、同比增长266.7%，2022年前11个月又回落。曲线是情绪型的，不是结构型的。

怎么看：判断一个赛道成不成熟，看的是轮次分布的迁移速度，不是事件数的绝对值。对从业者来说，这意味着选型时不能只看融资新闻，要看厂商的收入结构和续费数据；对想进入这个领域的人来说，意味着窗口还在，但窗口里的位置比窗口本身更重要。

5.3 误判三：低代码是要替代程序员

误判点：无代码号称比传统开发快8倍，很容易被理解成「不需要开发人员了」。

为什么：报告里的产品分层已经给了反证——低代码面向有编程基础的IT人员，服务中大型及IT成熟度较高的企业；无代码面向无编程基础的业务人员，服务缺乏IT支持的中小企业。两条产品线对应两批人，谁也没被替代。更实际的情况是，低代码把开发人员从重复的增删改查里解放出来，让他们去做集成、权限、性能和核心逻辑；业务人员则接管了大量原本要排期三个月的小应用。

怎么看：把低代码当成团队结构的重新分配，而不是人员数量的削减。真正被压缩的是「排队等排期」这件事，不是岗位。反过来说，一个团队如果用了低代码但排期没变短，问题多半不在工具，而在需求受理和交付流程没跟着改。

5.4 误判四：续费率低是产品不行

误判点：报告提到客户续费率整体偏低，很多人的第一反应是产品功能不够。

为什么：报告列的原因有三条——场景不匹配、自主搭建不顺利、更换供应商。第一条是售前问题，第二条是交付与培训问题，第三条是竞争问题。三条里只有第二条和产品直接相关，而且更多指向咨询能力和模板沉淀，不是功能数量。报告在挑战部分说得很清楚：产品设立之初可以轻易满足简单需求，随着用户增多和场景搭建需求增加，越来越多产品难以完全符合用户的业务场景需求；同时标准化控件牺牲了一定灵活性，部分页面由标准控件组装而成，不能灵活定制，有时满足不了精细化需求。

怎么看：把续费率拆成三个可观测的指标——首月激活率、三个月内自建应用数、跨部门使用比例。首月激活率低是培训问题，三个月内自建应用数低是模板和场景问题，跨部门使用比例低是权限和集成问题。三个指标分别对应三种解法，混在一起谈「产品不行」只会得出无解的结论。

5.5 误判五：私有化部署更安全所以更好

误判点：数据放在自己服务器上，安全性更高，所以私有化是更优选择。

为什么：报告的安全对比说得很克制——公有云数据存在服务商公用服务器，由服务商维护，不确定性较高；私有化数据存在企业自有服务器，维护更可控，若发生故障需自行检修或按实际情况定制维护方案。注意后半句：故障要自己修。安全性和可用性不是一回事。一套放在自己机房但没人打补丁、没人做备份、没人盯监控的平台，实际风险可能高于一套由服务商统一运维的公有云。报告也指出，公有云目前是大多数成功交付产品的部署方式，价格在几千元每年，而私有化在百万级。

怎么看：把决策拆成「数据边界」和「运维能力」两个独立问题。数据边界有硬性要求，就走私有化；运维能力不足，就必须把运维预算写进项目立项书，而不是假设 IT 部门顺手能管。两个问题都过关，私有化才成立；只过第一个，大概率会在第二年出问题。

6. 趋势判断：AI融合与生态聚合，厂商要在哪一层活下去

报告给出的趋势有三条，拼起来是一条清晰的路线：低代码正在从「一个开发工具」变成「一层被调用的能力」。

第一条是与AI、RPA、数据分析、IoT等技术加速融合。低代码平台通过API接口与这些技术对接，拓宽应用边界。报告举的例子很具体：AI与RPA结合，能让流程自动化对非结构化数据的识别和处理更进一步；低代码与RPA结合，能大幅降低流程自动化的搭建难度，提升易用性。这条趋势的实质是把「搭建」的门槛继续往下压——过去要拖控件，后来要配流程，往后可能只需要描述意图。

第二条是聚合平台构建生态圈。目前厂商众多，各自聚焦的功能模块和应用领域差异较大，聚合平台把低代码厂商、传统软件厂商、服务商、渠道商汇聚起来共同服务用户。这条趋势解决的是选型困境：企业不需要在一堆平台里赌一个，而是通过一层聚合去组合能力。它对厂商的含义是，产品要能被别人调用，接口规范和组件标准会变成竞争力的一部分。

第三条是跨品牌的低代码组件共同拓展应用边界。组件不再被锁在单一平台里，而是可以在不同平台间流转复用。这条最慢，但影响最深——一旦组件层标准化，平台之间的差异会从「谁的组件多」转向「谁的引擎稳、集成深」。

把三条趋势和前面的事实放在一起看，可以得出一个判断：未来的分层会更明显。底层是引擎和集成能力，比的是稳定性和开放性；中层是场景模板和行业组件，比的是沉淀速度和复用率；上层是入口和生态，比的是谁能把开发者和业务人员都留住。厂商很难三层都强，选一层扎下去比铺开更现实。独立厂商的合理位置在中层，用垂直场景的模板密度换生存空间；生态厂商的优势在底层与既有系统的耦合；云厂商的优势在上层入口。

对三类角色的建议不一样。采购方要盯的是合同里的「可拓展性」条款，把模块增购的价格、集成接口的开放程度、数据导出的格式写清楚，避免三年后被锁死。厂商要盯的是服务人力占比，这个数字不降下来，规模越大越亏。集成商和ISV要盯的是自己被替代的位置——标准化程度越高的场景，越容易被平台内置的模板吃掉，剩下的空间在深度集成和行业咨询。

如果要跟踪一个指标来判断趋势是否真的在发生，我建议看「单客实施人天」的年度变化。这个数字下降，说明产品和模板在沉淀，服务密度在降低，商业模式开始往软件公司靠；这个数字不降反升，说明每一单仍然要靠人堆，那么无论融资新闻多热闹，生意的性质没变。第二个可跟踪的是模块增购率，它比续费率更能反映使用深度——续费只说明客户还在付钱，增购说明客户在往里搬更多业务。第三个是跨部门使用比例，它决定了这套平台是部门工具还是企业基础设施，两者的天花板差一个量级。

顺带说一句政策线的作用。从2020年5月的工业大数据指导意见，到2021年的信息化和工业化深度融合发展规划、软件和信息技术服务业发展规划、新型数据中心三年行动计划，再到2022年10月至11月地方与部委的几份文件，脉络是一贯的：先把数字基础设施和企业上云的底座铺好，再推动中小企业用轻量化工具补齐应用缺口。低代码在这个脉络里的位置是「补缺口」，不是「建底座」。认清这个位置，就不会对政策抱有不切实际的期待，也不会低估它在中小企业市场的推动力。

我自己的教训来自一次选型评估。当时被演示界面的流畅度打动，六个引擎里只重点看了页面渲染和报表两块，集成引擎只在PPT上过了两眼。上线三个月后，数据要从既有系统回填，权限要和统一认证打通，两个需求把项目拖了整整一个季度，最后靠定制开发收场，预算超了一截。从那以后我每次评估这类平台，都强制走一遍「先看引擎清单、再看真实流程跑通、最后算三年总账」这三步，一步不省。希望帮到你。

本文还有配套的精品资源，点击获取