工作里有一个特别真实的场景：你明明已经把系统逻辑想清楚了，但一到要画架构图、流程图、模块关系图，就开始卡住。
不是不会画，而是太费时间。
一个业务流程要对齐多个角色，一个项目架构要讲清楚前端、后端、数据库、队列和外部服务之间的关系。如果只靠文字，读者很容易看累；如果能把这些关系整理成一张图，理解成本会低很多。
这也是我最近开始折腾 Codex × Draw.io MCP 的原因。
简单说：你把想画的内容描述给 Codex，Codex 通过 Draw.io MCP 生成图，然后直接打开到 draw.io / diagrams.net 里继续编辑。原来要手动拖拽半天的事情，现在可以先让 AI 帮你搭出 70% 的结构，再由人做最后的审美和细节调整。
这篇文章就聊一下怎么安装、怎么用，以及我实际体验下来更推荐的工作流。
为什么是 Draw.io
Draw.io 是很多程序员、产品经理和架构师都很熟悉的画图工具。它不花哨，但足够稳定，尤其适合画下面这些内容：
- 流程图
- 架构图
- 思维导图
- 系统设计图
- 业务流程图
- 技术路线图
- UML 图和泳道图
更关键的是，它生成的图不是一张"死图"。你可以继续在 Draw.io 里编辑节点、改线条、调配色、导出 PNG / SVG / PDF。
前段时间 Draw.io 官方推出了自己的 MCP 项目：
GitHub 地址：https://github.com/jgraph/drawio-mcp
官方 README 里也写得很直接：这个 MCP Server 的目的，就是让 LLM 能创建图，并在 draw.io editor 中打开。它目前提供几种接入方式，包括 MCP App Server、MCP Tool Server、Skill + CLI 和 Project Instructions。对 Codex 这类本地工作流来说，最常用的是 MCP Tool Server。
第一步：安装 Draw.io MCP
安装有两种方式。
一种是在 Codex 的设置里手动添加 MCP Server，填入对应配置。
另一种更省事：直接把 Draw.io MCP 的 GitHub 仓库链接发给 Codex，让它帮你完成安装。
如果你想手动理解一下它背后的启动方式，官方 MCP Tool Server 的 quick start 是：
bash
npx @drawio/mcp也就是说，它本质上是一个通过 npm 分发的 MCP 工具服务。接入完成后，Codex 就可以调用 Draw.io 相关工具，把 XML、CSV 或 Mermaid 这类结构化图形描述渲染成可编辑的图。
这里建议你安装完之后，先让 Codex 做一次很小的测试，比如：
text
请使用 Draw.io MCP 画一个简单的三层 Web 应用架构图：
用户 → 前端 → API 服务 → 数据库。
要求用简洁配色，并在 draw.io 中打开。如果能正常打开 draw.io 结果页，说明环境基本就通了。
第二步：把"我要画什么"讲清楚
很多人第一次用 AI 画图，容易直接丢一句：
text
帮我画一个架构图。这当然也能出图，但通常效果不会太稳定。
我的做法是：先把图当成一篇小文章来写，至少说明 4 件事：
- 这张图要表达什么主题
- 图里有哪些角色、系统或模块
- 它们之间是什么关系
- 希望图的风格是什么样
比如我在工作中经常要画项目架构图，就会先和 GPT / Codex 讨论清楚架构细节，再把整理后的文字发给 Codex，让它调用 Draw.io MCP 生成图。
一个更稳的提示词结构大概是这样：
text
请使用 Draw.io MCP 生成一张系统架构图。
主题：AI 内容生产工作流
模块：
1. 用户输入：选题、素材、参考链接
2. Codex：负责拆解任务、调用工具、生成草稿
3. 图片生成工具：生成封面图和正文配图
4. Markdown 发布工具：把本地图片上传到图床，并生成平台发布版
5. 发布平台：CSDN、公众号、知乎等
关系：
- 用户把任务交给 Codex
- Codex 调用图片生成工具和 Markdown 发布工具
- 所有产物最终输出到发布平台
要求：
- 使用横向布局
- 风格简洁，适合技术博客
- 模块之间用箭头连接
- 最终在 draw.io 中打开，方便继续编辑注意，最好在提示词里明确写上 "使用 Draw.io MCP"。否则 Codex 有可能只是在聊天里给你一段 Mermaid，或者生成普通文本说明，而不是调用 MCP 工具真正打开 Draw.io。
第三步：检查生成结果
绘制完成后，Codex 会总结本次任务，并自动打开浏览器显示绘图结果。
我第一次生成出来的图，结构是对的，但配色比较单一。
这很正常。
AI 画图最强的是"把关系先搭出来"，而不是一次性替你完成最终审美。尤其是架构图这种东西，最重要的是先把模块、层级和连接关系画准。至于颜色、间距、边框、图标，后面都可以在 Draw.io 里继续调。
我一般会按这个顺序检查：
- 模块是否漏了
- 箭头方向是否正确
- 层级是否清晰
- 是否有不必要的节点
- 配色和布局是否方便阅读
如果结构错了，直接让 Codex 重画；如果只是配色不够好，就在 Draw.io 里手动微调，或者让 Codex 基于当前图继续修改。
一个替代方案：用 Google AI Studio 生成 Draw.io XML
除了直接让 Codex 调用 Draw.io MCP，我也试过另一条路线：用 Google AI Studio 生成 Draw.io XML，然后复制到 Draw.io 网页版中。
Google AI Studio 是 Google 旗下的 AI 工具，免费额度比较友好。我自己一天要画很多图时，它的额度基本够用，而且有时候生成出来的图在配色上会更讨喜。
比如同样是上面的提示词，我让它输出 Draw.io / diagrams.net XML 架构图代码：
然后复制 XML 到 Draw.io 网页版里，就能生成图。
效果如下：
不得不说，Google 的审美有时候确实在线。
不过这两种方式适合的场景不太一样：
| 方式 | 适合场景 | 优点 | 不足 |
|---|---|---|---|
| Codex + Draw.io MCP | 本地工作流、需要自动打开和持续修改 | 跟 Codex 任务流结合紧密，可直接调用工具 | 初始配色可能需要调教 |
| Google AI Studio + XML | 想快速生成一份更好看的 Draw.io XML | 出图审美有时更好，试错成本低 | 需要手动复制 XML 到 Draw.io |
我的建议是：如果你已经在 Codex 里处理需求、写代码、整理文档，就优先用 Codex + Draw.io MCP；如果你只是想快速试几版图的风格，可以让 Google AI Studio 生成 XML，再放进 Draw.io 里二次编辑。
Google AI Studio能画的不只架构图：UML、泳道图也可以画
Draw.io MCP 不只能画系统架构图。
如果你把需求描述清楚，它也可以画 UML 图，比如用例图：
也可以画泳道图：
这里有一个小技巧：如果你想让 AI 直接输出可复制的 Draw.io XML，可以在提示词最后加一句：
text
请将上面的内容输出为 Draw.io（diagrams.net）XML 架构图代码。然后把生成的 XML 复制到 Draw.io 网页版的空白画布里，通常就能直接还原成图。
我的推荐工作流
如果你也想把这套流程用到日常工作里，可以从这个模板开始：
text
请使用 Draw.io MCP 生成一张 [图的类型]。
背景：
[简单介绍业务/系统/流程背景]
需要包含的元素：
1. [模块 A]
2. [模块 B]
3. [模块 C]
元素之间的关系：
- [A 如何连接 B]
- [B 如何连接 C]
- [哪些是输入，哪些是输出]
画图要求：
- 使用 [横向/纵向] 布局
- 用 [流程图/架构图/泳道图/UML] 形式表达
- 节点名称简短
- 连接线清晰
- 风格简洁，适合技术文档
- 生成后在 Draw.io 中打开，方便继续编辑这套模板的好处是，它把"语义"和"视觉要求"分开了。
前半部分告诉 AI：你到底要画什么；后半部分告诉 AI：你希望它怎么画。
对 AI 画图来说，这比一句"帮我画得好看一点"要稳定得多。
最后
我现在越来越觉得，AI 画图最适合解决的不是"最终设计稿"，而是"把复杂关系快速结构化"。
尤其是架构图、流程图、UML、泳道图这类图，真正耗时间的往往不是拖拽形状，而是先把信息关系整理清楚。
Codex × Draw.io MCP 的价值就在这里：它可以先帮你把图的骨架搭出来。你再根据实际表达需要，做最后一层人类审美和判断。
如果你经常写技术方案、项目复盘、系统设计文档，真的可以试试这套工作流。
先别追求一次生成完美。
让 AI 先画出第一版，然后你再改。这样就已经比从空白画布开始快很多了。