图表不是把文字塞进方框：一个 SVG Skill 如何把“画图”工程化

架构图、流程图和时序图看起来是简单产物，真正难的是信息层级、布局选择与最终导出的一致性。baoyu-diagram不只是一段让模型“画图”的提示词，它把图表类型、设计规范、布局逻辑和 SVG 转 PNG 的后处理放在了一条生产链上。

下面保留原始 Skill 及完整拆解；如果目标是长内容的单张视觉总结，可转到 baoyu-infographic。

---

Skill 详解:baoyu-diagram(专业 SVG 图表生成)

• 来源仓库:JimLiu/baoyu-skills —— 独立开发者 JimLiu 维护的 "baoyu-skills" 系列 Claude/Codex skill 合集
• 版本:1.117.3(版本号迭代次数很高,说明这是一个长期打磨、持续修订的 skill)
• 文件构成:
  baoyu-diagram/ ├── SKILL.md # 主流程 + 设计系统规范 ├── references/ │ ├── architecture.md # 架构图专用布局指南 │ ├── flowchart.md # 流程图专用布局指南 │ ├── sequence.md # 时序图专用布局指南 │ └── structural.md # 结构图(类图/ER图/组织架构图)专用布局指南 └── scripts/ └── main.ts # SVG → @2x PNG 转换脚本(基于 bun + sharp)

一、Frontmatter 元信息(原文)

--- name: baoyu-diagram description: Create professional, dark-themed SVG diagrams of any type — architecture diagrams, flowcharts, sequence diagrams, structural diagrams, mind maps, timelines, illustrative/conceptual diagrams, and more. Use this skill whenever the user asks for any kind of technical or conceptual diagram, visualization of a system, process flow, data flow, component relationship, network topology, decision tree, org chart, state machine, or any visual representation of structure/logic/process. Also trigger when the user says "画个图" "画一个架构图" "diagram" "flowchart" "sequence diagram" "draw me a ..." or uploads content and asks to visualize it. Output is always a standalone .svg file. version: 1.117.3 ---

触发范围非常广:凡是"画个图""架构图""流程图""时序图""帮我可视化一下""上传内容要求可视化"等,只要是技术/概念类图形需求都会命中。输出物固定是一个独立的.svg文件(且会附带自动生成的 @2x PNG)。

二、SKILL.md 全文原文(中文翻译)

以下为源文件SKILL.md的完整中文翻译,原文为英文,可在 JimLiu/baoyu-skills 仓库 查看。为便于理解,颜色代码、CSS/SVG 语法、文件路径占位符等技术符号保留原样未译。

# 图表生成器 面向多种图表类型,生成专业的 SVG 图表。所有输出物都是一个内嵌样式和字体、自包含的单一 `.svg` 文件。 ## 支持的图表类型 | 类型 | 使用场景 | 关键特征 | |------|-------------|-------------------| | **架构图** | 系统组件及其关系 | 分组方框、连接箭头、区域边界 | | **流程图** | 决策逻辑、流程步骤 | 决策菱形、圆角步骤框、方向性流程 | | **时序图** | 参与者之间按时间排序的交互 | 垂直生命线、水平消息、激活条 | | **结构图** | 类图、ER 图、组织架构图 | 分区方框、带类型的关系(继承、组合) | | **思维导图** | 头脑风暴、主题探索 | 中心节点、放射状分支、有机布局 | | **时间轴** | 按时间顺序排列的事件 | 水平/垂直轴线、事件标记、时段跨度 | | **概念图** | 概念性说明、对比 | 自由式布局、图标、注释、视觉隐喻 | | **状态机** | 状态转移、生命周期 | 圆角状态节点、带标签的转移、起止标记 | | **数据流** | 数据转换管线 | 处理气泡、数据存储、外部实体 | ## 设计系统 ### 配色方案 面向组件类别的语义化配色: | 类别 | 填充色(rgba) | 描边色 | 用途 | |----------|-------------|--------|---------| | Primary(主色) | `rgba(8, 51, 68, 0.4)` | `#22d3ee`(青色) | 前端、面向用户、输入 | | Secondary(次色) | `rgba(6, 78, 59, 0.4)` | `#34d399`(翠绿) | 后端、服务、处理逻辑 | | Tertiary(第三色) | `rgba(76, 29, 149, 0.4)` | `#a78bfa`(紫罗兰) | 数据库、存储、持久化 | | Accent(强调色) | `rgba(120, 53, 15, 0.3)` | `#fbbf24`(琥珀) | 云、基础设施、区域 | | Alert(警示色) | `rgba(136, 19, 55, 0.4)` | `#fb7185`(玫瑰红) | 安全、错误、警告 | | Connector(连接色) | `rgba(251, 146, 60, 0.3)` | `#fb923c`(橙色) | 总线、队列、中间件 | | Neutral(中性色) | `rgba(30, 41, 59, 0.5)` | `#94a3b8`(石板灰) | 外部、通用、未知 | | Highlight(高亮色) | `rgba(59, 130, 246, 0.3)` | `#60a5fa`(蓝色) | 活跃状态、焦点、当前步骤 | 对于流程图和时序图,应按"角色"(参与者、决策、流程)而不是按"技术类型"来分配颜色。 ### 字体排版 使用内嵌的 SVG `@font-face`,或回退到系统等宽字体: ​```svg <style> @import url('https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;500;600;700&display=swap'); text { font-family: 'JetBrains Mono', 'SF Mono', 'Cascadia Code', monospace; } </style> ​``` 按角色划分字号: - **标题(Title):** 16px,字重 700 - **组件名称:** 11-12px,字重 600 - **子标签/说明文字:** 9px,字重 400,颜色 `#94a3b8` - **注释/备注:** 8px,字重 400 - **箭头上的小标签:** 7-8px ### 核心视觉元素 **背景:** `#0f172a`(石板色-900),叠加一层不明显的网格纹理(40×40 网格单元,描边色 `#1e293b`,线宽 0.5)。 **箭头标记(marker):** 分为三种——standard(`#64748b` 实心三角)、colored(按类别配色的实心三角)、open(线框三角,用于异步/返回消息)。 ### SVG 结构与图层顺序 按以下顺序绘制各元素,以获得正确的图层叠放顺序(SVG 是按"从后到前"的顺序绘制的): 1. 背景填充 + 网格纹理 2. 区域/分组边界(虚线轮廓) 3. 连接箭头与线条 4. 不透明遮罩矩形(与组件方框位置相同,`fill="#0f172a"`) 5. 组件方框(半透明填充 + 描边) 6. 文字标签 7. 图例(右下角或底部区域,置于所有边界之外) 8. 标题区块(左上角) "不透明遮罩矩形"这个技巧必不可少——如果没有它,半透明的组件填充色会让底下的箭头透出来。 ### 间距规则 这些规则用于防止元素重叠——必须严格遵守: - **组件方框高度:** 50-70px(标准),80-120px(大型/复杂) - **组件之间的最小间距:** 垂直方向 40px,水平方向 30px - **箭头标签留白:** 距任意方框边缘 10px - **区域边界内边距:** 内部组件与边界之间留 20px - **图例位置:** 至少在图表最下方元素下方留 20px - **标题区块:** 距左上角 20px,置于图表内容区域之外 - **viewBox:** 始终扩展到能容纳所有内容,并在四周留 30px 内边距 ### 组件样式模板 包含四类可直接复用的 SVG 代码片段:**标准服务/流程方框**(带遮罩层+可见层双层结构)、**决策菱形**(流程图用)、**数据库圆柱体**(椭圆+矩形拼接)、**区域边界虚线框**(带标签)、**安全组虚线框**(玫瑰色,细虚线)。 ## 按图表类型划分的布局指南 先确定本 `SKILL.md` 文件所在目录为 `{baseDir}`。在开始布局之前,先读取对应图表类型的参考文件。参考文件位于 `{baseDir}/references/` 下,包含详细的布局算法和示例。 ### 架构图 → 读取 `{baseDir}/references/architecture.md` 要点:数据流方向选左到右或上到下之一。把相关的服务用区域边界框在一起。层与层之间使用总线/连接器。数据库放在底部或右侧。 ### 流程图 → 读取 `{baseDir}/references/flowchart.md` 要点:主流程方向为从上到下。决策用菱形表示,出口箭头上标注"是/否"。起止节点用圆角矩形。用高亮色(Highlight)标出"快乐路径"(happy path,即最常见的正常流程)。 ### 时序图 → 读取 `{baseDir}/references/sequence.md` 要点:参与者用方框放在顶部,垂直虚线作为生命线,消息用水平箭头表示(实线=同步调用,虚线=返回)。时间从上往下流动。激活条表示正在处理。复杂场景下给消息编号。 ### 结构图 → 读取 `{baseDir}/references/structural.md` 要点:分区方框(类图为:类名/属性/方法三段)。关系线:实线+实心菱形=组合关系,实线+空心菱形=聚合关系,虚线箭头=依赖关系,实心三角形=继承关系。 ### 思维导图 从中心概念向外放射的自由式布局。分支用有机曲线(带三次贝塞尔曲线的 `<path>`)绘制。用调色板中的不同颜色区分各分支。中心节点字号最大,越往外字号递减。 ### 时间轴 一条水平或垂直的轴线。事件标记为轴线上的圆形或菱形。说明文字在轴线两侧交替偏移,以避免重叠。用颜色对事件类型分类。 ### 状态机 状态用圆角矩形表示,复合状态用双线边框。初始状态用实心圆表示,终止状态用"靶心"图案表示。自我转移用弧形箭头。所有转移都用 `事件 [守卫条件] / 动作` 的格式标注。 ## 输出规则 1. 输出**单一的 `.svg` 文件**——除了 Google Fonts 的引入之外,不依赖任何外部资源 2. 设置 `viewBox` 以容纳所有内容并留出 30px 内边距;**不要**设置固定的 `width`/`height` 属性(让 SVG 能够响应式缩放) 3. 在根 `<svg>` 元素上加入 `xmlns="http://www.w3.org/2000/svg"` 4. 把所有的 `<style>`、`<defs>`、marker 和 pattern 都放在 SVG 的最前面 5. 居中的标签使用 `text-anchor="middle"`;确保文字不会溢出方框 6. **中文文本支持:** 当标签包含中文字符时,使用 `font-family: 'JetBrains Mono', 'Noto Sans SC', 'PingFang SC', sans-serif'`,并加宽方框——因为中日韩(CJK)字符本身更宽 7. **保存位置:** 如果输入是某个文件,则保存到 `{inputFileDir}/diagram/` 下;否则保存到 `{projectDir}/diagram/{topic-slug}/` 下。如果目录不存在则创建 ## 脚本 先确定本 `SKILL.md` 文件所在目录为 `{baseDir}`。脚本路径为:`{baseDir}/scripts/main.ts`。 解析 `${BUN_X}` 运行时:如果已安装 `bun` → 用 `bun`;如果有 `npx` 可用 → 用 `npx -y bun`;否则建议用户安装 bun。 ### SVG → @2x PNG 保存好 SVG 之后,将其转换为 @2x 倍图的 PNG: ​```bash ${BUN_X} {baseDir}/scripts/main.ts <svg-path> [options] ​``` 参数选项: - `-s, --scale <n>` — 缩放倍数(默认:2) - `-o, --output <path>` — 自定义输出路径(默认:`<输入文件名>@2x.png`) - `--json` — 以 JSON 格式输出 ## 处理流程 1. 从用户的需求中识别出图表类型 2. 如果该类型存在对应的参考文件,读取它 3. 规划布局:列出所有组件、确定分组与流向、计算坐标位置 4. 按照上文的图层顺序编写 SVG 5. 核查间距规则——无重叠、图例在边界之外、viewBox 足够大 6. 保存 SVG 文件 7. 运行 `${BUN_X} {baseDir}/scripts/main.ts <svg-path>` 生成 @2x 倍图 PNG 8. 把 SVG 和 PNG 两个文件都交付给用户

三、四份 references 参考文件全文

3.1references/architecture.md(架构图布局指南)

# Architecture Diagram Layout ## Flow Direction Choose one primary direction: - **Left-to-Right (LTR):** Best for data pipelines, request flows. Users/clients on left, data stores on right. - **Top-to-Bottom (TTB):** Best for layered architectures. Clients at top, infrastructure at bottom. ## Layout Algorithm 1. **Identify layers:** Group components by role (clients, gateways, services, data, infrastructure) 2. **Assign columns (LTR) or rows (TTB):** One layer per column/row 3. **Within each layer:** Stack components vertically (LTR) or horizontally (TTB), 40px gap minimum 4. **Region boundaries:** Draw around groups that share infrastructure (e.g., "AWS us-east-1", "Kubernetes Cluster") 5. **Connectors:** Route arrows between layers. For buses/queues between layers, place a thin connector bar in the gap. ## Typical Layer Structure (LTR) Column spacing: 200-220px between column starts. Adjust if components are wider. ## Typical Layer Structure (TTB) Row spacing: 120-140px between row starts. ## Connection Routing - Prefer straight horizontal or vertical lines - For connections that would cross components, use two-segment (L-shaped) paths - For busy diagrams, use `stroke-opacity="0.6"` on less important connections - Label important connections with a text element near the midpoint ## Message Bus / Event Bus Pattern When services communicate through a shared bus, draw it as a horizontal bar between the service layer. Use the Connector color (orange) for the bus bar. ## Multi-Region / Multi-Cloud Nest region boundaries: - Outer boundary: Cloud provider (AWS, GCP) - Inner boundary: Region or VPC - Innermost: Availability zones or subnets Use different dash patterns to distinguish nesting levels: - Outer: `stroke-dasharray="12,4"` - Middle: `stroke-dasharray="8,4"` - Inner: `stroke-dasharray="4,4"`

（含完整 ASCII 布局示意图与 SVG 代码,原文见本地文件references/architecture.md）

3.2references/flowchart.md(流程图布局指南)

# Flowchart Layout ## Shape Vocabulary | Shape | Meaning | SVG Element | |-------|---------|-------------| | Rounded rect (large radius) | Start / End | `<rect rx="25">` | | Rectangle | Process / Action | `<rect rx="6">` | | Diamond | Decision | `<polygon>` rotated 45° | | Parallelogram | Input / Output | `<polygon>` with skew | | Cylinder | Data store | Ellipse + rect combo | ## Flow Direction Primary flow: **top to bottom**. Branch flows go left/right from decisions. ## Layout Algorithm 1. **Identify the main path** (happy path / most common flow) — this runs straight down the center 2. **Branch from decisions:** "Yes" continues down center, "No" branches right (or left if space is tight) 3. **Merge paths:** Route branches back to the main path using L-shaped connectors 4. **Loop-backs:** Route upward on the far left/right side of the diagram with curved paths ## Spacing - Step-to-step vertical gap: 60-80px - Decision diamond height: 70px / width: 100px (point to point) - Branch horizontal offset: 200px from center - Merge connector clearance: 20px from any box ## Decision Labels Place "Yes" / "No"（或“是”/“否”）labels directly on the exit arrows, 10px from the diamond edge. ## Coloring Strategy - **Start/End nodes:** Highlight color (blue) - **Process steps:** Primary (cyan) or Secondary (emerald) - **Decision diamonds:** Accent (amber) — they draw the eye naturally - **Error/exception paths:** Alert (rose) dashed arrows - **Happy path arrows:** Slightly brighter than branch arrows (`stroke-opacity` difference) ## Complex Flowcharts For flowcharts with 10+ steps: - Group related steps into swim lanes (vertical columns with header bars) - Add a "phase" row header at the top of each swim lane - Use the region boundary pattern from Architecture for swim lanes

3.3references/sequence.md(时序图布局指南)

# Sequence Diagram Layout ## Core Elements | Element | Visual | Description | |---------|--------|-------------| | Actor/Participant | Box at top + dashed vertical lifeline | Each entity in the interaction | | Sync message | Solid arrow → | Request or call | | Async message | Open arrowhead → | Fire-and-forget | | Return message | Dashed arrow ← | Response | | Activation bar | Narrow filled rect on lifeline | Entity is processing | | Self-message | Arrow looping back to same lifeline | Internal processing | | Note | Rounded rect with folded corner | Annotation | | Alt/Opt frame | Dashed boundary with label tab | Conditional block | | Loop frame | Dashed boundary with "loop" tab | Repetition | ## Layout Algorithm 1. **Place actors** horizontally across the top, evenly spaced (150-200px apart) 2. **Draw lifelines** as vertical dashed lines from each actor box downward 3. **Place messages** as horizontal arrows between lifelines, top to bottom in time order 4. **Vertical spacing** between messages: 40-50px 5. **Activation bars:** 10px wide, centered on lifeline, spanning from incoming to outgoing message ## Numbering For complex sequences (8+ messages), number each message with a small circled index badge. ## Color Assignment Assign each actor a distinct color from the palette. Use that color for actor box stroke, activation bar on that lifeline, and (optionally) outgoing arrows from that actor.

（消息箭头、激活条、alt/loop 条件帧的具体 SVG 代码原文见本地文件）

3.4references/structural.md(结构图:类图/ER图/组织架构图)

# Structural Diagram Layout Covers: class diagrams, ER diagrams, component diagrams, package diagrams, org charts. ## Class Diagram ### Class Box (3-compartment) 三段式结构:类名 / 属性(attributes) / 方法(methods),用分隔线隔开。抽象类名用斜体,接口在类名上方加 «interface» 小字标注。 ### Relationship Lines | Relationship | Line Style | Arrow/End | |-------------|------------|-----------| | Inheritance | Solid | Empty triangle (▷) pointing to parent | | Implementation | Dashed | Empty triangle pointing to interface | | Composition | Solid | Filled diamond (◆) at owner end | | Aggregation | Solid | Empty diamond (◇) at owner end | | Dependency | Dashed | Open arrowhead at dependency target | | Association | Solid | Open arrowhead or none | ### Cardinality Labels Place at each end of the relationship line, offset 5-8px from the box edge (e.g. `1..*`). ## ER Diagram Similar to class diagrams but: - Use 2-compartment boxes (entity name + attributes) - Mark primary keys with `PK` prefix and bold - Mark foreign keys with `FK` prefix - Relationship lines use crow's foot notation ## Org Chart - Top-down tree layout - Root at top center - Each level evenly spaced (100-120px vertical gap) - Siblings evenly distributed horizontally - Connection lines: vertical from parent bottom center to horizontal bar, then vertical down to each child top center - Use color to indicate departments or hierarchy levels ## Layout Tips - Start by counting the widest level to determine total diagram width - Center the tree horizontally in the viewBox - For deep trees (5+ levels), consider horizontal layout instead

四、scripts/main.ts全文原文(Bun/TypeScript 脚本)

#!/usr/bin/env bun import { existsSync, readFileSync, mkdirSync } from "fs"; import { basename, dirname, extname, join, resolve } from "path"; interface Options { input: string; output?: string; scale: number; json: boolean; } function parseViewBox(svg: string): { width: number; height: number } | null { const vb = svg.match(/viewBox\s*=\s*"([^"]+)"/); if (vb) { const parts = vb[1].split(/[\s,]+/).map(Number); if (parts.length >= 4 && parts[2] > 0 && parts[3] > 0) return { width: parts[2], height: parts[3] }; } const w = svg.match(/\bwidth\s*=\s*"(\d+(?:\.\d+)?)"/); const h = svg.match(/\bheight\s*=\s*"(\d+(?:\.\d+)?)"/); if (w && h) return { width: Number(w[1]), height: Number(h[1]) }; return null; } function getOutputPath(input: string, scale: number, custom?: string): string { if (custom) return resolve(custom); const dir = dirname(input); const base = basename(input, extname(input)); const suffix = scale === 1 ? "" : `@${scale}x`; return join(dir, `${base}${suffix}.png`); } async function convert(input: string, opts: Options): Promise<{ output: string; width: number; height: number }> { const svg = readFileSync(input); const svgStr = svg.toString("utf-8"); const dims = parseViewBox(svgStr); if (!dims) throw new Error("Cannot determine SVG dimensions from viewBox or width/height attributes"); const width = Math.round(dims.width * opts.scale); const height = Math.round(dims.height * opts.scale); const sharp = (await import("sharp")).default; const output = getOutputPath(input, opts.scale, opts.output); mkdirSync(dirname(output), { recursive: true }); await sharp(svg, { density: 72 * opts.scale }) .resize(width, height) .png() .toFile(output); return { output, width, height }; } function printHelp() { console.log(`Usage: bun main.ts <input.svg> [options] Convert SVG to @2x PNG. Options: -o, --output <path> Output path (default: <input>@2x.png) -s, --scale <n> Scale factor (default: 2) --json JSON output -h, --help Show help`); } function parseArgs(args: string[]): Options | null { const opts: Options = { input: "", scale: 2, json: false }; for (let i = 0; i < args.length; i++) { const arg = args[i]; if (arg === "-h" || arg === "--help") { printHelp(); process.exit(0); } else if (arg === "-o" || arg === "--output") opts.output = args[++i]; else if (arg === "-s" || arg === "--scale") { const s = Number(args[++i]); if (isNaN(s) || s <= 0) { console.error(`Invalid scale: ${args[i]}`); return null; } opts.scale = s; } else if (arg === "--json") opts.json = true; else if (!arg.startsWith("-") && !opts.input) opts.input = arg; } if (!opts.input) { console.error("Error: Input SVG file required"); printHelp(); return null; } return opts; } async function main() { const opts = parseArgs(process.argv.slice(2)); if (!opts) process.exit(1); const input = resolve(opts.input); if (!existsSync(input)) { console.error(`Error: ${input} not found`); process.exit(1); } if (extname(input).toLowerCase() !== ".svg") { console.error("Error: Input must be an SVG file"); process.exit(1); } try { const r = await convert(input, opts); if (opts.json) console.log(JSON.stringify({ input, ...r }, null, 2)); else console.log(`${input} → ${r.output} (${r.width}×${r.height})`); } catch (e) { console.error(`Error: ${(e as Error).message}`); process.exit(1); } } main();

脚本逻辑拆解:
1.parseViewBox()优先从 SVG 的viewBox属性解析宽高,拿不到再退化去读width/height属性,都拿不到就抛错——这与 SKILL.md 里"必须设置 viewBox、不要写死 width/height"的规则是配套的。
2.getOutputPath()默认在原 SVG 同目录生成<原文件名>@2x.png,可以通过-o自定义。
3.convert()用sharp库(density: 72 * scale提高栅格化精度)把 SVG 渲染为指定倍数尺寸的 PNG。
4. CLI 参数解析支持-o/--output、-s/--scale(默认2倍)、--json(结构化输出)、-h/--help。
5. 整个脚本设计为可以用bun直接运行(通过 shebang#!/usr/bin/env bun),SKILL.md 里也写明了运行时探测逻辑:优先用已安装的bun,没有则退化用npx -y bun,再没有就提示用户安装 bun。

五、设计系统与实现原理综合说明

baoyu-diagram是本次盘点中工程化程度最高的 skill,体现在:

1. 强约束的暗色系设计系统:固定背景色#0f172a(slate-900)+ 网格纹理,固定 8 种语义化配色(Primary/Secondary/Tertiary/Accent/Alert/Connector/Neutral/Highlight),每种配色对应固定的语义用途(比如 Primary=前端/用户侧,Tertiary=数据库,Alert=安全/错误),而不是让 AI 每次随意选色,这保证了不同图表之间风格高度一致。

2. "遮罩矩形"这一 SVG 技巧被显式强调为"必不可少":由于组件方框用的是半透明填充色,如果不在方框下方先画一个同尺寸的不透明#0f172a矩形做"遮罩层",连线箭头就会透过方框显现出来,破坏视觉效果。这是一条容易被忽略但对最终成品质量影响很大的实现细节。

3. 分文件的类型特化知识:SKILL.md 本身只放通用的设计系统规范和精简版的分类型要点,具体的布局算法、间距规则、SVG 代码模板被拆分到references/下按图表类型分别存放(架构图/流程图/时序图/结构图),Claude 在实际作图前会按需读取对应的一份参考文件,而不是一次性把所有类型的细节都塞进主文件——这是一种典型的"渐进式加载上下文"设计,避免主 SKILL.md 过于臃肿。

4. 完整的产出流程闭环:识别图表类型 → 读取对应 reference → 规划布局(列组件、定方向、算坐标) → 按固定图层顺序绘制 SVG → 自查间距规则 → 保存 SVG → 调用main.ts脚本生成 @2x PNG → 把 SVG 和 PNG 两个文件都交付给用户。保存路径也有明确规则:如果输入是某个文件,则存到{该文件所在目录}/diagram/下;否则存到{项目目录}/diagram/{主题slug}/下。

5. 中文文本的专门适配:显式提醒当标签含中文字符时,要切换到含Noto Sans SC/PingFang SC的字体栈,并且要加宽方框,因为 CJK 字符本身更宽,这是很多国际化 skill 容易忽略的细节。

六、使用场景

• 用户要求"画个架构图""画一个系统的流程图""帮我画时序图""画个类图/ER图""画个思维导图""画个时间轴""帮我把这段描述可视化"等各类技术或概念图需求。
• 用户上传一段文字/代码/文档,要求"把这个流程可视化""把这个系统架构画出来"。
• 想要统一视觉风格的技术文档配图(比如团队 wiki、README、架构评审材料),因为该 skill 的暗色系 + 固定配色体系保证了多张图表之间风格一致。
• 需要同时拿到矢量图(SVG,可后续编辑/缩放)和位图(@2x PNG,可直接粘贴进 PPT/文档)两种格式的场景。

七、亮点总结

• 全流程工程化:从设计规范 → 分类型知识库 → 实际绘制规则 → 自动化后处理脚本,形成闭环,不依赖用户二次加工。
• "遮罩矩形"技巧、"CJK 加宽" 等细节体现出这是经过大量实战踩坑后沉淀出的经验规则,而不是泛泛的通用指导。
• 版本号高达 1.117.3,说明这是一个被持续快速迭代打磨的成熟 skill。
• 通过参考文件的按需读取机制,在保持主 SKILL.md 精简的同时,支撑了 9 大类图表类型(架构/流程/时序/结构/思维导图/时间轴/概念图/状态机/数据流)的专业化布局指导。