当AI编程已经能写几百行代码，它能不能帮你画图？

故事是这样的。

最近我在做一个系统设计方案，前后花了大概两天时间。想架构用了20分钟，画图花了2小时。

这个比例我在很多项目里都遇到过——想清楚结构其实很快，但真正把结构变成一张能用的图，中间隔着一整套劳动：选画图工具、学它的语法、调格式、对布局、让元素对齐、再导出成图片。每一步都不难，每一步都在磨人。

2比20，这个比例不对。

AI编程工具现在都能写几百行代码了——它能不能帮我画图？

答案是可以，但很粗糙。

你让Claude Code或者Cursor画一个微服务架构图，它确实能生成一段Mermaid代码或者一个Excalidraw JSON。但你多试几次，三个问题就冒出来了：

第一，没有方法论，质量全靠运气。换一天问同样的问题，出来的图结构完全不同——有时候布局清爽，有时候节点挤成一团。AI不知道什么叫”好的架构图”。

第二，每次从零描述需求。你得反复交代”分层画”、“连线要标注”、“配色别太花”。这些本应该是默认规范，不该每次手动口述一遍。

第三，在不同工具之间没法复用。你在Cursor里攒了一套画图Prompt，换到Claude Code就全废了，得重新写。

但用了一阵子之后我发现，这三个问题其实都是表面症状。底下还藏着一个更根本的事情，我们给AI信息的方式，一开始就错了。

传统的方式是”你告诉AI画什么”——你得用自然语言描述：我要一个三层架构，上面是API网关，中间是服务层，有订单服务、用户服务、支付服务，下面是MySQL和Redis。

等一下——这些信息是你发明的吗？不是。它们早就躺在你的设计文档里、在代码仓库的结构里、在DDL文件里、在K8s的YAML里。你做的事情，本质上就是把已经存在的知识，先人肉读一遍，再翻译成自然语言，再喂给AI。

这就好比你面前放了一本英文书，你不让翻译官自己看原文，而是你一个字一个字念给他听，让他翻成中文。效率低是必然的，信息丢失也是必然的。

所以这件事的本质不是AI画不好图——是我们给AI信息的方式不对。我们在”描述需求”，而不是”链接知识”。

顺着这个思路往下挖，我突然意识到——这里面有一个认知跃迁可以做。

AI编程工具都有一种扩展机制：Claude Code叫Skill，Cursor叫Rule，Copilot叫Instructions。本质都是把一段结构化指令注入AI的上下文，让它获得某个领域的专业能力。

我在GitHub上找到三个跟”AI画图”直接相关的开源Skill。

第一个是drawio-skill，来自Agents365团队。理念很直接——让AI直接输出Draw.io的XML文件，不走中间格式，不靠截图，直接生成可编辑的.drawio文件。它做了三件事：用Schema约束mxCell节点的合法属性、规定了网格对齐和分层间距、把”什么时候画什么图”的决策逻辑写进了Prompt。

第二个是excalidraw-diagram-skill，来自coleam00。走的是另一条路——JSON Schema驱动的白板图生成。Excalidraw的每个元素都有精确坐标、尺寸和样式，所以这套Skill定义了完整的坐标系统、元素类型和手绘风格控制参数。

第三个是ian-xiaohei-illustrations，来自helloianneo。这是转折点。前两个项目做的是工程图——架构图、时序图、流程图。而这个Skill做的是文章配图。它让AI不只是画工程结构，而是把文章里的认知动作——一个判断、一个隐喻、一个状态变化——变成一张手绘风格的插画。一个小黑IP角色，不是装饰，是图中核心动作的承担者。

这三个项目各有不同，但拼在一起之后我看到了一个共同模式：

输入都是知识源（代码、设计文档、DDL、接口规范、文章正文），而不是用户的自然语言描述。

输出都是图（架构图、流程图、手绘配图、概念图解）。

差别只在路由——根据知识源类型，自动选择最合适的可视化方式。

DDL进来出ER图，接口规范进来出时序图，科普文章进来出手绘配图。输入输出模式完全一致，只是映射关系不同。

那就不应该做成”一个人的画图工具”了——应该做成一个通用框架。

我把这个通用模式抽象成四层：

知识源→路由→生成→质量自检

对应到架构设计，就是四层：

Core层：方法论内核。 定义画什么图、什么时候画的决策逻辑。跟输出格式无关，跟具体工具无关。

Plugin层：输出格式。 drawio生成XML，支持导出PNG/SVG/PDF；excalidraw生成JSON，手绘风；mermaid生成文本代码块，版本控制友好；ian-illustrator生成PNG配图，适合科普文章。每个插件自带指令、Schema和质量自检清单。

Adapter层：工具适配。 同一套方法论加插件，要输出到10个不同AI工具的原生指令目录。Claude Code放.claude/skills/，Cursor放.cursor/rules/，Copilot放.github/copilot-instructions.md。适配器负责把编译后的内容写到对的位置。

CLI层：安装部署。 npx ai-viz init，一条命令直接跑。

为什么必须是插件架构？因为可视化格式还在持续演进。明天冒出一个新的图表工具，只需要加一个插件，不用改框架。

聊到这里你可能已经发现了，路由是这个方法论的核心差异化能力。

路由的本质是知识源类型到图种的自动映射。但现实比理想复杂——不是所有情况都能百分百确定画什么图。所以路由设计了一个置信度分级策略。

最高优先级：用户明确指定。你说”画个时序图”，直接执行。

次高优先级：知识源强映射。DDL进来就是ER图，接口规范进来就是时序图，K8s YAML进来就是部署图。这些关系确定性极高，AI直接执行并附上理由。

再往下：内容类型判断。技术工程内容走drawio或mermaid，科普文章走ian-illustrator。确定性稍低但足够高。

再往下：多种可能的场景。一份设计文档既适合架构图也适合数据流图——AI给出推荐方案和理由，等确认。

底层兜底：高成本场景。对外正式文档、需要额外工具链的格式——推荐方案但也等确认再执行。

确定性越高，自动化程度越高。减少交互摩擦，同时避免浪费生成成本。

这是整个方法论的哲学内核：知识不需要被”翻译”给AI——AI应该直接去读知识源，理解它的结构，然后画出来。

这意味着：

AI不是在”按你的描述画图”——它是在”从知识中提取可视化投影”。

图表不是创作物——图表是知识的视图，就像数据库的View是数据的视图。

同一份知识可以有多个投影——架构图是结构投影，时序图是行为投影，部署图是运维投影。

选择画什么图，本质上是选择从哪个角度观察同一份知识。

这个认知一旦转过来，很多东西就顺了。

但这还没完。AI能生成图了，生成不等于可用。如果你用过AI画图，一定遇到过节点挤在一起、连线交叉成蜘蛛网、配色花得像调色盘爆炸的情况。生成物和可交付物之间，有一道质量门禁。

传统靠人眼检查——看一眼觉得行就行。但主观标准不稳定，检查维度也不全。

ai-viz的做法是：把质量标准规则化，让AI自己对着清单来检查。不靠感觉，靠规则。

五层检查维度：结构正确性（图对不对）、布局合理性（看起来清不清楚）、信息完整性（该有的都有没有）、风格一致性（配色是否符合项目规范）、可交付性（格式稳不稳、能不能导出来）。

不同输出格式还有专项检查。Draw.io要检查XML标签的闭合、元素ID的存在性；Excalidraw要检查JSON合法性、箭头指向是否正确；Mermaid要检查语法渲染、特殊字符转义。

这些检查逻辑写成规则清单，AI生成图之后逐项自动跑。发现问题当场修复，不用等人来Review。

人的判断在复杂场景下仍然有价值——比如”这张图是否真正表达了设计意图”。但80%的质量问题——格式错误、元素遗漏、布局混乱——可以被规则化的自检捕获。

对了，还有一个很多人会问的问题：为什么不装一次全局生效，而要每个项目都跑一遍npx ai-viz init？

因为ai-viz的第一性原理是知识源——知识源在项目里。代码在项目里，DDL在项目里，设计文档在项目里。可视化能力应该跟着知识源走，而不是飘在全局配置里。

设计语言因项目而异——toC项目用品牌色，toB项目用稳重色，一份全局配色没法兼顾。插件按需选择——后端项目只要mermaid画时序图就够了，内容项目需要ian-illustrator画配图。版本隔离——生产项目锁定稳定版，实验项目用最新版，互不影响。

每个项目有自己独立的可视化配置，就像每个项目有自己的package.json一样。

这个项目叫ai-viz，是DeepJAI做的，已经在GitHub上开源了。

从一次画图时”比例不对”的感叹，到三个开源Skill的发现和改造，再到抽象出”知识源→路由→生成→质量控制”的通用范式，最终做成一个四层插件架构、覆盖10个AI工具的开源框架。

路不长，但每一步都是从实践中长出来的。

如果你也在日常工作中被”画图”这件事消耗了太多时间——想的东西20分钟，画的东西2小时——可以试试这个。

开源地址：github.com/deepjai-way/ai-viz

一行命令装完，跟你的AI说”画个这个项目的架构图”，它已经知道答案了。

---

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

/ 作者：卡兹克 / 投稿或爆料，请联系邮箱：wzglyay@virxact.com