首页/资讯中心/详情

Mermaid+AI：用自然语言生成流程图，提升技术文档与设计效率

Mermaid+AI：用自然语言生成流程图，提升技术文档与设计效率
📅 发布时间：2026/8/4 3:59:55

1. 从“手搓”到“口述”：流程图绘制的范式转移

画流程图这件事，对于任何一个需要梳理思路、设计系统、撰写文档的从业者来说，都像吃饭喝水一样平常。但这个过程，往往伴随着一种难以言说的“摩擦感”。你打开绘图工具，拖拽一个方框，输入文字，调整位置，再拖拽一个菱形，连线，调整箭头样式……整个过程机械、琐碎，且极易打断你的思维流。我称之为“手搓”流程图——你的精力被大量消耗在“如何画”而非“画什么”上。更别提当逻辑复杂、需要反复修改时，那种对齐、布局、格式统一的维护成本，足以让任何一个追求效率的人感到烦躁。

最近，一种新的工作流开始在我和身边不少技术同行的日常中流行起来：用自然语言描述你的逻辑，然后让 AI 结合 Mermaid 语法，直接生成可渲染的流程图。这听起来像魔法，但本质上，它解决的是一个核心痛点：将“思考逻辑”与“绘制图形”这两个任务解耦。你不再需要成为绘图工具的精通者，你只需要清晰地表达你的想法。Mermaid 作为一种基于文本的图表定义语言，提供了标准化的“图纸”；而 AI（特别是具备代码生成和理解能力的语言模型）则扮演了最懂你需求的“绘图员”。

这套组合拳，告别了“手搓”的笨拙，迎来了“口述”的流畅。它尤其适合快速原型设计、技术方案评审、文档即时插图以及思维整理。无论你是开发者、产品经理、系统架构师还是技术写作者，如果你曾为画图效率低下而苦恼，那么“Mermaid+AI”这条路径，值得你花时间深入了解。接下来，我将从一个实践者的角度，拆解这套工作流的核心环节、工具选型、实操细节以及那些只有踩过坑才知道的“甜点”与“雷区”。

2. Mermaid 语法精要：不只是“画图代码”

在拥抱 AI 之前，我们必须先理解 Mermaid 本身。很多人把它看作一种“画图的代码”，这没错，但低估了它的价值。Mermaid 的核心是一种声明式领域特定语言（DSL）。你声明节点和关系，它负责渲染和布局。这与我们熟悉的绘图工具（如 Visio, Draw.io, 甚至 PPT）的交互式、命令式操作有本质区别。

2.1 核心图类型与极简语法

对于流程图（Flowchart），掌握以下几个元素，你就能描述 80% 的场景：

  1. 图方向：声明图的流向，这是开头第一句。

    graph TD // 从上到下 Top-Down graph LR // 从左到右 Left-Right graph RL // 从右到左 graph BT // 从下到上

  2. 节点：用方括号[]或圆括号()定义。id[显示文字]或id(显示文字)。id是节点的内部标识，用于连接，可以简单如A,start。

    graph TD A[开始] --> B(处理数据) B --> C{判断条件} C -->|是| D[执行操作A] C -->|否| E[执行操作B]

  3. 连接线：定义节点之间的关系，箭头表示方向。

    • -->实线箭头
    • ---实线无箭头
    • -.->虚线箭头
    • ==>粗线箭头

  4. 子图（Subgraph）：用于将一组节点归类，这对于描述模块、系统边界至关重要。

    graph TD subgraph 客户端 A[UI交互] --> B[发送请求] end subgraph 服务端 C[接收请求] --> D[业务处理] end B --> C D --> E[返回响应] E --> A

仅仅这些，就构成了 Mermaid 流程图的基础骨架。它的美在于简洁和可读性。一段 Mermaid 代码本身，就是一份结构化的逻辑描述文档。即使不渲染成图，有经验的读者也能通过代码快速理解流程脉络。这是“手搓”图形无法带来的附加价值——你的图表源文件本身就是可版本管理、可差异对比、可协作修改的文本。

2.2 样式自定义：超越默认的审美

默认的样式可能略显单调，但 Mermaid 支持通过 CSS 类或直接样式定义进行美化。这不是必须的，但对于正式文档或演示，能提升不少专业性。

一种常见方式是在节点定义中直接使用style语句，或者为节点指定一个类，然后在外部或通过%%注释内的style指令定义类样式。

graph TD Start(开始) --> Process{有数据?} Process -->|是| ProcessA[数据处理] Process -->|否| End((结束)) style Start fill:#e1f5fe,stroke:#01579b,stroke-width:2px style Process fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#333 style ProcessA fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px style End fill:#ffcdd2,stroke:#c62828,stroke-width:2px

在实际使用中，尤其是与 AI 协作时，我建议初期不必过度追求样式。先专注于用准确的语法描述清楚逻辑结构。样式调整可以在生成基本正确的图表后，作为“优化步骤”手动微调，或者通过给 AI 更精确的样式指令来完成。分清主次，效率更高。

3. AI 如何成为你的“绘图助理”：提示工程是关键

现在来到最有趣的部分：如何让 AI 理解你的意图，并输出准确的 Mermaid 代码。这里的关键不是 AI 模型本身（无论是 GPT-4、Claude、DeepSeek 还是国内的各种大模型），而是你与它沟通的方式——提示词（Prompt）。

3.1 基础提示模式：从需求描述到代码生成

一个高效的提示，通常包含以下几个要素：

  1. 角色设定：让 AI 进入状态。

    你是一个资深软件架构师，擅长用 Mermaid 语法将复杂的业务流程和系统架构可视化。

  2. 核心任务：清晰、无歧义地说明你要什么。

    我将描述一个简单的用户登录流程，请为我生成对应的 Mermaid 流程图代码。流程如下：用户访问登录页面，输入用户名和密码，点击提交。系统先检查用户名格式是否有效（邮箱或手机号），无效则返回错误。有效则查询数据库验证密码，密码错误返回错误，密码正确则生成会话Token并跳转到首页。

  3. 输出约束：规定输出格式，避免多余废话。

    请只输出最终的、完整的 Mermaid 代码块，不要有任何额外的解释。使用graph TD方向。

将以上组合，发送给 AI。一个合格的“绘图助理”应该会返回类似下面的代码：

```mermaid graph TD A[用户访问登录页] --> B[输入用户名密码] B --> C{点击提交} C --> D[系统接收凭证] D --> E{用户名格式有效?} E -->|否| F[返回格式错误] E -->|是| G[查询数据库验证] G --> H{密码匹配?} H -->|否| I[返回密码错误] H -->|是| J[生成会话Token] J --> K[跳转至首页] F --> A I --> B ```

这个过程已经比“手搓”快了很多。但第一次生成的结果往往不尽如人意，可能需要调整。

3.2 进阶交互：迭代优化与精确控制

AI 并非一次就能完美理解你的所有隐含需求。你需要建立“迭代优化”的思维。

  • 问题1：布局混乱。AI 可能生成一个线性很长或布局奇怪的图。
    • 你的修正指令：“上面的流程图逻辑正确，但布局可以优化一下。请将‘格式检查’和‘数据库验证’这两个判断环节以及它们的后续分支，用子图（subgraph）组织一下，让结构更清晰。”
  • 问题2：节点命名不统一。有时用中文，有时用英文，或者描述过于口语化。
    • 你的修正指令：“将图中所有节点显示文字改为简洁的动宾短语，例如‘验证用户凭证’、‘查询用户信息’，保持风格一致。”
  • 问题3：缺少关键环节。你发现漏了“记录登录日志”这个步骤。
    • 你的修正指令：“在‘生成会话Token’之后，增加一个节点‘记录登录成功日志’，然后再连接至‘跳转首页’。”

这里分享一个核心心得：不要试图在一个提示词里描述所有细节。采用“大纲 -> 细化 -> 优化”的三段式方法。

  1. 第一阶段：用最简洁的语言描述核心主干流程，让 AI 生成骨架。
  2. 第二阶段：基于骨架，针对某个复杂分支进行详细描述，让 AI 补充细节，你再将细节代码合并进去。
  3. 第三阶段：整体审视，提出关于样式、布局、命名规范的优化要求。

这种交互方式，更像是在和一位理解力很强的实习生协作，你负责把握方向和关键决策，它负责高效执行和试错。你的思考负担，从“如何操作软件画出这个框和线”变成了“如何清晰地描述逻辑关系”，后者显然更接近问题的本质。

4. 实战工作流集成：让生成和渲染无缝衔接

有了 Mermaid 代码，下一步是把它变成可视化的图。这里有几个无缝衔接的工作流方案，可以嵌入到你日常的写作和开发环境中。

4.1 方案一：Markdown 编辑器 + 即时预览（最通用）

绝大多数现代 Markdown 编辑器或支持 Markdown 的笔记软件（如 Typora、VS Code with Markdown Preview Enhanced、Obsidian、Notion 等）都内置或通过插件支持 Mermaid 渲染。

  • VS Code：安装Markdown Preview Enhanced插件。在.md文件中写入 Mermaid 代码块，指定语言为mermaid，然后在预览窗口就能实时看到渲染后的图表。这是开发者的首选，因为无需离开编码环境。
  • Obsidian：需要安装Advanced Tables等社区插件来获得更好的 Mermaid 支持，但其核心编辑器对 Mermaid 的兼容性越来越好。优势在于图表直接存储在笔记库中，成为知识网络的一部分。
  • Typora：开箱即用，输入代码块后直接渲染为图片，体验非常流畅，适合纯写作场景。

操作流程：

  1. 在 AI 对话窗口中，获得优化后的 Mermaid 代码块。
  2. 复制代码块内容。
  3. 在你的 Markdown 编辑器中，新建一个代码块，语言设置为mermaid，粘贴内容。
  4. 实时预览图表，如果不满意，可以微调代码或返回 AI 进行下一轮优化。

4.2 方案二：专用渲染与导出工具

有时你需要将图表导出为图片，嵌入到 PPT、Word 或设计稿中。

  • Mermaid Live Editor：官方的在线编辑器。将代码粘贴进去，实时渲染，并可以直接导出为 PNG 或 SVG 文件。SVG 格式是矢量图，无限缩放不模糊，非常适合印刷和高清演示。
  • 命令行工具：对于需要批量生成或集成到 CI/CD 流程中的极客，Mermaid 提供了@mermaid-js/mermaid-cli包。你可以通过 npm 安装，然后用一条命令将.mmd文件转换为图片。
    npm install -g @mermaid-js/mermaid-cli mmdc -i input.mmd -o output.png -t dark -b transparent
    这允许你将图表生成自动化，例如，每次编译文档时，自动从 Mermaid 源代码生成最新版本的图片。

4.3 方案三：与文档平台集成（如 GitBook、Confluence）

许多知识库和文档平台现已原生支持 Mermaid。例如，在 GitBook 或 Confluence 中，直接插入 Mermaid 代码块即可渲染。这意味着，你的系统设计文档、API 文档中的流程图，其“源代码”就是可读、可维护的文本，而不是一张张难以更新的图片附件。团队协作时，成员可以直接修改代码块来更新流程图，版本历史清晰可见。

一个完整的场景示例： 假设我正在设计一个微服务架构下的订单处理流程，我需要将其写入技术设计文档。

  1. 思考与口述：我对着 AI 说：“描述一个电商订单处理流程。用户下单后，订单服务创建订单，并发送‘订单创建’事件到消息队列。库存服务监听该事件，执行库存预占。支付服务等待用户支付，支付成功后发送‘支付成功’事件。订单服务监听支付事件，将订单状态更新为‘待发货’，并通知物流服务。”
  2. AI 生成初稿：AI 返回一段包含orderService,inventoryService,paymentService等节点和事件箭头的 Mermaid 代码。
  3. 本地渲染与检查：我将代码复制到 VS Code 的 Markdown 文档中预览。发现事件流向的箭头不够直观，想区分同步调用和异步事件。
  4. 迭代优化：我指示 AI：“将同步 HTTP 调用改为实线箭头，将通过消息队列的异步事件改为虚线箭头。并为每个服务添加一个子图背景框。”
  5. 最终定稿与导出：获得满意的代码后，我将其留在 Markdown 文档中作为源文件。在需要制作演示文稿时，我使用 Mermaid Live Editor 打开这段代码，导出为 SVG 矢量图，插入到 PPT 中。

这套工作流，将设计、绘图、文档三个环节流畅地串联起来，中间没有格式转换的损耗，也没有工具切换的割裂感。

5. 避坑指南：当 AI 不理解你的“常识”

尽管“Mermaid+AI”很强大，但实践中一定会遇到问题。AI 毕竟不是人，它缺乏你的领域知识和上下文“常识”。以下是我踩过的一些坑及解决方案。

5.1 逻辑正确，但图形语义错误

这是最常见的问题。AI 生成的代码，流程逻辑也许是对的，但用的图形元素不符合约定俗成的规范。

  • 坑点：用矩形框[]表示判断，用菱形{}表示普通步骤。
  • 根因：AI 从海量数据中学习，但 Mermaid 的特定语义（菱形=判断，圆角矩形=开始/结束）可能没有被足够强地关联。它只学到了“用不同形状区分节点”，但没学到“具体用什么形状代表什么”。
  • 解决方案：在初始提示词中就加入图形语义的强约束。

    “请使用 Mermaid 语法生成流程图。注意：所有决策判断点请使用菱形框{}，所有开始/结束节点请使用圆角矩形()，普通处理步骤使用方框[]。流程描述如下：...”

通过前置规则，可以极大减少这类低级错误，节省后续修正的沟通成本。

5.2 布局的“审美”灾难

Mermaid 的自动布局算法有时会产生令人费解的布线，比如连线过长、交叉过多、节点排列稀疏。

  • 坑点：生成的图可读性差，需要手动调整。
  • 根因：Mermaid 的布局引擎为了追求通用性，不会像人类一样去理解“模块化”和“视觉分组”。
  • 解决方案：
    1. 积极使用子图：用subgraph将逻辑上紧密相关的节点包裹起来。这不仅是语义分组，也能给布局引擎强烈的提示，让它在布局时倾向于将子图内容保持在一起。
    2. 使用不可见节点引导流向：这是一个高阶技巧。有时你可以添加一个style为visibility:hidden的节点，或者使用&符号创建虚拟节点，来引导连线的路径，避免交叉。
    3. 接受不完美，后期微调：对于非常复杂的图，可能最终需要在 Mermaid Live Editor 中手动调整个别节点的位置（通过linkStyle或interpolate等高级语法，但这较复杂）。一个更务实的态度是：优先保证逻辑正确和内容清晰，美观度达到80分即可。追求100%的自动美观布局，在当前技术下可能投入产出比不高。

5.3 复杂分支与循环的表述歧义

描述带有嵌套循环、并行处理或异常处理的流程时，自然语言本身就有歧义，AI 容易误解。

  • 坑点：循环的边界不清晰，异常处理流程没有正确地从主流程中分离。
  • 根因：你的描述可能是“如果验证失败，则重试，最多三次”，但 AI 可能画成一个简单的三节点线性重试，而不是一个带计数器的循环判断框。
  • 解决方案：用更结构化、更接近程序逻辑的方式描述。
    • 不好的描述：“验证失败就重试，最多三次。”
    • 好的描述：“初始化重试计数器 retry=0。进入一个循环：首先进行验证步骤。如果验证成功，则退出循环进入下一步；如果验证失败，则令 retry 加1。然后判断 retry 是否小于3：若是，则继续循环进行验证；若否（即 retry 等于3），则退出循环，进入‘验证最终失败’的处理流程。” 虽然看起来啰嗦，但这样描述极大地消除了歧义，AI 几乎能一字不差地将其转化为准确的 Mermaid 判断和循环结构。这要求我们在向 AI 描述时，自己也进行一遍逻辑的严格梳理，本身就是一种有益的思考锻炼。

6. 超越流程图：解锁 Mermaid 的更多可能性

流程图只是 Mermaid 的冰山一角。当你熟悉了“文本描述生成图表”的范式后，完全可以将其扩展到其他类型的图表上，用同一套思维工具提升更多场景的效率。

6.1 序列图：描述交互时序的利器

序列图在描述 API 调用、模块间交互、用户操作序列时无可替代。用自然语言描述时序，让 AI 生成 Mermaid 序列图代码，体验同样惊艳。

示例提示词：

“生成一个 Mermaid 序列图，描述用户通过客户端访问 Web 应用的简单过程。参与者包括：用户、浏览器、Web服务器、数据库。流程是：用户向浏览器输入 URL，浏览器向 Web 服务器发起 HTTP GET 请求，Web 服务器处理请求时向数据库查询数据，数据库返回数据，Web 服务器组装 HTML 响应返回给浏览器，浏览器渲染页面呈现给用户。”

AI 生成的代码，在支持 Mermaid 的编辑器里渲染出来，就是一幅标准的、布局整齐的序列图。这对于快速绘制架构交互图、排查时序问题非常有帮助。

6.2 类图：快速勾勒系统结构

在早期设计阶段，快速画出核心的类及其关系，有助于厘清思路。虽然不如专业的 UML 工具精细，但 Mermaid 类图用于快速表达和沟通绰绰有余。

示例提示词：

“用 Mermaid 语法画一个简单的类图。有一个User类，有属性id、username、email，和方法login()、logout()。有一个Order类，有属性orderId、totalAmount、status，和方法create()、cancel()。User和Order之间的关系是：一个User可以拥有多个Order，一个Order属于一个User。”

6.3 甘特图：管理项目进度

甚至可以用它来画甘特图，虽然功能比专业软件简单，但对于小型项目或个人任务规划，直接在文档中用文本定义任务和时间，非常轻便。

思维转变的价值：学习“Mermaid+AI”的核心，不在于掌握多少种图表语法，而在于接受并熟练运用“声明式图表描述”这一范式。你的大脑从思考“怎么画”转变为思考“是什么”和“有什么关系”，这才是效率提升的本质。当你需要一张图时，你的第一反应不再是打开某个绘图软件，而是思考“如何用简练的语言定义它”。这种思维模式，会让你在技术设计、文档编写、甚至口头沟通时，都更加结构化和清晰。

7. 个人实践心得：效率提升与思维重塑

使用这套方法近一年，它已经彻底改变了我处理图表的方式。分享几点最深切的体会：

第一，效率的提升是非线性的。初期你需要同时学习 Mermaid 基础语法和如何与 AI 有效沟通，有一个小小的学习曲线。但一旦跨越，效率是碾压式的。过去画一个中等复杂度的系统上下文图，从打开工具到调整满意，可能需要半小时。现在，从理清思路到生成可用的图表代码，往往不超过5分钟。更重要的是，修改成本极低。需求变了？不用在图形界面里拖来拖去，只需修改或让 AI 重写一段文本描述即可。

第二，它促进了更好的设计。“手搓”流程图时，因为修改麻烦，我们常常倾向于在头脑中“脑补”一个简单模型就开始画，或者避免画太复杂的图。而“口述”生成的方式，鼓励你在动手（其实是动口）之前，更深入、更结构化地思考整个流程。你会更自然地思考“这个判断有几个分支？”“这个异常情况如何处理？”，因为你需要用语言清晰地表达出来。这个过程本身就是一个高质量的设计复盘。

第三，它实现了文档与图的“源文件合一”。我的技术设计文档现在全是 Markdown 格式，里面嵌入的 Mermaid 代码就是图表的“源代码”。它和周围的文字描述一起被 Git 管理。评审时，同事可以直接在 PR 中建议修改某行代码来调整图表逻辑，这比说“把第三那个框往左挪一点”要精确一万倍。图表不再是孤立的、易丢失的附件，而是活的、可版本控制的文档组成部分。

当然，它并非万能。对于需要高度自定义美学设计、像素级精确对齐的正式发布物（如书籍插图、宣传海报），专业绘图工具仍是不可替代的。但对于占日常工作 90% 以上的沟通、设计、文档场景，“Mermaid+AI”的组合已经足够强大，强大到让我再也回不去那个“手搓”的时代。

最后一个小技巧：建立一个你自己的“提示词库”。将那些针对特定图表类型（如“微服务架构图”、“数据流程图”、“状态机图”）打磨好的、高效的提示词片段保存下来。下次需要时，稍作修改即可使用，这将让你的“绘图”速度达到新的高度。真正的效率，来自于将重复性劳动转化为可复用的知识资产。