我第一次在某个低代码平台里看到“文字生成流程”这个入口时，说实话没抱什么期待。大模型写摘要、写文案见得多了，让它直接生成一张能落地的BPMN流程图，总感觉是演示Demo阶段的东西。BPMN这个东西，画图不难，难在一张图里藏着的语义——给你一张“请假流程”的图，你能看出来哪里是用户任务、哪里是排他网关吗？非技术背景的业务同事通常看不出来；反过来，他们嘴里说的一大段业务流程，让负责流程梳理的人转成标准BPMN图，光是把“如果费用超过五千”翻译成一个网关条件，就得来回确认好几轮。
大模型出现之后，不少团队都在做“文本转流程图”，但真正把这条链路做到能上线、能生成可执行BPMN模型的产品其实不多。这篇文章想聊聊这类产品背后的工程拆解：大模型怎么把一段人话翻译成一张“会跑”的图，建模器怎么兜住模型的不确定性，以及实测下来哪些场景真的靠谱、哪些场景一测就崩。如果你也在做类似的方向，或者正在评估低代码平台里的AI功能，这篇应该能给你一些参考。
1. 传统BPMN建模的痛点，比“画图慢”更麻烦
1.1 BPMN真正硬的门槛不是图形，而是语义
BPMN 2.0的符号体系对于第一次接触的人来说，信息密度是相当高的。开始事件、中间事件、结束事件，用户任务、服务任务、业务规则任务，排他网关、并行网关、包含网关、事件网关，子流程、调用活动，加上消息流、关联、泳道里的角色和部门……一个没受过训练的业务人员，第一次打开建模器看到的不是空白画布，而是一排看不懂的图标。
我见过很多实际项目里，业务用户拖了半天，最后只用上了“任务”和“结束”两个元素，连网关都不敢碰。为什么？因为网关背后的语义是路由逻辑，你得先想清楚“什么条件走哪条分支”，这个思考负担和BPMN图形本身没有关系。BPMN本质上是要给工作流引擎执行的一段“图形化脚本”，它既要表达业务，又要满足机器语义。对一个只想把流程理清楚的人来说，这套体系天然就有学习成本。
1.2 最贵的开销是把零散口述整理成标准模型
真正做过流程梳理的人都知道，画图本身只是最后一步，大头在访谈和需求澄清。业务部门经常会这么讲：“客户提交申请，我们销售先看下，能过的就过，过不了的退回去，反正要通知客户结果。”这句话里至少有开始事件、一个用户任务、一个排他网关、两条分支、一个通知任务、结束事件，而且“看下”到底是人工判断还是系统自动判断？没写。“过不了”是退回给销售重填，还是直接给客户发拒绝通知？还是没说。“通知”是站内消息还是邮件？也没说。
这些细节不澄清，图是画不出来的。传统BPMN建模工具只帮助表达结果，不帮助梳理过程，于是需求分析师只能一遍遍地开会追问，把零散的自然语言翻译成标准元素。这个过程又慢又容易失真，“开口说话”真正要解决的不是画图效率，而是这轮“从模糊到精确”的转译成本。
1.3 为什么必须得是BPMN，而不是随便画几根线
你可能会说，AI画图工具也能根据文字生成一个“看起来像流程”的图，为什么非要用BPMN？原因是平台里的工作流是引擎执行的。表单字段要关联，审批人要从组织架构里选，条件分支要真正参与路由，权限体系要识别节点类型。随便画个形状不是BPMN，BPMN牛在语义精确：网关、事件、任务各是各的类型，连线是有方向、有条件、有消息的。
所以AI生成流程的目标，从一开始就不是“画的像”，而是“生成的模型能不能直接被工作流引擎消费”。这就决定了下面所有的技术选型和工程链路，都跟做一个普通的小画板完全不一样。
2. 让一段人话变成可执行流程：整条管线的四个环节
2.1 第一步：从自然语言到“语义要素”
在真正调用大模型之前，得先定义清楚输入和输出。这里的输入是一段可能有错别字、有口语表达、有业务黑话的流程描述；输出不是一张图，而是一个结构化的“流程意图”。
我在实际的平台落地里，会把这一步的提示词设计成四个约束：角色设定为“企业流程建模助手”，目标限定为“只抽取事件、动作、判断、并行”，规则是“不要臆测文本里没有的信息，缺失时标记为待确认”，输出格式严格遵循一个自定义JSON Schema。用户输入“客户提交申请后，先检查信用分，如果低于600就拒绝，否则进入人工复核”，这一步得到的不是最终节点列表，而是一个结构化摘要：
{ "description": "客户提交申请；检查信用分；分支：如果低于600则拒绝，否则人工复核", "elements": [ {"kind": "event", "label": "客户提交申请"}, {"kind": "task", "label": "检查信用分"}, {"kind": "gateway", "label": "信用分是否低于600"} ] }这样做有一个好处：先让模型“复述”一遍它理解到的流程，再生成节点。如果复述错了，后面生成的节点大概率也是错的，等于把错误前置暴露出来。
2.2 为什么要加一层中间DSL，而不是直接输出BPMN XML
直接让大模型生成BPMN XML是一件特别诱人但危险的事。BPMN文件里光是语义部分就有definitions、process、startEvent、sequenceFlow这些标签；连线必须写sourceRef和targetRef；网关要么用direction区分，要么用default指定默认流；条件表达式要放在flow的conditionExpression里；更麻烦的是，BPMN规范还要求画布上的每个元素都有对应的图形坐标信息，也就是BPMN DI那一大段。
大模型对“语义正确”已经够吃力了，你还让它保证XML合法、ID唯一、坐标不重叠，这基本等于让一个刚学会写作文的人同时做排版和校对。所以工程上必须做一次职责分离：大模型只负责“理解并输出JSON DSL”，由确定性代码来负责“把DSL编译成合法BPMN XML”。中间DSL是大模型的输出边界，也是整个系统的稳定性护城河。
2.3 中间DSL怎么设计，才能把复杂流程也装得下
我建议的DSL结构不做太复杂，够用就好。节点部分要有id、type、label，type限定在常用的元素集合里：startEvent、endEvent、userTask、serviceTask、exclusiveGateway、parallelGateway。边要有from、to，以及可选的condition和流转文案。泳道和组织单元先不做强约束，但如果文本里能识别出“部门”或“角色”，也抽出来放到assignee字段。
一段典型的DSL长这样：
{ "nodes": [ {"id": "start", "type": "startEvent", "label": "开始"}, {"id": "task_check", "type": "serviceTask", "label": "检查信用分"}, {"id": "gateway_score", "type": "exclusiveGateway", "label": "信用分是否达标"}, {"id": "task_reject", "type": "userTask", "label": "发送拒绝通知"}, {"id": "task_manual", "type": "userTask", "label": "人工复核"}, {"id": "end", "type": "endEvent", "label": "结束"} ], "edges": [ {"from": "start", "to": "task_check"}, {"from": "task_check", "to": "gateway_score"}, {"from": "gateway_score", "to": "task_reject", "condition": "信用分低于600"}, {"from": "gateway_score", "to": "task_manual", "condition": "其他情况"} ] }这个DSL本质上就是BPMN语义的“高频子集”。低频元素比如消息中间事件、边界事件、补偿、事务子流程，先不指望大模型生成，留给用户在画布上手工补。把边界缩小，模型的准确率才能稳定在可接受的范围内。
3. 让大模型稳定输出结构化数据：比写提示词更重要的三件事
3.1 用函数调用约束输出，把“自由发挥”降到最低
很多人以为把“请用JSON格式输出”写进提示词就完事了，实测下来完全不够。模型心情一波动就会在JSON里加注释、输出Markdown代码块、把数字写成字符串，下游解析代码动不动就崩。
工程上的做法是优先使用对话模型的函数调用能力：预先声明一个createProcess(nodes, edges)函数，模型只负责决定函数的参数值，由运行时保证拿回来的就是一个标准JSON对象。这样模型的自由发挥空间被大幅压缩，输出结果从一个“散文体回答”变成了“确定性的API调用”，下游解析逻辑可以省掉一半。如果你用的模型服务不支持函数调用，也可以退而求其次，在提示词里给出严格的示例并禁用额外字段，但效果会差一些。
3.2 校验、修正、再生成的闭环
即便有函数调用约束，也不能保证语义正确。生成的DSL必须经过一层确定性校验，这一步是兜住模型幻觉的关键。校验规则其实不复杂：
- 节点type必须来自许可枚举列表
- 必须且只能有一个开始事件，至少一个结束事件
- 所有边的source/target必须存在于节点表，禁止悬空引用
- 节点ID不可重复
- 网关至少要有两条出边
- 不能出现从结束节点出发的边，不能出现无意义的事件回路
校验失败时，把校验器输出的错误信息拼回大模型的上下文，让它重写，最多重试3次。这个策略看起来笨，但比让模型一次性生成完美结构可靠得多。
for attempt in range(3): dsl = llm_generate_with_tool(system_prompt, user_text) errors = validate(dsl) if not errors: return compile_to_bpmn(dsl) user_text += f"\n上次生成的DSL存在这些问题：{errors}\n请修正后重新生成。" # 三次都不过，直接交给用户手动改，不要硬生成这里有个很重要的理念：AI不能保证100%正确，但工程系统要通过“确定性校验+重试修复”把模型的错误率压到一个可控水平。即使三次都失败，也应该优雅地降级，而不是把错误模型硬推给用户。
3.3 术语词典与模型双保险：防止业务黑话跑偏
企业里到处都是内部黑话，比如“会签”“转办”“两金”“OA单”。这些东西预训练模型不一定认识全，但平台里历史流程的表单名、节点名里都有。纯靠模型去猜，结果常常是生成一个表面通顺但完全不符合企业内部习惯的流程。
我的做法是维护一个“业务术语/同义词映射表”，在预处理阶段先把文本里的黑话替换成模型更熟悉的通用表达，比如把“会签”替换成“需要多个审批人依次审批”，等模型生成完节点标签之后，再反向替换成用户习惯的叫法。这个词典初始版本手工维护几百个高频词就够了，后续可以从历史流程数据里自动挖掘补充。核心思想是借词典的确定性来弥补模型的随机性。
4. 实测中的翻车现场，哪些流程真能用、哪些一测就崩
4.1 高频可复用的“常规流程”效果最好
实测下来，报销审批、请假申请、采购申请、合同用印这类流程，语义模式高度固定——发起、部门审批、财务审批、结束，偶尔加一条退回分支。大模型几乎不会认错节点类型，生成的网关条件也比较准确。这类场景用户平均只需要改一到两个条件表达式，完全达到了“可用”的标准。
一个典型的成功案例是“差旅报销”：员工提交申请，部门负责人审批，财务复核发票，出纳打款。大模型生成的流程图基本一次成型，特别是当用户给的文本里已经明确写了“如果金额超过5000元，需要总监审批”时，排他网关和两个分支的生成都很准确。这说明预先沉淀的流程模板对模型输出有很强的引导作用。
4.2 事件驱动和复杂回路最容易翻车
一旦文本出现“等供应商回传合同”“收到回调后”“超时自动提醒”这种话，麻烦就来了。这类语义在BPMN里对应消息中间事件、边界事件、定时中间事件，而大模型的大量训练语料来自“伪流程图”，经常把“等待外部事件”误写成两个普通任务之间的流转条件，生成的图里会出现一条从“等待”节点直接连到“发出通知”的线。业务上看着没错，引擎语义上完全是错的。
另一个高频翻车点是“退回”。业务口中的“退回”可能是按原路逐级退回到发起人，也可能只是退回到上一个审批人。很多模型会把退回画成一条并行回边，结果流程直接进入死循环。这类问题靠加大模型参数解决不了，得靠交互设计兜底：对不确定的分支，明确提示用户补充语义，而不是让模型自作主张。
4.3 产品化止损：定位成“智能草稿”而不是“一键成稿”
做完一轮实测后，最稳妥的产品定位是“生成初稿，人工确认”。平台的交互方式是：AI生成后打开一个对照面板，左侧显示用户原始描述，右侧显示识别出的节点和边，用户可以逐段修改；不确定的地方，系统高亮标注“请选择：普通任务/服务任务或网关类型”。
这样既保留了AI的效率，又不会让业务人员在完全看不懂的情况下乱点“生成”。另外，一定要给每次生成留一份可追溯快照——存用户原文和模型输出的DSL，方便用户后续复盘，也方便研发定位模型问题。这条经验我说给所有做类似功能的朋友，千万别省。
5. 从“生成一张图”到“看懂一张图”：反向能力与延伸思考
5.1 让AI给流程图“讲故事”
大模型能理解文本，自然也能把图反向翻译回人话。用户选中一段BPMN流程，点击“解释这段流程”，模型就能输出：“客户提交申请，检查信用分，若低于600则拒绝并通知客户；否则进入人工复核，最后发送结果通知。”
这个能力在新人入职、跨部门拉通、图纸评审时价值很大。原来需要专门培训BPMN语法才能读图，现在点一下就能得到中文自然语言描述，等于把读图的隐性成本降到了零。在实际使用中，我发现它比正向生成流程更常用，因为存量流程远远多于新流程。
5.2 给现有流程“体检”：大模型不只是生成器，还是检查员
顺着“读图”往下走，大模型还能对已有的BPMN模型做“业务体检”。比如静态检测没有结束事件、网关出边没写条件、某个用户任务没有配置审批人，这些都是规则能查的；但大模型还能提供更深层的业务视角：看完整张图后指出“这里两个并行网关之间没有任何任务，大概率是删过头了”“这个退回边可能会造成无限循环，建议加一个次数限制”。
这类建议不需要完全自动化，作为图上的一行批注就很有用。它把大模型从“生成工具”变成“评审助手”，这才是真正的“开口说话”。
5.3 流程对话的闭环：从草稿到真图的下一步
顺着这个思路走，远期应该把“流程对话”做成完整闭环：业务人员用自然语言描述需求，系统生成并渲染BPMN；用户在画布上做调整，系统把改动结果反向记录成一段“流程变更说明”，供后续生成时自动参考用户偏好。
还有一个我很看好的方向，是把已上线流程的运行数据和大模型生成结果做对比。假设你设计了一条审批链，系统根据历史数据显示“去年有37%的单子在这里被退回”，然后AI建议你把“财务复核”节点前移。这已经不是让流程开口说话，而是让流程的运行经验开口说话。目前这个方向还在很早期，但它比单纯的文本生成更有想象空间。
最后说点个人体会。这个功能真正打动我的一次，不是自动生成请假流程，而是梳理一个跨部门旧流程：系统里存着几十个节点，没人讲得清为什么这样流转，负责的业务同事换了两三茬。后来新来的流程负责人直接让AI把整个存量BPMN模型翻译成人话，再对着描述慢慢调整，沟通成本一下子降下来了。大模型在这里解决的问题，不只是省掉拖拽动作，而是把“画流程”的门槛从专业技能变成了“说清楚需求”。至于能不能完全替代人去设计流程，目前看还远。但它至少让流程设计从“一个人懂BPMN的人写XML”变成了“一群人在对话里把流程理清楚”。这就是我眼里“开口说话”最实在的价值。
