30c - 系统设计文档AI生成
本文是《AI Agent 实战手册》第 30 章第 3 节。 上一节:30b-AI辅助架构决策 | 下一节:30d-架构审查清单与反模式
概述
系统设计文档的核心是”图”——C4 架构图、序列图、流程图、ER 图、状态图、部署图。传统方式下,在 Visio 或 Draw.io 中手动绘制一张准确的架构图需要数小时,改一个组件名就要手动调整所有关联箭头。2025-2026 年,“图即代码”(Diagram-as-Code)工具与 AI Agent 的深度结合彻底改变了这个局面:用自然语言描述系统架构,AI 生成 Mermaid 或 PlantUML 代码,渲染出专业级架构图,修改只需改几行文本,版本管理与代码仓库同步。本节从 Vibe Coding 的视角出发,系统覆盖 Mermaid 全图表类型的 AI 生成、PlantUML UML 全类型与 C4 扩展、从需求到架构图的自动化管线、架构图版本控制与持续同步、多种图表类型的 Prompt 模板库、图表渲染与发布工具链,以及 AI 生成图表的常见语法错误修复指南。
1. AI 辅助系统设计文档生成工具全景
1.1 图即代码(Diagram-as-Code)核心工具
| 工具 | 用途 | 价格 | 适用场景 |
|---|---|---|---|
| Mermaid | Markdown 内嵌图表(流程图、序列图、C4、ER、状态图、甘特图、思维导图等) | 免费(开源) | Markdown 文档内嵌图表、GitHub/GitLab/Notion 原生渲染 |
| Mermaid Chart | Mermaid 官方在线编辑器 + AI 辅助生成 | 免费 / $8/月(Pro)/ $16/月(Business) | 团队协作、AI 辅助图表生成、实时预览与导出 |
| PlantUML | 标准 UML 全类型图(类图、序列图、组件图、部署图、活动图、用例图、对象图) | 免费(开源) | 标准 UML 建模、企业级架构文档、C4 扩展 |
| D2 | 声明式图表语言,专为软件工程师设计 | 免费(开源) | 现代化架构图、自动布局、主题支持、Markdown 集成 |
| Structurizr | C4 模型专用工具(DSL 定义架构) | 免费(Lite)/ $5/月(Cloud) | 结构化 C4 架构文档、代码即架构、多视图同步 |
| Graphviz | 经典图形可视化工具(DOT 语言) | 免费(开源) | 依赖关系图、网络拓扑图、自动布局 |
1.2 AI 辅助图表生成平台
| 工具 | 用途 | 价格 | 适用场景 |
|---|---|---|---|
| Eraser.io | AI 生成架构图 + 文档协作 | 免费 / $10/月(Pro)/ $15/月(Business) | AI 驱动的架构图生成、团队协作、白板模式 |
| Visual Paradigm AI C4 Studio | AI 驱动的 C4 模型全六视图生成 | $6/月起(Professional) | 企业级 C4 建模、AI 自动生成 Context/Container/Component/Deployment 图 |
| ChatUML | GPT-4 驱动的 UML 图生成 | 免费 / $5/月(Pro) | 快速 UML 图生成、PlantUML 输出、语法修复 |
| DocuWriter.ai | 从代码库自动生成 UML 图和文档 | $9/月起 | 代码库逆向工程、自动文档生成、持续同步 |
| Excalidraw + AI | 手绘风格图表 + AI 生成 | 免费(开源)/ $7/月(Excalidraw+) | 白板风格架构图、头脑风暴、非正式沟通 |
| Diagramming AI | 多格式 AI 图表生成器 | 免费 / $9/月(Pro) | 多格式图表生成、AI 对话式编辑 |
1.3 MCP 集成图表工具
| 工具 | 用途 | 价格 | 适用场景 |
|---|---|---|---|
| mcp-mermaid | AI 编码工具中动态生成 Mermaid 图并渲染为 PNG/SVG | 免费(开源) | Claude Code / Kiro 中直接生成和预览图表 |
| mcp-kroki | 通过 Kroki API 渲染 Mermaid、PlantUML、Graphviz 等多种格式 | 免费(开源) | 统一 API 渲染多种图表格式、支持 SVG/PNG/PDF 输出 |
| mermaid-mcp-server | 通过 Puppeteer 渲染 Mermaid 图表,支持多主题 | 免费(开源) | 高质量本地渲染、支持 default/forest/dark/neutral 主题 |
| Eraser MCP Server | AI 编码工具中生成 Eraser 架构图 | 免费(开源) | 在 IDE 中直接生成专业架构图 |
1.4 图表渲染与发布工具链
| 工具 | 用途 | 价格 | 适用场景 |
|---|---|---|---|
| @mermaid-js/mermaid-cli (mmdc) | Mermaid CLI 渲染工具,支持 SVG/PNG/PDF 输出 | 免费(开源) | CI/CD 管线中自动渲染、批量转换 |
| Kroki.io | 统一图表渲染 API,支持 30+ 图表格式 | 免费(开源,可自托管)/ 免费公共 API | 多格式统一渲染、REST API 集成、自托管部署 |
| PlantUML Server | PlantUML 在线/自托管渲染服务 | 免费(开源) | PlantUML 图表渲染、Docker 部署、API 集成 |
| GitHub/GitLab 原生渲染 | Markdown 中直接渲染 Mermaid 图表 | 免费 | 代码仓库文档中直接展示架构图 |
| Docusaurus + Mermaid 插件 | 文档站点中渲染 Mermaid 图表 | 免费(开源) | 技术文档站点、API 文档、架构知识库 |
2. Mermaid 图表 AI 生成深度指南
Mermaid 是目前与 AI 配合最好的图表语言——GitHub、GitLab、Notion、Obsidian、Confluence 原生支持渲染,LLM 对 Mermaid 语法的掌握度远高于其他图表语言。以下覆盖 Mermaid 支持的所有主要图表类型及其 AI 生成方法。
2.1 C4 模型图(C4 Context / Container / Component)
C4 模型是 Simon Brown 提出的分层架构可视化方法,Mermaid 从 v10.9 开始原生支持 C4 图表语法。
C4 Context 图示例(系统上下文):
C4 Container 图示例(容器视图):
AI 生成 C4 图的 Prompt 模板:
请为以下系统生成 Mermaid C4 [Context/Container/Component] 图:
系统名称:[系统名称]
系统描述:[一句话描述系统功能]
主要用户角色:[列出用户角色及其主要操作]
外部系统依赖:[列出外部系统及其交互方式]
[仅 Container 图] 主要容器/服务:[列出服务名称、技术栈、职责]
[仅 Component 图] 目标容器:[指定要展开的容器名称]
要求:
- 使用 Mermaid C4Context / C4Container / C4Component 语法
- 节点标签使用中文,ID 使用英文
- 关系标注通信协议(HTTPS、gRPC、TCP 等)
- 包含 title 标题
- 外部系统使用 System_Ext,数据库使用 ContainerDb,消息队列使用 ContainerQueue2.2 序列图(Sequence Diagram)
序列图是描述组件间交互时序的最佳工具,AI 生成序列图的准确率在所有图表类型中最高。
AI 生成序列图的 Prompt 模板:
请用 Mermaid sequenceDiagram 语法生成以下交互流程的序列图:
场景名称:[场景名称,如"用户下单支付流程"]
参与者:[列出所有参与者及其角色]
交互流程:
1. [步骤 1 描述]
2. [步骤 2 描述]
...
要求:
- 使用 autonumber 自动编号
- 用户使用 actor 类型
- 同步调用使用 ->>,异步调用使用 -)
- 返回使用 -->>(虚线)
- 包含错误处理分支(使用 alt/else)
- 关键操作添加 Note 注释
- 参与者标签使用中文2.3 流程图(Flowchart)
AI 生成流程图的 Prompt 模板:
请用 Mermaid flowchart 语法生成以下流程的流程图:
流程名称:[流程名称]
流程描述:[简要描述]
主要步骤:
1. [步骤描述]
2. [决策点及分支]
...
要求:
- 使用 TD(从上到下)或 LR(从左到右)布局
- 决策节点使用菱形 {}
- 关键路径用粗线 ==>
- 错误路径用虚线 -.->
- 成功节点用绿色 style,错误节点用红色 style
- 节点 ID 使用英文字母,标签使用中文2.4 ER 图(Entity Relationship Diagram)
AI 生成 ER 图的 Prompt 模板:
请用 Mermaid erDiagram 语法生成以下数据模型的 ER 图:
系统名称:[系统名称]
核心实体:[列出主要实体及其关键属性]
实体关系:[描述实体间的关系,如一对多、多对多]
要求:
- 每个实体包含字段名、类型、约束(PK/FK/UK)和中文注释
- 关系使用正确的基数符号(||--o{ 一对多,}o--o{ 多对多)
- 关系标签使用中文动词描述
- 包含常见字段(id、created_at、updated_at)
- 枚举类型标注可选值2.5 状态图(State Diagram)
AI 生成状态图的 Prompt 模板:
请用 Mermaid stateDiagram-v2 语法生成以下实体的状态机图:
实体名称:[实体名称,如"订单"]
状态列表:[列出所有可能的状态]
状态转换:
- [源状态] → [目标状态]:[触发条件]
...
要求:
- 使用 stateDiagram-v2 语法
- 包含初始状态 [*] 和终止状态 [*]
- 关键状态添加 note 注释说明业务规则
- 自动触发的转换标注条件(如超时、定时任务)
- 可重试的操作使用自循环箭头2.6 部署图(使用 Flowchart 模拟)
Mermaid 没有原生部署图语法,但可以用 flowchart + subgraph 模拟:
2.7 思维导图(Mindmap)
Mermaid 支持思维导图语法,适合用于架构决策的头脑风暴和知识组织:
3. PlantUML 图表 AI 生成深度指南
PlantUML 在企业级 UML 建模领域仍然是标准工具,尤其在类图、组件图和 C4 扩展方面比 Mermaid 更强大。
3.1 PlantUML 类图
@startuml
skinparam classAttributeIconSize 0
skinparam classFontSize 14
package "领域模型" {
abstract class BaseEntity {
- id: UUID
- createdAt: DateTime
- updatedAt: DateTime
+ getId(): UUID
}
class User extends BaseEntity {
- email: String
- name: String
- passwordHash: String
- role: UserRole
+ authenticate(password: String): Boolean
+ changePassword(oldPwd: String, newPwd: String): void
+ hasPermission(permission: String): Boolean
}
enum UserRole {
ADMIN
CUSTOMER
MERCHANT
}
class Order extends BaseEntity {
- userId: UUID
- status: OrderStatus
- totalAmount: Decimal
- shippingAddress: Address
+ addItem(product: Product, quantity: int): void
+ removeItem(itemId: UUID): void
+ calculateTotal(): Decimal
+ submit(): void
+ cancel(): void
}
enum OrderStatus {
DRAFT
PENDING_PAYMENT
PAID
PROCESSING
SHIPPED
DELIVERED
COMPLETED
CANCELLED
}
class OrderItem {
- orderId: UUID
- productId: UUID
- quantity: int
- unitPrice: Decimal
+ getSubtotal(): Decimal
}
class Product extends BaseEntity {
- name: String
- description: String
- price: Decimal
- stock: int
- categoryId: UUID
+ isAvailable(): Boolean
+ reduceStock(quantity: int): void
+ restoreStock(quantity: int): void
}
User "1" --> "*" Order : 下单
Order "1" *-- "*" OrderItem : 包含
Product "1" --> "*" OrderItem : 被购买
User --> UserRole
Order --> OrderStatus
}
@endumlAI 生成 PlantUML 类图的 Prompt 模板:
请用 PlantUML 语法生成以下领域模型的类图:
领域名称:[领域名称]
核心实体:
- [实体名称]:[属性列表]、[方法列表]
...
实体关系:
- [实体A] 与 [实体B] 的关系:[关系类型和描述]
...
要求:
- 使用 package 分组相关类
- 抽象类使用 abstract class
- 枚举使用 enum
- 标注访问修饰符(+ public, - private, # protected)
- 关系使用正确的 UML 符号(--> 关联, *-- 组合, o-- 聚合, ..|> 实现, --|> 继承)
- 关系标注基数("1" --> "*")和中文描述
- 使用 skinparam 美化样式3.2 PlantUML 组件图
@startuml
skinparam componentStyle uml2
skinparam backgroundColor #FEFEFE
package "前端层" {
[Web 应用\n(React + Next.js)] as Web
[管理后台\n(React + Ant Design)] as Admin
[移动端\n(React Native)] as Mobile
}
package "API 网关层" {
[API Gateway\n(Kong / AWS API Gateway)] as Gateway
[认证中间件\n(JWT + OAuth 2.0)] as AuthMiddleware
[限流中间件\n(Rate Limiter)] as RateLimiter
}
package "业务服务层" {
[用户服务\n(Go)] as UserSvc
[订单服务\n(Go)] as OrderSvc
[商品服务\n(Go)] as ProductSvc
[支付服务\n(Go)] as PaymentSvc
[通知服务\n(Node.js)] as NotifySvc
}
package "基础设施层" {
database "PostgreSQL\n(主从复制)" as DB
database "Redis\n(集群模式)" as Cache
queue "RabbitMQ\n(镜像队列)" as MQ
storage "MinIO / S3\n(对象存储)" as Storage
}
package "外部服务" {
cloud "支付宝/微信支付" as PayGateway
cloud "短信服务" as SMS
cloud "邮件服务" as Email
}
Web --> Gateway
Admin --> Gateway
Mobile --> Gateway
Gateway --> AuthMiddleware
Gateway --> RateLimiter
AuthMiddleware --> UserSvc
Gateway --> OrderSvc
Gateway --> ProductSvc
Gateway --> PaymentSvc
OrderSvc --> DB
OrderSvc --> Cache
OrderSvc --> MQ
ProductSvc --> DB
ProductSvc --> Cache
UserSvc --> DB
PaymentSvc --> PayGateway
MQ --> NotifySvc
NotifySvc --> SMS
NotifySvc --> Email
ProductSvc --> Storage
@enduml3.3 PlantUML C4 扩展(C4-PlantUML)
PlantUML 通过 C4-PlantUML 库提供了比 Mermaid 更丰富的 C4 模型支持,包括完整的六视图和自定义样式。
C4 Container 图(PlantUML 版):
@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
LAYOUT_WITH_LEGEND()
title 电商平台 - 容器图
Person(customer, "客户", "浏览商品、下单、支付")
Person(admin, "管理员", "管理商品、订单、用户")
System_Boundary(ecommerce, "电商平台") {
Container(web, "Web 应用", "React + Next.js", "提供用户界面和服务端渲染")
Container(api, "API 网关", "Kong", "路由、认证、限流")
Container(order_svc, "订单服务", "Go + gRPC", "处理订单生命周期")
Container(product_svc, "商品服务", "Go + gRPC", "管理商品目录和库存")
Container(user_svc, "用户服务", "Go + gRPC", "用户认证和权限管理")
ContainerDb(db, "PostgreSQL", "关系型数据库", "存储业务数据,主从复制")
ContainerDb(cache, "Redis", "缓存集群", "会话、热点数据、分布式锁")
ContainerQueue(mq, "RabbitMQ", "消息队列", "异步任务、事件驱动")
}
System_Ext(payment, "支付网关", "支付宝/微信支付")
System_Ext(logistics, "物流系统", "第三方物流 API")
Rel(customer, web, "访问", "HTTPS")
Rel(admin, web, "管理操作", "HTTPS")
Rel(web, api, "API 调用", "HTTPS/JSON")
Rel(api, order_svc, "路由", "gRPC")
Rel(api, product_svc, "路由", "gRPC")
Rel(api, user_svc, "路由", "gRPC")
Rel(order_svc, db, "读写", "TCP/5432")
Rel(order_svc, cache, "缓存", "TCP/6379")
Rel(order_svc, mq, "发布事件", "AMQP")
Rel(order_svc, payment, "支付请求", "HTTPS")
Rel(order_svc, logistics, "物流推送", "HTTPS")
@endumlC4 Dynamic 图(动态视图):
@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Dynamic.puml
LAYOUT_WITH_LEGEND()
title 用户下单支付 - 动态视图
ContainerDb(db, "PostgreSQL", "")
Container(web, "Web 应用", "React")
Container(api, "API 网关", "Kong")
Container(order, "订单服务", "Go")
Container(product, "商品服务", "Go")
Container(pay, "支付服务", "Go")
System_Ext(payment, "支付网关", "")
Rel(web, api, "1. 提交订单", "POST /orders")
Rel(api, product, "2. 检查库存", "gRPC")
Rel(product, db, "3. 查询库存", "SQL")
Rel(api, order, "4. 创建订单", "gRPC")
Rel(order, db, "5. 写入订单", "SQL")
Rel(order, product, "6. 锁定库存", "gRPC")
Rel(web, api, "7. 发起支付", "POST /payments")
Rel(api, pay, "8. 处理支付", "gRPC")
Rel(pay, payment, "9. 调用支付网关", "HTTPS")
Rel(pay, order, "10. 更新订单状态", "gRPC")
Rel(order, db, "11. 更新状态为已支付", "SQL")
@endumlC4 Deployment 图(部署视图):
@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Deployment.puml
LAYOUT_WITH_LEGEND()
title 电商平台 - 部署图
Deployment_Node(cdn, "CloudFront CDN", "AWS") {
Container(static, "静态资源", "HTML/CSS/JS")
}
Deployment_Node(aws, "AWS 云环境", "us-east-1") {
Deployment_Node(alb, "Application Load Balancer", "AWS ALB") {
Container(lb, "负载均衡器", "L7 路由")
}
Deployment_Node(ecs, "ECS Fargate", "容器集群") {
Deployment_Node(api_task, "API 任务", "3 实例") {
Container(api, "API 网关", "Kong")
}
Deployment_Node(svc_task, "业务服务任务", "各 2 实例") {
Container(order, "订单服务", "Go")
Container(product, "商品服务", "Go")
}
}
Deployment_Node(data, "数据层", "") {
Deployment_Node(rds, "RDS", "Multi-AZ") {
ContainerDb(db, "PostgreSQL 16", "主从复制")
}
Deployment_Node(elasticache, "ElastiCache", "集群模式") {
ContainerDb(redis, "Redis 7", "3 主 3 从")
}
}
}
Rel(cdn, alb, "HTTPS")
Rel(alb, api, "HTTP/8080")
Rel(api, order, "gRPC/50051")
Rel(api, product, "gRPC/50052")
Rel(order, db, "TCP/5432")
Rel(order, redis, "TCP/6379")
@enduml3.4 PlantUML 活动图(Activity Diagram)
@startuml
skinparam activityFontSize 14
title 订单处理流程
start
:接收订单请求;
if (用户已认证?) then (是)
:验证订单数据;
if (数据有效?) then (是)
fork
:检查库存;
fork again
:验证收货地址;
fork again
:计算运费;
end fork
if (库存充足?) then (是)
:锁定库存;
:创建订单记录;
:生成支付链接;
:等待用户支付;
if (支付成功?) then (是)
:确认订单;
:扣减库存;
:发送确认通知;
#palegreen:订单创建成功;
else (否/超时)
:释放库存锁定;
:取消订单;
#salmon:订单已取消;
endif
else (否)
:返回库存不足错误;
#salmon:订单创建失败;
endif
else (否)
:返回数据验证错误;
#salmon:请求无效;
endif
else (否)
:返回 401 未认证;
#salmon:认证失败;
endif
stop
@enduml3.5 PlantUML 主题定制
PlantUML 支持丰富的主题定制,可以统一团队的架构图风格:
@startuml
' ===== 自定义主题 =====
!define DARKBLUE #1a237e
!define LIGHTBLUE #e3f2fd
!define GREEN #2e7d32
!define ORANGE #ef6c00
!define RED #c62828
skinparam backgroundColor #FAFAFA
skinparam defaultFontName "Source Han Sans SC"
skinparam defaultFontSize 13
skinparam component {
BackgroundColor LIGHTBLUE
BorderColor DARKBLUE
FontColor DARKBLUE
ArrowColor DARKBLUE
}
skinparam database {
BackgroundColor #FFF3E0
BorderColor ORANGE
FontColor ORANGE
}
skinparam queue {
BackgroundColor #E8F5E9
BorderColor GREEN
FontColor GREEN
}
skinparam cloud {
BackgroundColor #FFEBEE
BorderColor RED
FontColor RED
}
' ===== 使用自定义主题的图表 =====
[API 网关] as API
[订单服务] as Order
database "PostgreSQL" as DB
queue "RabbitMQ" as MQ
cloud "支付网关" as Pay
API --> Order
Order --> DB
Order --> MQ
Order --> Pay
@enduml4. 从需求到架构图的自动化管线
4.1 端到端工作流概览
从自然语言需求到生产级架构文档的完整自动化管线:
4.2 步骤 1:从需求提取架构关注点
Prompt 模板——需求到架构关注点提取:
请分析以下需求文档,提取系统架构设计所需的关键信息:
---
[粘贴需求文档 / PRD / 用户故事]
---
请按以下结构输出:
## 1. 功能需求摘要
- 核心功能列表(按优先级排序)
- 用户角色和权限模型
## 2. 非功能需求
- 性能要求(QPS、响应时间、并发用户数)
- 可用性要求(SLA、RTO、RPO)
- 安全要求(认证方式、数据加密、合规需求)
- 可扩展性要求(预期增长、峰值倍数)
## 3. 技术约束
- 团队技术栈偏好
- 预算限制
- 部署环境要求
- 第三方集成需求
## 4. 架构关注点
- 需要重点设计的子系统
- 关键的架构决策点
- 潜在的技术风险
## 5. 建议的架构视图
- 推荐生成哪些类型的架构图
- 每种图的关注重点4.3 步骤 2:AI 生成架构方案和图表
Prompt 模板——一键生成完整架构文档:
基于以下架构关注点,请生成完整的系统设计文档:
系统名称:[系统名称]
系统描述:[一句话描述]
架构关注点:
[粘贴步骤 1 的输出]
请生成以下内容:
### 1. 系统上下文图(Mermaid C4Context)
- 展示系统与外部用户、外部系统的关系
### 2. 容器图(Mermaid C4Container)
- 展示系统内部的主要容器/服务及其技术栈
### 3. 核心业务流程序列图(Mermaid sequenceDiagram)
- 为最关键的 [N] 个业务流程各生成一张序列图
### 4. 数据模型 ER 图(Mermaid erDiagram)
- 展示核心实体及其关系
### 5. 关键状态机图(Mermaid stateDiagram-v2)
- 为核心实体(如订单、用户)生成状态机图
### 6. 部署架构图(Mermaid flowchart + subgraph)
- 展示生产环境的部署拓扑
要求:
- 所有图表使用 Mermaid 语法
- 每张图前添加简要说明(2-3 句话解释图表内容和设计决策)
- 图表标签使用中文
- 关系标注通信协议4.4 步骤 3:语法验证和渲染
在 CI/CD 管线中自动验证 AI 生成的图表语法:
Mermaid 语法验证脚本:
#!/bin/bash
# validate-mermaid.sh - 验证 Markdown 文件中的 Mermaid 图表语法
set -e
# 安装 mermaid-cli(如果未安装)
if ! command -v mmdc &> /dev/null; then
npm install -g @mermaid-js/mermaid-cli
fi
# 提取 Markdown 中的 Mermaid 代码块
extract_mermaid() {
local file=$1
local count=0
local in_block=false
local temp_dir=$(mktemp -d)
while IFS= read -r line; do
if [[ "$line" =~ ^\`\`\`mermaid ]]; then
in_block=true
count=$((count + 1))
continue
fi
if [[ "$line" =~ ^\`\`\` ]] && $in_block; then
in_block=false
continue
fi
if $in_block; then
echo "$line" >> "$temp_dir/diagram_$count.mmd"
fi
done < "$file"
echo "$temp_dir"
}
# 验证每个 Mermaid 文件
validate_diagrams() {
local dir=$1
local errors=0
for mmd_file in "$dir"/*.mmd; do
[ -f "$mmd_file" ] || continue
echo "验证: $(basename $mmd_file)"
if mmdc -i "$mmd_file" -o "/dev/null" 2>/dev/null; then
echo " ✅ 语法正确"
else
echo " ❌ 语法错误"
errors=$((errors + 1))
fi
done
return $errors
}
# 主流程
for md_file in "$@"; do
echo "=== 检查文件: $md_file ==="
temp_dir=$(extract_mermaid "$md_file")
validate_diagrams "$temp_dir" || echo "⚠️ 发现语法错误"
rm -rf "$temp_dir"
doneGitHub Actions 集成示例:
# .github/workflows/validate-diagrams.yml
name: Validate Architecture Diagrams
on:
pull_request:
paths:
- 'docs/architecture/**/*.md'
- 'docs/design/**/*.md'
jobs:
validate-mermaid:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Mermaid CLI
run: npm install -g @mermaid-js/mermaid-cli
- name: Validate Mermaid Diagrams
run: |
find docs/ -name "*.md" -exec grep -l '```mermaid' {} \; | while read file; do
echo "Validating: $file"
# 提取并验证每个 Mermaid 代码块
python3 scripts/extract-mermaid.py "$file" | while read mmd_file; do
mmdc -i "$mmd_file" -o /tmp/output.svg || exit 1
done
done
- name: Render Diagrams to SVG
if: success()
run: |
mkdir -p docs/generated-diagrams
find docs/ -name "*.mmd" -exec sh -c '
mmdc -i "$1" -o "docs/generated-diagrams/$(basename $1 .mmd).svg" \
--theme neutral \
--backgroundColor transparent
' _ {} \;
validate-plantuml:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup PlantUML
run: |
sudo apt-get update
sudo apt-get install -y plantuml
- name: Validate PlantUML Diagrams
run: |
find docs/ -name "*.puml" -exec plantuml -checkonly {} \;4.5 步骤 4:文档组装模板
系统设计文档模板(AI 填充):
# [系统名称] - 系统设计文档
## 文档信息
| 项目 | 内容 |
|------|------|
| 文档版本 | v1.0 |
| 创建日期 | [日期] |
| 最后更新 | [日期] |
| 作者 | [作者] + AI 辅助 |
| 状态 | 草稿 / 评审中 / 已批准 |
## 1. 系统概述
[2-3 段描述系统目标、核心功能和技术愿景]
## 2. 架构概览
### 2.1 系统上下文
[C4 Context 图 + 说明]
### 2.2 容器架构
[C4 Container 图 + 说明]
### 2.3 组件详情
[C4 Component 图 + 说明(针对核心容器)]
## 3. 核心业务流程
[序列图 × N + 每个流程的文字说明]
## 4. 数据模型
[ER 图 + 实体说明表]
## 5. 状态机设计
[状态图 + 状态转换规则表]
## 6. 部署架构
[部署图 + 环境说明]
## 7. 架构决策记录(ADR)
[关键 ADR 列表,详见 30b 节]
## 8. 非功能需求设计
### 8.1 性能设计
### 8.2 安全设计
### 8.3 可用性设计
### 8.4 可观测性设计
## 附录
- 术语表
- 参考文档5. 架构图版本控制与持续同步
5.1 图即代码的版本控制策略
架构图作为代码管理的核心优势在于:每次修改都有 Git 历史记录,可以进行 Code Review,支持分支和合并。
推荐的目录结构:
project/
├── docs/
│ ├── architecture/
│ │ ├── README.md # 架构文档入口
│ │ ├── context.md # 系统上下文(含 C4 Context 图)
│ │ ├── containers.md # 容器架构(含 C4 Container 图)
│ │ ├── components/
│ │ │ ├── order-service.md # 订单服务组件图
│ │ │ └── user-service.md # 用户服务组件图
│ │ ├── sequences/
│ │ │ ├── order-flow.md # 下单流程序列图
│ │ │ └── payment-flow.md # 支付流程序列图
│ │ ├── data-model.md # 数据模型 ER 图
│ │ ├── deployment.md # 部署架构图
│ │ └── adrs/ # 架构决策记录
│ │ ├── 001-api-gateway.md
│ │ └── 002-database-choice.md
│ └── generated/ # CI 自动生成的 SVG/PNG
│ ├── context.svg
│ ├── containers.svg
│ └── ...
├── scripts/
│ ├── render-diagrams.sh # 图表渲染脚本
│ └── validate-diagrams.sh # 图表验证脚本
└── .github/
└── workflows/
└── architecture-docs.yml # 架构文档 CI/CD5.2 架构图与代码的持续同步
架构文档最大的痛点是”文档漂移”——代码已经改了,但架构图还是旧的。以下是保持同步的策略:
策略 1:代码变更触发架构图更新提醒
# .github/workflows/architecture-drift-check.yml
name: Architecture Drift Check
on:
pull_request:
paths:
- 'src/**'
- 'services/**'
jobs:
check-drift:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check for architecture-impacting changes
run: |
# 检测是否有架构相关的代码变更
CHANGED_FILES=$(git diff --name-only origin/main...HEAD)
# 检查是否新增/删除了服务
if echo "$CHANGED_FILES" | grep -q "services/.*/main.go\|services/.*/index.ts"; then
echo "⚠️ 检测到服务层变更,请确认架构图是否需要更新"
echo "相关架构文档:"
echo " - docs/architecture/containers.md"
echo " - docs/architecture/deployment.md"
fi
# 检查是否修改了数据模型
if echo "$CHANGED_FILES" | grep -q "models/\|schema/\|migrations/"; then
echo "⚠️ 检测到数据模型变更,请确认 ER 图是否需要更新"
echo "相关架构文档:"
echo " - docs/architecture/data-model.md"
fi
# 检查是否修改了 API 路由
if echo "$CHANGED_FILES" | grep -q "routes/\|api/\|handlers/"; then
echo "⚠️ 检测到 API 变更,请确认序列图是否需要更新"
echo "相关架构文档:"
echo " - docs/architecture/sequences/"
fi
- name: Comment on PR
if: always()
uses: actions/github-script@v7
with:
script: |
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: '🏗️ **架构文档同步提醒**\n\n检测到可能影响架构的代码变更,请确认相关架构图是否需要更新。\n\n使用 AI 快速更新:\n```\n请根据以下代码变更,更新对应的架构图:\n[粘贴 diff]\n```'
})策略 2:AI 辅助的架构图自动更新
你是一个架构文档维护助手。以下是最近的代码变更(git diff):
---
[粘贴 git diff 内容]
---
以下是当前的架构图(Mermaid 代码):
---
[粘贴当前架构图代码]
---
请分析代码变更对架构图的影响,并输出:
1. **变更影响分析**:这些代码变更是否影响架构图?如果是,影响了哪些部分?
2. **更新后的架构图**:如果需要更新,输出完整的更新后 Mermaid 代码
3. **变更说明**:简要说明架构图做了哪些修改及原因
如果代码变更不影响架构图(如 bug 修复、样式调整),请明确说明"无需更新架构图"。策略 3:定期架构图健康检查
请对以下架构图进行健康检查:
[粘贴架构图代码]
检查项目:
1. **完整性**:是否所有已知的服务/组件都在图中?
2. **准确性**:服务间的通信协议和方向是否正确?
3. **一致性**:图中的命名是否与代码库中的命名一致?
4. **时效性**:是否有已废弃的组件仍在图中?
5. **可读性**:布局是否清晰?是否有交叉线过多的问题?
已知的服务列表(从代码库提取):
[列出当前代码库中的服务/模块列表]
请输出检查报告和建议的修改。5.3 架构图的 Code Review 最佳实践
在 PR 中审查架构图变更时的检查清单:
| 检查项 | 说明 | 优先级 |
|---|---|---|
| 语法正确性 | Mermaid/PlantUML 代码能否正确渲染 | 🔴 高 |
| 命名一致性 | 图中的服务名、组件名是否与代码一致 | 🔴 高 |
| 关系准确性 | 服务间的调用方向和协议是否正确 | 🔴 高 |
| 完整性 | 是否遗漏了重要的组件或关系 | 🟡 中 |
| 抽象层级 | 图的详细程度是否适合目标受众 | 🟡 中 |
| 布局清晰度 | 图是否易于理解,没有过多交叉线 | 🟢 低 |
| 样式一致性 | 是否遵循团队的图表样式规范 | 🟢 低 |
6. 多种图表类型的 Prompt 模板库
6.1 通用架构图生成 Prompt
从代码仓库逆向生成架构图:
请分析以下项目结构和关键文件,逆向生成系统架构图:
项目结构:
[粘贴 tree 命令输出或目录结构]
关键配置文件:
[粘贴 docker-compose.yml / kubernetes manifests / package.json 等]
关键入口文件:
[粘贴主要入口文件的 import 和路由定义]
请生成:
1. C4 Container 图(Mermaid):展示所有服务/容器及其关系
2. 数据流图(Mermaid flowchart):展示数据在系统中的流转路径
3. 部署图(Mermaid flowchart + subgraph):展示部署拓扑
每张图前添加 2-3 句说明。从 API 文档生成序列图:
请根据以下 API 端点定义,为每个核心业务流程生成 Mermaid 序列图:
API 端点列表:
[粘贴 OpenAPI/Swagger 定义或 API 路由列表]
服务间调用关系:
[描述哪些服务会调用哪些服务]
请为以下流程各生成一张序列图:
1. [流程 1 名称]
2. [流程 2 名称]
...
要求:
- 使用 autonumber
- 标注 HTTP 方法和路径
- 包含错误处理分支(alt/else)
- 异步操作使用 activate/deactivate 标注6.2 特定场景 Prompt 模板
微服务架构图生成:
请为以下微服务系统生成完整的架构图集:
系统名称:[名称]
服务列表:
- [服务名]:[技术栈],[职责描述]
...
通信方式:
- 同步:[gRPC / REST / GraphQL]
- 异步:[Kafka / RabbitMQ / SQS]
基础设施:
- 数据库:[类型和用途]
- 缓存:[类型和用途]
- 消息队列:[类型和用途]
请生成:
1. 服务拓扑图(flowchart):展示所有服务及其通信关系
2. 数据所有权图:展示每个服务拥有的数据存储
3. 事件流图:展示异步事件在服务间的流转
4. 服务依赖矩阵:展示服务间的依赖关系
所有图使用 Mermaid 语法。Serverless 架构图生成:
请为以下 Serverless 应用生成架构图:
云平台:[AWS / GCP / Azure]
触发器类型:
- API Gateway → Lambda/Cloud Function
- S3/GCS 事件 → Lambda/Cloud Function
- SQS/Pub/Sub → Lambda/Cloud Function
- 定时任务 → Lambda/Cloud Function
函数列表:
- [函数名]:[触发器],[职责],[下游依赖]
...
请生成:
1. 事件驱动架构图(flowchart):展示触发器→函数→下游的完整链路
2. 数据流图:展示数据从输入到输出的完整路径
3. 成本热力图:标注每个组件的预估月成本
使用 Mermaid 语法,用 subgraph 分组不同的云服务类别。事件驱动架构图生成:
请为以下事件驱动系统生成架构图:
事件列表:
- [事件名称]:[发布者] → [消费者列表]
...
事件存储:[Kafka / EventStore / DynamoDB Streams]
请生成:
1. 事件流图(flowchart LR):展示事件从发布到消费的完整路径
2. 事件溯源时间线(sequence diagram):展示关键业务场景的事件序列
3. 聚合边界图:展示领域聚合及其发布/订阅的事件
使用 Mermaid 语法。7. AI 生成图表的常见语法错误与修复
7.1 Mermaid 常见语法错误
AI 生成 Mermaid 代码时,错误率约为 15-40%(取决于图表复杂度和模型能力)。以下是最常见的错误类型和修复方法:
错误 1:节点 ID 包含特殊字符
❌ 错误:
flowchart TD
user-service --> order-service
✅ 修复:
flowchart TD
user_service[user-service] --> order_service[order-service]
💡 规则:节点 ID 不能包含连字符(-),使用下划线或驼峰命名,
在方括号中放置显示标签。错误 2:C4 图中缺少必要参数
❌ 错误:
C4Context
Person(customer)
System(ecommerce)
✅ 修复:
C4Context
Person(customer, "客户", "浏览和购买商品")
System(ecommerce, "电商平台", "提供在线购物服务")
💡 规则:C4 元素需要至少 2 个参数(alias, label),
建议提供 3 个参数(alias, label, description)。错误 3:序列图中箭头语法错误
❌ 错误:
sequenceDiagram
A -> B: 请求
B --> A: 响应
✅ 修复:
sequenceDiagram
A ->> B: 请求
B -->> A: 响应
💡 规则:Mermaid 序列图使用 ->> 表示实线箭头(同步调用),
-->> 表示虚线箭头(返回),-> 和 --> 是无箭头的线。错误 4:ER 图关系符号错误
❌ 错误:
erDiagram
USER 1--* ORDER : "下单"
✅ 修复:
erDiagram
USER ||--o{ ORDER : "下单"
💡 规则:Mermaid ER 图使用特定的基数符号:
|| 精确一个
o| 零或一个
}o 零或多个
}| 一或多个
|{ 一或多个(反向)
o{ 零或多个(反向)错误 5:flowchart 中 subgraph 嵌套语法错误
❌ 错误:
flowchart TD
subgraph AWS
subgraph VPC
A[服务 A]
end subgraph
end subgraph
✅ 修复:
flowchart TD
subgraph AWS["AWS 云环境"]
subgraph VPC["VPC"]
A[服务 A]
end
end
💡 规则:subgraph 的结束标记只需要 end,不需要 end subgraph。
subgraph 的标题放在方括号中。错误 6:状态图中状态名包含空格
❌ 错误:
stateDiagram-v2
[*] --> Pending Payment
Pending Payment --> Paid
✅ 修复:
stateDiagram-v2
[*] --> PendingPayment
state "Pending Payment" as PendingPayment
PendingPayment --> Paid
💡 规则:状态名不能包含空格,使用 state "显示名" as 别名 语法。7.2 PlantUML 常见语法错误
错误 1:缺少 @startuml/@enduml 标记
❌ 错误:
skinparam componentStyle uml2
[API 网关] --> [订单服务]
✅ 修复:
@startuml
skinparam componentStyle uml2
[API 网关] --> [订单服务]
@enduml
💡 规则:PlantUML 代码必须以 @startuml 开头,@enduml 结尾。错误 2:C4-PlantUML include 路径错误
❌ 错误:
@startuml
!include C4_Container.puml
✅ 修复:
@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
💡 规则:使用完整的 GitHub raw URL 引入 C4-PlantUML 库,
或在本地项目中使用相对路径并确保文件存在。错误 3:中文字符导致渲染异常
❌ 错误:
@startuml
[用户服务] --> [订单服务] : 调用
note right : 这里有个问题——破折号导致解析错误
@enduml
✅ 修复:
@startuml
[用户服务] --> [订单服务] : 调用
note right : 这里有个问题 - 使用英文短横线
@enduml
💡 规则:PlantUML 对某些中文标点符号(如中文破折号——、中文冒号:)
支持不佳,建议在标签和注释中使用英文标点。错误 4:组件图中括号嵌套错误
❌ 错误:
@startuml
package "业务层" {
[订单服务 (Go)] as Order
}
@enduml
✅ 修复:
@startuml
package "业务层" {
[订单服务\n(Go)] as Order
}
@enduml
💡 规则:组件名中的圆括号可能被解析为别名语法,
使用 \n 换行或避免在组件名中使用圆括号。7.3 AI 生成图表的语法修复 Prompt
当 AI 生成的图表有语法错误时,使用以下 Prompt 进行修复:
以下 Mermaid/PlantUML 代码有语法错误,无法正确渲染:
```[mermaid/plantuml]
[粘贴有错误的代码]错误信息: [粘贴渲染器的错误信息,如果有的话]
请:
- 逐行分析代码,找出所有语法错误
- 解释每个错误的原因
- 提供修复后的完整代码
- 确保修复后的代码保持原始图表的逻辑和结构不变
注意事项:
- 节点 ID 不能包含特殊字符(连字符、空格、中文)
- 检查箭头语法是否正确
- 检查 subgraph/end 是否配对
- 检查字符串引号是否闭合
### 7.4 预防语法错误的 Prompt 技巧
在生成图表时,通过以下 Prompt 技巧减少语法错误:
请生成 Mermaid [图表类型] 图,并严格遵守以下语法规则:
- 节点 ID 只使用英文字母、数字和下划线,不使用连字符
- 显示标签放在方括号 [] 中,可以使用中文
- 每个 subgraph 必须有对应的 end
- 序列图箭头使用 ->> (实线)和 —>> (虚线),不使用 -> 或 —>
- ER 图关系使用 ||—o{ 等标准基数符号
- 状态名不包含空格,使用 state “显示名” as 别名 语法
- 生成完成后,请自行检查一遍语法正确性
图表需求: [描述图表需求]
---
## 8. 图表渲染与发布工具链详解
### 8.1 Mermaid CLI(mmdc)
Mermaid CLI 是在 CI/CD 管线中渲染 Mermaid 图表的标准工具:
```bash
# 安装
npm install -g @mermaid-js/mermaid-cli
# 基本用法:将 .mmd 文件渲染为 SVG
mmdc -i diagram.mmd -o diagram.svg
# 渲染为 PNG(指定宽度)
mmdc -i diagram.mmd -o diagram.png -w 1920
# 渲染为 PDF
mmdc -i diagram.mmd -o diagram.pdf
# 使用指定主题
mmdc -i diagram.mmd -o diagram.svg --theme dark
# 可选主题:default, forest, dark, neutral
# 使用自定义配置
mmdc -i diagram.mmd -o diagram.svg --configFile mermaid.config.json
# 批量渲染
find docs/ -name "*.mmd" -exec sh -c '
mmdc -i "$1" -o "${1%.mmd}.svg" --theme neutral
' _ {} \;Mermaid 配置文件示例(mermaid.config.json):
{
"theme": "neutral",
"themeVariables": {
"primaryColor": "#1a73e8",
"primaryTextColor": "#ffffff",
"primaryBorderColor": "#1557b0",
"lineColor": "#5f6368",
"secondaryColor": "#e8f0fe",
"tertiaryColor": "#f1f3f4",
"fontSize": "14px",
"fontFamily": "Source Han Sans SC, sans-serif"
},
"flowchart": {
"htmlLabels": true,
"curve": "basis",
"padding": 15
},
"sequence": {
"diagramMarginX": 50,
"diagramMarginY": 10,
"actorMargin": 50,
"width": 150,
"height": 65,
"boxMargin": 10,
"useMaxWidth": true
},
"er": {
"diagramPadding": 20,
"layoutDirection": "TB",
"minEntityWidth": 100,
"minEntityHeight": 75,
"entityPadding": 15,
"useMaxWidth": true
}
}8.2 Kroki 统一渲染服务
Kroki 提供统一的 REST API,支持 30+ 种图表格式的渲染,是多格式图表项目的理想选择:
# Docker 自托管部署
docker run -d -p 8000:8000 yuzutech/kroki
# 通过 API 渲染 Mermaid 图表
curl -X POST https://kroki.io/mermaid/svg \
-H "Content-Type: text/plain" \
-d 'flowchart TD
A[开始] --> B{条件}
B -->|是| C[执行]
B -->|否| D[跳过]' \
-o diagram.svg
# 通过 API 渲染 PlantUML 图表
curl -X POST https://kroki.io/plantuml/svg \
-H "Content-Type: text/plain" \
-d '@startuml
[API] --> [DB]
@enduml' \
-o diagram.svg
# 支持的格式(部分):
# mermaid, plantuml, graphviz, d2, c4plantuml,
# dbml, erd, excalidraw, structurizr, vegalite...Kroki MCP 集成配置(Claude Code / Kiro):
{
"mcpServers": {
"kroki": {
"command": "npx",
"args": ["-y", "mcp-kroki"],
"env": {
"KROKI_URL": "https://kroki.io"
}
}
}
}8.3 PlantUML Server
# Docker 部署 PlantUML Server
docker run -d -p 8080:8080 plantuml/plantuml-server:jetty
# 通过 URL 编码渲染
# 访问 http://localhost:8080/svg/SoWkIImgAStDuNBAJrBGjLDmpCbCJbMmKiX8pSd9vt98pKi1IW80
# 通过 API 渲染
curl -X POST http://localhost:8080/svg \
-H "Content-Type: text/plain" \
-d '@startuml
Alice -> Bob: Hello
Bob --> Alice: Hi
@enduml' \
-o sequence.svg8.4 文档站点集成
Docusaurus + Mermaid 插件:
// docusaurus.config.js
module.exports = {
markdown: {
mermaid: true,
},
themes: ['@docusaurus/theme-mermaid'],
themeConfig: {
mermaid: {
theme: {
light: 'neutral',
dark: 'dark',
},
options: {
maxTextSize: 50000,
fontFamily: 'Source Han Sans SC, sans-serif',
},
},
},
};VitePress + Mermaid 插件:
// .vitepress/config.js
import { withMermaid } from 'vitepress-plugin-mermaid';
export default withMermaid({
mermaid: {
theme: 'neutral',
},
mermaidPlugin: {
class: 'mermaid',
},
});实战案例:从零生成 SaaS 平台系统设计文档
案例背景
一个 3 人创业团队要构建一个 B2B SaaS 项目管理平台,需要在一天内完成系统设计文档。以下是使用 AI 辅助的完整工作流。
步骤 1:需求输入
向 AI 提供以下需求摘要:
我们要构建一个 B2B SaaS 项目管理平台,核心功能包括:
- 多租户支持(每个企业一个工作空间)
- 项目和任务管理(看板视图、列表视图、甘特图)
- 团队协作(评论、@提及、文件附件)
- 权限管理(工作空间管理员、项目经理、成员、访客)
- 实时通知(应用内 + 邮件 + Slack/飞书集成)
- API 开放平台(供第三方集成)
技术约束:
- 团队熟悉 TypeScript 全栈(Next.js + Node.js)
- 预算有限,优先使用 Serverless 架构
- 目标用户 1000 家企业,每家 50-200 人
- 需要 SOC 2 合规步骤 2:AI 生成系统上下文图
步骤 3:AI 生成容器架构图
步骤 4:AI 生成核心业务流程序列图
步骤 5:AI 生成数据模型
步骤 6:AI 生成部署架构图
案例分析
这个案例展示了 AI 辅助系统设计文档生成的完整工作流:
- 效率提升:从需求到完整的 6 张架构图 + 文档框架,AI 辅助下约 2-3 小时完成,传统方式需要 2-3 天
- 一致性保证:所有图表使用统一的命名和样式,服务名在不同视图间保持一致
- 可维护性:所有图表都是文本代码,可以 Git 管理、Code Review、自动渲染
- 迭代友好:修改架构只需改几行 Mermaid 代码,AI 可以快速更新所有相关图表
关键决策点:
- 选择 Serverless 架构(Lambda + Neon + Upstash)降低运维成本,适合 3 人团队
- 实时服务使用 ECS Fargate 而非 Lambda,因为 WebSocket 需要长连接
- 多租户使用 Row-Level Security(RLS)而非独立数据库,降低成本和复杂度
- 文件存储使用 S3 + 预签名 URL,避免文件流量经过 API 服务
避坑指南
❌ 常见错误
-
一次性生成过于复杂的图表
- 问题:要求 AI 在一张图中展示所有细节,导致图表过于拥挤、难以阅读,且语法错误率飙升
- 正确做法:遵循 C4 模型的分层原则,每张图只关注一个抽象层级。先生成 Context 图,再逐层深入到 Container 和 Component
-
不验证 AI 生成的图表语法
- 问题:直接将 AI 生成的 Mermaid/PlantUML 代码提交到文档,上线后发现渲染失败
- 正确做法:在 CI/CD 管线中加入图表语法验证步骤,使用 mmdc 或 PlantUML CLI 进行自动化检查。AI 生成的图表错误率约 15-40%,必须验证
-
图表与代码脱节
- 问题:架构图在项目初期生成后再也没有更新,与实际代码严重不符
- 正确做法:建立架构图持续同步机制——代码变更触发架构图更新提醒,定期进行架构图健康检查,将架构图更新纳入 PR 审查流程
-
过度依赖 AI 生成的架构方案
- 问题:完全信任 AI 生成的架构图,不进行人工审查,导致遗漏关键的非功能需求(安全、性能、故障恢复)
- 正确做法:AI 生成的架构图是”初稿”,必须经过架构师审查。重点检查:是否遗漏了故障模式、安全边界是否正确、性能瓶颈是否被识别
-
忽视图表的目标受众
- 问题:给产品经理看充满技术细节的组件图,给开发者看过于抽象的上下文图
- 正确做法:根据受众选择合适的图表类型和详细程度。C4 Context 图给管理层和产品经理,Container 图给技术负责人,Component 图给开发团队
-
Mermaid 和 PlantUML 混用导致维护混乱
- 问题:同一个项目中部分图用 Mermaid,部分用 PlantUML,工具链和渲染方式不统一
- 正确做法:团队统一选择一种主要工具。推荐:文档内嵌优先选 Mermaid(GitHub/GitLab 原生支持),企业级 UML 建模选 PlantUML。如果必须混用,使用 Kroki 统一渲染
-
生成图表时不提供足够的上下文
- 问题:只给 AI 一句话描述就要求生成架构图,结果图表过于通用、缺乏项目特定的设计决策
- 正确做法:提供详细的需求描述、技术约束、团队能力、性能要求等上下文信息。上下文越丰富,AI 生成的图表越准确
✅ 最佳实践
- 分层生成,逐步细化:先生成高层 Context 图确认系统边界,再生成 Container 图确认技术栈,最后生成 Component 图和序列图确认实现细节
- 图文并茂:每张图前添加 2-3 句文字说明,解释设计决策和关键约束,图表本身不能替代文字解释
- 建立团队图表规范:统一命名规则、颜色方案、布局方向、标注格式,使用 Mermaid 配置文件或 PlantUML 主题文件确保一致性
- 将图表纳入 Code Review:架构图变更与代码变更一样需要审查,检查命名一致性、关系准确性、完整性
- 使用 MCP 集成提升效率:在 Claude Code 或 Kiro 中配置 mcp-mermaid 或 mcp-kroki,实现”对话生成 + 即时预览”的工作流
- 定期架构图健康检查:每个 Sprint 结束时,用 AI 对比代码库和架构图,检查是否有漂移
- 保持图表简洁:每张图的元素不超过 15-20 个,超过时拆分为多张图。复杂系统用多张关联图表达,而非一张巨图
相关资源与延伸阅读
- Mermaid 官方文档 — 完整的 Mermaid 语法参考和在线编辑器
- PlantUML 官方文档 — PlantUML 全类型图表语法参考
- C4-PlantUML GitHub 仓库 — C4 模型的 PlantUML 扩展库
- C4 Model 官方网站 — Simon Brown 的 C4 模型方法论
- Kroki 统一图表渲染服务 — 支持 30+ 图表格式的统一 API
- mcp-mermaid GitHub 仓库 — AI 编码工具中动态生成 Mermaid 图表的 MCP Server
- Mermaid Chart — Mermaid 官方在线编辑器和 AI 辅助工具
- Structurizr DSL — C4 模型专用的架构定义语言
参考来源
- Automate architecture diagrams with AI (2025)
- Automate Technical Diagrams with LLMs using Mermaid, PlantUML and CI/CD (2025)
- Generate Architecture Diagrams with AI in 15 Minutes (2026)
- The AI Revolution in C4 Architecture Diagramming (2025)
- Visual Paradigm AI C4 Studio — Complete C4 Model Support (2025)
- New AI-Powered C4 PlantUML Studio (2025)
- Why I Use Mermaid with LLMs (2025)
- From text to diagrams — Working with Mermaid (2025)
- Visual Paradigm AI vs. General LLMs: 2026 UML Accuracy Benchmark (2026)
- Mermaid Chart Reviews 2026 (2026)
- Data Modelling with Mermaid — From Whiteboards to Git (2025)
- Using GitHub Copilot AI for Documenting and Diagramming CI/CD Pipelines (2025)
- Migrate diagrams from PlantUML to Mermaid and draw.io (2025)
📖 返回 总览与导航 | 上一节:30b-AI辅助架构决策 | 下一节:30d-架构审查清单与反模式