以前我画流程图的方式非常原始打开 draw.io拖一个矩形填“用户登录”再拖一个菱形改判断条件然后拉线、对齐、调颜色。一张最简单的登录流程经常要花二十分钟。改流程的时候更崩溃加一个分支所有箭头和位置全乱。后来我在某个 AI 编程工具里用到了 skill让 AI 按我定义的规则直接生成流程图稿件这件事才真正开始变简单。这里说的 skill不是某个绘图网站的付费模板也不是传统意义上的“宏”或“插件”而是 AI Agent 流行起来之后的一种结构化能力包。你可以在 Claude Code、Codex、OpenCode 这类工具里看到 skill 的目录一个文件夹里面有一个SKILL.md再配一些示例、模板或参考文件。它的作用是告诉 AI遇到这一类任务时不要自由发挥先按照这几步来做。如果把这个思路用在流程图上效果就是你只需要把业务过程用自然语言说完AI 会按你定义的格式直接生成 Mermaid、draw.io XML 或带说明文字的流程图稿件。你不用再打开绘图工具一层一层拖节点。但这里有一个容易被误解的地方skill 真正解决问题的不是“画得比人快”而是把流程图的“设计”和“绘制”两件事拆开了。后面所有内容都围绕这个判断展开。1. 先搞清楚 skill 到底解决的是哪一类流程问题1.1 skill 的本质给 AI 一套执行说明书前两年大家提“提示词工程”核心是把写 prompt 这件事做得更结构化。但 prompt 依然是对话的一部分每次对话都要重复。skill 不太一样它不是一条临时指令而是一个独立的能力模块通常以目录和文件的形式存放在项目里。AI 遇到匹配场景时会主动加载这个模块并按里面的步骤执行。这对流程图的帮助非常明显。假设你直接对 AI 说“帮我画一个用户管理模块流程图”模型会按通用知识自由发挥输出的可能是一段文字可能是 Markdown 表格甚至可能是一段不完整的 Mermaid。几次输出的风格很难一致。但如果配置了一个 flowchart skillAI 会先读取 skill 里的步骤和示例知道用户要的是可编辑流程图知道先提取流程元素知道用 Mermaid 还是 draw.io XML。这很像给新人一份工作手册而不是让他每次凭感觉干活。我习惯把 skill 理解成“给 AI 的执行说明书”。它至少包含三块内容什么时候用、按什么步骤做、输出成什么样。对于流程图这种强结构化任务这三块内容刚好能解决“AI 画不好”的绝大多数原因。1.2 为什么普通对话画流程图不稳定但 skill 可以普通对话不是完全不能画流程图。对一些简单场景直接说“用 Mermaid 画一个登录流程”模型大概率能给出不错的结果。问题在于稳定性和可维护性。你可以从这两个维度看维度普通 prompt使用 skill输出格式有时代码块有时文字有时表格固定要求代码块和指定格式处理步骤凭模型自由发挥可能漏掉分支强制先提取节点、判断、路径再输出示例约束没有示例靠模型理解可以内置多个示例长期维护每次都要重新写 prompt只改目录里的 SKILL.md可复用性无法复用更换场景就失效跨任务、跨文档复用也就是说skill 相当于把零散对话里的有效经验沉淀成了固定规则。流程图任务本质上是高结构化的它要求模型先理解流程元素再安排节点关系最后检查是否缺少起点、终点或分支。普通单轮 prompt 很难把每个环节都约束好。skill 等于把这些环节固化成了“规则”而不是依赖对话上下文里的偶然提示。当然skill 不是万能药。如果模型本身不具备分支判断和步骤组织能力即使给了 skill 也帮助有限。但从工程经验看绝大多数“AI 画得乱”的问题不是模型能力不够而是规则没有定清楚。这也是我为什么建议把 skill 当作一套可迭代的规则文件来维护而不是写一次就再也不改。2. 流程图 skill 的关键不是画图而是输入、输出和工作流2.1 先定义输入用户会怎么描述流程在写 skill 之前先想清楚一个问题用户会怎么向 AI 描述一个流程同样是“画流程图”真实需求可以分几类业务描述型“用户登录后进入首页登录失败就提示错误并返回登录页。”算法描述型“用 for 循环求 1 到 100 的累加和输出每次中间结果。”系统模块型“用户管理模块包括用户列表、新增、编辑、禁用、权限管理。”教学讲解型“用流程图说明反向传播算法的工作原理。”这些输入需要的处理方式不一样。业务描述更关注分支和返回路径算法描述更关注循环、条件和退出条件系统模块更关注模块间的调用关系教学讲解更关注从简到繁的层次结构。如果 skill 不区分这些AI 很容易用一个模板套所有需求。所以流程图 skill 的第一步不是培训“输出格式”而是定义“怎么理解输入”。比较稳妥的做法是先让 AI 提取节点和连线包括起点、终点、处理步骤、判断条件、返回路径、可选分支。如果信息不足不要猜太多直接输出一个带有占位符的默认结构同时列出缺失信息让用户补充。在我的使用经验里“先出一个可修改的初稿再逐步补全”比“反复追问”更实用。2.2 再定义输出Mermaid、draw.io XML、PlantUML 怎么选流程图 skill 的输出是核心。你可以在同一个 skill 里支持多种格式但我建议在早期版本中只选择一种跑通后再扩展。下面是我常用的选型判断格式优势适用场景注意事项Mermaid文本短、可 diff、支持 Markdown 渲染快速产出初稿、放在文档仓库复杂布局容易乱分支多时要控制节奏draw.io XML可编辑、可导入桌面工具需要二次编辑、团队协作XML 内容长AI 可能生成不完整文件PlantUML适合时序图、状态机、部署图已有 PlantUML 技术栈的团队流程图不是它的最大优势如果只是画流程并放到 Markdown 文档里我建议默认选 Mermaid。Mermaid 有很强的类型提示语法简单代码块可以直接渲染。复杂流程超过 20 个节点时Mermaid 的布局会显得拥挤但第一版够用。如果需要给别人继续编辑或团队统一使用 draw.io那就让 skill 输出 draw.io XML。draw.io 有桌面版、网页版和在线版AI 生成的 XML 并不保证百分之百有效所以最好在 skill 的规则里明确要求“最终必须给出一个可以被 draw.io 打开的 XML 片段”并在描述中附一个最小可用的 XML 模板。这样做不是为了让 AI 学会画图而是为了让它在生成时有一个可以对照的坐标和 id 结构。2.3 skill 和 MCP 到底怎么配合和 skill 经常一起出现的一个词是 MCP。很多人会把它们混在一起。一个简单的区分是skill 是“方法和步骤”MCP 是“外部工具和接口”。skill 决定 AI 怎么做MCP 决定 AI 能调什么资源。可以这样理解skill 是菜谱MCP 是厨房里的炉灶、冰箱和食材采购通道。菜谱规定做菜的步骤但如果你需要从冰柜里拿食材就得通过接口去取。对应到流程图场景如果只是在对话里把业务流程转换成 Mermaid不需要 MCP但如果流程数据来自数据库表结构或者需要读取某个在线文档AI 就必须通过 MCP 去访问这些外部资源。这不是替代关系而是叠加关系。实际落地时你可能先有一个“读数据库表结构”的 MCP 服务再配一个“把表结构整理成用户管理模块流程图”的 skill。skill 保证输出风格一致MCP 提供输入数据。两个一起用效果才稳定。3. 从零写一个 flowchart skill 的完整步骤3.1 准备目录和 SKILL.md 的基本结构开始之前先确认一件事你使用的 AI 编程工具或 Agent 框架支持哪种 skill 规范。不同工具对 SKILL.md 的字段、目录位置、加载方式的定义不同。下面是通用结构可以作为起步参考。flowchart-designer/ ├── SKILL.md ├── examples/ │ ├── login.mermaid │ └── user-manage.draw 用AI Skill让流程图生成更稳定：从SKILL.md到Mermaid实践
以前我画流程图的方式非常原始打开 draw.io拖一个矩形填“用户登录”再拖一个菱形改判断条件然后拉线、对齐、调颜色。一张最简单的登录流程经常要花二十分钟。改流程的时候更崩溃加一个分支所有箭头和位置全乱。后来我在某个 AI 编程工具里用到了 skill让 AI 按我定义的规则直接生成流程图稿件这件事才真正开始变简单。这里说的 skill不是某个绘图网站的付费模板也不是传统意义上的“宏”或“插件”而是 AI Agent 流行起来之后的一种结构化能力包。你可以在 Claude Code、Codex、OpenCode 这类工具里看到 skill 的目录一个文件夹里面有一个SKILL.md再配一些示例、模板或参考文件。它的作用是告诉 AI遇到这一类任务时不要自由发挥先按照这几步来做。如果把这个思路用在流程图上效果就是你只需要把业务过程用自然语言说完AI 会按你定义的格式直接生成 Mermaid、draw.io XML 或带说明文字的流程图稿件。你不用再打开绘图工具一层一层拖节点。但这里有一个容易被误解的地方skill 真正解决问题的不是“画得比人快”而是把流程图的“设计”和“绘制”两件事拆开了。后面所有内容都围绕这个判断展开。1. 先搞清楚 skill 到底解决的是哪一类流程问题1.1 skill 的本质给 AI 一套执行说明书前两年大家提“提示词工程”核心是把写 prompt 这件事做得更结构化。但 prompt 依然是对话的一部分每次对话都要重复。skill 不太一样它不是一条临时指令而是一个独立的能力模块通常以目录和文件的形式存放在项目里。AI 遇到匹配场景时会主动加载这个模块并按里面的步骤执行。这对流程图的帮助非常明显。假设你直接对 AI 说“帮我画一个用户管理模块流程图”模型会按通用知识自由发挥输出的可能是一段文字可能是 Markdown 表格甚至可能是一段不完整的 Mermaid。几次输出的风格很难一致。但如果配置了一个 flowchart skillAI 会先读取 skill 里的步骤和示例知道用户要的是可编辑流程图知道先提取流程元素知道用 Mermaid 还是 draw.io XML。这很像给新人一份工作手册而不是让他每次凭感觉干活。我习惯把 skill 理解成“给 AI 的执行说明书”。它至少包含三块内容什么时候用、按什么步骤做、输出成什么样。对于流程图这种强结构化任务这三块内容刚好能解决“AI 画不好”的绝大多数原因。1.2 为什么普通对话画流程图不稳定但 skill 可以普通对话不是完全不能画流程图。对一些简单场景直接说“用 Mermaid 画一个登录流程”模型大概率能给出不错的结果。问题在于稳定性和可维护性。你可以从这两个维度看维度普通 prompt使用 skill输出格式有时代码块有时文字有时表格固定要求代码块和指定格式处理步骤凭模型自由发挥可能漏掉分支强制先提取节点、判断、路径再输出示例约束没有示例靠模型理解可以内置多个示例长期维护每次都要重新写 prompt只改目录里的 SKILL.md可复用性无法复用更换场景就失效跨任务、跨文档复用也就是说skill 相当于把零散对话里的有效经验沉淀成了固定规则。流程图任务本质上是高结构化的它要求模型先理解流程元素再安排节点关系最后检查是否缺少起点、终点或分支。普通单轮 prompt 很难把每个环节都约束好。skill 等于把这些环节固化成了“规则”而不是依赖对话上下文里的偶然提示。当然skill 不是万能药。如果模型本身不具备分支判断和步骤组织能力即使给了 skill 也帮助有限。但从工程经验看绝大多数“AI 画得乱”的问题不是模型能力不够而是规则没有定清楚。这也是我为什么建议把 skill 当作一套可迭代的规则文件来维护而不是写一次就再也不改。2. 流程图 skill 的关键不是画图而是输入、输出和工作流2.1 先定义输入用户会怎么描述流程在写 skill 之前先想清楚一个问题用户会怎么向 AI 描述一个流程同样是“画流程图”真实需求可以分几类业务描述型“用户登录后进入首页登录失败就提示错误并返回登录页。”算法描述型“用 for 循环求 1 到 100 的累加和输出每次中间结果。”系统模块型“用户管理模块包括用户列表、新增、编辑、禁用、权限管理。”教学讲解型“用流程图说明反向传播算法的工作原理。”这些输入需要的处理方式不一样。业务描述更关注分支和返回路径算法描述更关注循环、条件和退出条件系统模块更关注模块间的调用关系教学讲解更关注从简到繁的层次结构。如果 skill 不区分这些AI 很容易用一个模板套所有需求。所以流程图 skill 的第一步不是培训“输出格式”而是定义“怎么理解输入”。比较稳妥的做法是先让 AI 提取节点和连线包括起点、终点、处理步骤、判断条件、返回路径、可选分支。如果信息不足不要猜太多直接输出一个带有占位符的默认结构同时列出缺失信息让用户补充。在我的使用经验里“先出一个可修改的初稿再逐步补全”比“反复追问”更实用。2.2 再定义输出Mermaid、draw.io XML、PlantUML 怎么选流程图 skill 的输出是核心。你可以在同一个 skill 里支持多种格式但我建议在早期版本中只选择一种跑通后再扩展。下面是我常用的选型判断格式优势适用场景注意事项Mermaid文本短、可 diff、支持 Markdown 渲染快速产出初稿、放在文档仓库复杂布局容易乱分支多时要控制节奏draw.io XML可编辑、可导入桌面工具需要二次编辑、团队协作XML 内容长AI 可能生成不完整文件PlantUML适合时序图、状态机、部署图已有 PlantUML 技术栈的团队流程图不是它的最大优势如果只是画流程并放到 Markdown 文档里我建议默认选 Mermaid。Mermaid 有很强的类型提示语法简单代码块可以直接渲染。复杂流程超过 20 个节点时Mermaid 的布局会显得拥挤但第一版够用。如果需要给别人继续编辑或团队统一使用 draw.io那就让 skill 输出 draw.io XML。draw.io 有桌面版、网页版和在线版AI 生成的 XML 并不保证百分之百有效所以最好在 skill 的规则里明确要求“最终必须给出一个可以被 draw.io 打开的 XML 片段”并在描述中附一个最小可用的 XML 模板。这样做不是为了让 AI 学会画图而是为了让它在生成时有一个可以对照的坐标和 id 结构。2.3 skill 和 MCP 到底怎么配合和 skill 经常一起出现的一个词是 MCP。很多人会把它们混在一起。一个简单的区分是skill 是“方法和步骤”MCP 是“外部工具和接口”。skill 决定 AI 怎么做MCP 决定 AI 能调什么资源。可以这样理解skill 是菜谱MCP 是厨房里的炉灶、冰箱和食材采购通道。菜谱规定做菜的步骤但如果你需要从冰柜里拿食材就得通过接口去取。对应到流程图场景如果只是在对话里把业务流程转换成 Mermaid不需要 MCP但如果流程数据来自数据库表结构或者需要读取某个在线文档AI 就必须通过 MCP 去访问这些外部资源。这不是替代关系而是叠加关系。实际落地时你可能先有一个“读数据库表结构”的 MCP 服务再配一个“把表结构整理成用户管理模块流程图”的 skill。skill 保证输出风格一致MCP 提供输入数据。两个一起用效果才稳定。3. 从零写一个 flowchart skill 的完整步骤3.1 准备目录和 SKILL.md 的基本结构开始之前先确认一件事你使用的 AI 编程工具或 Agent 框架支持哪种 skill 规范。不同工具对 SKILL.md 的字段、目录位置、加载方式的定义不同。下面是通用结构可以作为起步参考。flowchart-designer/ ├── SKILL.md ├── examples/ │ ├── login.mermaid │ └── user-manage.draw