baoyu-diagram
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseDiagram Generator
图表生成器
Write real SVG code directly, following a consistent design system, the output is a single file that is self-contained (embedded styles, auto dark-mode), editable by humans, scales to any size without quality loss, and embeds cleanly into articles, WeChat posts, slide decks, Notion, and markdown.
.svgThis is not an image-generation skill — it does not call any LLM image model. Claude writes the SVG node-by-node, doing the layout math by hand so every diagram honors the rules in .
references/直接编写原生SVG代码，遵循统一的设计系统，输出单个独立的文件（内置样式、自动适配明暗模式），支持人工编辑、无损任意缩放，可完美嵌入文章、公众号推文、幻灯片、Notion、markdown文档中。
.svg这不是图像生成技能——它不会调用任何LLM图像模型。Claude会逐节点编写SVG，手动计算布局，确保所有图表都符合目录下的规范要求。
references/Usage
使用方法
bash
undefinedbash
undefinedPrompt for the topic if no argument given
未提供参数时会询问图表主题
/baoyu-diagram
/baoyu-diagram
Plain-text description
传入纯文本描述
/baoyu-diagram "how JWT authentication works"
/baoyu-diagram "how JWT authentication works"
Path to a markdown file as source content
传入markdown文件路径作为内容来源
/baoyu-diagram path/to/content.md
/baoyu-diagram path/to/content.md
Force a specific diagram type
强制指定图表类型
/baoyu-diagram "transformer attention" --type illustrative
/baoyu-diagram "Kubernetes architecture" --type structural
/baoyu-diagram "CI/CD pipeline" --type flowchart
/baoyu-diagram "OAuth 2.0 flow" --type sequence
/baoyu-diagram "Shape hierarchy" --type class
/baoyu-diagram "transformer attention" --type illustrative
/baoyu-diagram "Kubernetes architecture" --type structural
/baoyu-diagram "CI/CD pipeline" --type flowchart
/baoyu-diagram "OAuth 2.0 flow" --type sequence
/baoyu-diagram "Shape hierarchy" --type class
Language and output path
指定语言和输出路径
/baoyu-diagram "微服务架构" --lang zh
/baoyu-diagram "build pipeline" --out docs/build-pipeline.svg
undefined/baoyu-diagram "微服务架构" --lang zh
/baoyu-diagram "build pipeline" --out docs/build-pipeline.svg
undefinedOptions
可选参数
| Option | Values |
|---|---|
| |
| |
| Output file path (default: |
| 参数 | 可选值 |
|---|---|
| |
| |
| 输出文件路径（默认： |
Diagram types
图表类型
Pick the type by what the reader needs, not by the noun in the prompt.
The primary test: is the reader trying to document this, or understand it? Documentation wants precision — flowchart, sequence, or structural. Understanding wants the right mental model — illustrative.
| Type | Reader need | Route on verbs like | Reference |
|---|---|---|---|
| Flowchart | Walk me through the steps, in order | "walk through", "steps", "process", "lifecycle", "workflow", "state machine", "gate", "router", "parallelization", "orchestrator", "evaluator" | |
| Flowchart (phase band) | Walk me through each phase; show the tools at each stage | "phase 1/2/3", "multi-phase operation", "each phase has tools", "attack phases", "phased workflow", "security operation phases", "penetration test stages", "phase N feeds phase N+1" | |
| Sequence | Who talks to whom, in what order | "protocol", "handshake", "auth flow", "OAuth", "TCP", "TLS", "gRPC", "request/response", "who calls what", "exchange between", "round trip", "webhook" | |
| Structural | Show me what's inside what, how it's organized | "architecture", "organised", "components", "layout", "what's inside", "topology", "subsystem", "two systems", "side by side", "foreground + background" | |
| Illustrative | Give me the intuition — draw the mechanism | "how does X work", "explain X", "I don't get X", "intuition for", "why does X do Y", "LLM with tools", "agent and environment", "central + attachments" | |
| Class | What are the types and how are they related | "class diagram", "UML", "inheritance", "interface", "schema", "types and subtypes", "data model" | |
Routing heuristic: "how does X work" is the default ambiguous case. Prefer illustrative unless the user specifically asks for steps or components. A diagram that makes the reader feel "oh, that's what it's doing" is illustrative — even if the subject is software.
Multi-actor test for sequence: if the prompt names ≥2 distinct actors/participants/services (User + Server, Client + Auth + Resource, Browser + CDN + Origin), prefer sequence even when the verb is "flow" or "process". Single-actor "X flow" (build pipeline, request lifecycle, GC) stays flowchart. When you pick sequence for a multi-actor reason, announce it: "Picked sequence because the prompt names N actors (…). Rerun with to force the step-list version."
--type flowchartWorked examples of verb-based routing: same subject, different diagram depending on what was asked. Use these as a sanity check after picking a type.
| User says | Type | What to draw |
|---|---|---|
| "how do LLMs work" | Illustrative | Token row, stacked layer slabs, attention threads across layers. |
| "transformer architecture / components" | Structural | Labeled boxes: embedding, attention heads, FFN, layer norm. |
| "how does attention work" | Illustrative | One query token, fan of lines to every key, line thickness = weight. |
| "how does gradient descent work" | Illustrative | Contour surface, a ball rolling down, a trail of discrete steps. |
| "what are the training steps" | Flowchart | Forward → loss → backward → update. |
| "how does TCP work" | Illustrative | Two endpoints, numbered packets in flight, an ACK returning. |
| "TCP handshake sequence" | Sequence | SYN → SYN-ACK → ACK between client and server lifelines. |
| "how does a hash map work" | Illustrative | Key falling through a hash function into one of N buckets. |
| "LLM with retrieval, tools, memory" | Illustrative | Central LLM subject with dashed radial spokes to three labeled attachments. |
| "gate pattern with pass/fail exit" | Flowchart | Pill In → LLM → Gate → LLM → LLM → pill Out, with a dashed Fail branch to Exit. |
| "LLM router / parallelization" | Flowchart | Simple fan-out: pill In → hub → 3 branches → aggregator → pill Out. |
| "Pi session + background analyzer" | Structural (subsystem) | Two dashed sibling containers side by side, each with a short internal flow, labeled cross-system arrows. |
| "prompt engineering vs. context engineering" | Structural (subsystem) | Two sibling containers, each showing its internal mechanism with cross-links. |
| "agent + environment loop" | Illustrative | Human pill ↔ LLM rect ↔ Environment pill, Action/Feedback labels on the edges. |
| "Claude Code workflow with sub-loops" | Sequence | 4 actors with 1–2 dashed message frames labeled "Until tests pass" / "Until tasks clear". |
| "generator-verifier loop" | Flowchart | Outer loop container; two boxes with green ✓ / coral ✗ status circles on the return edge. See |
| "from TODOs to tasks" | Structural (subsystem) | Two siblings: left = checklist (checkbox glyphs); right = DAG of task nodes with one dashed future-state node. See |
| "finding the sweet spot" | Illustrative | Horizontal spectrum axis between two opposing labels; option boxes under tick points with the middle one highlighted. See |
| "agent teams with task queue" | Flowchart | Queue glyph inside the lead box, then vertical fan-out to workers. See |
| "message bus architecture" | Structural | Central horizontal bar + agents above/below, each linked by a publish/subscribe arrow pair. See |
| "shared state store" | Structural | Central hub with a doc icon + 4 corner satellites, bidirectional arrow pairs. See |
| "orchestrator vs. agent teams" | Structural (subsystem) | Two siblings; left = hub + fan-out; right = queue + vertical fan-out. See |
| "orchestrator vs. message bus" | Structural (subsystem) | Two siblings; left = hub + fan-out; right = mini bus topology. See |
| "advisor strategy" | Structural | Single container, multi-line box bodies (title/role/meta), mixed solid+dashed+bidirectional arrows with a legend strip. See |
| "tool calling vs. programmatic" | Sequence | Parallel independent rounds — left = stacked rounds; right = stacked rounds wrapped in a tall script box. See |
| "Claude + environment + skill" | Illustrative | Two subject boxes with a bidirectional arrow; annotation circle at the midpoint labels the skill. See |
| "code execution vs. dedicated tool" | Structural (subsystem) | Two siblings; left = Computer box with nested Terminal; right = Claude with an attached gadget box for Tools. See |
| "Shape inheritance / class hierarchy" | Class | 3-compartment rects (name / attrs / methods) with hollow-triangle inheritance arrows. See |
| "order lifecycle / status transitions" | Flowchart (state machine) | State rects + initial/final markers + |
| "network topology (3-tier)" | Structural (network) | Dashed zone containers (Internet / DMZ / Internal) + labeled device rects. See |
| "database comparison matrix" | Structural (matrix) | Header row + zebra-striped body rows with ✓/✗ glyphs in cells. See |
| "multi-phase attack / each phase has tools" | Flowchart (phase band) | Stacked dashed phase bands; compact tool cards with icons in each band; colored cross-band arrows (normal / exploit / findings); operator icons on left. See |
| "phased workflow / phase 1 recon phase 2 exploit" | Flowchart (phase band) | Phase labels as eyebrow text; tool card rows centered in each band; side annotations; legend strip. See |
Most common routing failure: picking a flowchart because it feels safer when an illustrative diagram would give the reader more insight. Illustrative is the more ambitious choice, and almost always the right one when the reader needs understanding rather than documentation.
Cycles, ERDs, and gantt charts are out of scope for v1. For cycles, draw the stages linearly with a small return glyph (see ). For ERDs, suggest a dedicated tool (mermaid, plantuml) — do not attempt to fake them in pure SVG.
↻ returns to startflowchart.md请根据读者的需求选择类型，而非仅根据提示词中的名词选择。
核心判断标准：读者是需要记录文档还是理解原理？文档需要精准性——对应流程图、时序图或结构图。理解需要构建正确的心智模型——对应示意图。
| 类型 | 读者需求 | 匹配动词示例 | 参考文档 |
|---|---|---|---|
| 流程图 | 按顺序梳理流程步骤 | "walk through", "steps", "process", "lifecycle", "workflow", "state machine", "gate", "router", "parallelization", "orchestrator", "evaluator" | |
| 阶段带流程图 | 梳理每个阶段，展示各阶段使用的工具 | "phase 1/2/3", "multi-phase operation", "each phase has tools", "attack phases", "phased workflow", "security operation phases", "penetration test stages", "phase N feeds phase N+1" | |
| 时序图 | 展示不同角色按顺序的交互逻辑 | "protocol", "handshake", "auth flow", "OAuth", "TCP", "TLS", "gRPC", "request/response", "who calls what", "exchange between", "round trip", "webhook" | |
| 结构图 | 展示组件的层级关系、组织架构 | "architecture", "organised", "components", "layout", "what's inside", "topology", "subsystem", "two systems", "side by side", "foreground + background" | |
| 示意图 | 直观解释原理、展示运行机制 | "how does X work", "explain X", "I don't get X", "intuition for", "why does X do Y", "LLM with tools", "agent and environment", "central + attachments" | |
| 类图 | 展示类型定义及相互关系 | "class diagram", "UML", "inheritance", "interface", "schema", "types and subtypes", "data model" | |
匹配规则：「how does X work」属于默认的模糊场景，除非用户明确要求步骤或组件，否则优先选择示意图。能让读者产生「哦，原来它是这么运行的」感知的图表就是示意图——哪怕主题是软件相关内容。
时序图多角色判断规则：如果提示词中提到≥2个不同的角色/参与者/服务（用户+服务器、客户端+认证中心+资源服务、浏览器+CDN+源站），哪怕动词是「flow」或「process」也优先选择时序图。单角色的「X流程」（构建流水线、请求生命周期、垃圾回收）仍属于流程图。当你基于多角色规则选择时序图时，需要告知用户：「选择了时序图，因为提示词中提到了N个角色（…）。如果需要步骤列表版本，可以添加参数重新运行。」
--type flowchart基于动词匹配的实例参考：同一主题根据不同需求会生成不同类型的图表，选择类型后可使用这些示例作为校验标准。
| 用户请求内容 | 类型 | 绘制内容 |
|---|---|---|
| "how do LLMs work" | 示意图 | Token行、堆叠的层块、跨层的注意力线程。 |
| "transformer architecture / components" | 结构图 | 带标签的框：嵌入层、注意力头、FFN、层归一化。 |
| "how does attention work" | 示意图 | 一个查询Token，指向所有Key的扇形连线，线的粗细代表权重。 |
| "how does gradient descent work" | 示意图 | 等高面，向下滚动的小球，离散步骤的轨迹。 |
| "what are the training steps" | 流程图 | 前向传播 → 损失计算 → 反向传播 → 参数更新。 |
| "how does TCP work" | 示意图 | 两个端点，传输中的编号数据包，返回的ACK包。 |
| "TCP handshake sequence" | 时序图 | 客户端和服务器生命线之间的SYN → SYN-ACK → ACK交互。 |
| "how does a hash map work" | 示意图 | Key经过哈希函数落入N个桶中的一个。 |
| "LLM with retrieval, tools, memory" | 示意图 | 中心LLM主体，用虚线放射状连线连接三个带标签的附属模块。 |
| "gate pattern with pass/fail exit" | 流程图 | 输入 → LLM → 门控 → LLM → LLM → 输出，带指向出口的失败虚线分支。 |
| "LLM router / parallelization" | 流程图 | 简单扇出：输入 → 枢纽 → 3个分支 → 聚合器 → 输出。 |
| "Pi session + background analyzer" | 结构图（子系统） | 两个并排的虚线同级容器，每个内部有简短的流程，带跨系统的标签箭头。 |
| "prompt engineering vs. context engineering" | 结构图（子系统） | 两个同级容器，各自展示内部机制，带交叉链接。 |
| "agent + environment loop" | 示意图 | 人 ↔ LLM ↔ 环境，边上标注动作/反馈。 |
| "Claude Code workflow with sub-loops" | 时序图 | 4个角色，1-2个虚线消息框标注「直到测试通过」/「直到任务完成」。 |
| "generator-verifier loop" | 流程图 | 外层循环容器；两个框，返回边上带绿色✓/珊瑚色✗状态圆圈。参考 |
| "from TODOs to tasks" | 结构图（子系统） | 两个同级模块：左侧=待办清单（复选框符号）；右侧=任务节点DAG，带一个虚线的未来状态节点。参考 |
| "finding the sweet spot" | 示意图 | 两个对立标签之间的水平频谱轴；刻度点下方的选项框，中间的选项高亮。参考 |
| "agent teams with task queue" | 流程图 | 领导框内部的队列符号，然后垂直扇出到工作节点。参考 |
| "message bus architecture" | 结构图 | 中心水平条 + 上下方的Agent，每个通过发布/订阅箭头对连接。参考 |
| "shared state store" | 结构图 | 带文档图标的中心枢纽 + 4个角落的附属节点，双向箭头对。参考 |
| "orchestrator vs. agent teams" | 结构图（子系统） | 两个同级模块：左侧=枢纽+扇出；右侧=队列+垂直扇出。参考 |
| "orchestrator vs. message bus" | 结构图（子系统） | 两个同级模块：左侧=枢纽+扇出；右侧=迷你总线拓扑。参考 |
| "advisor strategy" | 结构图 | 单个容器，多行框体（标题/角色/元信息），混合实线+虚线+双向箭头，附带图例条。参考 |
| "tool calling vs. programmatic" | 时序图 | 并行独立轮次——左侧=堆叠轮次；右侧=堆叠轮次包裹在高脚本框内。参考 |
| "Claude + environment + skill" | 示意图 | 两个主体框带双向箭头；中点的注释圆圈标注skill。参考 |
| "code execution vs. dedicated tool" | 结构图（子系统） | 两个同级模块：左侧=计算机框嵌套终端；右侧=Claude附带工具小工具框。参考 |
| "Shape inheritance / class hierarchy" | 类图 | 三格矩形（名称/属性/方法），带空心三角形继承箭头。参考 |
| "order lifecycle / status transitions" | 流程图（状态机） | 状态矩形 + 初始/结束标记 + |
| "network topology (3-tier)" | 结构图（网络） | 虚线区域容器（互联网 / DMZ / 内部网络） + 带标签的设备矩形。参考 |
| "database comparison matrix" | 结构图（矩阵） | 表头行 + 斑马纹内容行，单元格内带✓/✗符号。参考 |
| "multi-phase attack / each phase has tools" | 流程图（阶段带） | 堆叠的虚线阶段带；每个带内的紧凑工具卡带图标；彩色跨带箭头（正常/利用/发现）；左侧的操作员图标。参考 |
| "phased workflow / phase 1 recon phase 2 exploit" | 流程图（阶段带） | 阶段标签作为眉批文本；工具卡行居中在每个带内；侧边注释；图例条。参考 |
最常见的匹配错误：当示意图能给读者带来更多洞察时，出于稳妥选择流程图。示意图是更有价值的选择，当读者需要理解而非文档时，几乎永远是正确选择。
循环图、ERD、甘特图不在v1版本支持范围内。对于循环，可以线性绘制阶段，添加小的返回符号（参考）。对于ERD，建议使用专门工具（mermaid、plantuml）——不要尝试用纯SVG模拟。
↻ returns to startflowchart.mdWorkflow
工作流程
Step 1: Capture intent
步骤1：捕捉意图
Read the user's prompt or content file. If the topic is missing, ask for it with AskUserQuestion.
Before routing, extract these five things from the source:
-
Named elements — list every distinct actor, component, service, state, or phase explicitly named. Count them. If the count is 6+, plan multiple diagrams rather than cramming everything into one (see→ "Planning before you write SVG").
flowchart.md -
Relationship type — for each interaction between elements, classify it:
- Sequential steps / order of operations → flowchart signal
- Containment ("X is inside Y", zones, hierarchies) → structural signal
- Multi-actor message exchange (A sends to B, B replies to C) → sequence signal
- Mechanism ("how does X produce Y") → illustrative signal More than one type present? Pick the dominant one, or plan two diagrams.
-
What the reader needs — complete this sentence before routing: "After seeing this diagram, the reader understands ___." If you can't finish it, the topic is underspecified — ask.
-
Label preview — for each element name, count the characters. Latin titles >30 chars (CJK >16) will overflow a 180-wide box and need shortening. Draft the abbreviated form now, before layout math, so Step 4 uses real labels.
-
Language — CJK vs. Latin. Affects text-width multipliers in Step 4 (15 px/char vs. 8 px/char for titles). Mixed content (CJK labels with some Latin terms) counts as CJK.
阅读用户的提示词或内容文件。如果缺少主题，使用AskUserQuestion询问用户。
匹配类型前，从来源中提取以下5项内容：
-
命名元素——列出所有明确提到的独立角色、组件、服务、状态或阶段。统计数量。如果数量≥6，规划多个图表而非挤在一个里（参考→ 「编写SVG前的规划」）。
flowchart.md -
关系类型——对元素之间的每个交互进行分类：
- 顺序步骤/操作顺序 → 流程图信号
- 包含关系（「X在Y内部」、区域、层级） → 结构图信号
- 多角色消息交互（A发送给B，B回复给C） → 时序图信号
- 运行机制（「X如何生成Y」） → 示意图信号 存在多种类型？选择占主导的类型，或规划两个图表。
-
读者需求——匹配类型前完成这个句子：*「看完这个图表后，读者能理解___。」*如果你没法完成这句话，说明主题不明确——询问用户。
-
标签预览——统计每个元素名称的字符数。拉丁标题>30字符（CJK>16字符）会超出180宽度的框，需要缩短。在布局计算前就草拟缩写形式，确保步骤4使用真实标签。
-
语言——CJK还是拉丁文字。会影响步骤4的文本宽度乘数（标题15px/字符 vs 8px/字符）。混合内容（CJK标签加部分拉丁术语）按CJK计算。
Step 2: Route the diagram type
步骤2：匹配图表类型
Match the user's phrasing to the table above. If is given, use it. Otherwise route on the verb. When genuinely ambiguous between flowchart and illustrative, default to illustrative — the reader almost always benefits more from intuition than from a list of steps.
--typeTell the user which type you picked and why, in one sentence. Do not ask for confirmation — the type can always be changed with on a rerun.
--type将用户的表述与上表匹配。如果提供了参数，直接使用该类型。否则根据动词匹配。如果确实在流程图和示意图之间难以判断，默认选择示意图——读者几乎总能从原理洞察中比步骤列表获益更多。
--type用一句话告知用户你选择的类型及原因。不要请求确认——用户随时可以在重新运行时通过修改类型。
--typeStep 3: Load references
步骤3：加载参考文档
Always read:
- — philosophy, typography, color palette, hard rules
references/design-system.md - — the
references/svg-template.md+<style>boilerplate to copy verbatim<defs> - — text-width estimation, viewBox sizing, arrow routing
references/layout-math.md - — the pre-save checklist
references/pitfalls.md
Read the one that matches the type:
references/flowchart.mdreferences/sequence.mdreferences/structural.mdreferences/illustrative.mdreferences/class.md
Read on demand when the plan calls for a small pictorial element (status circle on a decision branch, checkbox inside a list, queue slot inside a box, doc/terminal/script icon inside a subject, annotation circle on a connector, paired pub/sub arrows, dashed future-state node) or when drawing a phase-band diagram (compact tool card icons, operator icons):
- — the shared glyph library, tool card icon set, operator icons, and dark-mode rules
references/glyphs.md
Read on demand for diagram type extensions:
- — when ≥3 poster-mode triggers fire in Step 4a (topic has a short name, named phases, parallel candidates, a loop termination mechanic, overflow annotations, or a footer quote)
references/flowchart-poster.md - — when the prompt describes a multi-phase sequential operation where each phase contains parallel tools or steps and outcomes propagate between phases ("phase 1/2/3", "attack phases", "phased workflow with tools")
references/flowchart-phase-bands.md - — when drawing network topology: zone containers, wired/wireless device connectivity, security zones (DMZ / VPC / firewall)
references/structural-network.md - — when drawing a comparison matrix: feature table, ✓/✗ cells, side-by-side "option × attribute" grid
references/structural-matrix.md
必须阅读：
- ——设计理念、排版、调色板、硬性规则
references/design-system.md - ——需要直接复制的
references/svg-template.md+<style>模板代码<defs> - ——文本宽度估算、viewBox尺寸计算、箭头路由
references/layout-math.md - ——保存前检查清单
references/pitfalls.md
阅读对应类型的参考文档：
references/flowchart.mdreferences/sequence.mdreferences/structural.mdreferences/illustrative.mdreferences/class.md
按需阅读：当规划需要小型图形元素（决策分支上的状态圆圈、列表内的复选框、框内的队列槽、主体内的文档/终端/脚本图标、连接线上的注释圆圈、成对的发布/订阅箭头、虚线未来状态节点）或绘制阶段带图表（紧凑工具卡图标、操作员图标）时：
- ——共享图形库、工具卡图标集、操作员图标、明暗模式规则
references/glyphs.md
按需阅读图表类型扩展文档：
- ——当步骤4a触发≥3个海报模式条件时（主题有短名称、命名阶段、并行候选、循环终止机制、溢出注释、页脚引用）
references/flowchart-poster.md - ——当提示词描述多阶段顺序操作，每个阶段包含并行工具或步骤，结果在阶段之间传递时（「phase 1/2/3」、「攻击阶段」、「带工具的分阶段工作流」）
references/flowchart-phase-bands.md - ——绘制网络拓扑时：区域容器、有线/无线设备连接、安全区域（DMZ / VPC / 防火墙）
references/structural-network.md - ——绘制对比矩阵时：功能表、✓/✗单元格、并排「选项×属性」网格
references/structural-matrix.md
Step 3.5: Check the patterns library
步骤3.5：检查模式库
If the user's topic matches a known AI-system pattern (multi-agent research, message bus, shared state, agent with skills, contextual retrieval), there is a pre-cooked starter plan in . Scan for a pattern name that matches the prompt. If one matches, load that pattern file and use its mermaid reference + baoyu SVG plan as the starting point for Step 4 — the node list, widths, and arrow routing are already drafted, and you only need to adapt labels.
references/patterns/references/patterns/README.mdIf nothing matches, skip this step and plan from scratch in Step 4. Do not force a near-miss: two patterns that share a surface name may have genuinely different topologies, and using the wrong pre-plan is worse than planning from scratch.
如果用户的主题匹配已知的AI系统模式（多智能体研究、消息总线、共享状态、带技能的Agent、上下文检索），目录下有预制的初始规划。浏览查找匹配提示词的模式名称。如果匹配，加载该模式文件，使用其mermaid参考+baoyu SVG规划作为步骤4的起点——节点列表、宽度、箭头路由已经草拟完成，你只需要适配标签即可。
references/patterns/references/patterns/README.md如果没有匹配，跳过这个步骤，在步骤4中从零开始规划。不要强行匹配接近的模式：两个表面名称相似的模式可能有完全不同的拓扑，使用错误的预规划比从零开始规划更糟。
Step 4: Plan on paper first
步骤4：先在纸面上规划
Before writing any SVG, draft a short layout plan. Do the math once, correctly, so the SVG comes out right on the first pass.
4a. Extract structure from the source — don't just transcribe the user's bullets into boxes. Read the source looking for these elements. Not every element will be present, but every present element should land in the diagram:
- Mechanism name — does the topic have a short, nameable identity (Autoreason, AutoResearch, OAuth, JWT auth, Reflexion loop)? If yes, that's a candidate .
.title - Framing question — does the source contain a "why does this exist" sentence? Usually in the form "Problem X has no Y, so we built Z to …". That's a candidate subtitle.
- Phases — do the stages naturally cluster into 2–4 named groups (setup / loop body / judgment / convergence)? Each cluster is a candidate section.
.eyebrow - Anchor inputs — is there a constant input (the task prompt, a dataset, a knowledge base) that every stage references? That's a candidate anchor box above the main flow.
- Parallel candidates — at some point, does the process generate N alternatives that are then compared? "Produce A, B, AB and pick the best" is a candidate fan-out + judge pattern. Watch for the implicit "keep unchanged" candidate — many iterative methods include "the incumbent wins by default" as one of the options, even when the source doesn't name it explicitly.
- Loop scope + termination — which boxes are inside a loop that repeats? What is the specific termination rule — streak counter, convergence check, iteration cap, quality threshold? That's a candidate left-rail loop bracket + a dedicated termination box.
- Per-box context that won't fit in a subtitle — "sees task + A + critique / adversarial / fresh context" is too long for a 5-word subtitle but too important to drop. Those are candidate right-column annotations.
.anno - Quotable hook — does the source end with a test result, a quote, or a memorable framing? That's a candidate footer .
.caption - Role categories — how many distinct kinds of operation does the process have (draft / critique / synthesize / judge)? This determines the color budget. Identity is a category, not a sequence.
Write the answers to these in the plan file. If ≥3 of them land, you're building a poster flowchart — load and follow its coordinate budget. Otherwise, it's a simple flowchart and the linear-top-down pattern applies.
references/flowchart-poster.md4b. Draft the layout:
- List the nodes / regions / shapes with their full label text (title + optional subtitle).
- Simple flowchart: ≤5 nodes.
- Poster flowchart: ≤12 nodes grouped into ≤4 eyebrow-divided phases.
- Structural: ≤3 inner regions.
- Illustrative: 1 subject.
- Sequence: list actors (2–4, max 4) in left-to-right order, each with a short title (≤12 chars) and optional role subtitle; then list messages as ordered tuples (6–10 total, 10 is the sweet spot); mark any self-messages; draft a side-note title for the protocol.
(sender, receiver, short label)
- For every rect, compute the width using the formula in :
layout-math.md- (Latin)
width = max(title_chars × 8, subtitle_chars × 7) + 24 - Replace 8 with 15 and 7 with 13 for CJK
- Round up to the nearest 10
- Pick colors by category, not sequence. ≤2 accent ramps per diagram. Gray for neutral/start/end. Reserve blue/green/amber/red for semantic meanings.
- Sequence exception: assign one ramp per actor (default ), up to 4 ramps total — arrows inherit the sender's ramp.
[gray, teal, purple, blue] - Poster-flowchart exception: up to 4 ramps, one per distinct agent/role (drafter=purple, critic=coral, synthesizer=teal, judge=amber). Baseline/anchor/convergence stay gray.
- Sequence exception: assign one ramp per actor (default
- Check tier packing: . For sequence, use the lane table in
N × box_width + (N-1) × gap ≤ 600(N=4 → centers 100/260/420/580) and verify every message label fits its lane span withlayout-math.md. For poster fan-out rows (3 candidates), see the coordinate sketch inlabel_chars × 7 ≤ |sender_x − receiver_x| − 8.flowchart.md - Map arrows and verify none cross an unrelated box. Use L-bends where a straight line would collide. (Sequence messages are always straight horizontal lines — no L-bends. Fan-out candidates converge to a common channel just above the judge box.)
ymid - Compute viewBox height: where
H = max_y + 20is the bottom of the lowest element. Poster flowcharts routinely reach H=800–950 — don't force them to be compact.max_y
Save this plan to so iteration runs can re-read it.
diagram/{slug}/plan.md编写任何SVG代码前，先草拟简短的布局规划。一次性算对数值，确保SVG一次生成正确。
4a. 从来源中提取结构——不要只是把用户的项目符号转录成框。阅读来源寻找以下元素。不是每个元素都会存在，但所有存在的元素都应该在图表中体现：
- 机制名称——主题是否有简短可命名的标识（自动推理、自动研究、OAuth、JWT认证、反思循环）？如果有，可以作为候选。
.title - 框架问题——来源是否包含「为什么要存在」的句子？通常形式为*「问题X没有Y，所以我们构建Z来…」*。可以作为副标题候选。
- 阶段——步骤是否自然聚类为2-4个命名组（设置/循环体/判断/收敛）？每个集群可以作为部分候选。
.eyebrow - 锚点输入——是否有所有阶段都引用的常量输入（任务提示、数据集、知识库）？可以作为主流程上方的锚点框候选。
- 并行候选——流程是否在某个节点生成N个备选方案然后进行对比？「生成A、B、AB然后选择最优」是扇出+判断模式的候选。注意隐含的「保持不变」候选——很多迭代方法会包含「默认保留当前版本」作为选项之一，哪怕来源没有明确提到。
- 循环范围+终止条件——哪些框在重复循环内部？具体的终止规则是什么——连续计数、收敛检查、迭代上限、质量阈值？可以作为左侧循环括号+专用终止框的候选。
- 无法放入副标题的框上下文——「获取任务+A+批评/对抗/全新上下文」太长不适合5词副标题，但又很重要不能丢。可以作为右侧注释的候选。
.anno - 可引用的亮点——来源末尾是否有测试结果、引用或令人印象深刻的框架？可以作为页脚的候选。
.caption - 角色分类——流程有多少种不同的操作类型（起草/批评/合成/判断）？这决定了颜色预算。身份是分类，不是顺序。
将这些答案写入规划文件。如果匹配≥3项，你要构建的是海报流程图——加载并遵循其坐标规范。否则就是简单流程图，适用从上到下的线性模式。
references/flowchart-poster.md4b. 草拟布局：
- 列出节点/区域/形状及完整标签文本（标题+可选副标题）。
- 简单流程图：≤5个节点。
- 海报流程图：≤12个节点，分为≤4个眉批分隔的阶段。
- 结构图：≤3个内部区域。
- 示意图：1个主体。
- 时序图：按从左到右顺序列出角色（2-4个，最多4个），每个带短标题（≤12字符）和可选角色副标题；然后将消息列为有序的元组（总共6-10条，10条是最优值）；标记所有自消息；草拟协议的旁注标题。
(发送者, 接收者, 短标签)
- 为每个矩形计算宽度，使用中的公式：
layout-math.md- （拉丁文字）
宽度 = max(标题字符数 × 8, 副标题字符数 × 7) + 24 - CJK文字将8替换为15，7替换为13
- 向上取整到最近的10
- 按类别选择颜色，而非顺序。每个图表≤2个 accent 色系。中性/开始/结束使用灰色。蓝/绿/黄/红保留给语义含义。
- 时序图例外：每个角色分配一个色系（默认），最多4个色系——箭头继承发送者的色系。
[gray, teal, purple, blue] - 海报流程图例外：最多4个色系，每个不同的Agent/角色分配一个（起草者=紫色、批评者=珊瑚色、合成者=蓝绿色、判断者=琥珀色）。基线/锚点/收敛保持灰色。
- 时序图例外：每个角色分配一个色系（默认
- 检查层级排列：。时序图使用
N × 框宽度 + (N-1) × 间距 ≤ 600中的泳道表（N=4 → 中心坐标100/260/420/580），验证所有消息标签符合泳道跨度要求layout-math.md。海报扇出行（3个候选）参考标签字符数 × 7 ≤ |发送者x坐标 − 接收者x坐标| − 8中的坐标草图。flowchart.md - 映射箭头，确认不会穿过无关的框。直线会碰撞时使用L型折弯。（时序图消息永远是水平直线——没有L型折弯。扇出候选会汇聚到判断框上方的公共通道。）
ymid - 计算viewBox高度：，最大y坐标是最低元素的底部位置。海报流程图通常高度达到800-950——不要强行压缩。
H = 最大y坐标 + 20
将规划保存到，方便迭代运行时重新读取。
diagram/{slug}/plan.mdStep 5: Write the SVG
步骤5：编写SVG
Emit a single element. Copy the + block from verbatim — don't abbreviate or edit the color ramp definitions. Then add visual elements in z-order:
<svg width="100%" viewBox="0 0 680 H"><style><defs>svg-template.md- Background decorations (rare)
- Containers (outer for structural diagrams)
<rect> - Connectors and arrows (drawn first so nodes paint on top)
- Nodes (rects with text)
- Labels outside boxes (leader callouts, legends, external I/O labels)
Typography rules:
- Two sizes only: 14px (,
t) and 12px (th)ts - Two weights only: 400 and 500
- Sentence case everywhere — "User login" not "User Login"
- Every element gets a class (
<text>,t, orts) — never hardcode fill colors on textth
输出单个元素。逐字复制中的 + 块——不要缩写或编辑颜色渐变定义。然后按z顺序添加视觉元素：
<svg width="100%" viewBox="0 0 680 H">svg-template.md<style><defs>- 背景装饰（很少使用）
- 容器（结构图的外层）
<rect> - 连接线和箭头（先绘制，这样节点会绘制在上方）
- 节点（带文本的矩形）
- 框外标签（引出标注、图例、外部输入输出标签）
排版规则：
- 仅使用两种字号：14px（、
t）和12px（th）ts - 仅使用两种字重：400和500
- 所有内容使用 sentence case——「User login」而非「User Login」
- 每个元素都指定类（
<text>、t或ts）——永远不要硬编码文本的填充颜色th
Step 6: Run the pre-save checklist
步骤6：运行保存前检查清单
Walk through every item in . The top failures to catch every time:
references/pitfalls.md- viewBox height covers every element with a 20px buffer
- No rect extends past x=640
- Every labeled rect is wide enough for its text (char-width check)
- No arrow crosses an unrelated box
- Every connector has
<path>(or usesfill="none")class="arr" - Every has a class — no hardcoded
<text>fill="black" - No at low x values (label would clip past x=0)
text-anchor="end" - ≤2 accent ramps, colors encode category not sequence
- No in the final output
<!-- comments -->
If any item fails, fix the SVG before saving. Don't rationalize past a failure — the checklist exists because these bugs are silent: the SVG is valid but looks wrong when rendered.
遍历中的所有项。每次都要检查的最常见错误：
references/pitfalls.md- viewBox高度覆盖所有元素，保留20px缓冲
- 没有矩形超出x=640
- 每个带标签的矩形宽度足够容纳文本（字符宽度检查）
- 没有箭头穿过无关的框
- 每个连接线都设置
<path>（或使用fill="none"）class="arr" - 每个都有类——没有硬编码的
<text>fill="black" - 低x值位置没有（标签会超出x=0被裁剪）
text-anchor="end" - ≤2个accent色系，颜色编码类别而非顺序
- 最终输出中没有
<!-- comments -->
如果任何项不通过，保存前修复SVG。不要为错误找借口——检查清单存在的原因是这些bug是隐性的：SVG是有效的，但渲染时看起来不对。
Step 7: Save output
步骤7：保存输出
If is given, save the SVG there and skip the scaffolded directory. Otherwise use the default layout:
--outdiagram/{topic-slug}/
├── source-{slug}.md # optional: user's input content if provided
├── plan.md # layout sketch from Step 4
└── diagram.svg # final output- Slug: 2–4 kebab-case words derived from the topic.
- Backup rule: if already exists at the target path, rename the existing one to
diagram.svgbefore writing the new file — never overwrite prior work silently.diagram-backup-YYYYMMDD-HHMMSS.svg - Plan: always save from Step 4 beside the SVG so the next iteration can re-read it.
plan.md - Source: if the user pasted source content, save it as in the same directory.
source-{slug}.md
如果指定了参数，将SVG保存到该路径，跳过脚手架目录。否则使用默认布局：
--outdiagram/{topic-slug}/
├── source-{slug}.md # 可选：如果用户提供了输入内容则保存
├── plan.md # 步骤4生成的布局草图
└── diagram.svg # 最终输出- Slug：从主题衍生的2-4个kebab-case单词。
- 备份规则：如果目标路径已存在，将现有文件重命名为
diagram.svg再写入新文件——永远不要静默覆盖之前的工作。diagram-backup-YYYYMMDD-HHMMSS.svg - 规划文件：始终将步骤4的保存在SVG旁边，方便下次迭代时读取。
plan.md - 源文件：如果用户粘贴了源内容，将其保存为同目录下的。
source-{slug}.md
Step 8: Report
步骤8：反馈结果
Tell the user in 4-6 lines:
- Diagram type picked (and one-sentence why)
- Node count / complexity
- viewBox dimensions
- Language
- Output file path
- One suggestion for how to preview it (e.g., "Open in Chrome for light/dark check")
用4-6行告知用户：
- 选择的图表类型（及一句话原因）
- 节点数量/复杂度
- viewBox尺寸
- 语言
- 输出文件路径
- 一个预览建议（例如「在Chrome中打开检查明暗模式适配」）
Core principles
核心原则
- Draw the mechanism, not a diagram about the mechanism (illustrative). Draw the sequence, not the architecture (flowchart). Draw the containment, not the flow (structural). Draw the conversation, not the steps (sequence). Picking the wrong type is the single biggest failure mode — more harmful than any layout bug.
- One design system, always. No flag, no alternate themes, no per-topic visual variants. The cohesive look across every diagram is the product — if a reader sees two baoyu diagrams in different articles, they should feel they came from the same hand. Any request to "use a different style" is a request to break this principle; push back and ask what the underlying need is instead.
--style - Self-contained output. Every SVG carries its own styles and dark-mode rules. The reader should never need to edit anything after pasting it into their article.
- Math before markup. SVG has no auto-layout. Every coordinate is hand-computed. A diagram that "almost fits" has a bug — fix the math, don't nudge pixels.
- Color encodes meaning, not position. Five steps in a flowchart are not five colors. All five are gray unless one specific step deserves emphasis — in which case it gets the accent color.
- The reader has 3 seconds. If the diagram needs prose explanation to parse, it's failing. Simplify until it can stand alone with only its labels.
- 绘制机制本身，而非关于机制的图表（示意图）。绘制序列，而非架构（流程图）。绘制包含关系，而非流程（结构图）。绘制对话，而非步骤（时序图）。选择错误类型是最大的失败模式——比任何布局bug的危害都大。
- 永远遵循同一套设计系统。没有参数、没有备选主题、没有按主题的视觉变体。所有图表的统一外观是产品核心价值——如果读者在不同文章中看到两个baoyu生成的图表，应该能感觉到它们出自同一体系。任何「使用不同风格」的请求都是要求违反这个原则；请拒绝并询问底层需求是什么。
--style - 输出独立自包含。每个SVG都携带自己的样式和明暗模式规则。读者粘贴到文章后永远不需要编辑任何内容。
- 先计算再写代码。SVG没有自动布局。每个坐标都是手动计算的。「几乎适配」的图表有bug——修复计算逻辑，不要微调像素。
- 颜色编码含义，而非位置。流程图的5个步骤不需要5种颜色。除非某个步骤需要特别强调，否则所有5个都是灰色，需要强调的步骤使用accent颜色。
- 读者只有3秒时间理解。如果图表需要文字说明才能看懂，就是失败的。简化到仅靠标签就能独立表意。
References
参考文档
- — palette, typography, hard rules
references/design-system.md - — the
references/svg-template.md+<style>boilerplate (copy verbatim)<defs> - — coordinates, text widths, viewBox math, arrow routing
references/layout-math.md - — the pre-save checklist
references/pitfalls.md - — flowchart-specific rules and worked examples (includes state-machine sub-pattern)
references/flowchart.md - — poster flowchart dialect (load on demand when ≥3 poster triggers fire)
references/flowchart-poster.md - — phase-band flowchart (horizontal dashed phase containers, compact tool card rows, cross-band semantic arrows, operator icons, legend strip)
references/flowchart-phase-bands.md - — sequence-diagram rules (actors, lifelines, messages, self-messages)
references/sequence.md - — structural-specific rules and worked examples (subsystem, bus, radial star, rich interior, mixed arrows)
references/structural.md - — network topology sub-pattern (zone containers, wired/wireless, tiered layout)
references/structural-network.md - — comparison matrix sub-pattern (feature table, ✓/✗ cells, zebra rows)
references/structural-matrix.md - — illustrative-specific rules and worked examples
references/illustrative.md - — UML class diagram rules (3-compartment rects, relationships, stereotypes)
references/class.md - — shared glyph library (status circles, checkboxes, queue slots, icons, annotation circles) and concept-to-shape conventions
references/glyphs.md - — pre-planned starters for common AI-system topologies (RAG, agents, memory tiers, verifier loops, …)
references/patterns/
- ——调色板、排版、硬性规则
references/design-system.md - ——
references/svg-template.md+<style>模板（逐字复制）<defs> - ——坐标、文本宽度、viewBox计算、箭头路由
references/layout-math.md - ——保存前检查清单
references/pitfalls.md - ——流程图专属规则和实例（包含状态机子模式）
references/flowchart.md - ——海报流程图变体（≥3个海报触发条件时按需加载）
references/flowchart-poster.md - ——阶段带流程图（水平虚线阶段容器、紧凑工具卡行、跨带语义箭头、操作员图标、图例条）
references/flowchart-phase-bands.md - ——时序图规则（角色、生命线、消息、自消息）
references/sequence.md - ——结构图专属规则和实例（子系统、总线、放射星型、丰富内部内容、混合箭头）
references/structural.md - ——网络拓扑子模式（区域容器、有线/无线、分层布局）
references/structural-network.md - ——对比矩阵子模式（功能表、✓/✗单元格、斑马纹行）
references/structural-matrix.md - ——示意图专属规则和实例
references/illustrative.md - ——UML类图规则（三格矩形、关系、构造型）
references/class.md - ——共享图形库（状态圆圈、复选框、队列槽、图标、注释圆圈）和概念到形状的约定
references/glyphs.md - ——常见AI系统拓扑的预制初始规划（RAG、Agents、内存层级、验证器循环…）
references/patterns/