1. 从画图工具到AI架构师next-draw.io想解决的到底是什么我最初看到next-draw.io这个项目名第一反应是这不就是给draw.io加上AI能力吗但深入琢磨之后发现这事没那么简单。它表面上是一个画架构图的工具实际上瞄准的是架构设计这个动作本身——尤其是从产品需求或系统描述直接生成可落地的架构图这条链路。大家在日常工作中画架构图最常见的痛点根本不是不会用绘图软件而是不知道画什么和画出来怕不对。需要画微服务架构图、系统架构图、业务流程图的时候脑子里可能只有零散的信息有几个服务、中间件要接哪种、客户端走什么协议、数据落哪儿。把这些碎片整理成一张结构清晰、层级分明、关系正确的图往往要来回改好几版。更别提在大型方案评审或者项目启动会上一张高质量的架构图直接决定了甲方和你之间的沟通效率。这个项目的价值就在这把AI理解业务描述→产出结构化架构设计→自动生成绘图语言→渲染成图→持续迭代修改这条链路打通。换句话说它想当的不是画图的笔而是帮你把架构设计出来的人。我根据标题、配套关键词和当前AI技术栈梳理了这套工作流最适合的用户群体后端/服务端开发要做微服务改造或新系统技术方案需要快速产出架构图用于评审架构师/技术负责人需要维护多套系统的架构文档希望从描述性文档一键出图运维/DevOps工程师梳理部署架构、中间件拓扑、可观测性体系时需要准确的组件关系图产品经理/技术文档写作者需要把业务逻辑或系统方案转成通俗直观的架构图用于对外汇报。下面我就从方案选型、核心实现、提示词工程、多AI协作、成果复用这几个维度完整拆解这套AI架构图设计工作流该怎么搭建、每一步为什么那么选、实际跑的时候有哪些坑。之所以这个标题在网络上有这么多关联词架构图软件、AI agent、多AI协作、AI编程提示词本质上是大家在探索同一件事AI生成架构图到底能不能脱离玩具阶段真正进入生产环境。2. 方案选型为什么不是一句话出图这么简单2.1 核心技术链路拆解从自然语言到拓扑结构我在构思这套工作流的具体实现时先画了一条主线自然语言描述 → 结构化数据JSON/知识点清单 → 绘图语言代码Mermaid/Graphviz → 渲染出图。这四步其实每一步都有独立的技术选型空间。第一步理解意图。这里通常用大模型来做可选的有通义千问、DeepSeek、GPT等。判断标准就一个中文理解能力和指令跟随能力是否够强。实测下来DeepSeek在复杂约束条件处理上表现不错通义千问的中文语义理解占优而它们在处理逐字遵循绘图规范时都需要靠提示词来兜底——这也是后面我要重点展开的一环。第二步输出结构化数据。这一步容易被忽视。很多人直接让AI写Mermaid代码结果生成出来的图能跑但布局不合理、关系错乱因为模型把设计架构和写Mermaid语法两件事混在一起做了。我建议让AI先输出一个中间产物比如JSON里面包含节点列表、节点属性、边列表、分组信息。这样做的优势在于JSON是严格的数据结构便于校验也便于后续做布局优化同时可以先人肉检查一遍这些节点和关系对不对然后再决定要不要继续往下走。第三步生成绘图代码。有了结构化JSON之后再让AI把它转成具体的绘图语言。这里我推荐用Mermaid理由后面细说。这个阶段也不是简单地翻译还需要处理布局、分组、层次、方向等视觉维度。第四步渲染与迭代。渲染端我建议用Mermaid Live Editor本地跑或者mermaid-cli直接生成SVG/PNG。迭代环节是整个工作流里最容易被低估的因为AI生成的第一版几乎一定不符合预期需要围绕改布局改关系补节点做多轮对话这也决定了你提示词设计上要留好迭代的口子。2.2 绘图语言怎么选Mermaid、Graphviz还是PlantUML这三个是架构图领域最常见的三套代码化绘图方案不少朋友一直在纠结到底选哪套。我是这么看的方案优势劣势适用场景Mermaid语法简单、生态好、GitHub原生渲染、迭代快复杂布局能力弱超大图会有点乱快速出图、嵌入式文档、方案演示GraphvizDOT语言布局算法强大自动处理复杂DAG、树形结构语法更底噪学习成本略高复杂系统拓扑、依赖关系图、大节点量图PlantUML专业建模语义丰富时序图、用例图等对UML偏好灵活度不如前两者中文文档相对少偏软件工程设计文档的场景我在这套AI工作流里优先选择Mermaid倒不是因为它功能最强而是因为AI生成Mermaid的成功率更高。原因在于Mermaid语法规则相对收敛上下文长度敏感度比Graphviz好Transformer类模型更容易顺着语法走完。而且Mermaid的可视化效果好、风格偏清新适合直接放方案PPT里面不用再做美化。Graphviz我保留给那些节点数量超过30个、层级深、自动布局难度大的场景。2.3 为什么要让AI分步走而不是一键生成现在市面上的AI画图工具很多都能一眼生成架构图我为什么还要强烈建议分步走答案是可分步校验、可控修改、可追溯。架构图本质上是一种观点的可视化。同一个系统在不同人眼里有不同的架构边界同一个需求在不同阶段关注的粒度也不一样。如果AI一步出图你只能接受或推翻中间没有校准的机会。但如果分步走第一步出了节点和关系你可以先看逻辑是否正确第二步出了布局和细节你可以只改视觉层面的问题第三步出了问题还能精准定位是哪个环节导致的。项目里实际跑下来让AI分步骤出图的成功率和返工率远优于一步到位。这个方案还带来一个额外好处中间产物是可以复用的。JSON数据结构可以二次输入给其他AI系统比如做多AI协作时传给另一个模型做审查Mermaid代码可以直接放进文档系统甚至你可以在JSON阶段用脚本自动检查--比如检查是否有孤立节点、是否缺少必要的连接线。这类自动化校验做多了以后AI就不容出那些看起来合理实则矛盾的架构关系。3. 环境准备与工具选型一套完整可复现的AI架构图工作台3.1 大模型选型评测中文语义理解与指令跟随怎么平衡在我实际搭建这套环境之前先花了不少时间在模型选型上。强迫自己做一个横向评测表格出来因为指令跟随能力是AI架构生成质量的生死线。选型指标的优先级是这样的中文能力是否理解XX能力对齐ISO这类口语化和行业黑话遵循输出格式能否严格按照只输出JSON不要解释这类命令执行上下文长度能否容纳一个完整的中型系统描述多模块多个接口Token成本如果是高频使用场景成本选择非常关键。在这个标准下我最终锁定了三个备选通义千问Max版本中文理解强擅长把口语化需求转换成正式结构描述适合需求分析的初始阶段DeepSeek V3在结构化输出和逻辑推理方面表现优秀单参数推理成本低适合批量生成节点关系Claude或GPT-4级别能力可达前提下英文文档、复杂边界校验更强适合做架构语义安全性审查。就这套AI架构图工作流而言我的实际建议是双模型协作一个是设计模型负责把描述转成JSON另一个是绘图模型负责把JSON转成Mermaid。这样做的好处在于两个阶段对模型的能力偏好不同而且一旦某一个阶段频繁出错你可以只替换那个环节的模型不用把整条链路推翻。3.2 渲染与迭代环境本地还是在线渲染环境我同时备了两套。开发调试阶段用本地的mermaid-js/mermaid-cli优点是可以命令行批量渲染还能把SVG、PNG输出整合进CI/CD流程适合把架构图生成做成团队基础设施的一部分。演示和快速预览阶段直接用Mermaid Live Editor改完代码立即看效果。本地环境搭建很简单Node.js环境下执行安装然后写一个批量渲染脚本读取所有*.mmd文件并输出对应图片即可。你可以把脚本挂到Git钩子上实现文档提交后自动重新渲染架构图。版本注意Mermaid语法在v10和v11有些细节变化建议固定一个版本避免团队协作时因为渲染差异对不上。中文字体处理本地渲染如果遇到中文乱码或缺失字体需要显式指定--fontFamily参数。自动渲染时机只要架构图对应的JSON或Mermaid文件发生变化脚本就要重新执行否则文档里的图和描述容易脱节。3.3 提示词工程AI绘画出的核心关键真正决定AI架构图质量上限的不是模型而是提示词。这一步我建议重点打磨因为同样的模型提示词水平不同产出质量能差出一眼假和直接能上场的距离。我总结了一套AI架构图提示词模板核心思路是让模型明确自己的角色、任务输入、输出格式和约束条件四件套缺一不可。后面会给出可直接复制的完整模板。需要提醒的是AI生成架构图纠错的成本很高与其让它自由发挥再返工不如在提示词里提前把雷排干净。后续我会把踩过的坑列成检查清单方便大家照着抄作业。4. 实操过程从文字描述到可发布架构图的完整工作流4.1 角色设定与任务描述的写法很多人写提示词的时候只写帮我生成架构图这个我试过效果不稳定。真正重要的是给AI一个明确的角色定义并告诉它任务的上下文。实际项目里我用的角色设定模式是你是一位经验丰富的系统架构师熟悉微服务设计、分布式系统、云原生架构。你擅长将非结构化的业务描述转化为清晰、准确的系统架构模型。请注意你的输出必须严格遵循给定的数据格式而且只输出数据不要输出任何解释性内容。角色设定的背后逻辑是大模型在推理时会根据不同角色调整知识结构的激活权重。当你把它设定为资深架构师时它对微服务、消息队列、缓存、负载均衡这些架构组件的语义理解会明显更到位。这一点我在测试多轮后可以确认重要性排在整个提示词的第一档。任务描述要精确到清单式包含三个要素输入是什么、输出是什么、输出格式是什么。最好是明确写出不要输出与数据无关的文字包括示例、注释、总结。这样能最大限度避免模型跑题。4.2 第一轮生成业务描述转结构化JSON真正的第一步是把一段非结构化的、口语化的系统描述转换成结构化JSON。我在提示词里定义的目标JSON结构是{ system_name: 系统名称, nodes: [ { id: 节点唯一标识, name: 节点显示名称, type: 类型如 service/database/mq/cache/gateway, description: 简要功能描述, group: 所属分组 } ], edges: [ { from: 源节点id, to: 目标节点id, label: 关系描述如HTTP调用/异步消息/读写数据 } ], groups: [ { id: 分组唯一标识, name: 分组名称, description: 分组维度的业务含义 } ] }这个结构的价值在于它把架构图里最核心的三个要素节点、边、分组拆清楚了。节点标识用英文ID而不是中文名是为了后续生成Mermaid时避免中文ID带来的兼容性问题。type字段是给后面布局和视觉设计用的比如服务节点用矩形、数据库用圆柱。edges的label字段不仅能画线还能在线上标注RPC调用异步事件这样的语义让图的信息密度高出一个量级。我第一次跑这个步骤的时候用的是通义千问。输入一段约500字的系统描述输出效果相当不错节点识别准确关系也能对上。但有一个共性问题它倾向于把节点数量压得很少希望用一个大而全的模块去概括很多东西。这和我们想要呈现的细粒度架构图有冲突。对策就是在提示词里显式加一句节点覆盖所有功能模块和依赖组件不要合并同类项。4.3 第二轮生成JSON转换成Mermaid代码拿到可靠的JSON之后第二步就是转Mermaid。这里我设计了一套固定模板让AI严格按模板输出。模板长这样flowchart TB subgraph gateway-layer[接入层] A[API Gateway] -- B[Auth Service] A -- C[Rate Limiter] end subgraph business-layer[业务层] D[Order Service] -- E[Order DB] D -- F[Payment Service] F -- G[Payment DB] end subgraph middleware-layer[中间件层] H[消息队列] I[缓存集群] J[搜索引擎] end B -- H D -- I F -- J这套模板的要义是flowchart TB表示从上到下布局适合层级分明的架构图。如果架构是横向的分层结构比如接入层在左、数据层在右可以改为LRsubgraph用于分组对应JSON里的groups。分组的好处是一眼看出这一块是接入层这一块是数据层对评审和交流极其友好节点ID和显示名称分开Mermaid里节点ID[显示文本]ID用英文显示文本用中文。这样既不破坏语法又能展示中文关系行统一用A -- B如果要在线上标注关系语义可以写成A -- HTTP调用 -- B。我在实际生成过程中发现AI转出来的Mermaid代码经常存在两个问题一是节点ID与显示文本混淆二是有时候会自动加一些Mermaid不支持的修饰符。所以我在提示词里加了一条只输出纯Mermaid语法不要使用任何扩展图形属性只保留基础节点、分组、连线能极大降低渲染失败率。4.4 第三轮渲染出图与视觉优化Mermaid代码生成后拿到Live Editor里渲染只是第一步。真正能拿得出手的架构图还需要经过多轮视觉优化。我整理了几条高频优化项方向优化默认TB是上下布局但如果你系统里有客户端→接入→业务→数据这样的单向链路TB是最佳选择如果是展示系统间平等交互建议改LR左右布局线标签优化如果线条太多导致图面拥挤可以先用无标签线等确认核心关系后再逐步补标签分组内节点数量均衡不要让某个subgraph里挤了10个节点而另一个只有1个这样视觉上严重失衡建议在生成JSON时就要求按职责把节点均分到组里使用click指令、classDef样式做高级美化这属于进阶玩法但MVP阶段可以不用。一个非常实用的提醒AI生成的图可以做局部放大思路优化。比如核心链路下单→支付→履约单独作为一个子图铺开大节点非核心依赖监控、告警、日志收敛为一个小型节点组。这种视觉引导本质上就是架构师自己在画图时的构图习惯把这个要求写进提示词里出图质量会明显提升。4.5 直接抄作业面向生产环境的完整提示词模板前面讲了很多原则下面给一个我实际用了很久、效果稳定的完整提示词模板。可以直接复制到你的AI工作台里替换方括号内容即可。角色你是资深系统架构师精通分布式系统、微服务、云原生架构设计。你擅长把非结构的业务描述转化为准确完整的系统架构图。 任务 1. 接收用户在【系统描述】里提供的关于某系统架构的说明。 2. 分析该系统涉及的所有组件包括但不限于客户端、网关、业务服务、数据库、消息队列、缓存、搜索引擎、第三方依赖、监控系统等。 3. 输出一个严格格式化的JSON结构包含节点列表、关系列表、分组列表。 4. 节点覆盖所有功能模块不要合并同类项。 5. 关系必须覆盖所有必要依赖并在label标注关系类型。 6. 分组合理建议按接入层、业务层、数据层、中间件层、基础设施层划分。 输出要求 - 只输出JSON不要任何解释、Markdown代码块标记、注释。 - JSON结构必须符合给定示例不要增加或删减字段。 - 如果描述的信息不足请默认补全合理的架构组件并保持通用性。 【系统描述】 {在这里粘贴你的系统描述} 【输出示例】 {在这里粘贴JSON示例结构}这套提示词的妙处在于先是明确角色再是任务拆分最后是输出约束。模型几乎不可能跑偏。我还在这个基础上加了一个后置校验步骤每个JSON输出之后不要直接进渲染先用脚本或者人工扫一眼检查节点是否有空ID边是否引用了不存在的节点分组是否包含未被分组的节点。这三条是最常见的低级错误。5. 实战项目用这套AI架构图工作流搭建微服务电商系统5.1 需求场景描述我拿一个微服务电商系统来完整走一遍流程这样讲起来比较直观。假设项目经理给的原始描述是这样的这个平台要支持用户在小程序端和PC端下单订单模块负责创建订单、取消订单、查询订单支付模块接微信支付和支付宝商品模块维护SKU和库存用户模块管理登录注册和收货地址。后端服务之间通过HTTP和消息队列通信数据库用MySQL缓存用Redis搜索走Elasticsearch整个系统要部署在K8s集群里。把这段描述丢给AI我用的是DeepSeek配合上面的提示词输出来的JSON我已经整理简化了大概长这个样子{ system_name: 微服务电商平台, nodes: [ { id: client-mp, name: 小程序端, type: client, group: 接入层 }, { id: client-pc, name: PC端, type: client, group: 接入层 }, { id: gw, name: API网关, type: gateway, group: 接入层 }, { id: auth, name: 鉴权服务, type: service, group: 接入层 }, { id: order, name: 订单服务, type: service, group: 业务层 }, { id: payment, name: 支付服务, type: service, group: 业务层 }, { id: goods, name: 商品服务, type: service, group: 业务层 }, { id: user, name: 用户服务, type: service, group: 业务层 }, { id: order-db, name: 订单库, type: database, group: 数据层 }, { id: payment-db, name: 支付库, type: database, group: 数据层 }, { id: goods-db, name: 商品库, type: database, group: 数据层 }, { id: user-db, name: 用户库, type: database, group: 数据层 }, { id: redis, name: 缓存集群, type: cache, group: 中间件层 }, { id: mq, name: 消息队列, type: mq, group: 中间件层 }, { id: es, name: Elasticsearch, type: search, group: 中间件层 }, { id: k8s, name: Kubernetes集群, type: infra, group: 基础设施层 } ], edges: [ { from: client-mp, to: gw, label: HTTPS }, { from: client-pc, to: gw, label: HTTPS }, { from: gw, to: auth, label: 鉴权调用 }, { from: gw, to: order, label: HTTP分发 }, { from: gw, to: payment, label: HTTP分发 }, { from: gw, to: goods, label: HTTP分发 }, { from: gw, to: user, label: HTTP分发 }, { from: order, to: order-db, label: 读写MySQL }, { from: payment, to: payment-db, label: 读写MySQL }, { from: goods, to: goods-db, label: 读写MySQL }, { from: user, to: user-db, label: 读写MySQL }, { from: order, to: mq, label: 异步消息 }, { from: payment, to: mq, label: 异步消息 }, { from: order, to: redis, label: 库存预热/会话缓存 }, { from: goods, to: es, label: 商品索引同步 } ], groups: [ { id: access, name: 接入层 }, { id: biz, name: 业务层 }, { id: data, name: 数据层 }, { id: middleware, name: 中间件层 }, { id: infra, name: 基础设施层 } ] }5.2 从JSON到Mermaid完整转换过程与细节打磨拿到JSON之后我直接扔给AI让它转Mermaid。在提示词里同样要强调只输出Mermaid代码。这一版本跑下来的效果骨干关系已经正确但有一个不大不小的视觉问题所有节点都不在分组里属于扁平排列。这种情况在团队评审时很吃亏因为无法一眼看出层与层之间的边界。于是我要求AI把JSON里的group字段对应成Mermaid的subgraph同时把基础设施层的节点比如k8s也做成一个分组放到最外层。最终生成的Mermaid代码可以参考下面这个优化版本flowchart TB subgraph access[接入层] client-mp[小程序端] -- gw[API网关] client-pc[PC端] -- gw gw -- auth[鉴权服务] end subgraph biz[业务层] order[订单服务] -- order-db[(订单库)] payment[支付服务] -- payment-db[(支付库)] goods[商品服务] -- goods-db[(商品库)] user[用户服务] -- user-db[(用户库)] gw -- order gw -- payment gw -- goods gw -- user end subgraph middleware[中间件层] mq[消息队列] redis[缓存集群] es[Elasticsearch] end subgraph infra[基础设施层] k8s[Kubernetes集群] end order -- 异步消息 -- mq payment -- 异步消息 -- mq order -- 库存预热/会话缓存 -- redis goods -- 商品索引同步 -- es5.3 渲染后的调整话术用什么指令让AI改布局渲染出的第一版通常能看但总有细节想调。这里我整理了高频调整指令直接照着用把客户端节点移到最上面数据层放在最下面对应提示词就是加一行客户端节点作为source数据节点作为sinkXX服务和XX服务之间有两条连线请合并成一条并标注两种关系防止线太多网关和业务服务之间不要直接连接改成网关分发给各服务这影响的是分层语义描述把XX节点放到XX分组的下一层用于调整subgraph内层级嵌套。我这套实操下来最关键的一句话是如果调整后依然不符合上述约束请重新检查你的输出是否遵守JSON示例不要自行发挥。它能大幅减少AI在迭代中偷偷加戏的问题。6. 多AI协作与Agent化从单一生成到架构图设计自动化6.1 用什么方式让多个AI角色协同处理架构图如果只是自己单机用单一模型方案完全够。项目如果要往团队级工程化走多AI协作是绕不开的方向。核心逻辑是拆分成三个角色需求分析师用通义千问负责把业务描述拆成准确的需求条目输出给下游架构设计师用DeepSeek接收需求条目产出JSON结构化架构设计绘图工程师用Claude级或GPT-4级模型接收JSON产出Mermaid代码同时做语法校验质检员独立模型实例或规则脚本检查节点完整性、检查边引用合法性、检查分组归属。多AI协作在工程上的落地抓手是结构化中间产物——每一层模型只对上一层的输出负责不跨层通信。这个设计能避免模型间互相污染上下文也便于单独优化某个角色的能力。6.2 用AI Agent工作流把生成架构图变成团队基础设施顺着多AI协作的思路再往前走一步就是AI Agent工作流。架构图的生成不应该只发生在个人笔记本上它应该成为团队文档系统的一部分。我的想法是做一个Agent它具备下面这些能力监听文档仓库的变更事件比如某个architecture.md文件更新了自动提取系统描述区块触发AI生成JSON与Mermaid代码生成后自动渲染把SVG、PNG回写到指定目录更新文档里的图表引用链接并推送变更记录到协作群。这个思路的副产品是架构图版本管理每一版架构变化都有迹可循。实践下来它还能自然形成一个架构知识库每次迭代后的架构图配上当时的业务背景描述后续再做同类系统设计时可以直接拿历史数据做参考让AI的起点一次次提高。7. 常见问题与排查技巧实录这套工作流跑得再顺也难免遇到问题。下面列几个我实际踩过、也帮同事排查过的典型坑附上对应解法。7.1 生成的节点之间没有连线拓扑是离散的表现Mermaid代码能渲染但图里是一堆孤立的节点只有子图结构没有连线关系。排查思路先回到JSON检查edges数组看是否为空或引用了不存在的节点id。大概率是描述阶段给出的关系信息太模糊。比如订单模块和商品模块有关联AI难以判断关联类型保险起见干脆不生成。对策有两条一是在描述阶段就给足方向性信息比如订单服务调用商品服务查询SKU信息二是在提示词里增加一条如果节点之间存在微弱的业务关联请补全合理的默认关系并标注为依赖。这一条能显著减少孤立节点。7.2 Mermaid语法渲染报错错误信息指向unexpected token出现此类报错八成的锅都在AI输出时带了额外字符。最常见的是输出里包含Markdown代码块标记mermaid、行尾多余的逗号或者节点ID用了中文。在提示词里强调只输出Mermaid语法不要Markdown包裹不要额外说明文字能解决大部分问题。如果还是报错检查一下引号中文字符和英文引号混用也会触发解析错误。7.3 AI生成的架构图看起来对但架构设计本身是错的这种问题最隐蔽因为语法上完全没毛病。比如支付服务放在业务层但订单服务又直接连接了支付数据库这在实际系统里往往是要避免的——支付数据不应该被订单服务直接访问。这就要求质检员角色不能省。建议在提示词里要求模型输出时自检也可以编写一个简单的规则脚本去检查数据库节点是否被多个服务直接引用这类典型问题。7.4 大图渲染后布局混乱节点挤在一起节点超过40个或者分组结构复杂的时候Mermaid默认布局会让人觉得杂乱。解法有很多我自己最常用的是进一步拆分把一张大图拆成总览图只画出层间关系 分层详图各层内部展开并在文档中交叉引用既保证清晰度又能保持完整信息。另外可以在提示词里要求AI优先确保层次结构清晰减少不必要的跨层连线。7.5 提示词这么好用还需要人工介入吗说句实话这套工作流再完善也替代不了架构评审。AI帮你快速产出的是候选架构图但方案的合理性、边界情况、成本权衡这些最终还是得有经验的人来拍板。这也是我为什么要强调分步产物——每一步都方便人审而不是到最后生成一张大图来赌运气。8. 架构图成果的深度复用AI不只帮你画还帮你维护8.1 从单一图片到结构化知识资产当架构图以JSONMermaid图三份产物形式沉淀之后它的价值就远超一张截图了。JSON是机器可读的可以接入系统做自动分析Mermaid是文本可控的可以直接放进Git做版本管理图是给人看的用于评审与文档展示。我建议每个项目组建立这样一个目录结构docs/architecture/digital-platform.md系统描述文档digital-platform.json结构化架构数据digital-platform.mmdMermaid源码digital-platform.png渲染输出图这个目录本身就是一个轻量级架构资产库配合CI/CD任何一次架构变更都有理有据、有迹可循。8.2 用架构图反哺其他AI场景测试用例、产品文档、专利辅助链接这套工作流的后链路潜力也很大。我可以举几个亲身试过的例子测试方向把JSON喂给AI自动生成微服务的集成测试点比如需要mock哪些外部依赖、哪些服务间需要做契约测试输出效率比人肉读文档翻代码快很多产品文档方向把JSON用于生成面向新人的系统模块说明图文对应降低理解门槛专利辅助链接方向架构图作为技术方案可视化素材结合AI辅助生成技术效果描述能帮研发把系统创新点讲得更清楚注意只是辅助整理材料最终提交仍需专业人士审核AI Agent化让Agent在架构图发生变化时自动触发影响面分析比如某个服务拆分自动列出所有涉及调用链的服务这个能力在大型系统演进中非常值钱。8.3 后续扩展空间从架构图到全链路系统设计这套工作流未来可以很自然地延展到从架构图扩展出时序图、部署图、C4模型图甚至可以联动生成基于OpenAPI的接口文档框架。我自己的计划是把它变成一个系统设计Copilot输入一个想法产出架构图、接口清单、部署拓扑、测试要点。每个环节都独立生成、独立校验最终合成为一份完整的技术方案手册。9. 三十条经验总结你在别处很难一次性看到的实操建议把AI架构图方案推进到能稳定产出的状态需要把很多小细节串起来。分享几条我个人最有体感的经验按重要性排序永远分步走不要一步到位。把自然语言、JSON、Mermaid三个层次彻底分开每层都能独立校验创建节点覆盖清单提示词减少AI习惯性合并节点的问题中英文ID分开管理ID用英文显示文本用中文这两个概念不能混使用只输出XXX这类强约束指令拒绝任何解释性内容首次出图后先看构图再改关系不要一上来就调细节对用户描述中缺失但有必要的组件如K8s、网关、监控要求AI默认补全并标注默认多模型配合时模型切换点放在JSON之后而不是自然语言之后排查错误时永远先问哪一层出了问题是描述层、模型层还是渲染层写文档时优先用文本型架构图Mermaid这样每次改动都有diff可看评审效率高得多本地渲染要固定Mermaid版本避免把时间浪费在莫名其妙的兼容问题上。记得我在第三轮迭代时最崩溃的一次是把AI生成的Mermaid代码粘到Live Editor渲染全红排错排了20分钟。后来发现只是输出里多了一个反引号。从那以后我总结出一个铁律AI输出必须过校验脚本不能直接信任。后来我在提示词模板里加了一条如果输出中包含Markdown代码块标记视为非法。这类小修补积累多了工作流的稳定性才会越来越接近生产级。另外必须强调一个安全底线AI生成架构图可以用来提升效率但在任何严肃的对外环境中都不能让未经人工审核的AI产物直接作为正式材料。架构设计涉及系统部署、数据流转、安全边界等关键内容人审这一步永远不能省。这也是从业者最基本的职业素养。如果后面再把Agent化做深一点还可以在每次方案生成后自动推一个架构风险提示——比如订单库被超过三个服务直连请确认是否引入数据服务层支付服务和用户服务之间存在跨层调用请判断合理性。到那个阶段AI架构图工具就不只是画图工具了它会变成一个真正懂得架构设计的助手。最后说一句我自己的体会画架构图从来都不是目的理解系统的关键链路和数据流才是。AI帮我们省掉的是从语言到视图的翻译成本但什么叫好的架构这个判断永远需要人来掌舵。