低代码还是零代码？按团队规模和业务场景选型

J 小助

低代码行业观察 | 用一套决策思路，判断你的团队该用低代码、零代码，还是两者搭配

---

一个常见的误会

「我们要上低代码平台」这句话在需求评审会上很常见，但追问下去，大家说的往往不是一回事：

• 行政主管想要的是「我自己能拖一个请假单出来」；
• IT 负责人想要的是「把重复的增删改查交给工具，人力集中在核心逻辑」；
• 老板想要的是「别再花几十万定制一个系统」。

第一个其实是零代码需求，第二个是低代码需求，第三个两者都有可能。方向选错了，结果通常有两种：业务人员被低代码平台里的数据库、接口、部署这些概念劝退，系统最后还是落回 IT 部门手里排期；或者开发团队被零代码平台的能力天花板卡住，做到一半发现某个关键需求配不出来，只能推倒重来。

这篇文章不罗列功能清单，也不逐款评测平台（平台横评和免费陷阱，同系列另有两篇专门讨论），只回答一个问题：面对一个具体的团队和一个具体的业务需求，怎么判断该用低代码、零代码，还是两者搭配。

文中的落地方案以两款产品为例：面向业务人员的 敲敲云零代码，和面向开发者的 JeecgBoot低代码。选它们不只因为都能免费使用，还因为两者出自同一个团队，定位正好一前一后，适合用来说明「搭配使用」到底怎么搭。

一、先把两类工具的本质差异讲清楚

低代码和零代码经常被放在一起说，宣传口径也越来越像：零代码平台开始提供脚本和接口，低代码平台也在做拖拽和模板。但从选型角度看，它们在四件事上有本质区别。

1. 使用者不同

零代码的目标用户是不写代码的人：行政、人事、销售主管、门店店长、车间班组长。他们熟悉业务，会用 Excel，但不知道什么是主键、什么是事务。零代码平台要做的，是把「建表」包装成「拖字段」，把「写流程」包装成「连节点」。

低代码的目标用户是会写代码但不想重复写代码的人：Java 开发、前端开发、实施工程师、软件服务商。他们需要的是把增删改查、权限、报表这些标准件交给平台，自己把时间花在业务规则和系统集成上。

一个简单的检验办法：系统上线以后，谁来改它？ 如果答案是业务部门自己，那是零代码；如果答案是 IT 团队，那是低代码。

2. 扩展上限不同

零代码平台的能力边界就是平台本身。平台提供 40 种控件，你就只能用这 40 种；流程引擎支持什么节点，你就只能编排这些节点。这不是缺点，而是设计取舍：为了让非技术人员能用，必须把可能性收窄。

低代码平台的上限是开发团队的能力。配置满足不了时，可以回到源码层面写代码。以 JeecgBoot 为例，Online 表单配不出来的逻辑，可以先写 JavaScript、SQL 或 Java 增强；还不够，就用代码生成器把表模型生成成标准的 Spring Boot + Vue3 工程代码，在上面继续开发。官方把这条路径概括为「在线配置 → 代码生成 → 手工合并」。

3. 交付方式不同

零代码交付的是一个应用：在平台里配好的表单、流程、仪表盘和权限。敲敲云还支持把配好的应用导出成模板，对方一键导入。交付物离不开平台，但也不需要任何构建和发布流程，改完即生效。

低代码交付的是一套工程：可以放进 Git、走代码评审、打包部署、交给客户二次开发。这对软件服务商和需要长期维护的核心系统很重要，因为交付物的所有权和可维护性是清楚的。

4. 维护成本不同

零代码的维护成本主要在治理：字段命名、数据归属、权限分配、重复应用清理。技术运维相对轻，敲敲云 v2.4.0 引入了 Flyway 增量升级，私有化部署时替换 jar 或镜像后重启，数据库脚本自动执行。

低代码的维护成本主要在工程：代码要有人维护，版本要有人升级，生成的代码改过之后，再生成时要手工合并。它的好处是可控，代价是需要持续投入开发人力。

把这四点放在一张表里：

对比维度	零代码（以敲敲云为例）	低代码（以 JeecgBoot 为例）
主要使用者	业务人员、部门管理者	开发团队、实施人员、软件服务商
搭建方式	拖拽表单、连接流程节点、配置仪表盘	在线配置 + 代码生成 + 手写代码
扩展上限	平台能力范围内	取决于团队开发能力
交付物	平台内的应用，可导出为模板	标准 Spring Boot + Vue3 工程
源码	代码不开放	开源版采用 Apache-2.0 协议
改需求的速度	业务人员当天改、当天用	需要开发排期、测试、发布
主要维护成本	数据和权限治理	代码维护与版本升级
部署	支持私有化部署，提供一键安装	需要技术人员部署，支持 Docker 一键启动

理解了这四点差异，后面的判断就有了依据：零代码换来的是速度和自主权，低代码换来的是上限和可控性。 选型本质上是在这两组价值之间做取舍。

二、一套可以打分的决策框架

很多团队选型靠感觉，或者看哪家演示做得漂亮。更稳妥的做法是把需求拆成几个维度，逐项打分。下面这套框架包含六个维度，每个维度按 1～3 分打分，分数越高越偏向低代码。

维度	1 分（偏零代码）	2 分（可混合）	3 分（偏低代码）
团队画像	没有开发人员，业务部门自己搭	有少量 IT 人员，能做部署和简单配置	有稳定的 Java / 前端开发团队
业务复杂度	表单 + 审批 + 统计，规则一句话说得清	有一些联动、计算和状态流转	多级计价、复杂状态机、批量计算、强事务
集成需求	基本独立运行，最多推送钉钉、企业微信消息	需要读取少量外部数据或对接单点登录	要读写 ERP、MES、财务库，调用存量系统接口
数据合规	普通办公数据	涉及客户信息，需要私有化部署	涉及生产、财务等核心数据，有审计和信创要求
生命周期	临时或阶段性需求，用几个月	长期使用，但范围基本稳定	核心系统，会持续扩展，几年后规模翻几番
变更频率	需求变得快，业务方希望自己改	偶尔调整	变更需要评审、测试，追求稳定

注意最后一个维度是反向的：需求变化越快、越希望业务方自己改，越适合零代码；变更越需要严格管控，越适合低代码。

怎么用这张表：

• 总分 6～9 分：零代码。业务部门直接动手，IT 部门只负责平台部署和权限规划。
• 总分 10～14 分：混合。前台的填报、审批、看板用零代码，涉及集成和复杂规则的部分交给低代码。
• 总分 15～18 分：低代码。这是需要开发团队持续投入的系统，从一开始就应该放在可控的工程底座上。

打分时有两条「一票否决」的规则，优先级高于总分：

1. 团队画像为 1 分时，不要选纯低代码方案。 没有人能维护代码，再好的低代码平台也会变成摆设。真有复杂需求，要么找外部开发支持，要么先用零代码把能做的部分做起来。
2. 集成需求为 3 分时，不要选纯零代码方案。 零代码平台可以通过接口做一些对接，但要深度读写存量系统的数据库、处理跨系统事务，迟早会碰壁。

这套框架的价值在于让参与讨论的人在同一组维度上对齐，分歧在哪个维度一目了然。

三、按团队规模分档给建议

团队规模不是唯一因素，但它和 IT 能力、系统数量、治理难度高度相关，是一个很好的起点。

10 人以下：零代码优先，别过早上工程

这个规模的团队通常没有专职 IT，老板或某个「懂电脑」的员工兼任管理员。需求集中在几件事上：客户怎么管、订单怎么跟、报销怎么批、库存怎么记。

建议：直接用零代码，从模板开始改。 敲敲云 v2.4.0 内置了人事OA、销售、考勤、进销存、CRM、教育行政办公 6 套标准版应用模板，每套都带完整的表单、流程、仪表盘、角色权限和字典，装好就能用。小团队最怕的不是功能不够，而是「搭了一半没人维护」，从模板改起，第一周就能用上。

这个阶段要避免过早上工程化方案，否则等于凭空多出一个岗位的工作量。

几十人：零代码为主，开始考虑治理

几十人的企业通常有了一两个 IT 人员，部门开始分化，各部门都有自己的表单和流程需求。这时候零代码的价值最大：IT 人员不可能响应所有部门的需求，让部门自己搭是最现实的办法。

建议：零代码为主，IT 负责平台和规范。 具体来说：

• 由 IT 负责私有化部署和账号、组织架构的统一；
• 每个部门指定一名「应用管理员」，负责本部门的应用搭建和维护；
• 公共数据（客户、供应商、物料、员工）只建一份，其他应用通过关联记录引用，不要各建各的；
• 如果公司已经有钉钉或企业微信，把消息通知接上，待办直接推送到常用的办公软件里。

这个规模如果开始出现少量需要对接的需求，比如和财务软件同步数据，可以先评估零代码平台的接口能力，确实不够再引入低代码。

几百人以上：混合架构成为常态

几百人的企业通常有了独立的 IT 部门，已经有 ERP、财务系统，可能还有 MES、WMS。系统之间的数据打通成了核心诉求，同时各业务部门的长尾需求依然很多。

建议：低代码做核心，零代码做长尾。

• IT 团队用 JeecgBoot 这类低代码平台建设和存量系统集成的业务系统。JeecgBoot 内置用户、角色、部门、菜单、数据字典、多租户，数据权限可以细到行级、列级和表单字段级，支持多数据源在线配置，这些都是中大型企业项目绕不开的底座能力；
• 业务部门用敲敲云这类零代码平台消化长尾需求：各种登记、申请、巡检、统计，不再占用开发排期；
• 两边的边界、数据流向和权限由 IT 统一规划（第五节详细讲）。

集团与信创场景：可控性优先

集团企业和有信创要求的单位，选型时的首要问题往往不是「好不好用」，而是「能不能控」：能不能私有化部署、能不能跑在国产数据库上、源码能不能自主掌握、能不能按子公司做多租户隔离。

在这类场景下：

• 核心系统优先低代码。JeecgBoot 开源版采用 Apache-2.0 协议，拿得到完整源码；兼容 MySQL、PostgreSQL、Oracle、SQL Server、MariaDB，以及达梦、人大金仓等国产数据库；单体和微服务（Spring Cloud Alibaba）可以切换；内置 SaaS 多租户架构，适合按子公司或事业部隔离；
• 零代码作为部门级工具。敲敲云支持私有化部署、数据自主可控，适合给各子公司、各部门做轻量应用，但要注意它是「功能免费、代码不开放」，对源码自主有硬性要求的项目要提前确认是否满足；
• 提前做数据库和中间件的适配验证。信创环境的具体版本组合较多，选型阶段就应该在目标环境上跑一遍，而不是上线前才发现兼容问题。

把四档建议汇总一下：

团队规模	IT 能力	推荐方向	敲敲云的角色	JeecgBoot 的角色
10 人以下	无专职 IT	零代码	主力，从模板起步	一般不需要
几十人	一两名 IT	零代码为主	主力，部门自助搭建	个别集成需求时引入
几百人以上	独立 IT 部门	混合	承接长尾需求	承接核心和集成系统
集团 / 信创	有开发团队或服务商	低代码为主	部门级轻量应用	核心系统底座

四、八个典型业务场景逐一判断

团队规模给出的是大方向，落到具体项目，还要看场景本身。下面用「业务复杂度」和「主要使用者」两个维度，对八个常见场景逐一判断。

场景 1：请假、加班、用车审批 —— 零代码

这是零代码最典型的场景。表单字段固定（申请人、类型、起止时间、事由），流程清晰（直属上级审批，超过一定天数加一级），数据量不大。真正的难点不在技术，而在需求变化快：今天加一个「是否涉及出差」，明天改一下审批人规则。

用敲敲云，人事专员可以自己拖表单、配流程。它的流程引擎提供 25 种流程节点，支持任意驳回、委派、跳转，审批人、权限和高级配置可以按节点分别设置；内置的人事OA和考勤模板可以直接作为起点。

用低代码同样做得出来，但每次调整都要开发介入。另外要注意，JeecgBoot 的 BPM 工作流和在线流程设计器属于商业版功能，开源版本身不含，这也是审批类场景更适合交给零代码的一个原因。

场景 2：设备报修与巡检 —— 零代码

某制造企业的设备报修，流程大致是：现场人员用手机提交报修单、拍照，设备科派单，维修人员处理后回填，报修人确认。巡检则是按计划生成任务，巡检员逐项填写。

判断：零代码。理由是这类场景的核心诉求是「移动端能填、流程能转、数据能统计」，敲敲云支持 APP、H5 和钉钉移动端，表单视图有表格、看板、日历几种风格，看板视图正好适合按「待派单 / 维修中 / 待确认」展示工单状态，再配一个仪表盘统计各车间的故障次数和处理时长。

例外情况：如果报修要和设备管理系统、备件库存自动联动，比如维修领用备件后自动扣减库存、自动计算设备的维修成本，就进入了混合区间。

场景 3：CRM 客户管理 —— 零代码起步，视规模演进

CRM 是最容易「选错」的场景，因为它的复杂度跨度很大。销售团队十几个人、管理客户、商机和跟进记录，零代码完全够用，敲敲云的 CRM 和销售模板就是现成起点，平台官方的说法是 5 分钟可以搭出一套 CRM。

但当 CRM 需要和 ERP 打通订单、按复杂规则计算提成、对接呼叫中心、支撑几百名销售同时使用时，它就成了核心系统，适合用低代码重建。

判断：零代码起步，用起来再说。零代码阶段积累的字段设计和流程规则，正好是后续用低代码重建时最有价值的需求文档。

场景 4：进销存 —— 看核算深度

进销存的基本形态是采购入库、销售出库、库存查询，零代码可以胜任，敲敲云内置了进销存模板。

但进销存有一个容易被低估的门槛：成本核算和库存准确性。一旦涉及批次管理、移动加权平均成本、多仓库调拨、负库存控制、高并发出库下的库存锁定，就需要严格的事务控制和计算逻辑，这正是零代码平台不擅长的。

判断：

• 小商户、门店、部门级物资管理，只关心「进了多少、出了多少、还剩多少」：零代码；
• 要出准确的成本报表、要和财务对账：低代码，用 JeecgBoot 的代码生成器生成主子表模块（例如入库单 + 入库明细），再手写库存计算和事务逻辑。

场景 5：生产 MES —— 低代码

MES 涉及工单下达、工序报工、物料追溯、质量检验、设备数据采集，几乎每一项都有行业特有的规则，而且要和 ERP、设备、仓储系统交换数据。数据量大，对性能和稳定性要求高。

判断：低代码。这类系统用零代码搭，前三个月可能很顺利，之后会在性能、集成和复杂规则上不断遇到瓶颈。JeecgBoot 的常见做法是：工厂、产线、工序这类基础数据用 Online 表单直接配出来；工单、报工这类标准业务用代码生成器生成后微调；排程、追溯这些复杂逻辑按常规 Spring Boot 方式手写。

不过，MES 周边往往有一圈适合零代码的需求：班组交接记录、安全检查、5S 巡检、临时的质量问题登记。这些交给车间自己用零代码搭，反而能减轻 MES 项目的范围压力。

场景 6：对接 ERP 的财务系统 —— 混合

以某制造企业的费用报销和付款为例：员工提交报销、多级审批，审批通过后生成凭证写入 ERP，付款结果再回写到报销单上。

这个场景天然分成两段：

• 前段是填报和审批：员工、部门经理、财务专员在用，需求变化频繁（报销标准调整、审批规则变化），适合零代码；
• 后段是凭证生成和 ERP 对接：涉及会计科目映射、金额校验、接口调用和失败重试，必须严格可控，适合低代码。

判断：混合。敲敲云负责报销单和审批流程，JeecgBoot 开发的集成服务负责把审批完成的数据转换成凭证、写入 ERP，并把结果回写。两边通过接口或中间表衔接，具体方式见下一节。

场景 7：数据大屏与经营看板 —— 看数据从哪来

数据大屏的选择，关键不在「做得多炫」，而在数据来源：

• 数据都在零代码应用里（销售跟进、工单处理、考勤统计）：直接用敲敲云的仪表盘。它支持图表、按钮、富文本、轮播图、嵌入 URL 等组件，提供 20 多种统计图表，业务人员自己就能配；
• 数据分散在 ERP、MES、财务等多个系统里：用 JeecgBoot 内置的积木报表（JimuReport）做大屏。它支持拖拽设计报表、打印模板和数据大屏，支持分组、钻取、联动和多数据源，可以把多个系统的数据汇总在一张大屏上；
• 只需要一张按 SQL 统计的报表或图表：JeecgBoot 的 Online 报表和 Online 图表，写一段查询 SQL 就能生成。

判断：业务看板用零代码，跨系统经营大屏用低代码侧的报表工具。

场景 8：AI 知识库问答 —— 看要不要调用业务系统

AI 知识库是近两年新增的高频需求：把制度文件、产品手册、技术文档放进去，员工用自然语言提问。

两款产品都提供了这方面的能力。敲敲云集成了零代码应用、AI 应用平台和 AI 知识库；JeecgBoot 开源版内置一套类似 Dify 的 AI 应用平台，包括模型管理（兼容 DeepSeek、通义千问、OpenAI、Ollama 本地模型等）、RAG 知识库、AI 聊天助手、AI 流程编排和 MCP 插件。

判断的关键在于问答之外还要不要「办事」：

• 只是制度问答、产品知识查询：零代码侧的 AI 知识库足够，业务部门自己维护文档即可；
• 要让 AI 查订单状态、查库存、发起业务操作：需要把业务接口封装成工具让大模型调用，这时 JeecgBoot 的 AI 流程编排和 MCP 插件更合适，接口的权限和数据范围也由开发团队把控。

八个场景汇总

场景	主要使用者	复杂度	推荐	关键判断点
请假 / 加班审批	全员、人事	低	零代码	需求变化快，业务方自己改
设备报修与巡检	一线员工、设备科	低到中	零代码	移动端填报 + 看板派单
CRM	销售团队	低到高	零代码起步	打通 ERP、复杂提成时转低代码
进销存	仓库、采购、销售	中	看核算深度	涉及成本核算和财务对账用低代码
生产 MES	车间、IT	高	低代码	行业规则多、集成多、数据量大
对接 ERP 的财务系统	员工、财务、IT	高	混合	前段审批零代码，后段凭证低代码
数据大屏	管理层	中	看数据来源	单一应用用仪表盘，跨系统用积木报表
AI 知识库问答	全员	中	看是否调业务接口	只问答用零代码侧，要办事用低代码侧

五、混合架构：零代码做前台，低代码做核心

前面多个场景都落到了「混合」上。混合不是两套平台各管各的，而是要有清晰的分工和打通方式，否则很快会变成两个数据孤岛。

分工原则：按「变化速度」和「出错代价」划线

一个实用的划线办法是看两个问题：这部分需求变化得快不快？出错的代价大不大？

• 变化快、出错代价小：放在零代码层，如各类申请、登记、巡检、部门看板；
• 变化慢、出错代价大：放在低代码层，如订单、库存、成本、凭证、生产工单；
• 变化快、出错代价也大：通常要拆开，把「填写和审批」放在零代码层，把「计算和落账」放在低代码层，前面的财务报销就是这种拆法。

数据怎么打通

常见的打通方式有三种，按耦合程度从低到高排列：

1. 接口调用：零代码应用在流程节点上调用低代码系统提供的接口，例如报销审批通过后调用凭证接口。JeecgBoot 提供 Knife4j 在线接口文档和 OpenAPI 鉴权，开发团队可以把需要开放的能力整理成一组受控接口。这种方式边界清楚，推荐优先使用；
2. 中间表或共享数据源：低代码系统定时读取零代码应用的数据，或者两边约定一张中间表交换数据。实现简单，但要约定好字段含义和数据所有权，避免两边同时修改同一条记录；
3. 报表层汇总：两边的数据各自存储，只在报表层合并。积木报表支持多数据源，适合做跨系统的经营看板。这种方式对业务系统零侵入，但只解决「看」的问题，不解决「流转」的问题。

流程怎么衔接

流程衔接的关键是明确每个环节的「主人」。以「采购申请 → 采购订单 → 入库」为例：

• 采购申请和审批在零代码层，主人是申请部门和采购主管；
• 审批通过后，由低代码系统生成采购订单，主人变成采购系统；
• 入库、付款、对账都在低代码层完成，结果状态回写到零代码层的申请单上，申请人能看到进度。

这样每条数据在任何时刻只有一个系统负责修改，另一个系统只读或接收状态通知，可以避免大部分数据不一致的问题。

统一身份和权限

混合架构里最容易被忽略的是人员和组织架构。两套平台各维护一份组织架构，半年后一定对不上。建议以一个系统为准（通常是已有的 HR 系统或钉钉、企业微信的通讯录），其他系统同步，而不是各自手工维护。

一个组合使用的例子

以一家 200 人左右的制造企业为例，比较合理的分工可以是：

1. 行政和人事用敲敲云搭请假、加班、用车、会议室预约，从人事OA和考勤模板改起，自己维护，不占 IT 人力；
2. 销售部门用敲敲云的 CRM 模板管理客户和商机，配一个销售仪表盘；
3. 设备科和车间用敲敲云搭报修、巡检、交接班记录，移动端填报；
4. IT 团队用 JeecgBoot 开发和 ERP、MES 对接的业务系统，比如质量追溯、供应商协同，这部分需要读写已有数据库、写较多业务规则；
5. 经营大屏用积木报表，把 ERP、MES 和零代码应用里的数据汇总展示。

这样业务部门的小需求自己消化，IT 团队专注真正需要开发的部分。两款产品都支持私有化部署，可以放在同一套内网环境里。

六、落地路线：试点、推广、治理

失败的项目大多不是因为平台选错，而是推进方式出了问题。比较稳妥的路线分三个阶段。

阶段一：试点，选一个「小而痛」的场景

试点场景的标准是：范围小、痛点明确、有一个积极的业务负责人。请假审批、设备报修、客户登记都是不错的选择。不要一上来就做 CRM 全流程或 MES。

试点阶段要回答三个问题：

• 业务人员能不能独立完成搭建和调整？如果每一步都要 IT 手把手教，说明零代码平台或者人选不合适；
• 用户愿不愿意用？手机端体验、消息通知是否到位，往往比功能多少更影响使用率；
• 平台的部署、升级、备份是否顺畅？试点期间至少完整走一次升级流程。

如果是低代码试点，建议选一个「有一定复杂度但不是最核心」的模块，让开发团队完整走一遍「在线配置 → 代码生成 → 手工合并」，评估团队对生成代码的掌握程度。

阶段二：推广，复制方法而不是复制应用

试点成功后，推广的重点是复制方法：

• 整理一份内部搭建规范：字段命名、表单分组、流程节点命名、权限角色划分；
• 培养各部门的应用管理员，让他们成为本部门的「第一响应人」；
• 把公共数据（员工、部门、客户、供应商、物料）先建好，作为其他应用的引用源；
• 把做得好的应用导出成模板，在其他部门复用。

低代码这边，推广的重点是沉淀公共组件和接口：统一的权限模型、统一的字典、统一的接口规范，让后续每个新模块都站在前一个模块的肩膀上。

阶段三：治理，防止「应用泛滥」

零代码平台用到一定规模，一定会遇到治理问题：重复的应用、没人维护的「僵尸表单」、权限给得过宽、关键数据散落在个人建的应用里。

治理要做的事情包括：

• 定期盘点：每季度清理一次长期无人使用的应用；
• 分级管理：涉及客户、财务、人事敏感数据的应用，要由 IT 审核权限配置后才能上线；
• 数据归属：明确每一类核心数据的「主数据系统」，其他应用只能引用不能另建；
• 升级节奏：私有化部署的平台要有固定的升级窗口，敲敲云这类支持数据库自动升级的平台降低了升级难度，但仍然建议先在测试环境验证；
• 边界评审：当某个零代码应用的复杂度明显上升（大量公式、频繁对接、数据量激增），评估是否应迁移到低代码层。

常见误区

误区一：把演示当成能力。 拿自己的一个真实流程、用真实数据搭一遍，才知道顺不顺手。

误区二：零代码不需要管理员。 即使不写代码，也需要有人统一规划字段命名、权限和数据归属，否则半年后会出现十几个重复的「客户表」。

误区三：低代码等于不用懂技术。 JeecgBoot 生成的是标准工程，团队至少要能看懂 Spring Boot 和 Vue 代码；部署、升级和复杂扩展都需要技术人员参与。

误区四：一个平台解决所有问题。 用零代码硬撑核心系统，或者用低代码去做每一张申请单，都会付出不必要的成本。混合才是中大型企业的常态。

误区五：只算采购成本，不算迁移成本。 一个平台用了两年再更换，迁移数据和重建应用的成本远高于当初的采购成本。选型时就要想清楚「零代码不够用了怎么办」。敲敲云和 JeecgBoot 出自同一个团队，业务部门先用零代码跑起来、遇到复杂需求再由开发团队用 JeecgBoot 承接，是一条比较顺的路径。至于免费版本身有哪些限制、哪些「免费」其实有附加条件，同系列的避坑清单有专门梳理。

---

总结

低代码和零代码不是二选一，而是给不同的人解决不同的问题。回到开头的三个问题：

• 谁来搭：业务人员自己搭、自己改，用零代码；开发团队负责、需要源码，用低代码；
• 搭什么：审批、登记、巡检、部门看板用零代码；集成、复杂规则、核心系统用低代码；跨两边的流程拆开做，前段零代码、后段低代码；
• 怎么演进：按团队规模从零代码起步，随着 IT 能力和系统数量增长逐步走向混合架构，并且从第一天起就做好数据归属和权限治理。

选型时可以直接套用文中的六维打分表：6～9 分零代码，10～14 分混合，15～18 分低代码，再用「没有开发不选纯低代码、深度集成不选纯零代码」两条规则兜底。

落地方案上，敲敲云零代码让业务部门自己动手，内置模板可以直接起步；JeecgBoot低代码让开发团队在可控的工程底座上提效。两者都可以免费使用、支持私有化部署，搭配使用基本能覆盖企业内部系统的大部分需求。