最近社区里突然冒出来一批「画图类 Skill」而且不止一个仓库的 star 涨得飞快。我连续试了几套实现之后最大的感受是以前画架构图、时序图、流程图第一反应是打开 draw.io 或者 ProcessOn从空白画布开始拖框拉线现在直接在 AI 编程助手比如 Claude Code、Codex里对话框描述一句话让 Skill 把图生成出来再不行就追加一句“把负载均衡那块改成 Nginx”它自己就把图改了。这种体验往回退一年是做不到的至少做不到这么顺。今天这篇不是单纯夸某个仓库多厉害而是想拆开聊聊这类“画图 Skill”到底解决什么问题、为什么它能取代 draw.io 这类传统工具的一部分使用场景、底层是怎么设计的以及我实际跑通一整套流程时踩过的坑。如果你已经在用 AI 编程助手写代码或者平时画图频率很高这篇应该能帮你省下不少时间。1. 为什么画图 Skill 能让 draw.io 失宠1.1 传统画图工具的三大痛点先说过往用 draw.io 的习惯。我前几年做项目架构梳理几乎每个迭代都要画一张系统架构图。draw.io 的优势是免费、开源、功能全、跨平台甚至支持本地文件。但用久了你会发现它本质上是一个“手动绘图软件”画图的效率完全取决于你的拖拽手速和排版审美。一次架构调整牵一发动全身新增一个微服务意味着要拉框、改箭头、调位置、对齐、改配色动辄半小时没了而且改完以后缩放到 80% 又发现布局乱了接着再调一遍。第二痛是版本管理。draw.io 的源文件虽然有 XML但团队协作时没人能直接在 code review 里看出你这次改了哪条线。即便导出 PNG/SVG 放到 Git 仓库里diff 也没法看最后大家传文件还是用 IM 软件。遇到想回退上一版布局只能靠“我本地还有一份老的”非常原始。第三痛是“画图工具和代码/文档割裂”。架构图和代码明明描述的是同一套系统但你要先在代码里改服务拆分再去画图软件里同步两边全靠手工维护。时间一长图就是摆设和代码真相完全对不上。1.2 AI 画图 Skill 做了哪件核心的事这类画图 Skill 的核心思路不是“又一个绘图引擎”而是把“画图”这件事变成 AI Agent 的一项能力底层通常靠模型直接生成结构化代码——比如 SVG、PlantUML、Mermaid、HTML/CSS——然后渲染成图。你不需要学绘图软件的复杂交互也不需要记忆各种图形工具的位置你只需要把脑子里的结构说清楚后面的布局、连线、美化全部交给模型。这里的关键词其实是“可迭代”。过去画图是单向操作画完一张图要修改就得重画或手动调整。Skill 模式下图是文本代码修改就是改文本AI 可以基于你的自然语言反馈反复改每次生成的版本都能比较。我试过让 Skill 画一张登录鉴权流程图第一版太简单我回复“细化 token 刷新逻辑并标注失败分支”几秒钟后就得到一张新的、更完整的图。这种对话式迭代比任何手动画图工具都自然。1.3 谁最需要这类能力如果你属于下面这几类人这类 Skill 带来的收益会非常大写技术文档、架构设计文档时经常需要配图但画图技术一般的人。后端或全栈工程师架构图、部署图经常要随着代码迭代而更新但不想花大量时间维护图形。做项目汇报、PPT 需要快速输出结构清晰图表的人比如产品经理、技术 Leader。用 AI 编程助手写代码的人希望 Agent 在解释代码时顺带画出调用关系、模块依赖图。如果你本来就是资深绘图爱好者享受手动画图带来的掌控感那 Skill 未必能取代你的习惯。但如果你要的是“快速得到一张还算专业的图并且随时能改”它就是碾压级效率工具。2. 从开源仓库拆解这类 Skill 的技术构成与选型逻辑2.1 Skill 本身是什么目录结构长什么样先普及一个背景。在 Claude Code、Codex 这类工具里Skill 可以理解成一个“给 AI 助手附加的结构化技能包”。通常一个 Skill 就是一个目录里面包含一个SKILL.md作为主描述文件里面写清楚这个技能在什么场景下被调用、需要遵守哪些输出规范、有哪些可用脚本。可能还会有scripts/、references/、assets/等子目录用来存放辅助脚本、模板示例、参考素材。我拆过社区里比较热门的几套画图 Skill它们的通用目录大致是diagram-skill/ ├── SKILL.md # 技能说明引导模型使用步骤 ├── scripts/ │ ├── render.py # 负责把 SVG/HTML 生成图片转换格式 │ └── validate.py # 简单校验输出 SVG 是否有明显错误 ├── templates/ │ ├── architecture.svg # 架构图模板 │ ├── flow.svg # 流程图模板 │ ├── sequence.svg # 时序图模板 │ └── mindmap.html # 思维导图模板 └── assets/ └── examples.md # 调用示例和提问范式这个结构本身不复杂但SKILL.md的编写水平极大影响实际效果。写得好的 Skill 会给模型明确的指令比如“先分析用户描述中涉及几个实体再决定使用架构图还是流程图输出时必须严格使用 SVG宽高不低于 1200×800样式统一用某个色板并在代码块内输出方便直接存为文件”。模型看到这样的约束后生成的图质量会明显更稳定。2.2 为什么很多实现选择 SVG 作为主力渲染方案这里有一个挺关键的选型问题画图 Skill 底层到底让模型直接生成什么格式主流选择有几个Mermaid文本类图、PlantUML文本类图、SVG矢量描述、HTML/CSS网页渲染以及 Canvas/SVG 的 JS 库封装比如 mermaid.js、DrawIO 的 mxGraph。我实际比较过这几个方案的体验差异其中很多问题用起来才发现。从实操角度讲Mermaid 和 PlantUML 的优势是语法简单模型生成的成功率高图表类型覆盖也广尤其是时序图、甘特图、流程图。但它们的排版是自动布局复杂图形会挤成一团样式定制能力弱想调成漂亮的“架构图”风格比较难。比如画一张包含十几个微服务、中间还有网关、消息队列、数据存储的系统架构图Mermaid 用 flowchart 硬画出来的效果往往层次不齐往文档里一放视觉上就是“简陋”。SVG 的优势恰恰是布局完全可控它本质上就是 XML 描述的矢量图。模型可以把方框放在指定坐标、连线拐弯处精确控制、颜色填充、圆角矩形、渐变、文字居中都能做到。虽然生成 SVG 的代码量比 Mermaid 大不少但这类 Skill 普遍会准备模板让模型在模板基础上改文字和结构而不是从零写这就解决了“代码量大导致失败率高”的问题。从我的实测经验看只要模板设计得够好、模型遵循指令的能力够强SVG 方案的出图质量上限是最高的这也是很多新开源 Skill 默认用 SVG 的原因。另外还有一部分 Skill 会选用 HTML/CSS 再配合 headless 浏览器或者 Playwright 截图导出 PNG。这种方式的好处是CSS 布局引擎强大Flexbox/Grid 天然能做复杂排版模型写 JSX/HTML 的语感也更熟练最终视觉表现非常接近网页设计图。缺点是多了一层环境依赖本地必须有浏览器内核或渲染服务安装门槛高一点。我自己更倾向“优先输出 SVG需要位图时再用工具转一次”的方案因为 SVG 在文档系统、Git 仓库、PPT 插入里都很好用。2.3 输出可复用文件被很多人忽略的“工程化”设计真正体验好的画图 Skill通常不只是把图画出来还会“落盘”。也就是说生成的 SVG 源文件会单独存成一个.svg文件下次修改时只需要在对话里说“读取./docs/architecture.svg给订单服务加上 Redis 缓存”AI 就能直接对 SVG 内容继续编辑。这种“文本即文件、文件可复用”的设计才是 Skill 替代 draw.io 的精髓。我们对比一下两种使用方式维度传统 draw.io画图 SkillSVG 落盘模式创建成本手动拖拽新手约 10 分钟描述需求生成约 10~30 秒修改成本重新拖拽或调布局自然语言描述增删AI 改代码版本管理二进制/XMLdiff 不友好纯文本 SVG可 Git 追踪团队协作依赖同一款软件任意文本编辑器 / AI 工具可改效果上限取决于手工人力取决于模型与模板质量这里我不太建议把 Mermaid 的.mmd文件当唯一源文件虽然它确实更易读但复杂架构的美观度不够。比较好的策略是“SVG 做最终交付必要时让 Skill 附赠一份 Mermaid / Markdown 摘要说明方便在技术文档里快速引用”。有的新开源 Skill 也支持生成 PlantUML 适配旧系统但我觉得没必要一开始就追求多格式先做好 SVG 这一种就足够支撑绝大多数画图场景了。3. 动手实操从安装到生成第一张架构图的完整流程3.1 准备阶段的工具环境我用的主力环境是 Claude Code 命令行版本操作系统是 macOS终端走的是 zsh。其实这套流程对 Codex CLI 或者其他支持 Agent 的类似工具也适用因为 Skill 本身是个通用机制。你只需要满足两件事第一能安装并运行对应的 Agent CLI第二有可以调用的模型 API 或订阅账号。局部试玩的话DeepSeek 的开源模型也能做到基础生成但代码能力与遵循长指令能力会比顶级模型弱一些架构稍复杂的图容易出现连线对不齐、元素丢失之类的现象不建议新手一上来就用弱模型排障。安装 Skill 的第一步是拉取项目仓库。以我用的这个仓库为例基本操作git clone https://github.com/example/diagram-skill.git ~/.claude/skills/diagram-skill不同工具识别 Skill 的路径不太一样有的支持项目级目录.claude/skills/有的放在用户级全局目录。我建议优先放全局目录因为画图需求不限于某个项目全局模式在任何仓库下都能调用。放好后在同一对话里重新启动一次 Agent让它重新扫描技能目录。3.2 用一段话生成“订单系统架构图”我实际开始画的时候没有用套话模版而是直接把项目里的真实需求描述丢给它请使用 diagram-skill帮我画一张订单系统的微服务架构图。 核心服务包括前端、API网关、订单服务、用户服务、库存服务、支付服务、消息队列。 订单服务和库存服务之间通过消息队列解耦支付成功后回调订单服务更新状态并发送事件到消息队列库存服务消费事件完成扣减。 要求用 SVG 格式风格简洁大方最好使用蓝灰配色宽度 1280高度建议 800服务模块旁附一行文字标明职责。模型收到后通常会按 Skill 指引先做一次简短分析判断这属于“系统架构图”类型然后读取模板目录里的architecture.svg把服务节点和文字替换进去再按照我描述的关系连线。大约 20 秒后它会输出一个 SVG 代码块我直接保存为/docs/order-architecture.svg。第一版结果整体可用但有个小问题支付服务和订单服务之间的回调箭头方向不够直观。我的处理方式是直接追加一句“把支付服务到订单服务的线改成虚线并在线上标注‘异步回调’。” Agent 会读取刚才生成保存的 SVG 文件精准修改对应路径的stroke-dasharray属性和文本标签。这种修改粒度基本能对应到 draw.io 里的“选中一条线改样式”。3.3 导出为 PNG处理中文字体和分辨率的正确姿势很多文档平台不支持直接展示 SVG或者团队习惯看图时用 PNG 格式。我一开始直接用系统自带工具把 SVG 转 PNG发现中文全部变成了豆腐块这是因为系统默认的字体没被正确嵌入。后来我改用开源工具rsvg-convert并指定系统中文字体效果就好了很多。命令大概是brew install librsvg rsvg-convert -w 1600 -h 1000 -o order-architecture.png order-architecture.svg如果的 SVG 里引用的是浏览器渲染才支持的 CSS 样式rsvg-convert 偶尔会解析不完全这种时候我会改用 Playwright 脚本加载 SVG 再截图虽然重一点但还原度最高。再补充一个经验输出图片时宽高尽量按 2 倍尺寸导出否则在文档中插入图片时稍微放大一点就会发虚。SVG 本身是矢量无损的但 PNG 不提前高清化后面想补救就只能重导。3.4 批量生成多图一次对话画完“系统全景图 时序图”画架构图只是热身。我试过最痛快的一次是在同一个对话里连续让它画了五张图一张系统全景图一张用户登录时序图一张支付状态机图一张部署拓扑图一张数据库 ER 图。全程只靠自然语言描述需求偶尔指定一下“用蓝色突出高可用组件”“表的数量不要超过 10 张”。这里最大的感受是对话上下文连贯性让配套图之间不容易互相矛盾。比如先画了“订单服务通过 MQ 通知库存服务”的架构图后面让它画“下单时序图”时它会自动延续前面定的通信方式而不是重新发明一套。传统方式下不同图往往由不同人画很容易出现架构图说用 HTTP时序图却画成 Feign 调用的低级错误。当然连续生成多张图对模型能力要求更高如果中途发现输出开始“忘事”可以把前面的关键约束放进一个context.md文件里让它每次都先读一眼再画。这个技巧是我实验多次后最有效的稳定方案。4. 实操中的高阶用法让 AI 不止“画得出来”还“画得专业”4.1 用示例文件和“风格词”约束出图颜值纯靠 prompt 让模型每次都输出好看、统一风格的图还是有一定运气成分。后来我学乖了看社区 Skill 的模板目录里通常有几个 example 文件这些 example 不只是给用户看更是让模型参考风格的“锚点”。我会在 prompt 里明确写“仿照模板 examples/architecture.svg 的视觉风格但内容替换成 xxx。” 实测这样生成出来的图结构层次感明显更强。如果你想要现代感更强一点的风格可以要求模型在 SVG 中使用卡片式布局、圆角矩形、外发光、柔和的阴影。说得越具体比如“主色 #2563EB背景 #F8FAFC边框 #E2E8F0”最终效果越靠近你脑子里的设想。我在微调了几次之后形成了一套自己的默认参数背景浅灰白 #F7F9FC容器底色白色矩形圆角 8px加浅灰色描边主服务节点蓝色系 #EFF6FF 底、边框 #60A5FA数据存储节点紫色系 #F3E8FF 底、边框 #C084FC外部系统灰色系 #F1F5F9 底箭头统一 #64748B关键路径用粗线或虚线并用文字标注字体统一用系统默认的无衬线字体避免特殊字体在渲染机上不兼容这几组参数其实花不了多少 token但能保证多张图风格统一整套文档看起来像出自同一个设计师之手很值。4.2 使用 SVG 模板做快速结构替换有些设计模式是固定复用的例如“网关 多个微服务 数据库”的经典分层。如果能让 Skill 默认识别到这类模式再套用固定模板速度和稳定性都会提升。我在实际使用中会故意写这种 prompt用模板 templates/microservice.svg帮我把四个后端服务替换为用户、订单、商品、支付。 注意模板中各模块之间的横向间距保持一致箭头连线不要交叉。这样省去了模型每次重新设计布局的思考过程。原因很简单模型虽然懂坐标但在动态规划一条从 (120, 310) 到 (840, 310) 的连线时偶尔会有失误导致线条穿过不该穿过的框。固定模板里这些连接路径都是验证过的替换文字内容风险最小。如果你对自定义模板感兴趣可以拿一张模型生成的效果最好的 SVG自己手工微调布局以后放到templates/里以后就成了你的专属样式下次会让 Skill 优先选择这张图做底子逐步积累自己的模板库。这也是 Skill 生态比较迷人的地方不需要会复杂编程只需要“把一次成功的输出固化成模板”。4.3 与其他 Skill 组合不只是画图是文档自动化画图 Skill 单独用已经很香但更强的玩法是和其他 Skill 组合。我目前的自动化工作流里画图 Skill 常常和写作类 Skill、代码解释类 Skill 串联使用让 Agent 扫描项目代码目录分析模块依赖生成一份 markdown 描述。把描述喂给画图 Skill让它生成对应的模块依赖图。最后再让文档类 Skill 把图插入到设计文档里并配一段说明文字。这相当于把“代码分析 → 架构可视化 → 文档编写”串成一条流水线。以前一个架构师做完这些至少小半天现在我自己一个人操作半小时能产出一整套配套图齐全的设计初稿。质量上初稿不一定能直接用但它把最费时间的“从无到有”阶段解决了。剩下的调整也都是对话式修改。当然这种组合玩法对模型能力要求更高。我在用普通开源大模型测试时它生成的 SVG 经常出现“圆角矩形标签和文字重叠”“箭头没有指向节点中心”之类的小 bug。如果你遇到类似情况别急着怪模型可以先考虑检查一下 prompt 是否有足够限制或换一个更强代码能力的模型。5. 避坑指南我从频繁使用中整理出的高频问题5.1 生成图片文字乱码、中文不显示怎么办这个问题主要是字体原因。SVG 文件里如果写了font-familyArial而当前渲染环境没有安装 Arial 字体或中文字体映射异常中文就会显示成方框。解决办法生成时在 prompt 里明确要求字体使用“PingFang SC, Microsoft YaHei, sans-serif”。在本地做 PNG 导出时确认系统已经安装了至少一款中文字体。如果多次导出仍有问题检查一下 SVG 文本标签里是否缺少xml:langzh-CN部分渲染器会有语言相关字体选择逻辑。5.2 SVG 元素大量堆叠导致输出中断或信息丢失大而全的架构图比如超过 30 个节点、50 条连线仍然强依赖模型的输出长度和逻辑一致性。模型在中途输出截断、自行发挥优化、少画了一个模块的情况在这一类任务中不算罕见。规避方法把大图拆成多个子图每个子图控制在 15 个节点以内最后再让 Skill 生成一张“总览图”总览图里不展示细节只画分组和关键链路。明确告诉模型“不必为每个节点都要用不同的配色层次关系用分组边框表达即可”降低视觉复杂度。在长输出前提醒它“先规划坐标再输出完整代码别中途换思路”。5.3 修改某个细节时背景样式全变了对话进行到第 N 轮如果你让它“把第一个框的宽度从 160 增加到 200”模型有时候会误判为“整张图重新调整布局”结果连背景颜色、配色、间距全改了。这不是不可用而是提示词不够精确。修正后的说法是只修改 id 为 service-order 的矩形元素将其 width 属性从 160 改为 200 新增宽度会导致后面的连线起点可能偏移请一并调整该节点右侧所有连接的起点坐标。 其余元素不要修改。借助元素定位描述模型就能精准编辑 SVG。这套玩法也验证了为什么 SVG 落盘模式比直接生成 PNG 更好用——PNG 一旦生成就无法局部修改SVG 能直接做到代码级微调。5.4 想让图片背景透明导出时会有白边如果你生成的 SVG 需要嵌入到深色 PPT 或网页里背景透明非常重要。我一开始默认生成的架构图都是白底插到深色主题的页面里非常突兀。后来我习惯在 prompt 里明说“背景使用透明不要添加任何 rect 作为全局背景不要使用 fill#fff。” SVG 输出时可以很好支持透明背景但在用 rsvg-convert 转 PNG 时需要额外加参数rsvg-convert --background-color none -o output.png input.svg不加--background-color none的话即使 SVG 透明PNG 也会默认渲染成白色背景。5.5 Team 协作中AI 生成的 SVG 能否被其他人直接编辑很多人会担心一个问题AI 生成的 SVG团队成员没装 Agent 工具是不是就改不了了亲测结果是可以。把 SVG 文件直接拖到 draw.io 里draw.io 支持导入或打开 SVG 文件严格来讲draw.io 原生编辑 SVG 的能力有限它更偏向识别合适的 XML 再导入。如果你希望团队成员以后能在 draw.io 里继续编辑最稳的办法是让 Skill 生成时同时输出一个.drawio格式的 XML 文件或者至少画完架构图之后导出一次可以导入 draw.io 的格式。不过这样一来“用 AI 生成原始图、再在 draw.io 里精修”就形成了一个混合工作流也是一种很实在的团队协作姿势。就我自己目前的使用偏好来说凡是给我自己维护的技术文档用的图我全走 SVG 落盘 Git 管理因为后续我自己用 AI 改起来最顺。凡是需要给团队里不熟悉这些工具的人做二次编辑的图我会多花一步转成 draw.io 可以识别的格式双轨并行避免协作时卡在工具链上。6. 我对这类 Skill 未来走向与个人使用心法这类 Skill 出现得这么快确实给“画图”这个传统领域带来了新的工作方式。往深一点看它在把“结构化表达”这件事彻底文本化、可编程化也让“文档图例随代码演进”变成可能。未来不管底层的模型怎么换这套“文本生成 → 文件落盘 → 对话式修改 → 版本管理”的工作流大概率会沉淀成技术文档的标准干活方式。不过我也必须泼点冷水Skill 不是万能钥匙。模型能力不足时生成的复杂图示依然会翻车输入的业务描述含糊不清时它也画不出精准的图。它更像一个“非常了解绘画规范的实习生”而不是“脑子里自动长出一套架构的架构师”。你需要先把逻辑讲清楚它才能把图做漂亮。聊聊我现在的使用习惯日常快速文档配图我已经基本不再打开 draw.io 了但遇到一张图需要精细叠层设计、需要严格控制输出的像素级布局时我还是会把 AI 生成的 SVG 作为底稿带进 Figma 或 draw.io 精修。动笔思路和骨架是 AI 帮我想清楚的省掉了最枯燥的空白画布阶段而精修阶段需要人类审美和经验的地方则仍然值得自己动手。如果你也想基于这类开源 Skill 搭一套自己的画图工作流我的建议是先别追求功能大而全只装一个针对架构图/流程图优化最好的仓库即可每天真的在写文档时强迫自己用三次以上慢慢把 Prompt 习惯调顺再逐渐尝试组合其他 Skill。等这套流程成为肌肉记忆你再回头看那些必须手动拖线框图的日子会有一种明显的“效率代差感”。真正影响工作流上限的往往不是工具本身而是你喂给它的信息结构和迭代思路。给模型越清晰、越模块化的描述你收回来的图就越接近一张值得直接放进技术方案里的作品。这是我尝试了近半个月这类 Skill踩过无数乱码和错位坑之后最想分享给你的一句话。