企业官网建设流程全解析

简介：这份头豹研究院出品的行业研究报告聚焦2022年中国低代码与无代码平台，面向企业数字化负责人、产品经理、投资研究者及希望了解低代码赛道的技术从业者，系统解答行业参与者构成、厂商分类与商业模式、部署方式与收费模式、投融资情况及未来趋势等关键问题。报告从低代码与无代码的定义差异切入，梳理其从第四代编程语言到2020年后快速增长的发展历程，并深入剖析直接面向客户、间接面向客户、前后端开发平台、生态型平台四类商业模式，对比公有云与私有化部署在收费、响应速度、维护与周期上的差异，同时揭示研发服务成本上升、续费率偏低导致多数厂商亏损的现状。资源包共1个PDF文件，大小约3.43MB，单文件即涵盖完整报告正文与图表。已有111人学习下载，适合作为行业入门与竞争格局分析的参考材料。

1. 低代码的真相：拖拽只是表象，引擎才是内核

很多人第一次接触低代码平台，看到的是「拖、拉、拽」三个字，于是下意识把它归类成表单工具或者页面搭建器。这个判断错得离谱。真正让低代码能跑通企业级应用的，从来不是前端那个可视化画布，而是画布背后一整套运行引擎——数据模型引擎负责把可视化字段翻译成表结构和查询视图，业务逻辑引擎负责把节点编排翻译成可执行的服务端逻辑，工作流引擎负责把流程定义翻译成状态机。拖拽只是交互层，引擎才是执行层。搞懂这一点，你才能理解为什么有的平台能撑起进销存、生产报工、工程物资管理这类复杂场景，而有的平台只能做做问卷和审批。这份行业研究报告把平台架构拆到引擎粒度，正好是理解低代码底层机制的一手材料。

2. 平台架构：六大引擎如何把可视化操作翻译成可运行系统

低代码平台的产品形态千差万别，但架构分层大体一致：自下而上分为基础层、平台层、应用层。基础层是数据库、操作系统、云主机这些老面孔；应用层是最终交付的 ERP、CRM、OA、工单系统；真正承载「低代码」这件事的是中间的平台层。平台层里塞着一组引擎，它们各自负责一类翻译工作，合起来构成应用生产的流水线。以报告中提到的活字格平台为例，平台层包含数据模型、业务逻辑、工作流、页面渲染、智能报表、系统集成六大引擎。下面逐个拆开看它们各自解决什么问题。

2.1 数据模型引擎：可视化字段怎么变成真实的表结构

数据模型引擎是整条流水线的起点。用户在界面上拖一个「文本字段」、一个「日期字段」、一个「关联字段」，引擎要做的事情是把这些声明式的元数据翻译成数据库能执行的 DDL，同时生成配套的查询视图。报告里提到它「内建小型数据库，可直连主流数据库，提供可视化数据模型与查询视图设计能力」，这句话信息量很大。

内建小型数据库的意义在于开箱即用——用户不需要先准备一个数据库实例就能开始建模，降低了起步门槛。直连主流数据库的意义在于落地能力——SQL Server、MySQL、Oracle、PostgreSQL 以及国产数据库都能接，企业已有的数据资产不用迁移。查询视图设计能力则是把「多表关联查询」这种原本要写 SQL 的活，变成可视化配置。

常见的实现思路是维护一份元数据模型（字段名、类型、约束、关联关系），在发布应用时由引擎生成建表语句和视图定义。这里有个容易被忽略的细节：字段类型到数据库类型的映射不是一一对应的。比如「多选」字段在关系型数据库里没有原生类型，通常要落成关联表或者 JSON 列，选哪种直接决定了后续查询的性能和可维护性。引擎在这一层的取舍，往往决定了平台能撑多复杂的业务。

2.2 业务逻辑引擎：前后端分离是怎么在可视化里实现的

业务逻辑引擎负责把「当某字段变化时执行某段计算」「提交前校验某条件」这类规则，翻译成运行在服务端或页面端的可执行逻辑。报告的描述是「提供可视化业务逻辑设计和调适能力，可自由编排运行于服务器和页面的业务逻辑，实现前后端分离」。

前后端分离在传统开发里是架构决策，在低代码里变成了引擎的职责划分。页面端逻辑处理交互响应、即时校验、界面联动，追求的是响应速度；服务端逻辑处理数据持久化、跨表事务、权限校验，追求的是安全性和一致性。引擎需要把用户编排的同一套逻辑图，按节点属性拆分到两端执行。

我一般会这么理解这套机制：逻辑编排本质上是一张有向图，节点是动作（赋值、查询、调用服务、发消息），边是执行顺序和条件分支。引擎在发布时把图序列化成配置，运行时由解释器逐节点执行。这里的关键设计取舍是「解释执行」还是「编译执行」——解释执行灵活、热更新方便，但每次执行都有解析开销；编译执行性能好，但改动逻辑要重新发布。多数平台选择解释执行，因为低代码的用户群体对发布等待的容忍度很低。

2.3 工作流引擎：流程定义如何变成可运转的状态机

工作流引擎处理的是「谁在什么条件下把单据推进到下一个节点」。报告说它「支持自由定制流程中各节点的各项规则和关联的业务处理，以及对工作流程的编排与调整」。企业应用里大量场景本质是流程：报销审批、工单流转、工程物资领用、合同会签。

流程定义通常包含节点、流转条件、参与人规则、节点动作四要素。引擎在运行时要维护每个流程实例的当前状态，并在状态迁移时触发对应的业务处理。难点不在单条流程跑通，而在流程变更——企业组织架构调整、审批层级变化是常态，引擎必须支持运行中实例的流程版本迁移，否则改一次流程就得让在途单据全部作废，这个血泪经验做过流程系统的人都懂。

2.4 页面渲染、报表与集成引擎：交付面的三块拼图

页面渲染引擎负责把设计器里的组件树渲染成实际页面，报告强调它「集成大量开箱即用的 UI 组件和外观样式，支持固定布局和响应式布局」。固定布局适合大屏和 PC 端复杂表单，响应式布局适合移动端，两套布局模式并存说明平台在覆盖多端场景。

智能报表引擎解决的是中国企业特有的复杂报表需求——「定制统计报表、中国式复杂报表、类 Word 报告」。中国式报表的特点是合并单元格多、表头层级深、数据来源跨表，通用 BI 工具往往搞不定，需要专门的报表引擎支持单元格级的数据绑定和公式。

系统集成引擎是低代码能不能进企业的关键。报告列出「数据库直连、WebAPI 构建与调用、用户认证与权限同步机制」。企业里已经有 ERP、CRM、OA，低代码应用不可能孤立存在，必须能读写既有系统的数据、复用既有的账号体系。集成能力弱的平台，最后只能做边缘小工具；集成能力强的平台，才有机会做核心业务的功能补充。

提示：评估一个低代码平台，别只看画布好不好用，重点看这六个引擎里哪几个是自研的、哪几个是拼凑的。引擎的自研深度决定了复杂场景下的天花板。

3. 商业模式与部署方式：按年付费背后的成本结构

理解了引擎，再看商业层面就顺了。低代码厂商卖的不是一次性软件，而是持续迭代的平台服务，这决定了它的收入模型和成本模型都必须是长周期的。

3.1 四种商业模式：谁赚产品费，谁赚实施费

报告把商业模式分成四类。直接面向客户模式是主流：厂商直接卖平台给企业，通用模块满足不了就加定制化实施，产品费加服务费一起收。间接面向客户模式把实施交给第三方 ISV 和咨询公司，厂商只赚产品费，合作伙伴赚实施费——这个分工的好处是厂商能专注产品迭代，坏处是对交付质量的控制力下降。

前后端开发平台模式面向软件开发商，提供框架、插件、控件、组件，帮开发商提升开发效率。生态型平台模式最重：厂商不直接卖产品，而是搭平台、定标准、收授权费，让专业开发者和 ISV 在上面做生意。报告明确指出生态型模式「尚处早期发展阶段」，对厂商的产品能力和生态建设能力要求都高。

这四种模式的本质区别在于「价值捕获点」放在哪里：产品、实施、开发工具还是平台授权。选哪种取决于厂商的产品标准化程度和渠道能力，没有普适最优解。

3.2 公有云与私有化：几千元每年和百万级投入的分野

部署方式的差异直接体现在价格上。报告给出的数字很具体：公有云产品价格在几千元人民币每年，私有化部署则在百万级人民币不等，包含打包安装费和按年更新费。这个价差不是随便定的，背后是成本结构的差异。

公有云部署即买即用，无部署周期，厂商统一维护，但产品偏标准化、模块相对固定，且无法与企业内网对接。私有化部署要和企业原有软硬件对接集成，部署周期长，但数据存在企业自有服务器上，升级灵活、可自由拓展。报告提到偏好私有化部署的企业「大多集中在金融和电信领域」，原因不难理解——数据安全要求和系统集成需求都高。

这里有个值得琢磨的点：报告说「大多数成功交付的低代码开发平台产品为公有云方式部署」。成功交付集中在公有云，说明低代码的价值主张——快速、低成本——在公有云模式下才能完整兑现。私有化部署虽然客单价高，但定制化对接吃掉了大量人力，交付周期长，反而稀释了「快」这个核心卖点。

3.3 成本结构：研发三到四成、服务四到五成，钱花在哪

报告披露了人员结构：研发人员团队占比 30% 到 40%，服务人员团队占比 40% 到 50%。服务人员比研发人员还多，这个比例在纯软件公司里不常见，但在低代码行业是合理的。

研发成本的大头不是技术攻关，而是「产品日常的更新和迭代」。客户数量增加、业务场景拓宽，对场景覆盖度的要求就水涨船高，研发团队必须保持一定频率的更新才能留住客户。服务售后成本则花在企业管理员培训和应用搭建协助上——低代码的用户是业务人员，他们没有梳理流程和数据的能力，厂商得派人陪着搭。

这就引出了行业的核心矛盾：高「研发加服务」成本，低「新客加续费」收入。报告直言多数厂商处于亏损状态，仅少数头部厂商实现轻微盈利。续费率低的原因也写得很实在：客户采购后发现业务场景不匹配、自主搭建不顺利，就不再续费或者换供应商。低代码卖的是「让业务人员自己搭应用」的承诺，承诺兑现不了，续费自然崩。

4. 厂商分类与行业落地：低代码和无代码不是一回事

市场上把低代码和无代码混着说，但从技术能力和适用群体看，这是两条产品路线。

4.1 低代码与无代码：开放容器和封装调用的路线之争

报告给出的对比很清晰。低代码平台面向有编程基础的 IT 人员，UI 界面可以用 HTML 等语言编写，数据库处理可以用 SQL 深度加工，产品发展路径偏开放，容器功能多但不够精细，用户需要用少量代码改进到想要的模式，速度快 2 倍，个性化程度相对较高，适合有资金和研发团队的中大型企业。无代码平台面向无编程基础的业务人员，基础功能全部封装，用户只能调用已做好的功能，场景覆盖面少但垂直场景精细，即拿即用，速度快 8 倍，适合无研发团队、需求紧急、业务变化快的中小企业。

这个分野的技术本质是「扩展点开在哪里」。低代码在组件、逻辑、数据层都留了代码扩展口，灵活但有门槛；无代码把扩展口全部封死，易用但天花板低。选型时最怕的是拿无代码平台去接复杂业务，或者拿低代码平台去服务完全不懂技术的业务人员，两头都会翻车。

4.2 三类厂商：独立、生态、互联网云的切入逻辑

微观分类上，独立厂商自创立起就专注低代码研发销售；生态厂商是传统 ERP、CRM、OA 厂商把产品线拓展过来，用来完善产品生态；互联网/云厂商则把低代码作为协同办公产品的功能补充。三类厂商的动机不同，产品形态也就不同：独立厂商拼的是平台能力深度，生态厂商拼的是与既有管理软件的集成度，互联网云厂商拼的是与协同办公入口的绑定。

4.3 行业应用分布：制造业占三成为什么合理

报告给出的应用占比是：制造业 30%，零售业 20%，服务业 15%，国企、建筑、教育合计约 5%，其他 30%。制造业占比最高有其合理性——中小微制造企业买不起传统 ERP，传统 ERP 流程又过于固化，改功能成本高昂，低代码的高性价比正好切中痛点。大型制造企业则走另一条路：ERP 功能完善，不需要低代码做复杂开发，但有功能改进需求时通过 API 把低代码应用和 ERP 连起来做补充。

这个分层很关键：同一行业里，大企业和中小企业的低代码用法完全不同。给中小企业卖的是「替代昂贵 ERP 的轻量方案」，给大企业卖的是「既有系统的功能补丁」。产品定位搞混，交付就会出问题。

5. 避坑与常见问题：低代码落地时最容易踩的五个坑

5.1 场景不匹配：买回来才发现搭不出来

现象：采购时演示很流畅，正式搭建时发现目标场景需要的字段关联、权限粒度、流程分支，平台都不支持或者支持得很别扭。原因：售前演示用的是平台最擅长的标准场景，而企业真实业务里有大量非标环节，标准化控件覆盖不到。解决：选型阶段拿真实业务单据做 PoC，至少跑通一条完整流程，别只看演示。

5.2 业务人员搭不动：说好的全民开发变成厂商代劳

现象：平台交给业务部门后，业务人员搭了几个简单表单就卡住，复杂逻辑还是得找厂商或 IT 部门。原因：业务人员不具备梳理流程和数据的能力，报告里明确点出了这个挑战。解决：把「轻度咨询」纳入实施范围，先帮业务部门把流程和数据理清楚，再让他们上手搭；同时给 IT 部门保留兜底的扩展能力。

5.3 续费率崩盘：第一年用得好，第二年不续了

现象：首年采购顺利，第二年续费时客户流失。原因：场景不匹配加上搭建不顺利，客户觉得投入产出不划算。解决：厂商侧要保证产品更新频率跟上客户业务变化；客户侧要在采购前明确平台的能力边界，别指望一个平台解决所有问题。

5.4 私有化部署的集成黑洞

现象：私有化部署后，与既有系统的对接集成工期一拖再拖，百万级预算花出去迟迟上不了线。原因：私有化部署需要与企业原有软硬件对接，集成复杂度被严重低估。解决：部署前把集成清单列全，包括账号体系、数据同步、单点登录，逐项评估工作量。

5.5 把无代码当低代码用

现象：用无代码平台接复杂业务，做到一半发现扩展不出去，推倒重来。原因：无代码平台封装了全部功能，场景覆盖面少，垂直场景精细但天花板低。解决：按业务复杂度选路线，复杂场景用低代码，简单场景用无代码，别指望一条路线通吃。

6. 设计取舍：低代码的天花板到底由什么决定

把整份报告读完，最值得琢磨的不是那些市场数字，而是一个结构性矛盾：低代码用标准化换效率，但企业需求天然是非标的。这个矛盾决定了行业里所有产品设计的取舍方向。

第一个取舍是「开放与易用的平衡点放在哪」。低代码留代码扩展口，灵活但门槛高；无代码封死扩展口，易用但天花板低。报告里低代码快 2 倍、无代码快 8 倍的对比，本质是效率与灵活性的兑换率。厂商真正要回答的问题是：我的目标客户愿意为灵活性付出多少学习成本。

第二个取舍是「标准化产品与定制化交付的边界」。直接面向客户模式下，通用模块加定制实施是主流，但定制越多，交付越重，越偏离低代码「快」的初衷。间接面向客户模式把实施甩给合作伙伴，产品标准化程度能保住，但交付质量不可控。这个边界画在哪里，直接决定了厂商的毛利结构和规模化能力。

第三个取舍是「引擎自研深度与迭代速度的平衡」。六大引擎全部自研，能力强但研发负担重；部分引擎采购或开源拼装，起步快但复杂场景下容易露怯。报告提到研发成本大头在持续迭代而非技术攻关，说明这个行业的竞争不在单点技术突破，而在长期维护能力。

验证一个低代码平台值不值得深入，我的习惯是三步：第一步，拿一条真实业务流程做端到端 PoC，看六个引擎里哪几个真正参与；第二步，查它的集成能力清单，看能不能接进既有系统；第三步，问清楚续费客户的实际使用深度，别只看新签数字。从那以后我每次评估这类平台，都强制走一遍这三步，因为演示环境和生产环境之间的差距，往往就是续费率崩盘的地方。希望帮到你。

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