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

简介这份PDF为头豹研究院2022年中国低代码/无代码平台行业研究报告面向企业数字化决策者、产品与技术负责人、低代码从业者及行业研究者帮助系统理解低代码与无代码的差异、适用边界及企业应用快速构建路径。压缩包仅含1个PDF文件大小约3.43MB阅读与检索较为轻便。当前已有111人学习。报告围绕行业综述展开覆盖定义分类、发展历程、平台架构、四类商业模式、公有云与私有化部署及收费差异并分析研发与服务成本上升、续费率偏低、多数厂商亏损等现实挑战同时梳理产业链参与者、厂商分类、投融资情况与未来趋势提及简道云、伙伴云、轻流等头部厂商的盈利表现。适合用于方案调研、市场判断和低代码产品选型时快速建立行业认知框架。1. 业务自己拼的应用三个月没人敢改这份报告能回答什么去年有个团队碰到的事很典型业务侧要一个供应商对账的小工具IT 排期到季度末业务主管转头用某在线表格平台自己拼了一个两周就上线。三个月后这东西还在跑但没人敢动——加一个字段历史对账口径就乱想接进 ERP发现数据是手工导的。这类“能跑起来但跑不长久”的项目问题几乎都不在产品能力而在选型时把“能搭出来”当成了“能长期跑”。手头这份 2022 年的低代码/无代码平台行业研究报告PDF不教某一家产品怎么点按钮它把边界、架构分层、四种商业模式、两种部署方式、成本结构和场景占比拆开讲清楚做平台选型的 IT 负责人和要给业务定规则的架构师能直接拿它当判断依据。2. 低代码与无代码的分界线一张对照表定边界六大引擎看天花板2.1 两倍与八倍的速度差衡量的到底是什么材料里给的第一组数据很直接相对传统开发低代码平台快约 2 倍无代码平台快约 8 倍。很多人拿这个当采购理由但这个倍数衡量的只是“从零到一个能点开的页面”的耗时不含数据治理、权限梳理和系统集成。无代码快 8 倍有个隐含前提——你的场景落在它已经封装好的那批功能里一旦出圈补丁成本会把这 8 倍原封不动吐回去。原文对两者的定义值得逐字读一遍低代码开发是指 UI 界面可以用 HTML 这类语言去写数据库处理也可以用 SQL 深度加工产品形态偏开放、容器功能多但做得不精细用户需要写一点代码把它改到想要的样子无代码则是把字段设定、数据库处理这些基础功能全部封装用户只能调用已经做好的功能场景覆盖面窄但垂直场景做得精细即拿即用。维度低代码平台无代码平台使用者有编程基础的 IT 人员无编程基础的业务人员相对传统开发速度约 2 倍约 8 倍易用性相对较低相对较高技术要求需具备代码知识能用 HTML/SQL 做深度加工无需代码知识只能调用封装好的功能个性化程度相对较高相对较低适配企业有资金、有研发团队的中大型企业无研发团队、软件需求紧急、业务变化较快的中小企业或中大型企业的某个部门/项目典型场景较复杂的业务应用表单、审批、进销存一类的轻应用我一般给团队一条经验阈值如果需求里有超过三成的字段需要跨表聚合计算或者需要跟两个以上外部系统做双向同步无代码平台会很快撞墙。反过来如果一个部门只是要收周报、走报销、管固定资产硬上低代码平台是给自己找麻烦——业务人员拿到的是一个需要写 SQL 的半成品第一步就卡住。这里有个容易忽略的点低代码与无代码面向的用户群体和使用特性是分离的不是“高级版和低级版”的关系。一个组织里同时存在这两类需求很正常硬要用一套平台覆盖通常是低代码那一侧配了复杂控件却没人会用无代码那一侧被逼着做超出边界的事两头都不讨好。2.2 三层架构与六大引擎判断平台能走多远的抓手材料把平台架构自下而上切成三层这个分层思路比我见过的很多产品白皮书都清晰基础层是物理机、云主机、容器编排平台、操作系统和数据库主流关系型数据库加国产数据库平台层就是低代码技术真正生效的地方由若干引擎组成应用层落到具体业务系统比如 ERP、CRM、OA、MES、物流管理、设备运维、客服工单终端覆盖 PC、移动端和大屏还能嵌到外部协同工具里。平台层的六大引擎是评估一个产品天花板的抓手。下面这张表左边是原文的能力描述右边是我实际选型时会追问的问题引擎负责什么选型时该追问数据模型引擎内建小型数据库可直连主流数据库提供可视化数据模型与查询视图设计支持哪些库视图能不能下推跨库关联怎么处理业务逻辑引擎可视化编排运行于服务器和页面的业务逻辑支持调适实现前后端分离能不能写自定义脚本调试信息落到哪里工作流引擎定制流程各节点的规则和关联业务处理支持流程编排与调整在途实例怎么办流程定义有没有版本化页面渲染引擎开箱即用的 UI 组件与外观样式支持固定布局与响应式布局移动端适配到什么程度能不能嵌自定义组件智能报表引擎专业级报表设计支持统计报表、复杂中式报表、类 Word 报告大数据量下的分页与导出性能系统集成引擎数据库直连、WebAPI 构建与调用、用户认证与权限同步有没有标准 SSO能否对接内部权限中心血泪经验是这六个引擎里真正决定项目能不能长期跑的是数据模型和工作流两个页面渲染是最容易在演示阶段惊艳、也最不重要的一个。销售永远先给你看拖拽出来的漂亮表单但上线三个月后折磨你的是字段迁移和流程版本。2.3 十分钟需求自评把场景清单压成一张分流表这一步是可以抄作业的不需要任何工具一张表就够。第一步列清单。把未来 12 个月可能被提出来的应用全部写下来一个应用一行不要按部门分按“业务对象”分比如供应商档案、采购订单、设备点检记录。第二步给每行打三个分。表单与流程复杂度 1-5 分节点数超过 8 个、有条件分支的直接给 4 分以上集成点数量数清楚要对接几个外部系统计算复杂度看是否需要跨表聚合和复杂口径。第三步按下表分流集成点计算复杂度建议归口0-1 个单表增删改查为主无代码平台业务侧自建IT 只做审核0-1 个需要跨表聚合低代码平台IT 主导业务配合2 个及以上任意低代码平台 集成方案必须 IT 主导任意涉及财务口径或对外报送不进低代码走传统开发或原系统改造第四步把分流结果反过来验证如果超过一半的应用都落在最后两行说明你需要的不是低代码平台而是一个集成中间件加一支能写代码的队伍。这个结论听起来扫兴但比采购完发现用不上要省钱。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 账把“感觉更安全”换算成数字我一般会让团队填下面这张表填完再讨论。注意下表里的金额是为了演示计算口径编的示例数字不是任何厂商的报价。成本项公有云方案私有化方案首年许可或安装费3 万60 万年度订阅或更新费第 2、3 年3 万 × 2 6 万6 万 × 2 12 万服务器与基础设施02 台 × 4 万 8 万实施与集成4 万20 万内部运维人力3 年10 人天 × 1500 1.5 万0.5 人 × 15 万 × 3 22.5 万三年合计约 14.5 万约 122.5 万五十人规模、三个轻应用的场景下两条路的差价接近 8 倍。这个差额在什么情况下是值得付的只有当“数据不能出内网”是硬约束、并且内部确实有需要实时双向同步的核心系统时私有化才成立。否则你花 8 倍价钱买到的是一份心理上的安全感换来的是一支要自己养的运维队伍。这里有个判断动作很实用把“必须私有化”的理由写成一句话如果这句话里出现了具体的外部监管要求或者具体的实时同步场景就继续如果写出来是“感觉这样更安全”“领导觉得放外面不放心”就先按公有云方案推进把预算留给集成。4.3 集成边界三件事必须提前确认部署方式定下来之后真正决定项目成败的是集成。材料里系统集成引擎列了三项能力——数据库直连、WebAPI 构建与调用、用户认证与权限同步这三项正好对应三个高发问题。第一件内网系统对接。前面说过公有云无法直连内网。如果必须做双向同步常见做法是在内网放一台前置机由它做数据中转同步频率从实时降到准实时。这里要提前算清楚你的业务能容忍多长的延迟库存扣减这种场景五分钟延迟就会出问题。第二件身份与权限。默认账号体系往往跟企业内部的目录服务不同构。最典型的现象是平台里的“部门”是一棵扁平的两级树而企业内部是带虚拟团队的多维组织做权限同步时会发现映射不上。提前确认三件事支不支持标准单点登录、组织架构同步是增量还是全量、角色能不能按自定义字段动态计算。第三件数据库直连的写权限。平台能直连你的库是只读还是可写如果是可写写入会不会绕过原业务系统的校验逻辑和状态机我见过一个案例低代码应用直接往订单表写状态字段绕过了原系统的库存冻结校验导致账实不符最后靠人工对账收场。建议在动手之前先填一张接口清单系统方向读/写/双向频率实时/准实时/T1协议责任人例核心业务系统双向准实时5 分钟数据库直连应用组 A这张表填不满说明集成方案还没想清楚这时候不该进入开发。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任何单项低于及格线的直接出局不参与总分排序。维度权重打分依据及格线场景覆盖25用你的需求清单逐条比对看有多少条落在平台封装范围内70% 的需求能不改代码实现集成能力20数据库直连的读写权限、API 构建能力、单点登录与权限同步三个必需接口全部有标准方案部署形态20是否能满足硬约束公有云方案能否用前置机补足硬约束全部满足厂商可持续性15融资阶段、团队规模、研发与服务人员占比、更新频率合同周期内无生存风险实施与服务20自有实施占比、伙伴认证、SLA 条款、专属人天有书面 SLA 且写明响应时限分数只是排序工具真正起作用的是复核动作。这套动作我建议固定成四步每次选型都走一遍第一步同一份需求文档、同一批脱敏数据、同一个验收脚本交给两到三家做 POC。脚本里必须包含一个“改流程”的动作比如给已有流程加一个条件分支看对方怎么处理在途实例。第二步让对方当场改一个字段类型从文本改成枚举观察是只改模型还是要把页面重做。这个动作三十秒就能暴露出平台的模型驱动程度。第三步索取最近三个版本的更新说明逐条看更新内容的分布。如果三版里超过一半是组件和皮肤说明这个平台近期在打体验战复杂业务要谨慎。第四步把接口清单交给对方填填不完整的直接扣分。清单填不满后面所有的工期承诺都是空的。从那以后我每次做平台选型都会先把“不能交出去的那部分”写在纸上数据口径、流程版本、集成边界。这三件事任何一件落在厂商手里后面都要付利息——口径交出去报表永远对不上流程版本交出去一次改流程就是一次事故集成边界交出去上线那天才发现数据出不了内网。评分卡可以商量这三条不让步。希望帮到你。本文还有配套的精品资源点击获取