干过架构设计这行的都有体会需求评审会上大家讨论得热火朝天回头整理架构图的时候又得对着白板照片一点点重画。改一处模块划分连带影响所有关联关系一张图能磨一个下午。后来我干脆试着把大语言模型当成一个“系统分析师”来用直接跟它描述业务需求让它先拆解系统边界、识别核心模块和依赖关系再输出结构化的图表代码一键渲染成专业架构图。这条路子实测下来把画图的时间从小时级压缩到了分钟级而且图的质量比手工整理还要规范。这篇文章就围绕这个实践展开适合想把 AI 引入系统设计流程的开发者、架构师也适合正在学习系统设计的同学参考。我会把完整的提示词设计、技术选型、工具链搭建、常见坑位一次说清楚。1. 为什么要把 AI 变成“系统分析师”从口头需求到架构图的链路拆解1.1 传统画图方式的最大瓶颈不是“画”而是“想”先说我观察到的现象。很多团队画架构图真正的耗时大头根本不是鼠标拖拽那几下而是脑子里得先把关系理顺系统跟外部系统之间有哪些交互核心业务模块应该拆成哪几个数据流是同步还是异步权限校验该放在网关层还是业务层这些问题想不清楚画出来的图就是一张“线一团乱、框一大片”的废图。而要理清这些问题又得去翻需求文档、看接口定义、找业务方确认边界。等这一套信息收集完时间已经过去大半。更讨厌的是需求变更。业务方今天说“加一个消息通知模块”后天说“用户系统要支持多租户”每动一次整个图的模块划分、依赖关系就要联动调整。手动改图的时候最容易漏掉的就是“改了 A 模块却忘了连带 B 模块的依赖箭头”。这种错漏在评审会上被指出来相当尴尬。所以我把目标定得很明确不是去找一个“自动画图工具”而是找一个“能帮我把架构想清楚”的助手。大语言模型恰好擅长做这件事——它能在上下文里同时处理角色、系统、交互、约束这些信息并输出结构化的分析结果。关键是它的输出可以直接映射成图表描述语言。1.2 核心路径自然语言 → 结构化架构模型 → 渲染成图整个做法的核心链路并不复杂自然语言需求 → AI 做架构分析 → 输出结构化图表描述代码 → 渲染器生图这里面最关键的一步是第二步到第三步的转换。我在这里做的设计决策是不要让 AI 直接给“一张画好的图”而是让 AI 先给出“架构分析结论”再按照我的格式要求输出图表描述代码。这样做的好处很明显第一架构分析是可审查的。AI 说“系统分为 Web 端、API 网关、用户服务、笔记服务、搜索服务”我能逐条判断这个拆分合不合理而不是拿到一张密不透风的图脑补。第二分析结论和图表互为印证。文档里如果写着“用户服务负责登录鉴权”那架构图里就该有对应的模块和依赖关系。AI 输出的文字分析可以作为图的补充说明图又反向验证分析有没有遗漏。第三后续迭代维护非常轻量。需求变了我只需要在对话里追加一句“把消息通知模块加进来”AI 会在原有基础上做增量修改而不是让我从头再来。这其实就是把“系统分析师”的工作方式搬进了 AI 交互流程里先调研需求再拆解边界最后用图说话。1.3 动嘴皮子背后的可操作前提标题说“动动嘴皮子”并不是夸张。实际上语音输入只是交互入口之一真正让这件事成立的前提有三个一是大语言模型具备足够的架构常识。它知道什么是微服务、什么是消息队列、什么是 CDN、什么是网关不需要你从零教起。二是图表描述语言把“图”变成了“代码”。只要 AI 能输出符合语法的代码渲染就是水到渠成的事。所以选哪种图表描述语言直接决定了 AI 的输出质量和渲染难度。三是提示词把“怎么做分析”说清楚了。模型不会自动知道你想要 C4 分层还是 UML 类图不会主动去识别系统边界。这些约束必须写进提示词里。把这三个前提落实之后你会发现所谓“动嘴皮子”本质是你负责说出业务意图AI 负责把意图翻译成被架构师认可的表达形式。你的很多专业能力依然要用在“评审”和“决策”上只是画图这个纯体力活彻底交出去了。2. 实现方案与工具选型Mermaid、PlantUML 与 Structurizr DSL 对比2.1 三种架构描述语言的定位差异要落地这个方案先得选对“输出语言”。我实际对比了三种分别是 Mermaid、PlantUML 和 Structurizr DSL。三者的核心区别在于设计目标不同。Mermaid 是一个轻量级的图表描述语言语法类似 Markdown最大的优势是渲染简单很多代码托管平台原生支持写进 Markdown 文档里直接能预览。它支持的图类型非常全流程图、时序图、状态图、甘特图、类图都有。缺点是它对“架构模型”的约束很弱它只负责画图不负责保证图在逻辑上是一套严谨的架构模型。PlantUML 是老牌的图表描述语言特别适合 UML 类图、时序图、用例图在高龄技术团队中使用率很高。它的语法比 Mermaid 稍繁琐渲染依赖 Java 运行时好处是 UML 建模能力强输出图表的专业感很足。如果团队做的是接口设计、类关系建模PlantUML 更老练。Structurizr DSL 是这三者里最“架构师向”的它专门为 C4 模型设计通过代码定义系统上下文、容器、组件、部署层级并且强调“图”只是架构模型的视图之一。它既能产出一张上下文图也能基于同一个模型切出各种视角的图。缺点是学习曲线最陡而且它的生态更多面向团队级架构治理个人快速画图反而有点重。我的选择逻辑是个人快速生成、嵌入文档、迭代频繁的场景优先用 Mermaid团队级架构建模、需要从多视角看同一套系统的时候用 Structurizr DSLPlantUML 保留在 UML 专项图的场景里。维度MermaidPlantUMLStructurizr DSL学习成本低中中高渲染部署极轻浏览器/编辑器即可需 Java 环境需专用 CLI 或平台架构模型约束弱只管画图中偏 UML强面向 C4 模型适用场景快速画架构图、嵌入文档类图、时序图专项建模团队级架构治理AI 输出稳定性好较好好但需提示词严格约束2.2 为什么我把 Mermaid C4 分层作为主路线最终我把主路线定为 Mermaid并且配合 C4 模型的思维去组织图。这个选择的理由很实际Mermaid 的语法简单AI 输出的结果很少出现语法错误。PlantUML 如果输出用例图缩进和括号错一个渲染就直接报错。Mermaid 虽然也有语法要求但容错性明显好一截就算有点小问题人工看一眼也能快速修掉。Mermaid 能直接嵌进 Markdown 文档这对“架构图随文档走”的习惯太友好了。我写完分析记录图就在旁边不用额外维护一个图形文件。再说 C4 模型。这是我在提示词里经常借用的分析框架Context上下文、Container容器、Component组件、Code代码。C4 的核心思想是分层表达每一层只画当前视角需要看到的内容这样能有效避免架构图变成一团乱麻。跟 AI 配合的时候C4 的价值格外明显。我可以先让 AI 生成系统上下文图确认整体的边界再让它把某个关键容器展开成组件图深入局部每一层都是一张独立图看得清楚改得也方便。这比让它一口气生成一张“包罗万象”的大图聪明得多。2.3 完整工具链与最小环境准备整套工具链其实很轻不需要太重的安装配置。我本地用的工具组合如下大语言模型的对话接口是基础可以是商业 API也可以用本地部署的开源模型。V3 级别的对话能力完全够用不一定追最新旗舰。渲染 Mermaid 图则很简单推荐从简到繁三种方式第一种是直接在支持 Mermaid 渲染的在线编辑器里粘贴代码生成第二种是本地安装命令行工具比如用 npm 安装 mermaid-cli把 Mermaid 编译成 SVG 或 PNG第三种是图形界面工具Chrome 插件或部分 Markdown 编辑器里面的预览插件都可以直接渲染。我的个人习惯是本地编码阶段用命令行工具生成图片因为我需要批量产出多张架构图并且在脚本里自动维护跟业务方评审的时候改用在线编辑器快速演示改起来不用重新编译。# 用 npm 安装 mermaid-cli需要有 Node.js 环境 npm install -g mermaid-js/mermaid-cli # 将一份 mmd 文件渲染成 PNG mmdc -i input.mmd -o output.png -w 2048基于这套工具链AI 输出的 Mermaid 代码可以直接落盘成.mmd文件再一行命令变成高清图片。我在后面实操章节会给出完整的调用示例和详细步骤。3. 核心实操让 AI 按“系统分析师”的方式输出架构图3.1 提示词设置的三个关键维度角色格式迭代很多人用 AI 画架构图失败第一步就错在提示词太笼统比如直接丢一句“帮我画一个在线笔记系统的架构图”。模型确实能给你画但画出来通常是一张不规范的“大杂烩”——图表里堆了十几个框又放数据库又放缓存又放第三方登录谁也不挨着谁关系箭头也很随意。要让它产出符合系统分析规范的图提示词里必须把三样东西讲清楚一是角色定位。明确告诉 AI 它是“系统分析师”熟悉 C4 模型职责是先分析需求再输出架构模型相关的图表代码。角色定位能让模型自动带入“分析-建模”的思维而不是只当一个画图工具。二是输出格式约束。必须告诉它输出什么语言的代码、使用什么图类型、节点和关系怎么组织。更高级一点的做法是同时给一两个“输出示例区”你不用展示完整例子只要给一小段符合预期的代码片段它就能照着这个风格输出。这就是 few-shot 的力量实测下来能显著减少格式跑偏。三是迭代机制。不要指望一次对话拿到完美成图。正确的做法是分几步先让 AI 输出系统角色的清单和系统边界描述再让它基于确认无误的边界生成上下文图进一步细化到关键模块时再用对话让它单独展开子模块。这样既不会信息量爆炸又能让你在每一步都做人工把关。3.2 一个完整实战为在线笔记系统生成上下文图我用一个完整的例子走一遍流程。假设需求是“做一个在线笔记应用用户可以在 Web 端和 Android 端浏览笔记、写笔记支持标签分类、全文搜索、多人协作管理员可以管理用户权限。”我没有给它任何结构化的技术约束完全模拟“动嘴皮子”描述需求的状态。我的提示词如下你是一名资深系统分析师熟悉 C4 架构模型和 Mermaid 语法。 请先基于需求做架构分析再从系统上下文视角生成 Mermaid 的 flowchart 图。 需求做一个在线笔记应用用户可以在 Web 端和 Android 端浏览笔记、写笔记 支持标签分类、全文搜索、多人协作管理员可以管理用户权限。 要求 1. 先输出文字分析外部角色、外部系统、期望的系统功能边界。 2. 再输出 Mermaid 代码以 system context 视角展示主系统与外部角色、外部系统的关系。 3. Mermaid 图使用 flowchart LR每个节点用类名 说明的格式箭头标签写明交互类型。这里我做了三个设计。第一要求“先输出文字分析”是为了让它在画图之前先梳理边界而不是直接闷头画。第二要求“以 system context 视角”防止它越级画出太细的容器组件。第三指定 flowchart LR 和节点格式避免输出的结构五花八门。AI 给我的分析结果大致如下外部角色普通用户、管理员。 外部系统第三方邮件服务用于注册/找回密码、对象存储服务用于存储笔记附件。 系统功能边界笔记管理、多端同步、标签分类、全文搜索、协作共享、用户与权限管理。这段分析本身质量很好尤其是把“对象存储服务”作为外部系统识别出来说明模型理解了附件存储不应该塞进主服务内部。确认分析无误后它输出了下面这段 Mermaid 源码我这里用纯文本形式展示方便复制flowchart LR User[普通用户] Admin[管理员] NotesSys[在线笔记应用] EmailSvc[第三方邮件服务] ObjectStore[对象存储服务] User --|HTTP/HTTPS 访问br/Web/移动端| NotesSys Admin --|后台管理操作| NotesSys NotesSys --|发信请求 SMTP| EmailSvc NotesSys --|附件上传/下载| ObjectStore把这段代码复制进渲染器出来的就是一张清晰的上下文图两个外部角色从左侧指向主系统主系统向右伸出两条依赖线指向两个外部系统箭头标签也写清楚了交互协议。这张图拿去给业务方看没有任何技术压力也把系统边界讲得明明白白。3.3 从上下文图到容器图让 AI 分层细化架构上下文图只解决了“系统外长什么样”的问题。评审通过后下一步就是往内一层走容器图。容器图展示主系统内部由哪些可部署的单元组成以及它们之间的调用关系。我继续追加一轮对话继续做下一步将“在线笔记应用”展开为容器图。 候选容器包括 Web 应用、Android 应用、后端 API 服务、数据库、搜索引擎、消息队列。 请先说明每个容器的职责再输出 Mermaid 的 container 视角图。 要求容器之间标注通信方式和数据流方向数据库不直接暴露给客户端。这里我给了候选容器列表。这是一个取舍既利用模型的常识做初步拆分又加了自己的约束确保结果符合真实技术场景。模型输出的容器拆分如下Web 应用面向浏览器的单页应用处理渲染与用户交互。 Android 应用移动端原生应用。 后端 API 服务处理业务逻辑提供 REST API。 主数据库存储用户、笔记、标签等核心业务数据。 搜索引擎提供全文索引与检索能力。 消息队列解耦笔记更新与搜索索引重建异步处理协作通知。然后输出的容器图源码大致是这样的flowchart TB WebApp[Web 应用] AndroidApp[Android 应用] ApiSvc[后端 API 服务] MainDB[(主数据库)] SearchEngine[搜索引擎] MQ[消息队列] WebApp --|REST/JSON| ApiSvc AndroidApp --|REST/JSON| ApiSvc ApiSvc --|SQL| MainDB ApiSvc --|写入索引任务| MQ MQ --|异步消费| SearchEngine ApiSvc --|查询请求| SearchEngine这里我刻意让 AI 加了主数据库的存储符号格式渲染出来是一个圆柱体一眼就能看出“这是数据库”。容器之间只有 API 服务跟数据库、搜索引擎发生关系客户端永远不直连数据层这是我对它的约束生效的体现。到这一步“动嘴皮子”的价值已经非常明显了一轮对话让系统边界和分析结果全部落成图形而且每一层的图都是可以直接评审交付的。接下来我再走一遍完整的工程化流程讲清楚怎么把这条链路变成日常可用的“系统”。4. 工程化落地渲染环境搭建与常见问题排查实录4.1 把随机对话变成可靠产出的工程化步骤对话式生成有个问题每次生成的图质量不稳定。有时候标点符号多了一个渲染器就不认了有时候节点命名不统一同一个意思一会儿叫“ApiService”一会儿叫“ApiSvc”。要把这套流程从“偶尔好玩”变成“日常可靠”需要加一道工程化约束设定“代码生成规范”。我习惯在提示词末尾追加一段固定模板强制 AI 遵循。这个模板包括节点命名规则、箭头语法、子图分组、输出纯净代码不要加前后解释。我给出一份可以直接复制的规范模板[Mermaid 代码规范] - 使用 flowchart LR 或 TB不要使用 graph 旧语法。 - 节点命名统一用大写驼峰如 User、NotesSys、ApiService。 - 箭头标签用简短动词短语如 HTTP 调用、异步写入。 - 涉及数据库节点时使用括号形式渲染圆柱体。 - 只输出 Mermaid 代码不附加任何说明。这个模板写进提示词尾部之后AI 产出的代码格式基本就稳定了。我再配合本地 CLI 批量渲染就能保证每一张图都按同一风格交付无论是写文档还是做汇报观感都整齐。4.2 踩坑记录从渲染报错到边界失控的排查经验再顺手的工具也有翻车的时候。我把自己实际碰到的典型问题和排查思路整理成了一张速查表这些坑你在实操中大概率也会遇到。现象常见原因排查与解决思路渲染报错浏览器提示语法错误箭头写法不符合 Mermaid 语法比如用了-而不是--标签引号未闭合先用在线编辑器定位到报错行提示词里强调“只输出合法 Mermaid 语法代码”把规范模板贴进去中文标签显示乱码字体问题或编码问题优先在本地 CLI 渲染时指定-f字体参数在线编辑器一般不存在此问题图太密几十个节点堆在一起模型把模块拆得过度详细没有分层表现强制要求“当前视角只画 6-10 个节点”超过则提示“先拆分子模块后续用组件图单独展开”逻辑错误数据流方向反了模型对“下单请求从用户到系统”这类语义理解偏差要求它在文字分析中先写明关键数据流走向确认后再生成图不要跳过分析直接画每次重新对话图的命名不一致上下文丢失模型重新随机命名固定一个全局命名表在提示词里重申或者把上一次输出的源码贴回去要求增量修改AI 输出的代码夹杂大量解释文字提示词缺少“只输出代码”的约束追加纯净输出指令如果还无效就把它输出的代码段提取出来手动清洗这里面我觉得最容易忽视的是第一种Mermaid 语法细节。很多团队用了 Mermaid 很久偶尔还是会踩到箭头写错、标签中文空格这些细节坑。排障的关键是不慌Mermaid 的报错信息虽然有时不够友好但把出错代码逐行检查重点看箭头符号和引号闭合基本都能解决。4.3 本地渲染脚本的完整配置参考我习惯写一个简易脚本来完成“源码入库 → 批量渲染 → 输出归档”的工作流。下面是一个最小可用的做法便于你直接套用。先准备目录结构arch-docs/ ├── src/ # AI 产出的 .mmd 源文件 └── out/ # 渲染后的图片输出然后写一个批量渲染脚本用 Python 调用 mmdc 命令行import os import subprocess src_dir src out_dir out os.makedirs(out_dir, exist_okTrue) for filename in os.listdir(src_dir): if filename.endswith(.mmd): input_path os.path.join(src_dir, filename) output_path os.path.join(out_dir, filename.replace(.mmd, .png)) # 额外加 2 倍宽度保证导出图片清晰 subprocess.run([ mmdc, -i, input_path, -o, output_path, -w, 2048, -b, white ], checkTrue) print(全部架构图渲染完成)这个脚本本身没什么难点关键是两个参数-w 2048保证图片在投影或文档里放大不糊-b white保证背景纯白避免透明背景在部分文档工具里显示成黑色。我把 AI 每次生成的源码存进 src 目录脚本一跑out 目录里就是全部图片。之后写设计文档、做评审 PPT直接引用这些图片就行不用再手动截图。5. 把“动嘴皮子”落到真实工作流进阶技巧与扩展场景5.1 让 AI 理解你的业务黑话建立术语表架构图专业与否不只取决于图的连线还取决于术语的表达。每个行业都有自己的业务语言比如电商行业里的“SKU”“履约单”“拒付”教育领域里的“班课”“课时包”“退费单”。如果你不把这些术语告诉 AI它默认会用自己的通用词汇去表达产出的图跟业务方认知对不上评审会直接卡壳。解决办法是在提示词里附加一个小型术语表比如[业务术语表] - 课次预约用户对一节具体的授课时间段进行的预约操作。 - 教师收入单根据教师完成的授课记录生成的结算数据记录。 - 退款审批单经过风控审核后产生的退款凭据。加了这一块之后AI 输出的节点命名和关系描述都会贴近业务习惯。我自己实测过没加术语表的图业务方看半天问“这是什么”加了术语表之后图直接变成评审材料根本不需要额外解释。这其实就是用 AI 的“办事前先对齐概念”来模拟分析师进场前的业务调研。5.2 维持架构图简洁的四个硬性约束AI 生成的架构图最常见的翻车方式是“信息过载”它恨不得把所有想到的东西都画进去结果图上一百多个节点几乎没法看。我的经验是对输出做四个硬性约束第一用分层限制信息量。上下文图就只画角色与外部系统不要出现具体的数据库名、缓存组件名。第二用数量限制节点。对话里明确要求“本节节点控制在 8 个以内”如果多于 8 个要求模型拆成子模块子模块单独画图。第三用深度限制细化程度。按 C4 层级逐层推进每一层只做当前粒度的事。比如画容器图时不要展开到内部的代码类。第四用“一行一关系”限制连线。让模型尽量不画长距交叉箭头交叉太多就把图拆开。Mermaid 的 subgraph 语法可以用来做视觉分组把强相关的节点包在一起可读性显著提升。这四个限制看起来琐碎但聚在一起的效果非常明显。我对照过同一个人同一个需求不加限制的图一团乱麻加了限制的图清晰专业评审通过率高很多。5.3 后续还能怎么玩从静态图到评审文档的自动化架构图画好只是第一步把图的“数据价值”榨干才更有意思。我的后续扩展方向有三个第一个方向是让 AI 从同一套架构模型中生成不同视角的图。比如画完容器图后让它生成“部署环境视角”的图把容器映射到服务器、Kubernetes 节点上或者让它生成“关键路径视角”的图高亮连接登录、搜索这条主链。基于同一个模型多出几张视图是 C4 思维最值钱的部分。第二个方向是让 AI 把架构图“翻译”成接口清单或风险清单。我试过让它基于架构图源码列出“系统间集成点说明”能直接作为接口文档初稿。虽然细节还需要人审但框架性的工作确实省了。第三个方向是定期用对话让 AI 对比“上个月架构图”和“这个月架构图”的差异自动输出变更摘要。这其实是把架构治理中的文档维护工作也半自动化了。我个人的体会是这套做法真正的价值不只是“省时间”这么简单。它把架构设计的思考过程从个人的脑内变成可对话、可保存、可追溯的记录。你跟 AI 聊的每一轮分析本质上都是一份带图的知识资产。下次团队里来新人把这段对话和产出的架构图丢给他他理解系统所需的时间会大幅缩短。最后再分享一个小技巧生成 Mermaid 图时尽量把一条箭头的关系语义限定为一句话比如“调用”、“写入”、“订阅”。不要用长难句这种歧义表达。图里的箭头就是系统的骨架骨架清楚后面细化填充什么事情都顺。