CCFast 驰骋低代码 BPM：积木菜单设计思想

关注

原创最新推荐文章于 2026-11-07 10:13:44 发布 204 阅读 AI 写同款· GEO 优化 ›

协同平台前端技术全景（九）：低代码表单与流程引擎某装备制造企业协同平台采用双引擎低代码架构：VForm3（本地UMD包）实现动态表单，自研EasyProcess管理审批流程，二者通过formFieldData无缝联动。表单模板可配置、无需发版，真正实现“改表单不改代码”，显著提升业务响应效率。阅读详情

一、概述：为什么从“菜单”出发做低代码

CCFast 驰骋低代码 BPM 是一款开源的低代码开发与流程平台，面向企业信息化与业务流程数字化场景。本文阐述驰骋低代码 BPM 的整体体验与交付结构，根植于一套清晰、可扩展的菜单体系。

其核心理念可以概括为：以菜单体系为骨架的低代码开发与运行平台——不是零散堆页面，而是用“可被授权、可被复用、可被组合”的菜单单元搭建系统。

底座能力运行在组织结构管理与系统权限体系之上：权限按系统、模块、菜单等粒度，并结合人员、角色、部门等进行划分与控制，积木菜单始终在可控、可审计的边界内被使用。

在产品语境中，菜单体系也常被称为「工具箱」，每一条菜单就像一个「工具」：解决系统建设过程中不同场景的问题，需要用不同的菜单形态去对症处理。

类比：维修一辆车时，拆装需要扳手等各类工具；路试与诊断需要测试仪器。不同阶段、不同工种，取用不同工具才能完成高质量交付。

类比到信息系统：会做查询、会做左树右表、会做大屏、会做实体台账、会做单据闭环、会做工程进度、会做任务协作……这些能力在工程中常常同时存在，但并非同一种页面形态能解决所有问题。

工程化视角：在一个成熟系统里，系统由不同类型的菜单组合而成。菜单类型越齐备、每种类型下的配置抽象越稳健，平台的表达力就越强。

二、积木菜单的定义：模板化解决“一类问题”

菜单可以理解为页面模板——它不是一次性的静态页面，而是面向一类稳定问题域的运行时载体；每个模板都对应一类典型应用场景。

举例：

流程类菜单：承载“立项—审批—办理—归档”的可编排协作；
实体类菜单：承载“台账式主数据”的增删改查与业务关联；
大屏类菜单：承载“沉浸式、可读性极强的数据展现与态势感知”；
视图类菜单：承载“基于数据源的列表、检索、层级组织、图形化时间表征”等分析型诉求。

平台能力的乘数：模板越丰富、每个模板的关键配置项越“抽象得刚刚好”（既不捆死开发者，又不会把复杂度甩给业务用户），CCFast 的整体能力半径就越大。

当前主流的模板版图（与产品能力与路线图对应，具体以交付版本为准）：流程类、单据类、实体类、活动类、工程类、大屏类、OA 类、视图类、高代码类。

三、对标产品界面：积木菜单分组导读

在驰骋低代码的「新建积木菜单」工作台中（GPN_Menu），能力与向导按分组组织，可作为读者理解本平台“菜单家谱”的快速索引：

分组	名称（摘要）	读者可记住的一句话
A	流程	以流程模板为维度发起、办理、追踪业务
B	单据	“有事发生”的记录型表单，常与审核结合
C	实体	“有编号与名称的事物”台账，承载主数据语义
U	字典管理	低频变更的键值与树形基础数据入口
P	工程	项目、里程碑、进度与任务的工程化视图
W	活动（持续演进）	面向特定人群的限时采集与外联表单
E	大屏列表（含数据源列表等入口）	蓝色/白色风格的数据大屏与统计分析场景
J	视图	用数据源拼装列表、查询、左树右表、多维报表
D	高代码	以 TS 全栈范式与页面模式解析支撑深度定制
G	页面引用	自定义 URL、Tab 容器等“最后一公里接入”
F	工具视图	实体/单据/流程从表视图等拼装型能力
H	OA 应用	信息发布、日程日历、记事、知识库、工作日志等办公常用能力

下文按“业务可读性优先”的顺序展开模板类型，穿插与分组相关的落地说明。

四、流程类积木

应用场景：公文、请假、订单、巡检与物联网业务流程等一切以“流转与协同”为中心的场合。
能力要点：在此类菜单上以某一个流程模板为维度完成发起、待办办理与全过程追踪，让业务从个人操作升级为组织级协作。
引擎底座：驰骋采用 CCFlow / JFlow 作为工作流引擎，长期在大量项目中沉淀，适配国产环境与复杂组织模型，侧重稳定可用与工程可维护。
与产品向导的呼应：向导中提供极简/专业建模路径、表单绑定策略、导入与“引入流程组件”等选项，满足不同交付节奏与存量资产复用需求。

五、实体类积木

5.1 实体是什么

通常具备编号、名称等主键语义字段的业务表单（或数据结构），围绕“某个事物本体”进行管理，描述对象的属性集合，语义上更接近说明书/台账：这是谁、有哪些属性、处于什么状态。
典型示例：资产、学生、车辆等主数据的集中维护。

5.2 实体与流程的三种常见关系（重要概念）

为方便业务规划，可把“实体驱动的流程语义”归纳为三类表述（以下为产品语义抽象，命名以项目实施为准）：

多次业务流程
在同一个实体上可以多次并行或先后发起互不“锁死”业务流程；流程生命周期结束时，不改变实体的核心业务属性。
示例：车辆加油、洗车、年检提醒类流程——车还是那台车。
宿主流程（强约束语义）
流程一旦启动后在运行中与结束后，可能对实体属性造成不可逆或强一致的业务影响；在流程占用实体生命周期的时段内，通常不应再对同一实体启动另一套同类宿主流程。
典型诉求：同一业务对象在某个阶段只能被一个“主轴流程”治理。
批量发起流程
选择多条实体记录，将它们作为起始集合进入流程起始节点或其从表结构，从而实现规模化办理。
示例：车辆批量报废、批量异动类业务。

补充：修改流程（批量治理）：在既定流程上对一批存量数据进行校正、调整或补办，常与数据治理场景结合——强调“以一个流程上下文处理一批数据的统一语义”。

六、单据类积木

形态特征：报销单、出库单、出门单等“一单一事”，往往具备单号、标题，记录时间、地点、人物、事由等要素，语义上更接近叙事文：当时在什么场景下发生了什么。
审核诉求：出库、请假等业务天然需要签收、核准与回溯。
审核两种常见模式：
- 简易审核：以更轻的路径完成单据侧的审批链路（适配简单组织与低风险场景）。
- 流程审核：让单据挂载在标准流程模板之下，以获得更强的过程治理、权责分离与可追溯性。
与产品向导的呼应：支持表单创建与模板导入、以及与既有单据资产的“组件化引入”，利于资产沉淀与并行交付。

七、字典管理

用途：管理系统中相对稳定的基础数据——键值对与层级结构，常用于下拉框数据源、编码体系与分类口径统一。
典型内容：商品类别、省份、职位、大类/小类等。
两类结构：
- 编号–名称型平面字典；
- 编号–名称–父节点编号的树形字典。
与产品向导的呼应：提供字典表创建、树结构字典创建，以及“把既有字典维护页面挂接到菜单”的引入能力。

八、大屏类积木

价值主张：以更友好、更直观的方式呈现关键指标与态势，把注意力引导到最需要被看见的异常与机会。
常见区分：蓝色科技风大屏、浅色信息窗/白色风格大屏等——面向指挥室与管理驾驶舱等不同阅读环境。
与产品向导的呼应：工作台提供大屏绑定与创建向导，并常与可视化设计器侧的工程列表联通；分组内也常一并提供数据源列表、通用列表组件等统计分析入口。

九、工程类积木

场景：项目管理、甘特视图、任务跟踪、里程碑管理等以“计划—执行—纠偏—复盘”为主线的工作。
说明：驰骋提供工程侧的引擎能力与模板向导；更细的参数建模与行业方案可在具体交付文档或版本说明中展开。

十、活动类积木

定位：在一定时间窗口内，对特定范围用户采集信息的工具；强调外联可达、表单清晰、收口可控。
典型场景：调查问卷、外部订单、信息采集样表、面向外部身份的登记活动等。
与产品向导的呼应：工作台已提供表单活动、试卷测评、业务流程型活动等向导项，并按用户类型、采集频次等维度做基础治理配置（能力与界面以当期版本为准）。
活动细分类型：可依行业方案扩展——例如信息采集、评测测评、限时申报、外链订单等；“活动”本质是在时间、人群与主题三者约束之下的采集与协办机制。

十一、视图类积木

定位：面向“看得清、筛得准、钻得下去”的场景，围绕数据源配置：列表、查询、左树右表、以及结合甘特语义的时间维展示等。
与产品向导的呼应：提供不分页视图、分页视图、左树右表、二维/三维交叉报表等向导入口，并按数据源方式进行选型。

十二、高代码类积木

定位：在需要突破标准向导边界时，以 TS 全栈范式承接深度定制；“基于多种页面模式的解析，像写结构化文档一样组织页面”。（产品拷贝中概括为“十三种页面模式”的工程抽象。）
与产品向导的呼应：工作台提供 Entity、GPN、TreeEns、GL、Tabs、多维报表等诸多高代码拼装入口，并提供 AI 工具链辅助由提示词或界面稿生成骨架代码包的落地路径——强调可读、可预览、可下载、可接续开发。
与读者的一句话：积木负责80% 的标准能效，高代码承接20% 的关键差异，两者共享同一菜单与权限底座。