歆格聊个很实际的场景：方案评审前一天晚上，产品经理发来一句"把新用户注册流程的图补一下"。你打开绘图软件，拖了二十分钟框，又花十分钟对齐、绕连线——真正让人头疼的不是画图本身，而是图的格式离"能被别人继续改"差得太远。我后来试了一圈工具，最后把画图工作流稳定成了"描述需求 → AI 生成 draw.io 文件 → 手动微调"这一条，用的就是 Next AI Draw.io 这类方案。它专门把流程图、时序图、架构图、UML 这些图形产出物变成可编辑的 draw.io 格式，而不是一张改不了的死图片。
这篇文章写给三类人：被评审图逼疯的产品和研发、想批量产出技术文档图的工程师，以及想在团队里落地"图表即代码"的管理者。全文不聊玄乎的概念，只讲清楚这个工具为什么值得用、内部是怎么运转的、实际生成时有哪些坑，以及怎么把它接进日常工作流。
1. 为什么是 Draw.io：AI 绘图的格式困局
1.1 大多数"AI 画图"的问题不是画不出来，而是画完没法改
先说一个反直觉的结论：让 AI 画一张图，现在太容易了；难的是画完之后你想改一个节点的文字，却发现根本无从下手。
市面上很多 AI 绘图工具走的是"图片生成"路线，输出 PNG 或 JPEG。这类图好看，但严格来说是一次性的。业务流程图这种东西，需求一变就要改，改完还要重新导出、重新传，痛点全在维护环节。还有一类工具走 Mermaid 或者 PlantUML 文本路线，用文字描述图，渲染也方便，但遇到复杂架构图就露怯：坐标控制不了，布局经常乱，想精确表达"这个服务部署在哪个子网里"很费劲。
Next AI Draw.io 选择的路线是第三种：直接生成 draw.io 的 .drawio 文件。这个词听起来像某个小众工具，其实它就是 diagrams.net 的开源桌面版/网页版使用的原生产物。draw.io 的文件本质是一个 XML 文本文件，里面记录了每个节点的坐标、样式、连线关系。它既有文本格式的版本管理优势，又有可视化编辑器的完整能力，正好卡在"可维护"和"可绘制"中间。加上 AI 生成的是 XML 文本，模型天然擅长输出这种结构化内容，这条路明显比生成图片再 OCR 识别要靠谱得多。
1.2 draw.io 格式好在哪：纯 XML、可 diff、可嵌入、免费
我特别吃 draw.io 的一点是它的文件足够"透明"。一个 .drawio 文件用记事本打开能看到全部门道，节点是 <mxCell>，边是 <edge>，坐标写在 <mxGeometry> 里，结构清清楚楚。这意味着你可以直接把它放进 Git 仓库，每次改动都能 diff，哪个节点变了、哪根线被挪了，在代码评审里一目了然。这是 Mermaid 和图片方案都比不了的优势——Mermaid 能 diff 文本但画不出复杂布局，图片干脆没法 diff。
另外它对工具链非常友好。Obsidian 里有插件能直接内嵌显示 .drawio 文件，GitHub 和 GitLab 的 Markdown 预览也能渲染这类 XML，团队写技术文档时不用反复导图片。而且它是免费的，桌面客户端、网页版、VS Code 插件都有，跨平台没有授权成本。
1.3 Next AI Draw.io 的定位与整体工作流程
把 Next AI Draw.io 理解成一个"翻译层"就够了：它把用户的需求描述翻译成 draw.io 可以识别的 XML。用户输入自然语言，比如"画一个用户登录流程图，包含验证码、账号密码、微信扫码三种方式，登录失败要返回重试"，它调用大模型生成对应的 .drawio 内容，最后输出文件，用户可以在 draw.io 里打开继续编辑。
整体链路大致是这样：前端页面收集提示词 → 后端请求大模型接口，要求模型输出 mxGraph 格式的 XML → 把 XML 保存为 .drawio 文件，或者直接返回给前端预览。这个流程看似简单，真正有门槛的地方在模型提示词设计、XML 结构校验、以及生成后的布局优化，后面几章会逐一展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心链路拆解：从自然语言到一张可编辑的图
2.1 大模型输出图表的三条技术路线
让模型输出一张图，其实有好几条路可选，Next AI Draw.io 这类项目在不同版本里也走过不同方案，我给它们排个序：
- 直接输出 mxGraph XML：最省事，模型一次返回完整的 .drawio 内容。缺点是对模型的 XML 规范理解要求高，一旦格式出错，整个文件打不开，排查起来费劲。
- 先输出中间 JSON，再序列化成 XML：模型先生成
{nodes: [...], edges: [...]}这种结构化描述，再由一段固定代码把 JSON 转成 mxGraph XML。这样做的好处是 JSON 简单、容易验证，可以单独为 nodes 和 edges 做重试，布局信息也可以后处理。这是当前很多实现里更稳妥的做法。 - 通过 Function Calling 调用专门的绘图函数：模型不是直接输出图，而是"决定"调用某个生成函数，把参数传过去。这种路线适合把绘图能力嵌入 Agent，让 AI 自主判断"这里应该生成一张时序图"。
从我实际观察来看，第二个方案在工程上最干净。因为 XML 格式一旦嵌套错误就容易整体不可用，而 JSON 作为中间层，容错性高得多；等 JSON 校验通过，再走一段序列化逻辑，出错的概率就被大大压缩了。
2.2 mxGraph 模型里不可不知的标签：mxCell、vertex、edge
无论走哪条路线，最终产出的文件都是 mxGraph 模型。mxGraph 是 draw.io 底层的图形库，它的 XML 结构其实不复杂，核心就几个概念：
| 元素 | 角色 | 说明 |
|---|---|---|
<mxfile> |
文件容器 | 整个 .drawio 文件的根节点 |
<diagram> |
单个图表 | 一个文件可以含多个图 |
<mxGraphModel> |
画布模型 | 定义画布尺寸、网格等属性 |
<root> |
对象容器 | 所有节点和连线都挂在 root 下 |
<mxCell> |
节点/连线/图层 | 通过 vertex 和 edge 属性区分 |
<mxGeometry> |
几何信息 | 节点坐标和宽高，或连线的路径 |
一张图里真正干活的是一个个 <mxCell>。它有两种主要身份：vertex="1" 代表节点，edge="1" 代表连线。节点之间的连接关系不靠坐标推断，而是靠 source 和 target 属性明确指定两个节点 id。理解了这一点，你就明白为什么 AI 生成连线总出错了——它得先保证每个 id 都存在，并且 source/target 的方向语义正确。
2.3 一个最小可用的 .drawio 文件长什么样
直接看一个最简单的例子。假设要画一个"开始 → 判断用户名是否存在 → 结束"的小流程，生成的 XML 大致如下：
xml复制<mxfile host="app.diagrams.net">
<diagram id="login-flow" name="登录流程">
<mxGraphModel dx="800" dy="600" grid="1" gridSize="10"
guides="1" tooltips="1" connect="1" arrows="1" fold="1"
page="1" pageScale="1" pageWidth="1169" pageHeight="826">
<root>
<mxCell id="0" />
<mxCell id="1" parent="0" />
<mxCell id="start" value="开始"
style="rounded=1;whiteSpace=wrap;html=1;"
vertex="1" parent="1">
<mxGeometry x="40" y="40" width="120" height="40" as="geometry" />
</mxCell>
<mxCell id="check" value="用户名是否存在？"
style="rhombus;whiteSpace=wrap;html=1;"
vertex="1" parent="1">
<mxGeometry x="160" y="120" width="160" height="80" as="geometry" />
</mxCell>
<mxCell id="end" value="结束"
style="rounded=1;whiteSpace=wrap;html=1;"
vertex="1" parent="1">
<mxGeometry x="200" y="260" width="120" height="40" as="geometry" />
</mxCell>
<mxCell id="e1" edge="1" parent="1" source="start" target="check"
style="edgeStyle=orthogonalEdgeStyle;rounded=0;">
<mxGeometry relative="1" as="geometry" />
</mxCell>
<mxCell id="e2" edge="1" parent="1" source="check" target="end"
style="edgeStyle=orthogonalEdgeStyle;rounded=0;">
<mxGeometry relative="1" as="geometry" />
</mxCell>
</root>
</mxGraphModel>
</diagram>
</mxfile>
几个关键点：style 里 rounded=1 让节点变成圆角矩形，rhombus 让节点变成菱形判断框，edgeStyle=orthogonalEdgeStyle 让连线走直角，而不是直线穿过其他节点。这些样式名在提示词里如果能写清楚，生成质量会直接上一个档次。
3. 实操：部署并生成第一张流程图和时序图
3.1 环境准备与启动
先说部署。Next AI Draw.io 这类基于 Next.js 的项目，跑起来跟普通 Node 项目差不多，最省心的流程是：
- 把项目拉到本地，检查 Node.js 版本在 18 以上；
- 执行
npm install安装依赖； - 在项目根目录创建
.env.local，配置大模型服务的 API Key； - 执行
npm run dev启动开发服务，浏览器打开本地地址。
如果只是临时用，也可以不部署完整项目，直接把生成逻辑封装成一段 Node 脚本，调用大模型接口后把返回的 XML 存成 .drawio 文件。我个人更喜欢这个轻量路子，因为它不用开 Web UI，适合写进自动化脚本里。环境准备阶段最容易忽略的是 API Key 的权限配置，很多模型接口默认不开"结构化输出"能力，需要在请求参数里显式开启。
3.2 配置模型服务
配置这一块，大部分项目默认读取环境变量里的 API Key，比如 OPENAI_API_KEY。除此之外，有几个参数值得调：temperature 要设低，最好在 0 到 0.3 之间，画图是结构化任务，温度太高会让模型自由发挥，输出不可预期的节点；max_tokens 要设大，复杂架构图的 XML 很容易超过 2000 token，默认值经常会截断。
如果你用的是支持"JSON Output Mode"的模型，建议在系统提示词里要求它先输出 JSON，再转 XML。如果不支持 JSON mode，也可以在提示词里强制写"只输出 XML，不要解释"，然后用代码把返回答头去尾再解析。
3.3 实际案例：用户登录流程图
下面是我实际跑通过的一个提示词模板，目标产物是"用户登录流程图"：
text复制请生成一个 draw.io 可识别的 mxGraph XML，绘制用户登录流程图。
要求：
1. 开始节点为圆角矩形，判断节点为菱形。
2. 流程：开始 → 输入账号密码 → 判断账号是否存在 → 判断密码是否正确 → 登录成功 / 失败返回重试。
3. 所有连线用 orthogonalEdgeStyle，方向从上到下。
4. 节点间距不小于 40。
5. 直接输出完整 XML，不要加解释。
模型返回的 XML 通常会比上一章那个最小示例完整得多，节点数在 6 到 10 个之间，坐标也能自动铺开。拿到文件后，在 draw.io 里通过 File > Open 打开，或者直接拖进浏览器画布，就能看到结构完整的流程图。
第一次跑通时你大概率会遇到一个问题：节点位置不理想。有的节点叠在一起，有的连线绕了远路。解决办法不是回去改提示词，而是直接用 draw.io 自带的自动布局功能。在编辑器里全选节点，点 Arrange > Layout，选一个合适的布局算法（垂直树、水平树、分层布局都可以），它会自动把节点摊开。AI 画图负责结构，布局交给算法，这是最高效的分工。
3.4 时序图案例与参与者语义
时序图比流程图更讲究"角色"和"顺序"。要让 AI 画好时序图，必须在提示词里把参与者、消息顺序、同步/异步关系说清楚。一个典型的提示词长这样：
text复制生成一个用户登录的时序图，参与者：用户、前端、后端、数据库。
消息顺序：
1. 用户→前端：提交账号密码
2. 前端→后端：POST /login
3. 后端→数据库：查询用户
4. 数据库→后端：返回用户信息
5. 后端→前端：登录成功
其中 3 是同步消息，用实线箭头；如果登录失败，后端→前端返回错误码 401。
时序图生成完，最常见的检查点是消息箭头的方向和同步/异步线型。在 mxGraph 里，同步调用一般是实线实心箭头，异步消息是实线开放箭头或虚线箭头。这两类信息在 XML 里靠 endArrow=block / endArrow=open 等样式控制。生成后如果发现箭头不对，不用重新生成整个图，直接在 draw.io 里双击连线改样式即可，这也是我不推荐一遇到问题就重画的原因。
4. 四类图表的提示词策略与模板
4.1 流程图：顺序、分支、泳道
流程图的提示词核心有三块：节点的类型语义、分支条件、泳道归属。
先讲节点形状语义，这是新手最容易忽略的。矩形表示处理动作，菱形表示判断，圆角矩形表示开始或结束，平行四边形表示输入输出，带折线的矩形表示文档。如果提示词里不指定形状，模型大概率把所有节点都画成普通矩形，整张图虽然没错，但可读性差很多。
泳道（Swimlane）是一个加分项。如果业务里有不同角色参与同一流程，建议在提示词里写明"用两个泳道分别表示前端和后端"。在 mxGraph 里泳道是一个宽度很大的容器节点，其他节点通过 parent 属性挂到它下面。让模型正确理解这种父子关系并不容易，所以更稳的做法是让模型把泳道设计为一个 swimlane 样式节点，并在提示词里说明"属于前端的节点 parent 都是前端泳道节点"。
4.2 时序图：参与者、消息、生命线
时序图提示词的关键词是"顺序"。模型对顺序的理解依赖你描述消息时的编号，如果用"然后"这类模糊词，它容易漏消息。我一般把消息写成编号列表，同时在提示词里显式声明"从 1 开始递增，不要跳过编号"。
参与者数量也要控制。一次生成超过 6 个参与者，布局会非常拥挤，生命线会挤成一团。如果系统里有 8 个服务在交互，建议拆成两张时序图，或者先用一个总览图展示服务间粗粒度调用关系，再为关键路径单独画细节时序图。画时序图的核心不是把所有消息堆在一张图里，而是让人一眼看出"一次请求经过哪些环节"。
4.3 架构图：分层、组件、连线方向
架构图和流程图不太一样，它的重点在容器关系和连接语义。绘图时经常用矩形框表示一个系统层级，比如"前端层""网关层""服务层""数据层"，里面再放组件。提示词里要明确层级关系和方向：是从上往下分层，还是从左往右分层；连线代表"调用"还是"依赖"还是"数据流"。
我常用的架构图提示词模板长这样：
text复制生成一个微服务架构图，从上到下分为四层：
1. 接入层：Nginx、API 网关
2. 服务层：用户服务、订单服务、支付服务
3. 中间件：Redis、RabbitMQ
4. 数据层：MySQL、Elasticsearch
接入层与服务层之间用实线箭头表示调用，服务层与中间件之间用虚线箭头表示依赖。
所有节点都用带阴影的矩形，服务层节点保持同一套配色。
"配色"这个要求模型也能响应，在样式里指定 fillColor=#dae8fc、strokeColor=#6c8ebf 这类值即可。架构图最容易翻车的地方是连线跨层乱穿，解决方法是让模型先生成分层布局的中间 JSON，再转成 XML，并关闭无关的自动连线段。
4.4 UML：关系类型的精确表达
UML 类图对关系语义的要求最高。继承、实现、聚合、组合、依赖，每种关系在 draw.io 里的箭头样式都不一样：
| 关系 | 说明 | draw.io 箭头样式 |
|---|---|---|
| 继承 | 子类继承父类 | 空心三角箭头（实线） |
| 实现 | 类实现接口 | 空心三角箭头（虚线） |
| 组合 | 强拥有关系 | 实心菱形 + 实线 |
| 聚合 | 弱拥有关系 | 空心菱形 + 实线 |
| 依赖 | 临时使用关系 | 开放箭头 + 虚线 |
提示词里如果不把关系名称和箭头样式绑定，模型输出的箭头经常张冠李戴。我一般会写"以下所有继承关系的连线都用空心三角箭头，禁止使用实心箭头"。生成后还得人工核对一遍，因为 UML 关系是语义级正确性问题，光看布局没用。
四种图的提示词策略，用一张表总结：
| 图表类型 | 提示词必备要素 | 最容易踩的坑 |
|---|---|---|
| 流程图 | 节点形状、分支条件、泳道 | 判断节点画成矩形 |
| 时序图 | 参与者、消息编号、同步/异步 | 箭头线型错乱 |
| 架构图 | 层级顺序、连线语义、配色 | 跨层连线乱穿 |
| UML | 类名、方法、关系类型 | 关系箭头张冠李戴 |
5. 实测排查：AI 生成的图为什么总差一步
5.1 布局混乱：节点叠压与自动布局的补救
AI 生成图表最大的问题不是结构，是空间感。大模型本质上是文本模型，它对画布坐标的感知来自训练语料里的坐标数值，经常出现两个节点算出相同坐标的情况。节点叠压、间距失控，是老生常谈的问题。
我的处理顺序很固定：先在提示词里严格要求"每个节点坐标必须是网格对齐的整数，相邻节点至少间隔 40px"；如果生成后还是乱，就直接用 draw.io 的自动布局算法，全选节点，点 Arrange > Layout，选分层或树形布局。这两个手段加起来能解决九成布局问题。如果你在集成开发，建议在序列化阶段引入一个轻量布局引擎，把中间 JSON 里的坐标全部重算，让布局和人眼审美解耦。
5.2 连线上穿下绕：方向、锚点与 Label 问题
连线是第二个高频翻车点。最常见的现象：A 和 B 明明在左中右，连线却从左下方穿出去绕一整圈再回来。原因是模型生成的 source 和 target 可能只保证 id 对了，但两个节点的相对位置和连线路径没有配合。另一个问题是连线上的文字标签（比如分支条件"是/否"）位置乱跑，甚至跑到线上之外。
提示词层面的解法是：强制使用 edgeStyle=orthogonalEdgeStyle;rounded=0; 加 exitX 和 entryY 控制出点和入点，让连线从节点右侧出去、左侧进来，避免下穿上绕。字符标签要单独用一个 mxCell 挂到连线旁，或者让模型在 value 里写清楚，再由前端做定位。
5.3 中文乱码：字体族与全局样式
中文乱码这个问题，国内用这套方案的人基本都会遇到。原因是 draw.io 里某些默认字体（比如 Helvetica）对中文支持不完整，打开后显示成一堆方框。解决办法不是在提示词里说"使用中文字体"，而是要精确指定 fontFamily。
在节点 style 里加 fontFamily=Microsoft YaHei;（Windows）或 fontFamily=Noto Sans CJK SC;（macOS/Linux），或者在 mxGraphModel 里设置默认样式，让全图统一字体。还有一个更省事的办法：在 draw.io 的样式模板里改一次全局字体，再保存为自定义样式，后续生成完批量套用。
5.4 复杂图截断：token 上限与分步生成
一个真实的微服务架构图，节点 30 个，连线 40 条，对应的 XML 很容易超过 6000 token。大模型输出一旦超过 max_tokens 上限就直接截断，返回给你的是一段不完整的 XML，draw.io 打开直接报错。
应对策略有三条：一是用支持更大输出上下文的模型，输出窗口最好在 8K token 以上；二是把图拆成多张子图，每张 10 个节点以内，生成后用合并逻辑把它们拼到同一张画布；三是在提示词里要求模型简化冗余 style，比如多个节点共享同一样式字符串，去掉重复的 whiteSpace=wrap;html=1; 这类不影响结构的属性。我现在的习惯是：超过 15 个节点的图，一律分两次生成，一次画结构，一次补细节，宁可多花时间也避免半截文件。
6. 进阶：把 AI 画图接入真实工作流
6.1 与 Hermes Agent 等智能体对接的实现思路
热搜里有一个问题是"Next AI Draw.io 是否支持与 Hermes Agent 对接"。直接回答的话，"是否支持"本质上取决于项目是否暴露了可编程接口，而不是一个非黑即白的开关。只要绘图能力被封装成 API 或者命令行工具，任何具备工具调用能力的 Agent 都能接进来。
实际对接时，我会先把绘图服务包装成一个工具函数，比如 generate_diagram(description, diagram_type)，Agent 在需要展示流程时自动调用这个工具，拿到 .drawio 文件路径后再做后续处理。关键点在于工具入参设计得越结构化，Agent 的调用越稳定。建议入参包含 diagram_type（流程/时序/架构/UML）、description、style_preferences 这三个字段，而不是让 Agent 传一段自由文本。这样即使日后换模型服务，接口定义也不用变。
6.2 纳入 Git 版本管理：图表可审查可对比
把图纳入 Git 仓库之后，最爽的是能做变更审查。产品经理改了一个判断分支，你在代码评审里能看到对应的 XML diff：新增了一个 mxCell，加了一条从 A 到 B 的边。这个能力是图片方案永远给不了的。
但纯 XML diff 也有噪音，因为每次用 draw.io 手动微调坐标，会改动大量 mxGeometry 数值，diff 看下来满屏坐标变化。我的惯例是：一个图一个文件，统一命名规范；提醒团队成员尽量少在 draw.io 里拖位置，要改结构就改提示词重新生成，或者只控制结构不改坐标。如果你的团队对图的变更频率很高，还可以写一个 CI 脚本，检测 .drawio 文件是否有新的有效 mxCell 被加入，自动提醒评审人重点关注结构变化。
6.3 团队模板库与批量出图
用 AI 画图最容易被低估的价值是批量。手动画一张架构图要半小时，脚本批量生成十张模块时序图只需要跑一次循环。
要在团队里落地批量出图，前提是沉淀一套模板库。把公司常用的前端配色、网关样式、数据库图标样式统一成一段段提示词片段，每次生成时自动拼进提示词。比如公司内部统一用蓝色系表示前端、绿色系表示后端，那提示词里就固定注入 fillColor=#dae8fc 和 fillColor=#d5e8d4。这套东西维护得越好，AI 生成的图就越接近团队规范。
批量脚本的骨架大致是这样：
bash复制for item in $(cat diagram-list.txt); do
curl -X POST http://localhost:3000/api/generate \
-H "Content-Type: application/json" \
-d "{\"type\": \"sequence\", \"description\": \"$item\"}" \
-o "output/$item.drawio"
done
6.4 和 Obsidian、在线协作文档的联动方式
最后说一个很多笔记用户关心的联动。Obsidian 里装一个 Draw.io 插件，就能直接渲染 .drawio 文件，还可以把图嵌到 Markdown 笔记里，和周边文字排在一起。在本地写完架构方案，旁边就是一张可交互的架构图，比贴一张截图体验好太多。
在线协作文档方面，draw.io 可以导出高清 PNG 和 SVG 放进展会材料里，但源文件一定要保留。AI 生成的图只是初稿，真正定稿需要人工修改的地方仍然不少，保留源文件才能持续迭代。
我自己的习惯是：每张图同时维护"源文件版本"和"图片版本"，源文件进 Git，图片进文档。评审时看图片，改方案时改源文件，AI 只负责把第一版草稿拉出来。这个习惯坚持了半年，画图的效率提升很明显，更重要的是再也没有人拿着一版截图问我"这个框在哪里改"了。