以前写一篇技术文章，配图能耗掉三分之一的时间——现在靠一个叫 drawio-chart 的自定义 Skill，让 Agent 自动生成可编辑的 draw.io 源文件，画图效率翻了好几倍，而且图还能反复改。
为什么偏偏选 draw.io，不用图片生成模型
一张图好不好看只是一方面，更关键的是发布以后还能不能改。
文章上线后标题会调、节点会加、箭头方向会变，这太常见了。如果手里只有一张 PNG，要么整张重新生成，要么在 PS 里硬抠，风格很容易对不上。所以更倾向于留一份可编辑的源文件——本地专门有个素材目录，把所有 .drawio 文件单独存着，哪天要改某张图，直接打开对应文件，不用从头再来。
draw.io 的好处也正在这儿：.drawio 文件可以继续在 diagrams.net 网页版或桌面客户端里改，导出 PNG、SVG、PDF 都很顺手，菜单里直接选就行，不用额外折腾格式转换。
流程图、架构图、状态图这类技术图，源文件体积通常不大，放进代码仓库或者素材文件夹都没有压力。
对比之下，纯图片生成模型更适合做视觉表现，不适合长期维护。今天改一个词，明天加一条分支，很难让模型只精准动那一小块还保持整张图不变形。draw.io 不会一次生成就是"完整大片"，但节点、连线、容器、文字都能继续动手改——这一点对技术文章来说价值很大。
现在画图具体怎么走一遍流程
先把文章写出来，或者至少把主线、流程、概念之间的关系理清楚——图是给内容服务的，不能图先于内容存在。
然后让 Agent 判断这篇文章里哪些地方真正值得配图，不是每一段都要画，硬凑图反而拖慢阅读。确定要画之后，调用 $drawio-chart 生成对应的 .drawio 源文件。等文章要发布了，再按需要导出 PNG、SVG 或 PDF。如果某张图需要更强的视觉表现力，比如封面感更足、细节更丰富，再单独找图片生成模型做二次处理。
这里更在意的是把"结构"和"表现"这两件事拆开来做。
drawio-chart 只负责结构化的部分：流程怎么走、模块怎么连、状态怎么迁移、哪些节点该分到一组——这些是逻辑层面的东西。
图片生成模型更适合处理位图层面的表达，比如让一张图整体观感更像正式的文章配图、视觉完整度更高。
关键是不管后面怎么处理，结构始终留在 .drawio 源文件里，哪天要改，直接改这份源文件就行，不用推倒重来。
实际生成的时候，Agent 读完需求会直接写出 .drawio 源文件，最后返回文件路径和一段结构说明，打开以后仍然是标准的 draw.io 文件——节点、连线、文字都能继续手动调，不会被锁死在一张图片里。生成的图不会一次到位，线条走向、间距这些细节通常还得手动再抠一抠，这也算正常，毕竟省的是从零开始画的那部分时间，不是省掉全部人工。
drawio-chart 到底解决了什么
Skill 本质上更像一份"按需加载的任务说明书"，不是发明了新工具，也不等同于 Function Calling 或 MCP。它解决的是某类任务该怎么做、什么时候做、哪些步骤不能漏、需要参考什么材料。drawio-chart 就是把"给技术文章画 draw.io 图"这件事沉淀成了一份可复用的说明。
主文件 SKILL.md 里只放几类关键信息：
1、什么场景该用它，比如 draw.io、diagrams.net、流程图、架构图、时序图、ER 图、状态机图、思维导图；
2、什么场景不该用，比如用户只想要 Mermaid 代码，或者想要的是位图插画、海报、白板风配图；
3、绘图前该收集哪些信息，主题、图表类型、关键节点、节点关系、是否需要导出；
4、生成 .drawio 时该按什么顺序走，标题、容器、核心节点、连线、标签；
5、交付前要检查什么，节点齐不齐、关系画没画对、连线标签是否过长、文件命名是否规范。
更细节的东西没有一股脑塞进主文件，而是拆成了几个独立的参考文档：
| |
|---|
| |
| draw.io XML 结构、节点模板、连线模板、布局建议 |
| PNG / SVG / PDF 导出命令、文件命名、交付规则 |
| 常见 prompt 写法、多图文章配图模式、页面命名建议 |
这个拆法跟 Skill 本身的设计逻辑是一致的——主文件不能写成一份超长 README。Agent 先大致知道这个 Skill 能干嘛，命中具体任务后再去读对应的参考文件。
比如只是画一张流程图，不见得要把导出规范通读一遍；用户明确要 PNG 了，再去翻 export-and-files.md 就够。这样上下文不会被无关细节挤满，执行也更稳。
安装和实际用法
只想装给 Codex 用，可以指定 agent：
主要在 Codex 里用的话，也可以从 GitHub 直接装：
有个坑要留意：某些版本的 skills CLI 下，如果只写 --path skills/drawio-chart 而仓库名不带具体路径，可能会先扫描到仓库里全部的 Skill，不是只装这一个。更稳妥的写法是把完整路径直接写进 source，也就是上面那种 Snailclimb/AIGuide/skills/drawio-chart 的形式。
安装过程中会看到它识别仓库来源、定位到 drawio-chart，再让你选装到哪个 agent、作用范围多大。装完 Codex 有时不会立刻重新扫描新 Skill，建议重启一下再用。
刚开始别让 Agent 自己猜要不要用这个 Skill，直接点名 $drawio-chart，更容易进入正确的工作流。比如想画一个登录流程图：
给整篇文章批量配图时，不用先规定死要画几张，更顺的做法是把文章路径丢给它，让它自己判断哪里值得画图：
"帮我画个架构图"这种虚指令就不要开口了，画微服务架构图，起码得说清楚有哪些服务、哪些存储、哪些外部依赖，请求从哪儿进来，哪些调用是同步的、哪些走异步消息队列——需求描述得越具体，产出才越接近能直接用的稿子，标题起得太笼统，后面大概率还得人工返工。
哪些图适合交给它，哪些不适合
日常主要把三类图交给 drawio-chart。
第一类是文章里的流程图，比如某个规范驱动的编程工作流、维护策略决策图、多 Agent 协作流水线，这些图步骤和分支都很清晰，后续微调也方便。
第二类是架构图和模块关系图，这类图最容易出的问题是风格不统一，服务节点、存储节点、外部依赖各用一套颜色逻辑，统一之后读者理解成本会低很多。
第三类是那些会反复改的图，文章上线后标题、节点名、箭头方向、导出尺寸都可能调，只要 .drawio 源文件还在，改动就不算麻烦事。
封面图、海报、产品氛围图这类偏视觉表现的，不会拿它来做，这些更适合用图片生成模型处理。想要那种白板手绘感，Excalidraw 风格的方案更贴近；想要带主题切换、自包含 HTML、能网页交互的效果，archify 也值得研究一下。
说到底，画图这件事被拆成了"结构"和"表现"两条线——drawio-chart 管结构，图片生成模型管视觉增强，两边不互相耽误。用了这套流程之后最大的感受是，配图不再是一次性消耗品，而是能跟着文章一起持续维护的东西，这点比单张图好不好看更重要。
