AI 时代还需要表单/流程设计器吗？从源码看设计器的真实职责

本文基于一套主流开源 BPM 引擎的源码做静态分析，讨论 AI 时代设计器的工程价值，供架构与平台工程师参考。

在 AI 面前，表单设计器与流程设计器还有用吗？——从该平台 BPM 的两个设计器说起

文档版本：2026-09 写作口径：只讨论仓库里能对得上的机制。不预设「AI 取代设计器」或「设计器不可替代」的立场，而是看两者各自在管什么。

一、把问题拆开

「AI 能不能替代设计器」这个问题问得太粗，因为「设计器」在两个层面同时存在：

该平台的 AI 向导（GPN_AIFrm、GPN_AIFlowNew）已经在做第一层——用提示词出字段、出节点。但从代码看，AI 生成的东西最后全都要「回到设计器」：生成完跳到 /WF/Designer/Form?FrmID=xxx，或 GloComm.UrlFlowD(flowNo) 打开流程设计器。这个「跳回」不是没做完，而是设计。

为什么？下面分两个设计器说。

二、表单设计器在管什么

FoolFormDesigner/main.vue 顶部有三个模式页签：可视化设计 / 预览 / 数据建模。这三个页签恰好对应了 AI 不碰的三件事。

2.1 结构：字段不只是字段

AI 生成字段时，AITools.Frm_Words 让它按 No / Name / 数据类型 / 逻辑类型 / 长度 / 分组 / ExtInfo / Tip 输出。这是一份压缩过的字段描述。但设计器里一个字段的真实状态远不止这些，从 props/database/FormInfo.ts、MapAttr 与各 *Widget.ts 看，至少还要管：

• 控件类型：文本、数字、金额、日期、日期时间、枚举、外键、单选、复选、富文本、附件、图片、手写签批、评分、进度…
• 分组归属：字段属于哪个 GroupField，分组本身还有顺序与折叠行为
• 校验与联动：MapExt 里的扩展配置（计算公式、级联、自动填充、正则）
• 数据存储：数据类型 + 长度 决定物理列，逻辑类型 决定存的是值还是外键

AI 一次生成的是一份「字段清单」，设计器管的是这些字段在一个表单模型里的完整状态。这份状态不是文本能穷举的——它是元数据表 Sys_MapAttr、Sys_GroupField、Sys_MapExt 的联合。

2.2 落库：数据建模页的「同步」

FoolFormDesigner/components/datamodel/DataModelPage.vue 有一棵「主表 / 从表」的树，每个表节点上有个状态点：已同步 / 未同步（tree-sync-dot）。DbAttrsTab.vue 里明确写着：

新增字段先保存元数据；删除字段先标记，执行"同步数据库"时清理元数据及关联配置。

也就是说，字段在设计器里改完，元数据和物理表结构是两件事，中间隔着一个显式的「同步」动作，且同步前会二次确认。

AI 直接生成 SQL 改表结构并不难，但谁来保证元数据与物理表一致、谁来处理「删字段时关联配置怎么办」？这类一致性维护必须有一个带状态的界面，让操作者看得见「哪张表还没同步」。这是设计器的职责，不是模型的。

2.3 关联：一流程多表单、节点换表单

表单不是孤立对象。节点可以绑定不同表单方案（NodeFormType），一个流程可能挂多张表。所以表单设计器保存的不只是一张表单，而是它在流程里的挂接关系。AI 生成的表单要进入这个关系网，必须经过设计器的绑定流程。

三、流程设计器在管什么

FlowDesignerV2 基于 @vue-flow/core，组件目录里有 CustomNode.vue、EditableEdge.vue、NodeContextMenu.vue、EdgePortModal.vue、FlowToolbarV2.vue 等。它不是「画图工具」，而是流程元数据的编辑器。

3.1 节点属性：AI 最难补齐的部分

AI 生成流程时（WF_Admin_AIFlow.cs 的提示词），只能让模型填 Name / X,Y / DeliveryWay / CondModel / FWCSta 这几个字段。但一个节点的真实配置远不止这些。FlowDesignerV2/utils/nodeQuickSettings.logic.ts 里的「快速设置」本身就暴露了一批：

注意最后两行的写法：用户看到的是一个下拉，背后是两个字段的组合。deriveRevokeMode / buildNodeQuickSettingsPatch 专门做「界面上的一档 ↔ 底层的字段组合」双向映射。

这正说明设计器的价值：它把分散在多个字段、有隐含约束的组合配置，收敛成操作者能理解的选项。AI 生成的 JSON 里如果只写了 CancelRole=1 没写 CancelDisWhenRead，语义就不完整——设计器的映射层正是为了防止这种「半套配置」。

3.2 接收人规则：50+ 种，且有前置条件

nodeQuickSettings.logic.ts 里 DELIVERY_WAY_LABELS 是一张接收人规则的中文对照表，从「按角色智能计算」到「按 WebAPI 计算」到「自定义组合规则」，编号一直排到 90。

这还只是快速设置里露出的部分。完整的 DeliveryWay 有 50 多种，且很多规则带参数与前置条件——比如「按绑定角色计算」要先选角色，「按明细表拆分子线程」要先有从表。

上一篇文章提到过，WF_Admin_AI.AiNode_DeliveryWaysSave 有一条白名单 AiSafeDeliveryWays：只放行「与上一节点处理人相同 / 与发起人相同 / 部门负责人 / 直属领导 / 分管领导」这五种不需要额外绑定的客观型规则，其余一律返回提示让用户手工配。原因写得很直白：

为避免节点缺失配置导致发送失败，AI 暂不作为"全自动落库"。

这说明连该平台自己都认为：接收人这种「选错就发不出去」的配置，不适合让 AI 直接定案。 设计器（接收人规则页 GPE_AccepterRole）在这里的角色不是「落后的手工工具」，而是「带前置条件的配置守门人」。

3.3 连线与条件：图 ↔ 模型的互转

EditableEdge.vue、EdgeLabelModal.vue、EdgePortModal.vue 处理的是连线。而在后端，连线对应 Dir（方向）与 Cond（方向条件）两组数据。设计器要做的是：

• 把用户拖出的线，翻译成 NDFrom / NDTo / Des 与条件记录；
• 把条件记录里的 FK_Attr / FK_Operator（如 ND101_QingJiaTianShu > 10）翻译回线上看得懂的标签；
• 保证「从 A 到 B 只有一条线」「条件字段必须属于本流程的表单」这类约束。

AI 生成流程时输出的 Cond 记录，字段名必须与表单实际字段严格对应（提示词里反复强调「用真实 NodeID，勿臆造」）。生成容易，保证引用有效很难——这是设计器与流程检查要接住的。

3.4 流程检查：设计器自带的质量闸门

GL_FlowCheckInfo.ts 是设计器里的「流程检查」面板，数据来自后端 Flow.DoCheck。它把问题分三级：

帮助里还写明两条关键信息：检测有局限性，无法 100% 保证无问题；以及系统具备自动更正与数据表结构修复能力。

这个面板的存在，回答了一个很实际的问题：AI 生成流程很快，但生成完谁来验收？答案是设计器里的检查器——它把「流程能不能跑」这件事变成了可枚举的红黄绿清单，而不是靠人肉看画布。

四、AI 与设计器的真实分工

把上面的观察收拢成一张表：

一句话：AI 负责把空白页填出个七八成，设计器负责让这七八成真正变成能跑的系统。 两者不是替代关系，而是「输入法」和「编译器」的关系——这个比喻在上一篇里用过，这里可以再补一句：设计器不只是编译器，它还兼任规格检查器和一致性维护器。

五、回应的三个常见说法

说法一：「拖拽太慢了，AI 一句话就能出表。」 出表快是真的。但 EnsureMergedSelectionSource 那套「先勾选、再落库」的交互说明，连该平台自己都没让 AI 直接落库——生成的是候选，选择权在人。快不等于可以直接用。

说法二：「设计器生成的东西也一堆坑，AI 至少省事。」 设计器的坑大多来自「配置项太多」。但 nodeQuickSettings.logic.ts 那种「一个下拉映射两个字段」的设计，恰恰是在减少坑。AI 不会自动帮你处理字段组合的完整性，反而更容易产出半套配置。

说法三：「以后 AI 直接把配置写库，设计器就没了。」 技术上可行，工程上危险。AiSafeDeliveryWays 白名单已经给出该平台的判断：会导致运行时失败的配置，不能交给概率。 设计器提供的「显式确认 + 校验 + 检查报告」，是让 AI 产物可上生产的前提。

六、结论

不是「AI 来了设计器就没用」，而是要分清两件事：

1. AI 让设计器的「起点」变高——不用再从空白画布开始，而是从一句描述开始。
2. 设计器让 AI 的「终点」可信——把草稿固化成有约束、可校验、能同步、能检查的元数据。

如果非要给一个判断：AI 越强，设计器越需要「厚」。 因为 AI 生成得越快，对「谁来保证正确」的要求就越高。该平台把流程检查、数据同步、接收人白名单这些都做进设计器和后端校验里，方向是对的；对选型者来说，评估一个低代码平台时，与其看它「AI 能不能生成」，不如看它「AI 生成完之后，有没有一套机制接得住」。