低代码与无代码选型指南：部署、成本与厂商评估

简介头豹研究院出品的《2022年中国低代码无代码平台行业研究报告》以 PDF 单文件形式提供压缩包约 3.43MB面向企业数字化负责人、产品经理、技术选型团队及行业研究者帮助读者在方案论证与产品选型时建立对低代码、无代码赛道的整体认知。报告从定义与分类入手区分低代码与无代码在用户群体、易用性、适用场景上的差异梳理其从上世纪七十年代第四代编程语言到 2020 年后快速增长的发展脉络与平台架构进而拆解直接面向客户、间接面向客户、前后端开发平台、生态型平台四类商业模式对比公有云与私有化部署在收费、响应速度、维护方式与部署周期上的取舍并分析研发与售后成本上升、续费率偏低导致多数厂商亏损、仅头部厂商微利经营的现状。文末还覆盖厂商分类、产业链参与者、投融资情况与未来趋势判断可作行业入门与竞品研究参考。已有 111 人学习。1. 一份 2022 年的低代码研报为什么现在还能当采购底稿低代码、无代码也叫零代码这两个词在采购会上被念了好几年真正让项目翻车的往往不是产品弱而是需求颗粒度和部署形态没对齐。这份 2022 年 11 月发布的行业研报是一份几十页量级的 PDF把低代码/无代码的定义分类、平台架构、商业模式、部署方式、产业链、投融资、发展挑战和趋势压成了一套还算完整的决策框架。它不教你怎么拖拽建表单但能回答采购前必须回答的三个问题什么样的业务该上低代码、公有云和私有化差在哪、厂商的收费模式和续费逻辑意味着什么风险。适合要给管理层写选型报告的技术负责人、准备接低代码交付的外包团队以及正在评估自研还是采购的中台同学。2. 低代码与无代码的划线用四个维度在第一周就把产品类型定死2.1 用「谁在拖拽」定产品类型LCDP 与 CADP 的分界报告里把广义的低代码拆成两个东西低代码开发平台LCDP和无代码开发平台CADP。前者面向有编程基础的 IT 人员界面可以用标记语言改数据库处理能下探到 SQL 层深度加工产品路径偏开放容器功能多但不够精细用户得靠少量代码把功能改到想要的样子后者把基础功能全部封装用户只能调用已做好的功能字段设定、数据库处理都走预置动作场景覆盖面窄但垂直场景做得细即拿即用。这条分界线比任何一份功能清单都重要。我见过最常见的误判是把无代码当低代码买前三个应用搭得飞快第四个应用要做跨表汇总和自定义校验才发现平台只允许调用预置动作只能推倒重来。维度低代码平台 LCDP无代码平台 CADP用户群体有编程基础的 IT 人员无编程基础的业务人员对比传统开发的交付速度约 2 倍报告经验值约 8 倍报告经验值易用性相对较低需要理解数据模型相对较高所见即所得技术要求需具备代码知识能写校验、能改页面无需代码知识个性化程度相对较高相对较低适合企业有资金、有研发团队的中大型企业无研发团队、需求紧急、业务变化快的中小企业或大企业的部门级项目典型场景复杂业务应用、需要与既有系统对接表单、审批、进销存、巡检这类结构清晰的轻应用「快 2 倍」和「快 8 倍」这两个数字不要当成性能指标读。它们是交付周期的经验倍数用在预算和排期里更合适同样一个带三级审批的工单应用传统开发估 20 人天低代码按 10 人天报无代码按 2.5 人天报然后在这个基数上再叠加集成和培训的工时。拿这个倍数去反推候选产品比听销售讲「我们什么都能做」靠谱得多。还有一个容易被忽略的点报告明确指出低代码产品适合服务中大型且 IT 成熟度较高的企业无代码适合缺乏 IT 支持的中小企业。这句话的潜台词是产品类型要跟企业自身的 IT 能力匹配不是越强越好。IT 成熟度低的组织买了低代码平台等于买了一套需要二次开发的半成品最后大概率烂在服务器上。2.2 三层架构与六大引擎验收时按引擎逐个点名报告里给了一套平台架构的分层自下而上是基础层、平台层、应用层。基础层是数据库、物理机或容器化的云原生架构、各类云主机平台层才是低代码技术真正落脚的地方由若干「运行引擎」组成应用层是最终交付的东西大屏、PC 端、移动端以及嵌进协同办公工具或业务系统里的页面。基础层和应用层各家的差别其实不大真正拉开差距的是平台层那几个引擎。报告以某款企业级低代码平台为例列出了六大引擎我把它们翻译成验收时可以直接问出口的一句话引擎报告描述的能力现场验收问这一句数据模型引擎内建小型数据库可直连主流关系型数据库提供可视化数据模型与查询视图设计我有 3 张主表、12 张子表、两级审批能不能在演示环境里当场建完并出一个带分组统计的查询视图业务逻辑引擎可视化业务逻辑设计与调试可编排运行于服务器和页面的逻辑实现前后端分离一段带条件分支和外部接口调用的校验逻辑改完要不要整包重新发版工作流引擎自定义流程各节点的规则与关联业务处理支持流程编排与调整流程跑到一半要加签、要改节点已经在途的实例怎么处理页面渲染引擎集成开箱即用的 UI 组件与样式支持固定布局与响应式布局元素位置样式可调同一个页面在 PC 和移动端是一套设计还是两套智能报表引擎支持统计报表、复杂报表、类文档式报告跨三张表关联的月度汇总不写 SQL 能不能出来系统集成引擎数据库直连、WebAPI 构建与调用、用户认证与权限同步能不能对接我们已有的账号体系做单点登录权限按组织架构同步这六个问题一场两小时的演示就能问完。回答含糊的那一项就是上线后最可能出血的地方。血泪经验是数据模型引擎和系统集成引擎这两项最容易被演示环节糊弄过去因为演示数据永远只有几十行、永远不跨系统。2.3 从定义到落地的三步判断法搞清楚产品分类和引擎构成之后落到自己身上还有一个动作把需求清单先做出来再倒推产品类型。顺序反了就会变成「先选平台再找场景」这是低代码项目最常见的一种死法。第一步列出未来 12 个月要建的应用控制在 20 个以内。每个应用写清楚四件事表单数量、字段总数、审批节点数、是否需要对接已有系统。这四列决定了后面所有判断。第二步给每个应用打三个标签。复杂度分简单、中、复杂三档判断标准可以粗一点表单数小于 3 且无跨表统计算简单超过 8 张表或需要外部接口算复杂中间算中。使用者标业务或 IT。是否涉外网单独标一列它直接决定部署形态。第三步按比例定类型。清单里复杂应用超过三成主平台必须选低代码八成以上是简单应用且使用者是业务人员无代码足够两类都有走混合主平台选低代码承接复杂应用部门级轻应用放无代码平台。混合采购有个隐形成本要说清楚两套平台的账号体系、权限模型、数据存储都不通做一次跨平台的数据同步大概要花掉一个集成人周而且每次组织架构调整都要重做一遍。所以混合的前提是两边的应用集合真的没有交集。3. 部署形态与成本测算公有云年费与私有化百万报价怎么比3.1 四项差异参数收费、需求响应、维护、周期报告把部署方式分成公有云和私有化两种并在四个维度上做了对比。这四个维度不是并列关系而是一环扣一环收费方式决定了你后续改需求的成本改需求的成本又决定了维护责任落在谁头上。维度公有云部署私有化部署收费方式前期投入低按模块数量和使用时长周期付费增模块需额外付费常见价位在几千元每年需自购服务器硬件整体价格可达百万级含平台打包安装费与按年更新费后续再开发不再额外收费需求响应偏标准化产品功能模块相对固定个性化拓展空间有限按需定制开发和搭建后续升级较灵活可自由拓展维护方法数据存在服务商公用服务器由服务商维护不确定性较高数据在企业自有服务器安全稳定故障需自检修或按实际情况定制维护方案部署周期即买即用无部署周期但无法与企业内网对接部署周期长需与既有软硬件做对接和集成安全性较低较高成本较低较高维护运营难度较低较高这张表里最值钱的一行是「公有云部署无法与企业内网对接」。它不是一句技术描述而是一条硬边界只要你的应用需要读写内网里的生产数据公有云方案在架构层面就不成立跟预算多少无关。3.2 把年费换算成三年总拥有成本几千元每年的公有云和百万级的私有化放在一起比很容易得出「公有云便宜」的结论但这个比较缺了一半。三年期的总拥有成本至少要包含五项报告只讲了前两项后面三项得自己补。成本项公有云私有化说明订阅或授权费按账号数与模块数按年付一次性打包安装费 按年更新费公有云超账号要加钱私有化增模块通常不再收开发费实施与培训通常按项目另计通常打包在总价内报告提到服务成本里包含对管理员的培训和对搭建应用的协助集成改造受网络边界限制可能需要中间库或导出导入可直连成本主要在接口开发跨网方案会引入数据延迟和对账工作量内部运维人力接近零需要专人或兼职运维服务器、备份、升级都要管私有化之后故障自检修这部分不能不算迁移与退出数据和配置导出能力受平台限制数据在自己机器上迁移摩擦小换供应商时才想起这一项通常已经晚了举个示例口径说明算法下面数字是为演示算法编的假设值不是任何厂商的报价80 人使用、5 个核心应用、三年周期。公有云假设 2 万元每年订阅、首年实施 5 万元、集成 3 万元三年合计 6 5 3 14 万元运维人力按 0.1 人折算约 3 万元总计约 17 万元。私有化假设授权 60 万元、硬件 15 万元、实施 20 万元三年更新费按授权额的 15% 计约 18 万元运维按 0.5 人折算约 15 万元总计约 128 万元。差距看着很大但要接着算第二笔账公有云方案如果因为无法对接内网导致你有两个核心流程只能继续手工做这部分人力一年值多少钱。很多项目的真实结论是公有云省下的钱被手工补账吃掉了。3.3 什么时候必须上私有化三条硬边界报告给了一个行业倾向对数据安全要求高、希望平台运行稳定可靠、内部有其他系统需要对接集成、业务场景复杂、且拥有自主服务器和技术人员的企业更偏好私有化这类企业多集中在金融和电信领域。这个描述可以再收紧成三条可判断的边界。第一条要对接的系统在内网。这条一票否决公有云。不要相信「我们可以做数据同步」这种说法先让对方画网络拓扑画不出来就是没有。第二条业务数据不允许出企业边界。这条不用讨论技术方案直接进私有化队列。第三条业务复杂到需要改平台本身。比如需要自定义控件、需要在流程引擎里挂自己的审批规则、需要把平台嵌进已有系统当组件用。这类需求在标准化产品上通常只能靠等版本。三条都不满足公有云就是更划算的选择即买即用、按年付费、服务商维护试错成本低。先用公有云跑三个轻应用验证业务方的接受度再决定要不要投入私有化这个顺序比反过来安全得多。4. 商业模式与厂商分类四种模式的收入结构和续费逻辑4.1 四种商业模式的收入结构报告把低代码厂商的商业模式拆成四类。这个分类对采购方的实际价值在于它告诉你钱付给了谁、出问题该找谁、以及为什么有些需求对方死活不肯接。模式谁付钱厂商赚什么伙伴赚什么适合什么客户风险点直接面向客户企业客户平台订阅费 定制化实施服务费无需求相对通用、希望一家负责到底实施人力绑在厂商身上排期受制于人间接面向客户企业客户产品费第三方服务商、咨询公司赚实施费需求偏通用本地有靠谱服务商实施质量不由厂商控出问题容易扯皮前后端开发平台软件开发商框架、插件、控件、组件的授权费无有研发团队、要提效的软件公司本质是工具链对团队工程能力有要求生态型平台平台上的开发者与服务商授权费开发者、软件商、服务商赚项目费需求多样、愿意自己组织供给尚处早期开发标准和交易规则可能变直接面向客户是当下的主流因为客户不想为了一次数字化改造去协调三方。间接模式的价格通常更低但你得自己有能力验收实施质量。前后端开发平台模式容易被误解成「买个低代码平台给研发用」实际上它卖的是组件和框架团队没有工程规范的话买回来只是一堆没人维护的控件。生态型平台模式对厂商的产品能力和生态建设能力要求都高报告也明确说这个模式还处在早期阶段。4.2 三类厂商的能力边界按厂商出身分报告分成独立厂商、生态厂商、互联网/云厂商三类。这个分类比商业模式更实用因为它决定了产品的能力偏向。独立厂商自创立起就专注低代码产品的研发和销售产品在垂直场景上做得细迭代节奏由自己掌控劣势是生态和集成能力要靠合作补齐。生态厂商原本做企业管理软件在发展过程中把产品线拓展到低代码优势是和自家管理软件天然打通劣势是低代码可能只是产品生态里的一块拼图投入优先级不稳定。互联网/云厂商把低代码作为协同办公产品的功能补充优势是账号体系、协同入口、移动端体验现成劣势是深度定制和私有化选项往往受限。选型时的判断规则可以很简单已有管理系统是某一家的且未来主要做功能补充优先看生态厂商需要独立平台承载复杂应用并对接多个系统优先看独立厂商组织已经在用某套协同办公工具、需求以轻应用为主优先看互联网/云厂商。反过来选通常会在集成阶段付出代价。4.3 用续费率和人员结构反推厂商健康度报告里有两个数字值得单独拎出来低代码厂商的研发人员团队占比约 30% 到 40%服务人员团队占比约 40% 到 50%。服务人员比研发人员还多说明这个行业的成本大头不在写代码而在教客户怎么用。这解释了报告里那个刺眼的结论多数厂商处于亏损状态只有少数头部厂商能实现轻微盈利。原因是双重的一边是研发和服务售后成本持续增长另一边是新客增量减少、客户续费率偏低。续费率低的具体原因报告也写了企业采购后发现业务场景不匹配、自主搭建应用不顺利于是不再续费或者换供应商。对采购方来说这些信息可以变成一组尽调问题。续费率的区间能不能给不要问具体数字问区间和趋势实施团队是自己的还是外包的外包比例多少版本更新的频率是多少上一个版本还在维护几个大版本服务人员与客户数的比例是多少一个服务人员同时跟几个客户。这四个问题问完厂商的健康度和你的后续风险基本能画出来。还有一个反直觉的判断服务人员占比明显低于报告区间不一定是好事。要么产品极度标准化、客户自助率高要么售后就是丢文档让你自己看。这两种情况在试用期很难区分最快的验证办法是提一个偏门问题看多久有人回、回的人是不是懂业务。5. 避坑与排查五条从演示到上线之间的翻车记录5.1 需求侧的三条翻车记录现象一演示很顺第二个应用就卡死。演示环节建三个表单、配两条审批流畅得让人当场想签合同。正式上线一个 40 字段、三级审批、带跨表统计的工单页面加载要五秒以上报表点了没反应。原因是数据模型引擎只用了默认表结构没有建查询视图数据量一过万行就开始塌而演示环境里永远只有几十行数据。解决办法是在 POC 阶段就用真实量级压一遍准备至少 10 万行脱敏数据要求对方现场建视图、出现场报表全程不许切回演示环境。压不过的产品功能清单再长也不要进候选。现象二业务部门自己买了无代码三个月后弃用。行政部门两周搭了六个应用第三个月流程改了一版没人会改慢慢就荒了。报告里点得很明确业务人员多数不具备梳理流程和数据的能力他们把精力放在业务目标上而低代码产品在垂直领域的轻度咨询能力普遍欠缺。解决办法是把「梳理」和「搭建」拆成两步上线前由 IT 或外部顾问把字段、状态机、权限写成一页纸业务方照着搭同时在业务部门留一个平台管理员负责后续调整。少了这一步无代码平台的采用率会断崖式下跌。现象三把无代码当低代码用。前四个应用都是表单和审批跑得飞快。第五个应用要写自定义校验、要调外部接口才发现平台只允许调用预置动作。这是典型的定位错配CADP 把基础功能封装死了场景覆盖窄、垂直场景精细本来就不是给复杂应用准备的。解决办法在需求清单阶段就做凡是标了「复杂」的应用一律不进无代码队列哪怕它看起来只是个表单。5.2 交付侧的两条翻车记录现象四公有云版连不上内网的业务系统。应用搭得挺漂亮等到要往已有系统里回写数据发现公有云实例根本没有到内网的网络通路。报告里其实写得很清楚公有云部署无法与企业内网对接。这是部署形态选错不是技术难题。解决办法是先画一张网络可达性图把要对接的系统逐个标上去只要有一个在内网就只能在私有化、或者「公有云 定时导出 人工对账」之间做选择而后者的隐性人力成本往往被严重低估。现象五私有化报价批不下来。预算二十万方案报到百万级项目直接死在立项会上。原因通常是把整个平台一次性买断没有拆模块、没有分期。报告提到私有化的费用包含平台打包安装和按年更新两部分这两部分是可以谈的。解决办法是要求厂商按模块报价把一期必须上的应用压缩到三个以内先买账号数加工作流和表单引擎报表和集成引擎放到二期用一期的实际使用数据去申请二期预算。5.3 上线后要盯的三个观察指标第一条是月活搭建人数。平台交付后如果只有两个人建应用其余账号都在看说明培训没到位或者场景选错了这时候补培训比加模块有用。第二条是应用改动频次。业务方自己在改表单、改流程是好信号所有改动都要提工单给 IT说明平台没真正交出去后续的续费大概率保不住。第三条是跨系统调用量。集成引擎的调用量长期为零意味着平台还停留在孤岛阶段这时候要主动找一两个对接场景做出来否则下一轮评审时它会被判定为「可有可无」。6. 进阶用法把研报维度压成一张加权评分表报告里的维度是散在几十页里的评审会上没法直接讲。我的做法是把第 2 到第 4 章拆出来的东西压成一张加权评分表每个候选产品按 1 到 5 分打分权重按自己的场景调最后不只看总分更看短板。维度默认权重打分依据定位匹配0.20需求清单里复杂应用占比与产品类型是否吻合引擎覆盖0.20六大引擎里现场演示没答上来的项数部署形态0.15网络可达性与数据边界是否满足集成能力0.15账号体系、权限同步、双向接口的实测结果三年 TCO0.15五项成本加总后的三年总额厂商健康度0.15续费率区间、服务人员占比、版本策略打分之后用一段小脚本算加权总分并标出短板避免在会议室里靠感觉争论# 低代码平台选型加权评分把研报维度落成可复用的打分器 WEIGHTS { 定位匹配: 0.20, # 复杂应用占比与 LCDP/CADP 的吻合度 引擎覆盖: 0.20, # 六大引擎演示通过率 部署形态: 0.15, # 网络可达性 数据出域约束 集成能力: 0.15, # 单点登录、权限同步、双向接口实测 三年TCO: 0.15, # 订阅/授权 实施 集成 运维 迁移 厂商健康度: 0.15, # 续费率区间、服务人员占比、版本策略 } # 1不满足 3勉强 5完全满足键必须与 WEIGHTS 一致 SCORES { 候选A: {定位匹配: 5, 引擎覆盖: 4, 部署形态: 3, 集成能力: 4, 三年TCO: 4, 厂商健康度: 3}, 候选B: {定位匹配: 3, 引擎覆盖: 5, 部署形态: 4, 集成能力: 2, 三年TCO: 3, 厂商健康度: 4}, } FLOOR 2 # 短板阈值任一项低于等于此分总分再高也要单独说明 def rank(scores, weights, floorFLOOR): rows [] for name, items in scores.items(): total sum(items[k] * weights[k] for k in weights) weak [k for k, v in items.items() if v floor] rows.append((name, round(total, 3), weak)) return sorted(rows, keylambda x: x[1], reverseTrue) for name, total, weak in rank(SCORES, WEIGHTS): flag 短板 、.join(weak) if weak else 无明显短板 print(f{name}\t加权总分{total}\t{flag})代码逻辑很直白WEIGHTS的六个键对应上表维度权重合计为 1SCORES里每个候选产品的键必须与WEIGHTS完全一致少一个键就会抛 KeyError这是故意的防止漏评。FLOOR设成 2 分的意思是任何一项低于 3 分都必须在评审材料里写明理由而不是被高总分平均掉。运行输出的排序只作参考真正的决策依据是最后一列短板。参数怎么调也有讲究。私有化倾向强的组织把「部署形态」提到 0.25同时把「三年 TCO」压到 0.10因为这类组织的成本本来就不在订阅费上第一次上低代码、以试错为主的团队反过来把 TCO 和厂商健康度提上去先把试错成本控住。从那以后我每次做选型评审都强制把 POC 清单和这张评分表一起摆上桌先看短板再看总分。这个习惯替我省过一次百万级的错误决策。希望帮到你。本文还有配套的精品资源点击获取