Mermaid

流程一变，拖拽图里的节点和连线往往要重新整理。Mermaid 采用另一种思路：把图表结构写成文本，由渲染器生成图形。文本改了，图也跟着更新。

这让图表可以和 Markdown、代码及版本控制放在一起。Mermaid 在线平台又在开源 Mermaid.js 语法之上加入 AI、可视化编辑和团队协作，降低了手写语法的门槛。

先看一个最小流程图

flowchart LR
  A[提交申请] --> B{资料完整？}
  B -- 是 --> C[进入审核]
  B -- 否 --> D[退回补充]
  D --> A

这段文本既是图表的来源，也是可评审的记录。审批条件变化时，只需修改相应节点或连线；在 Git 中还能看到具体改了哪一行，而不只是发现一张图片被替换。上线前可用 mermaid.parse() 检查定义能否通过语法解析，但解析成功只说明语法成立，不会验证业务流程是否正确。

从需求到可维护图表

先写清图要回答的问题

“画一下系统架构”通常太宽。更有效的问题是：“用户请求经过哪些服务？”“失败时在哪里重试？”或“哪个系统拥有这份数据？”问题越具体，图越容易保持边界。

只做最小首稿

先保留关键节点、方向和判断条件，不要在第一版塞进所有细节。大型系统最好按上下文、容器或单一流程拆成多张图，否则文字写得再规范，读者也很难理解。

把源码和文档一起保存

如果使用的 Wiki、IDE 或文档站支持 Mermaid，可直接嵌入源码；不支持时再导出 SVG 或 PNG。团队应把文本源码视为主要资产，静态图片只是交付形式。

AI 能省下的是起稿时间

Mermaid AI 可以根据自然语言、PRD、会议记录或其他文件生成图表，也能通过对话调整标签、布局和样式。AI Repair 则用于帮助修正有问题的语法。

• 适合：从文字快速生成时序图、流程图或架构草稿。
• 需要复核：服务依赖、数据库关系、权限边界和异常路径。
• 不能混淆：成功渲染只代表语法成立，不代表系统描述正确。

可视编辑不是代码模式的对立面

不熟悉语法的成员可以在可视化编辑器中调整图形，熟悉代码的成员则可直接修改文本。比较理想的协作方式，是保留可追踪的结构，同时让非开发角色也能参与评审。

不过，自由排版能力仍不是 Mermaid 的强项。如果任务强调品牌视觉、手绘表达或像素级布局，图表设计工具会更合适。

Mermaid.js 和 Mermaid 平台要分开理解

有些 Markdown 环境已经内置 Mermaid.js，此时未必需要在线账户；需要 AI、共享空间或可视编辑时，平台服务才体现价值。

什么图适合，什么图会吃力

• 很适合：时序图、流程图、状态图、ER 图、甘特图和需要随文档更新的技术图。
• 可以使用：规模适中的架构与组织关系，但应主动拆图。
• 不太适合：自由手绘、复杂品牌视觉、需要大量任意摆放元素的协作白板。

把 Mermaid 嵌入网站时还要区分图表源码是否可信。官方配置中 securityLevel: strict 为默认值，会编码文本里的 HTML 并禁用点击；loose 会开放 HTML 与点击能力，sandbox 则在隔离 iframe 中渲染，但可能限制弹窗和外链等交互。不要为了启用链接就对用户提交的未知图表直接切到宽松模式。上传代码、数据库结构或内部 PRD 到在线平台前，也应另行核对团队计划的隐私和 AI 数据规则。

何时不该用代码画图

Mermaid 适合与代码和 Markdown 一起维护的技术图，但自由脑暴、多人工作坊和精细视觉排版不是它的主场。8 款脑图、流程图与在线白板的选型指南 给出了四类交付物的分流方法，可用于判断哪些图值得代码化。