The interface is localized. Skill descriptions and documents are machine-translated by AI into your language; code, commands, paths and technical terms stay in the original, and the author's document governs.
Explore skills
Productivity · SKILL.md

architecture-diagram

architecture-diagram

架构图生成器——多轮结构化提问理解系统架构,生成精美深色主题自包含 HTML+SVG 架构图。 支持系统架构图、云基础设施图、微服务拓扑图、安全架构图、网络拓扑图等。 Trigger keywords: 架构图, architecture diagram, 系统架构, 画架构图, 云架构, 微服务架构, 网络拓扑, 安全架构, 基础设施图, system architecture, cloud architecture, AWS架构, infra diagram, 部署架构, 技术架构图, generate architecture diagram.

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill documentation

GitHub

name: architecture-diagram description: > 架构图生成器——多轮结构化提问理解系统架构,生成精美深色主题自包含 HTML+SVG 架构图。 支持系统架构图、云基础设施图、微服务拓扑图、安全架构图、网络拓扑图等。 Trigger keywords: 架构图, architecture diagram, 系统架构, 画架构图, 云架构, 微服务架构, 网络拓扑, 安全架构, 基础设施图, system architecture, cloud architecture, AWS架构, infra diagram, 部署架构, 技术架构图, generate architecture diagram. allowed-tools:


Architecture Diagram Generator — 架构图生成器

基于 Cocoon AI 的 MIT 开源项目深度优化版。 核心改进:Quick Mode / Deep Mode 自适应分支 + 多轮结构化发现协议,轻量场景秒出图,复杂系统深度理解。

工作流程总览

用户请求
    │
    ▼
┌─────────────────────────────┐
│ Step 0: Mode Detection      │
│ 判断走 Quick 还是 Deep       │
└──────────┬──────────────────┘
           │
    ┌──────┴──────┐
    ▼             ▼
┌────────┐   ┌────────────────────┐
│ Quick   │   │ Deep               │
│ 0-1轮确认│   │ 5轮渐进发现         │
│ 直接生成 │   │ R1→R2→R3→R4→R5     │
└───┬────┘   └─────────┬──────────┘
    │                  │
    └──────┬───────────┘
           ▼
    Phase 1: Layout  →  Phase 2: Generate  →  Phase 3: Verify

Step 0: Mode Detection — 自动判断走 Quick 还是 Deep

核心原则:不是所有图都需要大费周章。根据用户请求的特征,自动选择最合适的路径。

判断标准

在收到用户请求后,先用以下规则判断模式:

信号→ Quick Mode→ Deep Mode
组件数量≤ 5 个明确组件> 5 个,或数量不明
描述完整度用户说清楚了组件+关系描述模糊("我们有个微服务系统")
场景类型局部流程、单链路、概念草图全栈系统、多子系统、企业架构
用户意图"快速画一下" "示意一下" "简单画个""完整架构图" "梳理一下" "帮我理清"
领域知识典型/通用架构(AI已有足够知识)用户自己的定制系统

Quick Mode 触发示例

以下类型请求 → 直接走 Quick Mode,不要追问:

用户说什么为什么 Quick
"画一个 React + Node + PostgreSQL 的三层架构"经典三层,AI 完全理解
"画一下 OAuth 2.0 授权码流程"标准协议流程
"画出用户登录的时序图,从浏览器到数据库"单链路,组件明确
"给我一个典型的 AWS serverless 架构"通用参考架构
"CDN → ALB → ECS → RDS,画出来"用户已经列清楚了
"画个简单的微服务示意图,API Gateway + 3个服务 + Kafka"组件数量少且明确
"把这个数据流画一下:Kafka → Flink → ClickHouse → Grafana"线性管道,组件明确
"示意一下前端调用后端的认证流程"示意级别,不需要精确

Deep Mode 触发示例

以下类型请求 → 走 Deep Mode 5轮发现:

用户说什么为什么 Deep
"帮我梳理我们电商系统的完整架构"大型系统,需要理解业务
"画一下我们公司的技术架构图"需要大量追问才能搞清楚
"我想重构现有系统,先画个现状图"需要深入理解现有系统
"画一个包含安全边界的生产环境部署架构"多维度(部署+安全+网络)
"我们用了 K8s + Istio + 20个微服务,画个图"组件多,需要组织

灰色地带处理

当不确定时:

  1. 先用 1 轮轻量确认(类似 Quick Mode 的确认方式)
  2. 如果用户回复暴露出更多复杂性,自动升级到 Deep Mode
  3. 如果用户回复简洁明确,继续 Quick Mode 直接生成

一句话原则:用户说得越清楚,你问得越少;用户说得越模糊,你问得越多。


Quick Mode — 轻量快速出图

适用场景:组件 ≤ 5 个、用户描述清晰、典型通用架构、局部流程/单链路、概念草图。

Quick Mode 流程

用户请求 → [可选:1轮确认] → 直接生成 → 让用户看图迭代

什么时候跳过确认直接生成

直接生成(0 轮确认),当:

  • 组件完全明确(用户列出了每个组件名和技术栈)
  • 是标准/经典架构(三层架构、OAuth 流程、典型 AWS 架构等)
  • 用户说了"简单画个""示意一下""quick"

1 轮确认,当:

  • 组件明确但关系/方向不清晰
  • 有 2-3 种合理的画法(比如数据流方向不确定)
  • 用户给了组件但没给连接关系

Quick Mode 确认模板(1轮即可)

当需要确认时,用极简格式,不要抛出 5 轮问题:

## 🏗️ 确认一下(1 分钟)

**我理解的架构**:
  [组件A] ──HTTP──▶ [组件B] ──SQL──▶ [组件C]

**布局方向**: 左→右 / 上→下
**需要标注的协议/端口**: HTTP :443, PostgreSQL :5432

这样画可以吗?还是有什么要调整的?

确认后直接进入 Phase 2(跳过 Phase 1 的复杂布局规划,用默认布局)。

Quick Mode 默认布局规则

不经过 Phase 1 规划时,使用以下默认值:

参数默认值
布局方向左→右(从左到右数据流)
画布viewBox="0 0 1000 680"
组件尺寸标准 110×60px
水平间距100px
垂直对齐所有组件垂直居中(y 相同)
Header从用户请求中提取关键词作为标题
摘要卡片全部省略(Quick Mode 不生成摘要卡片,保持简洁)

Deep Mode — 多轮结构化提问

适用场景:组件 > 5 个、大型系统、描述模糊、需要梳理、多子系统、企业级架构。

关键原则:在生成任何 SVG 代码之前,必须通过多轮对话精确理解系统架构。 根据用户初始描述的详细程度,自动判断需要深入哪些轮次。 如果用户已经提供了非常详细的描述,可以跳过部分轮次并直接确认。

Round 1: 系统类型识别 & 范围界定

目标:确定架构的顶层模式和边界。

向用户提问(根据已有信息选择性提问,不要全部抛出):

  1. 系统类型:这是什么类型的系统?

    • Web 应用(前后端分离 / SSR / SPA)
    • 微服务系统(服务数量、服务间通信方式)
    • 数据管道 / ETL(数据源→处理→存储链路)
    • 云基础设施(AWS / Azure / GCP / 混合云)
    • 移动端后端 (BFF + Microservices)
    • Serverless 架构
    • 事件驱动架构
    • AI/ML 推理平台
    • 其他:________
  2. 规模感:系统的规模大约多大?

    • 小型(3-7 个核心组件)
    • 中型(8-15 个组件,多个子系统)
    • 大型(15+ 组件,多层嵌套,多区域)
  3. 目标受众:这张图给谁看?

    • 技术团队内部(可以偏技术细节)
    • 跨团队沟通(需要适度简化)
    • 高管/客户(需要高度抽象)
    • 文档/PPT(需要正式美观)
  4. 侧重点:用户最关心哪个维度?

    • 数据流(请求/响应路径)
    • 部署拓扑(物理/虚拟节点)
    • 安全边界(信任域、网络隔离)
    • 高可用/容灾(多区域、故障转移)
    • 全部展示

输出:1-2 句话的系统概要 + 架构模式标签。


Round 2: 组件清单盘点

目标:穷举所有组件,不遗漏。

根据 Round 1 的系统类型,引导用户分层列出组件:

📋 组件清单模板:

[客户端层]
  - 组件名 | 技术栈 | 关键信息(URL/端口/协议)

[接入层]
  - CDN / WAF / API Gateway / Load Balancer | 技术选型 | 配置要点

[应用层]
  - 每个服务/模块 | 语言/框架 | 端口/协议 | 扩缩容策略

[数据层]
  - 数据库类型 | 具体产品 | 用途 | 高可用方案
  - 缓存 | 消息队列 | 对象存储

[基础设施层]
  - 云平台/自建 | 区域 | 编排工具 | 监控告警

[外部依赖]
  - 第三方 API | 身份提供商 | 支付网关 | 邮件服务

交互策略:

  • 如果用户描述模糊(如 "用了一个数据库"),追问具体产品(PostgreSQL? MongoDB?)
  • 如果用户遗漏了常见配套组件(如说了 API 但没说 API Gateway),主动提醒
  • 如果组件过多(>20),建议拆分多张图或用分组折叠

输出:完整的组件表格,每个组件标注:名称、类型、技术栈、备注。


Round 3: 关系与数据流映射

目标:精确理解组件间的连接关系。

对 Round 2 的每个组件,逐一确认:

  1. 它调用谁? → 出方向箭头
  2. 谁调用它? → 入方向箭头
  3. 通信协议? → HTTP/REST, gRPC, WebSocket, GraphQL, TCP, UDP, 消息队列
  4. 认证方式? → JWT, OAuth2, mTLS, API Key, 无
  5. 数据方向? → 单向读取 / 双向读写 / 异步推送
  6. 是否有特殊流程? → 启动流程、故障转移路径、定时任务链路

交互策略:

  • 引导用户按 "请求进来 → 经过 → 到达 → 返回" 的路径描述
  • 对微服务系统,额外确认服务发现、配置中心、分布式追踪的位置
  • 对事件驱动系统,确认生产者→Topic→消费者的完整链路

输出:连接关系列表,每条标注:from → to | 协议 | 认证 | 备注。


Round 4: 基础设施与部署上下文

目标:理解运行环境的物理/虚拟拓扑。

仅在 Round 1 确认需要展示部署拓扑时深入:

  1. 云平台:AWS / Azure / GCP / 阿里云 / 腾讯云 / 自建机房?
  2. 区域部署:单区域?多区域?具体 region 名称?
  3. 容器化:Kubernetes? Docker Compose? 无容器?
  4. 网络拓扑:VPC / 子网划分?公网/私网暴露面?
  5. CI/CD 链路:是否需要展示构建→测试→部署流程?
  6. 监控告警:Prometheus + Grafana? Datadog? CloudWatch?

输出:基础设施上下文摘要。


Round 5: 安全边界确认

目标:明确信任域和隔离边界。

  1. 安全组/防火墙规则:哪些端口对谁开放?
  2. 网络隔离:公网子网 / 私有子网 / 数据库子网?
  3. 认证流程:用户登录的完整路径(前端→Auth Provider→Token 签发→验证)
  4. 敏感数据处理:PII 数据在哪里?加密方式?
  5. 合规要求:SOC2 / HIPAA / PCI-DSS?

输出:安全边界列表 + 安全组标记位置。


Discovery 完成确认

在进入 Phase 1 之前,向用户输出一份 架构理解摘要:

## 🏗️ 架构理解确认

**系统类型**: [识别的模式]
**规模**: [小型/中型/大型]
**组件总数**: [N] 个

**组件清单**:
  [Frontend] React SPA → CloudFront CDN
  [Backend]  Node.js/Express API (:3000)
  [Database] PostgreSQL (RDS, Multi-AZ)
  ...

**关键数据流**:
  用户 → CloudFront → ALB → API → RDS
  认证流: 用户 → Cognito → JWT → API 验证
  ...

**部署**: AWS us-east-1, EKS 集群, 2个AZ

以上理解是否正确?确认后我开始画图。

只有在用户确认后,才进入 Phase 1。


Phase 1: Layout Planning — 布局规划(Deep Mode)

基于 Phase 0 的发现结果,在生成代码前先规划布局。 Quick Mode 跳过此阶段,使用默认布局参数(左→右,组件垂直居中)。

1.1 布局模式选择

根据系统类型自动选择最佳布局:

系统类型推荐布局说明
Web 应用(前后端)左→右客户端在左,逐步向右到数据层
微服务系统左→右 + 分层入口层→业务服务层→数据层
数据管道/ETL左→右Source→Transform→Sink 线性流
云基础设施自由分组按 VPC/子网/区域分组
事件驱动上→下Producer→Bus→Consumer 流
安全架构洋葱模型外层→内层信任域递增

1.2 画布尺寸计算

画布宽度 = max(1000, 组件列数 × 180 + 边距 × 2)
画布高度 = max(680, 组件行数 × 100 + 边界框高度 + 图例高度 + 边距)

1.3 组件分组与 z-order 规划

  • Region boundaries (最底层)
  • Security groups (第二层)
  • Connection arrows (第三层,在组件后面)
  • Component boxes (第四层,半透明背景 + 不透明底层遮挡箭头)
  • Labels & annotations (最顶层)

1.4 配色分配

按组件类型自动分配(参见 Design System 章节的颜色表):

  • Frontend → Cyan
  • Backend → Emerald
  • Database / AI/ML → Violet
  • Cloud / AWS / Infrastructure → Amber
  • Security / Auth → Rose
  • Message Bus / Event → Orange
  • External / Third-party → Slate

Phase 2: Code Generation — 代码生成

2.1 使用模板

从 resources/template.html 获取基础模板,然后:

  1. 更新 <title> 和 Header 文字
  2. 调整 SVG viewBox 尺寸(根据 Phase 1 计算)
  3. 按 Phase 1 布局逐一定位每个组件(参考 Design System 的 Component Box Pattern)
  4. 绘制所有连接箭头(在组件之前,参见 z-order 规则)
  5. 添加安全组虚线框、区域边界框
  6. 填充 3 张摘要卡片(关键指标、技术栈、安全要点)
  7. 添加图例(放在所有边界框之外)
  8. 更新 Footer 元数据

2.2 关键约束

  • 必须保留模板中的 2 个 CDN script(html2canvas + jsPDF,含 SRI hash)
  • 必须保留 id="report-container" 在外层容器
  • 必须保留 .toolbar 和相关 JS 导出函数
  • 禁止引入新的外部依赖(除 Google Fonts 外)

Phase 3: Quality Verification — 质量验证

生成 HTML 后,逐项检查。Quick Mode 只需检查标有 ⚡ 的项目(核心项),Deep Mode 需全部检查。

自检清单

  • ⚡ 间距:所有组件间垂直间距 ≥ 40px,水平间距 ≥ 30px
  • ⚡ 无重叠:组件不重叠,箭头不穿过文字
  • 图例位置:图例在所有边界框下方 ≥ 20px(Quick Mode 如无图例可跳过)
  • ⚡ 箭头遮蔽:每个组件有 fill="#0f172a" 底层 rect 遮蔽穿透的箭头
  • ⚡ 箭头方向:所有箭头终点指向正确方向
  • ⚡ 完整性:用户提到的所有组件都在图中
  • ⚡ 颜色一致:同类组件使用相同的配色方案
  • ⚡ 文字可读:字号 ≥ 7px,标签不溢出组件边界
  • ⚡ 导出功能:工具栏 HTML + JS 完整,html2canvas/jsPDF CDN 标签完整
  • ⚡ 移动端:容器有 overflow-x: auto,小屏可横向滚动
  • 摘要卡片:3 张卡片内容准确(Deep Mode only — Quick Mode 不生成摘要卡片)

修复优先级

  1. 功能性问题(箭头指向错误、组件缺失)→ 立即修复
  2. 视觉问题(重叠、溢出)→ 调整坐标
  3. 增强性改进(更好的标注、更美观的布局)→ 可选修复

Design System

以下设计规范继承自上游 Cocoon AI v1.1,保持不变。

Color Palette

Component TypeFill (rgba)Stroke
Frontendrgba(8, 51, 68, 0.4)#22d3ee (cyan-400)
Backendrgba(6, 78, 59, 0.4)#34d399 (emerald-400)
Databasergba(76, 29, 149, 0.4)#a78bfa (violet-400)
AWS/Cloudrgba(120, 53, 15, 0.3)#fbbf24 (amber-400)
Securityrgba(136, 19, 55, 0.4)#fb7185 (rose-400)
Message Busrgba(251, 146, 60, 0.3)#fb923c (orange-400)
External/Genericrgba(30, 41, 59, 0.5)#94a3b8 (slate-400)

Typography

  • Font: JetBrains Mono (Google Fonts)
  • Sizes: 12px (组件名), 9px (副标签), 8px (注释), 7px (微型标签)
  • Weights: 400 (正文), 500 (强调), 600-700 (标题)

Visual Elements

  • Background: #020617 (slate-950) + 40px 网格
  • Component boxes: rx="6", 1.5px stroke, 半透明 fill
  • Security groups: stroke-dasharray="4,4", 透明 fill, rose 色
  • Region boundaries: stroke-dasharray="8,4", amber 色, rx="12"
  • Arrows: SVG <marker> 箭头, #64748b 颜色
  • Auth flows: 虚线 stroke-dasharray="5,5", rose 色

Arrow Masking

箭头在 SVG 中先绘制,组件半透明 fill 会让箭头透出。解决方案:

<!-- 不透明底层遮挡箭头 -->
<rect x="X" y="Y" width="W" height="H" rx="6" fill="#0f172a"/>
<!-- 半透明风格层在顶层 -->
<rect x="X" y="Y" width="W" height="H" rx="6" fill="rgba(...)" stroke="..." stroke-width="1.5"/>

Spacing Rules

  • 标准组件高度: 60px (服务), 80-120px (大型组件)
  • 垂直间距: ≥ 40px
  • 消息总线: 放在间隙中间,不重叠相邻组件
  • 图例: 在所有边界框下方 ≥ 20px

Iteration Protocol — 修改迭代协议

用户提出修改需求时,按以下优先级处理:

修改类型示例处理方式
增删组件"加一个 Redis 缓存"重新计算受影响区域的坐标
修改连接"API 不直连 DB,走 DAO 层"调整箭头路径
样式调整"把 Frontend 改成蓝色"修改颜色常量
布局调整"数据库放到底部"局部重新布局
标注修正"端口号不对,应该是 8080"修改文本内容

重要: 修改后必须重新执行 Phase 3 的间距和重叠检查。


安装方式

Claude Code CLI(本项目)

cp -r architecture-diagram/ ~/.claude/skills/architecture-diagram/

Claude.ai

下载 architecture-diagram.zip 并通过 Skills 面板上传。


触发示例

Quick Mode(快速出图):

  • "画一个 React + Node.js + PostgreSQL 的三层架构"
  • "画一下 OAuth 2.0 授权码流程"
  • "简单画个 CDN → ALB → ECS → RDS 的图"
  • "给我一个典型的 AWS serverless 架构"
  • "示意一下前端调后端的认证流程"
  • "画个 Kafka → Flink → ClickHouse 数据管道"

Deep Mode(深度梳理):

  • "帮我梳理一下我们电商系统的完整架构"
  • "画一个包含安全边界的生产环境部署架构"
  • "我们用了 K8s + Istio + 20 个微服务,画个图"
  • "我想重构现有系统,先画个现状架构图"

输出示例

参考 examples/ 目录下的示例 HTML 文件:

  • web-app.html — Web 应用三层架构
  • aws-serverless.html — AWS Serverless 架构
  • microservices.html — 微服务 + Kubernetes 架构

上游致谢

本 skill 基于 Cocoon AI 的 architecture-diagram-generator (MIT License) 深度优化。

v2.1 核心改进:

  • ✅ Quick Mode / Deep Mode 自适应分支:轻量场景秒出图(0-1轮确认),复杂系统深度发现(5轮)
  • ✅ Step 0: Mode Detection:自动判断走哪个模式,不是所有图都要大费周章
  • ✅ Quick Mode 省略摘要卡片和复杂布局规划,保持输出简洁
  • ✅ 增加 Phase 1: Layout Planning 布局规划(模式选择 + 画布计算)
  • ✅ 增加 Phase 3: Quality Verification 质量验证清单(区分 Quick/Deep)
  • ✅ 增加 Iteration Protocol 迭代修改协议
  • ✅ 增加中文触发关键词和双语支持
  • ✅ 保留上游 v1.1 的完整设计系统、模板和导出功能

中文介绍

以下内容整理自卡兹克的介绍文章:《又一个神级画图 Skill 开源,再见 draw.io!》

这是什么?

Cocoon AI 开源的 Claude Skill,说人话就能画架构图。跟 Claude 描述系统架构,它直接生成一张深色主题的 HTML 架构图,浏览器打开就能看,还能导出 PNG 和 PDF。不用碰 Draw.io,颜色、箭头、对齐 Claude 全包了。

开源地址:https://github.com/Cocoon-AI/architecture-diagram-generator

功能亮点

说人话就能画。 不需要写代码、不用学标记语法。把架构描述丢给 Claude,它自己决定组件怎么摆、箭头往哪指、用什么颜色。

颜色自动分类。 深色主题 + JetBrains Mono 字体,颜色语义固定:青色给前端,翠绿给后端,紫色给数据库,琥珀色给 AWS 等云服务,玫瑰色给认证和安全模块,一眼就能分辨模块类型。

一键导出。 生成的 HTML 右上角三个按钮:Copy PNG 到剪贴板、Download PNG、Download PDF。零命令行,零额外依赖。

安装方式

Claude Code:把 zip 解压到 ~/.claude/skills/ 或项目本地 .claude/skills/ 目录。

Codex / Cursor / Copilot 等:用 npx skills add 安装,或让 AI 直接重构一个适配版本。

使用方式

三种路子获得架构描述:

  1. 让 AI 分析代码库:把代码丢给 Codex/Claude,让它分析结构并输出组件清单
  2. 自己手写:直接列出组件和连接关系,比如 "React 前端 talking to Node.js API,PostgreSQL 数据库,Redis 缓存"
  3. 让 Claude 给模板:没有具体系统的话,直接问 "画一个典型的 SaaS 应用架构图"

然后把描述贴进对话,加一句"用你的架构图 Skill 生成一张架构图",Codex/Claude 返回 HTML 文件。想改图直接在聊天里说"把 Redis 挪到消息队列旁边"或"加一层 CDN"就行。

适用与不适用

✅ 擅长:软件架构、云基础设施、微服务拓扑等有明确层次和连接关系的图 ❌ 不适合:物理硬件图、流程图(流程图的姐妹项目 process-flow-diagram-generator 同作者出品)

省下时间干嘛?

写代码、想设计、或者干脆摸鱼,都比调箭头颜色有意义。

Saved skills