企业官网建设流程全解析

简介：《2022年中国低代码无代码平台行业研究报告》为头豹研究院出品的行业研究PDF，面向企业数字化负责人、低代码/无代码产品经理、投资研究人员及关注aPaaS赛道的从业者，用于系统了解行业边界、厂商格局与商业化路径。报告围绕低代码与无代码的定义分类、发展历程、平台架构展开，重点拆解直接面向客户、间接面向客户、前后端开发平台、生态型平台四类商业模式，并比较公有云与私有化部署在收费、响应、维护和周期上的差异，同时讨论研发与服务成本上升、续费率偏低及厂商盈利分化等现实问题。资源包共1个PDF文件，大小约3.43MB，单份报告便于检索与归档。已有111人学习，适合用作市场扫描、方案论证和投融资研究的参考资料。

1. 低代码的本质不是“少写代码”：交付权为什么被挪到了业务侧

大多数人把低代码、无代码平台理解成“给程序员省打字时间”的工具，这个理解是反的。它真正省掉的，是需求从业务方嘴里说出来、到变成一套能跑的企业数字化应用之间那段漫长的往返：提需求、排期、报价、开发、测试、上线，一圈下来以月计。低代码无代码平台做的事，是把这条链路上“翻译”和“排队”两段砍掉，让离业务最近的人直接产出应用。

所以值得搞懂的不是拖拽界面有多花哨，而是一个更硬的问题：一份不含任何可执行代码的元数据描述，凭什么在运行时能变成一套带权限、带流程、带报表、能对接老系统的应用？这背后是模型驱动架构、引擎分层和元数据契约三件事。这份行业研究报告里最容易被图表盖过去的，恰恰是这一层机制。

2. 平台层的六大引擎：一份元数据凭什么变成可运行的应用

2.1 三层切分：基础层、平台层、应用层各自兜住了什么

各家产品的功能清单差别很大，但架构自下而上基本都落在三层：基础层、平台层、应用层，低代码/无代码技术真正发生的位置只有平台层。基础层是物理机、公有云主机、基于容器编排的云原生平台、各类操作系统（含国产系统）和主流关系型数据库（含国产库）；平台层是构建应用的各种引擎；应用层是产出物，PC 端、移动端、大屏、嵌入协同办公软件里的页面，以及 ERP、CRM、OA、MES、物流管理、设备运维、客服工单这些业务系统。

我一般会这么理解这次切分的动机：三层各自承担一种不确定性。基础层的不确定性是资源和运维，平台层的不确定性是逻辑和表达，应用层的不确定性是需求和变更。低代码平台干的事情，是用云原生把基础层的不确定性吃掉——用户不用准备服务器、中间件这些 IT 基础设施；再用可视化把应用层的不确定性吃掉。剩下的平台层，才是厂商真正的护城河，也是选型时唯一值得逐条拆开看的部分。

这里有个常被忽略的推论：基础层被吃掉得越彻底，平台层的能力边界就越重要。因为用户已经不再拥有“实在不行自己写一套”的退路，一旦引擎表达不了某个需求，付出的代价不是多写几行代码，而是整个方案推倒重来。

2.2 六个引擎对应六种变化频率：拆分依据不是功能，是改动半径

以某低代码平台的实现为例，平台层被拆成六个引擎。它们的职责和“改错了会怎样”差别极大：

数据模型引擎内建小型数据库，也能直连主流数据库，提供可视化的数据模型与查询视图设计；业务逻辑引擎提供可视化编排和调试，逻辑可以跑在服务器，也可以跑在页面，实现前后端分离；工作流引擎支持自由定制流程中每个节点的规则和关联业务处理；页面渲染引擎集成开箱即用的 UI 组件和样式，支持固定布局与响应式布局；智能报表引擎做统计报表、复杂报表和类文档报告；系统集成引擎兜住数据库直连、接口构建调用、用户认证与权限同步。

这六个引擎的拆分依据不是“功能相似”，而是“改动半径”。页面改错，顶多难看；数据模型改错，历史数据全废。把改动半径差一个数量级的东西塞进同一个可视化画布，结果就是高频变更被迫去触碰低频资产——这是很多低代码项目上线半年后失控的真正根因，而不是“平台功能不够多”。

顺着这个逻辑，前后端分离在可视化体系里同样是硬约束。页面端逻辑跟着浏览器跑，对用户完全可见可改，只能放展示和交互；服务端逻辑跑在服务器上，才放校验、事务和权限。低代码平台如果允许把校验规则顺手拖到页面端，等于把安全边界交给了一次拖拽操作，这类坑在后面的排查章节还会出现。

2.3 解释执行还是代码生成：模型驱动的两条实现路线

元数据到底长什么样？一个“设备报修”应用的核心描述大致是这样：

{ "form": "equipment_repair", "version": 3, "fields": [ {"key": "asset_no", "type": "text", "required": true, "unique": true}, {"key": "fault_type", "type": "enum", "options": ["电气", "机械", "软件"], "required": true}, {"key": "level", "type": "enum", "options": ["一般", "紧急"], "default": "一般", "rule": "fault_type != null"}, {"key": "reporter", "type": "user", "default": "currentUser"}, {"key": "photos", "type": "attachment", "max": 6} ], "workflow": { "nodes": ["提交", "班组长审核", "派单", "维修", "验收"], "rules": {"班组长审核": "level == '紧急' ? 抄送设备主管 : 跳过"} }, "permissions": { "reporter": ["create", "read_own"], "technician": ["read_assigned", "update_status"] } }

这份描述里没有一个字符是可执行代码，但它同时喂给了四个引擎：数据模型引擎据此建表或映射到已有库，页面渲染引擎据此画出表单并挂上字段级联动（rule字段），工作流引擎据此生成节点和条件路由（workflow.rules里的三元表达式决定紧急单是否抄送主管），系统集成引擎据此生成读写接口并按permissions做行级过滤。这就是“元数据是唯一事实来源”的实际含义——同一份真相被多个引擎各读各的，任何一方都不允许私藏状态，否则改配置就会出现“页面改了、接口没改”的鬼故事。

version这个字段最容易被忽略，也最要命。它是 schema 版本，决定了平台升级时旧应用还能不能被正确解释，后面第 5 章会专门讲它翻车的场景。

元数据怎么变成运行中的应用，行业里有两条路线，取舍相当明确。第一条是运行时解释：元数据存在库里，用户打开页面时引擎读取描述再渲染，改配置立即生效，多租户共用一套引擎，代价是复杂逻辑受限于引擎的表达能力，且有一定的解释开销，深度定制只能靠插件或脚本钩子。第二条是代码生成：把元数据编译成一份普通工程源码，之后脱离平台走常规研发，好处是没有平台锁定、可以任意改，坏处是配置和生成物会逐渐脱节，重新生成会覆盖手改代码，形成二次开发里的烂摊子。

现实中多数产品是混合的：常规表单和流程解释执行，复杂报表和集成接口走代码生成或脚本。这个混合比例决定了你的“后悔药”有多少——选型时该问清楚的一件事是，如果三年后要迁出这个平台，能导出一份可读的模型描述和源码吗？导不出，这套东西就是黑匣子。

3. 商业模式与成本结构：这个赛道为什么会出现“卖得越多亏得越多”

3.1 四种商业模式，差别在于“谁承担实施”

低代码厂商的商业模式是向企业客户提供平台产品和服务，通过按年付费实现营收，并追求一个良好的续费率。具体分四类，表面看是售卖方式的区别，实际上是同一个问题的四种回答——实施这件事谁来干。

直接面向客户是当下的主流：厂商直接交付产品，通用模块满足不了场景需求时，再叠一层定制化开发，用“产品 + 项目实施”把客户接住。间接模式则把定制需求交给第三方伙伴，厂商只收产品费，规模化更快，但对交付质量基本失控。前后端开发平台模式干脆不碰业务，面向软件开发商卖前端或后端所需的能力，用云原生、微服务、DevOps 这些理念帮对方减少开发人员的编码量。生态型平台最激进：厂商不直接卖产品给终端客户，而是赚授权费，把专业开发者、软件商、服务商聚到平台上，制定开发标准和交易规则，让下游自己玩。

关键在最后一行。低代码降低的是编码成本，但没有消除需求梳理、数据整理、流程配置、权限设计和培训这些实施工作。直接模式把这些活自己扛了，毛利被服务吃掉，换来客户体验可控；间接模式把活外包出去，规模上得快，代价是客户对面站着的是伙伴而不是厂商；生态模式卖的是规则，赌的是网络效应，对产品能力和生态建设能力的要求都极高，行业里普遍还处在早期阶段。

3.2 研发三成、服务四成：成本结构决定了它不是纯软件生意

低代码平台产品的成本主要是两块：研发成本和服务售后成本。一份行业调研给出的团队占比很反直觉——研发人员占 30% 到 40%，服务人员占 40% 到 50%。一家号称降低开发门槛的软件公司，超过四成的人力在做服务，这个数字本身就说明了这个赛道的性质。

更反直觉的是研发成本的来源。报告明确指出，研发成本并非源于较高的技术研发难度，而是源于产品日常的更新和迭代。随着客户数量增加和业务场景拓宽，客户对场景覆盖度的要求同步抬升，研发团队必须保持一定频率的版本更新和功能改动，才能接住需求。更新跟不上业务变化，续费率就守不住。

服务成本则花在两件事上：给企业管理员的培训，以及协助企业搭建应用。注意这两件事都不是“教会你用工具”，而是“替你把业务流程先想清楚”。

把这两块合起来看，结论很清楚：这是一个“产品在追赶客户”的生意。收入随客户数线性增长，而需要覆盖的场景宽度随客户数组合式扩张，成本曲线比收入曲线更陡。卖得越多，要改的越多，要教的人也越多——这就是“卖得越多亏得越多”说法的由来，它不是诅咒，而是成本结构的必然推论。

3.3 续费率的数学：低于这条线，增长就是负现金流

我一般会用一个很粗的模型来估这件事。设单个客户年费 P，每年为它付出的服务成本 S，获客成本 C，年续费率 r。那么这个客户的终生净贡献约等于：

LTV ≈ (P - S) × r / (1 - r) - C

r / (1 - r)这一项就是放大器。r = 50% 时乘数是 1，r = 70% 时是 2.33，r = 85% 时是 5.67。也就是说，续费率从 50% 提到 70%，单个客户价值翻一倍多；从 70% 提到 85%，再翻一倍多。而服务成本 S 是当期支出，续费率 r 是乘数——这就解释了为什么厂商宁可加大服务投入也要保续费，因为服务是花一次钱买一个乘数。

反过来，如果客户第一年就因为“业务场景不匹配、自己搭不顺利”不再续费，那么 C 全部打水漂，(P - S) 只收到一年，模型立刻转负。这也对上了行业现状：研发和服务售后成本持续增长，而外部环境使得中小企业采购预算下滑、新客增量近两年逐渐减少，同时客户使用体验不佳导致续费率低下，高成本加低营收，多数厂商仍在亏损，只有少数头部实现轻微盈利。

投融资数据侧面印证了这一点。低代码赛道的投融资事件数近几年整体上行，2021 年国内事件数同比增长 266.7%，但轮次结构几乎没有变化——A 轮及以前占比从 2017 年的 66.7% 到 2022 年的 71.4%，只挪了几个点。这说明大量厂商还在早期投入阶段，尚未走完“产品能力—客户续费”这个闭环。热度是外部环境推动的，闭环是自己走出来的。

4. 部署方式与产业链位置：公有云和私有化分流的真实原因

4.1 四个维度拆开看：收费、响应、维护、周期

低代码平台的部署方式分公有云部署和私有化部署，两种方式在收费方式、需求响应、维护方法、部署周期上都有差异，而这些差异其实是同一件事的四种表现——控制权在谁手里。

值得注意的是，目前大多数成功交付的产品是公有云形态，价格在几千元人民币一年；私有化则要百万级，费用包含平台打包安装和按年更新。企业希望用公有云快速开发应用来拓展业务，低成本和短部署周期是它跑得更快的直接原因。

真正的决策变量不是“安全不安全”这种笼统判断，而是你的业务变更频率和厂商的版本节奏是否同频。业务变化快、需要深度定制，公有云的固定模块就会变成硬约束；业务稳定、只是要把散落的表格收进系统，公有云的固定模块反而省心。偏好私有化部署的，通常是数据安全要求高、希望平台运行稳定可靠、内部还有其他系统要对接集成、业务场景复杂、并且自有服务器和技术人员的企业，集中在金融和电信领域——注意这几个条件里，“有技术人员”和“有系统要对接”是并列的，缺一个，私有化就会变成自己给自己挖坑。

4.2 厂商三分类：独立、生态、互联网/云，各自的产品动机不同

从微观上看，低代码/无代码厂商可以分为独立厂商、生态厂商和互联网/云厂商。独立厂商也称原生厂商，自创立之初就专注低代码平台的研发与销售；生态厂商多是传统企业管理软件厂商，主营业务原本是 ERP、CRM、OA，在发展过程中把产品线拓展到低代码，用来完善自己的产品生态；互联网/云厂商推出低代码平台，主要是为协同办公产品做功能补充。

分这个类的价值不在贴标签，而在于产品动机决定了它会在哪个方向持续投入。独立厂商要靠产品本身活着，所以功能覆盖、模板库、垂直场景的精细度往往做得更深；生态厂商的低代码是自家管理软件的“外挂”，天然偏向与自家产品集成，跨系统能力偏弱；互联网/云厂商的低代码是协同办公的入口，强在账号体系、组织架构、审批流打通，弱在复杂业务建模。选型时先判断对面属于哪一类，比逐条比对功能清单有效得多——因为功能可以补，动机不会变。

按宏观再分一层，低代码厂商和无代码厂商的分野也值得说清，它不是营销话术，而是表达能力的上限差异：

机制上的差别是开放与封闭。低代码平台的界面可以用 HTML 这类语言去写，数据库处理可以用 SQL 深度加工，容器功能多但做得不那么精细，用户需要用少量代码把产品改到想要的形态，所以它适合有编程能力的人；无代码平台把基础功能封装死，用户只能调用已经做好的能力，包括字段设定和数据处理，场景覆盖面窄，但垂直场景做得精细，即拿即用。这条边界决定了后面所有的踩坑类型：你拿封闭的引擎去表达开放的需求，卡住是迟早的事。

4.3 制造业占三成，但大厂和小厂用它的理由完全相反

行业应用场景的分布是：制造业占比最高，达 30%，零售业 20%，服务业 15%，国企、建筑、教育合计约 5%，其余约 30% 分散在其他行业。制造业排第一这件事本身有点反常——制造生产过程中存在大量非标环节，从某种程度上并不适合标准化控件式的低代码开发。

答案藏在企业规模里。对中小微制造业来说，采购传统 ERP 的费用极高，难以承受；同时传统 ERP 流程过于固化，找 ERP 厂商改功能的报价也高。所以它们采购和续费低代码产品的关键点只有一个：高性价比。先用便宜的方式把非标流程跑起来，比追求功能完备重要得多。

大型制造业则是另一套逻辑。它们的 ERP 系统功能已经相当完善，不需要用低代码做复杂应用开发；真正的需求出现在 ERP 需要改进的时候——通过接口把低代码搭出来的应用和原有 ERP 连起来，作为功能补充。同一个行业，小客户买低代码是为了替代，大客户买低代码是为了打补丁。

这两类客户对产品的要求几乎相反：替代要功能全、模板多、上手快；补丁要集成强、接口稳、权限能对齐。一套产品同时打这两拨人，续费率一定会分化——这不是运营问题，是产品定位问题。报告里把制造业、零售、服务、建筑、教育等场景的典型应用列得很细，从生产报工跟踪、协同型供应商管理，到工程进度、物资、资金管理，再到教师考勤、宿舍管理、公物报修，做选型评审时按行业对照一遍，比听销售讲案例有用。

5. 常见翻车现场排查：五条从现象倒推到根因的记录

5.1 搭建期：表达力被封装吃掉

第一条，用无代码平台硬扛复杂流程，搭到第三层分支就卡死。现象是表单和审批都配好了，走到“根据金额和客户等级走不同审批链”这一步，发现条件表达式只支持单层判断，只能拆成多个流程加人工分流，维护成本翻倍。原因在于无代码平台把功能封装死，用户只能调用已经做好的能力，表达力上限就是封装那一刻的预设。解决办法是在立项前做复杂度分级，把需求按分支层级、跨系统数、计算复杂度打分，超过阈值就换低代码平台用 SQL 或脚本补位，或者干脆走传统开发。

第二条，把校验逻辑放在页面端。现象是界面上必填和格式都拦住了，但绕过页面直接调接口，脏数据照样写进库。原因是可视化设计器里“页面逻辑”和“服务端逻辑”常常画在同一块画布上，拖错位置没有任何提示，而页面端逻辑跑在浏览器里，对用户完全可见可改。解决办法只有一条：所有写操作在服务端再校验一遍，并把“这条规则归页面还是归服务端”写进搭建规范，而不是靠个人经验。

第三条，把业务人员默认当成开发者。现象是平台买了、账号开了，三个月后使用率不到 10%，业务方一句“不会用”把项目冻结。原因是低代码降低的是编码门槛，不是需求梳理门槛——使用低代码的业务人员大多不具备梳理流程和数据的能力，他们的精力放在业务目标上，而“轻度咨询”这段需求正好落在厂商和客户之间的真空里。解决办法是设一个“公民开发者”角色，配一名既懂业务又懂数据的骨干，IT 负责模型和权限把关，上线前先陪跑两三个真实流程。

5.2 采购与续费期：集成与价值证明的坑

第四条，公有云上线后才发现接不进内网。现象是应用搭得很顺，但一要和内部系统对账，数据只能导出表格手工搬。原因是公有云即买即用的代价，就是该模式下无法与企业内网直接对接，而集成能力往往不在试用期的验证清单里。解决办法是在选型阶段先列一张集成清单：要连哪些系统、走接口还是数据库直连、要不要单点登录和权限同步，逐条让厂商现场演示，演示不了的直接划掉。

第五条，第二年续费评审拿不出价值证明。现象是预算会上 IT 说“用的人挺多”，财务问省了多少工时，答不上来，预算被砍。原因是低代码的价值分散在几十个小应用上，单个都不大，不做量化就完全看不见，而续费率恰恰是这门生意里最重要的乘数。解决办法是上线即埋点，统计应用数、月活、单据量、平均处理时长，按“替代的人工工时乘人力成本”折算，续费前出一页纸的账。这件事的投入产出比高得离谱，但真正做的团队少之又少。

6. 标准化与个性化的边界：低代码的天花板到底画在哪

行业趋势讲得很清楚：低代码会加速与 AI、RPA、数据分析、IoT 融合，会走向聚合平台，汇聚低代码厂商、传统软件厂商、服务商和渠道商共同服务用户，跨品牌的低代码组件会一起拓展应用边界。这些方向都成立，但我认为它们改变的东西比想象中有限。

拿融合来说。AI 和 RPA 结合，能让流程自动化对非结构化数据的识别和处理更进一步；低代码和 RPA 结合，能大幅降低流程自动化的搭建难度。但拆开看，AI 改善的是输入端——票据识别、文本抽取、字段自动填充；RPA 改善的是输出端——让低代码搭的流程能去操作那些根本没有接口的老系统。两端都变强了，中间平台层的表达上限并没有被抬高。引擎表达不了的分支，接十个 AI 也表达不了。聚合平台同理，它的难点不在技术，而在组件契约和结算规则：跨品牌组件要能互相调用，前提是大家对“一个字段是什么、一个流程节点怎么描述”有共同定义，这是标准问题，不是能力问题。

所以低代码真正的天花板，是标准化控件与个性化需求之间那条线画在哪。厂商把线往个性化推，产品变重、服务成本上升、交付周期变长；往标准化推，场景匹配度下降、续费率下降、获客成本收不回来。前面几章里所有的矛盾——四种商业模式的选择、公有云与私有化的分流、制造业大客户和小客户诉求相反——说到底都是这条线在不同位置的投影。理解了这一点，看任何一家厂商的产品路线图，都能大致判断它下一步会牺牲什么。

落到可操作层面，我给一个自己常用的复杂度分级，用来判断一个需求到底该不该上低代码：

这张表不适合当标准答案，但它能挡住大部分“先上了再说”的决策。这份行业研究报告的价值也在这里：它把四种商业模式、两种部署方式、三类厂商、行业场景占比和成本结构放在同一套框架里对照，选型评审时把部署对比和成本结构那两页拆出来当检查表，比翻十份厂商白皮书省事得多。

说个教训。早些年我参与过一次平台选型，功能演示很漂亮，试用期两周搭了七八个表单，全票通过。半年后要迁一个应用出去，才发现模型导不出来，只能按页面截图手工重建。从那以后我每次参与低代码选型评审，都强制先让业务方把三个最疼的真实流程画出来，让厂商现场搭一遍，最后再补一句“三年后我要迁走，你能导出什么”。希望帮到你。

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