做技术这么多年我越来越觉得画流程图这件事快成了开发者的“时间黑洞”。为什么这么说你可以回忆一下接到一个需求代码逻辑其实想清楚了但leader让你“先画个流程图确认一下”系统出了故障你追了三天日志终于定位到问题复盘时要补一张调用链路图;新人入职你要把核心业务链路讲清楚PPT 里少不了一张流程图。大多数人的选择是打开 Visio、draw.io、ProcessOn把一个个方框拖到画布上再用箭头连起来。等你把箭头摆正、把颜色调好、把文字填完半小时已经过去了。如果中途发现逻辑画错了又要重新拖、重新连、重新排版。这是我在实际项目里感受最深的一类低效劳动画图的动作并不等于思考的过程。真正有价值的是那张图背后的逻辑梳理而不是鼠标拖动框线的操作。所以当我看到“skill”这个概念在 AI 编程工具里火起来的时候第一个反应就是最适合做成 skill 的场景恰恰就是“根据一段描述自动生成流程图”。这篇文章就来聊聊怎么用流程图生成 skill终结“手搓流程图”的日常以及如何把它接入到你的 AI 编码工具里。在往下看之前先给你一个判断如果你日常工作里至少每周要画一次流程图或者你的团队经常需要输出架构图、业务时序图、状态流转图那这个 skill 值得你花半小时配好。它不复杂核心就是一个规范化的指令集加一个目录结构但用对之后出图效率提升的不是一点半点。1. 这篇文章真正要解决的问题先不急着讲概念我们先把问题讲透。1.1 手工画流程图的四个痛点第一个痛点是排版耗时。哪怕是只有七八个节点的简单流程想画得整齐也要花不少时间。框的大小要统一箭头要对齐文字要放得下太多嵌套还要考虑布局。这些工作不产生任何技术价值但你不能不做。第二个痛点是改稿困难。产品经理告诉你“这里要加一个判断”你以为只是加一个菱形框结果发现加了之后整条线都要重画。一次改稿半小时起步。第三个痛点是沟通失真。很多人画图不遵循统一规范同一个“延期处理”有人用圆角矩形有人用菱形有人用普通矩形加注释。图是画出来了但团队里每个人理解都不一样。第四个痛点是图与代码脱节。代码改了流程图没更新。半年后回头看那张图描述的已经是另一个系统了。这四个痛点背后其实指向同一个本质我们把“绘制”这个动作错当成了“设计”这个动作。流程图真正的价值在于逻辑可视化而绘制本身是机械劳动。1.2 Skill 方案能改变什么用 skill 生成流程图变化发生在产出链路层传统链路 梳理逻辑 - 打开绘图工具 - 手动排版 - 反复调整 - 导出图片 Skill链路 描述逻辑 - 调用技能 - 生成结构文本 - 一键渲染 - 导出图片传统链路里你的大量时间消耗在“调整”上skill 链路里你只需要把逻辑描述清楚剩下的结构化和排版交给 AI 完成。这篇文章会带你从零搭建一个流程图生成 skill你可以把它用在支持 skill 机制的 AI 编程工具中。文章会覆盖skill 到底是什么和普通提示词有什么区别怎么设计一个流程图生成技能的目录结构和指令文件怎么用一段业务描述生成 Mermaid 流程图怎么验证生成的图是否正确实际项目中需要注意哪些坑。2. Skill 的核心概念它不只是“一段 Prompt”2.1 Skill 是什么Skill 是 AI 编程工具如 Claude Code、Cursor 等支持技能机制的 Agent 工具中的一种能力封装机制。它通常由一个文件夹和若干文件组成核心入口是一个SKILL.md文件。SKILL.md里写什么简单说它像是给 AI 的一本“操作手册”。手册里会定义这个技能解决什么问题AI 应该遵循什么步骤输出应该符合什么格式有哪些可复用的模板或示例。你可以把 skill 理解成“可复用的专业流程”。普通对话里你每次都要重新告诉 AI“请用 Mermaid 语法画流程图节点要拆分逻辑要清晰”有了 skill你只需要说“用流程图技能描述一下下单流程”AI 会自己按照手册里的规范去执行。2.2 Skill 与普通 Prompt 的区别很多新手会问这不就是一个预先写好的 Prompt 吗有相似之处但差别很明显。我们用下面这个表格对比对比维度普通 PromptSkill触发方式每次复制粘贴或当场描述按名字唤起一次性配置内容长度太长了浪费额度太短了效果不稳可以包含详细规范、多个参考文件可维护性散落在历史对话里难以更新集中在一个目录改一处全局生效可复用性只对当前会话有效跨项目、跨任务复用附带资源不方便携带示例文件可以附带模板、字典、参考图结构这个差异在生成流程图时特别明显。生成一张合格的流程图你需要约束的东西很多节点怎么命名、分支怎么表达、判断条件放哪里、异常流程要不要覆盖。如果这些约束写在 Prompt 里几轮对话后 AI 很容易“忘了”写在 skill 里它每次都会按规范执行。2.3 为什么流程图是最适合做 Skill 的场景之一流程图有一个天然优势它可以被结构化成文本。无论是 Mermaid 还是 PlantUML都用一种可读的文本来描述图形结构。这意味着“画图”不再是鼠标拖拽而是“生成结构化文本”的过程。而结构化文本恰恰是 AI 最擅长产出的内容。所以流程图生成技能的核心不是让 AI 学会“画图”而是让 AI学会把业务逻辑翻译成结构化的图形描述语言。3. 环境准备与前置条件在动手之前先确认你的环境。3.1 需要一个支持 Skill 机制的 AI 编程工具目前主流 AI 编程工具对“技能”的支持程度不一样。有的原生支持SKILL.md有的需要通过插件或第三方方案实现。本文讲的目录结构和SKILL.md编写方式是当前业界比较通用的做法你可以根据自己使用的工具把目录放到对应的技能加载位置。版本差异不用纠结。你只要记住一个原则你的工具需要能把一个文件夹里的SKILL.md和配套资源作为上下文加载给 AI 使用即可。3.2 需要一个支持 Mermaid 渲染的环境我们的 skill 输出使用 Mermaid 语法。Mermaid 是一个用文本定义图表的开源工具支持流程图、时序图、状态图、甘特图等几十种图形。如果你想在本地方便查看推荐以下任选其一VS Code 安装Markdown Preview Mermaid Support插件Typora 软件直接支持 Mermaid 渲染在线编辑器mermaid.live支持 Mermaid 的笔记软件如 Obsidian文档平台如语雀、飞书、GitLab/GitHub 的 Markdown 预览。推荐至少准备一种渲染方式。因为 skill 生成的是文本格式的流程图你要把它渲染成图片才能用于文档、评审和汇报。3.3 一个测试用业务场景准备一个你熟悉的业务逻辑。本文后面会用一个“用户下单”的流程做演示。你可以先想好一个自己项目里的真实场景稍后把它喂给 skill 做验证。4. 从零设计流程图生成 Skill 的完整结构在写代码之前我想先带你拆解一下这个 skill 应该长什么样。4.1 Skill 目录结构建议一个标准的流程图生成 skill目录结构可以设计成这样flowchart-skill/ ├── SKILL.md # 技能主文件定义技能行为 ├── references/ │ ├── mermaid-guide.md # Mermaid 语法速查 │ └── examples.md # 典型流程图示例 └── assets/ └── templates/ └── basic-flowchart.md # 兜底的通用模板说明一下每个部分的作用SKILL.md技能入口。AI 被唤起时首先读取这个文件它会告诉 AI 这个技能的目标、适用范围、工作流程、输出规范。references/mermaid-guide.md参考手册。AI 在生成语法不太确定的内容时可以查阅降低语法错误率。references/examples.md示例库。存放一些常见流程图的 Mermaid 示例供 AI 借鉴格式。assets/templates/basic-flowchart.md兜底模板。如果用户描述的场景比较模糊AI 可以基于模板向用户提问或补全。4.2 SKILL.md 里到底写什么这是整个 skill 的灵魂。很多技能效果不佳问题就出在这里要么写得像作文AI 抓不住重点要么写得像代码规范AI 不知道怎么用到具体场景。我建议SKILL.md按五个区块来写第一块是什么name description说明技能名字和一句话能力描述。AI 会根据这段描述判断是否应该唤起这个技能。第二块用在什么场景when to use明确技能的适用范围。例如生成业务流程、系统流程、状态流转、消息时序、用户操作流程。同时要写明不适用范围比如不适用于生成 UI 原型图。第三块怎么用workflow给出 AI 执行任务时必须遵守的步骤。这一段要具体到“先做什么、再做什么、最后做什么”。比如识别意图 - 明确流程边界 - 选择图形类型 - 套用模板 - 输出 Mermaid 代码 - 请求验证。第四块输出规范output rules定义 AI 输出结果的格式要求。包括必须用 Mermaid 语法节点命名要符合命名规范判断条件要写在节点描述中必须有开始和结束节点尽量用中文代码块必须标注语言。第五块示例examples给出一个完整的输入输出示例。AI 在执行时可以参考这个示例的格式。5. 完整示例流程生成 Skill 的代码实现下面我们直接写一个可用的最小实现。以下所有的文件路径、目录结构你都可以直接复制到自己的 skill 目录里。5.1 创建技能目录和 SKILL.md先在你的技能目录下新建flowchart-skill/SKILL.md内容如下--- name: flowchart-generator description: 根据用户提供的业务流程描述生成结构清晰、规范可渲染的 Mermaid 流程图。适用于业务流程、系统流程、状态流转、算法流程、时序交互等场景。 --- # 流程图生成技能 ## 目标 将用户的自然语言流程描述转换为规范、可渲染、结构清晰的 Mermaid 流程图代码并附带必要的使用说明。 ## 适用场景 - 业务流程订单处理、审批流、支付流程等。 - 系统流程接口调用、服务启动、异常处理流程等。 - 状态流转订单状态机、任务状态机。 - 算法/逻辑流程推荐策略、规则引擎判断。 - 时序交互多系统之间的调用顺序。 ## 不适用场景 - UI 页面原型图。 - 架构拓扑图应使用架构图专门的表达方式。 - 甘特图、饼图、雷达图等非流程图类型。 ## 工作流程 当用户请求生成流程图时按以下步骤执行 1. **识别流程类型**判断该流程属于业务流程、系统流程、状态流转还是时序交互。 2. **明确流程边界**如果用户描述中存在歧义或缺失信息先列出需要用户补充的关键问题不要直接猜测。 3. **选择图形语法** - 普通业务/系统流程使用 flowchart TD 或 flowchart LR。 - 状态流转使用 stateDiagram-v2。 - 时序交互使用 sequenceDiagram。 4. **套用模板**参考 assets/templates/basic-flowchart.md 和 references/examples.md 中的结构。 5. **生成 Mermaid 代码**将流程逻辑翻译为 Mermaid 语法注意控制节点数量超过 20 个节点时应主动拆分。 6. **输出说明**在 Mermaid 代码块之后用简短文字说明该图的阅读顺序和关键分支。 ## 输出规范 1. 必须使用 Markdown 代码块并标注语言为 mermaid。 2. 节点命名使用语义化名称例如 [处理支付]、[校验库存]、{库存充足?}。 3. 每个流程图都必须包含明确的开始节点和结束节点。 4. 判断节点使用菱形 {}普通操作使用矩形 []起止节点使用圆角矩形 ([ ])。 5. 节点文字默认使用中文。 6. 分支条件要尽量写在连线上例如 -- 是--、-- 否--。 7. 不要输出无法渲染的复杂表达式不要使用 Mermaid 不支持的语法。 8. 如果流程复杂建议拆分为多个子图 subgraph。 ## 输出结构模板 mermaid flowchart TD A([开始]) -- B[步骤1] B -- C{判断条件?} C -- 是 -- D[步骤2] C -- 否 -- E[步骤3] D -- Z([结束]) E -- Z示例用户输入请描述用户下单的流程AI 输出flowchart TD A([开始]) -- B[用户选择商品] B -- C[提交订单] C -- D{库存是否充足?} D -- 否 -- E[提示库存不足] E -- A D -- 是 -- F[创建订单] F -- G[跳转支付] G -- H{支付是否成功?} H -- 否 -- I[订单标记为待支付] I -- J[用户可继续支付或取消] H -- 是 -- K[订单确认] K -- L[通知仓库发货] L -- Z([结束])注意如果用户没有指定图形方向默认使用TD从上到下。当流程节点超过 15 个时建议用subgraph进行分组。不要生成多余的解释性文字除非用户明确要求。### 5.2 创建 Mermaid 语法速查文件 为降低 AI 生成错误语法的概率准备一个速查文件 references/mermaid-guide.md markdown # Mermaid 流程图语法速查 ## 基本形状 - 矩形普通步骤A[步骤名称] - 圆角矩形开始/结束A([开始]) - 菱形判断A{条件?} - 圆柱形数据库/存储A[(数据库)] - 子图分组subgraph 分组名 ... end ## 箭头与连线 - 默认箭头A -- B - 带文字箭头A -- 是 -- B - 虚线箭头A -.- B - 粗箭头A B ## 子图示例 mermaid flowchart TD subgraph 用户端 A[用户] -- B[提交请求] end subgraph 服务端 C[接收请求] -- D[处理逻辑] end B -- C常用指令flowchart TD从上到下布局flowchart LR从左到右布局stateDiagram-v2状态图sequenceDiagram时序图### 5.3 创建示例文件 再准备一个 references/examples.md放两个典型示例作为 AI 的少量参考 markdown # 流程图示例 ## 示例一审批流程 mermaid flowchart TD A([发起申请]) -- B[填写申请单] B -- C[提交审批] C -- D{部门经理审批} D -- 驳回 -- E[退回修改] E -- B D -- 通过 -- F{总监审批} F -- 驳回 -- E F -- 通过 -- G[审批完成] G -- Z([结束])示例二订单超时关闭stateDiagram-v2 [*] -- 待支付 待支付 -- 已支付: 支付成功 待支付 -- 已取消: 用户取消 待支付 -- 已关闭: 超时未支付 已支付 -- 已完成: 确认收货 已取消 -- [*] 已关闭 -- [*] 已完成 -- [*]### 5.4 创建兜底模板 assets/templates/basic-flowchart.md 内容如下 markdown # 基础流程图模板 适用于用户描述不够完整、需要快速输出一个基础框架的场景。 mermaid flowchart TD A([开始]) -- B[输入场景步骤1] B -- C{是否需要判断?} C -- 是 -- D[分支处理1] C -- 否 -- E[分支处理2] D -- F[后续步骤] E -- F F -- Z([结束])如果用户场景描述信息不足优先使用此模板并向用户提问流程的起点和终点分别是什么哪些环节存在分支判断是否需要区分正常流程和异常流程## 6. 实际调用让 Skill 生成真实流程图 ### 6.1 在 AI 工具中激活并调用 把上面整个 flowchart-skill 目录放到你的 AI 工具对应的技能目录后就可以直接对话。 触发方式一般有两种 - 直接说“使用流程图生成技能帮我画一个……” - 或者直接描述“帮我用流程图梳理一下用户下单的流程”工具会根据 SKILL.md 中的 description 自动匹配。 ### 6.2 演示从业务描述到流程图 我们用一段业务描述来测试 用户在小程序里选择商品后提交订单系统先校验库存。库存不足则提示用户流程结束。库存充足则创建订单跳转支付。用户支付成功订单状态变为已支付系统通知仓库发货如果支付失败或超时订单在 30 分钟后自动关闭。 skill 生成的结果大致如下 mermaid flowchart TD A([开始]) -- B[用户选择商品] B -- C[提交订单] C -- D{库存校验} D -- 不通过 -- E[提示库存不足] E -- Z([结束]) D -- 通过 -- F[创建订单] F -- G[跳转支付] G -- H{支付结果} H -- 成功 -- I[订单已支付] I -- J[通知仓库发货] J -- Z H -- 失败/超时 -- K[等待30分钟] K -- L[订单自动关闭] L -- Z注意看skill 生成的流程有几个特点节点命名是语义化的不是node1、node2判断分支都标了条件正常流程和异常流程都覆盖了开始和结束节点明确。这就是SKILL.md里输出规范起作用的结果。如果你只是随便让一个 AI 画图它大概率也会画但节点的命名、分支的表达、异常分支的覆盖都不可控。6.3 渲染与验证生成 Mermaid 代码后把它粘贴到支持 Mermaid 渲染的编辑器中就能看到图形。我建议的验证路径是先复制 Mermaid 代码到mermaid.live确认能正常渲染对照你的业务描述检查分支是否完整重点确认正常路径是否走通、异常路径是否覆盖、结束节点是否明确。第 2 步和第 3 步其实是这个流程中最有价值的工作。AI 把草图画出来你来判断逻辑对不对这正好回到前面说的人负责判断AI 负责绘制。6.4 如何判断技能生效如果你执行完以上步骤发现 AI 输出的内容明显符合规范、节点命名语义化、分支条件清晰说明 skill 已经正确加载。如果输出结果和普通对话没有区别那要回到技能目录的存放位置检查是否被工具正确识别。7. 常见问题与排查思路在实际使用这个 skill 的过程中下面这几个问题最常出现。问题现象可能原因排查方式解决方案AI 没有按 skill 规范输出技能没有被正确加载检查技能目录是否放在工具识别的路径检查SKILL.md的name和description是否清晰调整目录位置在对话中明确要求“使用 flowchart-generator 技能”Mermaid 代码渲染失败使用了不支持的语法把代码粘贴到 mermaid.live查看报错信息用基础语法重写对照references/mermaid-guide.md检查流程节点太多图很乱没有对复杂流程做拆分检查是否使用subgraph对节点进行分组SKILL.md工作流程中要求超过 20 个节点要拆分精简节点或增加子图分组分支条件没有标识输出规范约束不够强检查SKILL.md中是否明确写了“判断分支必须带条件文字”在输出规范中加强表达并在示例中多给带分支条件的示例生成的是文字描述而不是图技能识别失败走了普通对话通道查看工具日志或对话上下文使用显式触发词比如“调用流程图技能”中文节点在某些主题下显示异常Mermaid 渲染主题对中文支持不佳查看本地渲染器配置使用较新的渲染器或调整主题字体8. 最佳实践与工程建议8.1 让 skill 的“输出规范”始终优先一个 skill 的效果好不好80% 取决于输出规范写得好不好。每次你发现 AI 产出的流程不符合预期不要想着在对话里补充一句“下次注意”那是对付不了下一次的。正确的做法是把这次的教训写回SKILL.md的输出规范中。比如你希望 AI 永远用“动词 宾语”命名节点而不是用名词短语那就在输出规范里加一条并配一个正反示例。Skill 文件越用越贴合你的团队习惯。8.2 流程拆分的三个程度使用复杂流程时我建议按下面这个原则拆分少于 8 个节点一个流程图直接画。8 到 20 个节点用subgraph分块按业务阶段分组。超过 20 个节点不要试图一个图画完。拆成主流程图 若干子流程图分别生成。不要在SKILL.md里写死“超过 20 就拆”可以写成“超过 20 个节点时先输出主流程概览再按关键子模块分别输出详图”。这样的输出更适合实际评审场景。8.3 流程图要覆盖异常路径新手画图最容易漏掉异常分支。业务流程图里最常见的异常包括库存不足支付超时接口调用失败幂等冲突用户取消超额重试。建议在SKILL.md的适用场景里加一条如果用户描述中没有提到异常情形在生成前先询问是否有异常分支需要覆盖。这样能减少后续返工。8.4 善用 markdown 内嵌渲染即使不用任何专业绘图软件你的代码仓库本身就能渲染 Mermaid。把生成的流程图写进项目的docs/目录用 Markdown 文件保存提交到 Git 仓库后团队里每个人都能在代码托管平台上直接查看。这比导出一张 PNG 再发到群里要清晰得多而且天然版本可控。我特别推荐一个实践在每个核心业务模块的README.md中放一张主流程图。这样后来者看代码前先看流程图建立全局认知可以大幅减少沟通成本。8.5 把 skill 纳入团队维护如果整个团队都在用同一个 skill建议把它当作代码仓库里的一个子项目来维护。变更要记录 changelog示例要定期增补。特别是examples.md项目里每出现一个典型的复杂流程就把它沉淀为一个示例。时间越长skill 对团队业务的贴合度越高。9. 对实际项目的一点提醒最后说几个真话。这个 skill 不是万能的。它最擅长的是“把已经想清楚的逻辑快速变成一张规范、美观、可维护的图”。如果你自己都没有想清楚流程期望 AI 帮你“梳理”出逻辑效果往往不理想。AI 能帮你确定的大多是你已经隐含表达出来的内容它不会替你做业务决策。另外流程图生成 skill 生成的始终是“给别人看”的交付物。真正值钱的永远是你对业务的判断、对边界的定义、对异常情况的覆盖。这些判断能力不是工具能代替的。但如果你已经完成了思考只想快点把脑子里的流程变成一张拿得出手的图那这个 skill 能帮你把时间从半小时压缩到三分钟。建议你现在就做三件事把文章里的SKILL.md复制到你的 skill 目录找一个最近刚写完的模块用这个 skill 生成一张流程图把SKILL.md里的示例替换成你们团队自己的业务案例。用不了几次你就会发现画流程图这件事真的可以不用“手搓”了。