ARTICLE · 1102283
软件设计画图 DSL 选型:Mermaid、PlantUML、D2 与 draw.io 的深度对比
软件设计画图 DSL 选型:Mermaid、PlantUML、D2 与 draw.io 的深度对比
一、先给结论
最 AI Native 的就是 Mermaid，没有并列，没有争议。 它的 AI 生成成功率、训练语料密度、渲染器覆盖率都是四者里最高的。这一点是事实判断，不需要客气。
但"最 AI Native"只回答了一个问题：让 AI 写出一张合法、过得去的图，谁最省力。 它不回答另一个更花钱的问题：这张图能不能进仓库、能不能交付给客户、能不能被精确打磨。 这才是选型真正的分歧点。
所以本章的结论要分成两半，别混着听：
• 论 AI 生成友好度，冠军唯一：Mermaid。
• 论交付和打磨，四个工具各占一个位置，没有强弱排序。
判断规则只有两条：这张图要不要被版本管理，以及要不要被人类精确打磨。
• 要 commit 进仓库、要 CI 渲染：Mermaid 或 PlantUML。
• 要 AI 生成且观感漂亮：D2。
• 要拿去给客户看、要控制每一个像素：D2 生成骨架，draw.io 收尾。
一句话：Mermaid 管生成，D2 管观感，draw.io 管打磨。
二、Mermaid 为什么是 AI Native 的冠军
2.1 三个事实，与它们之间真正的因果关系
事实一：GitHub 自 2022 年 2 月起原生渲染 mermaid 代码块。 GitLab（13.3 及以上）、Gitea、Notion、Obsidian、VS Code 随后跟进。Mermaid 因此成为唯一能在源码仓库里"写了就看到"的绘图 DSL。其他三个工具都需要额外渲染步骤，这一步差距是结构性的，不是量级上的。
事实二：GitHub 是全球最大的公开代码与文档语料来源，而 LLM 的训练数据大量来自这里。 这是 Mermaid 友好这个判断的真实来源，不是 Mermaid 的设计者特意优化了什么。Mermaid 的语法设计早于这波大模型浪潮，设计者当时想的也不是给 AI 用。
事实三：Mermaid 的语法确实短，这是它一次写对率高的真正原因。 一条时序图的典型写法是 A->>B: call，七个 token 就完成一个消息箭头。更少的字符意味着更少的出错机会，也意味着模型输出的 token 更少、推理更稳定。
真正的因果链是：Mermaid 短小 + GitHub 原生渲染 → 海量正确样本进入训练语料 → 模型写得更稳 → 用户更愿用 → 样本更多。 这是一条自增强的数据飞轮。
这条飞轮有两个推论，都很实用。第一个推论是 Mermaid 在简单图上几乎不会翻车，这不是它设计得好，是语料喂出来的。第二个推论更重要：一旦超出舒适区，模型的错误会变得非常顽固，因为训练语料里复杂 Mermaid 的高质量样本本就稀少。
这意味着 Mermaid 的失败不是随机的，而是有清晰边界的：简单图稳定，复杂图突然崩。你不需要猜，看图的规模就知道风险在哪。
2.2 极简换来的代价
极简不是免费的。Mermaid 是声明式加自动布局：你描述节点和边，引擎决定坐标。越界后你会遇到三类问题。
第一类是语法覆盖不全。 复杂时序图的 par、critical、loop 嵌套，跨页泳道，自引用消息，分组背景色，要么不支持，要么写法别扭。Mermaid 的设计目标本来就是在 Markdown 里零配置出一张说得过去的图，不是完整建模一个系统。这个目标决定了它的上限。
第二类是布局失控。 subgraph 的嵌套与排序规则对 AI 和用户都不透明。反复调整顺序却看不到效果，是典型的无效迭代，最消耗预算。
第三类是错误信息粗糙。 parser 报错常指向一个字符偏移，真正根因却是语义冲突，比如两个同名 participant。报错给的是症状，不是病因。
2.3 生成成功率不等于稳定
"一次写对率高"必须拆成两层看：语法合法率，以及语义符合预期率。
Mermaid 的语法合法率确实高，这是它 AI Native 身份的核心证据。但"渲染出来跟我想要的一样"这一层它没有优势，因为布局是引擎给的，AI 无法预测坐标结果。
常见失败模式里频率最高的是非法字符与未转义括号，修复成本低。频率同样高、但修复成本最高的是布局方向与预期相反，这种时候往往只能重构图，不是微调能解决的。
还有一条最容易被忽略：同一份 Mermaid 在 GitHub、GitLab、Notion、mermaid.ink 上的表现并不一致。 本地预览通过，commit 进去仍可能变样。严肃场景应在 CI 里做渲染快照比对，而不是能渲染就合并。
2.4 Mermaid 的正确位置
Mermaid 最不可替代的价值是与 Markdown 同源同生命周期：图作为代码提交，随 PR 评审，随分支演进，diff 可读。这是 draw.io 做不到的，它产出的是坐标 XML，diff 基本没有信息量。
最佳落点是 README 架构总览、PR 描述里的变更示意、ADR 方案对比图、CI 流水线示意图。它们的共同特点是读的人多、改的人少、精度要求不高、需要和代码一起被版本管理。
本章小结： Mermaid 是 AI 生成的默认选项，也是首选，除非你的图有明确的布局需求或建模需求。在这两种情况下继续用 Mermaid，不是坚持，是硬扛。
三、PlantUML：图论表达能力最强，但能写与写得好看差距最大
3.1 它的优势是建模语义，不是 AI 友好
PlantUML 覆盖的 UML 语义最完整，包括时序图、活动图、组件图、部署图、对象图，以及专门的 timing diagram，也就是信号级别的时间波形图。这是 Mermaid 完全不具备的一整类表达。
更关键的是它的布局引擎是 Graphviz。在处理任意拓扑时它天然优于 Mermaid。多对多依赖、深层嵌套、状态爆炸的图，PlantUML 的 together、hidden link、rank 定向控制有效得多。
判断规则很直接：如果你的图里有超过两层的嵌套，或者有大量交叉边需要手工理顺，直接上 PlantUML，别在 Mermaid 里硬扛。 这不是偏好问题，是工具能力问题。
3.2 它的真实弱点
PlantUML 的问题不是 AI 写不出来，而是 AI 写出来了但丑。
模型很容易产出语法合法、语义正确、但布局难看的图。原因是 PlantUML 的布局参数，包括 together、rank same、linetype，本身就需要人类对结果做视觉反馈后才能调好，而 AI 看不到渲染结果。
这带来一个重要的工作流结论：PlantUML 适合 AI 出草稿加人类调布局的两段式，不适合一次生成就交付。 把它当成一次性生成工具用，效果会明显低于预期。
3.3 两个容易忽略的实用点
第一，PlantUML 的 include 机制很强。 可以用 include 指令拆分大型图，把通用样式和参与者库抽成公共文件。这让它在大型项目中比 Mermaid 更容易维护。
第二，PlantUML 支持主题，即 skinparam 与 theme。 内置主题可以直接改变整套图的配色与字体，比 Mermaid 的逐个样式声明高效得多。
四、D2：被低估的第三选项
4.1 它在 Mermaid 与 draw.io 之间找到了一个缺口
D2 由 Terraform 团队维护，设计目标是代码即架构图。它的语法比 Mermaid 表达力强，同时保留了代码 DSL 的可维护性。
最实用的两点。第一，它支持 near、grid、dagre 等多种布局引擎，可以用 shape、style、constraints 直接表达这个组件放在那个旁边，这让 AI 生成的结果观感明显好于 Mermaid。第二，它有完整的 JSON 中间表示，可以程序化生成、转换、校验，这是它比 draw.io 更适合 AI 管道的根本原因。
4.2 它解决了 Mermaid 解决不了的问题
Mermaid 的布局是黑盒，D2 的布局是可引导的。对于既要进仓库、又要拿去给人看的图，包括架构图、网络拓扑、数据流，D2 是目前最均衡的选择。
判断规则：如果这张图既要进仓库，又要拿去给客户看，优先 D2，而不是 Mermaid。 这种需求下 Mermaid 只能保证生成，保证不了观感。
4.3 它的局限
D2 的社区规模和训练语料密度低于 Mermaid。模型写 D2 的成功率接近 Mermaid，但在一些冷门语法上会不稳定，比如 sql_table 与 class shape。同时 D2 的渲染依赖其 CLI，CI 集成比 Mermaid 多一步环境配置。
本章小结： D2 的定位很清晰，它要解决的是"AI 生成 + 观感"这个 Mermaid 没解决好的交叉需求。如果你手上的图落在这个交叉点上，D2 比继续调 Mermaid 更省事。
五、draw.io：唯一真正有坐标空间的格式
5.1 先纠正一个常见误解
draw.io 通常指 mxGraph 引擎，文件格式是 dot drawio，也就是 XML。它在 app.diagrams.net 里手动画出的图，确实有显式的 x、y、width、height，以及图层、样式和连线路由。
但它不是一个 DSL，而是 GUI 的产物。 AI 直接手写 mxGraph XML 非常痛苦且不稳定，这正是它的软肋。
所以"draw.io 最 AI Native"这个说法是错的。反过来才是真的：draw.io 是四个工具里 AI 生成友好度最低的。它的价值从来不在生成，在打磨。
5.2 它不可替代的地方
当你需要的是物理定位敏感的图，比如网络设备机架图、机柜布局、楼层平面图、任何有真实几何约束的图，只有 draw.io 以及它的近亲 Excalidraw、tldraw 能胜任。
这类图的本质是工程制图，不是关系建模。前三个工具没有坐标空间，画不出来；即使画出来也无法精确控制。
5.3 现实工作流
draw.io 的正确用法是收尾工具：用 D2 或 PlantUML 生成骨架，导出后人工调整位置、配色、对齐、连线路由，最后作为交付件。
六、综合选型
6.1 四个维度对比
首要目标这个维度： Mermaid 是在 Markdown 内零配置出图，PlantUML 是完整 UML 语义建模，D2 是代码即架构图，draw.io 是所见即所得画布。
布局控制权这个维度： Mermaid 低且是黑盒，PlantUML 中到高且基于 Graphviz，D2 中到高且可引导，draw.io 高且是显式坐标。
AI 生成友好度这个维度： Mermaid 高，PlantUML 中，D2 高，draw.io 低。这里要再强调一次，这个维度的冠军是 Mermaid，没有并列。
人类精细打磨这个维度： Mermaid 弱，只能改源码；PlantUML 弱，只能改源码；D2 中，改源码；draw.io 强，GUI 拖拽。
拓扑表达力这个维度： Mermaid 低到中，PlantUML 高，D2 中到高，draw.io 低且没有自动布局。
典型产出这个维度： Mermaid 是文档内嵌示意图，PlantUML 是严谨设计文档，D2 是对外架构图，draw.io 是最终交付件。
6.2 不存在统一的强弱排序
上一节的分项对比不是为了排出总名次，而是为了说明四个工具各占一个位置。总名次没有意义，因为它们优化的是不同的环节。
唯一有总名次的维度是 AI 生成友好度，那个维度的冠军是 Mermaid。除此之外，选谁只看你的图落在哪个需求上。
七、AI 协作的三条硬经验
7.1 AI 能不能写只解决了一半问题
真正决定维护成本的，是 AI 写出来的东西能不能被人轻易改对。前者是生成成功率，后者是可修正性。
可修正性取决于图的复杂度与 DSL 的表达边界是否匹配。一旦图的复杂度超过 DSL 的舒适区，AI 的错误会变得非常顽固，因为训练语料里复杂用例的高质量样本本就稀少。
7.2 两段式工作流优于一次到位
任何工具都不要指望一次生成就交付。正确做法是：AI 出草稿，人类做视觉反馈，定点修正，再交给 AI。
PlantUML 尤其适合这种流程，因为布局参数本身就需要人类看一眼才能调好。
7.3 把图的职责分开
同一份架构文档里，不同图承担不同职责。总览图进 README，用 Mermaid，要版本管理。详细设计图用 PlantUML，要 UML 语义严谨。对外架构图用 D2，要观感。物理部署图用 draw.io，要坐标精确。
四张图各用最合适的工具，比强迫一个工具包打天下高效得多。
八、一句话总结
AI Native 的冠军只有一个，就是 Mermaid。
这个结论来自它与 GitHub README 的深度绑定，让大量正确样本反复进入训练语料。这是事实，不需要打折。
但冠军身份不自动推导出冠军垄断。Mermaid 管生成，D2 管观感，draw.io 管打磨，PlantUML 管建模。四个环节各有一个最合适的工具，这才是完整的选型结论。
要 commit 进仓库、要 CI 渲染，选 Mermaid 或 PlantUML。要 AI 生成且观感漂亮，选 D2。要拿去给客户看、要控制像素，用 D2 或 draw.io 收尾。
最 AI Native 的就是 Mermaid，没有并列，没有争议。 它的 AI 生成成功率、训练语料密度、渲染器覆盖率都是四者里最高的。这一点是事实判断，不需要客气。
但"最 AI Native"只回答了一个问题：让 AI 写出一张合法、过得去的图，谁最省力。 它不回答另一个更花钱的问题：这张图能不能进仓库、能不能交付给客户、能不能被精确打磨。 这才是选型真正的分歧点。
所以本章的结论要分成两半，别混着听：
• 论 AI 生成友好度，冠军唯一：Mermaid。
• 论交付和打磨，四个工具各占一个位置，没有强弱排序。
判断规则只有两条：这张图要不要被版本管理，以及要不要被人类精确打磨。
• 要 commit 进仓库、要 CI 渲染：Mermaid 或 PlantUML。
• 要 AI 生成且观感漂亮：D2。
• 要拿去给客户看、要控制每一个像素：D2 生成骨架，draw.io 收尾。
一句话：Mermaid 管生成，D2 管观感，draw.io 管打磨。
二、Mermaid 为什么是 AI Native 的冠军
2.1 三个事实，与它们之间真正的因果关系
事实一：GitHub 自 2022 年 2 月起原生渲染 mermaid 代码块。 GitLab（13.3 及以上）、Gitea、Notion、Obsidian、VS Code 随后跟进。Mermaid 因此成为唯一能在源码仓库里"写了就看到"的绘图 DSL。其他三个工具都需要额外渲染步骤，这一步差距是结构性的，不是量级上的。
事实二：GitHub 是全球最大的公开代码与文档语料来源，而 LLM 的训练数据大量来自这里。 这是 Mermaid 友好这个判断的真实来源，不是 Mermaid 的设计者特意优化了什么。Mermaid 的语法设计早于这波大模型浪潮，设计者当时想的也不是给 AI 用。
事实三：Mermaid 的语法确实短，这是它一次写对率高的真正原因。 一条时序图的典型写法是 A->>B: call，七个 token 就完成一个消息箭头。更少的字符意味着更少的出错机会，也意味着模型输出的 token 更少、推理更稳定。
真正的因果链是：Mermaid 短小 + GitHub 原生渲染 → 海量正确样本进入训练语料 → 模型写得更稳 → 用户更愿用 → 样本更多。 这是一条自增强的数据飞轮。
这条飞轮有两个推论，都很实用。第一个推论是 Mermaid 在简单图上几乎不会翻车，这不是它设计得好，是语料喂出来的。第二个推论更重要：一旦超出舒适区，模型的错误会变得非常顽固，因为训练语料里复杂 Mermaid 的高质量样本本就稀少。
这意味着 Mermaid 的失败不是随机的，而是有清晰边界的：简单图稳定，复杂图突然崩。你不需要猜，看图的规模就知道风险在哪。
2.2 极简换来的代价
极简不是免费的。Mermaid 是声明式加自动布局：你描述节点和边，引擎决定坐标。越界后你会遇到三类问题。
第一类是语法覆盖不全。 复杂时序图的 par、critical、loop 嵌套，跨页泳道，自引用消息，分组背景色，要么不支持，要么写法别扭。Mermaid 的设计目标本来就是在 Markdown 里零配置出一张说得过去的图，不是完整建模一个系统。这个目标决定了它的上限。
第二类是布局失控。 subgraph 的嵌套与排序规则对 AI 和用户都不透明。反复调整顺序却看不到效果，是典型的无效迭代，最消耗预算。
第三类是错误信息粗糙。 parser 报错常指向一个字符偏移，真正根因却是语义冲突，比如两个同名 participant。报错给的是症状，不是病因。
2.3 生成成功率不等于稳定
"一次写对率高"必须拆成两层看：语法合法率，以及语义符合预期率。
Mermaid 的语法合法率确实高，这是它 AI Native 身份的核心证据。但"渲染出来跟我想要的一样"这一层它没有优势，因为布局是引擎给的，AI 无法预测坐标结果。
常见失败模式里频率最高的是非法字符与未转义括号，修复成本低。频率同样高、但修复成本最高的是布局方向与预期相反，这种时候往往只能重构图，不是微调能解决的。
还有一条最容易被忽略：同一份 Mermaid 在 GitHub、GitLab、Notion、mermaid.ink 上的表现并不一致。 本地预览通过，commit 进去仍可能变样。严肃场景应在 CI 里做渲染快照比对，而不是能渲染就合并。
2.4 Mermaid 的正确位置
Mermaid 最不可替代的价值是与 Markdown 同源同生命周期：图作为代码提交，随 PR 评审，随分支演进，diff 可读。这是 draw.io 做不到的，它产出的是坐标 XML，diff 基本没有信息量。
最佳落点是 README 架构总览、PR 描述里的变更示意、ADR 方案对比图、CI 流水线示意图。它们的共同特点是读的人多、改的人少、精度要求不高、需要和代码一起被版本管理。
本章小结： Mermaid 是 AI 生成的默认选项，也是首选，除非你的图有明确的布局需求或建模需求。在这两种情况下继续用 Mermaid，不是坚持，是硬扛。
三、PlantUML：图论表达能力最强，但能写与写得好看差距最大
3.1 它的优势是建模语义，不是 AI 友好
PlantUML 覆盖的 UML 语义最完整，包括时序图、活动图、组件图、部署图、对象图，以及专门的 timing diagram，也就是信号级别的时间波形图。这是 Mermaid 完全不具备的一整类表达。
更关键的是它的布局引擎是 Graphviz。在处理任意拓扑时它天然优于 Mermaid。多对多依赖、深层嵌套、状态爆炸的图，PlantUML 的 together、hidden link、rank 定向控制有效得多。
判断规则很直接：如果你的图里有超过两层的嵌套，或者有大量交叉边需要手工理顺，直接上 PlantUML，别在 Mermaid 里硬扛。 这不是偏好问题，是工具能力问题。
3.2 它的真实弱点
PlantUML 的问题不是 AI 写不出来，而是 AI 写出来了但丑。
模型很容易产出语法合法、语义正确、但布局难看的图。原因是 PlantUML 的布局参数，包括 together、rank same、linetype，本身就需要人类对结果做视觉反馈后才能调好，而 AI 看不到渲染结果。
这带来一个重要的工作流结论：PlantUML 适合 AI 出草稿加人类调布局的两段式，不适合一次生成就交付。 把它当成一次性生成工具用，效果会明显低于预期。
3.3 两个容易忽略的实用点
第一，PlantUML 的 include 机制很强。 可以用 include 指令拆分大型图，把通用样式和参与者库抽成公共文件。这让它在大型项目中比 Mermaid 更容易维护。
第二，PlantUML 支持主题，即 skinparam 与 theme。 内置主题可以直接改变整套图的配色与字体，比 Mermaid 的逐个样式声明高效得多。
四、D2：被低估的第三选项
4.1 它在 Mermaid 与 draw.io 之间找到了一个缺口
D2 由 Terraform 团队维护，设计目标是代码即架构图。它的语法比 Mermaid 表达力强，同时保留了代码 DSL 的可维护性。
最实用的两点。第一，它支持 near、grid、dagre 等多种布局引擎，可以用 shape、style、constraints 直接表达这个组件放在那个旁边，这让 AI 生成的结果观感明显好于 Mermaid。第二，它有完整的 JSON 中间表示，可以程序化生成、转换、校验，这是它比 draw.io 更适合 AI 管道的根本原因。
4.2 它解决了 Mermaid 解决不了的问题
Mermaid 的布局是黑盒，D2 的布局是可引导的。对于既要进仓库、又要拿去给人看的图，包括架构图、网络拓扑、数据流，D2 是目前最均衡的选择。
判断规则：如果这张图既要进仓库，又要拿去给客户看，优先 D2，而不是 Mermaid。 这种需求下 Mermaid 只能保证生成，保证不了观感。
4.3 它的局限
D2 的社区规模和训练语料密度低于 Mermaid。模型写 D2 的成功率接近 Mermaid，但在一些冷门语法上会不稳定，比如 sql_table 与 class shape。同时 D2 的渲染依赖其 CLI，CI 集成比 Mermaid 多一步环境配置。
本章小结： D2 的定位很清晰，它要解决的是"AI 生成 + 观感"这个 Mermaid 没解决好的交叉需求。如果你手上的图落在这个交叉点上，D2 比继续调 Mermaid 更省事。
五、draw.io：唯一真正有坐标空间的格式
5.1 先纠正一个常见误解
draw.io 通常指 mxGraph 引擎，文件格式是 dot drawio，也就是 XML。它在 app.diagrams.net 里手动画出的图，确实有显式的 x、y、width、height，以及图层、样式和连线路由。
但它不是一个 DSL，而是 GUI 的产物。 AI 直接手写 mxGraph XML 非常痛苦且不稳定，这正是它的软肋。
所以"draw.io 最 AI Native"这个说法是错的。反过来才是真的：draw.io 是四个工具里 AI 生成友好度最低的。它的价值从来不在生成，在打磨。
5.2 它不可替代的地方
当你需要的是物理定位敏感的图，比如网络设备机架图、机柜布局、楼层平面图、任何有真实几何约束的图，只有 draw.io 以及它的近亲 Excalidraw、tldraw 能胜任。
这类图的本质是工程制图，不是关系建模。前三个工具没有坐标空间，画不出来；即使画出来也无法精确控制。
5.3 现实工作流
draw.io 的正确用法是收尾工具：用 D2 或 PlantUML 生成骨架，导出后人工调整位置、配色、对齐、连线路由，最后作为交付件。
六、综合选型
6.1 四个维度对比
首要目标这个维度： Mermaid 是在 Markdown 内零配置出图，PlantUML 是完整 UML 语义建模，D2 是代码即架构图，draw.io 是所见即所得画布。
布局控制权这个维度： Mermaid 低且是黑盒，PlantUML 中到高且基于 Graphviz，D2 中到高且可引导，draw.io 高且是显式坐标。
AI 生成友好度这个维度： Mermaid 高，PlantUML 中，D2 高，draw.io 低。这里要再强调一次，这个维度的冠军是 Mermaid，没有并列。
人类精细打磨这个维度： Mermaid 弱，只能改源码；PlantUML 弱，只能改源码；D2 中，改源码；draw.io 强，GUI 拖拽。
拓扑表达力这个维度： Mermaid 低到中，PlantUML 高，D2 中到高，draw.io 低且没有自动布局。
典型产出这个维度： Mermaid 是文档内嵌示意图，PlantUML 是严谨设计文档，D2 是对外架构图，draw.io 是最终交付件。
6.2 不存在统一的强弱排序
上一节的分项对比不是为了排出总名次，而是为了说明四个工具各占一个位置。总名次没有意义，因为它们优化的是不同的环节。
唯一有总名次的维度是 AI 生成友好度，那个维度的冠军是 Mermaid。除此之外，选谁只看你的图落在哪个需求上。
七、AI 协作的三条硬经验
7.1 AI 能不能写只解决了一半问题
真正决定维护成本的，是 AI 写出来的东西能不能被人轻易改对。前者是生成成功率，后者是可修正性。
可修正性取决于图的复杂度与 DSL 的表达边界是否匹配。一旦图的复杂度超过 DSL 的舒适区，AI 的错误会变得非常顽固，因为训练语料里复杂用例的高质量样本本就稀少。
7.2 两段式工作流优于一次到位
任何工具都不要指望一次生成就交付。正确做法是：AI 出草稿，人类做视觉反馈，定点修正，再交给 AI。
PlantUML 尤其适合这种流程，因为布局参数本身就需要人类看一眼才能调好。
7.3 把图的职责分开
同一份架构文档里，不同图承担不同职责。总览图进 README，用 Mermaid，要版本管理。详细设计图用 PlantUML，要 UML 语义严谨。对外架构图用 D2，要观感。物理部署图用 draw.io，要坐标精确。
四张图各用最合适的工具，比强迫一个工具包打天下高效得多。
八、一句话总结
AI Native 的冠军只有一个，就是 Mermaid。
这个结论来自它与 GitHub README 的深度绑定，让大量正确样本反复进入训练语料。这是事实，不需要打折。
但冠军身份不自动推导出冠军垄断。Mermaid 管生成，D2 管观感，draw.io 管打磨，PlantUML 管建模。四个环节各有一个最合适的工具，这才是完整的选型结论。
要 commit 进仓库、要 CI 渲染，选 Mermaid 或 PlantUML。要 AI 生成且观感漂亮，选 D2。要拿去给客户看、要控制像素，用 D2 或 draw.io 收尾。