智能架构图绘制

它解决什么问题

把架构讲清楚，难点通常不在「画」，而在画之前的信息处理。开发者口里的「订单链路」「网关层」「参考一下 /path/to/x」，对 Agent 而言都是悬空引用：它看不见你脑子里的背景知识，也不会自动去读那个文件。结果是产出的图要么只有一串术语框（网关、订单服务、Redis），要么连线方向含糊，看着像元素的随便摆放。

另一个常见坑是一张图塞下全部细节，宏观骨架和微观实现混在一起，谁看都抓不住重点。再加上输出形态不统一——有时要可交付的 HTML，有时要在对话里直接看 SVG，有时只是要一段 Mermaid 贴进文档——手工来回切换很费事。

核心能力：三条不变式与三模式渲染

这个 Skill 的做法是先立规则再动手，核心是三条不变式：

• 解引用一切：绘图前先读取被引用的文件并拍平为文本；专有名词补全角色、层级、动作、上下游；遇到「基于上一张图修改」时读回已保存的 HTML/SVG 当基线。
• 论证而非展示：每条关系必须能复述成明确语句（如「A 依赖 B」），禁止用元素靠近表达关系；去掉文字标签后结构仍应传达逻辑。
• 一图一主题：按宏观/中观/微观定层级，单图装不下就拆分，先输出拆分方案并等待确认再动手。

渲染侧提供三种模式，按图表类型选择：

• 模式 A HTML 模板：用于系统/微服务/分层架构图，基于 assets/architecture-template.html 的 CSS 变量生成自包含文件，支持响应式与 hover 动画。
• 模式 B 内联 SVG：用于流程图、时序图、状态机、ER 图、拓扑图，通过 read_me(["diagram"]) 加载模块，遵循固定 viewBox 与防压字、Token 复用规范。
• 模式 C Mermaid：用于嵌入 Markdown 文档或用户明确要语法时。

输出前还有一轮渲染自检：CSS 变量与卡片类名是否正确、SVG 是否含非法标签、箭头尖端 10px 禁区有无文字、节点是否超过 20 个。修改需求走文件迭代法，读原文件做增量修改后覆盖保存。

适用边界与注意点

支持的图表集中在「结构与关系」类：架构图、拓扑、业务流程、泳道、数据流、时序、状态机、ER、类图、甘特图。

明确不支持的几类不要硬画：统计图表（饼/柱/折线）建议改走 Chart.js，思维导图建议用 Mermaid mindmap 或拆成层级架构，3D 与地理地图留给专用工具，导出 PNG/PDF 只交付源码由用户自行导出，反向工程（图→代码）不在范围内。遇到越界请求，Skill 会先说明不支持原因和替代方案再停下等确认。

另外要注意意图澄清是强制环节：图表类型、输出形态、配色、重点强调四个问题不清时会先提问；只有用户已明确或回答「你决定」时才跳过。如果你想控制细节，直接在请求里把这些要素写全，可以省掉一轮往返。