企业官网建设流程全解析

简介：这份头豹研究院2022年11月发布的行业研究报告，聚焦中国低代码与无代码平台，适合企业数字化负责人、产品经理、SaaS从业者及投研人员梳理赛道格局与商业逻辑。全文围绕低代码/无代码的定义分类、发展历程、平台架构、四种商业模式、公有云与私有化部署差异展开，并进一步讨论厂商按独立厂商、生态厂商、互联网/云厂商的划分，以及收费模式、投融资、盈利状况与续费率偏低等现实挑战，对简道云、伙伴云、轻流等头部厂商的微利状态亦有提及。包内为1个PDF文件，压缩包约3.43MB，便于检索和离线阅读。目前已有111人学习，可作为快速了解低代码/无代码产业链、部署选型与市场趋势的参考材料，也可用于整理行业框架、撰写方案或开展竞品研究时对照查阅。

1. 2022年那份低代码/无代码行业报告，最扎眼的不是增速而是亏损

一份发布于2022年11月的行业研究报告，把中国低代码/无代码平台从定义、架构、商业模式一直拆到投融资和政策，讲得相当完整。但通篇读下来，最反直觉的数字不是投融资同比增长266.7%，而是另一句轻描淡写的结论：多数厂商仍处于亏损状态，只有少数头部玩家做到轻微盈利。这个判断放在一个被反复称作"风口"的赛道里，显得格格不入。企业数字化应用的构建方式确实在变，拖拽、可视化、少量代码就能搭出一套进销存或工单系统，这句话在过去几年被讲了太多遍，以至于很少有人追问：谁在为这套效率买单，买单的人续不续费，卖的人赚不赚钱。这份报告的价值恰在这里——它没有停在"低代码能提效"的层面，而是把成本结构、续费率、部署账本这些不太好看的里子翻了出来。对从业者来说，这比任何增长曲线都更值得读一遍。

2. 报告的基本盘：低代码与无代码是两条产品线，不是同一个词的长短版

2.1 定义分野：一行代码的门槛，划出了两拨完全不同的客户

报告开篇做的第一件事，是把"低代码"这个被用滥的词拆开。低代码开发平台指的是通过少量代码就能快速生成应用的开发平台，用户借图形化界面、拖拽组件和模型驱动的逻辑来创建网页与移动应用；而无代码则是把基础功能整体封装，用户只能在既有能力里调用，字段设定、数据处理都不需要碰代码。两者常被合并成"低代码/无代码"一个词，但报告明确指出，它们在用户群体和使用特性上都不是一回事。

这个差别落到具体维度上很清晰。低代码面向有编程基础的IT人员，相对传统开发大约快2倍，易用性偏低，需要具备代码知识，个性化程度较高，适合有资金、有研发团队的中大型企业，扛得住较复杂的应用场景。无代码面向没有编程基础的业务人员，速度能快8倍左右，易用性和开箱即用程度更高，个性化空间小，适合没有研发团队、软件需求紧急、业务变化快的中小企业，或者中大型企业里的某个部门、某个项目。

从行业角度看，这张表真正的含义不是"谁更强"，而是两条产品线的成本结构和交付方式根本不同。低代码卖的是可扩展性，客户买回去还要有人会用；无代码卖的是即拿即用，客户买回去最好当天就能跑起来。销售环节把这两个词混着用，是最常见的翻车起点——对着一个没有IT团队的中小企业讲"你可以用简单代码去改造"，对方听到的其实是"你还得养个程序员"。

报告还点出了变现形态：低代码和无代码平台的主要变现形式是aPaaS，也就是应用程序平台即服务。开发过程不需要自备服务器、中间件这些基础设施，用户只管拖拽，底层资源由平台方兜着。这个定位决定了它天生是订阅制生意，也决定了厂商必须持续迭代——客户第二年续不续费，取决于平台这一年有没有跟上他的业务变化。

2.2 五十年时间线：概念2014年才有，逻辑能追到第四代语言

报告里有一条容易被略过但信息量很大的时间线。"低代码"这个概念由一家市场研究机构在2014年正式提出，但背后的逻辑可以追到上世纪70年代。1970到1990年是第四代编程语言的阶段，ABAP、Unix Shell、SQL、PL/SQL、Oracle Reports、R这类语言开始支持数据库管理、报告生成、数学优化、图形界面和Web开发。1990年，用Visual Basic、Delphi、Oracle Forms这类可视化工具"组装"桌面应用的做法流行起来，快速应用开发（RAD）成型，核心理念是先把界面做出来，再逐步补业务逻辑。2001年，对象管理组织推出模型驱动架构（MDA），把需求捕获、分析、设计、编码、测试、部署串成一套框架。2007年iOS入场、2008年Android问世，移动平台带来了新的可视化开发工具。2014年概念落地，2020年疫情把企业数字化转型的需求推到了台前。

报告把它划成三个阶段：1970到2013年的萌芽期，2014到2019年的升温期，2020年至今的快速增长期。

这条线真正说明的是：低代码不是横空出世的新技术，而是软件工程里"抽象层级不断上移"的又一次尝试。每一次上移，都是把上一代开发者反复手写的部分封装成可复用能力。理解了这一点，评估一个平台就不会停留在"界面好不好看、拖拽顺不顺"——那是表象，真正的分水岭是封装的粒度：封装得越粗，上手越快、边界越死；封装得越细，灵活度越高、越需要人会用。这也解释了后面所有的商业困境，为什么有的客户用得很顺，有的客户买了就闲置。

2.3 平台架构：六大引擎撑起的中间层，决定了交付的天花板

报告用了一个具体平台做样本，画出了低代码平台的典型架构：自下而上分基础层、平台层、应用层，低代码/无代码技术主要落在平台层，那里是应用生产的引擎。基础层是物理机、PaaS平台、各类操作系统、云主机和数据库，包括SQL Server、MySQL、Oracle、PostgreSQL以及国产数据库；应用层是PC端、移动端、大屏展示、嵌入ERP/CRM/OA/MES的客户端；中间的平台层则由六大引擎构成。

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

这六个引擎的齐备程度，基本决定了一个平台能接多复杂的活。数据模型和页面渲染是入门件，大多数平台都有；工作流和业务逻辑决定能不能做带审批、带分支的真实业务；智能报表决定了能不能替掉企业里那些用Excel手工汇总的环节，中国式复杂报表尤其是个硬门槛；系统集成引擎则决定了平台是"孤岛"还是"补丁"——能不能跟企业已有的ERP、CRM对接，往往是一单生意成不成的关键。

从交付角度看，这份架构图还藏着一个成本信号：引擎越多、能力越全，平台层就越重，私有化部署时要打包安装、要对接客户现有软硬件、要按客户环境调优的工作量就越大。这也解释了为什么公有云部署能做到即买即用、几千元一年的量级，而私有化部署动辄百万级——差价买的不是软件功能，是把这套引擎装进客户机房并让它转起来的人力和时间。

3. 商业化拆解：四种模式与两套部署账本

3.1 四种商业模式，赚的不是同一份钱

报告把低代码厂商的商业模式拆成四种：直接面向客户、间接面向客户、前后端开发平台、生态型平台。这个分类看起来平淡，实际上决定了厂商的收入结构、成本结构和客户关系质量。

直接面向客户模式是当下的主流。厂商直接向企业客户提供产品，通过付费订阅收费，满足通用性开发需求；如果平台上的通用模块覆盖不了客户的场景，厂商再提供定制化开发服务，用"产品+项目实施"的方式交付。这个模式的好处是客户关系握在自己手里，续费有抓手；坏处是实施服务很重，人力成本随客户数线性增长，规模效应不明显。

间接面向客户模式把实施环节交出去。厂商针对相对通用的场景提供产品，客户的定制化需求由第三方ISV、咨询公司等合作伙伴实施。收入怎么分很清楚：厂商赚产品费，合作伙伴赚实施服务费。这个模式让厂商的收入更"轻"，但客户体验被切成两段，一旦实施方交付不力，骂名还是会算到平台头上。

前后端开发平台模式面向的客户是软件开发商本身，提供前端或后端开发所需的框架、插件、控件、组件，用云原生、微服务架构、DevOps这些理念帮对方提升开发效率，减少开发人员的代码编写量。说白了这是卖给同行的生意，客户懂技术、议价能力强、对性能和扩展性要求高，但一旦用进去，替换成本也高。

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

从行业角度看，这四种模式的差别不在收钱方式，而在"谁承担场景不匹配的风险"。直接模式下风险全在厂商身上，客户搭不出来就是厂商的服务问题；间接模式把风险分给伙伴，但品牌受损的还是平台；生态模式把风险摊给整个生态，代价是厂商对终端的感知变弱。这也解释了报告后面那个结论：为什么续费率整体偏低——场景不匹配这件事，在四种模式里都没有被真正解决，只是被转移了。

3.2 公有云几千元、私有化百万级：差价买的到底是什么

部署方式是这份报告里最实在的一节。低代码平台分公有云部署和私有化部署，报告直言目前大多数成功交付的产品是公有云方式。两种方式在收费、需求响应、维护方法、部署周期上差异明显。

收费上，公有云按模块数量和使

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