1. 先说说我为什么折腾这套组合1.1 手动画架构图的罪我受够了做技术的人尤其是要经常写方案、做汇报、带项目的应该都体会过画架构图的痛苦。倒不是说画图本身有多难而是它太耗时间了一个个拖方框、调对齐、拉箭头、改文字一套下来少说二十分钟多则一两个小时。更折磨人的是架构永远在变。上午刚画完微服务的拆分图下午产品就说要加一个消息队列这周刚把模块图画好下周重构直接把整个分层推翻了。图纸比代码还容易过时最后谁都不想维护只好重画。我以前试过很多工具也有不少辅助手段。用draw.io手动拖拽只是最基础的我还尝试过代码化绘图比如用PlantUML、Mermaid写文本生成图。确实比纯拖拽快一点语法也熟了但你得先记一套标记语言而且图一复杂文字堆叠得跟代码一样难读改起来依然费劲。真正让我改观的是最近把vscode、opencode、draw.io这三个东西组合在一起之后——我用自然语言描述想要的架构让AI去生成和修改居然比我自己动手画快出好几倍。这篇文章就是把这条链路完整拆开讲一遍包括怎么装、怎么用、原理是什么、中途踩了哪些坑。如果你平时也要画系统架构图、微服务架构图、部署拓扑图又不想在这些图上消耗太多精力这套方案值得你花一个下午搭起来。1.2 这套方案的底层思路让AI直接产出可编辑文件先说清楚这套方案是怎么“串”起来的不然你很难理解后面每一步在做什么。vscode是容器和入口所有的操作都在这个编辑器里完成文件管理、插件管理、终端调用都集中在这里。opencode是一个能跑在终端里的开源AI编码助手。它跟普通聊天问答工具最大的区别是它能以agent的方式自己读取项目文件、执行命令、修改代码而不只是给你回复一段文字。draw.io这里指vscode里的Draw.io Integration插件它能把你打开的.drawio文件渲染成可视化的图形并且支持你继续手改。关键点在于opencode并不直接“画图”它做的是生成或修改.drawio文件的内容。而.drawio文件本质上是一个XML结构draw.io插件负责把它渲染成你看到的那种图形。这意味着只要opencode能理解draw.io的XML语法它就能像写代码一样“写”出一张架构图来。这套思路的核心启发是不要把AI当成一个画图助手而是把它当成一个会写XML的代码助手。你告诉它目标架构是什么它用drawio的XML语法生成文件vscode里的插件自动渲染出图。整个过程里真正需要你做的只是把架构想清楚、用自然语言说清楚。改图也一样直接说“把支付模块拆成两个服务”它改的也是XML你这边看到的图会即时刷新。1.3 这套方案适合谁不是所有人都需要用这个组合。我自己用下来觉得下面几类人收益最大。第一类是经常出方案文档的架构师和技术负责人。画架构图是工作刚需方案讨论阶段图纸往往一天改好几版用自然语言改图效率提升非常明显。第二类是写博客、写技术文章的人。想在文章里配一张清晰的架构图以前要专门去画现在一句话生成还能反复修改省下来的时间都花在写作本身。第三类是在vscode里写代码、已经重度使用AI助手的开发者。环境本来就有加装一个插件、一个CLI工具就能用边际成本极低。如果你只想偶尔画一张图也可以但投入产出比没那么高如果你一周要画好几次图这套组合能直接把“画架构图”这件事从半小时级降到分钟级。2. 环境准备三个组件怎么装、怎么串起来2.1 安装opencode命令行工具以及“cmd里命令无效”的真相先装opencode。它是个命令行工具官方仓库提供了多种安装方式最常见的是通过npm全局安装。我的机器上已经有过Node.js环境所以直接用npm装npm install -g opencode-ai装完之后在终端输入opencode --version能正常输出版本号说明就装好了。如果你用的是Windows这里大概率会遇到一个热搜词里反复出现的坑在cmd、PowerShell里输入opencode提示“无法将opencode识别为cmdlet、函数、脚本文件或可运行程序的名称”。我最初也踩了这个坑。问题根源多半是npm的全局安装目录没有加入系统PATH。你可以先执行下面这个命令把npm全局目录打印出来npm config get prefix比如输出的路径是C:\Users\你的用户名\AppData\Roaming\npm那你就去“系统属性-环境变量”里把这个路径加到PATH里然后重新开一个终端窗口。如果重新打开还不行再确认一下Node.js是否正常、npm是否在PATH里。绝大部分“命令找不到”都是这三个原因安装失败、PATH没配置、终端没重启。顺带说一句很多人刚装完opencode在cmd里输opencode没反应就以为没装好其实只是没开新终端。Windows的PATH变更不会自动同步到已经打开的窗口里这一点特别容易让人白折腾。2.2 vscode侧的两种接入姿势opencode本身是终端工具新手会疑惑“那它和vscode到底怎么配合”。其实有两种姿势我都用过可以按习惯选。第一种直接把vscode的集成终端当成opencode的跑场。在vscode里按Ctrl 打开终端输入opencode 启动交互界面在里面提问、下发任务。这种姿势的好处是零额外配置而且opencode本身自带TUI终端用户界面用上下键、斜杠命令就能操作。打开的文件、项目目录都能被它看到相当于AI助手就在你的项目里干活。第二种安装opencode的vscode插件在侧边栏里打开对话面板。体验上更接近你在用的其他AI助手插件不用切到终端。插件连接的就是你装好的opencode CLI。如果你更习惯图形界面的聊天窗口这种姿势更顺手。我个人推荐先走第一种因为它能让你更直观地理解opencode在做的事。等你把工作流跑顺了再切换到插件方式你会发现等待AI出结果的时候还能看看代码体验更好。2.3 draw.io插件与.drawio文件的格式约定vscode里装draw.io插件很简单直接在扩展市场搜索“Draw.io Integration”安装即可。装完后你新建一个后缀为.drawio的文件vscode会自动把它用图形编辑器打开。这里有个至关重要的知识点.drawio文件本质上是一个XML文本文件图形编辑器只是它的“渲染视图”。你可以在vscode里右键这个文件选择“在文本编辑器中打开”能看到一堆类似mxGraphModel、mxCell的标签。这些标签定义了每一个图形元素的位置、样式、文案和连线关系。为什么要强调这个因为opencode生成的并不是“一张图片”而是一段结构化的XML。它只要按照draw.io的格式要求把XML写对vscode里的draw.io插件就能识别并渲染出图形。这跟我们人类画图的方式完全不同我们是一笔一笔画AI是一行一行写。文本文档天然适合AI操作这也是整套方案能跑通的根本原因。还有一个习惯建议给你的架构图文件起一个语义化的名字比如system-architecture.drawio、microservices.drawio别叫drawing1.drawio。因为opencode在读取项目文件、判断你接下来要画什么的时候文件名是它理解任务的重要上下文之一。2.4 打通验证第一句自然语言指令环境都装好后我建议你不要急着画大图先用一个最小的例子验证整条链路是否打通。在vscode里新建一个空项目目录在里面创建一个空的test.drawio文件然后打开vscode集成终端输入opencode启动给它下第一个指令“在test.drawio里画一个简单的架构图包含三个方框客户端、网关、后端服务从上到下排列用连线把它们串起来。”如果一切正常opencode会分析任务读取test.drawio的现有内容然后往里面写入用于表示客户端、网关、后端服务这三个方框以及两段连线的XML。你切回test.drawio的图形视图就能看到三张方块和两条箭头。这一步跑通后面所有玩法都能陆续铺开。如果这一步没反应或者报错优先级是先确认opencode能正常读写文件再确认draw.io插件能正常渲染XML最后才去检查你的自然语言描述是否足够清晰。3. 自然语言出图的原理为什么是drawio格式而不是图片3.1 opencode的agent机制规划、调用工具、读写文件很多人会有个疑问直接在对话里让AI“帮我画个架构图”它怎么能真的把文件写出来这就要说到opencode的agent机制了。普通的聊天AI你问一句它答一句回答完之后就结束了不会去改动你的文件系统。但opencode这类agent工具不一样它在接到任务之后会自己做一个“计划”然后调用工具去执行需要看当前项目结构就列目录需要改文件就读取文件、写入文件需要验证结果就再读一遍文件确认。整个过程像是一个实习生坐在你的电脑前干活而不是一个只能动嘴的顾问。这个机制对画架构图这件事意义重大。因为“画图”在AI眼里不是一个独立的操作而是两个步骤的组合第一步根据你的描述决定图里有哪些元素、元素之间什么关系第二步把决定好的结构按draw.io的XML格式写进.drawio文件。这两个步骤都是opencode擅长的前者靠语言理解后者靠代码生成能力。理解了这一点你就能明白为什么我不推荐“让AI直接生成一张PNG图片”的路线。生成图片需要调用绘画模型效果不可控而且图片生成后没办法精准修改局部——你让AI“把右下角那个方块换成圆的”它做不到。但XML不一样每个元素、每条连线的属性都是文本AI可以精确定位、修改、重排。这就是“可编辑”三个字的分量。3.2 drawio文件是XML这正是关键我们来细看一下drawio文件的内部结构。一个最简单的.drawio文件打开文本视图大致长这样mxfile hostapp.diagrams.net diagram name第 1 页 idpage123 mxGraphModel dx800 dy600 grid1 gridSize10 root mxCell id0 / mxCell id1 parent0 / mxCell id2 value客户端 stylerounded1;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x120 y40 width160 height60 asgeometry / /mxCell mxCell id3 value网关 stylerounded1;whiteSpacewrap;html1; vertex1 parent1 mxGeometry x120 y180 width160 height60 asgeometry / /mxCell mxCell id4 styleedgeStyleorthogonalEdgeStyle; edge1 source2 target3 parent1 mxGeometry relative1 asgeometry / /mxCell /root /mxGraphModel /diagram /mxfile结构不复杂mxCell定义节点vertex1表示是图形mxGeometry确定位置和宽高edge1表示是连线source和target决定连线两端指向谁。AI只要理解了这套语法生成一个包含10个甚至20个节点的架构图对它来说跟写一段几百行的配置文件没有本质区别。这也是为什么这套方案能比PlantUML、Mermaid更进一步PlantUML和Mermaid也是文本生成图但它们生成的图不太方便在vscode的draw.io插件里继续手动微调而drawio是所见即所得的编辑器AI生成后你依然能用鼠标拖、拉、改样式人机和协作结合得很好。3.3 一个好用的“出图提示词”长什么样既然核心是自然语言那“怎么说”就非常关键。我刚开始试用的时候指令写得随意结果AI生成的图要么漏了节点要么布局乱成一团。试了几十次之后我总结出一个好用的提示词结构分享给你第一指明目标文件和格式。不要让AI猜你要干什么直接说“请在xxx.drawio中生成/修改架构图”。目标文件越明确AI越不会另起炉灶。第二描述架构内容时按层级结构走。先说这张图整体分几层每一层有哪些模块模块之间的连线关系是什么。你描述得越接近结构化的表达AI生成时越不容易漏。第三说清楚布局偏好。是自顶向下分层、从左到右分段还是中心辐射节点多的时候AI默认的布局往往不理想显式告诉它会更可控。第四给出风格约束。比如“圆角矩形”“统一宽度”“不同层用不同填充色”。如果你对样式没特别要求也可以让它用默认样式减少它的思考负担。我一般会这样写“在framework.drawio中画一张业务系统架构图。自上而下分四层接入层、应用层、服务层、数据层。接入层包含Web门户、移动端、开放API网关应用层包含用户中心、订单中心、支付中心服务层包含消息服务、文件服务、任务调度数据层包含MySQL主库、Redis缓存、Elasticsearch。各层之间用连线表示调用关系接入层到应用层是HTTP调用应用层到服务层走RPC服务层到数据层走JDBC。整体颜色区分四层每层的节点用圆角矩形纵向排列。”你仔细看会发现这几句话其实信息密度很高位置、内容、关系、颜色、形状都有了。模型拿到这样的描述基本不需要“自由发挥”出图准确率会高很多。3.4 迭代修改让AI改图而不是重画架构图的灵魂在于“改”。方案讨论时今天加一个模块明天调一条链路后天整体换一个分层的逻辑都太常见了。用自然语言改图比重新画图的优势还明显。你可以直接在会话里追加指令比如“把支付中心从应用层挪到服务层”“在数据层加一个只读从库节点用虚线连到MySQL主库”“把接入层和应用层之间的连线改成从上往下的泳道箭头”。opencode会基于当前.drawio文件的内容做增量修改而不是重新生成一张图。但这里有个使用技巧修改类指令要尽量具体最好能引用到图里的节点名称。比如“第二个方框”这种描述AI很难判断你说的是哪个你需要给它依赖的信息。而“把应用层里的订单中心宽度改成220”这种描述它就能在XML里准确定位。我自己的习惯是先让AI出初稿然后以“小步快跑”的方式连续下达修改指令。一次只改一个点改完切到图形视图确认一下不对再追加指令。这比一口气提出五六个修改要求然后等着AI翻车要稳妥得多。4. 实战三类高频架构图的完整过一遍4.1 业务系统整体架构图这类图几乎是技术方案文档的标配。它们通常展示一个系统的全貌分层展示不同模块、组件之间的相互关系。我们以一套典型的业务系统为例我把完整提示词和生成效果预期都写出来。提示词可以这样写“在business-architecture.drawio里绘制一张业务系统整体架构图。自上而下分为五层用户层、接入层、业务层、基础组件层、数据层。用户层C端用户、B端商家、管理后台。接入层PC Web、H5移动端、App、开放API网关。业务层商品中心、订单中心、库存中心、支付中心、营销中心、用户中心。基础组件层消息队列Kafka、分布式缓存Redis、文件存储OSS、任务调度平台。数据层MySQL主库、MySQL从库、MongoDB。连线关系用户层通过HTTPS访问接人层各端接入层经网关鉴权后路由到业务层各中心业务层各中心对基础组件层的调用如下订单中心依赖消息队列、缓存、文件存储支付中心依赖消息队列、任务调度基础组件层统一访问数据层。要求同一层节点水平排列层与层之间纵向连接业务层节点用浅蓝色填充。”AI生成之后你大概率能得到一张节点排列整齐、颜色区分到位的五层架构图。之所以强调把连线关系说清楚是因为架构图最怕“节点都有关系全乱”AI写XML时每条edge都对应着源节点和目标节点你不给它关系它就只能猜。得到初稿以后我通常会再追加两条修改指令“把接人层和业务层之间画一个标注为‘鉴权路由’的虚线框把这部分逻辑圈出来”“给数据层每个节点下方标注它的部署副本数”。这种追加修改很快因为AI已经清楚整个文件的结构了。4.2 微服务架构图微服务架构图是另一个高频场景而且通常比整体架构图更复杂因为它要展现的不只是分层还有服务发现、网关、配置中心、熔断、监控等一系列基础设施。实操时我是这样下指令的“在microservices.drawio中绘制一张微服务架构图。图的入口是流量入口包括移动端、Web端和第三方OpenAPI。入口流量统一经过API网关网关负责认证、限流、灰度路由下方连接Nacos注册中心和Spring Cloud Gateway集群。网关的下游是业务微服务集群包括用户服务、订单服务、商品服务、支付服务、库存服务。这些服务之间通过OpenFeign进行同步调用订单服务启动时会调用库存服务和商品服务。基础设施层包括Nacos服务注册与配置、Sentinel Dashboard熔断限流、SkyWalking链路追踪、Prometheus Grafana监控。数据存储包括各服务的独立数据库订单库、用户库、商品库、库存库、支付库外加Redis缓存集群。绘图要求流量入口在上方网关其次微服务集群在中间基础设施和数据存储在下层服务之间的Feign调用用虚线标出来每个微服务节点下方用一个小圆点连接到它对应的数据库。”这种复杂图对AI的生成能力是有考验的一次性描述太多容易漏。我的经验是分成两步第一步先让它画出主体结构就是“入口-网关-微服务集群”这三层的框架第二步再追加“在下方补充基础设施和数据存储”并把连接关系说清楚。分步走一来AI不容易懵二来你在中间能检查一次布局。微服务架构图里最需要注意的是连线交叉问题。节点一多连线很容易交叉重叠。如果AI生成的图你看着乱不要忍直接给它一句“调整所有连线的路径尽量减少交叉允许微服务节点之间上下左右偏移。”drawio的XML里连线的路径是可以调整的AI很多时候也愿意去优化只是默认情况下它不会主动做。4.3 部署拓扑图第三类是部署拓扑图展示系统在服务器、容器、中间件上的部署形态。这类图和前面的区别在于它更关心“节点所在的物理或虚拟位置”比如哪台机器上跑了哪个服务哪些端口对外暴露。提示词参考“在deployment.drawio中绘制部署拓扑图。最外层用一个虚线框代表阿里云VPC私有网络。VPC内包含三台云服务器应用服务器8核16G运行Nginx和网关服务器B8核16G运行用户服务、订单服务服务器C4核8G运行商品服务、库存服务。VPC内还有一个云数据库实例部署了MySQL主从一个云Redis集群。外部有一个用户节点从公网通过HTTPS访问负载均衡SLBSLB再把流量转发到服务器上的Nginx。绘图要求服务器节点用方框里面列出运行的服务列表服务器与服务器之间的调用用实线箭头服务之间的内部调用在方框内用文字列出来不画额外连线云数据库和Redis集群放在最下方用实线连接到涉及的服务方框。”这种图AI生成的效果通常都不错因为它要素相对固定技术栈也清晰。关键是要把“每个服务器上运行什么”写明白AI就能生成层级分明的节点结构。如果你有云环境的特定名词VPC、SLB、容器服务等直接在提示词里用这些词模型都能理解。部署图我最后都会加一句“在图的标题位置加一行注释生产环境部署拓扑2025年xx月”。这样图进文档、进PPT的时候读者一眼就能知道版本时间避免拿旧图当新图。5. 常见报错与避坑实录5.1 “free tier can only be used from within opencode”的来龙去脉这个报错在热搜里很显眼很多人遇到它时基本是一脸懵。报错信息长这样“error from provider (console): opencodes free tier can only be used from within opencode”。它本质上是一个使用边界错误。简单来说opencode提供的免费套餐只能在其官方客户端/官方CLI环境内使用你不能拿opencode的免费额度去喂给其他外部项目比如自己写脚本调用它的接口或者在某个第三方GUI工具里挂上“opencode free”作为模型来源。一旦opencode检测到请求不是来自官方客户端内部会话就会以这个报错拒绝提供服务。我当时排查这个问题的思路值得分享一下先分清请求是从哪里发出的。如果你的请求来自vscode里的某个插件而这个插件允许你填“opencode free”作为模型服务商那大概率就会触发这个限制。解决方法有两个一是换用自己已有的模型服务商额度在opencode配置里填写你自己的API Key二是直接回到opencode的官方CLI会话里使用如果你只是想在vscode终端里用那就直接在集成终端调用opencode启动官方会话。如果你不需要免费的额度这问题基本不会影响你的主流程。但一定不要在配置里“既想用插件界面又想蹭官方免费通道”这就是它最典型的触发场景。5.2 cmd使用opencode命令无效的三种原因前面提到过“cmd使用opencode命令无效”这个坑这里我把判断顺序再完整列一遍方便你照着排查。原因一npm全局目录没在PATH里。执行npm config get prefix看输出再把输出路径加进PATH。这一步能解决七八成的问题。原因二命令行工具没有真正安装成功。执行npm ls -g --depth0看看opencode是否出现在全局包里。如果是安装中断、版本冲突导致的半成品建议先npm uninstall -g opencode-ai再重装。原因三终端还是旧会话。Windows里改完PATH后必须重新开终端旧窗口不会自动刷新环境变量。很多人各种排查半天最后发现就是没开新窗口。另外提一句如果你在检查完PATH之后还是不行可以试着用where opencode查看它实际被安装到哪个目录然后直接在命令行输入完整路径运行作为临时替代方案。这不是解决方法的重点但能帮你立刻用起来不至于卡住干不了活。5.3 AI生成的图布局乱、连线飞怎么办如果AI生成了内容但你打开.drawio一看节点互相重叠、连线乱飞、整体布局像一团乱麻这其实是这套方案里最常遇到的问题。原因在于AI在设计布局时坐标计算不一定会那么理想尤其是节点多、关系复杂的时候它逐一把每个mxCell的x和y坐标给出来但“整体看起来美观”这件事模型的能力还达不到人类画图时的那种直觉。我的处理习惯是分三步第一步让AI“重排坐标”。可以直接追加指令“把图中所有节点重新排列改成自上而下分层的对齐排列每层之间的垂直间距不少于80像素同层节点的水平间距不少于40像素”。AI会重新计算并更新每个节点的坐标。第二步如果重排之后仍不满意让AI把图简化一点。比如“合并同类节点把这些基础组件合并成一个分组”。节点数量降下来之后布局问题往往会自行缓解。第三步最后一点手动调整。架构图的审美是比较主观的AI做不到完美是正常的。你可以用draw.io的“调整布局”功能里的“垂直/水平排列”“横向分布”快速整理再手动微调几个节点位置。记住目标不是甩开draw.io插件而是用AI省掉80%的工作剩下20%手工忙活也是可以接受的。顺便说一个经验让AI画图时最好让它基于网格布局。drawio有网格吸附grid功能节点坐标会吸附到整数网格上这样生成出来的图天然更整齐。你可以在.drawio文件里的mxGraphModel标签中看到grid1和gridSize10这类属性保持默认即可这块不需要专门去调整。5.4 vscode里与opencode协作过程中的体验细节这一节说的不是报错而是使用过程中容易被忽略的体验细节但它们对整体的流畅度影响很大。关于vscode里没编辑过的文件会被自动关掉这件事很多人可能遇到过你在工作区打开了一堆文件结果vscode默认的workbench.editor.enablePreview是开启状态新打开的文件会以“预览模式”显示当你打开另一个文件时之前的预览文件会被自动关闭不会留在标签栏。这个问题常出现在你让opencode在多个文件之间来回切换、你想对照查看时。解决方法是设置里搜索workbench.editor.enablePreview把它关掉。这样每个文件都会固定在标签栏不会因为切换而悄悄消失。另一个体验细节是opencode在修改完.drawio文件后vscode的draw.io插件不一定会立刻刷新渲染。遇到这种情况你看一眼插件右上角的刷新按钮或者直接切换到文本视图再切回图形视图基本就能触发重新渲染。这通常不是数据损坏只是vscode的编辑器缓存没刷新。还有一个关于vscode清理删除分支的热搜词我顺手说一句这不是opencode相关的问题而是vscode的Git面板操作。如果你删除了本地分支却发现看不到可以在Git视图的“分支”栏顶部切换显示所有分支或者在终端执行git fetch --prune清理远程已删除的分支记录。它和架构图方案没有直接关系但如果你一边用opencode一边整理仓库分支容易混淆这两类问题。5.5 对“go套餐”“go v2”等搜索词的误解澄清热搜词里反复出现“opencode go套餐”“opencode go v2 cc-switch”“opencode go 套餐是每种模型分开计算额度吗”这类查询。我猜测很多人是被“go套餐”这个词吸引了以为它是指某种特定的画图方案或者OpenCode的特殊版本。其实从字面和实际使用场景看这更可能是指opencode在集成某些模型服务商时通过特定套餐/网关对外提供服务的一种说法类似“go版本/最新版”的简称。我没办法对你确认某个具体套餐的计费细节因为服务商的定价规则变动很快官方文档才是最准确的。我能说的是工具本身不绑定特定套餐。opencode的价值在于它接的是你配置好的模型服务商无论你是用自己的API额度还是用某个网关聚合的额度它都能跑通。12个模型的额度是不是分开计算这种问题取决于你接的那家服务商的计费规则你去查对应服务商的计费文档就行。换句话说不要被“go套餐”这四个字限制住了思路。你真正需要关心的是模型服务商是谁、额度是否够用、响应速度是否达标。这三个问题解决了底层是不是“go套餐”都无所谓。6. 我最后留下的几个使用习惯整套方案用了一个多月踩完坑、跑顺流程之后我沉淀下来几个习惯也算是对这篇分享的收尾。第一个习惯是把提示词模板化。我电脑里存了一个architecture-prompts.md里面按“整体架构图”“微服务图”“部署拓扑图”“流程图”分类写好了几套提示词模板。每次要画新图复制模板、替换系统名和组件名稍微调整层次关系一句话的事。模板帮我省掉了大量“重新组织语言”的时间也保证了AI出图质量稳定。第二个习惯是永远让AI先出骨架再叠细节。我踩过的最多的坑就是一开始把需求说得太满、太细AI生成出来的图不是漏这个就是乱那个。现在我的节奏是第一轮只交代层级和核心模块让它画出一个干净的骨架确认骨架没问题之后再用连续修改指令把细节一点点叠上去比如连线标注、颜色区分、分组框、文字注释。这个习惯让我对最终效果的控制力强了很多。第三个习惯是每次修改后切回图形视图肉眼检查一遍。AI修改XML这件事本身是靠谱的但“靠谱”不意味着“总是完美”。连线指向错了、节点被覆盖了、颜色值写漏了这些问题在XML里看很难发现但切回图形视图一眼就能看出来。检查成本极低收益极高这一步我建议你不要省。第四个习惯是把drawio文件纳入版本管理。变革之后架构图经常要回看历史.drawio是纯文本git能精确地 diff 改动。哪天领导问“这个模块当初是怎么拆的”你打开Git历史就能查出来。这一点是很多用在线绘图工具的人享受不到的福利。最后说一句个人体会自然语言画图这件事看起来是“AI帮我画图”但真正跑下来你会发现它逼着我把架构想得更清楚了。因为AI不会自动补全你没说的东西你说不清楚的地方画出来就一定是乱的。所以这套方案带给我的不只是省时间还有对架构表达能力的反向训练。我很推荐你也试一试先从一张最简单的图开始。