流程图修改告别拖拽，用文字驱动AI Skill实现高效改图

流程图改到崩溃这个热门Skill让修改回到文字里做过流程图的人都有过这种时刻业务方说“采购审批那里加一个部门的会签”你打开Visio或者Draw.io找到那个判定框拖一根线出来再把后面的框整体往后挪结果关联的箭头全乱了对齐线歪了为了捋直一根线又花了二十分钟。改到第五版的时候你已经不想改图了只想把需求文档直接拍在对方桌上。这个“热门Skill”解决的就是这件事——让流程图修改回到文字里。也就是说你不再直接拖动图形而是用文字描述“采购审批环节需要增加部门会签”AI自动帮你更新流程图。源文件是文字图形只是它的一种视图。这个思路放在算法流程图、用户管理模块流程图、甚至BPMN流程图上都一样好使。今天这篇就从一个踩坑无数的人的角度把“怎么用Skill把流程图修改变成改文字”这件事讲透。1. 改流程图改到崩溃问题不在你手残而在“图形即源”1.1 一个常见的崩溃现场我先还原一个典型场景。你在画一个“输入10个数求最大值”的算法流程图。传统画法是开一个流程图软件拖一个“开始”椭圆拖一个“输入”平行四边形拖一个“判断”菱形然后连线、加标注。画到这里一切正常。这时需求变化了说“不仅要找最大值还要找次大值”你怎么办你得把后面那一截逻辑全部重排新加一个变量加一个判断框然后所有连线重新走一遍。更崩溃的是“用户管理模块流程图”。用户管理通常包含注册、登录、权限校验、修改资料、删除用户。业务方某天说“删除用户之前要先发送确认邮件”。你需要在“删除”前面插一个“发送邮件”的矩形框再把“确认成功”和“确认失败”两条支线接上。如果你画的图比较大光是把后面的节点往右挪保证箭头不交叉就得花掉整个下午。这种崩溃的核心原因是大多数流程图工具把“图形”当成了唯一真相。你拖拽出来的方框和连线就是文件的本质。文字描述不存在流程逻辑只存在于一堆坐标和连线关系里。一旦逻辑发生变化你需要操作的是一堆看得见摸得着的形状而不是逻辑本身。1.2 图形编辑器的三个反人类设计第一个反人类设计是“布局等于意义”。在一张业务流程图里节点放在哪个位置分支往哪个方向走都决定了图的人读起来顺不顺。但图形编辑器不会帮你自动排版你手动拉出来的线一旦多了自动对齐就失效。每次修改都像在玩华容道。第二个反人类设计是“改逻辑必须改形状”。流程逻辑是“如果n能被3整除则输出A否则输出B”这在文本里只是一行if-else。但在图形里你得画一个菱形判断框、两个输出框、三条连接线以及相应的文字标签。你改“能被3整除”为“能被3和5同时整除”在代码里是一句正则的事在图形里要改判断框里的文字、改分支条件、可能还要加一个判断节点。第三个反人类设计是“版本管理和协作都很难”。流程图文件保存成.drawio、.vsdx或者.png你想对比“第一版审批流程”和“第二版审批流程”的差异只能靠肉眼。你想用Git做版本控制diff出来的全是坐标数字没有可读性。而文字描述天然适合diff改了一个词diff会清晰地告诉你这里变了。所以当有人提出来“我们能不能用文字来描述流程然后自动生成图”的时候我觉得这才是流程图该有的底层逻辑。最早接触的是PlantUML、Mermaid这类文本绘图工具它们解决了“文字生成图”的问题但没解决“聪明地修改”的问题。而Skill把这个能力往前推了一大步。2. 热门Skill到底是什么把“图”还回“文字”2.1 Skill的本质给AI一份“如何画图”的说明书Skill这个词最近很热无论是Claude、Codex还是仓颉、WorkBuddy都开始支持Skill或类似插件机制。说得直白一点Skill就是一堆“说明书 示例 规则”的集合放在约定的目录里让AI在需要的时候自动加载并按照里面的规范干活。以前你让AI“画一个流程图”它可能给你一段代码、一堆解释、甚至直接输出一个Mermaid字符串但格式乱七八糟。现在你给AI“加载一个流程图Skill”AI会自动遵守这套技能里定义的输出格式、命名规则、分支写法、渲染建议。它相当于一个专业老员工一上手就知道该用什么体例而不是靠你现场叮嘱“记得用菱形表示判断、方形表示处理”。比如一个“算法流程图Skill”的说明书里会写使用Mermaid语法输出开始节点用圆角矩形判断节点用菱形每行语句必须对应一个节点分支标签必须写在连线上。当AI看到这些规则再结合你给的文字描述就能生成一份稳定、一致、可继续修改的流程图。2.2 为什么这个思路能解决问题关键在于“源文件”变了。以前流程图源文件是图形坐标现在流程图源文件是文字脚本。你修改时不需要拖拽任何图形只需要在文字描述里加一句“在判断前增加一个预处理步骤”AI拿到这个更新重新生成整张图。逻辑变了图跟着变逻辑没变图不会乱跑。这有点像是把“画图”变成了“写文档”。写文档可以撤销、对比、找历史版本而这些能力图形编辑器都很难做好。Skill还解决了另一个问题它让生成结果可预期。没有Skill的时候同样的需求让AI画十次可能得到十种不同风格的图有的用Mermaid有的用PlantUML有的甚至直接输出ASCII字符图。有了Skill输出格式被锁死你可以像使用工具一样使用AI。还有一个容易被忽略的点Skill让流程图可以“被讨论”。以前流程图是图片业务方只能“看图说话”。现在流程图是文字业务方可以直接在大段的“start - 输入n - 判断n%30 - ...”里看到逻辑顺序改动意见也能精确到“把判断放在输入之后而不是之前”。流程设计的重心从“怎么画出来”回到了“怎么设计”本身。2.3 哪些场景最吃这一套算法图、业务图、BPMN图从热词里的“算法流程图”、“SAP业务流程图 从采购到销售”、“BPMN流程图网关使用”、“判断n能否同时被3和5整除”就能看出流程图的使用场景非常广。算法流程图是最标准的判断、循环、输入输出都是固定套路。用文字描述算法逻辑几乎天然适合。比如“依次输入10个数输出其中最大的数”一眼就能拆成循环、比较、更新最大值、输出。Skill能保证这些节点以最好的布局生成。业务流程图相对复杂比如SAP里从采购到生产到销售涉及供应商、库存、物料清单、销售订单、发货、开票。这种图最大的痛点是分支多、角色多、部门多。用文字描述每个环节的负责人、动作、判断条件AI生成时可以把泳道也带上。Mermaid支持泳道图Skill里可以规定“每个角色单独一列”改起来同样只是改文字。BPMN图更讲究符号语义有开始事件、结束事件、网关、任务、子流程。热词里提到的“BPMN流程图网关使用”就是典型场景。BPMN的排他网关、并行网关、包容网关在文字里可以被定义为“如果条件A则走分支1否则走分支2”AI能根据这些文字生成对应的BPMN结构。改网关类型只是把文字从“排他”改成“并行”。3. 实操用Skill把文字变成流程图改文字就改图3.1 准备Skill的骨架文件先说Skill长什么样。以目前主流的Skill结构为例一个Skill就是一个文件夹里面至少有一个说明文件比如SKILL.md。这个文件用Markdown写成包含两部分一个是“什么时候用”——描述该技能适用的场景另一个是“怎么用”——包括输出格式、步骤、示例、约束条件。以一个“算法流程图Skill”为例骨架大概是算法流程图Skill/ ├── SKILL.md └── examples/ ├── 判断整除.md └── 求最大值.mdSKILL.md里写的是规则examples里放的是几个完整的示例让AI照着“抄”。你可以把SKILL.md理解为给AI的一份SOP里面既要有原则也要有具体的正例和反例。在SKILL.md里我会明确几件事语言统一使用Mermaid语法节点类型开始/结束用([文本])处理用[文本]判断用{文本}输入输出用[/文本/]分支判断节点必须两条连线一条标“Y”一条标“N”不能出现不标注的分支注释关键节点可以加classDef进行高亮但不允许修改节点文字修改策略当用户修改了文字描述必须重新输出整份Mermaid代码不允许只给片段。这些规则里最后一条尤其重要。很多人用AI改图时AI会偷懒说“只需要把第二个判断改成...其余不变”结果用户复制粘贴后图就崩了。Skill强制“全量输出”从源头上杜绝了一截一截改造成的格式混乱。3.2 编写一个“判断题”算法流程图Skill我们用最简单的例子来跑通全流程——“判断一个数n能否同时被3和5整除”。传统流程图画法会画一个菱形判断框写“n%30”Y走右边进入第二个判断“n%50”N直接输出“不能被整除”。如果我把这个需求交给一个“算法流程图Skill”我不需要自己画图只需要写一段文字输入一个整数n 第一步判断n是否能被3整除如果不能则输出“不能被3和5整除” 如果能被3整除继续判断是否能被5整除 如果不能被5整除输出“不能被3和5整除” 如果能被5整除输出“能被3和5整除” 结束。Skill根据规则生成的Mermaid代码是flowchart TD A([开始]) -- B[/输入n/] B -- C{n % 3 0?} C -- Y -- D{n % 5 0?} C -- N -- E[输出“不能被3和5整除”] D -- Y -- F[输出“能被3和5整除”] D -- N -- E E -- G([结束]) F -- G这里的关键是AI完全按照Skill里的节点类型和分支标注规则来生成。判断节点是菱形输出处理是矩形输入输出是平行四边形分支连线有Y/N标签。这些不需要你反复叮嘱Skill已经“安排”好了。3.3 实际修改场景从“n能被3整除吗”到“n能被3和5同时整除”现在到了最重要的一步修改。假设最初的需求只是“判断n能否被3整除”你已经用这个Skill生成了一张图。业务方或者你导师突然说不对我要的是“同时被3和5整除”。传统做法是打开原图找到第一个判断框修改条件文字然后在“Y”分支后面新增一个判断框“n%50”再引出两条新连线把原来的“输出能被3整除”改成“输出能被3和5整除”把“N”分支改成“不能被3和5整除”。你光看这个描述就觉得累。但用Skill做修改你只需要把文字描述改一下输入一个整数n 判断n能否被3整除若否输出“不能被3和5整除” 若是继续判断n能否被5整除 若n不能被5整除输出“不能被3和5整除” 若n能被5整除输出“能被3和5整除” 结束。把这段新文字发给AI它套用Skill自动生成新的完整Mermaid代码。你检查一下逻辑没问题直接替换旧代码。整个修改过程你碰过图形吗没有。你只在文字层操作。这就是“让修改回到文字里”的意思。你可能觉得这跟用Mermaid有什么区别区别在于Skill让AI的输出更加稳定并且能把“文字改图”这件事封装成可复用的技能。我们团队之前用裸Mermaid让AI画图经常遇到它把“结束”节点漏了或者分支标签写反。有了Skill之后这种情况基本消失。3.4 进阶业务流程图与网关、子流程算法流程图相对简单我们再看业务流程图。假设要画一个“用户管理模块流程图”包含登录、权限校验、修改资料、删除用户每个操作都需要记录日志。用Skill可以这样规定泳道按角色划分操作节点包含“动作数据库表”所有异常路径都要画出来。把文字描述写成用户进入登录页面输入账号密码 系统校验账号密码如果失败返回登录页并提示错误 如果成功加载用户角色权限 用户可以选择“修改资料”“删除用户”或“查看日志” 如果选择“删除用户”系统先发送确认邮件用户点击确认后才执行删除并记录日志 所有操作完成后返回主页面。Skill会生成带泳道的Mermaid代码例如flowchart LR subgraph 用户端 A[输入账号密码] -- B{校验} B -- 失败 -- A B -- 成功 -- C[进入主页面] end subgraph 服务端 C -- D[加载权限] D -- E[选择操作] E -- F[修改资料] E -- G[删除用户] G -- H{是否确认邮件?} H -- 否 -- I[取消删除] H -- 是 -- J[删除并记录日志] end这里如果要把“修改资料”改成“修改资料前必须二次验证”你只需在文字描述里加一句AI就能在正确的位置插入判断节点。BPMN网关同理排他网关在文字里对应“如果A成立走分支1否则走分支2”并行网关对应“分支1和分支2同时执行”。Skill里写清楚网关的文本表达AI就能在生成时选对符号。4. 文字改图实战避坑那些文档里不写的教训4.1 Skill输出格式要“锁死”我在实际使用中踩过的第一个坑是Skill写得不够细。一开始我只写了“用Mermaid生成流程图”没有指定节点类型库。结果AI经常使用flowchart LR但在一些复杂场景下又擅自改成stateDiagram-v2或者混用graph。不同语法的渲染效果差别很大一旦格式变了你在渲染工具里的样式就乱套。所以在Skill里我强烈建议把输出格式锁死到具体语法和方向。比如只允许使用mermaid的flowchart TD自上而下禁止使用其他图类型 节点文本必须用中文且不要加多余引号 每条连线必须写成 “节点ID -- 标签 -- 节点ID” 的形式。这样AI就没办法“自由发挥”。我见过不少开发者在Claude Code或Codex里随便写一句“帮我把这段逻辑画成流程图”然后花大量时间让它修正成想要的形状。如果你一开始把规则写死在Skill里这个过程可以直接省略。4.2 生成结果的5种翻车现场与修复即使有了SkillAI也偶尔会翻车。常见问题我整理成了一张速查表问题现象可能原因修复方法判断节点只有出一个分支文字描述里只写了条件成立的情况在Skill中强制要求“每个判断必须有Y和N两个出口”结束节点缺失文字描述没有明确结束标识在Skill示例里写清“所有流程必须以结束节点收尾”节点文字过长图变得很宽业务环节文字太长在Skill中规定“节点文字控制在10个汉字以内细节写在连线标签或注释里”分支交叉严重自由布局导致连线混乱在Skill中规定“先画主干再画分支”并限制最大节点数AI只输出修改片段而不是完整图没有在Skill里强制“全量输出”在Skill中写入“每次修改后必须输出完整可渲染代码”这个表里的前四条本质都是因为Skill规则不够明确。第三条我在实际项目里遇到最多。那时候画“SAP从采购到销售”的业务流程每个节点都是“采购订单创建”“供应商发货确认”这种长文本生成出来的图又宽又密根本没法看。后来我在Skill里加了“节点文字精简”的规则把超长文字挪到底层说明里图才清爽起来。4.3 Skill和Agent别搞混热词里同时出现“agent skill”“skill和agent的区别”这里必须说清楚。Agent是一个能自主思考、规划、行动并调取工具的智能体Skill更像是一本操作手册。Agent可以加载多个Skill但Skill本身不会主动行动。在流程图的场景里你可以让一个Agent带着“流程图Skill”和“代码审查Skill”先让Agent分析一段业务逻辑再利用流程图Skill输出图。你也可以只加载Skill把它当成一个稳定的“画图助理”。别把这两个概念混在一起设计。如果你在Skill里写了太多“你要理解用户意图”“你可以自主调用其他工具”这类话它其实就不是一个Skill而是一个不完整的Agent。Skill应该是确定性的、招式固定的技能包。对流程图来说你需要的不是天马行空的创造力而是稳定的输出格式和严格的修改规范。这一点想清楚了Skill才能为你所用。5. 一套可以直接抄的Skill模板5.1 模板内容下面这套模板是我实际在用的“流程图生成与修改Skill”你可以在Claude Code、Codex、仓颉、WorkBuddy等支持Skill机制的AI工具里直接创建对应目录并复制进去。流程图Skill/ ├── SKILL.md └── examples/ ├── 单分支判断.md └── 多节点业务图.mdSKILL.md内容参考如下# 流程图生成与修改Skill ## 用途 当用户需要将文字描述的流程转换为流程图或者对已有流程逻辑进行修改并重新生成图时使用本Skill。 ## 输入要求 - 用户提供流程步骤描述必须使用自然语言包含明确的先后顺序和分支条件。 - 如果用户给出已有的Mermaid代码结合代码与新的文字描述进行全量更新。 ## 输出规则 - 必须使用Mermaid flowchart TD 语法图方向为自上而下。 - 节点类型规范 - 开始/结束([文字]) - 处理步骤[文字] - 判断{文字} - 输入输出[/文字/] - 每个判断节点必须有两个分支连线标签为Y和N不允许省略。 - 分支条件需要写在连线标签上不写在节点内部。 - 节点文字必须简洁建议不超过10个汉字如有关键细节在节点下方用类注释补充。 - 每次修改后必须输出完整可渲染的Mermaid代码不得只输出修改片段。 ## 示例 请参考 examples 目录下的两个示例。 ## 修改策略 当用户在原始描述上增加或修改一个环节时 1. 先理解新的完整流程逻辑 2. 重新规划节点顺序和分支 3. 输出一张全新的完整流程图不做局部修补。配套的示例文件里放一个简单判断和一个复杂业务图的生成结果。有了这套模板AI每次输出的符号规范性会明显提升。5.2 使用流程与自定义扩展使用流程很简单。先把上面的文件夹和文件放到AI工具指定的Skill目录下然后在对话中告诉AI“使用流程图Skill”接着把你要画的流程描述丢给它。以后每次修改只需说“在上一版基础上把删除用户前增加确认邮件”AI会调用Skill输出新的完整图。等你用顺手了可以根据场景扩展不同的专用Skill。比如“算法流程图Skill”侧重循环和判断“SAP业务流程图Skill”侧重泳道和部门“BPMN流程图Skill”则把网关、事件、任务对应到Mermaid的特定结构。每个Skill里的示例文件是最重要的AI会通过示例学到的细节远超你在规则文件里写的抽象文字。我在实际使用中发现一个示例文件比十条规则更管用。你把“输入一个数n判断奇偶”的完整Mermaid输出放在示例里AI遇到类似“判断素数”的需求时输出的结构几乎一模一样。这就是为什么我会在Skill文件夹里维护多个示例每次发现一个漂亮的输出就保存进去。Skill会随着你的使用越来越懂你这比每次都从零开始指挥AI要高效得多。如果你也被流程图改版折磨过强烈建议你把现有的几个常用流程图整理成文字描述建一个自己的Skill库。从那以后流程图的修改就会变成一件“改一行文字交差”的事。我个人现在的习惯是所有流程逻辑先写在文档里用文字把逻辑理清楚最后才让AI转成图。图形永远不是源头文字才是。