企业官网建设流程全解析

简介：头豹研究院发布的《2022年中国低代码无代码平台行业研究报告》，面向数字化转型决策者、IT主管、产品研发人员，系统阐述低代码与无代码的定义分类、发展历程、平台架构、商业模式、部署方式及市场现状。包内含1个PDF文件，压缩包约3.43MB，研报正文含厂商四类商业模式对比、公有云与私有化部署差异、盈利情况与投融资梳理，还包含产业链与未来趋势分析。目前已有110人学习，适合产品选型、行业研究或了解低代码落地场景时参考，也可作为撰写行业分析、竞品对比前的快速背景资料。报告展示简道云、伙伴云、轻流等头部厂商盈利情况，也指出新客增量减少、客户续费率低下等现实挑战，能帮助读者快速把握中国低代码/无代码市场的竞争格局与潜在机会。

1. 低代码无代码平台报告：多数厂商在亏损，这反而是一份有用的选型地图

这份《2022年中国低代码无代码平台行业研究报告》把“低代码无代码快速构建企业数字化应用”这件事拆得很透，覆盖了平台定义、技术架构、商业模式、部署方式、产业链、投融资和应用场景。但真正给我留下反直觉印象的是它的盈利结论：多数低代码厂商处于亏损状态，客户续费率整体偏低，只有少数头部厂商实现轻微盈利。这意味着选型时不能只被“拖拽搭应用”的表象吸引，还要看厂商的商业模式是否健康、服务成本是否可控。报告适合三类人：正在做数字化应用选型的技术负责人、帮客户落地低代码的顾问或集成商，以及想评估低代码产品边界的产品经理。

2. 低代码与无代码的边界：看清两类平台的本质差异再选型

2.1 一个快读方法：从第四代编程语言到今天的演进脉络

低代码并不是一个新鲜概念。报告把它的起源追溯到了上世纪 70 年代的第四代编程语言，比如 SQL、R、ABAP 这类高级描述性语言，它们的目标就是让开发者用更少的指令完成数据库操作和报表生成。到了 90 年代，Visual Basic、Delphi 这些可视化编辑器把“拖拽式组装界面”带进了主流开发，快速应用程序开发（RAD）开始流行。RAD 的理念很接近今天的低代码——先关注图形界面，再逐步添加业务逻辑。但报告也指出它的局限：开发环境过于特定，缺乏模块化，导致团队协作困难。2001 年，模型驱动架构（MDA）被提出，它试图把业务模型从具体代码中抽离出来，让系统的可移植性和可维护性得到改进。2014 年，某权威市场研究机构正式提出“低代码”概念，云计算的发展给了这个概念落地的土壤。2020 年之后，企业数字化需求激增，低代码平台的普及率被快速拉升。

这条演进路径对选型有实际启发：低代码不是“从零发明的新工具”，而是可视化编程、模型驱动和云服务三者成熟后合流的结果。所以判断一个产品是不是真低代码，不是看它有没有花哨的拖拽界面，而是看它的底层是否具备模型驱动的数据结构、服务端逻辑编排能力，以及是否能独立构建前后端分离的应用。如果某个产品只是把表单模板拼一拼，没有任何数据模型引擎，那它更接近表单收集工具，而不是低代码平台。

下面这张表是我从报告里提炼出来的关键时间线，适合放进你的调研文档里：

看这条时间线，你会发现一个规律：低代码每隔十几年就会以新的形态出现一次，前几次都因为缺乏云基础设施或标准化生态而没能大规模普及。今天的低代码平台能不能长期用，关键看它是否建立在开放的云生态上，而不是封闭的自定义脚本。报告里反复出现的“aPaaS”变现路径，正是这个逻辑的产物——开发过程中无需准备服务器和中间件，用户只用“拖、拉、拽”就能创建应用。

2.2 低代码 vs 无代码：对比表、判断标准与“如果我是你”的建议

报告对低代码和无代码的差异给了一张很直观的对比表。我把它整理成更便于决策的形式：

这张表里最容易被忽略的是“个性化程度”。无代码平台声称“快8倍”，但它的代价是把表达复杂业务规则的能力封装掉了。如果你的业务流程里有多种粒度的审批分支、多系统数据需要交叉校验、权限要按组织和角色双维度控制，无代码平台会让你处处碰壁。反过来，如果你的团队全都是业务人员，只想快速跑通一个进销存或报修流程，低代码平台较高的学习门槛反而会让项目烂尾。

我平时给客户做选型，都会要求他们完成“三步判断”：

第一步，列需求清单并区分“关键业务”和“边缘业务”。关键业务指直接涉及交易、客户数据、合规流程的系统，边缘业务指内部协作、审批、信息收集。低代码试点尽量从边缘业务开始，避免第一个项目就撞上复杂集成。 第二步，盘点团队能力。如果团队里有 1-2 名能写 SQL 或 JavaScript 的人，低代码平台的可扩展空间会被放大很多；如果没有任何人懂代码，就只能选无代码平台，但必须提前问清楚平台是否支持“未来由开发者接管”的升级路径，比如代码导出、API 开放、数据字典导出。 第三步，算总成本。无代码的订阅费可能更低，但一个高度定制场景卡住你三天，人力成本就上去了。报告提到低代码厂商成本中服务售后占比达 40%-50%，这部分成本最终会通过订阅价或服务包转嫁到客户身上。你需要把第一年的实施服务费、后续版本升级费、员工培训时间全部算进 TCO。

这个三步判断法看起来简单，但很多人会跳过第一步，直接注册平台账号试用，结果被平台自带模板带偏，做了一个和真实业务不匹配的“玩具应用”，反而得出“低代码不行”的结论。报告里也提到，客户续费率低的核心原因就是“业务场景不匹配”和“自主搭建应用不顺利”，这两个词背后的血泪经验，绝大多数是选型阶段没有做好需求分级。

3. 平台架构与商业模式：看懂谁在赚钱，谁在裸泳

3.1 三层架构与六大引擎：看平台时不要把注意力只放在“拖拽界面”上

报告里给出了一个很有价值的低代码平台分层模型：基础层、平台层、应用层。基础层是数据库、物理机、云主机、操作系统，应用层是最终交付给用户的 ERP、CRM、OA、大屏展示等系统，真正的低代码技术集中在平台层。报告以某商业低代码平台为例，把平台层细分为六大运行引擎：

• 数据模型引擎：内建小型数据库，也可以直连主流数据库，提供可视化数据模型与查询视图设计能力。选型时问一句“能直连我们现有的哪些数据库”，就能筛掉一批只是自建表单存储的平台。
• 业务逻辑引擎：提供可视化业务逻辑设计和调试能力，支持在服务器端和页面端分别编排逻辑，实现前后端分离。只支持前端逻辑、不支持服务端逻辑的产品，严格意义上不算低代码。
• 工作流引擎：自由定制流程节点规则、关联业务处理，并支持工作流编排与调整。注意“调整”这个词，很多平台流程一旦发布，节点就不允许改动，只能停用重建，这在实际运维中非常痛苦。
• 页面渲染引擎：可视化页面设计器集成大量开箱即用的 UI 组件和样式，支持固定布局和响应式布局。高级平台还会允许你用自定义 CSS 或组件扩展做更精细的调优。
• 智能报表引擎：提供专业级报表设计能力，能定制统计报表、中国式复杂报表、类 Word 报告。这里的“中国式复杂报表”是指多级表头、合并单元格、动态行列等传统报表工具擅长而普通表单工具做不出来的格式。
• 系统集成引擎：提供数据库直连、WebAPI 构建与调用、用户认证与权限同步机制。这是企业级应用的分水岭——没有系统集成引擎的低代码平台，基本无法成为你现有系统中的一环。

这六个引擎不是所有产品都齐全。我见过不少号称低代码的 SaaS 产品，实际上只有“表单+流程+报表”三件套，数据模型引擎很弱，系统集成引擎几乎不存在。你在钉钉或某协同办公软件里搭一个内部审批应用没什么问题，但要用它对接你们的某个大型 ERP 或自研系统，大概率会翻车。

所以每接触一个新平台，我会把这六个引擎做成一张检查表，直接拿去问厂商：

报告原文在这一节还列到了第三方软硬件服务，包括企业微信、钉钉、主流 ERP 和数据库等，说明低代码平台从来不是孤立产品，它必须能嵌入你现有的软件生态。如果你现在的业务管理全靠 Excel 和邮件，那低代码平台带来的“应用标准化”反而是好事；但如果你的公司已经有一套复杂的系统在运行，低代码平台要做的第一件事就是接入这套系统，而不是另起炉灶。

3.2 四种商业模式：厂商赚什么钱，直接影响你的服务质量和议价空间

报告把低代码厂商的商业模式分成四种：直接面向客户、间接面向客户、前后端开发平台、生态型平台。它们之间的差异，决定了你在采购时会碰到谁、由谁负责实施、出了问题找谁。

这里常见的认知误区是：采购方倾向于选“直接面向客户”的厂商，觉得厂商亲自服务一定更可靠。但报告也点了问题：服务售后成本高企，场景不匹配和搭建不顺利导致客户续费率低。如果厂商派来的实施顾问只是会拖拽组件、并不懂你的行业业务流程，那和间接模式下找来的第三方 ISV 没有本质区别。反过来，间接面向客户模式下，第三方 ISV 往往深耕某一行业，有的做得比厂商原厂顾问更好。所以不要被“官方服务”四个字迷惑，关键看合同里有没有约定实施责任方、SLA 响应时间和交付验收标准。

我一般会在间接模式下，要求厂商和第三方伙伴共同出书面确认：应用上线后第一响应时间和修复时限归谁，数据权限和备份归谁，二次开发需求走什么通道。报告里的“生态型平台模式”还处在早期，只有少数大厂能玩转，多数企业客户没必要一开始就选这种模式，除非你已经决定深度绑定某个平台生态。

3.3 盈利数据背后的信号：为什么续费率低，以及我们怎么避免踩坑

报告给了两个非常有参考价值的成本占比：研发人员占 30%-40%，服务人员占 40%-50%。这意味着低代码厂商本质上是一种“重服务”生意，而不是纯软件生意。多数厂商亏损的原因来自三个叠加：新客增量减少、客户续费率低、服务成本高。对客户来说，这两个数据直接影响你未来能得到的支持质量。

首先，如果一个厂商的续费率低，说明大量客户搭建不顺利、场景不匹配。你在采购前有责任要求销售提供真实的“客户续费率”和“近一年活跃客户数增长”情况。如果销售支支吾吾，只给你看登入成功的 Demo 录屏，那就要警惕。其次，厂商服务人员占比接近一半，意味着它的交付成本很高，如果订阅价格压得特别低，后续服务一定会缩水或通过项目制额外收费。最后，厂商处于持续亏损时，可能通过裁员或削减服务团队来控成本，这会让你的应用上线后处于无人维护的状态。

我在一次公开分享时讲过这个判断方法：看厂商商业健康度，品牌、融资、盈利状况都要看，但最核心的是续费率。一个产品即便做的再好看，如果客户第二年都不续费，那你大概率也会在第二年发现问题。报告里说“仅少数头部厂商可实现轻微盈利”，这个结论在选型中不是一句废话，它就是筛选供应商的一道硬性门槛。至少，你要选择资金储备足够、团队稳定且有持续版本更新的厂商，而不是一个连官网更新都停滞的团队。

4. 部署方式与产业链落地：公有云还是私有化，照这份清单来

4.1 公有云部署 vs 私有化部署：四维对照表与决策步骤

报告对公有云部署和私有化部署做了四个维度的对比：收费方式、需求响应、维护方法、部署周期。我把它整理成一张可以直接抄进评估表的对照：

报告提到，目前大多数成功交付的低代码产品是公有云部署，价格在几千元每年。私有化部署则常见于金融、电信这类对数据安全要求极高的行业，价格通常在百万级。报告给出的原因是：私有化部署下企业数据存在自有服务器，维护更安全稳定；但企业要承担服务器采购和运维人力成本。

我建议的决策步骤是：

第一步，数据合规评估。先让法务和安全团队确认，你们要低代码承载的业务数据里，有没有个人敏感信息、商业秘密或监管要求必须私有化存。如果有，直接偏向私有化；如果没有，公有云是性价比更高的起点。 第二步，集成需求评估。低代码应用如果需要高频访问内网数据库或专有系统，公有云平台通常无法直接穿透内网。除非平台提供代理网关或混合云桥接模式，否则别硬上公有云。这一步可以被报告里的“无法与企业内网对接”直接命中。 第三步，三年 TCO 测算。公有云按三年订阅费加可能的加模块费用；私有化要算上服务器、存储、备份、安全加固、运维人员月薪，以及报告里提到的按年更新费用。我算过不少客户的数字，私有化的总拥有成本往往是公有云的 3-5 倍。这不是说私有化不值得，而是你必须明确这份成本买来的数据主权和定制空间值不值。

4.2 产业链三类厂商：独立厂商、生态厂商、互联网/云厂商，怎么识别和选择

报告把低代码厂商按微观分为三类：独立厂商、生态厂商和互联网/云厂商。这三类厂商服务对象的重合度很高，但产品定位差异很大。

独立厂商也叫原生厂商，从创立之初就专注低代码平台的研发和销售。这类厂商的特点是把低代码当作唯一主营业务，产品迭代节奏快，垂直功能做得细。常见的代表是那些表单流程类工具，团队规模不一定大，但客户口碑往往不错。它的风险在于公司规模可能有限，如果你是大企业客户，需要确认它是否有能力和意愿服务你的体量。

生态厂商是从传统 ERP、CRM、OA 等企业管理软件拓展过来的。它们原本就有庞大的企业客户基础，低代码平台往往是原有产品线的补充，用来满足客户长尾的定制化需求。这类厂商的优势是行业理解深，和自家主产品集成非常顺滑；风险在于低代码业务可能不是战略核心，一旦母公司收缩投入，低代码产品线的更新速度就会明显放慢。

互联网/云厂商推出低代码平台，主要目的是为其协同办公产品补充应用搭建能力。这类平台的最大优势是入口多、上手快，用户能直接在协同办公软件里访问；最大风险则是平台绑定强，数据导出和跨平台迁移往往受限制，一旦你深度使用了某个特定生态，后续想迁徙会付出额外成本。

识别方法很简单：第一，看官网产品定位。独立厂商会把自己叫“低代码开发平台”，生态厂商会把它放在“产品矩阵”里的一个模块，互联网/云厂商则会把它藏在“管理后台-应用中心”。第二，看版本更新日志。独立厂商通常月度或季度更新，生态厂商跟随大版本节奏，互联网/云厂商更倾向于小步快跑式的功能迭代。第三，看技术客服的答题深度。向客服问一句“你们的系统集成引擎支持哪些认证方式”，独立厂商能给你讲清楚，生态厂商会转到主产品顾问，互联网/云厂商大概率只会说“我们支持钉钉登录”。

4.3 行业应用占比与场景清单：用它做需求调研模板

报告给出低代码应用在行业端的占比：制造业 30%，零售业 20%，服务业 15%，国企/建筑/教育合计约 5%，其他约 30%。制造业排第一，因为制造企业存在大量非标环节，传统 ERP 价格高、流程固化，低代码正好填补了灵活应用的空间。报告同时提醒，制造业生产过程有大量非标环节，并不完全适合标准化控件的低代码开发。所以占比高只能说明需求基数大，不代表每个制造场景都适合低代码。

报告列的应用场景还包括 CRM、生产报工与跟踪、供应商管理、进销存、订单管理、工程进度管理、物资管理、售后、会员充值消费、教师考勤、校园宿舍管理、电梯维保、门店巡检、社区管理等。我建议你拿这份清单做一次“需求映射”：

• 把报告场景清单拷贝到 Excel，每个场景一行。
• 增加一列给业务部门勾选“现有没有系统覆盖”。
• 再增加一列给信息化负责人打分，分数代表“这个场景不上线，业务痛点有多高”。
• 汇总后，优先选“痛点分高且当前无系统覆盖”的场景作为低代码第一个试点。
• 试点选择有讲究：不要选全流程涉及核心交易和财务的系统，选一个流程长短适中、数据量可控、失败影响小的边缘业务，比如设备报修、门店巡检、物资申领。跑通一个完整场景后，再向生产报工、进销存这类关键业务扩展。

报告里的“行业应用场景占比”是基于头部厂商交付案例汇总的，它反映的是市场现状，而不是你的业务标准答案。我能给出的建议是：把它当作思路库，而不是照抄清单。你真正要做的事情是在自己公司内部做高频流程盘点，把纸质审批、Excel 台账、多人协作邮件这些低效环节找出来，再匹配低代码平台的能力边界。

5. 避坑指南：读报告和做选型时容易踩的五个认知坑

5.1 现象：拿报告当“万能说明书”，直接照搬别人的方案

原因：报告是行业级宏观洞察，不是企业级实施蓝图。它告诉你制造业应用占比最高，但你的制造业场景可能是完全特殊的供应链协同，而不是生产报工。直接照搬报告里的成功案例，会低估你的业务特殊性。 解决：把报告当作“场景菜单”和“概念框架”，先做完第 4 章的需求映射，再决定用哪个场景。至少把你们内部的 Top 10 高频流程列出来，再去和报告场景清单交叉比对，选重合度高且业务价值明确的场景试点。

5.2 现象：只盯“无代码快8倍”的数字，忽略了前提条件是“简单应用”

原因：报告对比表里的“快8倍”是基于简单应用和熟练业务人员的理想情况。一旦场景涉及复杂业务逻辑、多系统集成，无代码平台会因为表达能力不足而频繁返工，交付速度反而更慢。 解决：用报告里的分类逻辑划边界——无代码适合“表单或办公自动化应用程序”，低代码适合“较复杂的应用场景”。立项时把需求按复杂程度分级，简单场景交给无代码，复杂场景交给低代码或传统开发，不要用一个工具包打天下。

5.3 现象：把“私有化部署更安全”当成默认答案

原因：报告说私有化部署把数据留在企业自有服务器上，确实能降低第三方服务商接触数据的风险。但它没有提醒你，私有化部署同时把安全运维责任转移到了你的团队身上。如果企业没有专职安全人员，补丁更新、漏洞排查、容灾备份都可能滞后，实际安全水平未必高于服务商集中防护的公有云。 解决：先做安全能力自评。如果没有专职运维，优先选公有云或混合云模式，并和厂商约定数据加密、访问审计、备份恢复方案。如果必须私有化，单独拨预算给安全加固与定期巡检，不要把安全责任默认外包给低代码平台。

5.4 现象：看到多数厂商亏损，就否定整个赛道

原因：亏损主要是商业模式问题——高研发成本加高服务成本，新客增长受宏观环境影响，不代表低代码技术本身无效。有些亏损厂商的产品能力很强，只是商业上尚未跑通。 解决：区分“产品能力”和“商业健康度”。先按第 3 章的六大引擎检查表确认产品是否及格，再问厂商要续费率、平均交付周期、客户支持响应时间等运营数据。如果产品能力强、商业暂时亏损但融资储备充足，可以列入候选继续谈；如果产品能力弱且财务情况不明，果断放弃。

5.5 现象：忽略部署方式对续费的影响，选了“即买即用”却想深度定制

原因：公有云部署的低代码产品偏向标准化，功能模块相对固定。很多客户前期图便宜，上线后才发现大量场景需要对接内网、定制审批规则、调整页面逻辑，而公有云产品不支持，最终搭建不顺利，第二年不续费。 解决：在第一年不要把所有应用都绑在一个公有云订阅上。预算允许时，要求厂商先提供试用空间，挑两个真实场景做两周 Demo，重点验证集成、权限和定制能力。同时在合同里写明“如需私有化部署或混合模式的迁移路径”，避免平台锁定。如果你们明确有大量定制需求，采购起点就应该是支持私有化部署的平台，而不是先用公有云再把成本连番地追加回来。

6. 把报告变成决策工具：“三看”验证法与我后续还会做什么

我读这类行业报告的习惯，是把几万字的分析压缩成三句话：看架构、看模式、看部署。我把这套动作叫作“三看”。

• 一看架构：平台层是否具备数据模型、工作流、页面渲染、智能报表、系统集成等完整引擎，并且能开放 API。没有数据模型和集成引擎，这样的平台只能做表单级应用，撑不起企业数字化骨架。
• 二看模式：厂商是直接面向客户，还是依赖第三方实施；续费率有没有真实案例和数据支撑。商业模式不清的平台，后续服务容易扯皮。
• 三看部署：公有云适合快速试错，私有化适合强数据管控。无论选哪种，三年总拥有成本必须算清楚。

下面这张验证卡片，我把它放在每一次低代码项目立项文档的附录里：

读完这份 2022 年中国低代码无代码平台行业研究报告，我最想向读者强调的不是“低代码能做什么”，而是“低代码不能做什么”。它不能替代复杂系统全流程重构，不能突破标准化的边界，也不能解决企业自身的流程梳理问题。报告里说的“业务人员大多不具备梳理流程和数据的能力”，在每一家企业的落地上都会成为真正的瓶颈。

从那以后，我每次接触一个新的低代码平台，都强制自己做一遍“三看”，再约厂商做现场 Demo。事实是，这个标准筛掉的第一批产品，正是那些只有表单和流程、没有数据模型引擎、也讲不清续费率的“表单型平台”。筛完之后，再回看报告里的行业应用占比，就会觉得它开始有用了——因为你不是在大海里捞鱼，而是在有限的几条航道里，拿着一张能看懂暗礁的海图下网。

希望这份报告拆解和选型框架能帮到你。如果你也正在评估低代码平台，试着用这三段式走一遍，你会少走我做过的不少弯路。

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