如果企业主要配置请假、报销、采购、合同等以"人审"为主的流程，优先选择仿钉钉审批设计器；如果流程包含消息事件、定时器、子流程、服务编排、异常补偿或跨系统协同，应选择专业 BPMN 设计器。对低代码平台而言，更稳妥的答案通常不是二选一，而是"简化审批模式 + 专业 BPMN 模式 + 同一套流程治理与执行底座"。
专业 BPMN 设计器解决的是"如何准确表达并执行复杂流程语义"；仿钉钉审批设计器解决的是"如何让业务管理员快速配置常见审批"。两者的用户、模型自由度和错误成本都不同。把专业设计器简单换一套皮肤，并不会自动变成易用的审批设计器；把审批树保存成 JSON，也不会自然获得 BPMN 的事件、并发和补偿语义。
图 1 左侧强调标准化和复杂流程语义，右侧强调表单驱动和快速配置；中间是两者可以共享的组织、表单、规则和治理能力。
一、先给结论：按流程复杂度和建模人群选择
选择专业 BPMN 设计器还是仿钉钉审批设计器，首先看"谁在设计"和"设计什么"，而不是看哪种画布更漂亮。
- 业务管理员维护的常规 OA 审批，流程大多是串行、条件分支、会签、或签和抄送，选择仿钉钉式设计器。
- 流程架构师或开发人员维护的跨系统流程，包含事件、网关、子流程、异步任务和异常处理，选择专业 BPMN 设计器。
- 同一平台同时服务行政审批、业务流程和系统编排，采用双模式，并让两种设计器共享发布、版本、权限、审计和运行监控。
- 不能接受模型转换失真的企业，不要承诺"任意 BPMN 一键切回简化模式"，而应明确可逆边界。
一句话定义：专业 BPMN 设计器是标准流程图建模工具；仿钉钉审批设计器是面向特定审批场景的受约束业务建模工具。
二、两类设计器解决的不是同一个问题
OMG 对 BPMN 的定位，是用标准图形符号连接业务人员与技术实现，并以足够精确的语义支持软件执行。BPMN 因此不仅有任务和箭头，还包括事件、不同类型的网关、子流程、边界事件、消息交互和补偿等概念。
仿钉钉审批设计器通常把流程收敛为一棵更容易理解的审批树：发起人、审批人、条件分支、并行分支、抄送人和结束。用户配置的是"谁来办、满足什么条件、表单能看什么、按钮能做什么"，而不是 BPMN 元模型本身。
两种产品表面上都在"画流程"，实际优化目标不同：
- BPMN 优先保证表达能力、标准交换和执行语义。
- 简化审批优先保证学习成本、配置速度和业务约束。
- BPMN 允许建模者组合出大量拓扑，平台必须用规则和校验防止错误。
- 简化审批只开放少数合法结构，很多错误在交互层就无法产生。
1. 专业 BPMN 设计器的优势与边界
BPMN 的价值不只是符号丰富，而是模型具有明确语义。bpmn-js 官方将自身定义为 BPMN 2.0 的浏览与建模工具，并通过 diagram-js、bpmn-moddle、规则、命令栈和扩展模块共同维护图形与 XML 模型。企业可以在标准模型上增加属性面板、组织选人、表单权限和引擎扩展，同时保留 BPMN 文件交换能力。
*图 2 Camunda 官方 Web Modeler 界面：左侧是 BPMN 元素工具箱，中间是自由建模画布，右侧是节点属性面板；专业设计器把图形、执行属性、校验和发布放在同一工作区。
这张界面图体现了专业 BPMN 设计器的典型信息架构：元素库负责表达标准语义，画布负责组织拓扑，Context Pad 负责就近建模，属性面板负责配置任务实现、人员分配、表单和扩展参数。它允许建模者在同一张图中组合人工任务、系统任务、网关与事件，因此表达上限高，但也要求建模者理解元素行为和令牌流转。
专业 BPMN 设计器适合以下场景：
- 订单、合同、供应链等跨多个系统的业务流程；
- 定时提醒、超时升级、消息等待和外部回调；
- 并发分支、汇聚、循环、事件子流程和补偿；
- 可复用子流程、服务任务、脚本任务和规则任务；
- 流程架构评审、版本差异、标准化交付和引擎迁移。
它的边界也很明显。普通业务人员需要理解网关配对、令牌流转和事件作用域；自由画布容易出现"图能保存、引擎不能按预期执行"的模型；企业属性越来越多时，右侧面板会变得很重。因此专业模式必须配套模板、建模规则、发布校验和角色权限，不能把完整元素库直接交给所有用户。
2. 仿钉钉审批设计器的优势与边界
仿钉钉式审批设计器把技术符号翻译为业务语言。用户看到的不是 Exclusive Gateway 或 Multi-instance User Task，而是"条件分支""多人会签""任意一人同意""自动跳过""抄送"。它尤其适合表单驱动、组织关系驱动的中国式 OA 审批。
*图 3 开源 wflow-web 仿钉钉审批流程设计界面：用户通过"添加流程节点"选择审批人、抄送人、条件分支、并行分支、延迟等待和触发器。
与自由 BPMN 画布相比，这类设计器先限定合法结构，再让用户在结构内选择审批业务语义。节点以卡片形式纵向展开，新增动作围绕"审批人、抄送人、条件和并行"组织，业务人员不需要先判断该使用哪一种网关或事件。易用性的代价是模型通常保存为平台私有 JSON，复杂事件和非结构化拓扑需要额外扩展或编译转换。
这类设计器的优势包括：
- 结构固定，拖拽和插入节点即可完成大多数配置；
- 审批人、部门负责人、角色和发起人关系可以直接选择；
- 条件读取表单字段，业务管理员容易验证；
- 节点卡片可以直接展示审批方式、人数和异常策略；
- 移动端预览和流程说明更接近日常办公习惯。
但简洁来自限制。任意回路、复杂汇聚、边界事件、事件子流程、补偿事务和消息编排很难在审批树中无损表达。若不断为少数复杂需求增加"高级开关"，最终会得到一个名称通俗、语义却比 BPMN 更隐晦的私有语言，长期维护成本反而更高。
本文使用"仿钉钉"描述一种常见的卡片式审批交互范式，并不意味着复制钉钉界面或推断其内部实现。钉钉开放平台提供审批工作流与待办集成能力，这说明产品级审批还需要模板、实例、表单数据和待办等服务，而不只是一个设计画布。
三、一张表看懂两种流程设计器
| 对比维度 | 专业 BPMN 设计器 | 仿钉钉审批设计器 | 选型判断 |
|---|---|---|---|
| 主要用户 | 流程架构师、开发、实施顾问 | 业务管理员、部门负责人 | 用户是否理解流程语义 |
| 典型流程 | 业务编排、系统协同、复杂长流程 | 请假、报销、合同、采购审批 | 人审还是编排 |
| 模型结构 | 任意图结构，元素和事件丰富 | 受约束的审批树或有向结构 | 是否需要复杂拓扑 |
| 学习成本 | 较高，需要培训与规范 | 较低，可按业务语言配置 | 上线速度要求 |
| 可移植性 | BPMN XML 可交换，仍需处理厂商扩展 | 通常是平台私有 JSON | 是否重视标准资产 |
| 执行语义 | 与 BPMN 引擎关系直接 | 需编译或由自研运行时解释 | 是否已有流程引擎 |
| 治理重点 | 模型正确性、版本和依赖 | 组织、表单、审批策略和体验 | 平台核心能力在哪一层 |
| 主要风险 | 复杂、容易误建模 | 表达能力不足、私有语义膨胀 | 哪种风险更可控 |
不要用"节点数量"判断复杂度。一个只有五个节点、却包含超时边界事件和消息回调的流程，更适合 BPMN；一个有十几个审批节点、但始终是串行与条件分支的流程，仍可能适合简化审批。
四、六个问题完成设计器选型
图 4 先判断流程是否以人工审批为主，再判断是否存在审批树无法稳定表达的事件和复杂拓扑。
选型评审时可以连续回答六个问题：
- 建模者是业务管理员，还是受过 BPMN 培训的流程架构师？
- 流程的主要活动是人工审批，还是系统任务与跨系统协同？
- 是否需要消息、定时器、边界事件、事件子流程或补偿？
- 并发分支是否需要复杂汇聚，是否存在任意回路？
- 模型是否需要跨工具交换，或作为长期标准资产保存？
- 业务是否要求部门负责人、逐级审批、会签、或签、加签、抄送和表单权限开箱即用？
前两问偏业务使用体验，第三至第五问决定语义上限，第六问决定产品化成本。若答案同时落在两边，应建设双模式，而不是让一种设计器承担全部需求。
五、简化审批节点怎样映射为 BPMN
仿钉钉审批设计器可以把模型保存为受约束 JSON，再在发布时编译为 BPMN XML。编译不是简单改名称，而是把业务语义展开为引擎可以执行和审计的模型。
| 简化审批概念 | BPMN 映射建议 | 必须补充的业务语义 |
|---|---|---|
| 发起人 | Start Event + 启动表单 | 发起范围、组织上下文、数据权限 |
| 审批人 | User Task | assignee/candidate、选人策略、无人处理 |
| 条件分支 | Exclusive Gateway + 条件连线 | 优先级、默认分支、空值和类型 |
| 并行分支 | Parallel Gateway 或多实例任务 | 分支汇聚、完成条件、撤回影响 |
| 会签 | Parallel Multi-instance User Task | 全票/比例/人数、拒绝策略 |
| 或签 | Multi-instance + completionCondition | 首人完成后的剩余任务处理 |
| 抄送 | 平台扩展、监听器或通知任务 | 是否产生待阅、是否影响流程令牌 |
| 自动通过 | 运行时策略或表达式 | 触发条件、审计记录、是否生成任务 |
"会签"和"并行网关"不能直接画等号。会签通常是同一个审批活动产生多份任务实例，并由完成条件决定活动何时结束；并行网关则创建多条独立流程分支。两者在撤回、超时、变量聚合和历史记录上的行为不同。
六、哪些 BPMN 模型无法无损切回简化模式
双模式最容易踩的坑，是承诺专业模式和简化模式可以随时双向切换。只要 BPMN 出现审批树没有对应概念的元素，转换就会丢失语义。
典型不可逆内容包括：
- 附着在任务上的边界定时器、错误和消息事件；
- 事件子流程、补偿事件和事务子流程；
- 多个网关交叉形成的复杂分支与汇聚；
- 任意回路、非结构化跳转和跨泳道消息流；
- 服务任务、脚本任务的重试、异步边界和连接器配置；
- 调用活动的变量映射与版本绑定。
平台应给模型标记 simple-compatible、advanced-only 或 lossy 状态。进入专业模式后，如果只使用白名单元素，可以继续回到简化模式；一旦使用高级元素，就只能保留只读简化预览，不能静默删除元素后重新保存。
七、更稳妥的答案：双模式共用一个治理底座
图 5 两种设计器拥有不同的编辑模型，但通过编译、校验和版本服务进入同一套发布与执行链路。
双模式不是维护两套毫无关系的产品。合理架构应分为四层：
- 设计体验层：简化审批树面向业务管理员，BPMN 画布面向专业用户。
- 模型层：简化模式保存稳定的审批 DSL；专业模式保存 BPMN XML 和扩展属性。
- 编译治理层：负责 DSL 到 BPMN 的编译、语义校验、版本冻结、差异比较和兼容性标记。
- 运行服务层：统一对接流程引擎、表单、组织、规则、消息、待办、监控和审计。
两种设计器必须共享节点业务主键、表单字段引用、组织选择器和权限模型，否则切换模式后，审批意见、表单权限和历史统计会失去关联。执行引擎也不应感知前端使用哪种设计器，只执行已发布、已校验、不可变的模型版本。
八、双模式平台怎样实现才不会失控
第一，先定义简化 DSL，而不是先画页面。DSL 要明确节点类型、分支结构、审批策略、异常策略和版本号；字段应有稳定标识，不能依赖卡片标题或数组下标。
第二，建立语义编译器。编译器输出 BPMN XML、厂商扩展和编译报告，并用固定样例验证会签、或签、条件优先级和默认分支。相同 DSL 必须产生可重复的 BPMN 结果。
第三，建立能力白名单。简化模式只允许业务人员使用经过验证的结构；专业模式也应按角色显示元素库，常规实施人员不必看到全部 BPMN 元素。
第四，发布时做双重校验。前端即时校验改善体验，后端权威校验防止绕过；校验至少覆盖图结构、表达式、组织策略、表单字段、调用活动和引擎扩展。
第五，版本不可变。草稿可以编辑，已发布版本只能复制为新草稿。流程实例必须记录设计模式、DSL 版本、BPMN 哈希和引擎部署标识，才能追溯"当时实际运行的模型"。
九、从当前项目出发，可以怎样演进
当前项目已经提供独立的 ych-bpm-designer，入口中组装了 Modeler、Properties Panel、Camunda Provider、moddle 扩展以及 simpleDesign / simpleRender 模块；属性面板还覆盖候选人、多实例、自动选人、表单和任务操作等审批能力。这说明专业 BPMN 模式和中国式审批扩展已经有较好的技术基础。
这里的 simpleDesign 目前更接近"BPMN 节点的简洁渲染风格"，并不是完整的仿钉钉审批树。建议按以下顺序演进：
- 保留现有 BPMN.js 设计器作为专业模式，逐步升级依赖并隔离对内部源码的修改。
- 新增审批 DSL 和卡片式简化设计器，只开放发起人、审批、条件、并行和抄送等稳定节点。
- 建立 DSL 到 BPMN 的编译器，复用现有审批人、多实例、表单和权限属性。
- 增加兼容性分析器，明确哪些专业模型可以返回简化模式。
- 将两种模式接入同一发布、版本、部署、运行监控和审计链路。
这样既能保留专业流程的表达能力，也能让常规审批更容易配置。云程低代码开发平台适合把双模式设计器作为同一流程资产的两个入口，而不是让业务人员在两套引擎和两套待办之间做选择。
十、上线前的检查清单
- 是否明确了两种设计器各自的用户角色和授权范围？
- 简化 DSL 是否有版本、JSON Schema 和迁移机制？
- 会签、或签、抄送、自动通过等概念是否有可测试的执行定义？
- 条件分支是否规定类型、空值、优先级和默认路径？
- DSL 到 BPMN 的编译结果是否可重复、可审计？
- 是否识别高级 BPMN 元素并阻止有损回切？
- 草稿、发布版本、引擎部署和运行实例是否能相互追溯？
- 表单、组织、规则、按钮和数据权限是否由两种模式共享？
- 前端与后端是否都执行发布校验？
- 是否准备了真实 OA 流程和复杂编排流程作为回归样例？
1. 如果只记住三句话
第一，常规人工审批优先选仿钉钉审批设计器，复杂业务编排和事件驱动流程优先选专业 BPMN 设计器。
第二，仿钉钉审批设计器是一种受约束的业务 DSL，不是换皮 BPMN；要接 BPMN 引擎，必须建立明确、可测试的语义编译规则。
第三，平台型产品最合适的是双模式：体验分开，模型边界清楚，发布治理和执行底座统一，并明确哪些转换可逆、哪些不可逆。