★ FEATURED ARTICLE 前几天帮同事改一张从采购到销售的业务流程图第 N 次把合同审批这个框从采购分支拖到销售分支之后箭头果然又绕成了麻花文本框也叠成了千层饼。我当时差点把电脑合上。最后实在没辙干脆把整张图删了用一段文字描述让 AI 重新生成结果五分钟出图逻辑清爽布局规整。这件事让我彻底想明白了一个东西流程图最折磨人的从来不是画而是改。改一个框的位置可能牵动半个图的布局改一条分支可能让所有箭头重新排队。而最近很多人讨论的Skill机制恰好提供了一种修改回到文字里的新玩法——你不再对着画布拖拽节点而是直接改一段结构化文字再让 AI 帮你重新生成图。这篇就把我实际搭建、调试、使用这套流程的经验完整拆解出来给所有被流程图反复修改折磨过的产品、研发、测试和项目经理一个可落地的参考。1. 先坦白为什么画流程图总在改这一步翻车1.1 视觉画图的几个真实崩溃瞬间我在用主流流程图工具画系统流程图的时候踩过的坑能列出一整屏。最常见的场景是一个节点稍微挪动一下位置原本直来直去的箭头立刻变成绕路三连整张图的视觉节奏全乱了。要是画的是那种节点密集的算法流程图比如依次输入 10 个数求最大值这种带循环结构的图稍微改一改循环条件整套框线几乎要重画。更别提多人协作的时候设计师用 Figma 改了一版产品用 ProcessOn 又改了一版最后合并时根本不知道哪个框是被删掉的、哪个箭头是新增的。图形协作还有一个特别隐蔽的痛点是合并冲突。我见过团队里两个人同时改一张 draw.io 导出的 XML 文件Git 合并的时候冲突标得满屏都是谁都不敢动最后只能由资深同事重新手工合并一遍。这种事经历几次之后你就会明白图片文件、甚至图形编辑器的原生文件本质上都不是好的修改载体。它们适合被看但不适合被改尤其不适合被多人异步地改。1.2 图的本质是投影文字才是源码这里我想打一个类比流程图之于流程逻辑就像编译产物之于源代码。你在画布上拖出来的那些框和箭头本质上是流程逻辑这个信息的可视化投影。你改投影投影背后的逻辑可能没变但图形的几何结构全乱了你改源码编译出来的东西自然就对了。我一直觉得任何一份需要长期维护的流程图都应该有一个文字版源码作为唯一事实来源。这个源码可以是 Mermaid 文本、PlantUML 文本、也可以是 BPMN 的 XML甚至是一份条理清晰的伪代码。改图之前先改源码再重新生成图整个过程稳定、可审查、可回滚。这个理念跟最近 AI 编程工具里大热的 Skill 机制放在一起正好形成一套非常顺手的流程图维护工作流。2. 认识 SkillAI 时代的岗位说明书工具箱2.1 Skill 到底是什么先给还不熟悉的朋友解释一下。近一年 Claude Code、Codex、Cursor 这些 AI 编程工具里都出现了Skill的概念各家叫法略有差异但本质是一样的一个可复用的、定义了 AI 在特定场景下怎么工作的规则包。你可以把 Skill 理解成给 AI 的岗位说明书工具箱。平时你写一句 promptAI 是临场发挥但当你把一套完整的工作约定做成 Skill 放进项目的 skills 目录AI 遇到相关任务时就会自动按这套约定执行。一个标准的 Skill 通常是这样一个目录flowchart-builder/ ├── SKILL.md # 说明书干什么、怎么干、边界在哪 ├── prompt/ │ └── generate.md # 提示词模板需求怎么翻译成图文本 ├── examples/ │ ├── algorithm-demo.md # 算法流程图的成品样例 │ └── business-demo.md # 业务流程图的成品样例 └── scripts/ └── validate.py # 校验脚本生成结果先自动体检SKILL.md 是最关键的入口文件AI 读到它就知道哦这个项目里有这么一套专门处理流程图的约定。辅助目录里的模板、样例、脚本用来补充执行细节。这个机制最大的价值不是每次少打几个字而是把个人经验沉淀成团队资产。你踩过的流程图写法的坑整理成规则写进 SKILL.md团队每个人调用时都能自动避开。2.2 为什么 Skill 恰好适合管流程图流程图生成天生是规则驱动的任务。什么样的流程用菱形判断框、分支命名怎么编号、条件怎么写才不容易产生歧义、循环出口放在哪一层——这些规则完全可以写进 Skill 的说明文档里。AI 照着规则生成出来的图就是团队统一风格而不是每次随缘。更关键的是Skill 可以内置校验脚本。图形工具画完了只能靠人肉眼检查而文字版的流程图生成完脚本能自动检查有没有孤立节点、有没有命名冲突、分支是否成对闭合。生成阶段和修改阶段都能第一时间发现问题这比画完了再对着图找半天问题高效太多。3. 实际操作做一个文字改流程图的 Skill3.1 先定边界这个 Skill 管什么、不管什么做 Skill 之前最忌讳的是什么都想管。我第一版就把流程图配色、图标、水印全写进去了结果 AI 每次生成都要纠结半天样式反而把核心逻辑搞乱了。后来我把边界收敛成三条管业务流程图、系统流程图、算法流程图的逻辑结构设计。管输出为标准的 Mermaid 文本格式方便直接渲染和版本管理。不管页面美化、配色、图标素材这类纯视觉层的事那是渲染工具该操心的。边界写清楚AI 才不会在无关细节上浪费精力。同时我约定了几条硬性输出规则节点命名不允许重复用 P 开头表判断如 P1、P2用 A 开头表动作如 A1、A2所有条件分支必须成对要么都有出口要么注释说明为什么终止。这些规则写进 SKILL.md 之后生成质量立刻稳定了一个档次。3.2 SKILL.md 怎么落地我这里放一个精简过的 SKILL.md 写法你可以直接参考--- name: flowchart-builder description: 根据需求生成或修改流程图文本。适合用户提到流程、节点、分支、算法图、业务流时使用。 version: 1.0.0 --- # 流程图文案生成 Skill ## 职责 - 将用户需求转换为符合 Mermaid 语法的流程图文本 - 修改已有流程时只改对应节点不重构无关部分 ## 输出约定 1. 节点命名唯一动作节点用 A01 起判断节点用 P01 起 2. 判断条件必须明确写出比较逻辑例如 n%30 且 n%50 3. 循环结构必须标注循环入口和出口 4. 不输出图片、不输出样式建议只输出可渲染的文本 ## 生成前动作 - 先用三到五行伪代码复述用户需求确认理解无误 - 大型流程先列主干再展开分支 ## 修改守则 - 用户说改某处时只修改对应段落并列出改动点 - 如果改动会牵扯其他分支需要主动提示这份说明的核心作用有两个一是让 AI 在动手前先复述需求避免理解偏差二是用编号规则把生成结果的稳定性拉起来。实际用下来生成前动作那一条对减少返工特别有效。3.3 提示词模板把口语需求翻译成图文本SKILL.md 负责定规矩真正的翻译动作发生在提示词模板里。我写的 generate.md 大致长这样你是资深流程设计专家。用户会给你一段流程描述请 1. 提取所有实体节点和判断节点 2. 明确先后顺序、并行关系、循环边界 3. 输出 Mermaid 文本节点命名遵循 flowchart-builder 约定 4. 同时在文本末尾用两行说明你的分支判断依据 要求你输出时遵守以下格式 - 先输出 5 行内的伪代码复述 - 再输出完整的流程文本 - 最后列出修改或生成过程中的关键取舍这段模板的核心技巧是强制先输出伪代码复述。这等于给 AI 设了一道闸如果它理解偏了你在伪代码阶段就能看出来不用等整张图生成完再返工。我用它处理过几个很典型的场景效果都还不错。第一个是教科书级的算法题依次输入 10 个数要求输出其中最大的数。Skill 收到后先输出伪代码初始化 i1 读入第一个数 x令 maxx 当 i10 时循环 读入下一个数 x 如果 xmax则更新 maxx ii1 循环结束后输出 max然后再转成流程图文本。以前手画这种带循环的图改一次循环条件就要挪一遍框现在直接改伪代码里那一行i10重新生成即可。第二个常见问题是判断一个数 n 能否同时被 3 和 5 整除。这种判断节点的关键在条件合并伪代码就是n%30 且 n%50一个判断框两个出口分别标能和不能。Skill 里关于判断节点命名的约定在这里特别有用P01 就是那个唯一判断框清晰明了。第三个是求两个数 m 和 n 的最大公约数用辗转相除法。伪代码三行当 n!0 时循环 rm%n mn nr 输出 m这个例子我特别喜欢用来测试 Skill 对循环结构的处理——循环出口放在计算之后和放在条件判断之前画出来完全两种形态。用文字改的时候只是移动一行伪代码的位置重生成就完事了。第四个稍微复杂一点是 BFS 和 DFS 的算法流程图。BFS 的流程核心是队列起点入队、访问队首、邻居入队、标记已访问DFS 的核心是递归或栈沿一条路径走到头再回溯。这种图手画的崩溃感我太熟悉了——邻居节点的交叉连线能把人逼疯。但用文字描述就很简单主干和递归分支分开写渲染出来自动布局基本不用手工调整。3.4 校验脚本生成完先让图体检文字流程图的价值不止在于好改还在于能自动检查。我写了一个简单的 Python 校验脚本放在 Skill 的 scripts 目录里import re import sys def check_flow(text): actions set(re.findall(r\bA(\d{2})\b, text)) preds set(re.findall(r\bP(\d{2})\b, text)) dupes [x for x in actions if x in preds] if dupes: print(警告: 动作节点与判断节点编号冲突, dupes) # 检查判断节点是否都有两个出口分支 for p in preds: exits re.findall(rfP{p}--[^:]:, text) if len(exits) 2: print(f警告: 判断节点 P{p} 分支不完整) print(检查完成) if __name__ __main__: check_flow(sys.stdin.read())这个脚本的逻辑很简单扫描输出文本里的节点编号检查动作节点和判断节点有没有编号冲突判断节点是否都有成对出口。可能有人觉得这点检查不值得写代码但在实际项目里一张几十个节点的大图编号冲突和分支缺失是发生率最高的两类低级错误。让脚本在生成后自动跑一遍能省掉大量肉眼排查时间。3.5 安装与调用一个命令进入工作流Skill 的安装方式各家工具大同小异本质都是把目录放到对应位置。以 Claude Code 为例就是把上面的目录结构放进项目的.claude/skills/flowchart-builder/下Codex 和 Cursor 也都有各自的 skills 目录。装好之后调用更是直接我一般就这么说一句用 flowchart-builder 帮我画一张系统流程图用户从输入账号密码开始经过校验进入用户管理模块支持增删改查最后记录操作日志。AI 会先复述伪代码确认无误后生成流程文本。如果你要改直接在对话里说把校验失败的分支加一个重试三次的循环Skill 的修改守则就会生效——只改对应分支其他部分保持不动并且它会主动列出这次改了哪几个节点。这个改动点清单功能我特别推荐等于每次修改都留了一条审计记录。3.6 业务场景也能用BPMN 网关和跨模块流程算法流程图用文字改很爽业务流程图更是重灾区。比如搜索里常见的BPMN 流程图网关使用——BPMN 里的网关有排他网关、并行网关、包容网关三种。排他网关是多个条件只选一个分支走比如金额大于一万走审批、否则自动通过并行网关是所有分支同时走比如通知财务和通知仓库同时进行包容网关是满足条件的分支都走。用图形工具画网关的时候最难搞的是网关符号和分支线的布局几个网关叠在一起线稍微歪一点就看不清哪个条件对应哪条路。但用文字表达就非常干净一个判断 P01金额1万就是排他网关一条并行分支注释就是并行网关。Skill 里只要约定好网关的文本表达方式复杂的 BPMN 流程也能稳稳维护。另一个典型是从采购到 PS 到销售这种跨模块端到端流程。SAP 场景里采购订单、货物收据、发票校验、项目系统PS的 WBS 活动、销售订单、交货、开票一串节点跨了好几个模块。这种图用文字维护的最大好处是可以分层第一层只画五个主干节点第二层再展开某个模块的内部子流程。真要在画布上展开所有细节那图基本没法看了。4. 常见问题与排查记录4.1 图生成出来了但逻辑不对最常见的问题是判断条件搞反。比如最大数算法里循环条件应该是i10AI 偶尔生成i10多循环一次在大多数场景里看不出问题但边界情况就出 bug。我的排查方法是看它输出的伪代码复述——伪代码对了流程文本一般不会错伪代码错了直接让它重来不纠结在后面的细节上。还有一个高频错误是循环出口位置不对。GCD 算法里rm%n必须在n被更新之前执行AI 一旦把顺序搞反结果直接算错。我在 SKILL.md 里专门加了一条循环体内部语句必须按语义顺序标注序号。有了这个规则之后这类错误基本上绝迹了。4.2 图太大一坨看不清五十个节点的图不管用什么工具渲染都是灾难。我的处理方式是强制分层每次生成的流程文本只允许包含不超过十五个主干节点超出部分用子图引用。比如 SAP 端到端流程第一层是采购→收货→发票→PS→销售→交货每个节点再各自对应一张子流程图。修改时也按子图为单位改不会动不动就牵动全局。这里有个技巧分层不等于丢失细节。把细节沉淀到子图之后主图反而更接近业务汇报时真正需要的抽象层次。这一点在跨部门评审的时候特别加分因为不同角色关心的颗粒度完全不同。4.3 Skill 不生效AI 完全不按约定输出如果你发现 AI 没走 Skill 的逻辑先别急着怀疑工具坏了。按照我的排查经验十次里有八次是这几种原因SKILL.md 没放进正确的目录description 里的触发条件太窄用户的话没触发它或者 examples 目录是空的AI 没有参考样例可循。修复方法也很直接往 description 里加宽触发词尽量覆盖流程、流程图、节点、分支、算法图、业务流、时序这些常说的词。然后在 examples 里放至少一正一反两个完整样例正例展示标准输出反例标注常见错误。AI 有了参照物输出稳定性会明显提升。4.4 多人协作时的版本管理最后说协作。用文字流程图的另一个隐藏收益是 Git 友好。图形文件合并冲突基本没法解但 Mermaid 或 PlantUML 文本的冲突跟代码冲突一样Git 能明确标出哪一行冲突团队里任何一个人都能处理。我现在的团队约定是每次改流程图必须提交一段变更说明内容是改了哪个流程段、为什么改、影响哪些分支然后流程文本本身跟着提交记录走。Review 的时候先看变更说明再对比文本 diff基本五分钟就能完成一次流程评审。不过也有个要注意的坑不要让渲染出的图片直接进 Git。图片是产物文本才是源码。源码变更进版本库渲染图片按需导出这样才能避免源码改了图没更新这种经典事故。最后分享一点个人体会用文字维护流程图这件事我真正坚持下来之后感受最深的是图是给读者看的文字是给作者改的。每次项目复盘要调整流程时我不再害怕改动牵一发动全身因为我知道改的是源码重新生成只是按一下渲染按钮的事。如果你现在也被流程图反复修改折磨我的建议是从一个小流程开始试——先别急着搭复杂的 Skill哪怕只是把一张常用图改成 Mermaid 文本再让 AI 改两次你就能体会到修改回到文字里的爽感。等攒够了经验再花半小时把规则封装成 Skill后面就是持续的复利了。
阅读完成 · 觉得有帮助？
