2026/9/8 19:38:36
FEATURED · 精选文章 
1. 为什么传统的“开draw.io画图”流程其实一直在拖慢你先讲个真实场景。我上一份工作里团队每两周要出一版架构方案每次都是同一个流程打开draw.io拖几个框调半天对齐挨个连线标注完导出PNG贴到文档里。等到下一轮评审需求改了又要重新打开文件挪框、改线、更新注释前后没有半小时下不来。更不用说多人协同时一个文件被几个人轮番编辑最后总有人覆盖掉别人的改动。这个痛点不是个例。你去问任何一个做架构设计、画流程图、写方案文档的工程师基本都能听到类似的抱怨。问题本质不是draw.io不好用而是传统画图工具把“思考结构”这件事和“调整图形样式”这件事强行绑在了一起。你脑子里想的其实是“模块A调用模块BB依赖数据库C”但手上操作的却是“这个矩形放在哪个坐标、那条线的箭头用什么样式、颜色怎么区分”。当画图工具被AI Skill化之后整个逻辑变了。画图不再是一块画布上的手工劳动而变成了一段可以被生成、被复用、被批量执行的文本指令。我最近在社区看到一个开源的画图Skill项目名字不重复了思路就是典型的“用一个文本DSL替代拖拽画布”。它跟draw.io的关系与其说是替代不如说是把draw.io从一个“编辑器”降级成了一个“渲染引擎”。真正的核心价值从界面转移到了指令和数据结构上。写这篇东西是想把我实测这套开源画图Skill之后的完整心得整理出来。包括它内部是怎么组织图形的、如何在本地AI环境里跑起来、请求和输出的数据格式长什么样、以及和draw.io对比下来各自的适用边界。不管你是对Agent Skill感兴趣的开发者还是只想找个更省事的画图方案这篇应该都能给你一些实际的参考。2. 这个开源方案解决的核心问题把画图从“拖拽”变成“写JSON”2.1 从图形界面到文本指令的范式切换draw.io这类工具底层的数据模型其实也是XML.drawio文件本质就是XML但它的设计目标是为“人直接操作图形”服务的。你拖一个矩形它在XML里生成一个mxCell节点你拉一条线它生成一个mxCell边。问题是这个XML可读性很差你几乎不可能手写一整个drawio文件更不可能让AI稳定地生成一个复杂的drawio XML。而这个开源Skill选择的表达方式是类似Mermaid思想的JSON DSL。整个图被定义为四个核心集合nodes所有节点每个节点有id、label、type如rect、ellipse、diamond以及可选的位置和样式属性edges所有连线定义的是“从哪个节点到哪个节点”以及可选的标签和线的类型groups可选用于把节点分组成一个视觉上的容器框对应draw.io里的“泳道”或“容器”metadata图标题、方向、语言等全局信息这个设计的聪明之处在于它把“图的结构”和“图的渲染”彻底拆开了。AI只需要负责生成结构正确的JSON渲染交给Skill里内置的适配器。适配器可以把这套JSON转成SVG、转成HTML、甚至转成draw.io可以导入的XML。这意味着你可以在任意支持怎么输出跳转的地方使用它而不是困在某个具体工具的界面里。2.2 跟draw.io的导出文件相比这套JSON到底好在哪为了让你直观感受差异我拿同一个简单示例做对比。假设要画一个“用户请求进入网关网关调用订单服务订单服务读写数据库”的流程图。用draw.io手画导出后的XML大概是这样的简化版mxfile diagram mxGraphModel root mxCell id0 / mxCell id1 parent0 / mxCell idnode1 value用户请求 stylerounded1;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x80 y80 width120 height60 asgeometry / /mxCell mxCell idnode2 valueAPI网关 stylerounded1;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x240 y80 width120 height60 asgeometry / /mxCell mxCell idedge1 styleedgeStyleorthogonalEdgeStyle; edge1 parent1 sourcenode1 targetnode2 mxGeometry relative1 asgeometry / /mxCell /root /mxGraphModel /diagram /mxfile你让一个没有draw.io经验的人读这个XML基本是读不懂的。你让AI去修改其中一个节点的坐标AI会算得头皮发麻。更重要的是mxGeometry里的x、y坐标是硬编码的一旦节点数量变化坐标体系整个就要重新调整。而这套Skill采用的JSON结构长这样{ title: 订单链路, nodes: [ { id: req, label: 用户请求, type: rect }, { id: gw, label: API网关, type: rect }, { id: svc, label: 订单服务, type: rect }, { id: db, label: 数据库, type: ellipse } ], edges: [ { from: req, to: gw, label: HTTP }, { from: gw, to: svc, label: RPC }, { from: svc, to: db, label: SQL } ] }差异是肉眼可见的。JSON里没有坐标信息只有结构信息。渲染器会按照图的布局算法自动计算坐标。AI生成这种JSON的成功率远高于生成drawio XML因为它的语义足够清晰且没有冗余的回调结构。这也是为什么这类Skill能把“AI画图”从玩具变成真正可用工具的核心原因——它定义了一个AI友好、人类也容易校验的中间格式。提示如果之前用过Mermaid会发现思路很像。但它们的差异在于Mermaid的语法对中文label里的特殊字符比较敏感而且分支多的时候缩进容易乱。JSON天然没有这种问题每种语言都有现成的解析器生成时也不需要考虑缩进状态。3. 本地环境实测让这个Skill在我的笔记本上真正跑起来3.1 环境准备与安装过程先说结论这个项目的安装过程非常轻不像某些开源项目动辄要你配数据库、起微服务。整个Skill本质上是一个Python包加一个CLI入口。我的实测环境是Windows 11 WSL2Ubuntu 22.04Python 3.10Node.js 18用于调用渲染模块安装我用的是pip直接装命令如下注意这里省略了具体包名你们找到对应项目后替换成自己的包名即可pip install draw-skill装完之后可以用自带的命令验证是否安装成功draw-skill --version如果输出版本号说明核心模块没问题。接下来还需要装渲染依赖因为默认的SVG渲染器依赖少量的Node包。这一步在项目文档里叫“install-renderer”执行后会创建一套本地渲染环境draw-skill install-renderer这套环境在国外网络下载时速度一般不过好在包都不大。安装完成后整个Skill就可以独立离线使用了。3.2 Agent场景下的接入配置既然标题里带“Skill”它的设计初衷就是给AI Agent用的。我分别实测了接入开源工具链和官方API两种方式。先说开源工具链的接法。现在的Agent运行时普遍支持“Skill目录”的概念即一个目录对应一个技能目录里有SKILL.md描述该技能的用途、参数、用法外加若干脚本。这个画图Skill就提供了这样一套现成的目录结构draw-skill/ ├── SKILL.md ├── src/ │ ├── generator.py # JSON DSL - 渲染器格式 │ ├── renderer.js # 节点布局与SVG输出 │ └── exporter.py # 导出PNG/SVG/drawio XML等 └── examples/ ├── system_design.json ├── sequence_diagram.json └── mindmap.json你需要做的事是把这个目录软链接到你的Agent运行时指定的skills目录下。比如我用的Agent框架是open-skill-store规范热词里提到的skill creator基本都遵守这个它的目录结构长这样~/.claude/skills/ └── draw-skill - /path/to/draw-skill/配置好之后我直接对Agent下了一句自然语言指令“画一个订单服务架构图前端通过API网关调用订单服务订单服务依赖数据库和消息队列。”几秒钟后Agent调用了这个Skill输出了一张结构清晰的SVG图。整个过程我没有打开过任何画图软件。如果你用的是OpenAI系API流程也类似只需要在函数调用里注册这个Skill暴露的端点。这个Skill内置了一个本地HTTP服务模式启动后可以作为一个tools端点被标准API调用draw-skill serve --port 8231然后API请求里像这样声明工具{ type: function, function: { name: draw_diagram, description: 根据JSON DSL生成架构图/流程图, parameters: { type: object, properties: { json: { type: string, description: 图的JSON DSL内容 } } } } }启动服务后只要把JSON弹给它它就能返回一张SVG图的地址。这套逻辑对任何兼容OpenAI工具调用规范的模型都适用。3.3 踩过的几个小坑第一次跑的时候我碰到几个问题写出来帮大家避雷布局算法依赖特定的node版本。如果你只有老版本的系统Python环境install-renderer可能提示找不到某个Node模块。解决办法是把Node升级到18以上或者在WSL里用一个干净的虚拟环境重装一次。中文字体问题。默认的SVG模板用的字体栈对中文支持一般如果图里全是中文标签导出PDF时会有几个字变成方块。解决方法是把操作系统的中文字体链接到渲染模块的字体目录里或者改一行配置指定使用Noto Sans CJK SC。不要用系统自带的json库生成DSL。这句话是说给Agent的。如果你让Agent自己手搓JSON它经常会把注释写进JSON里导致解析失败。正确做法是让Agent只输出一个Python dict由Skill内部的序列化器转换成JSON。这个细节如果不在SKILL.md里写清楚首次使用大概率要折腾一轮。4. 核心操作拆解一段DSL变成一张图的完整流转过程4.1 输入格式详解每个字段到底是干什么的要真正驾驭这个Skill光会填nodes和edges是不够的。它支持的完整DSL字段比初见时想象的要细致一些。我结合官方文档和源码把关键字段列成一张表一目了然字段归属说明示例id节点/边唯一标识边靠它引用节点auth-svclabel节点/边图形上显示的文本认证服务type节点节点形状支持rect/ellipse/diamond/hexagon等diamondstyle节点内联样式比如填充色、边框色、圆角{fill:#f0f4ff,stroke:#1e3a8a}shape节点非几何形状如cylinder数据库图标、person人物cylinderfrom/to边起点节点id和终点节点idfrom:gateway,to:order-svckind边线的样式solid/dashed/dotted默认soliddasheddir边箭头方向默认to可选both/nonebothgroups顶层用于把节点包进一个视觉容器{id:zone-a,label:内网,nodes:[svc1,svc2]}rankDir顶层布局方向LR左到右、TB上到下、RL、BTTB重点提一下groups。这玩意儿对应的是draw.io里特别常用的“泳道/容器”能力。比如你画一个部署架构图需要把“K8s集群”作为一个大框里面再放“Pod A”“Pod B”利用groups可以很轻松地表达。相对地Mermaid里表达容器靠subgraph嵌套一多语法很容易乱而JSON里就是个简单的层级嵌套不会有歧义。4.2 一个真实示例从JSON到成品图的全过程我拿一个近期在团队内部用过的例子来完整演示。需求是画一个“账号注册链路”的时序图当时我用这个Skill生成然后用draw.io打开做了微调。JSON长这样{ title: 账号注册流程, rankDir: TB, nodes: [ { id: client, label: 客户端, type: rect }, { id: api, label: API网关, type: rect }, { id: auth, label: 认证服务, type: rect }, { id: db, label: 用户库, type: cylinder }, { id: mq, label: 消息队列, type: cylinder } ], edges: [ { from: client, to: api, label: POST /register, kind: solid }, { from: api, to: auth, label: 校验参数, kind: solid }, { from: auth, to: db, label: INSERT user, kind: solid }, { from: auth, to: mq, label: 发送欢迎消息, kind: dashed } ] }这段JSON通过CLI画图时命令是这样的draw-skill render example.json -o output.svg --format svg执行完它会先经过renderer.js内部的布局算法自动把节点安排成纵向流程然后通过SVG模板输出。生成的SVG可以直接用浏览器打开也可以用脚本转成PNGdraw-skill convert output.svg -o output.png --format png为了能在draw.io里继续编辑还可以把它导成drawio格式draw-skill export output.svg -o output.drawio --format drawio这一步对很多团队很实用。兼容不代表要彻底放弃draw.io而是让AI先生成结构草稿你拿草稿到draw.io里做微调两边配合效率高很多。4.3 从AI生成到人工修改的接力工作流上面这个例子其实带出一个重要的工作流观念AI画图工具不是用来取代最后的“美化”环节的而是用来取代“从零想结构”的环节。以前画一个系统架构图花的时间分三块想清楚有哪些模块大概占20%确定模块之间关系占30%排版和美化占50%。传统工具帮不了前三块AI Skill的价值恰恰在这两块。结构越复杂、节点越多AI生成DSL的边际优势越明显。比如一个30个节点的微服务拓扑图手画需要大半天AI生成DSL只要几十秒排版再丑也只需要微调而不是从零开始拖。所以我现在的习惯是先跟AI讨论清楚架构让它把结构生成JSON我肉眼检查一遍节点和边有没有缺漏再导出到draw.io做视觉层的语义化微调比如分组着色、梳理重点路径。整个过程从半天压缩到半小时省下来的时间全在沟通和思考上。5. 进阶玩法这玩意不只是画流程图那么简单5.1 泳道图、时序图、拓扑图全都能生成很多人看到“画图Skill”的第一反应是“这不就是个加强版Mermaid吗”。实测下来它能做的事情比Mermaid广不少。我梳理一下我实际验证过的场景系统架构图这是最常用的场景。把各个服务、中间件、数据库当节点把调用关系当边groups用来圈边界。这类图draw.io能画但AI生成的最大优势是迭代快你描述一句“网关到鉴权加一条虚线”它直接把JSON改了重新渲染不用像draw.io那样手动找线。泳道图/跨职能流程图把每个泳道定义为一个group流程节点按阶段放到对应的组里。以前在draw.io里画泳道图是劝退操作因为拖拽每个框时都需要手动对齐到泳道内部。DSL模式下这个问题不存在布局算法自动处理位置。C4架构图的Level 1/Level 2C4强调分层表达把整个系统当容器内部再展开组件。利用groups的嵌套能力能很自然地表达“容器里有组件组件间有连线”。我在项目里用它画过几次C4的Container图和Component图比对着C4规范手动画准确度高很多。时序图严格意义上说它的时序图不是标准UML时序图更准确地说是一种“带消息标注的节点链接图”。但用来向团队快速解释消息顺序足够了。配合rankDirTB节点从上到下排列边的标签标明消息名可读性很不错。思维导图只需把所有节点设置为只有一个父节点的树状结构渲染出来就是一个标准的思维导图。配合shape字段还能让子节点用不同形状层级感更强。5.2 和Agent配合的自动化场景我在博客公开分享过几个增强了这套Skill效力的组合用法这里挑两个最实用的方案一需求文档自动配图我的工作流里有一个Agent行为每次生成一份新的架构方案文档时自动附带生成对应的架构图。老办法是我在文档里写“如图所示”然后手动截图粘贴非常割裂。现在Agent可以直接把文档里的模块描述解析成DSL渲染成SVG再自动嵌入到Markdown文档里。文档的文字和配图保持同步更新再也不存在“文档改了三版图还是老版”的问题。方案二代码仓库结构可视化我写了一个小脚本扫描一个Git仓库的目录结构自动生成一个nodes列表每个目录变成一个节点依赖关系根据语言自动分析然后渲染出一个“仓库模块依赖图”。这个用途是我自己最常用的一个场景尤其是在接手陌生项目时第一次打开永远乱糟糟的代码库时这个图能给我一个快速的整体认识。类似的脚本完全可以在半小时内基于这个Skill的CLI写出来。5.3 批量生成与自动化流程设计另外一个容易被忽略的能力是批量生成。因为在DSL模式下图就是一份JSON文本所以批量操作非常自然。我做过一件事把一个系统在不同阶段的架构快照比如V1、V2、V3分别写成JSON然后用一个循环命令全部渲染成图做一个架构演进图序列。这个需求如果用draw.io做我得开三个文件分别复制粘贴太痛苦。for f in snapshots/*.json; do draw-skill render $f -o rendered/$(basename $f .json).svg --format svg done这类自动化能力才是这套方案真正超越图形编辑器的部分。它把图当成一种可批量处理、可版本管理、可程序生成的“代码资产”来对待而不是一堆不可推测的坐标点。6. 我为什么说“再见draw.io”只说对了一半6.1 适用边界测试哪些场景它还不如draw.io聊到这里必须说句公道话。标题党喜欢说“再见draw.io”但真的在实际项目里待过的人会知道draw.io这种图形编辑器在某些场景下依然是不可替代的。我实测下来至少有三类情况这套Skill方案处理不好第一自由排布要求高的图。比如视觉设计稿、带有严格品牌规范的架构展示图或者那种需要在图的排版上体现数据流热度把核心路径放在视觉焦点位置的图。DSL的布局算法是自动的虽然支持调整顺序但很难实现完全像素级的自由布局控制。第二超大图件的编辑。几百个节点的图不是DSL生成不出来而是生成的SVG在可读性上很难一次性到位。图太复杂时通常需要人工重新分组、折叠、浓缩。这些操作在draw.io里更直觉化。最新版的draw.io对超大规模图件的处理也一直在优化检索、图层管理等能力确实成熟。第三需要和他人实时协作编辑的场景。draw.io支持多人同时编辑同一个文件一个人加节点另一个人调布局实时同步。这套Skill在流程上不太支持这种协作模式本质上它是一个先JSON后渲染的单向管线如果要多人同时改只能通过Git等版本控制来实现异步协作。6.2 正确的姿态Combined Workflow而不是A/B Switch所以我的结论很明确真正应该实践的不是“用A替代B”的站队思维而是找到AI生成和人工精修的接缝点。我现在的完整画图工作流是这样的先在对话里把图和队友/自己的想法对齐明确节点、边界、依赖关系让Agent生成DSL JSON检查无误后渲染SVG导出PNG/SVG嵌入文档用于快速同步如果后面还需要精细美化或者交付给甲方再把DSL转成drawio文件在draw.io里做最后的视觉润色这个流程的关键在于第4步也就是前面提到的导出drawio格式。这个能力保证了向传统工具的无缝迁移让这套Skill不是把你关进一个“只能AI画”的盒子里而是作为一个高效的草稿引擎存在。任何一个已经熟练使用draw.io的团队都可以先零成本地引入这个流程——AI生成初稿人力只做精修。从我这几周的实测感受来看这套开源画图Skill真正的价值不是“替代draw.io”而是把画图这个环节的效率瓶颈从“操作工具”变成了“思考结构”。搞定一份良好的DSL结构产出质量比拍脑袋拖框稳定得多。以后如果再有人跟我说“这个图画起来太麻烦了”我会直接把这份DSL模板发给他。工具永远都是服务于思考的以前要把思考翻译成拖拽动作现在只需要把思考变成清晰的逻辑关系剩下的交给Skill就行了。
告别拖拽画图：AI Skill用JSON DSL自动生成架构图与流程图
1. 为什么传统的“开draw.io画图”流程其实一直在拖慢你先讲个真实场景。我上一份工作里团队每两周要出一版架构方案每次都是同一个流程打开draw.io拖几个框调半天对齐挨个连线标注完导出PNG贴到文档里。等到下一轮评审需求改了又要重新打开文件挪框、改线、更新注释前后没有半小时下不来。更不用说多人协同时一个文件被几个人轮番编辑最后总有人覆盖掉别人的改动。这个痛点不是个例。你去问任何一个做架构设计、画流程图、写方案文档的工程师基本都能听到类似的抱怨。问题本质不是draw.io不好用而是传统画图工具把“思考结构”这件事和“调整图形样式”这件事强行绑在了一起。你脑子里想的其实是“模块A调用模块BB依赖数据库C”但手上操作的却是“这个矩形放在哪个坐标、那条线的箭头用什么样式、颜色怎么区分”。当画图工具被AI Skill化之后整个逻辑变了。画图不再是一块画布上的手工劳动而变成了一段可以被生成、被复用、被批量执行的文本指令。我最近在社区看到一个开源的画图Skill项目名字不重复了思路就是典型的“用一个文本DSL替代拖拽画布”。它跟draw.io的关系与其说是替代不如说是把draw.io从一个“编辑器”降级成了一个“渲染引擎”。真正的核心价值从界面转移到了指令和数据结构上。写这篇东西是想把我实测这套开源画图Skill之后的完整心得整理出来。包括它内部是怎么组织图形的、如何在本地AI环境里跑起来、请求和输出的数据格式长什么样、以及和draw.io对比下来各自的适用边界。不管你是对Agent Skill感兴趣的开发者还是只想找个更省事的画图方案这篇应该都能给你一些实际的参考。2. 这个开源方案解决的核心问题把画图从“拖拽”变成“写JSON”2.1 从图形界面到文本指令的范式切换draw.io这类工具底层的数据模型其实也是XML.drawio文件本质就是XML但它的设计目标是为“人直接操作图形”服务的。你拖一个矩形它在XML里生成一个mxCell节点你拉一条线它生成一个mxCell边。问题是这个XML可读性很差你几乎不可能手写一整个drawio文件更不可能让AI稳定地生成一个复杂的drawio XML。而这个开源Skill选择的表达方式是类似Mermaid思想的JSON DSL。整个图被定义为四个核心集合nodes所有节点每个节点有id、label、type如rect、ellipse、diamond以及可选的位置和样式属性edges所有连线定义的是“从哪个节点到哪个节点”以及可选的标签和线的类型groups可选用于把节点分组成一个视觉上的容器框对应draw.io里的“泳道”或“容器”metadata图标题、方向、语言等全局信息这个设计的聪明之处在于它把“图的结构”和“图的渲染”彻底拆开了。AI只需要负责生成结构正确的JSON渲染交给Skill里内置的适配器。适配器可以把这套JSON转成SVG、转成HTML、甚至转成draw.io可以导入的XML。这意味着你可以在任意支持怎么输出跳转的地方使用它而不是困在某个具体工具的界面里。2.2 跟draw.io的导出文件相比这套JSON到底好在哪为了让你直观感受差异我拿同一个简单示例做对比。假设要画一个“用户请求进入网关网关调用订单服务订单服务读写数据库”的流程图。用draw.io手画导出后的XML大概是这样的简化版mxfile diagram mxGraphModel root mxCell id0 / mxCell id1 parent0 / mxCell idnode1 value用户请求 stylerounded1;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x80 y80 width120 height60 asgeometry / /mxCell mxCell idnode2 valueAPI网关 stylerounded1;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x240 y80 width120 height60 asgeometry / /mxCell mxCell idedge1 styleedgeStyleorthogonalEdgeStyle; edge1 parent1 sourcenode1 targetnode2 mxGeometry relative1 asgeometry / /mxCell /root /mxGraphModel /diagram /mxfile你让一个没有draw.io经验的人读这个XML基本是读不懂的。你让AI去修改其中一个节点的坐标AI会算得头皮发麻。更重要的是mxGeometry里的x、y坐标是硬编码的一旦节点数量变化坐标体系整个就要重新调整。而这套Skill采用的JSON结构长这样{ title: 订单链路, nodes: [ { id: req, label: 用户请求, type: rect }, { id: gw, label: API网关, type: rect }, { id: svc, label: 订单服务, type: rect }, { id: db, label: 数据库, type: ellipse } ], edges: [ { from: req, to: gw, label: HTTP }, { from: gw, to: svc, label: RPC }, { from: svc, to: db, label: SQL } ] }差异是肉眼可见的。JSON里没有坐标信息只有结构信息。渲染器会按照图的布局算法自动计算坐标。AI生成这种JSON的成功率远高于生成drawio XML因为它的语义足够清晰且没有冗余的回调结构。这也是为什么这类Skill能把“AI画图”从玩具变成真正可用工具的核心原因——它定义了一个AI友好、人类也容易校验的中间格式。提示如果之前用过Mermaid会发现思路很像。但它们的差异在于Mermaid的语法对中文label里的特殊字符比较敏感而且分支多的时候缩进容易乱。JSON天然没有这种问题每种语言都有现成的解析器生成时也不需要考虑缩进状态。3. 本地环境实测让这个Skill在我的笔记本上真正跑起来3.1 环境准备与安装过程先说结论这个项目的安装过程非常轻不像某些开源项目动辄要你配数据库、起微服务。整个Skill本质上是一个Python包加一个CLI入口。我的实测环境是Windows 11 WSL2Ubuntu 22.04Python 3.10Node.js 18用于调用渲染模块安装我用的是pip直接装命令如下注意这里省略了具体包名你们找到对应项目后替换成自己的包名即可pip install draw-skill装完之后可以用自带的命令验证是否安装成功draw-skill --version如果输出版本号说明核心模块没问题。接下来还需要装渲染依赖因为默认的SVG渲染器依赖少量的Node包。这一步在项目文档里叫“install-renderer”执行后会创建一套本地渲染环境draw-skill install-renderer这套环境在国外网络下载时速度一般不过好在包都不大。安装完成后整个Skill就可以独立离线使用了。3.2 Agent场景下的接入配置既然标题里带“Skill”它的设计初衷就是给AI Agent用的。我分别实测了接入开源工具链和官方API两种方式。先说开源工具链的接法。现在的Agent运行时普遍支持“Skill目录”的概念即一个目录对应一个技能目录里有SKILL.md描述该技能的用途、参数、用法外加若干脚本。这个画图Skill就提供了这样一套现成的目录结构draw-skill/ ├── SKILL.md ├── src/ │ ├── generator.py # JSON DSL - 渲染器格式 │ ├── renderer.js # 节点布局与SVG输出 │ └── exporter.py # 导出PNG/SVG/drawio XML等 └── examples/ ├── system_design.json ├── sequence_diagram.json └── mindmap.json你需要做的事是把这个目录软链接到你的Agent运行时指定的skills目录下。比如我用的Agent框架是open-skill-store规范热词里提到的skill creator基本都遵守这个它的目录结构长这样~/.claude/skills/ └── draw-skill - /path/to/draw-skill/配置好之后我直接对Agent下了一句自然语言指令“画一个订单服务架构图前端通过API网关调用订单服务订单服务依赖数据库和消息队列。”几秒钟后Agent调用了这个Skill输出了一张结构清晰的SVG图。整个过程我没有打开过任何画图软件。如果你用的是OpenAI系API流程也类似只需要在函数调用里注册这个Skill暴露的端点。这个Skill内置了一个本地HTTP服务模式启动后可以作为一个tools端点被标准API调用draw-skill serve --port 8231然后API请求里像这样声明工具{ type: function, function: { name: draw_diagram, description: 根据JSON DSL生成架构图/流程图, parameters: { type: object, properties: { json: { type: string, description: 图的JSON DSL内容 } } } } }启动服务后只要把JSON弹给它它就能返回一张SVG图的地址。这套逻辑对任何兼容OpenAI工具调用规范的模型都适用。3.3 踩过的几个小坑第一次跑的时候我碰到几个问题写出来帮大家避雷布局算法依赖特定的node版本。如果你只有老版本的系统Python环境install-renderer可能提示找不到某个Node模块。解决办法是把Node升级到18以上或者在WSL里用一个干净的虚拟环境重装一次。中文字体问题。默认的SVG模板用的字体栈对中文支持一般如果图里全是中文标签导出PDF时会有几个字变成方块。解决方法是把操作系统的中文字体链接到渲染模块的字体目录里或者改一行配置指定使用Noto Sans CJK SC。不要用系统自带的json库生成DSL。这句话是说给Agent的。如果你让Agent自己手搓JSON它经常会把注释写进JSON里导致解析失败。正确做法是让Agent只输出一个Python dict由Skill内部的序列化器转换成JSON。这个细节如果不在SKILL.md里写清楚首次使用大概率要折腾一轮。4. 核心操作拆解一段DSL变成一张图的完整流转过程4.1 输入格式详解每个字段到底是干什么的要真正驾驭这个Skill光会填nodes和edges是不够的。它支持的完整DSL字段比初见时想象的要细致一些。我结合官方文档和源码把关键字段列成一张表一目了然字段归属说明示例id节点/边唯一标识边靠它引用节点auth-svclabel节点/边图形上显示的文本认证服务type节点节点形状支持rect/ellipse/diamond/hexagon等diamondstyle节点内联样式比如填充色、边框色、圆角{fill:#f0f4ff,stroke:#1e3a8a}shape节点非几何形状如cylinder数据库图标、person人物cylinderfrom/to边起点节点id和终点节点idfrom:gateway,to:order-svckind边线的样式solid/dashed/dotted默认soliddasheddir边箭头方向默认to可选both/nonebothgroups顶层用于把节点包进一个视觉容器{id:zone-a,label:内网,nodes:[svc1,svc2]}rankDir顶层布局方向LR左到右、TB上到下、RL、BTTB重点提一下groups。这玩意儿对应的是draw.io里特别常用的“泳道/容器”能力。比如你画一个部署架构图需要把“K8s集群”作为一个大框里面再放“Pod A”“Pod B”利用groups可以很轻松地表达。相对地Mermaid里表达容器靠subgraph嵌套一多语法很容易乱而JSON里就是个简单的层级嵌套不会有歧义。4.2 一个真实示例从JSON到成品图的全过程我拿一个近期在团队内部用过的例子来完整演示。需求是画一个“账号注册链路”的时序图当时我用这个Skill生成然后用draw.io打开做了微调。JSON长这样{ title: 账号注册流程, rankDir: TB, nodes: [ { id: client, label: 客户端, type: rect }, { id: api, label: API网关, type: rect }, { id: auth, label: 认证服务, type: rect }, { id: db, label: 用户库, type: cylinder }, { id: mq, label: 消息队列, type: cylinder } ], edges: [ { from: client, to: api, label: POST /register, kind: solid }, { from: api, to: auth, label: 校验参数, kind: solid }, { from: auth, to: db, label: INSERT user, kind: solid }, { from: auth, to: mq, label: 发送欢迎消息, kind: dashed } ] }这段JSON通过CLI画图时命令是这样的draw-skill render example.json -o output.svg --format svg执行完它会先经过renderer.js内部的布局算法自动把节点安排成纵向流程然后通过SVG模板输出。生成的SVG可以直接用浏览器打开也可以用脚本转成PNGdraw-skill convert output.svg -o output.png --format png为了能在draw.io里继续编辑还可以把它导成drawio格式draw-skill export output.svg -o output.drawio --format drawio这一步对很多团队很实用。兼容不代表要彻底放弃draw.io而是让AI先生成结构草稿你拿草稿到draw.io里做微调两边配合效率高很多。4.3 从AI生成到人工修改的接力工作流上面这个例子其实带出一个重要的工作流观念AI画图工具不是用来取代最后的“美化”环节的而是用来取代“从零想结构”的环节。以前画一个系统架构图花的时间分三块想清楚有哪些模块大概占20%确定模块之间关系占30%排版和美化占50%。传统工具帮不了前三块AI Skill的价值恰恰在这两块。结构越复杂、节点越多AI生成DSL的边际优势越明显。比如一个30个节点的微服务拓扑图手画需要大半天AI生成DSL只要几十秒排版再丑也只需要微调而不是从零开始拖。所以我现在的习惯是先跟AI讨论清楚架构让它把结构生成JSON我肉眼检查一遍节点和边有没有缺漏再导出到draw.io做视觉层的语义化微调比如分组着色、梳理重点路径。整个过程从半天压缩到半小时省下来的时间全在沟通和思考上。5. 进阶玩法这玩意不只是画流程图那么简单5.1 泳道图、时序图、拓扑图全都能生成很多人看到“画图Skill”的第一反应是“这不就是个加强版Mermaid吗”。实测下来它能做的事情比Mermaid广不少。我梳理一下我实际验证过的场景系统架构图这是最常用的场景。把各个服务、中间件、数据库当节点把调用关系当边groups用来圈边界。这类图draw.io能画但AI生成的最大优势是迭代快你描述一句“网关到鉴权加一条虚线”它直接把JSON改了重新渲染不用像draw.io那样手动找线。泳道图/跨职能流程图把每个泳道定义为一个group流程节点按阶段放到对应的组里。以前在draw.io里画泳道图是劝退操作因为拖拽每个框时都需要手动对齐到泳道内部。DSL模式下这个问题不存在布局算法自动处理位置。C4架构图的Level 1/Level 2C4强调分层表达把整个系统当容器内部再展开组件。利用groups的嵌套能力能很自然地表达“容器里有组件组件间有连线”。我在项目里用它画过几次C4的Container图和Component图比对着C4规范手动画准确度高很多。时序图严格意义上说它的时序图不是标准UML时序图更准确地说是一种“带消息标注的节点链接图”。但用来向团队快速解释消息顺序足够了。配合rankDirTB节点从上到下排列边的标签标明消息名可读性很不错。思维导图只需把所有节点设置为只有一个父节点的树状结构渲染出来就是一个标准的思维导图。配合shape字段还能让子节点用不同形状层级感更强。5.2 和Agent配合的自动化场景我在博客公开分享过几个增强了这套Skill效力的组合用法这里挑两个最实用的方案一需求文档自动配图我的工作流里有一个Agent行为每次生成一份新的架构方案文档时自动附带生成对应的架构图。老办法是我在文档里写“如图所示”然后手动截图粘贴非常割裂。现在Agent可以直接把文档里的模块描述解析成DSL渲染成SVG再自动嵌入到Markdown文档里。文档的文字和配图保持同步更新再也不存在“文档改了三版图还是老版”的问题。方案二代码仓库结构可视化我写了一个小脚本扫描一个Git仓库的目录结构自动生成一个nodes列表每个目录变成一个节点依赖关系根据语言自动分析然后渲染出一个“仓库模块依赖图”。这个用途是我自己最常用的一个场景尤其是在接手陌生项目时第一次打开永远乱糟糟的代码库时这个图能给我一个快速的整体认识。类似的脚本完全可以在半小时内基于这个Skill的CLI写出来。5.3 批量生成与自动化流程设计另外一个容易被忽略的能力是批量生成。因为在DSL模式下图就是一份JSON文本所以批量操作非常自然。我做过一件事把一个系统在不同阶段的架构快照比如V1、V2、V3分别写成JSON然后用一个循环命令全部渲染成图做一个架构演进图序列。这个需求如果用draw.io做我得开三个文件分别复制粘贴太痛苦。for f in snapshots/*.json; do draw-skill render $f -o rendered/$(basename $f .json).svg --format svg done这类自动化能力才是这套方案真正超越图形编辑器的部分。它把图当成一种可批量处理、可版本管理、可程序生成的“代码资产”来对待而不是一堆不可推测的坐标点。6. 我为什么说“再见draw.io”只说对了一半6.1 适用边界测试哪些场景它还不如draw.io聊到这里必须说句公道话。标题党喜欢说“再见draw.io”但真的在实际项目里待过的人会知道draw.io这种图形编辑器在某些场景下依然是不可替代的。我实测下来至少有三类情况这套Skill方案处理不好第一自由排布要求高的图。比如视觉设计稿、带有严格品牌规范的架构展示图或者那种需要在图的排版上体现数据流热度把核心路径放在视觉焦点位置的图。DSL的布局算法是自动的虽然支持调整顺序但很难实现完全像素级的自由布局控制。第二超大图件的编辑。几百个节点的图不是DSL生成不出来而是生成的SVG在可读性上很难一次性到位。图太复杂时通常需要人工重新分组、折叠、浓缩。这些操作在draw.io里更直觉化。最新版的draw.io对超大规模图件的处理也一直在优化检索、图层管理等能力确实成熟。第三需要和他人实时协作编辑的场景。draw.io支持多人同时编辑同一个文件一个人加节点另一个人调布局实时同步。这套Skill在流程上不太支持这种协作模式本质上它是一个先JSON后渲染的单向管线如果要多人同时改只能通过Git等版本控制来实现异步协作。6.2 正确的姿态Combined Workflow而不是A/B Switch所以我的结论很明确真正应该实践的不是“用A替代B”的站队思维而是找到AI生成和人工精修的接缝点。我现在的完整画图工作流是这样的先在对话里把图和队友/自己的想法对齐明确节点、边界、依赖关系让Agent生成DSL JSON检查无误后渲染SVG导出PNG/SVG嵌入文档用于快速同步如果后面还需要精细美化或者交付给甲方再把DSL转成drawio文件在draw.io里做最后的视觉润色这个流程的关键在于第4步也就是前面提到的导出drawio格式。这个能力保证了向传统工具的无缝迁移让这套Skill不是把你关进一个“只能AI画”的盒子里而是作为一个高效的草稿引擎存在。任何一个已经熟练使用draw.io的团队都可以先零成本地引入这个流程——AI生成初稿人力只做精修。从我这几周的实测感受来看这套开源画图Skill真正的价值不是“替代draw.io”而是把画图这个环节的效率瓶颈从“操作工具”变成了“思考结构”。搞定一份良好的DSL结构产出质量比拍脑袋拖框稳定得多。以后如果再有人跟我说“这个图画起来太麻烦了”我会直接把这份DSL模板发给他。工具永远都是服务于思考的以前要把思考翻译成拖拽动作现在只需要把思考变成清晰的逻辑关系剩下的交给Skill就行了。 
