1. 项目概述从“画图工具”到“设计伙伴”的转变作为一名在软件架构领域摸爬滚打了十多年的老兵我画过的架构图连起来能绕办公室好几圈。从早期的Visio、Rational Rose到后来的OmniGraffle、Draw.io再到如今各种在线协作工具工具在变但一个核心痛点始终存在从脑海中的设计构思到一张清晰、规范、能准确传达意图的图纸这个过程充满了反复的“翻译”损耗和体力劳动。你不仅要懂技术还得是个不错的“美工”和“文档工程师”。直到我开始系统性探索用AI来画架构图才发现这不仅仅是换了个画笔而是引入了一位能理解你意图、快速将思维可视化的“设计伙伴”。这个项目就是关于如何通过Prompt工程将诸如GPT-4、Claude、Midjourney乃至一些专业图表生成AI从“玩具”变成你架构设计工作流中可靠、高效的一环。很多人对“AI画图”的理解还停留在输入“画一个微服务架构”然后得到一张卡通示意图的阶段。这完全低估了现代大语言模型和文生图模型在理解复杂逻辑、遵循规范方面的潜力。核心价值不在于替代你思考而在于加速从“思考”到“表达”的过程并在这个过程中通过“对话”帮你梳理和检验设计本身。无论是绘制标准的业务架构图、系统架构图还是描述复杂的微服务交互、数据流走向一个精心设计的Prompt能引导AI生成出结构严谨、元素规范、甚至可以直接放入设计文档的图表。这尤其适合需要快速原型沟通、方案评审、或者维护大量架构文档的团队。2. 核心思路将架构设计语言“翻译”成AI能理解的Prompt要让AI成为合格的“绘图员”关键在于建立一套有效的沟通机制。你不能用和人沟通的方式“这里画个数据库那边来几个服务”直接命令AI而需要将架构设计的元语言和约束条件通过Prompt清晰地“喂”给它。2.1 理解AI绘图的两条技术路径目前利用AI辅助绘制架构图主要有两条技术路径它们各有优劣适用的Prompt策略也完全不同。路径一基于大语言模型LLM的图表描述生成代表工具Mermaid通过GPT-4等生成代码、PlantUML、以及一些能直接输出图表JSON结构的AI。原理你向LLM描述架构LLM理解后输出一种标准的、机器可读的图表描述语言如Mermaid语法、Graphviz的DOT语言。你再将此代码粘贴到支持该语言的渲染工具如Mermaid Live Editor、Typora、GitLab Wiki中即可得到矢量图。优点极度精准和可编程。元素位置、连线样式、子图分组都可以通过代码精确控制。生成的图表是矢量格式易于嵌入文档、版本管理因为本质是文本代码。非常适合生成逻辑复杂、需要严格遵循公司制图规范的系统架构图、序列图、类图。缺点需要间接步骤生成代码-渲染且美学表现力相对固定依赖于渲染引擎的默认主题。路径二基于文生图模型Diffusion Model的直接图像生成代表工具Midjourney、DALL-E 3、Stable Diffusion配合ControlNet等插件。原理你通过自然语言描述你想要的图像模型直接生成像素图片。优点视觉表现力强风格多样。可以生成非常美观、具有特定艺术风格如科技感、手绘风、白板草图的架构图在演示、海报、初步创意沟通时效果惊艳。缺点可控性差细节难以精确。让AI在生成的服务图标旁边精确写上“User-Service API Gateway”字样并确保连线正确无误是极其困难的。元素的位置、数量也常出现偏差。我的实践选择对于严肃的工程实践我几乎全部采用路径一LLM 图表代码。因为它可靠、可重复、可集成。而路径二更适合制作宣传材料或头脑风暴时的灵感激发。本项目的核心Prompt工程也将主要围绕路径一展开。2.2 构建Prompt的层次化思维框架一个能高效生成架构图的Prompt绝不是一句话的魔法。它应该是一个结构化的“设计任务书”。我将其分为四个层次角色与目标层Role Goal首先定义AI的角色和本次绘图的核心目标。这能锁定AI的“工作状态”。示例“你是一个经验丰富的云架构师擅长用清晰规范的图表传达设计意图。你的任务是根据我的描述生成一份标准的、可用于技术文档的Mermaid流程图代码。”架构规范与风格层Specs Style定义图表的技术栈、视觉风格和制图规范。这是确保输出专业性的关键。内容应包括图表类型指明是流程图graph TD、时序图sequenceDiagram、类图classDiagram还是ER图等。元素映射明确不同架构组件对应的图形。例如“用户服务使用圆角矩形数据库使用圆柱体消息队列使用圆柱体加闪电图标外部系统使用平行四边形。”样式约定定义颜色、线型、字体等。“所有微服务用蓝色填充数据存储用绿色外部系统用灰色。关键数据流用红色虚线箭头普通调用用黑色实线箭头。”布局偏好“请使用自上而下的布局TB确保核心服务在中央数据存储在下层。”架构描述层Architecture Description清晰、结构化地描述你要画的架构。这是Prompt的主体。描述技巧采用“总-分”结构。先概述整体如“这是一个基于Spring Cloud的电商微服务系统”再分模块描述。关键要素务必说清组件是什么、关系如何连接、数据/流向传递什么。避免模糊词汇。输出与约束层Output Constraints严格规定输出格式和必须遵守的规则。示例“只输出Mermaid代码块不要任何解释。代码必须完整、可运行且符合Mermaid 10.0语法。确保所有节点都有唯一ID连线关系正确无误。”3. 实战演练从零生成一张微服务架构图让我们通过一个完整的例子看看如何应用上述框架。假设我们要为一个简单的“在线书店”绘制系统架构图。3.1 第一步构思与草稿在打开AI之前先用纸笔或白板软件画个草图明确核心组件用户通过浏览器/APP访问。请求经过API网关。网关将请求路由到用户服务、图书目录服务、订单服务。服务间调用使用服务发现。用户服务读写用户数据库。订单服务创建订单后发送消息到消息队列由库存服务异步处理。所有日志汇总到集中日志系统。配置统一由配置中心管理。3.2 第二步编写结构化Prompt基于草图我们编写一个详细的Prompt。注意这是给GPT-4或Claude 3等高级LLM的。你是一名资深云原生架构师精通使用Mermaid绘制技术架构图。你的任务是帮我生成一份清晰、专业、可直接嵌入技术设计文档的Mermaid流程图代码。 【图表规范】 1. 图表类型使用Mermaid的“graph TD”自上而下流程图。 2. 图形规范 - 客户端/外部系统使用平行四边形 [ ] - 网关/负载均衡器使用倒梯形 [/ ] - 微服务使用圆角矩形 ( ) - 数据库使用圆柱体 [( )] - 消息队列使用圆柱体加闪电 [(( ))] - 配置/注册中心使用六边形 {{ }} 3. 样式规范 - 所有微服务填充色为#e1f5fe浅蓝。 - 数据存储数据库、消息队列填充色为#e8f5e8浅绿。 - 基础设施组件网关、注册中心等填充色为#f3e5f5浅紫。 - 外部系统无填充色。 - 关键业务数据流使用红色虚线箭头 -.-。 - 服务间调用/同步通信使用黑色实线箭头 --。 - 异步消息使用蓝色实线箭头 - 配置/注册关系使用灰色虚线箭头 -.-。 【架构描述】 系统名称在线书店微服务系统 整体描述这是一个基于Spring Cloud的微服务架构用户通过Web/APP访问请求经过API网关路由到后端服务。 核心组件与流向 1. 流量入口 - 外部[用户客户端]发起请求。 - 请求首先到达[/API网关]。 2. 业务微服务层横向调用均注册到服务发现 - (用户服务)处理登录、注册、个人资料。 - (图书目录服务)管理图书信息、搜索、分类。 - (订单服务)处理订单创建、支付状态。 - 服务间存在调用例如订单服务需要调用图书服务验证库存。 3. 数据层 - (用户服务) 读写 [(用户数据库)]。 - (图书目录服务) 读写 [(图书数据库)]。 - (订单服务) 读写 [(订单数据库)]。 4. 异步处理 - (订单服务) 创建订单后向 [((订单消息队列))] 发送消息。 - (库存服务) 监听队列消费消息并更新 [(库存数据库)]。 5. 支撑设施 - 所有微服务都向 {{服务注册与发现中心}} 注册并从中获取服务地址。 - 所有微服务从 {{配置中心}} 拉取配置。 - 所有服务将日志发送到 {{集中日志系统}}。 - 所有指标上报到 {{监控告警系统}}。 【输出要求】 1. 只输出一个完整的、可被Mermaid解析的代码块。 2. 确保图形ID简洁且有意义如UserService, OrderQueue。 3. 布局尽量规整核心服务在中间层。 4. 不要添加任何注释以外的额外文字。3.3 第三步处理AI输出与优化将上述Prompt发送给AI。你可能会得到类似下面的代码graph TD %% 外部客户端 Client[用户客户端] %% 网关 APIGateway[/API网关/] %% 微服务 UserService(用户服务) BookService(图书目录服务) OrderService(订单服务) InventoryService(库存服务) %% 数据库 UserDB[(用户数据库)] BookDB[(图书数据库)] OrderDB[(订单数据库)] InventoryDB[(库存数据库)] %% 消息队列 OrderQueue[((订单消息队列))] %% 支撑设施 ServiceRegistry{{服务注册与发现中心}} ConfigCenter{{配置中心}} LogSystem{{集中日志系统}} MonitorSystem{{监控告警系统}} %% 样式定义可省略在渲染工具中统一设置主题更好 classDef microservice fill:#e1f5fe classDef storage fill:#e8f5e8 classDef infra fill:#f3e5f5 classDef external fill:#ffffff class UserService,BookService,OrderService,InventoryService microservice class UserDB,BookDB,OrderDB,InventoryDB,OrderQueue storage class ServiceRegistry,ConfigCenter,LogSystem,MonitorSystem infra class Client external %% 连接关系 Client -- APIGateway APIGateway -- UserService APIGateway -- BookService APIGateway -- OrderService OrderService -.- BookService UserService -- UserDB BookService -- BookDB OrderService -- OrderDB OrderService OrderQueue OrderQueue InventoryService InventoryService -- InventoryDB UserService -.- ServiceRegistry BookService -.- ServiceRegistry OrderService -.- ServiceRegistry InventoryService -.- ServiceRegistry UserService -.- ConfigCenter BookService -.- ConfigCenter OrderService -.- ConfigCenter InventoryService -.- ConfigCenter UserService -.- LogSystem BookService -.- LogSystem OrderService -.- LogSystem InventoryService -.- LogSystem UserService -.- MonitorSystem BookService -.- MonitorSystem OrderService -.- MonitorSystem InventoryService -.- MonitorSystem拿到代码后你需要做以下几步复制到渲染器将代码粘贴到 Mermaid Live Editor 或支持Mermaid的Markdown编辑器如Typora、VS Code with插件中立即预览。检查与修正布局是否美观Mermaid的自动布局有时会拥挤。你可以尝试调整graph TD为graph LR从左到右看看效果或者使用subgraph对相关服务进行分组能极大改善布局。关系是否正确仔细检查箭头指向确保与你的设计一致。样式是否生效检查classDef定义和class应用是否正确。迭代优化如果对布局不满意不要回去改Prompt让AI重画。更高效的做法是直接手动调整Mermaid代码。例如将部分服务用subgraph包裹。AI提供了高质量的初稿和正确的逻辑关系而最终的排版微调人类更擅长。实操心得把AI当作“高级绘图助手”而非“全自动绘图机器”。它的价值在于快速生成结构正确、元素齐全的草图。最后的排版优化、细节调整自己动手往往更快。Prompt工程的目标是让这张“草图”尽可能接近终稿减少手动调整的工作量。4. Prompt高级技巧与避坑指南经过大量实践我总结出一些能显著提升出图质量和效率的高级技巧以及必须绕开的“坑”。4.1 技巧一使用“参考图”进行风格对齐如果你希望AI生成的图表符合你公司或团队特定的图形规范比如数据库一定用黄色圆柱体网络设备用特定图标而用文字描述又太繁琐。可以这样做准备一张符合规范的、简单的参考图哪怕是你手画的草图截图保存。使用支持视觉识别的LLM如GPT-4V、Claude 3。在Prompt中附上图片并说明“请参考附图的图形样式和配色方案为以下架构生成Mermaid代码。特别注意数据库请使用附图所示的黄色圆柱体样式网络组件使用附图所示的交换机图标。”AI能很好地理解视觉参考并尝试在代码中通过classDef和style语句来模仿。4.2 技巧二分步骤、分视图生成复杂架构对于非常庞大的系统一张图会变得难以阅读。这时可以引导AI生成多张关联的图表。Prompt示例“首先请生成一张系统上下文图只包含本系统与外部用户、第三方系统的关系。然后生成一张容器级架构图展示主要的服务进程、数据存储和它们之间的通信。最后为最核心的‘订单处理’服务生成一张组件级架构图。请分三个独立的Mermaid代码块输出。”这样做的好处是AI会分层思考每张图聚焦一个抽象层次逻辑更清晰。4.3 技巧三利用“思维链”让AI自我校验对于逻辑复杂的交互图如时序图AI可能搞错调用顺序。可以在Prompt中要求AI“分步思考”。Prompt示例“在生成序列图代码前请先以列表形式梳理出‘用户下单’这个场景中从客户端点击按钮开始到订单创建成功返回所有参与组件客户端、网关、A服务、B服务、数据库、队列的交互步骤顺序。确认步骤列表正确后再根据此列表生成Mermaid序列图代码。”这相当于让AI先打草稿你检查草稿AI再根据草稿绘图准确性大幅提升。4.4 常见“坑”与解决方案AI“自由发挥”添加多余组件现象你描述了一个简单服务AI却自作主张加上了“防火墙”、“CDN”、“Kubernetes Master节点”等。对策在Prompt的输出约束层明确强调“严格只包含我描述过的组件不要添加任何我没有明确提及的组件或连接。” 如果它还是加了在后续对话中明确指出“请移除关于‘防火墙’和‘CDN’的所有图形和连接。”Mermaid语法错误或版本不兼容现象生成的代码在渲染器中报错比如使用了旧版语法或错误的关键字。对策在Prompt中明确指定语法版本“请使用Mermaid 10.0的语法。” 并提供一个最简单的正确示例锚定它的认知“例如流程图使用graph TD节点用A[描述]箭头用--。”布局混乱图形重叠现象代码逻辑正确但渲染出来一团乱麻。对策这是Mermaid渲染引擎的局限并非Prompt问题。最佳实践是接受AI生成的逻辑关系然后手动优化布局。使用subgraph将相关服务分组是改善布局最有效的手段。也可以尝试换用graph LR从左到右布局。无法生成特定图标现象你需要一个“Redis”图标或“Kafka”图标但Mermaid内置图形没有。对策Mermaid支持使用Font Awesome图标。在Prompt中告诉AI“对于‘Redis’组件请使用fa:fa-database图标表示为Redis[(fa:fa-database Redis)]。” AI通常能正确应用这种格式。5. 将AI绘图集成到日常工作流掌握了Prompt工程下一步就是让它真正为你工作而不是每次手动复制粘贴。场景一快速设计评审在技术讨论会上当大家在白板上画出一个新模块的设计时你可以实时将讨论要点整理成结构化描述通过预置好的Prompt模板保存在记事本或快捷指令中让AI生成图表代码并立即投屏。这能让讨论焦点迅速从“该怎么画”转移到“设计是否合理”上。场景二自动化文档更新如果你的架构文档是用Markdown维护在Git仓库中你可以编写一个简单的脚本如Python调用OpenAI API。当架构变更时更新一个描述架构的YAML文件然后运行脚本自动调用AI生成最新的Mermaid代码并替换文档中的旧代码块最后提交。这实现了架构图的“基础设施即代码”。场景三知识库问答增强在公司内部知识库中很多架构图是静态的难以查询。你可以将关键的架构图描述和生成的Mermaid代码作为知识喂给AI助手如基于GPT构建的内部客服。当新同事询问“订单服务怎么和库存服务交互”时AI不仅能文字回答还能动态生成或展示对应的架构子图体验极佳。我个人最深的体会是Prompt工程让画架构图这件事从一项耗费心神的“美术作业”回归到了它本该有的样子——一种设计思维的表达和推演工具。我不再纠结于框框的颜色和箭头是否对齐而是通过与AI的“对话”不断厘清组件边界、梳理依赖关系。很多时候在编写Prompt描述架构的过程中我自己就发现了设计上的模糊点或潜在问题。这或许才是AI带给架构师最大的礼物一个永不疲倦、随时可用的“思维反射板”。