低代码平台的评估指标：从「上层建筑 / 基座」两层看
一、先把评估范围收窄
「低代码」是一个宽泛到近乎失效的词。它可以指：
- 表单引擎
- 流程引擎
- 报表 / BI 工具
- 页面搭建器
- 甚至 Excel 宏、RPA 脚本
范围不收窄，就没法评估。 本文只聚焦一件事：
面向应用系统的开发。 也就是用低代码的方式，把一套企业业务系统（有表单、有流程、有数据、有权限）搭出来。
按这个范围，评估的对象不是「哪个平台功能多」，而是这套平台能不能撑起一个真实应用系统的全生命周期。
二、两层结构：上层建筑与基座
评估之前，先建立一张结构图。一个应用系统在低代码平台上，可以被拆成两层：
两层之间是单向依赖，可以这样理解：
- 基座先立------菜单、模块、权限、组织结构决定「谁来用、看得见什么、能做什么」；
- 上层建筑后盖------流程、表单、报表、大屏在基座之上承载业务形态；
- 方向不可逆------上层做得再漂亮，也补不上基座的缺口。
这个两层划分，本身就是第一个评估判断：
| 层 | 包含 | 回答的问题 |
|---|---|---|
| 上层建筑 | 流程、表单、报表、大屏 | 业务长什么样 |
| 基座 | 菜单、模块、权限、组织结构 | 谁来用、看得见什么、能做什么 |
关键判断：基座比上层建筑更能区分平台。
原因很简单------流程、表单、报表、大屏，任何一家低代码都能做出来，做得好坏是程度问题；而菜单、模块、权限、组织结构这四样，是决定一个平台能否承接真实企业应用的骨架。骨架不对，上层建筑盖不高。
下面分两层展开评估指标。
第一部分：上层建筑的四项指标
三、流程：看「执行模型」而不只看「能画图」
流程是最容易被演示骗过去的一块。画一个请假流程图，十家产品有九家都能画得漂亮。
评估要点不是能不能画，而是引擎允许多复杂的执行模型。
参考指标：
| 指标 | 说明 |
|---|---|
| 节点执行方式 | 是否支持人工、机器、混合、流水线、过程等多种执行者 |
| 事件体系 | 发送前/后、退回、撤销、移交、流程结束等生命周期点是否可挂业务 |
| 参数机制 | 外部数据能否注入并参与方向判断与接收人计算 |
| 退回能力 | 能否退回到任意结点、能否撤销退回 |
| 会签/加签 | 多人协作的模型是否完整 |
以驰骋为例，节点执行方式是一个可枚举的属性 （0=操作员执行 @1=机器执行 @2=混合执行 @3=流水线执行 @4=过程执行），意味着流程引擎不是只服务审批，也能服务产线。这类设计在演示里看不出来，但决定了流程能不能承接非审批类业务。
四、表单：看「数据模型」而不只看「拖控件」
表单设计器最容易被比较的是「控件多不多、拖拽顺不顺」。这是必要不充分的指标。
更关键的是：表单背后的数据模型，是不是独立存在、能不能被复用。
参考指标：
| 指标 | 说明 |
|---|---|
| 数据模型独立性 | 表单字段是否对应真实表结构，而非仅存于设计器 JSON |
| 主子表支持 | 能否处理一对多（如订单 + 明细） |
| 复杂控件 | 是否支持表格、附件、签字、富文本等业务级控件 |
| 数据源绑定 | 下拉、字典等能否绑定外部数据源 |
| 与流程解耦 | 同一个表单能否被多个流程、多个菜单复用 |
判断标准：如果一个平台的表单只能「依附于流程节点存在」，那它是流程的一部分，不是独立能力。这会影响后面所有复用场景。
五、报表：看「数据来源」而不只看「图表多」
报表的评估陷阱是比图表数量。柱状、折线、饼图，前端图表库（如 ECharts）本身就提供几十种，这不是平台能力。
报表能力的真实分水岭，在于「数据从哪来、能不能自助配」。
参考指标：
| 指标 | 说明 |
|---|---|
| 数据源接入 | 能否连多种数据库 / 数据源 |
| 查询定义方式 | SQL、可视化、还是只能选内置表 |
| 参数化 | 能否按组织、时间、业务参数过滤 |
| 权限继承 | 报表数据是否受使用者权限约束（这点极重要） |
| 与业务系统同源 | 报表读的是业务流程数据，还是需要单独同步 |
以驰骋为例，报表走的是 GenerDBSrc（数据源）体系，报表本身是配置出来的，可以指向 SQL、存储过程、WebApi 等。这意味着报表不是独立模块，而是复用整套数据源与权限体系。
六、大屏：看「是不是同一套数据源」
大屏是近年被单独包装成产品的功能。评估时要小心：很多「大屏工具」是独立的，跟业务系统两套数据、两套权限。
参考指标：
| 指标 | 说明 |
|---|---|
| 是否与报表同源 | 大屏和报表是不是同一套设计器 / 数据源 |
| 图表覆盖面 | 是否支持常见 + 特殊图表（漏斗、桑基、热力、词云等） |
| 交互与联动 | 是否支持下钻、联动、轮播 |
| 自适应 | 能否适配不同分辨率的大屏 |
| 与权限打通 | 不同角色看到的大屏内容能否不同 |
驰骋的 RptBlue（蓝色大屏）是一个可视化设计器，从代码看它支持线 / 面积 / 柱 / 条形 / 饼 / 环 / 玫瑰 / 雷达 / 散点 / 仪表盘 / 桑基 / 矩形树图 / 旭日图 / 漏斗 / 热力 / 词云 等十余种图表，另有排行列表、轮播表格、分页表格等列表类组件；且内置了「AI 创建大屏」（可按提示词、流程、单据、实体生成）。更重要的是它与报表共用同一套组件与数据源体系，而不是另起炉灶。
第二部分：基座的四项指标
这一部分才是评估的重心。
七、菜单：看「菜单是不是有类型的」
最朴素的设计是「菜单 = URL + 标题」。这个设计在功能少时没问题，一上规模就崩。
评估指标：菜单是否有类型（分类）。
参考指标：
| 指标 | 说明 |
|---|---|
| 是否区分菜单类型 | 不同功能页面是不是「同一种菜单」 |
| 类型到渲染的映射 | 类型是否决定用哪个页面组件渲染 |
| 承载方式 | 不同复杂度功能能否用不同方式承载 |
| 多语言 / 图标 / 排序 | 基础但必需 |
驰骋的 MenuModel 把菜单分成一系列类型常量------菜单不是「一个 URL」，而是「一个有语义的类型」 ，类型决定解析页面（GPN_Menu 的 ClassFactory 映射表）。这一点直接决定了平台能不能把「表单页 / 流程页 / 报表页 / 大屏页 / 自定义页」统一纳管。
八、模块：看「有没有中间层」
「系统 → 菜单」两级，也能用。但少了模块这一层，会有两个问题：
- 权限颗粒度不够------只能做到「能不能进这个系统」，做不到「进了系统能看哪块」；
- 菜单堆积------几十上百个菜单平铺，无法组织。
评估指标：是否有模块作为系统与菜单之间的中间层。
参考指标：
| 指标 | 说明 |
|---|---|
| 是否有模块实体 | 系统之下、菜单之上是否还有一层 |
| 模块归属 | 一个模块能否被多个系统引用 |
| 模块级权限 | 能否按模块授权 |
| 模块内排序 | 模块内菜单能否自定义顺序 |
九、权限：看「颗粒度是不是分层的」
权限是低代码平台的试金石。「谁能进这个系统」是入门题，「谁能看哪个菜单、点哪个按钮」才是真问题。
参考指标：
| 指标 | 说明 |
|---|---|
| 授权对象分层 | 能否按系统 / 模块 / 菜单分别授权 |
| 授权主体 | 能否按人、部门、岗位、角色授权 |
| 岗位维度 | 是否区分「岗位」（有些产品只有角色） |
| 数据权限 | 能否约束到数据行（而不仅功能点） |
| 权限与菜单联动 | 无权限的菜单是否自动隐藏 |
用「院子 / 房子 / 家具」来理解这个分层：
| 层 | 比喻 | 控制什么 |
|---|---|---|
| 系统 | 院子 | 谁能进这个院子 |
| 模块 | 房子 | 进了院子的人，谁能进这间房 |
| 菜单 | 家具 | 进了房子的人，谁能用这件家具 |
驰骋的 GPM_PowerCenter 用 CtrlObj 区分授权对象（System / Module / Menu），授权主体则落到 PCenter 系列（部门 PCenterDept、人员 PCenterEmp、岗位 PCenterStation、组织 SpecOrg）。「授权对象 × 授权主体」构成一个二维矩阵------这张矩阵铺得开不开，直接决定平台能承接多复杂的组织。
十、组织结构：看「组织模型能不能表达真实企业」
组织结构看起来是最基础的，其实是最容易被低估的一块。因为大多数产品只支持一种组织模型：树形部门。
但真实企业不是只有一种：
- 集团 --- 子公司 --- 部门（树形）
- 项目组、虚拟团队（跨部门）
- 大队 --- 中队 --- 小队（编制）
- 兼岗、多岗（一人多岗）
评估指标：组织模型是否可配置、能否表达多种组织形态。
参考指标：
| 指标 | 说明 |
|---|---|
| 组织类型 | 是否支持多种组织类型（部门、岗位、组织、编制...） |
| 层级深度 | 能否支持深层级 |
| 一人多岗 | 一个人能否挂多个岗位 / 部门 |
| 与权限联动 | 组织变动后权限能否自动跟随 |
| 与流程联动 | 接收人规则能否按组织计算 |
驰骋在这块有专门的设计（见 doc\组织结构\ 系列）：组织模型按「三态组织类型」划分，PCenterSpecOrg、PCenterStation 等实体支撑岗位与组织维度。组织结构是权限和流程接收人的共同地基------它错了，上面两层都跟着错。
十一、一张完整的评估表
把两层八项收成一张表，可以直接拿去核对：
| 层 | 指标 | 核心问题 |
|---|---|---|
| 上层建筑 | 流程 | 引擎支持多复杂的执行模型？ |
| 上层建筑 | 表单 | 数据模型是否独立、可复用？ |
| 上层建筑 | 报表 | 数据源能否自助配置、是否受权限约束？ |
| 上层建筑 | 大屏 | 是否与报表同源，而非另起一套？ |
| 基座 | 菜单 | 菜单是否有类型、类型是否决定渲染？ |
| 基座 | 模块 | 系统与菜单之间是否有中间层？ |
| 基座 | 权限 | 授权是否分层（系统/模块/菜单 × 人/部门/岗位）？ |
| 基座 | 组织结构 | 能否表达多种组织形态，并与权限/流程联动？ |
一个简单的权重判断
如果只能问三个问题，建议问这三个：
- 权限能不能分层？（系统/模块/菜单三级 + 数据权限）
- 组织结构能不能改？（支不支持岗位、多组织形态）
- 报表和大屏是不是同一套数据源？（是不是跟业务系统打通）
这三个问题，问的是基座 。能不能画出好看的流程图、能不能拖出漂亮的表单，演示五分钟就能看出来；而基座的能力，往往要到项目后期才会暴露------那时候换平台的代价已经很高了。
十二、结论
回到开头：低代码的定义太宽，所以要先收窄范围 （本文只谈应用系统开发），再建立结构（上层建筑 + 基座）。
在这个结构下，评估的逻辑是：
- 上层建筑（流程 / 表单 / 报表 / 大屏）决定「能不能做出来」；
- 基座（菜单 / 模块 / 权限 / 组织结构）决定「能不能规模化地做出来、交付给真实组织使用」；
- 基座比上层建筑更能区分平台------因为上层建筑是能力问题，基座是骨架问题。
一个可用的经验：看一个低代码平台，先看它的权限中心和组织结构做得多细，再看它的流程和表单做得多顺。 顺序反过来，容易在演示阶段被说服，在交付阶段吃亏。
附录：本文涉及的代码索引
| 主题 | 路径 |
|---|---|
| 系统实体 | Vue3/src/CCFast/GPM/MySystem.ts |
| 模块实体 | Vue3/src/CCFast/GPM/Module.ts |
| 菜单实体 / 菜单类型 | Vue3/src/CCFast/GPM/CCMenu/Menu.ts、MenuModel.ts |
| 菜单新建向导（类型→解析页面映射） | Vue3/src/CCFast/GPM/CCMenu/GPN_Menu.ts |
| 权限中心（授权对象 CtrlObj） | Vue3/src/CCFast/GPM/CCMenu/PowerCenter.ts |
| 权限主体（部门/人员/岗位/组织） | Vue3/src/CCFast/GPM/PCenter/PCenterDept.ts、PCenterEmp.ts、PCenterStation.ts、SpecOrg.ts |
| 表单设计器 | Vue3/src/WF/Admin/FoolFormDesigner/ |
| 流程设计器 | Vue3/src/WF/Admin/FlowDesignerV2/ |
| 报表 / 大屏设计器 | Vue3/src/CCFast/RptBlue/Designer/ |
| 大屏图表配置工厂 | Vue3/src/CCFast/RptBlue/Designer/components/widgets/charts/configs/index.ts |
| 大屏 AI 创建 | Vue3/src/CCFast/RptBlue/GPN_RptBlueAI.ts |
本文基于当前仓库源码静态分析整理，属于评估视角的整理而非产品能力清单；具体能力以你所部署的版本与实测为准。