架构图这件事，画过的人都懂那种痛。需求评审前夜，白板上画了三版，拍照存下来，第二天打开绘图工具准备重画，发现连线对不齐、框大小不一、箭头方向全乱。更别提改需求的时候，一个模块挪位置，牵动十几条线重排。我见过太多团队把架构图当成"一次性消耗品"——画完就扔，因为维护成本比重新画还高。这两年 AI 辅助编码工具起来了，很多人拿它写代码、补测试、生成文档，但真正让我觉得"回不去"的场景，是让它直接产出可编辑的架构图源文件。这篇就聊我实际跑通的一套组合：用 Codex 这类代码智能体，配合 Draw.io 的 MCP 服务，把一句自然语言描述变成一张能在 Draw.io 里继续拖拽修改的图。适合谁看？写过几行代码、被架构图折磨过、想把这套流程固化下来的同学；完全没接触过 MCP 的也能跟，我会把每个环节为什么这么设计讲清楚。

1. 为什么是"生成源文件"而不是"生成图片"

先说一个很多人踩过的认知坑。市面上不少 AI 画图工具，输出的是 PNG 或 SVG 图片。看起来很美，实际用起来是灾难——图片是死的，改一个框里的文字要重新生成整张图，改完风格还可能漂移。架构图的核心价值从来不是"好看"，而是"可维护"。一张架构图在项目生命周期里要改几十次，每次改动都应该是在原有结构上做增量，而不是推倒重来。

Draw.io 的源文件格式是 XML（压缩后是.drawio或未压缩的.xml），本质是一堆节点和边的结构化描述。这意味着只要 AI 能输出合法的 XML，我们拿到的就是一张"活"的图：每个矩形、每条连线都是独立对象，可以在 Draw.io 里继续调样式、改文字、加注释。这是整套方案成立的第一块基石。

那为什么不让 AI 直接吐 XML 就完事，非要绕一层 MCP？这里要解释一下 MCP 是什么。MCP（Model Context Protocol）可以理解成给 AI 智能体装的一套"标准插座"——它规定了 AI 怎么调用外部工具、怎么传参、怎么拿回结果。没有 MCP 的时候，你得手动把 AI 生成的 XML 复制粘贴到文件里，再打开 Draw.io 验证，来回折腾。有了 MCP，AI 可以直接调用 Draw.io 暴露出来的工具接口，把图"画"进去，甚至能读回当前画布状态做二次修改。省掉的是中间那段最烦人的搬运和校验。

我实测下来，直接让模型裸写 XML 的失败率相当高——标签闭合错、坐标重叠、连线锚点乱指，十次里能有三四次需要人工修。走 MCP 之后，工具层会做一些参数校验和结构约束，成功率明显上来了。这个差异后面第 4 节会展开讲。

还有一个现实考量：团队协作。XML 源文件能进 Git，能 diff，能 code review。图片不行。你把架构图当代码管，评审时能看到"这次改动新增了一个缓存层、删掉了两条直连"，这种颗粒度是图片给不了的。所以整套方案的目标从一开始就定死了：产出可版本管理的源文件，而不是截图。

2. 环境搭建：把三个部件接起来

这套流程涉及三个角色：代码智能体（Codex 侧）、MCP 服务端（桥接层）、Draw.io（渲染与编辑端）。三者怎么连，决定了后面顺不顺。我按实际搭建顺序讲，每一步说清楚为什么这么配。

2.1 智能体侧的配置逻辑

Codex 这类工具通常通过一个配置文件声明可用的 MCP 服务。核心是告诉它：有这么个服务，叫什么名字，用什么方式启动，需要哪些参数。配置项一般长这样（不同工具字段名略有差异，但结构一致）：

{ "mcpServers": { "drawio": { "command": "node", "args": ["/path/to/drawio-mcp-server/index.js"], "env": { "DRAWIO_OUTPUT_DIR": "/path/to/diagrams" } } } }

这里有几个容易翻车的点。第一，command和args必须是绝对路径或者确保在 PATH 里能找到，相对路径在不同工作目录下启动会失效，我一开始就栽在这。第二，env里指定的输出目录要提前建好，服务端不一定帮你创建，目录不存在时写入会静默失败或者报个很隐晦的错。第三，改完配置要重启智能体会话，热加载不一定生效，别改完发现没反应就怀疑人生。

提示：配置里的服务名（上面是drawio）后面在对话里调用工具时会用到，起个短好记的，别用带空格或特殊字符的名字。

为什么用node启动而不是别的？因为多数现成的 Draw.io MCP 实现是 Node 写的，生态成熟、依赖好装。如果你团队统一用 Python，也有对应实现，选型时优先看维护活跃度和 issue 响应速度，别只看 star 数。

2.2 服务端的职责边界

MCP 服务端不是"画图引擎"，它更像一个翻译官加质检员。它接收智能体传来的结构化描述（比如"创建一个矩形，标签是 API 网关，位置在 x=100,y=50"），转换成 Draw.io 能识别的 XML 片段，写进文件，必要时还能读回文件解析成结构化数据返回给智能体。

理解这个边界很重要，因为它决定了你该期待什么、不该期待什么。服务端通常不负责"布局美观"——它不会自动帮你把节点排成漂亮的层次结构，那是智能体该干的活（通过合理的坐标规划）。服务端也不负责"语义理解"——你说"画个微服务架构"，它不知道微服务长啥样，得靠智能体把这句话拆成具体的节点和连线指令。

我见过有人抱怨"用了 MCP 画出来的图还是很丑"，问题往往出在智能体那侧的坐标规划没做好，而不是服务端不行。这个分工要在脑子里分清。

2.3 Draw.io 端的两种接入姿势

Draw.io 有两种用法：桌面版和网页版。MCP 方案通常操作的是文件系统里的.drawio文件，所以跟具体用哪个客户端关系不大——生成完文件，你用桌面版打开、用网页版导入都行。

但有个细节值得说：如果你希望"边生成边看"，可以让服务端把文件写到一个固定目录，然后用 Draw.io 桌面版打开这个文件，它支持文件变更自动重载（部分版本需要手动刷新）。这样智能体每写一次，你切过去就能看到最新状态，调试体验好很多。网页版就得手动重新导入，来回几次就烦了。

另外，.drawio文件本质是压缩的 XML。调试阶段建议让服务端输出未压缩的.xml，出问题时能直接文本编辑器打开看结构，定位是哪个节点写错了。等流程稳定了再切回压缩格式减小体积。

3. 从一句话到一张图：提示词怎么写才不返工

环境通了只是开始，真正决定产出质量的是你怎么跟智能体说话。我试过几十次，总结下来，好的提示词不是"描述得越详细越好"，而是"把结构约束和视觉约束分开说清楚"。

3.1 结构描述的三段式

我习惯把需求拆成三段：分层、节点、关系。举个例子，要画一个典型的 Web 应用架构：

第一段说分层。"这张图分四层，从上到下依次是：接入层、应用层、数据层、基础设施层。"分层信息决定了纵向的坐标区间，智能体据此给每层分配 y 轴范围，避免节点全挤在一起。

第二段说节点。"接入层放两个节点：负载均衡、API 网关。应用层放三个：用户服务、订单服务、支付服务。数据层放两个：主库、缓存。基础设施层放一个：消息队列。"每个节点给个明确的名字，别用"一些服务"这种模糊表述，模型会自由发挥。

第三段说关系。"负载均衡指向 API 网关；API 网关分别指向三个应用服务；三个应用服务都指向主库；用户服务和订单服务指向缓存；订单服务指向消息队列。"关系用"指向"这种明确动词，比"连接"更不容易产生歧义。

三段式的好处是可复用。换个系统，你只改节点名和关系，骨架不变。我把它存成了模板，每次改改就能用。

3.2 视觉约束要单独交代

结构说清楚了，图可能还是丑——因为模型不知道你要什么风格。视觉约束我一般单独列一段：

• 节点统一用圆角矩形，宽 160 高 60，这是经验值，太小放不下中文标签，太大浪费空间
• 同层节点水平等距排列，间距 40
• 层与层之间垂直间距 80
• 连线用正交折线（orthogonal），别用直线，直线在多层架构里会穿过节点
• 箭头统一指向目标节点顶部或左侧，避免箭头方向混乱

这些数值不是拍脑袋。160×60 是中文标签在默认字号下比较舒服的尺寸；间距 40 保证连线有折弯空间又不至于太散；正交折线是架构图的标准画法，斜线看着乱。把这些写进提示词，产出的一次通过率能高不少。

注意：不同模型对数值约束的遵守程度不一样。有的模型会把"间距 40"理解成"大概 40 左右"，实际给你 35 或 50。如果对整齐度要求高，可以在提示词里加一句"严格使用给定坐标，不要自行调整"，或者干脆让它先输出坐标规划表，你确认后再让它落图。

3.3 让智能体先出"坐标规划"再落图

这是我踩坑之后养成的最有用的习惯。直接让模型画图，它经常边想边画，画到一半发现空间不够，开始压缩间距或者重叠节点。改成两步走：第一步让它输出一张表，列出每个节点的名称、层级、x 坐标、y 坐标；第二步你扫一眼这张表，确认没有重叠、间距合理，再让它按表生成 XML。

坐标规划表大概长这样：

一眼就能看出问题：如果两个节点 x 差小于节点宽度，就会重叠。这种检查比看最终图快得多。确认无误后，把表喂回去让它生成，返工率大幅下降。

4. 实测中最容易翻车的四个地方

前面讲的是"应该怎么做"，这一节讲"实际会怎么坏"。这些都是我在真实项目里撞过的墙，按出现频率排序。

4.1 连线锚点乱指导致箭头穿框

这是最高频的问题。Draw.io 的连线需要指定起点和终点锚点（source 和 target 的 connection point）。如果智能体只给了"从 A 连到 B"，没指定锚点，服务端可能默认连到节点中心，结果线从框中间穿过去，视觉上非常乱。

解决办法是在提示词里明确要求锚点策略。我常用的策略是：纵向关系（上层到下层）用"底部中心到顶部中心"，横向关系（同层之间）用"右侧中心到左侧中心"。对应到 Draw.io 的锚点标识大概是exitX=0.5,exitY=1到entryX=0.5,entryY=0这种。让智能体在生成连线时带上这些参数，穿框问题基本消失。

如果模型不听话，还有个兜底方案：生成完之后在 Draw.io 里全选连线，右键"重置连线样式"，它会按最短路径重新走线，能救回大部分。

4.2 中文标签宽度估算错误

英文标签和中文标签的宽度差异很大。模型如果按英文字符数估算宽度，中文标签会溢出框外。比如"用户服务"四个字，按英文算可能觉得 80 宽够了，实际中文需要 100 以上。

我的做法是直接在提示词里给死宽度：所有节点统一 160 宽，标签超过 6 个中文字符的，要么换行要么缩小字号。统一宽度还有个好处——图看起来整齐，这是架构图的基本审美。

4.3 层级坐标算错导致整体错位

多层架构里，每层的 y 坐标要严格递增，且增量要大于节点高度加间距。如果模型算错，比如第二层 y 只比第一层大 50，而节点高 60，两层就叠在一起了。

这个问题的根因是模型在做加法时"心算"出错。对策还是那个——先出坐标表。表里 y 值一目了然，叠没叠一眼看穿。另外可以在提示词里给个公式："第 n 层 y = 40 + (n-1) × (60 + 80)"，让它按公式算而不是自由发挥，准确率高很多。

4.4 生成成功但文件打不开

偶尔会遇到 XML 结构合法但 Draw.io 打不开的情况，通常是根元素或命名空间写错了。Draw.io 的根结构有固定要求，<mxGraphModel>下面套<root>，<root>里必须有 id 为 0 和 1 的两个基础单元格，少了这两个，文件就废了。

排查方法：用文本编辑器打开生成的 XML，检查开头几行。正常的结构大概是这样：

<mxGraphModel> <root> <mxCell id="0"/> <mxCell id="1" parent="0"/> <!-- 你的节点从这里开始 --> </root> </mxGraphModel>

如果缺了 id=0 或 id=1 的单元格，手动补上通常就能打开。这个坑比较隐蔽，因为文件大小、标签闭合都正常，就是打不开，第一次遇到会懵。

5. 把一次性生成变成可迭代的工作流

单次生成能跑通只是及格线。真正提升效率的，是让这套流程支持"改图"——需求变了，不是重画，而是在原图上增量修改。这一节讲怎么做到。

5.1 让智能体读回现有图再改

MCP 服务端如果支持"读取"操作，就能实现增量修改。流程是：智能体先调用读取工具，拿到当前图的节点和连线列表，理解现状，然后只针对变化部分生成修改指令。比如"在应用层新增一个库存服务，放在订单服务右边，并让它指向主库"。

这比"重新生成整张图"靠谱得多，因为重新生成会丢失你手动调过的样式。我一般会在提示词里加一句"先读取现有图结构，只做增量修改，不要重建"。

如果服务端不支持读取，退而求其次：把现有 XML 作为上下文喂给智能体，让它输出修改后的完整 XML。缺点是 token 消耗大，图大了容易超上下文。所以选 MCP 实现时，"是否支持读取"是个重要考量点。

5.2 版本管理：把图当代码管

生成的.drawio或.xml文件直接进 Git。每次改动一个 commit，commit message 写清楚改了什么，比如"新增缓存层，调整数据层连线"。评审时 diff 能看出结构变化，虽然 XML diff 不如代码 diff 直观，但至少能看出节点增减。

有个小技巧：如果团队对图的可读性要求高，可以同时维护一份 Mermaid 或 PlantUML 的文本描述作为"图的注释"，XML 管渲染，文本管语义。两者一起进 Git，改的时候同步更新。这样新人看文本就能理解架构，不用去解析 XML。

5.3 样式模板的沉淀

反复生成会发现，每次都要交代一遍视觉约束很烦。解决办法是沉淀一个"样式前缀"提示词，把所有视觉规范固化进去，每次生成时拼在需求前面。我的样式前缀大概包含：节点尺寸、圆角、字体、配色（分层用不同底色）、连线样式、锚点策略。拼一次省几十次。

配色这块提一句：分层用不同底色能大幅提升可读性，但别用太饱和的颜色。我常用的是浅蓝、浅绿、浅灰这种低饱和度色，打印出来也清楚。具体色值让智能体用十六进制给，比如#dae8fc，比说"浅蓝色"精确。

6. 这套方案适合什么、不适合什么

最后说说边界，免得有人拿去用在不合适的场景然后骂街。

适合的场景：中大型系统的分层架构图、模块依赖图、部署拓扑图、流程图。这些图结构规整、节点数量适中（几十个以内）、关系明确，AI 生成的成功率高，改起来也方便。

不太适合的：高度定制化的视觉设计图（比如带插画风格的产品架构图）、节点上百的超大图（坐标规划容易崩，token 也吃不消）、需要精确对齐到像素的正式交付物（AI 生成的坐标总有几像素偏差，得手动微调）。

还有一个现实问题：模型能力差异。同一个提示词，强模型和弱模型产出质量差很多。我建议先用小图（五六个节点）测试你手头模型的"听话程度"，再决定要不要上大图。别一上来就让它画二十个节点的图，失败了很难定位是提示词问题还是模型能力问题。

我个人在实际操作中的体会是，这套流程最大的价值不是"省了画图的时间"，而是"让架构图重新变成可维护的资产"。以前图是消耗品，画完就烂在那；现在图跟着代码走，改需求顺手就改了。这个转变带来的协作收益，比单纯省几个小时画图时间大得多。如果你团队还在用截图传架构图，真的可以试试把源文件管起来，哪怕先不用 AI，手动画 XML 也比截图强。