# Architecture Diagrams > 当用户需要系统拓扑、技术架构、部署结构、物理架构、节点关系、网络分区、流量路径或环境结构等架构图时使用此 skill。除非用户明确只要其中一种，否则默认同时输出物理架构图和部署架构图。 - Skill: `reaperhero/architecture-diagrams` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add reaperhero/architecture-diagrams` - Raw SKILL.md: https://api.skillmd.com/api/skills/reaperhero/architecture-diagrams/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: reaperhero (https://skillmd.com/u/reaperhero) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/reaperhero/architecture-diagrams --- # 架构图 ## 概述 当用户需要的是架构图，而不是纯文字说明时，使用这个 skill。默认交付物是一组双图：一张物理架构图，一张部署架构图。 ## 输出约定 除非用户明确排除，否则始终同时提供： - 一张 `物理架构图` - 一张 `部署架构图` 每张图都应当能够独立阅读，命名保持一致，结构清晰。如果输入资料不完整，应做最小且合理的假设，并明确标注这些假设，同时保持两张图内部一致。 ## 推荐格式 - 文字版架构图默认优先使用 Mermaid - 除非结构明显更适合纵向排布，否则使用 `flowchart LR` - 节点标签中如果有空格或标点，使用带引号的写法 - 节点文字应尽量简短，保证可读性 - 需要时按区域、主机、集群、环境或网络边界分组 - 明确表示流量方向和关键依赖关系 如果用户要求输出图片文件，先草拟 Mermaid 结构，再生成图片。最终输出前要检查每个标签是否放得进节点、是否正常换行、是否存在重叠。 ## 图片输出规则 当任务需要输出图片文件时，除非用户明确指定其他要求，否则遵循以下默认规则： - 优先使用 `PNG` - 图片默认保存到 `/Users/edy/Downloads/AI/images` - 保存前如果目录不存在，先创建目录 - 文件名使用有语义的英文名，必要时附加日期或时间戳避免覆盖 - 在回复中始终返回图片的绝对路径 - 图片中不要加入来源说明或参考资料备注 对于带框和文字的架构图： - 所有文字都必须在框内 - 默认开启自动换行 - 避免文字重叠、截断、过密、压线或超出画布 在输出任何已经排版完成的图片前，必须先自检。如果发现文字过密、重叠、越界或难以辨认，先调整字号、行高、卡片高度、间距或画布尺寸，再输出最终结果。 ## 图的职责 ### 物理架构图 这张图用于表现系统由什么组成，以及这些组件“位于哪里”。 应优先包含这些与物理或基础设施相关的元素： - 用户、客户端或边缘入口 - CDN、WAF、负载均衡、网关或 Ingress - VPC、子网、可用区、机房、办公室、机架、主机、虚拟机或裸金属分组 - Kubernetes 集群、节点或服务器组 - 数据库、缓存、消息队列、对象存储和第三方依赖 - 关键网络链路与安全边界 重点是拓扑和位置关系，不要在这张图里堆太多发布流程细节。 ### 部署架构图 这张图用于表现软件是如何部署、组织和运行的。 应优先包含这些与部署相关的元素： - 环境，如开发、测试、预发、生产 - 区域、集群、命名空间、节点池或宿主机 - 可部署单元，如服务、Pod、容器、Job 或 Sidecar - 部署控制器、CI/CD 路径、镜像仓库、配置源或密钥源 - 对运行时真正重要的服务间调用关系 - 当高可用或扩缩容会影响部署理解时，也应表示出来 重点是运行时落位和发布结构。除非某些物理细节会影响部署理解，否则不要机械重复物理图里的全部内容。 ## 工作流 ### 1. 提取架构名词 优先识别： - 流量入口 - 核心服务 - 数据存储 - 基础设施边界 - 环境 - 部署目标 - 外部系统 在画图前先统一命名。同一个组件尽量只保留一个标准名称。 ### 2. 区分物理视角与部署视角 对每个元素都先判断： - 它更偏向“系统位于哪里”或“跨越了什么网络边界” - 还是更偏向“软件如何被打包、部署、扩缩容和发布” 只有在确实有助于理解时，才让同一个概念同时出现在两张图里。 ### 3. 降低杂乱度 - 如果多个节点在当前抽象层级上是等价的，可以合并 - 省略对当前目标没有帮助的实现细节 - 一条清晰的连线优先于多条冗余连线 - 每张图只保留最小但真实的系统切片 ### 4. 标注假设 当信息不足时，在图后补一个简短的 `假设说明` 列表。保持短小、具体、可核对。 ## 质量标准 在最终输出前，检查以下内容： - 两张图都已提供 - 两张图中的命名保持一致 - 箭头方向清晰 - 需要强调的网络边界或环境边界已体现 - 关键数据存储和外部依赖没有脱离上下文悬空出现 - 部署图体现了可部署单元，而不是简单复制物理图的盒子 - 物理图体现了拓扑，而不是只列服务名 ## 提示词示例 - `使用 $architecture-diagrams 绘制当前系统，并同时输出物理架构图和部署架构图。` - `使用 $architecture-diagrams，基于这份服务清单和部署说明输出两张架构图。` - `使用 $architecture-diagrams，把这份 README 转成物理架构图和部署架构图。` ## 资源 - 当系统规模较大、输入较混乱或抽象层级不清晰时，读取 [references/diagram-rules.md](references/diagram-rules.md)