diagram-design最近有点炸，核心原因就一句话：AI画架构图那种圆角框+渐变蓝紫+自动连线的"塑料感"，终于有人受不了了，做了个专门治这个病的Skill。现在已经积累了两万多GitHub Star，官方README上的图表类型也从最初二十来种涨到了39种，更新节奏相当快。
diagram-design 为什么突然火了
开发者对"AI味"审美疲劳这件事其实攒了很久。Mermaid画流程图方便，但节点一多容易变成"能看懂但没法直接放进文档"的粗糙感;普通模型画架构图，基本都是标准化圆角矩形加自动排版连线，和你网站的视觉风格完全是两个世界。
作者Cathryn Lavery自己写博客(littlemight.com)、也在打理BestSelf.co。她说以前每次找Claude要架构草图、流程图，甚至一个"什么最重要"的金字塔图，得到的永远是那种和站点风格不搭的通用方框。 要么去Figma手动调半小时颜色，要么干脆放弃不画了。于是她把"怎么画得像专业编辑手上出来的图"这套经验直接写成了Agent Skill，目标写得很直白：做出设计师不会嫌弃的编辑级图表。 它不是又一个Mermaid，是一套视觉审稿标准
现在这套技能覆盖39种editorial diagram，大致分三组:
- 工程架构:Architecture、Sequence、ER、Deployment、Dependency Graph、UML Class、Database Schema
- 产品项目:Timeline、Gantt、Kanban、User Journey、Story Map、Quadrant
- 数据表达:Sankey、Radar、Bar、Line、Treemap、Venn，外加Wardley Map、鱼骨图这类偏冷门但确实有用的类型
每种类型都配minimal light、minimal dark、full-editorial三套静态版本，默认直接出单文件HTML加内联SVG，不用你搭前端构建流程。
真正的关键在设计理念上——它把"少即是多"变成了硬性规则:每个节点得有存在的理由，强调色只能留给一两个真正重要的地方，官方给的信息密度目标大概是4/10。
这个思路挺反直觉的，大部分AI画图工具是在鼓励模型往图里塞更多东西，它反过来要求模型先想清楚该删掉什么。比如那张Loop/Flywheel循环图，中心只留Shared memory一个核心节点，唯一需要盯着看的Decide节点才配得上那抹强调色，别的地方全是干净留白。
装起来、用起来都不复杂
官方现在同时维护Claude Code、Codex、Factory Droid和Pi四条安装路径。Claude Code这边是先加marketplace再装插件: Codex那边命令结构基本一致，Pi可以直接装GitHub仓库。
有个坑要留意:Claude Code对第三方marketplace默认不自动更新，装完得手动进/plugin→Marketplaces把自动更新打开，不然版本会卡住。
装完之后不用背命令，直接跟Agent说"给我的App画一张前端、后端、数据库、Redis缓存的架构图"就行。提示词参考：
第一次在新项目里用，它会先检查style-guide是不是还停留在默认配色，如果是就会问你要不要做品牌onboarding。最省事的做法是直接甩个网址过去，让它读取主页的背景色、正文色、CTA色和字体栈，自动映射成paper、ink、accent几个语义色板，确认后写进样式指南。官方给的目标耗时大概60秒。
真正好用的地方，是把已有的丑图重排一遍
很多人手头本来就有Mermaid或draw.io画的图，麻烦不在于没图，而在于图对但丑。 diagram-design支持直接导入.drawio、.drawio.xml，也能读取带内嵌数据的.drawio.png/svg，以及.mmd文件或Markdown里的Mermaid代码块。它不会照搬原图的坐标、配色和字体，只保留组件、关系、分组和方向，按自己那套设计系统重新排一遍版。
重画这一步给了四个可调参数:
- Format:HTML / SVG / PNG / HTML+PNG
- Size:文档、16:9幻灯片、社交卡片、打印尺寸
- Detail:faithful / balanced / simplified，控制保留多少节点
- Audience:engineer / mixed / executive，决定措辞面向工程师、混合读者还是管理层
这个设计其实挺像真实的编辑工作——同一张Auth Service架构图，给工程团队看可以保留JWT算法和端口细节，给executive看可能就只剩"Sign-in"三个字。
重画完成后它还会给出一份删减清单，清楚告诉你哪些节点被合并或折叠了，不至于让AI在重画时顺手把逻辑也改了。
它值得关注，但也有边界
它长在Coding Agent工作流里这件事本身就是优势。Agent已经理解你的代码和文档上下文，不用你再复制一遍去某个画图网站从头解释。
输出是可编辑的HTML+SVG而不是位图，后续能继续改，也能通过Playwright导出高分辨率PNG给Figma或Illustrator用。团队还能把网站的色彩字体存成profile跨项目复用，不用每次都重新教AI"用我们家的蓝色"。
官方自己也划了边界:
- 终端里一个Unicode小图、一份清单、简单的前后对比，或只有一个方框的"图"，都不该用这个工具，老老实实用表格更合适
- 几十上百个节点的完整拓扑图，或需要多人实时拖拽协作的场景，传统绘图工具反而更合适
- 最终构图还是由Agent完成的，不同模型、不同上下文喂进去可能出来不一样的结果，仓库自带的检查脚本能挑出一部分颜色、字体和几何问题，但替代不了人工最后看一眼
- 默认字体依赖Google Fonts，导出PNG还得装Playwright和Chromium，这些环境依赖也得提前踩一遍坑
完整流程大致是：描述需求或导入旧图→Agent选型重画→检查删减记录→手动微调HTML/SVG→导出发布格式，一条龙下来比单纯一句"帮我画得高级点"的提示词完整太多。
说到底，diagram-design更像一套给Agent用的"图表编辑规范":先决定什么值得画，再决定什么必须删，颜色字体反而是最后才轮到的事。如果你也常让Agent帮忙画图，流程图、架构图和文章配图里，你最想先解决哪一类?
AI 速览
