OpenClaw+Skill：基于自然语言自动生成业务流程图的工程实践

1. 从“一句话”到“一张图”为什么我们需要自动化的业务流程图“能不能用一句话就把这个业务流程给我画出来”这句话我相信很多产品经理、技术负责人、甚至一线研发同学都说过或者在心里想过。尤其是在需求评审、方案设计、或者给新人讲解复杂业务逻辑的时候面对白板或者绘图工具我们常常需要花费大量时间去梳理节点、拖拽图形、调整连线、美化布局。这个过程不仅耗时而且容易打断思路。更关键的是当业务逻辑需要频繁调整时维护这些图表的成本会急剧上升。这就是我决定动手折腾“一句话出流程图”这个想法的起点。我的核心目标很简单让描述业务逻辑的自然语言直接、快速、准确地转化为结构化的流程图。这听起来像是魔法但拆解开来无非是三个核心环节理解、转换、呈现。理解就是让机器“听懂”我们描述业务的人话转换就是把听懂的逻辑映射成流程图的标准元素开始/结束、判断、处理、子流程等呈现就是把这些元素按照合理的布局画出来。市面上其实已经有不少类似的工具或尝试比如一些AI绘图工具集成了流程图生成或者某些低代码平台内置了基于模板的流程设计。但我在实际体验后发现几个痛点要么生成的结果过于死板只能处理极其标准的句式要么对中文业务描述的语义理解不到位经常把“如果用户登录成功”和“当用户登录后”识别成完全不同的逻辑要么就是生成的图布局混乱根本没法看。所以我的方案没有选择从零训练一个大模型而是走了“组合创新”的路子用OpenClaw作为理解自然语言的“大脑”用Skill作为定义和执行绘图规则的“双手”。OpenClaw 在中文语义理解和结构化信息抽取上表现相当不错而 Skill 则提供了灵活、可编程的图形生成能力。把它们俩“捏”在一起就构成了一个能听懂人话、并立刻动手画图的“自动绘图员”。接下来我就详细拆解一下这个“自动绘图员”是怎么搭建起来的其中有哪些关键的技术选型思考、具体的实现步骤以及我踩过哪些坑、总结出哪些能让它更好用的经验。2. 技术栈选型为什么是 OpenClaw Skill在决定技术方案时我评估了几个方向。最直接的可能是用 OpenAI 的 GPT 系列 API让它直接生成 Mermaid、PlantUML 这类文本绘图语言的代码。这条路子快但问题也很明显首先成本不可控尤其是对于需要频繁调用、内部使用的工具其次生成结果的稳定性和格式一致性是玄学今天能生成完美的 PlantUML明天可能就给你一段无法解析的胡话最后它缺乏对“绘图”这个动作本身的可控性比如我想严格规定某种类型的节点必须用蓝色菱形GPT 可能不会听我的。因此我决定将“理解”和“绘图”解耦并寻找在各自领域更专精、更可控的组件。2.1 OpenClaw专精中文信息抽取的“业务逻辑解析器”OpenClaw 并不是一个尽人皆知的名字它更像是一个在特定领域内口碑不错的工具。它的核心能力是给定一段中文文本和一个预定义的 Schema模式它能精准地抽取出结构化的信息。举个例子你定义好一个“业务流程”的 Schema包含“步骤名”、“执行角色”、“判断条件”、“下一个步骤”等字段然后把一段需求描述扔给它它就能输出一个结构化的 JSON 对象清晰地标明了每个步骤及其关系。这正好击中了我们的需求。我们不需要一个能写诗、能聊天的通用 AI我们只需要一个能精准理解业务句子中“谁在什么条件下做什么然后下一步是什么”的专门工具。OpenClaw 基于微调的中文预训练模型在这类信息抽取任务上比通用大模型表现更稳定、更准确而且因为是本地或私有化部署的方案数据隐私和调用成本都更友好。我的使用方式是预先定义好几个常见的业务流程模式 Schema线性序列模式用于“先A然后B最后C”这类描述。条件分支模式用于“如果X则Y否则Z”这类描述。并行处理模式用于“同时进行A和B”这类描述。循环模式用于“重复执行X直到Y条件满足”这类描述。OpenClaw 会先对输入的一句话进行意图分类匹配到最合适的模式然后再基于该模式进行细粒度的信息抽取。这样一句“用户提交订单后系统检查库存如果充足则扣减库存并生成运单否则通知用户库存不足”就会被解析成一个包含开始、处理检查库存、判断是否充足、两个分支扣减库存生成运单、通知库存不足、以及隐含结束的树状结构对象。2.2 Skill不只是一个绘图库而是可编程的“图形引擎”绘图库的选择很多从前端经典的 D3.js、mxGraph到服务端的 Graphviz、Cytoscape。我选择 Skill是因为它解决了一个关键问题将绘图逻辑代码化、模块化。Skill 允许你用一种声明式的方式定义图形元素节点、连线的样式、布局规则以及它们之间的逻辑关系。更重要的是它支持“技能”Skill的概念你可以把“画一个审批流程”、“画一个数据流图”这样的复杂绘图逻辑封装成一个独立的、可复用的、可配置的技能模块。这意味着什么意味着我不需要每次都写一堆冗长的代码去计算节点位置、画路径、调样式。我只需要写好一个“业务流程图”技能这个技能内部定义好了开始/结束节点用椭圆判断节点用菱形处理节点用矩形。节点之间的连线要带箭头条件分支的连线要打上“是/否”标签。使用层次布局算法让流程图自上而下清晰展开。同一层级的节点尽可能对齐。然后我只需要把 OpenClaw 解析出来的结构化数据JSON按照这个技能要求的输入格式喂给它它就能自动调用底层的布局算法和渲染引擎生成一张既符合规范又美观的流程图。如果我觉得菱形不好看想换成六边形我只需要修改技能模块里的一个配置项所有生成的图都会统一改变。这种“绘图逻辑即代码”的方式带来了极大的灵活性和可维护性。当业务方提出“能不能把涉及财务的节点标成红色”这种新需求时我只需要在技能里增加一条基于节点类型的样式规则即可无需改动核心的解析和生成链路。2.3 组合的化学反应112单独看OpenClaw 解决了“听懂”的问题Skill 解决了“画好”的问题。但它们的组合产生了额外的价值流程标准化通过 Skill 的技能模板确保了公司内部所有自动生成的业务流程图其图形规范、样式、布局都是统一的避免了“千人千图”的混乱。逻辑可验证OpenClaw 解析出的结构化 JSON本身就是一份机器可读的业务逻辑描述。我们可以很容易地对这个 JSON 进行校验比如检查是否有无法到达的节点死循环或者是否存在没有出口的判断分支。这相当于在画图之前就对业务逻辑进行了一次静态检查。迭代效率高当生成的图不准确时我们可以清晰地定位问题出在哪一环。是 OpenClaw 的 Schema 定义不够覆盖这种句式还是 Skill 的技能布局规则在这种复杂分支下会重叠定位快修改也快。这个技术选型本质上是在精度、可控性、成本之间找到了一个适合内部工具场景的平衡点。3. 核心实现链路拆解从文本到图形的流水线整个系统的工作流是一条清晰的流水线。下面我以一个具体的例子来贯穿说明。假设输入一句话是“客户在APP提交退款申请系统首先验证订单是否在可退款期内如果是则自动审核通过并原路退款否则转人工客服审核。”3.1 第一步自然语言预处理与意图识别原始输入文本首先会经过一个简单的预处理环节包括去除无意义符号、纠正明显的错别字可以用一个简单的词典映射、以及分句。虽然我们说是“一句话”但用户实际输入可能是一个长句包含多个逗号分隔的短句。预处理会将它们初步分离。接着处理后的文本会送入 OpenClaw 的意图分类器。我们预先训练好的分类器会判断这句话最符合哪种业务流程模式。对于上面的例子分类器会识别出其中包含明显的条件逻辑“如果是…否则…”因此将其归类到“条件分支模式”。实操心得意图分类的准确性至关重要。初期我们只定义了四五种模式发现很多复杂句子分类不准。后来我们增加了“混合模式”并允许一个句子匹配多个模式意图然后由后续的解析器进行融合。例如“提交申请后系统验证并同时通知卖家和买家”这就包含了“线性序列”和“并行处理”的混合。我们的策略是优先识别强信号词如“同时”、“并行”再处理弱信号。3.2 第二步基于 Schema 的结构化信息抽取确定了“条件分支模式”后系统会调用为该模式定制的 OpenClaw 抽取模型。这个模型背后有一个定义好的 JSON Schema{ type: object, properties: { start: {type: string}, condition: { type: object, properties: { description: {type: string}, judge_point: {type: string} } }, true_branch: { type: array, items: {type: string} }, false_branch: { type: array, items: {type: string} }, end: {type: string} } }模型会努力将句子中的元素填入这个 Schema。对于我们的例子它可能输出{ start: 客户在APP提交退款申请, condition: { description: 系统验证订单是否在可退款期内, judge_point: 是否在可退款期内 }, true_branch: [自动审核通过, 原路退款], false_branch: [转人工客服审核], end: 流程结束 }这里有一个关键点OpenClaw 的抽取不是简单的关键词匹配它基于上下文理解。它能知道“自动审核通过”和“原路退款”是“真”分支下顺序执行的两个步骤而不是两个独立的分支。踩坑记录初期 Schema 设计得太死板。比如最初“true_branch”只定义了一个“action”字段。当遇到“则A并B然后C”这种描述时信息就会丢失。后来我们将分支定义为步骤数组array并允许嵌套。同时我们为抽取模型提供了大量包含并列、递进关联词的训练例句显著提升了其处理复杂句子的能力。3.3 第三步结构化数据到图形元素的映射拿到结构化的 JSON 后我们需要将其转换为 Skill 技能所能理解的“图形描述语言”。这一步是一个确定的转换规则我写了一个转换器Transformer来完成。转换规则示例start- 创建一个类型为“start”的节点内容为 start 字段的值。condition- 创建一个类型为“decision”的节点内容为 condition.description。true_branch数组 - 为数组中的每个元素按顺序创建类型为“process”的节点。这些节点与 decision 节点用“是”标签的连线连接并且它们之间用顺序连线连接。false_branch数组 - 类似创建“process”节点与 decision 节点用“否”标签的连线连接。最后一个处理节点连接到end节点。转换器输出的是一个符合 Skill 技能输入格式的配置对象。这个对象描述了有哪些节点、每条连线从哪个节点到哪个节点、以及每个节点和连线的类型、标签是什么。它不关心布局和样式那是由 Skill 技能内部定义的。3.4 第四步Skill 技能执行与图形渲染转换器输出的配置对象被传递给名为“BusinessFlow”的 Skill 技能。这个技能内部封装了所有绘图逻辑节点样式映射根据节点类型start, end, decision, process应用预定义的形状、颜色、边框样式。比如decision 节点自动使用菱形、浅黄色填充。布局计算技能调用内置的层次布局算法如 Dagre。算法会根据节点间的连线关系自动计算每个节点的位置目标是使连线尽可能直、交叉尽可能少、整体布局紧凑且层次清晰。这一步完全自动化无需手动干预。连线绘制根据连线类型普通顺序流、条件流绘制带箭头的贝塞尔曲线或直线并在条件连线上添加“是/否”标签。渲染输出Skill 将计算好的最终图形渲染成目标格式。在我们的实现中主要输出两种格式一是 SVG 矢量图用于网页前端直接高清显示二是 PNG 图片方便插入文档或PPT。至此从一句自然语言描述到一张标准业务流程图的全过程就完成了。整个过程可能在几百毫秒到一秒内完成真正实现了“一句话一张图”。4. 提升可用性的关键处理模糊性与复杂逻辑如果所有业务描述都像教科书一样规范那这个世界就太美好了。现实是用户的输入充满模糊、省略和隐含信息。让这个工具真正“可用”而不仅仅是“可演示”关键在于如何处理这些情况。4.1 指代消解与信息补全用户经常说“提交后它会先验证如果通过就...” 这里的“它”指代什么“通过”指代什么条件这就需要指代消解和信息补全。我们的策略是结合上下文和领域知识库。系统会维护一个简单的会话上下文如果是多轮对话和一个业务实体知识库例如在电商领域“提交”可能指“提交订单”“验证”可能指“验证库存”。当 OpenClaw 遇到代词或模糊指代时会尝试从上下文中找到最近的一个合适的主语或宾语进行关联。对于“通过”这类抽象词我们会将其与当前环节最常见的判断条件进行关联例如“验证库存”的“通过”自然关联到“库存充足”。经验技巧我们建立了一个可配置的“同义词与隐含逻辑映射表”。例如当句子中出现“审核”时映射表提示解析器这里可能隐含一个“判断”节点其两个分支可能是“通过”和“驳回”。这个表极大地提升了对口语化、非正式描述的解析能力。4.2 嵌套与并行逻辑的处理复杂的业务流往往是嵌套的“如果A成立则执行BB完成后若条件C成立则执行D否则执行E。” 这包含了嵌套的条件判断。我们的 OpenClaw Schema 支持嵌套结构。true_branch或false_branch里的一个步骤其本身可以又是一个完整的条件分支模式对象。转换器和 Skill 技能也需要支持这种嵌套。在图形上这体现为一个子流程图或者一个更复杂的节点群组。Skill 的技能框架允许将一组节点和连线打包成一个“复合节点”从而在布局上保持清晰。对于并行逻辑如“同时通知买家和卖家”我们将其解析为在同一层级创建两个并行的“process”节点。Skill 的布局算法会尽可能将它们在同一水平线上对齐并用不同的连线颜色或样式加以区分。4.3 容错与交互式修正完全准确的自动解析是理想我们必须接受一定程度的错误率。因此系统提供了“交互式修正”界面。当流程图生成后会以一个可编辑的图形界面呈现给用户。用户可以直接拖拽调整节点位置如果自动布局不够理想用户可以手动微调。编辑节点文本直接点击图形上的文字进行修改。补充或删除节点/连线通过简单的图形化操作添加新的步骤或判断。重新生成如果解析完全错误用户可以稍微修改输入文本再次生成。所有在界面上的修改都会反向同步更新到底层的结构化 JSON 数据。这意味着用户既享受了自动生成的便利又保留了最终的控制权和修正能力。这个“半自动”模式在实际应用中接受度最高。5. 从工具到能力集成与扩展实践做出一个能跑通的 Demo 只是第一步把它变成团队内部甚至跨部门都能用的“能力”还需要做很多集成和扩展工作。5.1 多种集成形态我们提供了几种集成方式适应不同场景浏览器书签小工具最简单的方式。用户将我们的工具页面保存为书签。在任何网页如 Confluence 需求文档、JIRA Ticket中选中一段描述文本点击这个书签弹出小浮窗选择“生成流程图”图片就直接生成并显示用户可以复制图片粘贴回文档。Confluence /飞书等办公套件插件在 Confluence 编辑器中增加一个“/流程图”的斜杠命令。用户输入“/流程图 客户提交退款申请...”插件在后台调用服务直接将生成的流程图图片插入到光标位置。API 服务为其他内部系统如低代码平台、测试用例生成系统提供 RESTful API。其他系统只需要传入业务描述文本即可获取流程图图片或结构化数据。5.2 自定义技能与领域适配“业务流程图”只是其中一个技能。Skill 的技能架构使得扩展变得非常容易。当其他部门的同事看到这个工具后他们提出了新需求时序图技能研发同学希望根据“用户点击登录前端发送请求网关鉴权服务端查询数据库返回结果”这样的描述自动生成 UML 时序图。架构图技能运维同学希望根据“Web 服务调用 Auth 服务Auth 服务读写 Redis 缓存和 MySQL 数据库”生成简单的组件架构图。我们只需要为新的图形类型时序图、架构图设计对应的 OpenClaw Schema例如时序图需要抽取“参与者”、“消息”、“时间顺序”。训练或配置 OpenClaw 针对新 Schema 的抽取模型如果与业务流程差异大可能需要补充一些训练数据。开发一个新的 Skill 技能定义时序图或架构图的图形元素样式和布局规则例如时序图的参与者垂直排列消息水平箭头。很快我们就拥有了一个“一句话生成多种技术图表”的工具集。这充分体现了 OpenClaw Skill 这种解耦架构的扩展性优势。5.3 效果评估与持续优化如何衡量这个工具是否成功我们设定了几个指标生成准确率随机采样生成结果由人工判断流程图是否准确反映了文本意图。我们初期准确率约70%通过优化 Schema 和增加训练数据半年后提升到了85%以上。使用频率统计 API 调用次数和各插件的活跃用户数。用户反馈最重要的指标。我们建立了反馈渠道鼓励用户提交“生成错误”的案例和“希望支持”的新描述句式。这些案例是我们优化模型和规则的最宝贵材料。我们定期如每两周回顾这些反馈将常见问题归类。如果是 OpenClaw 解析错误就针对性补充训练数据如果是 Skill 绘图不美观就调整布局算法的参数或节点的样式配置。这个持续迭代的过程让工具越来越“聪明”越来越贴合大家的真实使用习惯。回过头看把 OpenClaw 和 Skill 组合起来做成自动生成业务图的能力本质上是一次“让工具理解人而不是让人适应工具”的尝试。它节省的不仅仅是画图的时间更是将业务逻辑从模糊的自然语言快速固化为清晰、可讨论、可验证的视觉模型的时间。对于需要频繁沟通、快速迭代的团队来说这种“提效”虽然看似微小但汇聚起来却能显著降低协作的摩擦成本。如果你也在受困于重复、繁琐的绘图工作不妨也试试这种思路从解构你的具体需求开始寻找那些专精而非全能的组件把它们组合成属于你自己的自动化解决方案。