低代码/无代码平台选型：边界、六大引擎、成本与部署

简介：这份PDF为头豹研究院2022年中国低代码/无代码平台行业研究报告，面向企业数字化决策者、产品与技术负责人、低代码从业者及行业研究者，帮助系统理解低代码与无代码的差异、适用边界及企业应用快速构建路径。压缩包仅含1个PDF文件，大小约3.43MB，阅读与检索较为轻便。当前已有111人学习。报告围绕行业综述展开，覆盖定义分类、发展历程、平台架构、四类商业模式、公有云与私有化部署及收费差异，并分析研发与服务成本上升、续费率偏低、多数厂商亏损等现实挑战；同时梳理产业链参与者、厂商分类、投融资情况与未来趋势，提及简道云、伙伴云、轻流等头部厂商的盈利表现。适合用于方案调研、市场判断和低代码产品选型时快速建立行业认知框架。

1. 业务自己拼的应用三个月没人敢改：这份报告能回答什么

去年有个团队碰到的事很典型：业务侧要一个供应商对账的小工具，IT 排期到季度末，业务主管转头用某在线表格平台自己拼了一个，两周就上线。三个月后这东西还在跑，但没人敢动——加一个字段，历史对账口径就乱；想接进 ERP，发现数据是手工导的。这类“能跑起来但跑不长久”的项目，问题几乎都不在产品能力，而在选型时把“能搭出来”当成了“能长期跑”。手头这份 2022 年的低代码/无代码平台行业研究报告（PDF）不教某一家产品怎么点按钮，它把边界、架构分层、四种商业模式、两种部署方式、成本结构和场景占比拆开讲清楚，做平台选型的 IT 负责人和要给业务定规则的架构师，能直接拿它当判断依据。

2. 低代码与无代码的分界线：一张对照表定边界，六大引擎看天花板

2.1 两倍与八倍的速度差，衡量的到底是什么

材料里给的第一组数据很直接：相对传统开发，低代码平台快约 2 倍，无代码平台快约 8 倍。很多人拿这个当采购理由，但这个倍数衡量的只是“从零到一个能点开的页面”的耗时，不含数据治理、权限梳理和系统集成。无代码快 8 倍有个隐含前提——你的场景落在它已经封装好的那批功能里；一旦出圈，补丁成本会把这 8 倍原封不动吐回去。

原文对两者的定义值得逐字读一遍：低代码开发是指 UI 界面可以用 HTML 这类语言去写，数据库处理也可以用 SQL 深度加工，产品形态偏开放、容器功能多但做得不精细，用户需要写一点代码把它改到想要的样子；无代码则是把字段设定、数据库处理这些基础功能全部封装，用户只能调用已经做好的功能，场景覆盖面窄，但垂直场景做得精细，即拿即用。

我一般给团队一条经验阈值：如果需求里有超过三成的字段需要跨表聚合计算，或者需要跟两个以上外部系统做双向同步，无代码平台会很快撞墙。反过来，如果一个部门只是要收周报、走报销、管固定资产，硬上低代码平台是给自己找麻烦——业务人员拿到的是一个需要写 SQL 的半成品，第一步就卡住。

这里有个容易忽略的点：低代码与无代码面向的用户群体和使用特性是分离的，不是“高级版和低级版”的关系。一个组织里同时存在这两类需求很正常，硬要用一套平台覆盖，通常是低代码那一侧配了复杂控件却没人会用，无代码那一侧被逼着做超出边界的事，两头都不讨好。

2.2 三层架构与六大引擎：判断平台能走多远的抓手

材料把平台架构自下而上切成三层，这个分层思路比我见过的很多产品白皮书都清晰：基础层是物理机、云主机、容器编排平台、操作系统和数据库（主流关系型数据库加国产数据库）；平台层就是低代码技术真正生效的地方，由若干引擎组成；应用层落到具体业务系统，比如 ERP、CRM、OA、MES、物流管理、设备运维、客服工单，终端覆盖 PC、移动端和大屏，还能嵌到外部协同工具里。

平台层的六大引擎，是评估一个产品天花板的抓手。下面这张表左边是原文的能力描述，右边是我实际选型时会追问的问题：

血泪经验是：这六个引擎里，真正决定项目能不能长期跑的，是数据模型和工作流两个；页面渲染是最容易在演示阶段惊艳、也最不重要的一个。销售永远先给你看拖拽出来的漂亮表单，但上线三个月后折磨你的是字段迁移和流程版本。

2.3 十分钟需求自评：把场景清单压成一张分流表

这一步是可以抄作业的，不需要任何工具，一张表就够。

第一步，列清单。把未来 12 个月可能被提出来的应用全部写下来，一个应用一行，不要按部门分，按“业务对象”分，比如供应商档案、采购订单、设备点检记录。

第二步，给每行打三个分。表单与流程复杂度 1-5 分（节点数超过 8 个、有条件分支的直接给 4 分以上）；集成点数量，数清楚要对接几个外部系统；计算复杂度，看是否需要跨表聚合和复杂口径。

第三步，按下表分流：

第四步，把分流结果反过来验证：如果超过一半的应用都落在最后两行，说明你需要的不是低代码平台，而是一个集成中间件加一支能写代码的队伍。这个结论听起来扫兴，但比采购完发现用不上要省钱。

2.4 从发展脉络看“模型驱动”这件事

材料把低代码的技术前史拉到了上世纪七十年代，这条线对选型有实际意义，不是纯背景。第四代编程语言指的是非过程的高级规范语言，覆盖数据库管理、报表生成、数学优化、图形界面和 Web 开发；九十年代流行起来的是快速应用开发，先关注界面再逐步补业务逻辑，理念先进但有明显局限——开发环境特定、缺乏模块化、多人协作困难；2001 年出现了模型驱动架构，把需求捕获、分析、设计、编码、测试、部署串成一条链；2014 年“低代码”这个概念被正式提出，此后云计算的发展把这条技术路线在国内推了起来；2020 年外部环境推动企业数字化需求激增，普及率进一步提升，同时大型互联网与云厂商开始入局。

为什么这条线有用？因为它能帮你判断一个平台是“表单工具长出来的”还是“模型驱动长出来的”。前者在表单和审批类场景极快，配置几分钟出结果，但业务对象一复杂、状态机一多，就开始用流程去模拟数据关系，越做越乱。后者上手慢，但数据模型和页面是分离的，同一份模型能渲染出多个视图和终端。

判断方法很简单，问一句“你的数据模型和页面是分离的吗，一张表能不能同时挂三个不同终端的不同视图”，再让对方当场演示改一个字段类型，看是只改模型还是要把页面推倒重来。这两个动作基本能问出底子。

3. 四种商业模式与三类厂商基因：选平台前先搞清它靠什么赚钱

3.1 四种商业模式，对应四种议价姿势

材料把低代码厂商的商业模式拆成四种，并且明确说直接面向客户是当下的主流。这个分类不是学术游戏，它直接决定你签合同的时候，钱付给谁、出了问题找谁、砍价砍掉的是什么。

间接面向客户这一种要特别留意。厂商只赚产品费用，实施服务费归第三方，这意味着实施方的动力是“把这个项目交付完”，不是“把这个产品用透”。我在一个项目里见过这种情况：流程引擎明明支持条件分支，实施方为了赶工期写死了三个审批人，业务一调整就要重新开发一次，费用另算。生态型平台模式的风险在另一头——它对厂商的产品能力和生态建设能力要求都很高，早期阶段规则变更是常态，你按今天的规则做的集成，明年可能要返工。

3.2 宏观看能力，微观看基因

材料给了两组分类法，都很实用。

按宏观分，低代码厂商也就是面向专业开发人员或业务人员的低代码应用平台，通常有较强的本地化定制支持能力，适合服务中大型以及 IT 成熟度较高的企业；无代码厂商面向业务人员，解决表单、办公自动化这类功能性用例，提供无代码平台的厂商多为初创，走轻量化路线满足市场需求，更适合缺乏 IT 支持的中小型企业。

按微观分，独立厂商自创立之初就专注低代码/无代码产品的研发与销售；生态厂商原本是做 ERP、CRM、OA 这类企业管理软件的，在发展过程中把产品线拓展过来，用来完善自己的产品生态；互联网/云厂商则是用低代码产品给自家的协同办公产品做功能补充。

这个区分对选型的意义在于：生态厂商的低代码是“配套”，云厂商的低代码是“入口”。配套的定位意味着它的迭代优先级跟着主营业务走，你提的需求在路线图上排第几，取决于它是否服务于主营产品的销售；入口的定位意味着它在易用性和免费额度上会很大方，但在深度定制和私有化上会保守。独立厂商反过来，愿意为单个客户做深度适配，但你要评估它能不能撑过你的合同周期。

3.3 三步给候选厂商定位

不用做调研报告，三个动作就能把一家厂商归到上面某一格里。

第一步，看官网第一屏卖的是什么。如果首屏主视觉是“应用搭建平台”，往下才是行业方案，这是产品驱动型；如果首屏是“某某管理系统”，低代码藏在产品矩阵的第三屏，这是生态厂商的配套产品线。第二种情况下，你提的个性化需求很可能被引导回它已有的行业模板。

第二步，问实施团队的归属和比例。自有实施团队占比高，说明它愿意为交付质量负责；大量依赖认证伙伴，就要问清楚伙伴的认证等级、平均交付年限、换人机制。

第三步，要最近三个版本的更新说明。看更新集中在组件库、皮肤和模板，还是集中在数据模型、流程引擎和集成能力。前者是体验迭代，后者是能力迭代。一个连续三个版本都在加组件的平台，遇到复杂流程会很难受。

3.4 成本结构与行业现状：低价年费背后的账

材料里有一组数据我认为是整份报告最该被记住的：低代码厂商的研发人员团队占比在 30%-40%，服务人员团队占比在 40%-50%。两项加起来是 70%-90%，剩下的才是销售和管理。成本增长不是来自技术研发难度，而是来自产品日常的更新和迭代——客户数量增加、业务场景拓宽，对场景覆盖度的要求随之提升，研发团队必须保持一定频率的更新和功能改动，跟不上客户业务变化，续费率就保不住。服务与售后成本则体现在对企业管理员的培训、对搭建应用的协助上。

而收入端的情况是：经济下行让中小企业采购预算下滑，新客增量近两年逐渐减少；客户采购后发现业务场景不匹配、自主搭建不顺利，就不续费或者换供应商。高成本和低营收叠加，多数厂商处于亏损状态，只有少数头部实现轻微盈利。

这组数据对你的实际含义有三条，都跟钱有关：

• 年费砍到很低的时候，先被砍掉的是实施与售后人力，而那部分恰恰是你上线头三个月最需要的。
• 续费率偏低的行业里，销售激励会偏向新签，老客户的工单排期自然后置。这不是态度问题，是考核决定的。
• 选厂商本质上是选它能不能撑过你的合同周期。一个还在早期投入阶段、未实现盈利的厂商，你签三年约，第三年它还在不在、服务团队还剩几个人，是要在合同里写清楚的。

踩坑提醒：把“版本更新频率”和“专属服务人天”写进条款，比把单价砍下来 15% 更有价值。单价是一次性的，服务是三年的事。

4. 公有云还是私有化：四个维度对比与一份三年 TCO 账

4.1 四个维度，两种部署的真实差异

材料对部署方式的对比做得很干脆，直接给了四个维度加三组排序，我把它整理成一张可对照的表：

三组排序是：安全性上私有化高于公有云；成本上公有云低于私有化；维护运营难度上私有化高于公有云。价格量级上，公有云产品通常在几千元一年的区间，私有化则需要定制开发和对接，价格在百万级，包含平台打包安装费用以及按年更新费用。偏好私有化的企业大多集中在金融和电信领域，共同特征是：对数据安全要求高、内部有其他系统要对接集成、业务场景复杂、并且自己有服务器和技术人员。

注意其中那句容易被跳过的话——“公有云模式下无法与企业内网进行对接”。这不是一句产品缺陷描述，而是部署方式的物理边界。如果你的核心系统在内网，公有云部署的低代码平台就只能靠定时导出导入或者前置机做数据交换，实时性和一致性都要额外设计。

4.2 三年 TCO 账：把“感觉更安全”换算成数字

我一般会让团队填下面这张表，填完再讨论。注意下表里的金额是为了演示计算口径编的示例数字，不是任何厂商的报价。

五十人规模、三个轻应用的场景下，两条路的差价接近 8 倍。这个差额在什么情况下是值得付的？只有当“数据不能出内网”是硬约束、并且内部确实有需要实时双向同步的核心系统时，私有化才成立。否则你花 8 倍价钱买到的是一份心理上的安全感，换来的是一支要自己养的运维队伍。

这里有个判断动作很实用：把“必须私有化”的理由写成一句话，如果这句话里出现了具体的外部监管要求或者具体的实时同步场景，就继续；如果写出来是“感觉这样更安全”“领导觉得放外面不放心”，就先按公有云方案推进，把预算留给集成。

4.3 集成边界：三件事必须提前确认

部署方式定下来之后，真正决定项目成败的是集成。材料里系统集成引擎列了三项能力——数据库直连、WebAPI 构建与调用、用户认证与权限同步，这三项正好对应三个高发问题。

第一件，内网系统对接。前面说过公有云无法直连内网。如果必须做双向同步，常见做法是在内网放一台前置机，由它做数据中转，同步频率从实时降到准实时。这里要提前算清楚：你的业务能容忍多长的延迟？库存扣减这种场景，五分钟延迟就会出问题。

第二件，身份与权限。默认账号体系往往跟企业内部的目录服务不同构。最典型的现象是，平台里的“部门”是一棵扁平的两级树，而企业内部是带虚拟团队的多维组织，做权限同步时会发现映射不上。提前确认三件事：支不支持标准单点登录、组织架构同步是增量还是全量、角色能不能按自定义字段动态计算。

第三件，数据库直连的写权限。平台能直连你的库，是只读还是可写？如果是可写，写入会不会绕过原业务系统的校验逻辑和状态机？我见过一个案例，低代码应用直接往订单表写状态字段，绕过了原系统的库存冻结校验，导致账实不符，最后靠人工对账收场。

建议在动手之前先填一张接口清单：

这张表填不满，说明集成方案还没想清楚，这时候不该进入开发。

4.4 场景占比反过来影响部署选择

材料给的行业应用占比是：制造 30%、零售 20%、服务 15%，国企、建筑、教育合计约 5%，其他 30%。制造业占比最高这件事值得单独说，因为它的部署选择逻辑跟别的行业不一样。

原文的分析是：制造生产过程中存在大量非标环节，从某种程度上并不适合标准化控件的低代码开发；但对中小微制造企业来说，采购传统 ERP 费用极高，而且传统 ERP 流程过于固化，找厂商改功能的成本也很高，所以它们采购和续费低代码产品的关键点是高性价比。大型制造企业的 ERP 功能已经完善，不需要用低代码做复杂应用开发，如果有功能改进需求，可以用 API 把低代码搭的应用和原有 ERP 连接起来，作为功能上的补充。

翻译成部署建议：中小制造企业走公有云加轻应用，重点是性价比和上线速度，不要碰核心生产流程；大型制造企业走私有化加集成网关，定位明确写成“补丁”而不是“底座”，接口清单要精确到字段级。零售和服务业场景标准化程度高，公有云的模板化优势能发挥出来，但要注意会员、订单这类数据涉及个人信息时的合规边界，这部分要单独评估，不在这里展开。

5. 五条踩坑记录：从 POC 到续费，问题都出在哪

5.1 试用期搭得飞快，上线三个月没人用

现象：POC 阶段两周搭出三个应用，业务方当场叫好，签了合同。正式上线两个月，日活只剩录入岗的三个人，其余人继续用原来的表格。

原因：POC 只验证了“能不能搭出来”，没验证“数据从哪来、口径谁定、谁来维护”。材料把续费率低归到两个原因——场景不匹配和自主搭建不顺利，本质上都是这件事：POC 的验收标准和生产的验收标准不是一套。

解决：POC 阶段就要求带真实数据跑满两周，验收项里强制加两条：“字段口径说明书”和“异常数据处理流程”，并且指定业务侧的数据责任人。没有责任人的应用，上线即弃用。

5.2 复杂审批流一改就崩

现象：一个十二节点的采购审批，业务提需求说“金额大于阈值时加签一位负责人”，改完之后，在途的两百多个流程实例状态错乱，待办列表里出现了已经审批过的节点。

原因：可视化改流程的门槛太低，改的人不觉得这是一次数据结构变更。工作流引擎支持节点规则和业务处理关联，但各家对流程版本化和在途实例迁移的支持深浅不一。材料里说工作流引擎要“支持自由定制流程中各节点的各项规则和关联的业务处理，以及对工作流程的编排与调整”，这句话在产品宣传里是优点，在运维里就是风险点。

解决：改流程之前先问三个问题——在途实例怎么处理、旧版本流程定义保不保留、节点变更会不会影响已产生的待办。上线前把流程定义导出留档，按 schema 变更的流程来管：评审、备份、灰度、回滚预案，一样不能少。

5.3 续费率低，最后会传导到你身上

现象：第一年提工单两小时响应，第二年提工单排一周，专属对接人换了三个。

原因：这不是个别现象。行业整体续费率偏低，厂商研发加服务人员占团队七到九成，新客增量又在放缓，多数厂商处在亏损状态。销售考核压在新签上，老客户的工单自然往后排。

解决：合同里写清 SLA 和响应时限，把“年版本更新次数”和“专属服务人天”写进条款；续费谈判的筹码不是压价，是把服务内容具体化。另外，自己留一份应用资产清单——用了哪些组件、哪些自定义脚本、哪些外部接口，换供应商的时候这份清单就是后悔药。

5.4 私有化报价从几万跳到百万

现象：沟通时说年费几千到几万，一提出要私有化部署，报价单直接变成七位数。

原因：材料里写得很清楚，公有云是按模块数量和使用时间周期付费，价格在几千元一年的区间；私有化需要定制化开发和对接，价格在百万级，包含打包安装费用和按年更新费用。这不是销售套路，是工作量差异——私有化交付要适配你的操作系统、数据库、网络环境，要跟你已有的系统做对接，这些工作公有云版本里是厂商一次性投入、所有客户分摊的。

解决：先定硬约束，再谈部署。把“是否必须内网”“数据是否必须不出域”写成一页纸，能通过前置机解决同步的就不要直接上私有化。真的必须私有化，把报价拆成四块分别谈：许可、安装实施、年度更新、后续定制，别接受打包总价。

5.5 报表和原系统对不上数

现象：低代码里搭的进销存报表，和原系统的库存数差几十条，业务方开始怀疑平台不可靠。

原因：两套口径。低代码侧的字段是业务自己定的，没有对齐原系统的单据状态机——在途、冻结、占用这些状态在原系统里是分字段存的，在低代码侧被合并成了一个“数量”。智能报表引擎能做出复杂的中式报表和类 Word 报告，但它不替你定义口径。

解决：动手搭报表之前先做一张字段映射与口径对照表，每个指标写清楚来源表、过滤条件、统计时点。对不上数的时候先查时点（是日切前还是日切后），再查状态过滤，最后才怀疑平台。

6. 把报告拆成一张选型评分卡：权重、及格线与复核动作

材料本身是行业概览，不是选型工具，但它给的分类维度足够拼成一张评分卡。我一般这么用：五个维度，总分 100，先定及格线 70，任何单项低于及格线的直接出局，不参与总分排序。

分数只是排序工具，真正起作用的是复核动作。这套动作我建议固定成四步，每次选型都走一遍：

第一步，同一份需求文档、同一批脱敏数据、同一个验收脚本，交给两到三家做 POC。脚本里必须包含一个“改流程”的动作，比如给已有流程加一个条件分支，看对方怎么处理在途实例。

第二步，让对方当场改一个字段类型，从文本改成枚举，观察是只改模型还是要把页面重做。这个动作三十秒就能暴露出平台的模型驱动程度。

第三步，索取最近三个版本的更新说明，逐条看更新内容的分布。如果三版里超过一半是组件和皮肤，说明这个平台近期在打体验战，复杂业务要谨慎。

第四步，把接口清单交给对方填，填不完整的直接扣分。清单填不满，后面所有的工期承诺都是空的。

从那以后我每次做平台选型，都会先把“不能交出去的那部分”写在纸上：数据口径、流程版本、集成边界。这三件事任何一件落在厂商手里，后面都要付利息——口径交出去，报表永远对不上；流程版本交出去，一次改流程就是一次事故；集成边界交出去，上线那天才发现数据出不了内网。评分卡可以商量，这三条不让步。希望帮到你。

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