1. 为什么架构图这件事值得用AI重新做一遍我最早接触 next-draw.io 的时候其实是抱着怀疑态度的。做架构图这件事从最早的 Visio、ProcessOn到后来团队里用的 draw.io、Excalidraw工具换了一茬又一茬但痛点基本没变过画一张能看的系统架构图从零到能拿出手少说也要半小时到一小时画完以后只要业务一调整图就跟不上代码没过多久就变成一张没人敢信的历史文物。所以当AI 架构图这个词出现在工作流里时我第一反应是这不就是把画图的活儿外包给大模型吗但实际用了 next-draw.io 一段时间之后我的看法变了。它解决的并不只是省掉拖拽鼠标的时间而是把画架构图这件事从手工劳动变成了描述-生成-迭代的对话式协作。你说清楚系统里有谁、谁依赖谁、边界在哪里AI 先给你一版骨架你再在骨架上修修改改。这个模式的变化才是真正值钱的地方。这篇文章我会从实际操作的角度把我在 next-draw.io 里用 AI 生成架构图的完整过程拆开讲包括怎么准备提示词、AI 输出结果之后怎么调、遇到哪些典型翻车场景、以及我怎么把这张图落到真正可维护的状态。适合谁看适合那些和我一样每个迭代都要画系统架构图、微服务架构图又被传统画图流程折磨过的开发者和架构师。如果你只是偶尔画一张示意图这个流程也能帮你把效率提起来不少。说实话AI 画的架构图不是一上来就完美但它最大的价值是给了你一个可以改的起点。这比对着空白画布发呆强太多了。2. 先用十分钟摸清 next-draw.io 的 AI 画图入口2.1 界面布局与传统绘图功能的差异next-draw.io 这个名字一看就是从 draw.io 那条线出来的——支持在线编辑、支持导出各种格式、画布操作逻辑和 draw.io 基本一致。但既然叫next它确实在 AI 能力上做了不少增量。我建议你第一次进去之后别急着用 AI先把界面摸一遍。左侧是图形库中间是画布右侧是配置面板——这套逻辑和 draw.io 用户是无缝衔接的。但你会在工具栏或者右键菜单里看到一个 AI 相关的入口具体形式可能是一个对话框图标也可能是一个AI 生成按钮不同版本位置略有差异。点开之后你会看到一个输入框这就是整个 AI 画图的核心入口。next-draw.io 的 AI 生成架构图底层逻辑是你输入自然语言描述它解析出组件、关系、层级然后自动在画布上摆放节点和连线。关键点在于它生成完不是一张图片而是一个可以继续编辑的图形文件——节点还能拖、连线的样式还能改。这一点太重要了因为如果是生成一张死图片那和 Midjourney 画概念图没什么区别对工程实践毫无意义。我第一次用的时候犯了个小错误把输入框当成了聊天机器人输入了帮我画一个电商系统架构图就等结果。结果当然翻车了——它确实生成了一些东西但非常抽象几乎没有可用性。后来我才总结明白AI 画架构图不是你给我需求我出图这么简单它需要你给出结构化的描述这一点我会在后面详细展开。2.2 前置准备先想清楚你的图要被谁看在打开 next-draw.io 之前有一个比工具本身更重要的问题这张架构图是给谁看的这个问题的答案决定了你的描述方式。如果是画给技术团队看的微服务架构图重点在网络调用关系、服务边界、数据存储上如果是画给产品或者领导看的系统示意图重点在模块划分和用户侧链路如果是要进技术方案文档的那还要考虑图例、标准分层、命名规范。我举个实际差异。同一个订单系统给研发看订单服务、库存服务、用户服务、消息队列、订单库、库存库以及它们之间的同步/异步调用关系给产品看用户下单 → 支付 → 履约 → 售后一条主链路加上周边支撑模块给运维看部署架构、网关层、服务实例数、依赖的外部中间件。不同视角意味着完全不同的组件划分方式。如果你自己都没想清楚这张图的主视角AI 再聪明也不可能替你做出判断它只会给你一个四不像的大杂烩。所以我的建议是打开 next-draw.io 之前先花两分钟在草稿纸上写下来这张图的边界是什么、主要参与者有哪些、核心依赖是什么。不用写得很正式三五条要点就够了。这个习惯让我后续的 AI 生成成功率翻了一倍不止。3. 一段描述变成一张架构图全流程实操记录3.1 第一版提示词把你脑子里的系统翻译成文字我在 next-draw.io 里实操过很多次之后总结出一套比较好用的提示词结构核心是四个要素边界、组件、关系、布局偏好。拿我最常画的微服务架构图举例。这是我在一个实战项目里用过的提示词请生成一张微服务系统架构图采用分层布局从上到下依次是 接入层Nginx 负载均衡 网关层API Gateway 网关服务 业务层用户服务、订单服务、库存服务、支付服务 支撑层RabbitMQ 消息队列、Redis 缓存 数据层用户数据库、订单数据库、库存数据库、支付数据库 重点连线关系 - Nginx 反向代理到 API Gateway - API Gateway 根据路由分发到四个业务服务 - 订单服务通过 RabbitMQ 发送订单事件库存服务消费 - 四个业务服务分别读写各自的数据库 - 订单服务、库存服务、支付服务读写 Redis 缓存这段描述直接复制到 AI 输入框生成的效果已经相当能看了。你注意我做了几件事第一说明了布局方向从上到下分层第二点名了组件清单第三把关键的连线关系单独列出来。这比帮我画一个微服务架构图这种模糊指令要有效得多。第一版生成的图一般会有一个问题组件之间的连线会比较乱AI 会自动摆布节点的位置可能导致某些线跨过中间的大块区域。但没关系架构图的骨架已经出来了后续微调的成本远低于从零开始画。3.2 生成之后的常规修正流程第一版生成完之后我会按三个步骤来检查第一步核对组件是否齐全。对着我原始需求里的清单一项一项核对少了的组件马上手动拖进画布补上。AI 偶尔会漏掉一些非核心组件尤其是消息队列里的 Topic、缓存里的 Key 分类这种细节。第二步理顺连线关系。AI 生成的连线有时候经过的位置不合理我会手动选中连线调整路径走向。next-draw.io 里连线的样式、拐点、文字标注都可以改这个工作量不大但图形会干净很多。第三步补充图例和分组。如果这张图要放进正式文档我会加上图例说明比如虚线代表异步消息、实线代表同步调用、不同颜色代表不同服务层级。这些细节 AI 不会自动给你加要靠手工补上。我实测下来的体感是用 AI 生成从零到初稿的耗时从传统方式的 30~40 分钟压缩到了 5 分钟左右从初稿到终稿的调整大约还需要 10~15 分钟。总时间从一小时级别降到了二十分钟级别而且因为是从已有的正确骨架上改出错率也比自己从零画低得多。3.3 导出与后续维护为什么可编辑比好看更重要next-draw.io 生成的架构图导出选项和 draw.io 基本一样支持 PNG、SVG、PDF以及 .drawio 和 .xml 格式。我的经验是如果图要放进 PPT 或 Word 文档导出 SVG放大不糊且体积小如果要作为附件放在代码仓库里保存为 .drawio 文件这样团队其他人可以直接继续编辑如果要渲染到网页或 Wiki导出 PNG注意把导出的缩放比例设置高一些200% 左右保证清晰度。这里我要多说一句维护性。架构图的宿命是腐烂——只要代码在演进图就会过期。以前用 Visio 画图最大的痛点是每改一次架构都要重画一遍于是大家越来越不爱维护。现在有了 AI 辅助改架构的成本大幅降低了你只需要在文字描述里改一两句话重新生成一版再把需要保留的手工调整部分合入即可。这让架构图跟上代码第一次成为了一件不那么痛苦的事情。4. AI 架构图生成的内在逻辑它到底在做什么4.1 从文字到图LLM 与图数据的转换机制你用自然语言描述一个系统AI 是怎么把它变成一张有节点和连线的架构图的这个问题的答案决定了你以后怎么优化自己的提示词。next-draw.io 的 AI 架构图能力本质上是把大语言模型和图形数据处理结合在了一起。大语言模型负责做一件事从你的自然语言描述中抽取出一组结构化的图形数据——哪些是节点、节点的层级关系如何、节点之间存在什么连线、连线有向还是无向。然后再用图形引擎把这组数据渲染成可视化的图。所以你会发现一个规律AI 生成架构图的质量上限直接取决于它从你的描述里抽取出来的数据结构是否合理。如果你的描述里一堆术语含糊不清、层级紊乱、组件之间的依赖关系绕来绕去大模型再聪明也只能给你一份乱糟糟的数据最后渲染出来自然是乱的。我最早用的时候犯过这样一个错写了一大段项目背景描述什么本项目旨在提升用户体验引入中台概念之类的话写了一大堆结果 AI 输出了一张完全没法看的东西。后来我悟了它是从描述里抽组件的不是来读项目的。你需要给它的不是背景而是结构。4.2 提示词的本质给 AI 清晰的抽取边界搞清楚这个机制之后提示词的写法就变得有章可循了。我把它拆成三层第一层谁是节点。把所有名词性组件列出来——服务、中间件、数据库、网关、客户端逐个点名。不要有隐含的组件你要什么就说什么。第二层节点之间的边。直接描述调用关系A 调用 BA 异步发送消息给 BA 依赖 B 的接口。连词要尽量一致性不要一会儿用调用一会儿用请求一会儿又用发给模型会懵。第三层布局与样式。告诉它分层方向、分组方式、哪些组件应该画在一起。AI 对布局的默认处理往往是按提及顺序排列所以你的描述顺序本质上就是在决定布局顺序。我习惯用操作系统的类比来理解这件事提示词像是你在给 AI 列一份画图的对照组组件就是变量连线就是变量之间的函数关系。你变量没定义清楚函数关系再对也没法跑。4.3 架构图 skill可复用的提示词模板热搜榜里有一个词叫架构图 skill我猜很多人对怎么给 AI 描述架构这件事感到头疼想要一个可以直接复制粘贴的模板。根据我自己的实践积累分享一套我多次调优后觉得最通用的模板。你用[描述]生成一张架构图要求 1. 组件清单不含背景描述 - 组件A类型服务/中间件/数据库/客户端 - 组件B类型服务 - 组件C类型数据库 ... 2. 关系矩阵格式为组件A --调用-- 组件B - 组件A --HTTP-- 组件B - 组件B --异步-- 组件C - 组件C --读写-- 组件D 3. 布局偏好采用[分层/从左到右/围绕中心]布局[组件集合X]放同一条边界内这套模板写起来稍微麻烦但有个好处是可复用性极强。我把自己常用的微服务基础架构“前端三件套架构”“数据处理流水线”都做成了固定模板每次干活直接套用改一改组件名就能生成一版初稿。真正常用的提示词不是临场发挥的而是反复打磨沉淀下来的。5. 从能看到好看架构图的迭代调优方法论5.1 布局是第一位的AI 生成的架构图最大的短板往往是布局合理性。它确实理解了你说的从上到下分层但具体的节点位置、间距、对齐方式往往还是需要人工微调。我的经验是拿到初稿之后先不动具体节点先调布局大框架。比如微服务架构图我会先把接入层、网关层、业务层、数据层的泳道拉出来调整好高度和间距然后让每个节点在各自的层里横向对齐。这个过程有点像整理书架——先分好格子再把书放进去。只要格子分对了书架整体就不会乱。next-draw.io 里可以用框选的方式批量移动节点配合对齐工具顶部对齐、水平居中、垂直居中把一层的节点摆整齐也就几秒钟的事。画图的洁癖感在这里是加分项因为图乱了看的人第一印象就差了。5.2 颜色和分组传递语义最快的方式架构图不仅仅是表达有哪些组件更是让人一眼看出这些组件之间的边界在哪里。这就要用到颜色和分组容器。我的惯用配色方案层级颜色用途接入层浅灰色边缘设施非核心业务网关层浅蓝色流量入口路由转发业务层浅绿色核心业务服务支撑层浅橙色消息队列、缓存等中间件数据层浅紫色数据库、存储这套方案没有什么高深的道理核心诉求就一条让看图的人在一秒钟内凭颜色就能分辨出图的层次。next-draw.io 里你可以框选一层的所有节点统一设置填充色两分钟就能搞定。分组容器容器/边界的用法也很关键。微服务架构图里我习惯用一个大的容器框包住业务层的多个服务并标注业务服务集群数据库也是同理。容器框传达的信息量非常大它直接把哪些东西属于同一个逻辑分组这个信息编码到了图里。5.3 差异化连线把信息密度提上去架构图里最容易被忽略的是连线的语义。很多人画架构图所有连线都是一个粗、一个颜色图上的信息量直接砍掉一半。我在 next-draw.io 里至少会区分三种连线同步调用实线箭头标注表示一次 HTTP 或 RPC 请求异步消息虚线或点划线表示通过消息队列进行的事件传递数据依赖细实线标注读写表示对数据库或缓存的访问。这三种连线在语义上差异很大如果不区分看图的人需要逐条去读文字标注才能理解交互关系纯属浪费时间。样式区分做完之后架构图的信息密度会高一大截。我常用的做法是在 AI 生成初稿之后把异步消息相关的连线全部选中改成虚线把数据访问相关的连线改成细线。熟练之后这个操作也就几分钟。但带来的阅读体验提升非常明显——团队成员反馈说拿到图之后第一眼就能分清同步链路和异步链路的边界理解成本低了很多。6. 微服务架构图实测一个真实项目的还原过程6.1 项目背景一个双十一场景下的订单中台为了让你更直观地感受整个过程我拿一个我在实际工作中画过的系统来做完整演示。这是一个电商订单中台双十一场景下要扛住峰值流量架构上有一些典型设计网关层做限流、业务层做了订单和库存的异步解耦、数据层做了读写分离。需求就一句话把订单中台画出来包含接入层、网关、服务、消息、缓存、数据库重点体现异步解耦。我把它翻译成了 AI 友好的描述用到了前面说的模板结构生成一张订单中台系统架构图采用分层布局从上到下 接入层CDN、负载均衡 Nginx 网关层API Gateway含限流、鉴权 业务层用户服务、订单主流程服务、支付服务、库存服务、售后处理服务 支撑层RabbitMQ订单事件队列、库存扣减队列、Redis会话缓存、热点数据缓存 数据层用户库、订单主库、订单从库读写分离、库存库、支付流水库 关键关系 - Nginx 反向代理到 API Gateway - API Gateway 限流后将请求分发到用户服务和订单主流程服务 - 订单主流程服务发起订单通过 RabbitMQ 的订单事件队列异步通知库存服务 - 库存服务消费库存扣减队列扣减库存并回写库存库 - 订单主流程服务读写订单主库通过订单从库进行查询 - 支付服务走支付流水库并通过回调通知订单主流程服务 - 用户服务读取用户库订单主流程服务读取 Redis 热点数据这段话比我之前用的模板要长一些但信息密度是够的。AI 生成之后我得到的初稿已经包含了所有组件和大部分的连线关系拓扑结构基本正确。6.2 调整过程中最花时间的其实是细节表现的打磨初稿生成之后我花了大约十五分钟做调整。第一个调整点是读写分离的表示。AI 虽然识别出了订单主库和订单从库但连线的样式默认都是实线。我把主库和从库之间的同步连线单独标记了一下并在从库旁边加了一个文本标签读写分离这样看图的人一眼就知道这是主从架构。第二个调整点是异步链路的强调。双十一场景的核心亮点是订单与库存的异步解耦所以我在订单主流程服务、RabbitMQ、库存服务这条异步链路上用了高亮色并在图角落标注了异步解耦路径。第三个调整点是服务分组。业务层的五个服务我全部框进了一个容器命名为订单中台业务服务。如果将来有人往这个容器里加服务只需要在描述里添加对应的组件名称重新生成再合并进来就行。最终这张图放进技术方案文档后评审会上大家几乎没有提出这张图看不懂的问题。放在以前画图的方式这种完整度的图至少要画一晚上现在从开始到成稿只花了二十来分钟。7. 实操了三个月踩过的坑和沉淀下来的经验7.1 常见翻车场景及对策用 AI 画架构图这件事翻车不可怕可怕的是不知道为什么会翻车。我把这段时间遇到的典型问题总结了一下按频率排序描述含糊导致组件丢失。比如只说数据库而不说用户库、订单库、库存库AI 可能给你一个笼统的数据库节点。对策是点名的颗粒度足够细宁可多列也别让 AI 猜。组件重复出现。一段描述里同一个东西用了两种叫法比如一会儿说网关一会儿说API GatewayAI 可能当成两个节点。对策是全文保持同一个称呼。连线方向反了。把订单服务调用库存服务说成库存服务被订单服务调用语义是对的但 AI 抽取的连线方向可能反。对策是统一用主动句表达A 调用 B不要用被动结构。布局乱七八糟。没有指定布局方式AI 就按自己的习惯排列有时候会排得很随缘。对策是开头就点名采用分层布局/从左到右/上下结构。这四条是我统计下来出现次数最多的也是最好解决的。关键就是给 AI 的信息里少一点模糊空间它返回的图就少一点需要返工的地方。7.2 团队协作模式下AI 画图的正确姿势最后说一点团队协作层面的体会。现在我和团队成员在项目里已经形成了一套固定的架构图协作流程架构师在 next-draw.io 里用提示词生成骨架图并把关整体结构各服务负责人拷贝一份在骨架上补充自己负责的模块细节最终由架构师合并回归统一连线风格、配色和标注规范。这个流程的核心受益在于从零到骨架的那部分重复劳动被 AI 承担了人力集中在真正有价值的判断和细节打磨上。架构图不再是某个人的负担而变成了团队协作的一个轻量环节。另外我还有个习惯每次画完一张重要的架构图我会把对应的提示词存到项目的 docs 目录下和 .drawio 文件放一起。下次架构调整时我只需要更新提示词里变动的那几行重新生成初稿再手工合并需要保留的结构。这套组合拳打下来架构图的维护成本已经低到了我愿意每迭代维护一次的程度。对我来说这就够了——AI 画图从来不是为了让你当一个甩手掌柜而是为了把画图的时间省下来留给更需要人脑去做的设计决策。next-draw.io 这个方向是对的我以后画图基本就固定用它了。