尧图网页设计 
1. 项目概述当ChatGPT遇上架构图作为一名在软件开发和架构设计领域摸爬滚打了十多年的老兵我深知画架构图这件事有多“磨人”。从早期在白板上手绘到后来用Visio、Draw.io再到尝试PlantUML、Mermaid这类文本绘图工具工具在进化但核心痛点始终没变构思和绘制是两件高度耦合但又相互消耗精力的事。你脑子里可能已经有了清晰的模块划分和数据流向但要把它们精准、美观地落到图上往往需要花费大量时间在调整框线、对齐元素、选择图标上。更别提当架构需要调整时牵一发而动全身的修改有多痛苦。直到我开始深度使用ChatGPT一个想法逐渐成型能不能让这个强大的语言模型来分担“绘制”这部分的工作甚至辅助“构思”答案是肯定的。这个项目就是关于如何利用ChatGPT结合PlantUML这类文本化绘图语言实现架构图的自动化、半自动化生成。这不仅仅是“让AI画图”而是一套全新的、高效的架构设计与表达工作流。无论你是需要快速绘制系统架构图、业务流程图还是生成UML类图这套方法都能让你从繁琐的绘图操作中解放出来将精力真正聚焦在架构设计本身。2. 核心思路与工具选型为什么是“ChatGPT PlantUML”在开始动手之前我们需要明确核心思路和选择最合适的工具。我们的目标不是让ChatGPT直接输出一张PNG或SVG图片目前它做不到而是让它生成一种中间描述语言我们再通过专门的工具将这种语言渲染成图。这个思路有几个关键优势首先描述语言是文本ChatGPT极其擅长理解和生成文本其次文本易于修改、版本控制和复用最后成熟的文本绘图工具能保证输出图形的规范性和美观度。2.1 主流文本绘图工具对比市面上主流的文本绘图工具主要有PlantUML、Mermaid和Graphviz DOT。我们来快速对比一下看看为什么PlantUML是当前阶段与ChatGPT配合的最佳选择。特性PlantUMLMermaidGraphviz DOT语法友好度极高。语法接近自然语言组件定义直观如component “用户服务”关系描述清晰如用户服务 - 数据库 : 读写。ChatGPT容易学习和生成。中等。语法相对紧凑对于复杂布局有时需要手动调整。较低。是严格的图论描述语言需要定义节点、边及其属性抽象层次高不易直接描述业务概念。图形类型非常全面。支持时序图、用例图、类图、组件图、部署图、状态图、对象图等几乎所有UML图以及甘特图、思维导图等。较全面。支持流程图、时序图、类图、甘特图、饼图等但UML图支持不如PlantUML专业。专注于有向/无向图、流程图。对于标准的UML图支持较弱需要大量自定义。布局引擎内置多种布局策略自动化程度高通常能产生不错的默认布局。内置布局但在复杂场景下可控性一般。极其强大和灵活。但需要使用者对布局算法如dot, neato有较深理解学习成本高。与ChatGPT配合度最佳。其类自然语言的语法使得Prompt编写简单ChatGPT输出的结果可读性强且容易通过后续对话进行修正和优化。良好。可以配合但生成复杂图表时可能需要更多轮次调整。较差。让ChatGPT直接生成高质量的DOT代码挑战较大更适合生成基础结构后由人工精细调整。注意Mermaid近年来发展很快尤其在网页集成和实时预览方面体验很棒。但对于以“架构设计”为核心需要频繁输出标准UML图的场景PlantUML在专业性和语法友好度上依然有明显优势。2.2 工作流设计人与AI的协同确定了核心工具我们的工作流就清晰了。这不是一个完全自动化的“黑箱”而是一个增强智能的循环需求输入你用自然语言向ChatGPT描述你的架构想法。例如“帮我设计一个简单的电商微服务系统包含用户服务、商品服务、订单服务和支付服务它们通过一个API网关对外暴露并共用同一个认证中心和MySQL数据库。”AI生成初稿ChatGPT理解你的需求生成对应的PlantUML代码例如一张组件图。渲染与审查你将这段代码粘贴到PlantUML在线编辑器或本地工具中渲染出图片查看效果。反馈与迭代如果对布局、元素命名或关系不满意你可以直接告诉ChatGPT你的修改意见。例如“把数据库放在所有服务的下方用虚线连接并给订单服务到支付服务的箭头加上‘调用支付接口’的标签。” ChatGPT会修改代码你再次渲染。定稿与导出经过几轮快速迭代得到满意的架构图导出为PNG、SVG等格式。这个工作流的核心价值在于你将最耗时的“从想法到规范图形代码”的转换工作交给了AI而你则扮演架构师和审核者的角色专注于高层设计和细节修正。3. 实战从零生成你的第一张架构图理论说再多不如动手一试。我们以生成一个“在线视频转码平台”的简化系统架构图为例完整走一遍流程。我假设你使用的是ChatGPTGPT-4模型效果更佳并有一个PlantUML的渲染环境推荐使用官方的在线服务器https://www.plantuml.com/plantuml/uml/。3.1 第一步提出明确的绘图需求与AI合作清晰的指令Prompt是成功的一半。不要只说“画一个架构图”。一个好的Prompt应包含图形类型明确告诉AI你要什么图。是组件图部署图还是时序图核心元素列出系统的主要组成部分如服务、数据库、队列、网关等。元素关系描述这些组件之间如何交互数据流向如何。风格或约束如果有特殊要求比如颜色、分组、备注等一并提出。我的初始Prompt请为我生成一份PlantUML代码绘制一个在线视频转码平台的系统组件图。 核心组件包括 1. 客户端Web或App 2. 负载均衡器Nginx 3. API网关Spring Cloud Gateway 4. 视频上传服务 5. 转码任务管理服务 6. 分布式转码集群多个转码Worker 7. 消息队列RabbitMQ用于传递转码任务 8. 对象存储MinIO用于存储原始视频和转码后视频 9. 元数据库MySQL存储用户、视频元数据、任务状态 10. 缓存Redis存储热点数据和任务锁 关键关系 - 客户端请求经过负载均衡器到达API网关。 - 上传服务接收视频后存入对象存储并向任务管理服务创建任务。 - 任务管理服务将任务信息放入消息队列。 - 转码Worker从消息队列消费任务从对象存储读取原始视频转码后再写回对象存储并通知任务管理服务更新状态。 - 所有服务都可能需要访问数据库和缓存。 请使用合适的PlantUML组件图语法布局尽量清晰可以适当使用颜色区分不同层次的组件如接入层、业务层、基础设施层。最后请只输出PlantUML代码不要有其他解释。3.2 第二步处理AI的初次输出ChatGPT会返回一段PlantUML代码。第一次生成的结果通常可用但可能布局拥挤、颜色混乱或关系不精准。这是完全正常的也是我们工作流中“迭代”环节的价值所在。首次生成的代码可能类似这样已简化startuml !define LAYER_COLOR #DDDDDD skinparam component { BackgroundColor LAYER_COLOR BorderColor Black } package 接入层 { [客户端] as Client [负载均衡器 Nginx] as LB [API网关] as Gateway } package 业务服务层 { [视频上传服务] as UploadService [转码任务管理服务] as TaskService [转码Worker 1] as Worker1 [转码Worker 2] as Worker2 [转码Worker N] as WorkerN } package 基础设施层 { [消息队列 RabbitMQ] as MQ [对象存储 MinIO] as Storage [元数据库 MySQL] as DB [缓存 Redis] as Cache } Client -- LB : HTTP请求 LB -- Gateway : 路由 Gateway -- UploadService : 上传API Gateway -- TaskService : 查询API UploadService -- Storage : 存储原始视频 UploadService -- TaskService : 创建任务 TaskService -- MQ : 发布任务 Worker1 -- MQ : 消费任务 Worker2 -- MQ : 消费任务 WorkerN -- MQ : 消费任务 Worker1 -- Storage : 读取/写入视频 Worker2 -- Storage : 读取/写入视频 WorkerN -- Storage : 读取/写入视频 TaskService -- DB : 读写元数据 UploadService -- DB : 读写元数据 Worker1 -- TaskService : 更新状态 Worker2 -- TaskService : 更新状态 WorkerN -- TaskService : 更新状态 DB -- Cache : 缓存同步可选 enduml将这段代码复制到PlantUML在线编辑器你会得到一张图。你可能会立刻发现几个问题所有转码Worker与MQ和Storage的连接线交叉严重图显得很乱“基础设施层”的组件与其他层的连接线也纵横交错。3.3 第三步进行迭代优化现在发挥你作为架构师的判断力给ChatGPT具体的修改指令。我的优化Prompt上面生成的图逻辑正确但布局太乱连线交叉太多。请优化这段PlantUML代码要求 1. 使用 left to right direction 指令改为从左到右的布局这样更符合数据流从左客户端到右存储的直觉。 2. 将“转码集群”抽象为一个整体组件 [转码集群]内部可以用()表示包含多个Worker避免画出一大堆与MQ和Storage重复的连线。只需展示集群与MQ和Storage的关系。 3. 将“基础设施层”的组件MQ, Storage, DB, Cache放在最右侧作为共享资源。 4. 调整连线尽量减少交叉。可以尝试使用隐藏节点和间接连线如 A - B 和 B - C而不是 A - C来梳理流程。 5. 为不同层的包package设置不同的浅背景色以示区分。 请输出优化后的完整代码。3.4 第四步获得最终成果ChatGPT会根据你的反馈生成新版代码。经过一两轮这样的调整你就能得到一份布局清晰、表达准确的架构图代码。优化后的核心部分示意startuml left to right direction skinparam packageBackgroundColor #F5F5F5 skinparam packageBorderColor #333 package “客户端” #LightBlue { [Web/App] as Client } package “接入层” #LightGreen { [负载均衡器\nNginx] as LB [API网关] as Gateway } package “业务服务层” #LightYellow { [视频上传服务] as UploadService [转码任务管理服务] as TaskManager component “转码集群” as TranscodeCluster { () “Worker 1” () “Worker 2” () “Worker …” } } package “基础设施层” #LightGray { [消息队列\nRabbitMQ] as MQ [对象存储\nMinIO] as Storage database “元数据库\nMySQL” as DB [缓存\nRedis] as Cache } ‘ 连接关系 Client - LB : “HTTP/HTTPS” LB - Gateway Gateway - UploadService : “/api/upload” Gateway - TaskManager : “/api/query” UploadService -- Storage : “上传原始视频” UploadService - TaskManager : “创建转码任务” TaskManager - MQ : “发布任务消息” TranscodeCluster - MQ : “消费任务” TranscodeCluster -- Storage : “读取原始视频\n写入转码后视频” TranscodeCluster - TaskManager : “通知任务完成” TaskManager -- DB : “更新任务状态” UploadService -- DB : “记录元数据” DB -- Cache : “缓存热点数据” ‘ 使用隐藏节点整理连线避免交叉 note right of MQ 任务消息驱动 解耦服务与集群 end note enduml渲染出的图形结构会清晰很多从左到右的流向明确集群被抽象基础设施集中右侧连线经过规划后交叉显著减少。整个过程你只需要用自然语言沟通无需手动调整一行布局代码。4. 进阶技巧与场景应用掌握了基本流程后我们可以探索更多高阶用法让这个组合发挥更大威力。4.1 生成UML类图Class Diagram这是PlantUML的强项也是ChatGPT能很好完成的。你可以直接粘贴一段代码或描述类结构让ChatGPT生成类图。Prompt示例请根据以下Java类的简单描述生成PlantUML类图代码。 - 有一个抽象类 BaseEntity包含 Long id 属性和 Date createTime、Date updateTime 属性以及 save() 抽象方法。 - User 类继承 BaseEntity增加 String username、String email 属性并实现 save() 方法。 - Order 类继承 BaseEntity增加 BigDecimal amount、OrderStatus status 枚举属性。它与 User 是多对一关系一个用户有多个订单。 - OrderItem 类与 Order 是一对多关系一个订单有多个订单项包含 String productName、Integer quantity 属性。 - 有一个接口 Auditable包含 getAuditLog() 方法。User 类实现这个接口。 - 注意使用合适的可见性符号 for public, - for private, # for protected和关系箭头继承、实现、关联。ChatGPT生成的PlantUML代码会清晰地展示出继承树..|、实现关系..|、关联--和聚合/组合o--*--你只需渲染即可得到规范的类图。4.2 绘制时序图Sequence Diagram时序图非常适合描述单个业务流程或API调用链。用自然语言描述交互流程即可。Prompt示例生成一个PlantUML时序图描述用户通过客户端上传视频的简化流程 1. 用户从客户端点击上传。 2. 客户端调用【上传服务】的预签名接口获取一个可直传至对象存储的临时URL。 3. 客户端直接使用该URL将视频文件上传至【对象存储】。 4. 上传成功后【对象存储】回调【上传服务】的通知接口。 5. 【上传服务】收到回调后在【数据库】中创建一条视频记录状态为“待转码”。 6. 【上传服务】向【消息队列】发送一个“新视频待转码”事件。 7. 【转码服务】监听队列消费该事件。 请为每个参与者Client, UploadService, ObjectStorage, DB, MQ, TranscodeService和关键步骤添加说明。4.3 利用上下文和知识库生成更专业的图如果你的架构遵循某种特定范式如Clean Architecture、DDD分层或者使用了特定的云服务AWS、Azure图标你可以提前“教会”ChatGPT。方法在对话开始先发送一段包含专业约定的文本。在接下来的对话中当我们讨论系统架构时请遵循以下约定 1. 使用C4模型中的“容器图”视角来描述系统。主要元素是“容器”可独立部署/运行的应用、数据存储等。 2. 使用AWS的图标集。例如数据库用 :Amazon RDS:对象存储用 :Amazon S3:消息队列用 :Amazon SQS:。 3. 在PlantUML代码开头使用 !includeurl https://raw.githubusercontent.com/awslabs/aws-icons-for-plantuml/v14.0/dist 来引入AWS图标。 现在请为一个使用AWS服务的内容推荐平台生成容器图包括API Gateway, Lambda函数, S3, DynamoDB, SQS和Personalize服务。通过这种方式ChatGPT能生成更贴近行业规范、更具专业感的架构图。5. 避坑指南与实操心得在实际使用中我积累了一些宝贵的经验和需要避开的“坑”。5.1 常见问题与解决方案问题现象可能原因解决方案ChatGPT生成的代码无法渲染1. 语法错误括号不匹配、错误关键字。2. 包含了非PlantUML的说明文本。1. 将错误信息反馈给ChatGPT让它修正。2. 在Prompt中强调“只输出PlantUML代码”。3. 对于复杂图可要求“分步骤生成”先定义组件再定义关系。图形布局仍然不理想PlantUML的自动布局算法在复杂情况下有局限。1. 使用left to right direction或top to bottom direction强制全局方向。2. 使用隐藏节点进行连线路由[Hidden] -[hidden]-。3. 手动调整组件顺序声明顺序会影响布局位置。4. 使用together关键字将需要靠近的组件分组。元素样式不符合预期对PlantUML的皮肤参数skinparam不熟悉。1. 在Prompt中直接指定样式如“将所有数据库组件背景色设为淡蓝色”。2. 学习常用skinparam如skinparam componentStyle rectangle或skinparam monochrome true。3. 生成后手动添加最外层的skinparam调整全局样式。描述复杂关系时AI理解偏差自然语言描述存在二义性。分解问题。先让AI生成组件定义部分检查无误后再让它根据已定义的组件名来添加关系。Prompt示例“基于上面定义的组件 [A], [B], [C]请添加关系A调用B的同步接口B向C发送异步消息。”生成的图过于琐碎或抽象Prompt的粒度控制不当。在Prompt中明确层级。例如“绘制高层次的系统上下文图只包含本系统和外部用户、支付网关等不展示内部模块。” 或 “绘制详细的组件图需要展示服务内部的子模块。”5.2 我的核心实操心得Prompt工程是关键把你当成一个需求清晰的“产品经理”把ChatGPT当成一个能力强大但需要精确指引的“工程师”。指令越具体、越结构化产出质量越高。多使用“首先…然后…最后…”的句式来分解任务。迭代优于一次成型不要指望第一个Prompt就得到完美结果。把生成-审查-修正的循环看作正常流程。每次修正指令要具体“连线交叉”不如“请将组件A移到组件B的左边以减少连线交叉”。积累自己的“模板库”将多次调试后满意的、用于特定场景如微服务组件图、数据库ER图、API时序图的PlantUML代码片段保存下来。下次可以直接将模板喂给ChatGPT“请参考以下代码风格和结构为XX系统生成一个类似的图。”结合图形界面工具对于最终定稿的、需要精美排版的架构图如用于正式文档、PPT可以将PlantUML生成的图导出为SVG再导入Draw.io或Excalidraw中进行微调和美化。这样既利用了AI的快速构思能力又保留了人工对最终美学的把控。理解AI的局限性ChatGPT本质上是在“模仿”它训练数据中见过的PlantUML模式。对于极其复杂、非典型的架构布局它可能力不从心。此时你需要具备基本的PlantUML语法知识对AI生成的代码进行手动调整。这正体现了“增强智能”的意义——人负责创造和决策AI负责执行和优化。这套“ChatGPT PlantUML”的方法彻底改变了我绘制技术图表的方式。它最大的价值不是百分百的自动化而是将我从机械的绘图劳动中解放出来让我能更专注地思考架构本身。当你需要快速绘制草图进行沟通或者需要维护一套与代码同步更新的架构文档时试试这个方法你会感受到那种“动动嘴皮子就把图搞定”的效率飞跃。 ChatGPT与PlantUML结合：自动化生成架构图的高效工作流
1. 项目概述当ChatGPT遇上架构图作为一名在软件开发和架构设计领域摸爬滚打了十多年的老兵我深知画架构图这件事有多“磨人”。从早期在白板上手绘到后来用Visio、Draw.io再到尝试PlantUML、Mermaid这类文本绘图工具工具在进化但核心痛点始终没变构思和绘制是两件高度耦合但又相互消耗精力的事。你脑子里可能已经有了清晰的模块划分和数据流向但要把它们精准、美观地落到图上往往需要花费大量时间在调整框线、对齐元素、选择图标上。更别提当架构需要调整时牵一发而动全身的修改有多痛苦。直到我开始深度使用ChatGPT一个想法逐渐成型能不能让这个强大的语言模型来分担“绘制”这部分的工作甚至辅助“构思”答案是肯定的。这个项目就是关于如何利用ChatGPT结合PlantUML这类文本化绘图语言实现架构图的自动化、半自动化生成。这不仅仅是“让AI画图”而是一套全新的、高效的架构设计与表达工作流。无论你是需要快速绘制系统架构图、业务流程图还是生成UML类图这套方法都能让你从繁琐的绘图操作中解放出来将精力真正聚焦在架构设计本身。2. 核心思路与工具选型为什么是“ChatGPT PlantUML”在开始动手之前我们需要明确核心思路和选择最合适的工具。我们的目标不是让ChatGPT直接输出一张PNG或SVG图片目前它做不到而是让它生成一种中间描述语言我们再通过专门的工具将这种语言渲染成图。这个思路有几个关键优势首先描述语言是文本ChatGPT极其擅长理解和生成文本其次文本易于修改、版本控制和复用最后成熟的文本绘图工具能保证输出图形的规范性和美观度。2.1 主流文本绘图工具对比市面上主流的文本绘图工具主要有PlantUML、Mermaid和Graphviz DOT。我们来快速对比一下看看为什么PlantUML是当前阶段与ChatGPT配合的最佳选择。特性PlantUMLMermaidGraphviz DOT语法友好度极高。语法接近自然语言组件定义直观如component “用户服务”关系描述清晰如用户服务 - 数据库 : 读写。ChatGPT容易学习和生成。中等。语法相对紧凑对于复杂布局有时需要手动调整。较低。是严格的图论描述语言需要定义节点、边及其属性抽象层次高不易直接描述业务概念。图形类型非常全面。支持时序图、用例图、类图、组件图、部署图、状态图、对象图等几乎所有UML图以及甘特图、思维导图等。较全面。支持流程图、时序图、类图、甘特图、饼图等但UML图支持不如PlantUML专业。专注于有向/无向图、流程图。对于标准的UML图支持较弱需要大量自定义。布局引擎内置多种布局策略自动化程度高通常能产生不错的默认布局。内置布局但在复杂场景下可控性一般。极其强大和灵活。但需要使用者对布局算法如dot, neato有较深理解学习成本高。与ChatGPT配合度最佳。其类自然语言的语法使得Prompt编写简单ChatGPT输出的结果可读性强且容易通过后续对话进行修正和优化。良好。可以配合但生成复杂图表时可能需要更多轮次调整。较差。让ChatGPT直接生成高质量的DOT代码挑战较大更适合生成基础结构后由人工精细调整。注意Mermaid近年来发展很快尤其在网页集成和实时预览方面体验很棒。但对于以“架构设计”为核心需要频繁输出标准UML图的场景PlantUML在专业性和语法友好度上依然有明显优势。2.2 工作流设计人与AI的协同确定了核心工具我们的工作流就清晰了。这不是一个完全自动化的“黑箱”而是一个增强智能的循环需求输入你用自然语言向ChatGPT描述你的架构想法。例如“帮我设计一个简单的电商微服务系统包含用户服务、商品服务、订单服务和支付服务它们通过一个API网关对外暴露并共用同一个认证中心和MySQL数据库。”AI生成初稿ChatGPT理解你的需求生成对应的PlantUML代码例如一张组件图。渲染与审查你将这段代码粘贴到PlantUML在线编辑器或本地工具中渲染出图片查看效果。反馈与迭代如果对布局、元素命名或关系不满意你可以直接告诉ChatGPT你的修改意见。例如“把数据库放在所有服务的下方用虚线连接并给订单服务到支付服务的箭头加上‘调用支付接口’的标签。” ChatGPT会修改代码你再次渲染。定稿与导出经过几轮快速迭代得到满意的架构图导出为PNG、SVG等格式。这个工作流的核心价值在于你将最耗时的“从想法到规范图形代码”的转换工作交给了AI而你则扮演架构师和审核者的角色专注于高层设计和细节修正。3. 实战从零生成你的第一张架构图理论说再多不如动手一试。我们以生成一个“在线视频转码平台”的简化系统架构图为例完整走一遍流程。我假设你使用的是ChatGPTGPT-4模型效果更佳并有一个PlantUML的渲染环境推荐使用官方的在线服务器https://www.plantuml.com/plantuml/uml/。3.1 第一步提出明确的绘图需求与AI合作清晰的指令Prompt是成功的一半。不要只说“画一个架构图”。一个好的Prompt应包含图形类型明确告诉AI你要什么图。是组件图部署图还是时序图核心元素列出系统的主要组成部分如服务、数据库、队列、网关等。元素关系描述这些组件之间如何交互数据流向如何。风格或约束如果有特殊要求比如颜色、分组、备注等一并提出。我的初始Prompt请为我生成一份PlantUML代码绘制一个在线视频转码平台的系统组件图。 核心组件包括 1. 客户端Web或App 2. 负载均衡器Nginx 3. API网关Spring Cloud Gateway 4. 视频上传服务 5. 转码任务管理服务 6. 分布式转码集群多个转码Worker 7. 消息队列RabbitMQ用于传递转码任务 8. 对象存储MinIO用于存储原始视频和转码后视频 9. 元数据库MySQL存储用户、视频元数据、任务状态 10. 缓存Redis存储热点数据和任务锁 关键关系 - 客户端请求经过负载均衡器到达API网关。 - 上传服务接收视频后存入对象存储并向任务管理服务创建任务。 - 任务管理服务将任务信息放入消息队列。 - 转码Worker从消息队列消费任务从对象存储读取原始视频转码后再写回对象存储并通知任务管理服务更新状态。 - 所有服务都可能需要访问数据库和缓存。 请使用合适的PlantUML组件图语法布局尽量清晰可以适当使用颜色区分不同层次的组件如接入层、业务层、基础设施层。最后请只输出PlantUML代码不要有其他解释。3.2 第二步处理AI的初次输出ChatGPT会返回一段PlantUML代码。第一次生成的结果通常可用但可能布局拥挤、颜色混乱或关系不精准。这是完全正常的也是我们工作流中“迭代”环节的价值所在。首次生成的代码可能类似这样已简化startuml !define LAYER_COLOR #DDDDDD skinparam component { BackgroundColor LAYER_COLOR BorderColor Black } package 接入层 { [客户端] as Client [负载均衡器 Nginx] as LB [API网关] as Gateway } package 业务服务层 { [视频上传服务] as UploadService [转码任务管理服务] as TaskService [转码Worker 1] as Worker1 [转码Worker 2] as Worker2 [转码Worker N] as WorkerN } package 基础设施层 { [消息队列 RabbitMQ] as MQ [对象存储 MinIO] as Storage [元数据库 MySQL] as DB [缓存 Redis] as Cache } Client -- LB : HTTP请求 LB -- Gateway : 路由 Gateway -- UploadService : 上传API Gateway -- TaskService : 查询API UploadService -- Storage : 存储原始视频 UploadService -- TaskService : 创建任务 TaskService -- MQ : 发布任务 Worker1 -- MQ : 消费任务 Worker2 -- MQ : 消费任务 WorkerN -- MQ : 消费任务 Worker1 -- Storage : 读取/写入视频 Worker2 -- Storage : 读取/写入视频 WorkerN -- Storage : 读取/写入视频 TaskService -- DB : 读写元数据 UploadService -- DB : 读写元数据 Worker1 -- TaskService : 更新状态 Worker2 -- TaskService : 更新状态 WorkerN -- TaskService : 更新状态 DB -- Cache : 缓存同步可选 enduml将这段代码复制到PlantUML在线编辑器你会得到一张图。你可能会立刻发现几个问题所有转码Worker与MQ和Storage的连接线交叉严重图显得很乱“基础设施层”的组件与其他层的连接线也纵横交错。3.3 第三步进行迭代优化现在发挥你作为架构师的判断力给ChatGPT具体的修改指令。我的优化Prompt上面生成的图逻辑正确但布局太乱连线交叉太多。请优化这段PlantUML代码要求 1. 使用 left to right direction 指令改为从左到右的布局这样更符合数据流从左客户端到右存储的直觉。 2. 将“转码集群”抽象为一个整体组件 [转码集群]内部可以用()表示包含多个Worker避免画出一大堆与MQ和Storage重复的连线。只需展示集群与MQ和Storage的关系。 3. 将“基础设施层”的组件MQ, Storage, DB, Cache放在最右侧作为共享资源。 4. 调整连线尽量减少交叉。可以尝试使用隐藏节点和间接连线如 A - B 和 B - C而不是 A - C来梳理流程。 5. 为不同层的包package设置不同的浅背景色以示区分。 请输出优化后的完整代码。3.4 第四步获得最终成果ChatGPT会根据你的反馈生成新版代码。经过一两轮这样的调整你就能得到一份布局清晰、表达准确的架构图代码。优化后的核心部分示意startuml left to right direction skinparam packageBackgroundColor #F5F5F5 skinparam packageBorderColor #333 package “客户端” #LightBlue { [Web/App] as Client } package “接入层” #LightGreen { [负载均衡器\nNginx] as LB [API网关] as Gateway } package “业务服务层” #LightYellow { [视频上传服务] as UploadService [转码任务管理服务] as TaskManager component “转码集群” as TranscodeCluster { () “Worker 1” () “Worker 2” () “Worker …” } } package “基础设施层” #LightGray { [消息队列\nRabbitMQ] as MQ [对象存储\nMinIO] as Storage database “元数据库\nMySQL” as DB [缓存\nRedis] as Cache } ‘ 连接关系 Client - LB : “HTTP/HTTPS” LB - Gateway Gateway - UploadService : “/api/upload” Gateway - TaskManager : “/api/query” UploadService -- Storage : “上传原始视频” UploadService - TaskManager : “创建转码任务” TaskManager - MQ : “发布任务消息” TranscodeCluster - MQ : “消费任务” TranscodeCluster -- Storage : “读取原始视频\n写入转码后视频” TranscodeCluster - TaskManager : “通知任务完成” TaskManager -- DB : “更新任务状态” UploadService -- DB : “记录元数据” DB -- Cache : “缓存热点数据” ‘ 使用隐藏节点整理连线避免交叉 note right of MQ 任务消息驱动 解耦服务与集群 end note enduml渲染出的图形结构会清晰很多从左到右的流向明确集群被抽象基础设施集中右侧连线经过规划后交叉显著减少。整个过程你只需要用自然语言沟通无需手动调整一行布局代码。4. 进阶技巧与场景应用掌握了基本流程后我们可以探索更多高阶用法让这个组合发挥更大威力。4.1 生成UML类图Class Diagram这是PlantUML的强项也是ChatGPT能很好完成的。你可以直接粘贴一段代码或描述类结构让ChatGPT生成类图。Prompt示例请根据以下Java类的简单描述生成PlantUML类图代码。 - 有一个抽象类 BaseEntity包含 Long id 属性和 Date createTime、Date updateTime 属性以及 save() 抽象方法。 - User 类继承 BaseEntity增加 String username、String email 属性并实现 save() 方法。 - Order 类继承 BaseEntity增加 BigDecimal amount、OrderStatus status 枚举属性。它与 User 是多对一关系一个用户有多个订单。 - OrderItem 类与 Order 是一对多关系一个订单有多个订单项包含 String productName、Integer quantity 属性。 - 有一个接口 Auditable包含 getAuditLog() 方法。User 类实现这个接口。 - 注意使用合适的可见性符号 for public, - for private, # for protected和关系箭头继承、实现、关联。ChatGPT生成的PlantUML代码会清晰地展示出继承树..|、实现关系..|、关联--和聚合/组合o--*--你只需渲染即可得到规范的类图。4.2 绘制时序图Sequence Diagram时序图非常适合描述单个业务流程或API调用链。用自然语言描述交互流程即可。Prompt示例生成一个PlantUML时序图描述用户通过客户端上传视频的简化流程 1. 用户从客户端点击上传。 2. 客户端调用【上传服务】的预签名接口获取一个可直传至对象存储的临时URL。 3. 客户端直接使用该URL将视频文件上传至【对象存储】。 4. 上传成功后【对象存储】回调【上传服务】的通知接口。 5. 【上传服务】收到回调后在【数据库】中创建一条视频记录状态为“待转码”。 6. 【上传服务】向【消息队列】发送一个“新视频待转码”事件。 7. 【转码服务】监听队列消费该事件。 请为每个参与者Client, UploadService, ObjectStorage, DB, MQ, TranscodeService和关键步骤添加说明。4.3 利用上下文和知识库生成更专业的图如果你的架构遵循某种特定范式如Clean Architecture、DDD分层或者使用了特定的云服务AWS、Azure图标你可以提前“教会”ChatGPT。方法在对话开始先发送一段包含专业约定的文本。在接下来的对话中当我们讨论系统架构时请遵循以下约定 1. 使用C4模型中的“容器图”视角来描述系统。主要元素是“容器”可独立部署/运行的应用、数据存储等。 2. 使用AWS的图标集。例如数据库用 :Amazon RDS:对象存储用 :Amazon S3:消息队列用 :Amazon SQS:。 3. 在PlantUML代码开头使用 !includeurl https://raw.githubusercontent.com/awslabs/aws-icons-for-plantuml/v14.0/dist 来引入AWS图标。 现在请为一个使用AWS服务的内容推荐平台生成容器图包括API Gateway, Lambda函数, S3, DynamoDB, SQS和Personalize服务。通过这种方式ChatGPT能生成更贴近行业规范、更具专业感的架构图。5. 避坑指南与实操心得在实际使用中我积累了一些宝贵的经验和需要避开的“坑”。5.1 常见问题与解决方案问题现象可能原因解决方案ChatGPT生成的代码无法渲染1. 语法错误括号不匹配、错误关键字。2. 包含了非PlantUML的说明文本。1. 将错误信息反馈给ChatGPT让它修正。2. 在Prompt中强调“只输出PlantUML代码”。3. 对于复杂图可要求“分步骤生成”先定义组件再定义关系。图形布局仍然不理想PlantUML的自动布局算法在复杂情况下有局限。1. 使用left to right direction或top to bottom direction强制全局方向。2. 使用隐藏节点进行连线路由[Hidden] -[hidden]-。3. 手动调整组件顺序声明顺序会影响布局位置。4. 使用together关键字将需要靠近的组件分组。元素样式不符合预期对PlantUML的皮肤参数skinparam不熟悉。1. 在Prompt中直接指定样式如“将所有数据库组件背景色设为淡蓝色”。2. 学习常用skinparam如skinparam componentStyle rectangle或skinparam monochrome true。3. 生成后手动添加最外层的skinparam调整全局样式。描述复杂关系时AI理解偏差自然语言描述存在二义性。分解问题。先让AI生成组件定义部分检查无误后再让它根据已定义的组件名来添加关系。Prompt示例“基于上面定义的组件 [A], [B], [C]请添加关系A调用B的同步接口B向C发送异步消息。”生成的图过于琐碎或抽象Prompt的粒度控制不当。在Prompt中明确层级。例如“绘制高层次的系统上下文图只包含本系统和外部用户、支付网关等不展示内部模块。” 或 “绘制详细的组件图需要展示服务内部的子模块。”5.2 我的核心实操心得Prompt工程是关键把你当成一个需求清晰的“产品经理”把ChatGPT当成一个能力强大但需要精确指引的“工程师”。指令越具体、越结构化产出质量越高。多使用“首先…然后…最后…”的句式来分解任务。迭代优于一次成型不要指望第一个Prompt就得到完美结果。把生成-审查-修正的循环看作正常流程。每次修正指令要具体“连线交叉”不如“请将组件A移到组件B的左边以减少连线交叉”。积累自己的“模板库”将多次调试后满意的、用于特定场景如微服务组件图、数据库ER图、API时序图的PlantUML代码片段保存下来。下次可以直接将模板喂给ChatGPT“请参考以下代码风格和结构为XX系统生成一个类似的图。”结合图形界面工具对于最终定稿的、需要精美排版的架构图如用于正式文档、PPT可以将PlantUML生成的图导出为SVG再导入Draw.io或Excalidraw中进行微调和美化。这样既利用了AI的快速构思能力又保留了人工对最终美学的把控。理解AI的局限性ChatGPT本质上是在“模仿”它训练数据中见过的PlantUML模式。对于极其复杂、非典型的架构布局它可能力不从心。此时你需要具备基本的PlantUML语法知识对AI生成的代码进行手动调整。这正体现了“增强智能”的意义——人负责创造和决策AI负责执行和优化。这套“ChatGPT PlantUML”的方法彻底改变了我绘制技术图表的方式。它最大的价值不是百分百的自动化而是将我从机械的绘图劳动中解放出来让我能更专注地思考架构本身。当你需要快速绘制草图进行沟通或者需要维护一套与代码同步更新的架构文档时试试这个方法你会感受到那种“动动嘴皮子就把图搞定”的效率飞跃。