用 Skill 让 AI 直接生成 draw.io 流程图：从零手写指南

自从 AI 编程助手越来越像“团队里的实习生”之后我发现一个尴尬的矛盾你让它写代码它写得很积极你让它画流程图它却总在“给你一段 Mermaid 代码”和“给你一段文字描述”之间反复横跳。最后你还是要打开 draw.io一顿拖拽、对齐、改箭头半小时过去了。这个问题的本质不是 AI 不会画流程图而是它不知道你的交付标准是什么。你要的是“能直接导入 draw.io 再编辑的 XML 文件”它默认理解成“在聊天框里描述一下流程”。解决这个认知差靠的不是每次重新叮嘱而是给它一份“画流程图的说明书”。在 Claude Code、Codex 这类支持 Skill 的编程助手里这份说明书可以做成一个 Skill。有了它你只需要说清楚业务流程AI 就能直接产出一个结构正确、命名规范、导入即用的 draw.io 文件。这篇文章就从零讲清楚Skill 到底是什么为什么画流程图适合用 Skill 来解决以及如何手写一个属于自己的“流程图 Skill”。1. 画流程图这件事到底难在哪里流程图本身不是一个高门槛任务。画过业务流程图、技术架构图的人都知道真正的耗时点往往不在“逻辑设计”而在“工具操作”和“格式调整”。1.1 手工拖拽的隐性成本在 draw.io 或 Visio 里画一张 10 步的业务流程图常规操作是拖一个开始节点、拖几个步骤节点、拖一个判断节点、手动连线、调整箭头方向、修改文字大小、再统一对齐。这些操作本身不复杂但非常琐碎。画完第一版之后业务方说“第三步和第四步顺序反了”你又得重新拖线、调整布局。这种“手工感”正是标题里说的“手搓”。它不是技术难题却是时间黑洞。1.2 让 AI 直接画为什么总是不满意如果你尝试过直接对 AI 说“帮我画一个用户登录流程图”大概率会得到一个 Mermaid 代码块。看过程、理逻辑没问题但如果要交付到设计文档、评审 PPT、项目 Wiki 里就会遇到几个现实问题团队协作工具不一定支持 Mermaid 渲染或者渲染样式和公司统一模板不一致Mermaid 的布局控制相对有限分支多的时候生成结果经常挤在一起你希望流程图中带团队统一的节点颜色、判断形状、命名规则通用生成结果做不到。如果换一种要求让 AI 直接输出 draw.io 的 XML 格式它又会经常出错节点坐标互相重叠、边的 source 和 target 引用不存在的节点、中文字体显示异常。原因很简单draw.io 的 XML 结构对格式要求很高模型如果没有明确的格式约束自由发挥的成功率并不高。1.3 团队规范才是真正的隐形门槛单张流程图怎么画都行但一个团队里的流程图通常需要保持基本的风格统一开始结束用椭圆、业务操作用圆角矩形、判断用菱形、颜色体系一致、节点命名规范。这些要求很难通过一句提示词固定下来。正因为如此画流程图这件事特别适合用 Skill 来解决。Skill 能承载的不只是“生成流程图的提示词”而是一整套“输入要求 节点规范 输出格式 校验规则”。2. Skill 到底是什么它不是技能是操作说明书Skill 这个概念在 Claude Code、Codex 等编程助手里越来越常出现。但很多人对它的理解存在偏差。2.1 一个容易误解的概念第一次听说 Skill 的人往往会把它理解成一个“外挂能力”好像装上之后 AI 就突然会做某件事了。这个理解不准确。实际上Skill 是一个结构化的指令包通常表现为一个目录里面核心文件叫 SKILL.md。这个文件里写清楚了完成某类任务需要遵循什么步骤、输出格式是什么、有什么注意点、有哪些示例可以参考。它本质上是给 AI 模型的一份“操作说明书”。比如你有一个“代码审查 Skill”那么 SKILL.md 里会写审查哪些维度、代码规范重点看什么、发现的问题按什么格式输出、每个问题应该给出什么级别的修复建议。模型读到这份说明书后就会按照里面的规则去执行。2.2 Skill 与普通 Prompt 的区别很多人会觉得既然 Skill 本质是说明书那为什么不直接在对话里写一段很长的提示词区别在于两点。第一普通 Prompt 是一次性的。每次要用你都得重新写一遍或者从收藏夹里复制粘贴。Skill 是文件化的放在指定目录后编程助手启动时会自动扫描。当用户任务与 Skill 的 description 匹配时模型会自动读取对应文件并遵循其中规则。这意味着你可以把团队规范沉淀成一个文件而不是靠每个人手打提示词。第二普通 Prompt 缺少结构。Skill 可以包含一个完整的工作流比如先让用户补充信息、再按节点规范生成、最后用脚本校验 XML 合法性。这些东西写在一个结构化文档里比一段 Prompt 更可靠、更可维护。2.3 Skill、MCP 与普通 Prompt 的对比概念解决什么问题形态典型使用方式普通 Prompt单次对话的任务指导聊天输入文字每次输入完整要求Skill将某类任务的操作流程固化下来目录 SKILL.md编程助手自动匹配并加载MCP标准化 AI 与外部工具、数据源的连接服务端 客户端协议通过协议调用外部能力MCP 和 Skill 经常被放在一起讨论但它们不在同一层。MCP 更像是“USB 接口”解决的是 AI 如何标准化地连接外部工具Skill 更像“说明书”解决的是 AI 如何按照既定流程完成一件事。在实际场景中两者可以配合使用Skill 定义工作流程MCP 提供流程中需要调用的外部能力。3. Skill 画流程图的原理把画图规范变成文件约定理解了 Skill 的本质再来看它为什么适合画流程图。3.1 流程图的本质是节点加边任何一张流程图底层数据结构都很简单节点代表步骤或判断边代表流转关系。对于 AI 来说理解“用户输入账号密码”是一个步骤“校验是否通过”是一个判断这并不困难。困难的是把这种理解转化成目标工具能识别的文件格式。3.2 draw.io 为什么适合作为交付格式目前常见的文本绘图方案有 Mermaid、Graphviz 等它们各有长处但从“可编辑、可交付、团队协作”的角度看draw.io 的 XML 格式有一个明显优势它本身就是图表编辑器的原生格式。这意味着AI 生成的 draw.io XML 文件你可以直接右键用 draw.io 打开继续手动调整。它不像 Mermaid 那样只能重新渲染也不像图片那样无法编辑。该改文字改文字该拖位置拖位置完全无缝衔接。更重要的是draw.io XML 是纯文本格式适合 AI 生成也适合用脚本校验。这让“AI 生成文件”和“人工继续编辑”两个环节可以顺利衔接。3.3 三种绘图方案对比方案优点缺点适合场景Mermaid语法简单生成快布局控制弱团队定制麻烦快速预览、文档内嵌Graphviz布局算法强大自动排版dot 语法有学习成本样式偏向技术风复杂 DAG、依赖关系图draw.io XML原生可编辑团队协作成熟XML 冗长手写成本高交付给设计评审、项目 Wiki从表格可以看出draw.io 的缺点恰好是 AI 的强项。XML 冗长模型生成无所谓人工手写麻烦但模型可以直接输出。这也是“用 Skill 画流程图”最有价值的组合AI 负责生成格式繁琐的 XML人只负责确认业务逻辑。3.4 Skill 在画流程图时的工作过程一个画图 Skill 的工作过程大致是编程助手扫描到用户请求与 Skill 的 description 匹配模型读取 SKILL.md获得节点规范、输出格式、示例文件模型根据用户提供的流程描述按规范生成 draw.io XML 文件可选地执行校验脚本检查 XML 是否合法、边引用是否有效用户拿到文件直接导入 draw.io 查看和继续编辑。这里真正关键的一步是第三步。模型是否按要求输出取决于 SKILL.md 中对输出格式的约束有多具体。约束越明确生成成功率越高。4. 从零写一个画流程图的 Skill下面开始动手。我们以一个“用户登录流程”为例写一个名为 drawio-flowchart 的 Skill。4.1 Skill 的整体目标这个 Skill 要做到用户描述一个业务流程AI 按照固定的节点规范生成一个结构完整、可直接打开编辑的 draw.io XML 文件。设计目标包括流程节点分为开始、结束、业务步骤、判断四类节点 id 使用 step1、step2 这种顺序命名便于维护使用中文 label 保持可读性生成的 XML 必须能被 draw.io 正常打开所有连线必须引用真实存在的节点 id。4.2 Skill 目录结构以 Claude Code 为例一个 Skill 通常是一个目录目录名是 Skill 名称里面必须包含 SKILL.md 主文件还可以有 examples 目录放示例文件、scripts 目录放辅助脚本。.claude/skills/drawio-flowchart/ ├── SKILL.md ├── examples/ │ └── user-login.drawio └── scripts/ └── check_drawio_xml.py建议将 Skill 放在项目级目录.claude/skills/下这样团队每个成员拉取代码后都能使用同一个 Skill。4.3 SKILL.md 完整内容SKILL.md 是 Skill 的核心。它需要包含 frontmatter 元信息和正文规则。frontmatter 里的 name 和 description 会被编程助手用来建立技能索引因此 description 要尽量准确描述 Skill 的用途方便模型自动匹配。--- name: drawio-flowchart description: 根据用户描述的流程生成 draw.io 流程图 XML 文件输出可直接导入 draw.io 编辑 --- # Drawio 流程图生成 当用户要求“画流程图”“生成流程图”“做个流程说明图”时使用本 Skill。 ## 输入要求 1. 先确认流程中的关键节点开始节点、结束节点、业务步骤、判断节点。 2. 如果用户描述缺少判断条件或分支先按步骤序号向用户确认。 3. 默认使用纵向布局如果业务步骤超过 8 个改为横向布局。 ## 节点规范 - 开始/结束节点使用 shapeellipseid 命名为 step1、stepN。 - 业务步骤节点使用 shaperoundedid 按顺序命名为 step2、step3... - 判断节点使用 shaperhombus并在 label 中写明判断条件。 - 所有 label 使用中文必须完整表达动作例如“输入账号密码”而不是“输入信息”。 - 每条边必须指定 source 和 target且引用真实存在的节点 id。 ## 输出格式 1. 直接输出 drawio 可识别的 XML 文件不要输出解释文字。 2. XML 以 mxfile 为根元素内部包含 diagram 和 mxGraphModel。 3. 所有节点使用 mxCellvertex1边使用 mxCelledge1。 4. 输出完成后提示用户已生成 drawio 文件可导入 draw.io 查看并编辑。这里“输出格式”部分是整个 SKILL.md 的关键。它没有让 AI 自由发挥而是把 XML 的根元素、节点属性、边引用规则都固定下来。模型按规则生成出错概率会大幅下降。4.4 输出示例drawio XML 长什么样为了让模型更好地模仿输出格式SKILL.md 里的规则只能解决“怎么写”示例文件负责解决“写出来什么效果”。实际使用中SKILL.md 可以引用 examples 目录下的文件作为参考。下面是一个简化但完整的“用户登录流程” drawio XML 示例。mxfile hostapp.diagrams.net diagram iduser-login name用户登录流程 mxGraphModel dx800 dy600 grid1 gridSize10 guides1 tooltips1 connect1 arrows1 fold1 page1 pageScale1 pageWidth827 pageHeight1169 root mxCell id0 / mxCell id1 parent0 / mxCell idstep1 value开始 styleellipse;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x320 y40 width120 height60 asgeometry / /mxCell mxCell idstep2 value输入账号密码 stylerounded;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x300 y160 width160 height60 asgeometry / /mxCell mxCell idstep3 value校验账号密码 stylerhombus;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x310 y290 width140 height80 asgeometry / /mxCell mxCell idstep4 value登录成功进入系统 stylerounded;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x310 y440 width160 height60 asgeometry / /mxCell mxCell idstep5 value提示账号或密码错误 stylerounded;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x100 y440 width160 height60 asgeometry / /mxCell mxCell idstep6 value结束 styleellipse;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x320 y580 width120 height60 asgeometry / /mxCell mxCell idedge1 styleedgeStyleorthogonalEdgeStyle;rounded0; edge1 sourcestep1 targetstep2 parent1 mxGeometry relative1 asgeometry / /mxCell mxCell idedge2 styleedgeStyleorthogonalEdgeStyle;rounded0; edge1 sourcestep2 targetstep3 parent1 mxGeometry relative1 asgeometry / /mxCell mxCell idedge3 styleedgeStyleorthogonalEdgeStyle;rounded0; edge1 sourcestep3 targetstep4 parent1 mxGeometry relative1 asgeometry / /mxCell mxCell idedge4 styleedgeStyleorthogonalEdgeStyle;rounded0; edge1 sourcestep3 targetstep5 parent1 mxGeometry relative1 asgeometry / /mxCell mxCell idedge5 styleedgeStyleorthogonalEdgeStyle;rounded0; edge1 sourcestep4 targetstep6 parent1 mxGeometry relative1 asgeometry / /mxCell /root /mxGraphModel /diagram /mxfile这个 XML 示例包含 6 个节点和 5 条边。节点用 mxCell 定义id 是 step1 到 step6边的 source 和 target 都指向真实存在的节点 id。你可以把这段 XML 保存成.drawio文件直接拖进浏览器打开看到的就是一个完整的登录流程。实际使用时可以让 AI 参考这个示例用户只需要描述流程步骤即可。4.5 可选校验脚本XML 是结构化的因此可以用脚本自动校验。这个小工具脚本检查每个边的 source 和 target 是否都能在节点中找到避免生成无效的引用。# 文件路径.claude/skills/drawio-flowchart/scripts/check_drawio_xml.py import sys import xml.etree.ElementTree as ET def validate_drawio(file_path): try: tree ET.parse(file_path) except ET.ParseError as exc: print(fXML 解析失败: {exc}) sys.exit(1) root tree.getroot() cells root.findall(.//mxCell) vertex_ids set() edges [] for cell in cells: cell_id cell.get(id) if cell.get(vertex) 1: vertex_ids.add(cell_id) if cell.get(edge) 1: source cell.get(source) target cell.get(target) edges.append((source, target)) missing_refs set() for source, target in edges: if source not in vertex_ids: missing_refs.add(source) if target not in vertex_ids: missing_refs.add(target) if missing_refs: print(以下节点引用未定义:, missing_refs) sys.exit(1) print(f校验通过共找到 {len(vertex_ids)} 个节点{len(edges)} 条边引用全部有效。) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python check_drawio_xml.py 文件路径) sys.exit(1) validate_drawio(sys.argv[1])这个脚本在生成文件后运行一次如果输出“校验通过”就说明 XML 结构基本可用。当然它能校验的是引用关系不能保证图形布局完美但已经能挡住大部分低级错误。5. 安装 Skill 并接入编程助手Skill 写好后需要放到编程助手能扫描到的目录里。不同工具的具体路径可能不同但思路一致个人级技能放在用户目录项目级技能放在项目目录。5.1 安装位置项目级还是用户级项目级 Skill 放在项目的.claude/skills/目录下跟随项目代码一起提交到 Git 仓库。这样团队其他成员 clone 代码后会自动拥有同一个 Skill适合团队规范统一。用户级 Skill 放在~/.claude/skills/目录下仅对当前用户生效适合个人习惯或跨项目复用的技能。5.2 具体操作命令以 Claude Code 为例安装 drawio-flowchart Skill 的命令如下。# 项目级 Skill推荐用于团队协作 mkdir -p .claude/skills/drawio-flowchart cp SKILL.md .claude/skills/drawio-flowchart/ cp -r examples .claude/skills/drawio-flowchart/ cp -r scripts .claude/skills/drawio-flowchart/ # 用户级 Skill适合个人通用技能 mkdir -p ~/.claude/skills/drawio-flowchart cp SKILL.md ~/.claude/skills/drawio-flowchart/ cp -r examples ~/.claude/skills/drawio-flowchart/ cp -r scripts ~/.claude/skills/drawio-flowchart/如果是项目级 Skill建议在项目 README 中写清楚每个 Skill 的用途避免后续维护时出现“不知道这个目录是哪来的”的情况。5.3 如何使用这个 SkillSkill 装好之后不需要额外命令行参数。直接在对话中提需求即可。比如请用 drawio-flowchart 画一个用户登录流程图 用户输入账号密码系统校验如果校验通过则进入系统否则提示错误并返回重新输入。编程助手会根据你的描述先扫描匹配的 Skill再读取 SKILL.md 中的规则最后按照规则生成 drawio XML 文件。需要特别说明的是生成结果可能不是一次性完美的。如果节点坐标重叠直接在 draw.io 里微调即可如果流程分支不对就继续补充描述让模型重新生成。这也是选择 draw.io 作为交付格式的好处人的最终编辑成本极低。5.4 验证 Skill 是否被加载判断 Skill 是否被正确加载最直接的方式是看输出结果。如果 AI 返回的是普通文字描述而不是 drawio XML 文件说明 Skill 没有被匹配到。此时可以检查文件名是否叫 SKILL.md大小写是否正确frontmatter 中是否包含 name 和 description目录是否落在编程助手扫描的 skills 目录下description 是否覆盖了你刚才的请求描述。如果以上都正常可以尝试在对话中更明确地提到“请使用 drawio-flowchart Skill”让匹配更容易命中。6. 运行结果与效果验证走完整个流程后你需要确认产出的文件真的可用。6.1 预期输出是什么正常情况下编程助手会输出一段 drawio XML 内容并提示“已生成 drawio 文件可导入 draw.io 查看并编辑”。你把这个 XML 保存为login.drawio文件然后用浏览器打开 draw.io选择 File - Open就能看到流程图。6.2 验证流程建议按以下顺序检查用文本编辑器打开生成的.drawio文件确认根元素是 mxfile在 draw.io 中打开文件确认没有报错检查节点数量是否与业务步骤一致检查判断节点的分支是否有对应的出口边如果有脚本运行python check_drawio_xml.py login.drawio检查引用关系。如果以上检查都通过说明这个 Skill 已经可以正常工作。6.3 失败信号与第一反应如果生成的 XML 在 draw.io 中打开是空白先不要怀疑 Skill 写得有问题而是先检查文件是否保存为 UTF-8 编码以及内容是否被编程助手截断。截断是常见问题尤其是流程步骤较多时模型可能只输出了一部分 XML。此时最简单的处理方式是让模型“继续输出剩余部分”或者把流程拆成多个子流程分多次生成。7. 画流程图 Skill 常见问题与排查问题现象可能原因排查方式解决方案AI 没有调用 Skilldescription 与用户请求不匹配查看 SKILL.md 的 description 是否覆盖常见说法在 description 中补充“流程图”“drawio”“flowchart”等关键词输出不是 XML 而是文字描述SKILL.md 输出格式约束不够强检查 SKILL.md 是否明确要求“直接输出 XML 文件”增加“不输出解释文字”“以 mxfile 开头”等强约束draw.io 打开报错XML 被截断或格式不完整查看文件结尾是否包含/mxfile让模型继续输出剩余内容或拆分生成节点重叠严重坐标是模型估算的未做布局优化在 draw.io 中选中全部节点使用 Layout 菜单自动布局将布局操作交给 draw.ioSkill 保证结构和引用不追求完美坐标中文字体显示异常draw.io 默认字体对中文支持不统一检查节点 style 中是否包含字体设置在 SKILL.md 节点规范中加入fontFamilyMicrosoft YaHei这类配置判断分支丢失用户描述中没有明确条件模型擅自简化反问用户确认分支逻辑在 SKILL.md 输入要求中规定缺失条件必须先追问团队规范不一致每个成员自定义了一套样式检查是否统一使用项目级 Skill将 Skill 放入.claude/skills/并提交到 Git 仓库最常见的问题其实不是“AI 画错了”而是“AI 没有按规范画”。解决这类问题的核心手段是把规则写得足够细。SKILL.md 越具体模型表现越稳定。8. 最佳实践让 Skill 成为团队资产写一个 Skill 不难难的是让 Skill 在团队中持续发挥价值。几个实践建议。8.1 一个场景对应一个 Skill不要试图做一个“万能绘图 Skill”。画流程图的 Skill 只负责流程图画架构图可以单独做一个 Skill画时序图再做一个。每个 Skill 的职责边界越清晰description 越精准AI 的匹配准确率越高。如果你发现一个 Skill 里塞进了太多不同场景的规则说明它该拆分了。8.2 规范先于生成写 SKILL.md 时不要从“怎么让 AI 生成得快”出发而要从“团队希望交付物长什么样”出发。先把节点颜色、形状、命名规则、输出格式定下来再考虑如何让模型遵循规则。规范是目的生成是手段。8.3 用版本管理追踪 Skill 的变更Skill 是文本文件享受和代码一样的版本管理待遇。团队里有人提出“判断节点要不要加颜色区分”时改完 SKILL.md提交 Git让变更历史可追溯。这比在聊天记录里讨论规范要可靠得多。8.4 Skill 与 MCP 搭配使用Skill 描述流程MCP 提供外部能力。如果团队里已经配置了 MCP 服务可以将流程图 Skill 的校验脚本封装成 MCP 工具让 AI 生成 XML 后自动调用校验接口。这样生成和校验在同一条链路里完成效率更高。8.5 不要试图用 Skill 解决所有问题Skill 最适合解决“有明确规则、重复发生、输出格式稳定”的任务。画流程图就属于这一类。但如果你希望 AI 完成一个高度依赖实时数据、需要大量外部交互的任务那应该优先考虑 MCP 或专用 Agent而不是硬写一个 Skill。9. 总结与下一步画流程图之所以适合用 Skill 来解决是因为它的难点不在逻辑创作而在格式规范和交付标准。Skill 恰好能把“节点怎么命名、XML 怎么输出、边怎么引用”这些规则固化下来让 AI 每次生成都稳定在同一水平线上。这篇文章里的 drawio-flowchart Skill 是一个起点。你可以先照着写一个最小版本跑通“描述需求、生成 XML、导入 draw.io”这条链路然后再根据团队规范逐步调整 SKILL.md。后续还可以继续深入几个方向在 Skill 中加入字体和配色规范让输出的流程图更贴近团队视觉风格把校验脚本扩展到判断分支完整性检查为不同场景拆出多个 Skill例如“业务流程图”“时序图”“架构图”。无论你用 Claude Code、Codex 还是其他支持自定义 Skill 的工具核心思路是一致的与其每次重复交代怎么画不如把画图规范写进一个文件让 AI 一次就懂。