聊个很实际的场景:方案评审前一天晚上,产品经理发来一句"把新用户注册流程的图补一下"。你打开绘图软件,拖了二十分钟框,又花十分钟对齐、绕连线——真正让人头疼的不是画图本身,而是图的格式离"能被别人继续改"差得太远。我后来试了一圈工具,最后把画图工作流稳定成了"描述需求 → 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 作为中间
