按理说，

你好。我是小 G，很多时候我感叹 AI 时代给我带来的冲击，是从一些小事引起的。

在过去。我写一篇技术文章最少需要花费一周，长一点的甚至要一个月。其中，有 / 的时间都花费在了枯燥的配图上。按理说，

熟悉我的读者朋友应该知道。JavaGuide 上的所有配图都是用 draw.io 手动绘制的。每一篇文章都有很多图解，帮助理解。

到了 AI 时代就彻底变了特别是对于 draw.io 配图来说。

在去年 skill 还没火的时候。我是用 AI 直接生成对应的 XML，接下来导入到 draw.io 中。

到了今天得益于 skill 的诞生，生成 draw.io 配图变得更加自动化了。按理说，

今天我会分享一下我平时用的自定义 draw.io 绘图 skill。还会提到一些其他常见的 AI 绘图项目。

为什么选择 draw.io？其实，

• 可编辑性痛点: 技术文章发出后经常需要调整标题、节点、箭头、术语。如果只剩 PNG 应对修改需求太痛苦！
• 统一管理痛点: 技术类配图源文件通常不大，但数量多时很难管理。话说回来，draw.io 源文件可以放进仓库或素材目录方便版本控制
• 导出灵活痛点: 支持 PNG/SVG/PDF 一键导出无需额外转换工具链
• 开发者友好痛点: 对于程序员来说XML格式比Mermaid更易操作和修改

技术作者面临的主要问题:

1. "配图修改地狱"问题: 假设你有一篇关于微服务架构演进史的文章,发布后发现各个版本架构示意图里服务名称需要统一更新.如果只是PNG格式。代表着需要重新画所有版本架构图...
2. "风格碎片化"问题: 不同文章里使用不同绘制工具导致:颜色程序混乱、连线样式不统一、节点形状各异,破坏了品牌识别度...
3. "协作困境"问题: 当团队成员需要修改你创建的配图时,发现只能通过截屏+PS处理等原始方式进行二次编辑...
"之前我们团队合作写教程时,遇到一个严重问题:因为使用不同工具绘制配图,最终整套文档看起来像拼贴画而非程序化教程.这极大影响了使用者体验." - 开源项目维护者A

为什么不只用图片生成？

AI生成位图存在三大局限性:

"结构不可编辑"痛点:

"虽然AI能快速生成漂亮效果,但当你需要添加一个新模块或调整流程顺序时。必须重新描述所有内容才能得到新版本" - 技术博主B

"专业性不足"痛点:

"尝试过用DALL·E生成UML类图,结果发现关系线随机乱飞,属性和方法被混为一谈.完全不能作为技术文档使用!" - 软件设计师C

"品牌识别度损失"痛点:

"每次换一种AI工具都会产生不同风格,长期下来我们公司官方文档看起来像聚集了多个不同设计师作品!" - CTO D

我的现行绘图流程优势展示

阶段	传统方式耗时	新流程耗时

需求分析与结构设计 60分钟 5分钟

基础框架搭建 90分钟 3分钟

风格统一与品牌调整 30分钟 >1秒钟

迭代修正与更新维护 重新制作耗时 具体取决于复杂度