画流程图、架构图、UML 图时，真正耗时间的往往不是理解业务，而是重复性的绘图动作：拖组件、摆位置、连线、调颜色、对齐、改文案。图越复杂，越容易在细节上消耗精力。
Next AI Draw.io 解决的正是这个问题。它是一个基于 Next.js 的开源应用，把大语言模型（LLM，Large Language Model）接到 Draw.io 上，让 AI 根据自然语言或截图生成 Draw.io 可识别的 XML 图表文件。生成后的图不是一张静态图片，而是可以继续拖拽、编辑、保存的矢量图。
项目地址：
https://github.com/DayuanJiang/next-ai-draw-io
它解决的核心问题
传统画图工具需要人手动完成所有布局和连线，AI 绘图工具又经常只生成一张不可编辑的图片。Next AI Draw.io 的关键点在于：它生成的是 Draw.io 图表结构，而不是普通位图。
这意味着一次生成之后，后续仍然可以像平时使用 Draw.io 一样继续编辑：
- 调整节点位置；
- 修改文字；
- 改颜色和边框；
- 重新连接线条；
- 使用云厂商图标库；
- 导出 Draw.io 支持的格式。
自然语言生成图表的效果可以直接落到 Draw.io 编辑区，图里的节点、连线和布局都能继续调整。
这类工具最适合“先把图画出来”的场景。AI 负责生成大体结构，人再处理精确布局和视觉细节，比从空白画布开始拖组件快得多。
核心工作方式：让大模型输出 Draw.io XML
Draw.io 的图表底层可以用 XML 表示。一个节点的位置、大小、样式，以及连线的起点和终点，都可以写在 XML 结构里。Next AI Draw.io 的思路就是让大模型把用户需求转换成 Draw.io 能识别的结构化内容。
整体流程可以理解成这样：
flowchart LR
A[用户输入需求] --> B[Next.js 应用]
B --> C[调用大语言模型]
C --> D[生成或修改 Draw.io XML]
D --> E[Draw.io 渲染图表]
E --> F[用户继续编辑和导出]
如果用户输入的是一段文字，比如：
画一个电商下单流程图，包含用户、商品服务、订单服务、库存服务、支付服务和消息队列。
大模型需要完成几件事：
- 识别图里应该有哪些实体；
- 判断这些实体之间的调用关系；
- 生成节点、连线和文字；
- 给每个元素安排初始布局；
- 输出符合 Draw.io 格式要求的 XML。
这个过程的难点不只是“理解文字”，还包括“输出稳定的结构化文件”。如果 XML 标签不完整、节点 ID 引用错误、连线目标不存在，Draw.io 就可能无法正常打开或显示异常。因此模型的格式遵循能力会直接影响生成质量。
主要能力
1. Text-to-Diagram：用自然语言生成图表
Text-to-Diagram 是最核心的功能。用户描述想要的图，大模型把描述转换成 Draw.io 图表。
适合生成的内容包括：
| 图表类型 | 示例需求 |
|---|---|
| 流程图 | 登录流程、审批流程、订单状态流转 |
| 架构图 | 微服务架构、云上部署架构、数据同步架构 |
| UML 图 | 类图、组件图、时序关系草图 |
| 技术说明图 | 缓存读写流程、消息队列消费流程、权限校验链路 |
例如可以这样描述：
画一个用户登录认证流程：
1. 用户提交手机号和验证码；
2. 网关把请求转发给认证服务；
3. 认证服务校验验证码；
4. 校验通过后生成 JWT；
5. 客户端后续请求携带 JWT 访问业务服务。
生成出来的图通常可以作为初稿，再根据实际系统细节调整节点名称、布局和边界。
2. AI 辅助修改：像改需求一样改图
图表生成之后，并不需要重新开始。可以继续用自然语言要求 AI 修改现有图，例如：
把“订单服务”拆成“订单写服务”和“订单查询服务”，查询服务连接 Redis 缓存。
或者：
把支付服务的背景改成紫色，并把它放到订单服务右侧。
AI 辅助修改的价值在于减少重复操作。尤其是一个图已经有了十几个节点后，手动改结构往往会牵动很多线条；用自然语言描述修改目标，AI 可以基于当前图表上下文重新调整 XML。
下面的示例展示了基于已有图继续修改的过程，重点不是生成一张全新的图，而是在原有结构上做增删改。
不过这类修改仍然依赖模型对上下文和布局的理解。简单的颜色、文字、节点增删通常比较稳定；复杂重排、跨区域分组、精确对齐仍然更适合人工最后处理。
3. Image-to-Diagram：把草图或截图变成可编辑图
除了文字输入，Next AI Draw.io 还支持根据图片复刻图表。典型场景有两类：
- 白板上手画了一个草图，希望转换成正式架构图；
- 文档里看到一张图，希望变成可编辑的 Draw.io 文件。
这个能力可以称为 Image-to-Diagram。它的大致流程是：上传截图后，AI 识别图片里的节点、文字和连线，再重新生成 Draw.io XML。
flowchart LR
A[上传草图或截图] --> B[模型识别图中元素]
B --> C[提取节点、文字、连线关系]
C --> D[生成 Draw.io XML]
D --> E[得到可编辑矢量图]
这比“照着图片重新画一遍”省事很多。尤其是团队讨论时先在白板上快速画结构，讨论结束后再转成正式图表，可以减少整理成本。
4. 继承 Draw.io 的图标库和编辑能力
Next AI Draw.io 的优势不只在 AI，还在于它基于 Draw.io。Draw.io 本身已经是成熟的图表工具，内置了大量图形库，包括 AWS、GCP、Azure 等云厂商图标。
画云架构图时，这一点很重要。专业架构图通常不希望所有组件都只是一个写着名字的矩形，而是要使用对应云服务图标，比如负载均衡、对象存储、数据库、消息队列等。
AI 负责生成结构，Draw.io 负责承载图表编辑能力，两者组合起来比单纯生成图片更适合工程文档场景。
适合和不适合的场景
Next AI Draw.io 不是“按一下就得到完美架构图”的工具。它更适合生成初稿，而不是替代人对系统结构的判断。
| 场景 | 是否适合 | 原因 |
|---|---|---|
| 从 0 到 1 生成流程图初稿 | 适合 | 能快速列出节点和连线，减少重复绘图 |
| 画中等复杂度的系统架构图 | 适合 | 可以先生成大体结构，再人工调整 |
| 把白板草图整理成正式图 | 适合 | Image-to-Diagram 可以节省复刻时间 |
| 精确到像素级排版的图 | 不太适合 | AI 对空间布局的控制不如人工稳定 |
| 特别复杂的大型架构总览 | 不太适合一次生成 | 节点太多时容易布局混乱，适合拆成多个子图 |
| 强规范的正式交付图 | 适合作为初稿 | 最终仍需要人工检查命名、连线和边界 |
比较务实的用法是让 AI 完成 70% 到 80% 的基础工作：组件放上去、主要关系连起来、初始布局给出来。剩下的部分由人来做，包括视觉对齐、细节命名、边界划分和最终检查。
Docker 部署
项目提供了 Docker 镜像，适合快速启动。准备好模型 API Key 后，可以直接运行：
docker run -d -p 3000:3000 \
-e AI_PROVIDER=openai \
-e AI_MODEL=gpt-4o \
-e OPENAI_API_KEY=your_api_key \
ghcr.io/dayuanjiang/next-ai-draw-io:latest
参数含义如下：
| 参数 | 作用 |
|---|---|
-p 3000:3000 | 把容器内的 3000 端口映射到本机 3000 端口 |
AI_PROVIDER | 指定使用的模型服务提供方 |
AI_MODEL | 指定调用的模型名称 |
OPENAI_API_KEY | 模型服务的 API Key |
| 镜像地址 | 使用 GitHub Container Registry 上的项目镜像 |
启动后访问：
http://localhost:3000
如果部署到服务器上，需要根据实际情况配置反向代理、HTTPS 和访问控制，避免 API Key 或内部图表被不相关的人访问。
本地开发运行
如果需要改代码或在本地调试，可以克隆仓库运行：
git clone https://github.com/DayuanJiang/next-ai-draw-io.git
cd next-ai-draw-io
npm install
npm run dev
本地运行时同样需要准备模型相关配置。Docker 命令里通过环境变量传入 provider、model 和 API key，本地开发也需要按项目要求配置对应环境变量。
模型选择会影响生成质量
图表生成对模型有两个要求：
- 能理解用户描述里的结构关系；
- 能稳定输出 Draw.io 需要的 XML。
第二点尤其关键。聊天类回答里偶尔少一个标点问题不大，但 XML 少一个闭合标签、节点 ID 引用错了，图表就可能损坏。
复杂图更适合使用格式遵循能力强的模型，例如 Claude Sonnet 4.5 这类在长上下文和结构化输出上表现更稳的模型。能力较弱的模型可能出现这些问题：
| 问题 | 表现 |
|---|---|
| XML 不完整 | Draw.io 无法打开或渲染失败 |
| 节点引用错误 | 连线找不到目标节点 |
| 布局混乱 | 节点重叠、线条交叉严重 |
| 图标选择不准确 | 云架构图里使用了不合适的图形 |
| 修改上下文丢失 | 要求改一个节点，结果重写了整张图 |
如果图比较复杂，可以把任务拆小。例如先让 AI 生成核心服务链路，再补充缓存、消息队列、监控、外部系统等外围部分。这样比一次性要求生成完整大图更稳定。
使用建议
更稳定的工作流可以按这个顺序来：
flowchart TD
A[描述目标图表] --> B[AI 生成初稿]
B --> C{结构是否基本正确}
C -- 否 --> D[补充约束重新生成]
D --> B
C -- 是 --> E[用自然语言做局部修改]
E --> F[人工调整布局和样式]
F --> G[保存或导出 Draw.io 文件]
提示词里最好包含这些信息：
- 图表类型：流程图、架构图、UML 图、时序图；
- 参与组件：有哪些服务、系统、用户、数据库；
- 关系方向：谁调用谁，数据怎么流动；
- 分组边界：前端、后端、基础设施、第三方系统；
- 样式偏好：颜色、图标、横向布局或纵向布局。
一个更完整的提示词可以这样写：
生成一个横向布局的微服务架构图。
包含这些模块：
- 用户端 Web App
- API Gateway
- Auth Service
- Order Service
- Payment Service
- Redis
- PostgreSQL
- Kafka
- 第三方支付平台
关系：
- Web App 调用 API Gateway
- API Gateway 调用 Auth Service 和 Order Service
- Order Service 读写 PostgreSQL，并使用 Redis 做缓存
- Order Service 发送订单事件到 Kafka
- Payment Service 消费 Kafka 消息，并调用第三方支付平台
样式：
- 前端使用蓝色
- 后端服务使用绿色
- 存储组件使用橙色
- 第三方系统使用灰色
需求描述越清楚，AI 越容易生成可用的结构。只写“画一个电商架构图”，模型需要自行猜测组件和关系，结果更容易偏离实际系统。
需要注意的坑
- 不要把生成结果当成最终设计
AI 可以画出“看起来合理”的结构，但它不知道真实系统的所有约束。服务边界、数据一致性、权限控制、容灾设计等内容仍然需要工程判断。
- 复杂图要拆分
节点很多的大图容易变乱。可以拆成业务流程图、部署架构图、数据流图、监控链路图，而不是把所有信息塞进一张图。
- 生成后必须检查连线语义
线条方向很容易影响理解。比如“订单服务调用支付服务”和“支付服务回调订单服务”不是一回事，生成后需要确认箭头方向和文字说明是否正确。
- API Key 要妥善管理
自部署时不要把 API Key 写进前端代码或公开仓库。Docker 环境变量适合快速启动，生产环境还需要结合密钥管理、访问控制和日志脱敏。
- 截图复刻要注意信息安全
Image-to-Diagram 会把上传的图片交给模型处理。如果截图里有内部系统名称、账号、网络地址或业务数据，需要先脱敏，再上传处理。
小结
Next AI Draw.io 的定位很清晰：用大模型降低画图的启动成本，再用 Draw.io 保留专业编辑能力。它不适合完全替代人工设计，但很适合快速生成流程图、架构图和草图复刻的初稿。
对于经常写技术方案、整理系统设计、补充项目文档的人来说，这类工具能把大量机械绘图动作交给 AI，精力更多放在结构是否正确、边界是否清晰、图表是否能解释问题上。