AI 终于开始"替你画图"了：draw.io-mcp 使用体验 + 实操教程
最近有一个小东西开始在开发者圈子里慢慢传开。
draw.io-mcp
draw.io （也就是 diagrams.net ）官方做了一个 MCP 接口，让像 Claude Code 、 Claude.ai 这样的 AI ，可以直接生成 draw.io 图表文件。
你不再需要拖框、拉线、对齐、调样式。
你只需要：把你脑子里的结构说清楚。
这件事看起来很小，但实际用下来，它改变的不是"画图方式"，而是建模方式。
一，它解决的不是"画图"，而是"表达结构"
先说我的真实体验结论：
以前你画图，大致流程是这样的：
现在变成：
从操作 → 描述 → 生成
二、实际效果长什么样？
举几个真实能用的场景。
1 ）系统架构图（最实用）
你只需要说：
帮我画一个系统架构图：
用户 → API Gateway → 后端服务（用户服务、订单服务） → MySQL + Redis
再加一个 Kafka 做异步消息
AI 会直接给你一个 draw.io 文件结构（ XML ），打开就是图。
2 ）流程图（写文档效率直接翻倍）
比如你写一个 Skill 的执行流程：
用户输入 → Agent 判断 → 调用向量库 → 是否命中 →
是：生成内容 → 输出
否：调用 Python → 再生成
以前你要画 10 分钟，现在：
👉 一句话 + 回车
3 ）概念模型图
比如我之一直在讲的：
Personalizable APP ：
协议层（统一消息） + 客户端层（个性化） + AI 生成能力
这种"偏思想表达"的图，反而更适合 AI 生成，因为：
三、怎么用（核心教程）
这里我给你讲最实用的一条路径，不是官方文档那种复杂版本。
Step 1 ：准备环境
你需要：
核心本质是：
drawio-mcp = 一个"让 AI 可以生成 draw.io 文件"的工具接口
Step 2 ：让 AI 知道它能"画图"
👉 在 Claude Code 里，让它加载 MCP server
然后你就可以直接说：
帮我生成一个 draw.io 图：
一个典型的微服务架构：
用户 -> 网关 -> 服务 A 、服务 B -> 数据库
Step 3 ：生成 draw.io 文件
AI 会返回一种结构（通常是 XML 或 JSON ）
你只需要：
就完成了。
Step 4 （关键技巧）：不要一次说太复杂
这是使用体验里最重要的一点：
❌ 一次说完整系统
✅ 分阶段生成 + 迭代
比如：
第一步：
先画主流程
第二步：
在订单服务下面加一个 Kafka
第三步：
把数据库拆成主从
这其实就是：
👉 把"画图"变成"对话式建模"
四、真实体验：优点 & 不足（不吹）
优点（很明显）
1 ）节省的是"体力"，不是"脑力"
你还是要想清楚结构，但不用做重复操作。
2 ）特别适合你这种"写系统/写模型"的人
你现在在做：
这些东西，本质都是"结构表达"。
drawio-mcp 正好卡在这个点上。
3 ）统一表达方式
以后可能会变成：
文档 + 图 = 同一个来源（语言）
这点很关键。
不足（目前也很真实）
1 ）布局有时候不美
AI 会"对"，但不一定"好看"。
2 ）复杂图容易失控
一旦你描述太复杂：
👉 图会乱
3 ）还是需要你有结构能力
如果你说不清楚：
👉 AI 也画不清楚
五、你可以怎么用（结合你现在在做的事情）
我直接给你几个你可以马上用的点：
1 ）你的 Skill 架构图
你可以这样让 AI 画：
一个 Agent 系统：
用户输入 → Skill Router →
• 报告 Skill （调用向量库）
• 计算 Skill （调用 Python ）
最终输出结果
2 ）你的向量库 + MCP 体系
MCP Server
• 向量检索
• 规则查询Agent 调用这些服务
3 ）你那个核心概念（非常适合）
Personalizable APP 模型：
• 协议层（消息传输）
• 客户端层（ AI 生成）
• 用户个性化逻辑
这个用 drawio-mcp 出图，会非常适合你做"思想传播图"。
六、最后说一句更本质的变化
drawio-mcp 本身不重要。
重要的是它代表了一件事：
软件开始从"操作工具"，变成"表达工具"。
你以后可能会越来越少去：
而是更多去：
然后让 AI 去"实现表达"。