计划执行与检查节点
executing-plans
按既定实施计划完成工作,保持过程检查和反馈。
architecture-diagram【效率与协作】架构图生成器——多轮结构化提问理解系统架构,生成精美深色主题自包含 HTML+SVG 架构图。 支持系统架构图、云基础设施图、微服务拓扑图、安全架构图、网络拓扑图等。 Trigger keywords: 架构图, architecture diagram, 系统架构, 画架构图, 云架构, 微服务架构, 网络拓扑, 安全架构, 基础设施图, system architecture, cloud architecture, AWS架构, infra diagram, 部署架构, 技术架构图, generate architecture diagram.
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
name: architecture-diagram description: > 架构图生成器——多轮结构化提问理解系统架构,生成精美深色主题自包含 HTML+SVG 架构图。 支持系统架构图、云基础设施图、微服务拓扑图、安全架构图、网络拓扑图等。 Trigger keywords: 架构图, architecture diagram, 系统架构, 画架构图, 云架构, 微服务架构, 网络拓扑, 安全架构, 基础设施图, system architecture, cloud architecture, AWS架构, infra diagram, 部署架构, 技术架构图, generate architecture diagram. allowed-tools:
基于 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
核心原则:不是所有图都需要大费周章。根据用户请求的特征,自动选择最合适的路径。
在收到用户请求后,先用以下规则判断模式:
| 信号 | → Quick Mode | → Deep Mode |
|---|---|---|
| 组件数量 | ≤ 5 个明确组件 | > 5 个,或数量不明 |
| 描述完整度 | 用户说清楚了组件+关系 | 描述模糊("我们有个微服务系统") |
| 场景类型 | 局部流程、单链路、概念草图 | 全栈系统、多子系统、企业架构 |
| 用户意图 | "快速画一下" "示意一下" "简单画个" | "完整架构图" "梳理一下" "帮我理清" |
| 领域知识 | 典型/通用架构(AI已有足够知识) | 用户自己的定制系统 |
以下类型请求 → 直接走 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 5轮发现:
| 用户说什么 | 为什么 Deep |
|---|---|
| "帮我梳理我们电商系统的完整架构" | 大型系统,需要理解业务 |
| "画一下我们公司的技术架构图" | 需要大量追问才能搞清楚 |
| "我想重构现有系统,先画个现状图" | 需要深入理解现有系统 |
| "画一个包含安全边界的生产环境部署架构" | 多维度(部署+安全+网络) |
| "我们用了 K8s + Istio + 20个微服务,画个图" | 组件多,需要组织 |
当不确定时:
一句话原则:用户说得越清楚,你问得越少;用户说得越模糊,你问得越多。
适用场景:组件 ≤ 5 个、用户描述清晰、典型通用架构、局部流程/单链路、概念草图。
用户请求 → [可选:1轮确认] → 直接生成 → 让用户看图迭代
直接生成(0 轮确认),当:
1 轮确认,当:
当需要确认时,用极简格式,不要抛出 5 轮问题:
## 🏗️ 确认一下(1 分钟)
**我理解的架构**:
[组件A] ──HTTP──▶ [组件B] ──SQL──▶ [组件C]
**布局方向**: 左→右 / 上→下
**需要标注的协议/端口**: HTTP :443, PostgreSQL :5432
这样画可以吗?还是有什么要调整的?
确认后直接进入 Phase 2(跳过 Phase 1 的复杂布局规划,用默认布局)。
不经过 Phase 1 规划时,使用以下默认值:
| 参数 | 默认值 |
|---|---|
| 布局方向 | 左→右(从左到右数据流) |
| 画布 | viewBox="0 0 1000 680" |
| 组件尺寸 | 标准 110×60px |
| 水平间距 | 100px |
| 垂直对齐 | 所有组件垂直居中(y 相同) |
| Header | 从用户请求中提取关键词作为标题 |
| 摘要卡片 | 全部省略(Quick Mode 不生成摘要卡片,保持简洁) |
适用场景:组件 > 5 个、大型系统、描述模糊、需要梳理、多子系统、企业级架构。
关键原则:在生成任何 SVG 代码之前,必须通过多轮对话精确理解系统架构。 根据用户初始描述的详细程度,自动判断需要深入哪些轮次。 如果用户已经提供了非常详细的描述,可以跳过部分轮次并直接确认。
目标:确定架构的顶层模式和边界。
向用户提问(根据已有信息选择性提问,不要全部抛出):
系统类型:这是什么类型的系统?
规模感:系统的规模大约多大?
目标受众:这张图给谁看?
侧重点:用户最关心哪个维度?
输出:1-2 句话的系统概要 + 架构模式标签。
目标:穷举所有组件,不遗漏。
根据 Round 1 的系统类型,引导用户分层列出组件:
📋 组件清单模板:
[客户端层]
- 组件名 | 技术栈 | 关键信息(URL/端口/协议)
[接入层]
- CDN / WAF / API Gateway / Load Balancer | 技术选型 | 配置要点
[应用层]
- 每个服务/模块 | 语言/框架 | 端口/协议 | 扩缩容策略
[数据层]
- 数据库类型 | 具体产品 | 用途 | 高可用方案
- 缓存 | 消息队列 | 对象存储
[基础设施层]
- 云平台/自建 | 区域 | 编排工具 | 监控告警
[外部依赖]
- 第三方 API | 身份提供商 | 支付网关 | 邮件服务
交互策略:
输出:完整的组件表格,每个组件标注:名称、类型、技术栈、备注。
目标:精确理解组件间的连接关系。
对 Round 2 的每个组件,逐一确认:
交互策略:
输出:连接关系列表,每条标注:from → to | 协议 | 认证 | 备注。
目标:理解运行环境的物理/虚拟拓扑。
仅在 Round 1 确认需要展示部署拓扑时深入:
输出:基础设施上下文摘要。
目标:明确信任域和隔离边界。
输出:安全边界列表 + 安全组标记位置。
在进入 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 0 的发现结果,在生成代码前先规划布局。 Quick Mode 跳过此阶段,使用默认布局参数(左→右,组件垂直居中)。
根据系统类型自动选择最佳布局:
| 系统类型 | 推荐布局 | 说明 |
|---|---|---|
| Web 应用(前后端) | 左→右 | 客户端在左,逐步向右到数据层 |
| 微服务系统 | 左→右 + 分层 | 入口层→业务服务层→数据层 |
| 数据管道/ETL | 左→右 | Source→Transform→Sink 线性流 |
| 云基础设施 | 自由分组 | 按 VPC/子网/区域分组 |
| 事件驱动 | 上→下 | Producer→Bus→Consumer 流 |
| 安全架构 | 洋葱模型 | 外层→内层信任域递增 |
画布宽度 = max(1000, 组件列数 × 180 + 边距 × 2)
画布高度 = max(680, 组件行数 × 100 + 边界框高度 + 图例高度 + 边距)
按组件类型自动分配(参见 Design System 章节的颜色表):
从 resources/template.html 获取基础模板,然后:
<title> 和 Header 文字viewBox 尺寸(根据 Phase 1 计算)id="report-container" 在外层容器.toolbar 和相关 JS 导出函数生成 HTML 后,逐项检查。Quick Mode 只需检查标有 ⚡ 的项目(核心项),Deep Mode 需全部检查。
fill="#0f172a" 底层 rect 遮蔽穿透的箭头overflow-x: auto,小屏可横向滚动以下设计规范继承自上游 Cocoon AI v1.1,保持不变。
| Component Type | Fill (rgba) | Stroke |
|---|---|---|
| Frontend | rgba(8, 51, 68, 0.4) | #22d3ee (cyan-400) |
| Backend | rgba(6, 78, 59, 0.4) | #34d399 (emerald-400) |
| Database | rgba(76, 29, 149, 0.4) | #a78bfa (violet-400) |
| AWS/Cloud | rgba(120, 53, 15, 0.3) | #fbbf24 (amber-400) |
| Security | rgba(136, 19, 55, 0.4) | #fb7185 (rose-400) |
| Message Bus | rgba(251, 146, 60, 0.3) | #fb923c (orange-400) |
| External/Generic | rgba(30, 41, 59, 0.5) | #94a3b8 (slate-400) |
#020617 (slate-950) + 40px 网格rx="6", 1.5px stroke, 半透明 fillstroke-dasharray="4,4", 透明 fill, rose 色stroke-dasharray="8,4", amber 色, rx="12"<marker> 箭头, #64748b 颜色stroke-dasharray="5,5", rose 色箭头在 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"/>
用户提出修改需求时,按以下优先级处理:
| 修改类型 | 示例 | 处理方式 |
|---|---|---|
| 增删组件 | "加一个 Redis 缓存" | 重新计算受影响区域的坐标 |
| 修改连接 | "API 不直连 DB,走 DAO 层" | 调整箭头路径 |
| 样式调整 | "把 Frontend 改成蓝色" | 修改颜色常量 |
| 布局调整 | "数据库放到底部" | 局部重新布局 |
| 标注修正 | "端口号不对,应该是 8080" | 修改文本内容 |
重要: 修改后必须重新执行 Phase 3 的间距和重叠检查。
cp -r architecture-diagram/ ~/.claude/skills/architecture-diagram/
下载 architecture-diagram.zip 并通过 Skills 面板上传。
Quick Mode(快速出图):
Deep Mode(深度梳理):
参考 examples/ 目录下的示例 HTML 文件:
web-app.html — Web 应用三层架构aws-serverless.html — AWS Serverless 架构microservices.html — 微服务 + Kubernetes 架构本 skill 基于 Cocoon AI 的 architecture-diagram-generator (MIT License) 深度优化。
v2.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 直接重构一个适配版本。
三种路子获得架构描述:
然后把描述贴进对话,加一句"用你的架构图 Skill 生成一张架构图",Codex/Claude 返回 HTML 文件。想改图直接在聊天里说"把 Redis 挪到消息队列旁边"或"加一层 CDN"就行。
✅ 擅长:软件架构、云基础设施、微服务拓扑等有明确层次和连接关系的图 ❌ 不适合:物理硬件图、流程图(流程图的姐妹项目 process-flow-diagram-generator 同作者出品)
写代码、想设计、或者干脆摸鱼,都比调箭头颜色有意义。