AI 与低代码引擎如何分工？从一套工作流引擎源码看工程边界

本文基于一套主流开源 BPM 引擎的源码做静态分析，梳理 AI 能力在设计期/运行期的分布与工程边界，供架构与平台工程师参考。

AI 是更快的输入法，引擎是必须成立的编译器——从该平台 BPM 的 AI 落点看两类能力的边界

文档版本：2026-09 写作口径：只写仓库里能对得上的调用链与字段，不做「AI 全能」或「低代码已死」的结论。

一、先把问题问清楚

「有了 AI 还需要低代码吗」这句话，通常混了三个不同的问题：

1. 写页面的活要不要 AI 干？——这是生成能力问题。
2. 业务怎么落地要不要模型和元数据？——这是运行时问题。
3. 改一处、影响哪里由谁保证？——这是治理问题。

AI（大模型）最擅长的是第 1 类：从自然语言或截图产出一段结构化文本。 低代码擅长的是第 2、3 类：把业务规则固化成可校验、可升级、可审计的元数据与代码结构。

下面不空谈，直接看该平台 BPM 把 AI 放在了哪些位置，以及它故意没有让 AI 碰哪些位置。

二、该平台把 AI 放在哪里：一张调用图

从代码看，该平台的 AI 能力集中在设计期，入口是若干 GPN_AI* 向导，落点是后端 WF_Admin_AI*.cs 与 AITools.cs。运行期（发送、退回、找人、会签）目前仍由确定性引擎执行，没有 AI 介入。

设计期（AI 参与）
├─ AI 流程        GPN_AIFlowNew / GPN_AIFlow.ts        → WF_Admin_AIFlow
├─ AI 修改流程    Prompt_AIFlow.ts                      → WF_Admin_AIFlow_Designer
├─ AI 表单        GPN_AIFrm.ts                          → WF_Admin_AIFrm
├─ AI 大屏        GPN_RptBlueAI.ts                      → HttpHandlerRpt
├─ AI 高代码实体  GPN_AIFrm(From=GPN_MenuHardCode)      → WF_Admin_AIFrm.AiHardCode_*
├─ AI 接收人      GPN_AIAccepter.ts                     → WF_Admin_AI.AiNode_DeliveryWays*
└─ AI 助手        Vue3/src/Copilot/index.vue            → WF_Admin_AI_Copilot / WF_Admin_AI

运行期（AI 不参与）
└─ 发送 / 退回 / 找人 / 会签 / 超时  →  WorkNode、FindWorker、ExecEvent（纯确定性代码）

底层只有一个薄封装：BP.WF.AITools，默认走 DeepSeek 的 chat/completions，JSON 模式强制 response_format=json_object，温度 0.3，超时 300 秒（见 AITools.cs 的 CallDeepSeekChatAsync）。识图另配 OpenAI 兼容视觉接口，未配置时回退通义千问多模态——这是工程上很实在的一处取舍：deepseek-chat 不支持 image_url，所以识图必须换模型，代码里写得很直白。

三、AI 干得好的部分：把「描述」变成「草稿」

3.1 表单：识别「分组」与「从表」

AITools.Frm_Words 构造的提示词，是整个 AI 表单能力的核心。它做了几件低代码平台自己不太会写、但 AI 很擅长的事：

• 给上下文：把已存在的字段、可用枚举库、可用外键表、已有分组、已有从表全部拼进提示词，要求「不要重复、优先复用」。
• 定输出格式：强制返回纯 JSON 数组，字段结构固定为 No / Name / 数据类型 / 逻辑类型 / 长度 / 备注 / 分组 / 是否必填 / ExtInfo / Tip。
• 区分分组与从表：提示词里明确「一条业务只有一份的信息放 main 的不同分组；一对多、可多行重复的才是从表」。
• 生成时就把扩展属性带上：ExtInfo 里包含 @Icon=、@JSExp=正则^^提示、@suffix=cm，等于让 AI 顺手把图标、校验、单位也配了。

识图场景更体现工程细节。Frm_Words(...MainAndDtl) 会要求模型把纸质/扫描表单里「标题上方的单值项」放主表、「中间多列多行的表格区」放从表，并强制 dtls 至少一条。返回后 Frm_ParseAiFormMainAndDtls、Frm_AttrResponseToDataTable 负责剥 Markdown 围栏、兼容 {"main":[],"dtls":[]} 或纯数组、列名归一化（name→Name、type→数据类型）、缺失列补默认值。AI 输出天然不稳定，这一层清洗是让草稿能进设计器的前提。

前端 GPN_AIFrm.ts 的 EnsureMergedSelectionSource 也值得一提：它把主表字段和从表字段合成一棵「分组 + 项」的勾选树，用户先勾选、再落库（AiFrm_SaveAttrs / AiFrm_DtlsSave）。AI 生成的永远只是候选，落库动作由人确认。

3.2 流程：把自然语言翻译成一串方法调用

WF_Admin_AIFlow_Designer.Edit() 是这套体系里最像「agent」的一段。流程：

1. 导出当前流程的 XML 模板（flow.GenerFlowXmlTemplete()，超 12 万字符截断）；
2. 连同用户提示词、Flow/Node/Cond 字段说明一起塞给模型；
3. 要求模型返回一个任务数组，每个任务是 { MethodName, MethodParas, GenerPara }；
4. 后端按序调用 Dev2InterfaceCCFast.ExeMethod，用 GenerPara（如 @NodeID）在任务间传递上一步产物。

也就是说，AI 不直接改数据库，它只填参数；真正改流程的是 Dev2InterfaceCCFast 里既有的、经过事务与校验的静态方法（FlowTemplate_NodeCreate、FlowTemplate_DirCreate、FlowTemplate_CondCreate_ByFrm…）。提示词里甚至写明了「用真实 NodeID，勿臆造」。

这是个可以推广的范式：让模型做意图 → 方法映射，让既有 API 做落地。 好处是 AI 出错时，错在参数而非数据一致性。

3.3 接收人：只放开「客观型」规则

WF_Admin_AI.AiNode_DeliveryWaysGener/Save 有一段很克制的设计。它把 DeliveryWay 分成两类：

• 客观型（AiSafeDeliveryWays）：与上一节点处理人相同、与发起人相同、部门负责人、直属领导、分管领导——这些由组织结构在计算期推导，不需要再绑定角色/部门/人员集合，写 Node.DeliveryWay 即可生效。
• 绑定型：按角色、按部门、按人员、按表单字段——需要额外配置。AI 拒绝自动落库，返回明确提示，引导用户去接收人规则页手填。

代码里的处理是 IsAiSafeDeliveryWay，不在白名单就直接返回：

该接收人规则需要额外绑定角色/部门/人员或表单字段，为避免节点缺失配置导致发送失败，AI 暂不作为"全自动落库"，请在接收人规则页手动选定该规则并完成绑定。

这是全文最值得记的一个细节。它说明作者想清楚了一件事：AI 的可用边界，不是模型能力边界，而是"出错后系统能不能兜住"的边界。 会导致发送失败的配置，宁可不自动做。

3.4 高代码：AI 生成 TypeScript / C# / Java 实体

AiHardCode_GenerFromWords/Img 代表另一条路线：不生成低代码元数据，而是生成高代码实体类。它先让 AI 判断表单形态（Gener_FrmTypeByPrompt：EntityNoName 实体 / EntityOID 单据 / EntityTree 树），再生成三套源码——GenerCodeTS2024、GenerCodeCS2024、GenerCodeJava2024，用同一套 fillMapLinesInto 规则保证三种语言语义一致，最后写入 Vue3Path 下的目录。

这里出现了本文要讨论的核心问题：AI 生成的代码，怎么接进一个已经成体系的工程？ 该平台的答案是给代码一个「模板」和「归宿」——实体继承 EntityNoName/EntityOID，EnMap 里用平台约定的 AddTBString/AddDDLSysEnum/AddTBDtl，保存时写进约定的目录。AI 只填内容，不决定架构。

四、AI 干不好、也不该干的部分

4.1 运行时不能交给概率

流程引擎的核心是「发送到下一个节点后状态一定可推导」。WorkNode 的按 RunModel 分派（NodeSend_11、NodeSend_24_SameSheet…）、FindWorker 的 50+ 种接收人计算、ExecEvent 的事件时序——这些一旦掺入模型输出，就失去了「同一输入必得同一结果」这个前提，审计和排障都无从谈起。

所以从代码看，该平台的 AI 全部落在设计期：改的是 WF_Flow、WF_Node、Sys_MapAttr 这类元数据，改完经设计器保存、经流程检查（FlowDesignerV2 的 SSE 检查）验证，才进入运行期。AI 产出的东西，必须先「固化」成确定性的配置或代码。

4.2 「生成一个页面」不等于「交付一个系统」

回到第一节的第 2、3 问。一个业务系统真正难的不是画出表单，而是：

这些是结构性的，不是生成性的。AI 能帮你更快地填出表单字段，但它不会替你决定「一人多部门时按本部门角色找人」该怎么配——那是组织建模。

4.3 一致性靠的是约束，不是提示词

高代码那一章（doc/低代码部分/面向模式编程思想-的高代码开发.md）讲得很清楚：该平台前端有 14 种页面模式，基类定契约、子类写业务、解析页面统一渲染。这个「铁三角」的价值，在 AI 时代反而更明显——

• 基类约束了子类「必须实现 Init()、BtnClick()」，格式统一；
• 解析页面统一了 UI，升级 Vue/组件库时业务子类不动；
• 工厂按 ClassID 注册，避免「野生页面」。

有了 AI，生成 100 个 GL_* 子类变得很容易。但如果没有基类约束和工厂注册，这 100 个文件就是 100 个失控点。低代码/模式化提供的约束，正是让 AI 的产物可治理的前提。

五、结论：不是替代，是分工

回到标题。从该平台 BPM 的代码分布看，AI 与低代码的关系更像这样：

所以答案不是「有了 AI 就不需要低代码」，而是：

1. AI 把低代码的门槛进一步压低——从「会拖拽配置」压到「会描述业务」。该平台的 GPN_AI* 向导、Copilot 助手（自然语言打开菜单/发起流程）都在做这件事。
2. 低代码/引擎把 AI 的产出变得可用——没有 EnMap、没有 DeliveryWay 白名单、没有 Dev2Interface 这些结构化落点，AI 生成的内容只是一段无法进系统的文本。
3. 两者的接缝就是 AI 落地成败的关键——AITools 的字段归一化、AiSafeDeliveryWay 的安全集合、任务 JSON 的占位符替换，这些「不性感」的工程代码，才是决定 AI 能力能不能上生产的地方。

一句话：AI 是更快的输入法，低代码/引擎是必须成立的编译器。 打字快不能替代编译器，但编译器配上快输入法，交付效率是真的会变。