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

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

依据代码：Vue3/src/WF/Admin/FoolFormDesigner/（表单设计器）、Vue3/src/WF/Admin/FlowDesignerV2/（流程设计器）、WF_Admin_AIFrm.cs、WF_Admin_AIFlow*.cs文档版本：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 生成完之后，有没有一套机制接得住」。

附录：本文涉及的代码索引

本文基于当前仓库源码静态分析撰写，功能具体行为以你部署的版本为准。