上个月做内部方案评审我坐在会议室里对着白板发呆。要讲的是“订单超时未支付自动取消”的完整链路我试图在白板上画清楚状态流转、定时任务、支付回调、库存释放这几条线的先后关系。画了大概五分钟最开始的箭头已经被擦了三轮坐我旁边的工程师默默掏出手机拍了张白板照片跟我说要不你把需求文字发我我来理那次的结局是我回去花了一个小时用绘图工具重新画了一版边画边改等画完评审会早就结束了。后来我接触了 diagram-design 这类让 AI 根据自然语言直接生成图表的思路实测使用了一段时间后想把它背后的原理、用法和那些文档里不会写的坑完整聊一聊。这篇文章不讲空泛的概念就直接说它到底能做什么、怎么写出好用的 Prompt、实际项目里会踩什么坑以及如何把生成结果变成团队真正可维护的文档资产。无论你是要画流程图、时序图、类图还是状态图都可以照着下面的方法直接上手。1. 为什么说让 AI 画图的关键不是画图而是把需求说清楚1.1 手动画图的真正痛点布局、改版、图文分离先说说我在用 AI 画图之前手动绘图到底烦在哪里。第一是布局压力。一张流程图只要分支超过五条方框的位置就会影响整张图的可读性。我经常花大量时间在对齐、拉线、调整间距上而不是在思考流程本身。画完之后回头一看真正有价值的还是那一串节点和箭头花了最多精力的排版反而是最不该由人来做的事。第二是改版成本。业务需求一变图就得跟着动。这时最要命的不是某个框删掉而是它牵扯到的前后连线、跨层引用、判断条件统统要重排。改一版图的时间比改一次需求文字还久于是很多人最后就不改图了改着改着图就和现状彻底脱节。第三是图文分离。需求文档是一份文件图表是另一份文件评审讨论时候你很难同时维护两边的对应关系。文字改了图忘了改图改了文字没跟上。时间一长文档和图互为矛盾新成员看哪个都信不过。这些痛点的核心是同一个图表本身是需求的“投影”它的重点是逻辑结构而不是画布上的位置。而手动绘图工具把这两件事强绑在一起让人不得不同时处理“思考”和“排版”两个任务自然效率低。1.2 diagram-design 是什么一句话到一张图的翻译器diagram-design 本质上是一个”自然语言到图表代码“的转换工具。它接收一段描述性的文字输出一份结构化的图表定义代码然后由支持该语法的渲染器把代码变成实际可视化的流程图、时序图等。对于大部分技术场景输出用的都是 Mermaid 语法它有专门的结构表达方式非常适合表达顺序、分支、状态转移和实体关系。我第一次试用的感受很直接。我输入了一句“用户下单后系统先校验库存库存不足则返回提示库存充足则创建订单并调用支付接口支付成功后通知仓库发货”它立刻给我生成了一张结构完整的流程图。分支、判断、结束节点都在排版也足够清晰。对比我那天在白板上的狼狈这种体验确实让人眼前一亮。它适合的人群很多写技术方案的人用它快速出草图产品经理用它梳理业务链路开发工程师用它把接口调用顺序画成时序图甚至带新人的导师可以快速把系统流程画出来作为讲解材料。它解决的核心问题是把“脑子里或文字里已经存在的需求描述”快速翻译成“一张能反映逻辑的图”省去手动排版的时间。1.3 先明确边界它擅长结构不擅长美化不过这里必须先说清楚一件事diagram-design 不是万能的画图工具。它擅长的是结构化图形的生成也就是节点、箭头、分支、状态、实体关系这类能“用规则描述”的内容。它不擅长做精细排版和艺术美化。如果你想让它生成一张可以放在融资 PPT 首页那种极致美观的架构图或者要画一张只有特定业务逻辑才能推导出来的跨层网络拓扑图那它给你的初稿大概率只能算“逻辑正确颜值一般”。所以正确的心态是把它当“草稿快速生成器”和“逻辑校验器”而不是“最终视觉设计师”。我用它的时候90% 的场景是把生成的代码当作底稿再在需要精修的地方手工调整。至于哪些图值得手工精修、哪些图直接就能用后面章节我会根据自己的实测给出判断。2. 先摸清能力边界diagram-design 能稳定产出的几类图2.1 流程图与决策图最可靠的一档在我测过的所有类型里流程图和决策图是 output 最稳定的。因为流程本身的描述方式和人们对一行文字的理解方向高度一致顺序、分支、汇合这些都是自然语言中非常常见的表达AI 在解析时不容易出偏差。通常我会这样写 Prompt请生成一个流程图描述用户在小程序提交订单后的处理逻辑 用户提交订单系统先校验库存 库存不足则返回失败提示流程结束 库存充足则创建订单调用支付接口 支付成功后通知仓库发货同时发送短信通知用户 支付失败则订单标记为待支付流程结束。它生成出来的 Mermaid 代码大概是这个样子需要说明的是下面这段是源码你可以直接让渲染器画出来graph TD A[用户提交订单] -- B{库存校验} B -- 库存不足 -- C[返回库存不足提示] B -- 库存充足 -- D[创建订单] D -- E[调用支付接口] E -- F{支付结果} F -- 支付成功 -- G[通知仓库发货] F -- 支付成功 -- H[发送短信通知用户] F -- 支付失败 -- I[订单标记为待支付]这种输出的可靠性很高。但有两个细节会影响质量第一分支条件如果用“否则”这类模糊词容易被简化第二多个并发动作如果不显式说明“同时执行”它可能会帮你排成先后顺序。想让并发更准确就在 Prompt 里明确写“支付成功后同时通知仓库发货和发送短信给用户”而不是笼统说“然后”。2.2 时序图接口设计评审最顺手时序图是我个人在接口设计中用得最多的类型因为它非常擅长展示多个角色之间的消息往返顺序。用 diagram-design 生成时序图的体验也不错前提是你要把它理解为一个“讲顺序”的过程。你只要描述清楚谁先调用谁、每个请求的返回是什么、中间是否有异步回调它就能生成带参与者和消息箭头的时序图。举个例子我写下面这些内容画一张时序图描述用户请求重置密码的过程 用户在前端页面点击重置密码前端向后端发送获取验证码请求 后端生成验证码并发送邮件给用户 用户查收邮件后在前端提交新密码和验证码 后端校验验证码校验通过后更新密码并向前端返回更新成功通知。输出如下这一段同样可以直接用支持 Mermaid 的渲染器查看sequenceDiagram participant U as 用户 participant F as 前端 participant B as 后端 participant E as 邮件服务 U-F: 请求重置密码 F-B: 获取验证码 B-E: 发送邮件 E--U: 验证码邮件 U-F: 提交新密码与验证码 F-B: 校验并更新密码 B--F: 更新成功通知 F--U: 提示更新成功需要注意默认参与者如果少它会自动命名成 A、B、C 这种很难看的代号。所以对于重要的角色一定要在 Prompt 里把“用户”“前端”“后端”这类名词写清楚否则出来的图别人看不懂。另外一个坑是“同步调用”和“异步回调”的区别它不一定能准确区分。如果你的场景里存在回调建议在描述里明确写“这里回调”“这个响应是异步返回的”等指导性词汇。2.3 类图与 ER 图写建模草稿的加速器类图和实体关系图是日常开发中非常常用但手动绘制很费时间的类型。用手动工具画一张 20 个字段的 ER 图光调整字段排版就能吃掉半小时。而 diagram-design 在这类场景表现意外地好因为你只需要描述实体名称和它们之间的关系标签。例如我想表示用户和订单的关系可以写生成一个 ER 图一个用户可以拥有多个订单一个订单包含多个商品 用户有 id、用户名、邮箱字段 订单有 id、订单状态、创建时间字段 商品有 id、名称、价格字段。对应生成的代码类似erDiagram USER ||--o{ ORDER : places ORDER ||--|{ ORDER_ITEM : contains PRODUCT ||--o{ ORDER_ITEM : includes USER { int id PK string name string email } ORDER { int id PK string status datetime created_at } PRODUCT { int id PK string name decimal price }每次看到这种输出我都觉得类图和 ER 图是“高结构化、低美感需求”的典型代表和这类 AI 生成工具真是绝配。不过要提醒的是生成后一定要人工检查字段类型和主外键标注因为这类细节极其容易出错它适合帮你搭骨架不适合帮你背书。2.4 状态图与甘特图低频但关键时刻能救场状态图是我原本预期它做不好、但实测还不错的一类。尤其是订单状态机这种经典业务场景用自然语言列举状态转移条件后它生成的stateDiagram-v2结构很清晰。比如画一个订单状态图 订单创建后处于待支付状态 支付成功进入已支付 超时未支付进入已取消 已支付后仓库发货变成已发货 用户确认收货后变成已完成。生成的代码大致如下stateDiagram-v2 [*] -- 待支付 待支付 -- 已支付: 支付成功 待支付 -- 已取消: 超时未支付 已支付 -- 已发货: 仓库发货 已发货 -- 已完成: 用户确认收货 已完成 -- [*]甘特图则更适合排期类的需求你可以输入任务名称、起止时间、依赖关系它会输出横道图。实测下来它更适合展示静态的执行计划不太适合做需要频繁拖拽调整的项目排期毕竟项目管理工具本身已经有了更好的交互方式。但这张能力在写方案、做汇报时能省不少事。2.5 需要降低期待的类型在我测试中以下类型输出质量相对一般需要做好手工补救的心理准备。首先是复杂网络架构图。比如多数据中心、多层级网络、安全域的架构表示这类图有大量的嵌套分组和跨层连线自然语言描述很容易让 AI 在分组归属上犯迷糊。其次是精细 UI 线框图它毕竟不是专门做原型设计的生成出来的界面结构能看出布局但离可直接使用的原型还差得远。最后是大型整体架构图节点一旦超过二三十个它的布局算法和人类审美会明显脱节需要你重新调整分组和层级。我把实测能力边界整理成了一张表方便自己后续选型时快速判断图表类型可靠程度主要用途需要人工介入的程度流程图 / 决策图高业务梳理、方案展示低时序图高接口设计、流程评审低类图 / ER 图高数据建模、代码设计中需校对字段状态图中高状态机梳理低甘特图中计划展示中复杂架构图 / 线框图低总体概览高建议手绘为主这张表其实就是我自己的“期待值管理清单”提前知道它哪里强哪里弱使用的时候心情会平和很多。3. 从一句话到一张图的完整工作流Prompt 才是真正的门槛3.1 一个能稳定复用的 Prompt 模板工具本身再强Prompt 写得糊输出一样糊。我踩过几次坑之后总结了一条公式现在每次输入都按这个结构来。写 Prompt 的四步是先指定图表类型再交代场景背景然后说起点和终点最后把分支和关键约束显式列出来。举个标准模板我会这么写请生成一个{流程图/时序图/类图/状态图}场景是{一句话背景描述}。 流程从{起点}开始到{终点}结束。 过程中存在这些分支 1. 如果是{条件A}执行{动作A} 2. 如果{条件B}则执行{动作B}。 另外请注意{这里填写并发、异步、别名、方向等特殊要求}。这个模板看着简单但它把最容易导致 AI “自由发挥”的几个变量都框定了。指定类型是让它的输出符合你的预期背景场景是给 AI 上下文起点终点是框住范围显式列分支是防止条件被简化最后的特殊要求是补上那些自动解析容易漏掉的细节。3.2 完整案例把一句模糊需求变成可发布的图我用一个真实经历来说明 Prompt 的重要性。最开始我只是写了句“我看一眼登录流程帮我画个图”结果生成出来的图平平无奇分支条件只有成功和失败两条缺少验证码校验和账号锁定这些关键节点。第二次我改用模板写的是请生成一张流程图场景是网页端账号登录。 流程从用户输入账号密码开始到用户成功进入首页或看到错误提示结束。 分支包括 1. 如果账号不存在提示“用户未注册” 2. 如果密码错误提示“密码错误” 3. 如果密码错误累计超过 5 次锁定账号并提示“账号已锁定” 4. 如果校验通过跳转到首页。 注意账号锁定动作要独立成一个节点不要把提示文案写在分支线上。这次的输出质量明显提升关键节点都在锁定操作也按要求独立出来了。只需要做了两处微调一个是给判断节点起了更明确的名字另一个是调整了其中两条连线的颜色用于区分“异常路径”和“成功路径”。这个例子说明了一个道理不是 AI 不会画而是我一开始根本没把自己的需求描述清楚。它只能从文字里还原逻辑文字里没有的约束它不可能凭空变出来。所以与其说我们在使用 AI不如说是在用它倒逼自己把逻辑讲完整。3.3 生成结果如何接入现有文档拿到一份还不错的 Mermaid 代码之后接下来的问题是怎么把它用起来。这里有几个已经验证过的路径。最轻量的是直接在你的 Markdown 文档中嵌入代码块大部分文档平台和代码仓库都自带 Mermaid 渲染粘贴即可显示成图。这样图和文字同步更新改代码就等于改图彻底告别“图文不一致”。稍微重点的是导出成图片文件再插入 PPT 或者在线文档这个过程可以用命令行工具批量完成后面章节我会给出具体方案。第三个路径很多人会忽略把 Mermaid 源码当作一种“可读的图”。即使不渲染光看代码里的节点名和箭头就能读懂大部分逻辑。这意味着它可以直接进入代码评审比如给某个模块画流程图时你甚至不需要截图直接把源码发给同事对方看代码就知道你想表达什么。3.4 第二种用法让 AI 审你自己的图同一个工具不只是“从文字生成图”它还能反向工作。我会把已经画好的 Mermaid 代码扔给它让它把图里的逻辑用文字复述一遍再检查有没有分支遗漏。比如我会写“请看下面的流程图代码帮我检查是否存在分支条件缺失、循环未闭合、或者某些节点从未被引用的问题。”它通常能从逻辑角度找出几个我漏掉的边角情况。这个能力尤其在画复杂状态机时很有用人脑看多了容易默认某些路径不存在而 AI 会把所有可能路径穷举给你看。用一次就会上瘾。这个方法还有一个变体让 AI 根据你的图生成测试用例。它会把每个分支路径提取出来生成覆盖这些路径的用例列表对做技术方案评审和测试设计的人来说属于额外赚到的价值。4. 真实使用中踩过的坑四种典型翻车现场4.1 中文节点和超长文本图不丑但字挤成一团第一次在正式文档里用生成结果时我就遇到了中文文本不换行的问题。节点里写“用户提交订单并成功创建支付单”渲染出来文字被压缩成一大块整个节点变成一个长条特别难看。后来我才意识到问题出在节点命名上。Mermaid 语法里节点文本默认不会自动折行如果输入的内容太长渲染端就会硬塞。解决办法有两个。第一个是给节点起短名字把长描述放到节点标签上。第二个是主动在节点文本里加换行标记像br/这样的 HTML 换行标签在多数渲染端都能生效。我后来的习惯是Prompt 里就明确写“节点名称尽量控制在 4 到 8 个字详细动作放节点内部”这样生成出来的图一开始就是干净的。还要提一个细节判断节点的文案不适合写成长句。比如“库存是否充足”直接作为判断框内容比“检查当前订单中商品库存量是否大于用户购买数量”好读得多。详细逻辑可以在图下方的说明段落里补图本身要承担的是扫一眼就懂的职责。4.2 复杂分支被悄悄省略AI 生成分支条件时有个让我头疼的问题它会把“否则”简化成一条直接路径。比如我写“如果用户是会员走会员价否则走普通价”它有时候会生成一个判断框只画了“是会员”的路径把“否则”当成一条隐含的默认线不单独画出来。这在语义上不算错但在图表展示上就是漏信息。很多评审者看了图会追问“那非会员的路径在哪”你解释半天效果还不如一开始就把分支写清楚。针对这个问题最有效的办法是在 Prompt 里把所有分支以列表形式显式写出而不是用“如果……否则……”这种半模糊句式。另外可以加一句“所有分支都要有对应的节点和连边不要省略任何路线”给生成结果一个明确的指令。实测这句话能明显降低漏分支的概率。4.3 渲染平台版本不一致导致语法报错一个让我特别无语的场景是同样的 Mermaid 代码在本机渲染正常同事的机器上就报语法错误。原因其实很简单不同版本的 Mermaid 对语法特性的支持不同。比如某些新引入的节点样式、箭头类型在旧版本上就不认识。这个问题在接入 CI 后变得非常麻烦因为构建机上的渲染器版本往往和你本机的不一致。我遇到过一次最夸张的情况是某段代码本地显示完美到 CI 上直接失败最终排查下来是箭头定义方式在那个版本上不受支持。解决思路有两个方向第一种是统一版本把渲染器固定在项目依赖里版本锁定之后本机和 CI 跑的是同一套代码问题自然消失。第二种是尽量使用兼容性最好的基础语法不要用各种“看起来很炫”的扩展特性。其实从沟通角度出发基础语法已经能表达绝大多数场景花哨语法带来的收益远低于它带来的兼容性风险。4.4 布局方向不可控要纵向偏给横向默认情况下流程图的方向可能和你预期不一致。比如我想让流程从上往下画体现层级递进感它默认生成了从左往右的布局把一张流程硬生生拉成了横向长条打印的时候差点超出页面。这个问题的解决方法最直接在 Prompt 里或者生成的代码里显式声明方向。Mermaid 的graph TD表示从上到下graph LR表示从左到右。如果你发现自己多次生成的方向都不对就养成在 Prompt 里写“请使用从上到下的排版方向”的习惯。不过我也意识到过度纠结方向其实没有太大必要因为图的结构清晰度比方向重要得多。只要逻辑关系清楚横向或者纵向都不影响表达。我把这个坑写出来更多是想提醒你如果对方向有执念先定规则别等生成完再手动拖拽。4.5 实践后的避坑速查表我把以上几条集中整理一下方便以后踩坑时快速对照常见症状根因处理方式中文节点文字挤成块节点文本过长或不换行节点用短名长文放节点内必要时用br/换行分支路径缺失Prompt 中分支表述模糊用列表显式列出所有分支并声明不要省略同一代码不同环境报错渲染器版本不一致锁定版本使用兼容语法布局方向不符合预期未声明方向Prompt 中明确“从上到下”或“从左到右”这张表已经成了我团队里的内部参考遇到问题先查表能省下不少排查时间。5. 把图表变成文档资产团队协作和版本管理的进阶玩法5.1 图的源码入库比截图更经得起时间我最早用生成图的时候习惯是截图保存到文档里。后来发现这有一个致命问题图一旦需要修改原始代码和图片来源对不上只能从头再画一遍。后来我把 Mermaid 源码文件比如.mmd文件纳入了代码仓库和普通代码一样提交、评审、合并。图的源码入库之后所有历史版本都保存在 git 记录里每次改动可以通过 diff 看到具体改了什么节点、改了哪条连线。这比看两张截图对比有效率得多。这么做还有一个好处截图会失真源码不会。只要渲染器代码还在任何时候都能重新生成清晰的图片不受分辨率影响。团队新成员拿到一份图看到的不仅是一张静态图片还有它背后的构建方式。5.2 在 CI 里自动渲染导出失败直接阻断发布既然源码入库了下一步就是让它在构建流程里自动变成可发布的图片。用命令行渲染工具可以做到这一点我在脚本里对每个.mmd文件循环处理导出成 SVG 或 PNG渲染失败就让流水线直接失败退出。一个典型的批量导出脚本大致长这样#!/bin/bash for file in diagrams/*.mmd; do echo 渲染文件: $file mmdc -i $file -o ${file%.mmd}.svg if [ $? -ne 0 ]; then echo 渲染失败阻断流程: $file exit 1 fi done把这个脚本挂到持续集成流水线里后只要有人提交了语法错误的图表代码构建立刻失败问题在合并前就会被发现。这个机制看起来简单但它把“图表代码正确性”从人为判断变成了自动化检查对团队协作的规范性提升很大。同时还能在每次构建后生成一份最新的图片产物让文档站点或报告直接引用。5.3 多人评审时怎么看图关注逻辑不关注配色多人协作时还有一个要点评审图的重点应该是逻辑而不是样式。我参加过的图表评审里经常出现大家花大量时间讨论“这个框应该用蓝色还是绿色”“箭头是不是应该带虚线”这类问题。说实话对逻辑表达而言这些都是可选项。真正需要关注的是节点所代表的业务动作是否正确、分支条件是否覆盖完整、时序消息的先后是否准确。所以我现在会引导评审者去看源码 diff而不是看图的美观度。用源码 diff 评审时变化一目了然新增了什么节点、删掉了哪条路径、某个箭头从实线变成了虚线这些都对应着业务逻辑的变化。相比肉眼在那张图里找不同代码比对要精确得多。5.4 和团队角色如何分工用了一段时间后我觉得在这个工作流里设计师、开发工程师和 AI 各自的定位是可以分工清楚的。设计师适合输出风格模板和精修规则对最终展示质量负责开发工程师负责把流程逻辑转化成准确的 Prompt 和 Mermaid 源码并维护构建流水线AI 负责把描述快速转化为草稿和结构骨架。这个分工最舒服的地方在于每个人都只做自己擅长的事AI 承担的是最枯燥的“从文字到结构化”这一步。这也解释了为什么我不建议让 AI 一步到位生成最终图片。它生成的是“逻辑半成品”还需要人来确认边界和补充细节。真正的流程是人描述逻辑AI 画草稿人审逻辑AI 按要求微调最后人做视觉定稿。这条链路跑顺之后出图效率比纯手工操作至少翻倍。6. 实际体会别把它当画师当白板6.1 不同阶段的不同定位用了几个月之后我对 diagram-design 的定位发生了很大变化。刚开始我是把它当成“画图工具”来用的希望它直接生成能发的成品图。后来发现它更像一块智能白板。在思路探索阶段我随手输入一句需求描述它快速画出一张初稿我盯着图看哪里不对再改 Prompt再生成。这个“输入-生成-推翻-再输入”的循环速度足够快反而比在白板上折腾更有助于理清思路。你可以把它当成一种“可视化的思维草稿纸”这比它作为“最终成品生成器”的价值大得多。到了方案评审阶段我再把初稿导出手工调整节点颜色、间距和标题最后变成一张正式图。也就是说在不同阶段它的使用方法完全不同。我建议你一开始就把它定位成“第一稿生成器”这样使用心态会好很多不会因为“生成的图不够美”而失望。6.2 一个小技巧先圈动词再交给 AI分享一个我实际用下来觉得最提升生成质量的技巧写 Prompt 之前先把你需求描述里的动词圈出来。比如“用户提交订单系统校验库存创建订单调用支付通知仓库发货”里动词就是提交、校验、创建、调用、通知。把这些动词按顺序理一遍每个动词对应一个节点整个流程的骨架就出来了。这时候再补上主语、条件和分支交给 AI 的 Prompt 就天然清晰。这个技巧的原理很简单流程图本质上就是“动作的有序组合”动词是动作的浓缩。AI 的能力再强也需要在文字里识别动作词你把动作词显式列给它它就不容易乱编。我现在无论是自己画图还是帮别人调试生成结果都会先问一句你这里面核心的动作是哪几个6.3 它改变了我画图的方式但没有消灭手绘最后讲讲我对这类工具的最终看法。它确实改变了我画图的方式以前我画图是“先想清楚再落笔”现在我可以“边描述边生成边修正”整个过程更像是在对话中把逻辑逼出来。特别是当你面对一个并不完全清晰的需求时用 AI 快速画出几种可能的路径图再逐一对比比凭空想象要靠谱得多。但它没有消灭我用手绘图。在某些高度模糊、充满不确定性的讨论场景比如白板画拓扑、画地图式的自由联想图手动绘图那种“边画边想”的质感依然是 AI 给不了的。AI 适合的是把清晰逻辑变成图形而人适合探索那些还不清晰的逻辑。所以我的总结只有一句把 AI 当画师你会失望把它当白板你会惊喜。真正核心的思考能力还是你自己的AI 只是把你脑中的结构翻译成了别人能看见的东西。平时画图不妨就先圈动词、写明分支、让它出一稿你再从这稿开始雕琢慢慢你就会发现画图这个事儿最大的瓶颈早就不是工具而是你能不能把自己的需求说清楚。 
长河君 · 2026/10/13 11:28:22 · 阅读 1.2k AI生成流程图实战：从自然语言到Mermaid文档的全流程指南
上个月做内部方案评审我坐在会议室里对着白板发呆。要讲的是“订单超时未支付自动取消”的完整链路我试图在白板上画清楚状态流转、定时任务、支付回调、库存释放这几条线的先后关系。画了大概五分钟最开始的箭头已经被擦了三轮坐我旁边的工程师默默掏出手机拍了张白板照片跟我说要不你把需求文字发我我来理那次的结局是我回去花了一个小时用绘图工具重新画了一版边画边改等画完评审会早就结束了。后来我接触了 diagram-design 这类让 AI 根据自然语言直接生成图表的思路实测使用了一段时间后想把它背后的原理、用法和那些文档里不会写的坑完整聊一聊。这篇文章不讲空泛的概念就直接说它到底能做什么、怎么写出好用的 Prompt、实际项目里会踩什么坑以及如何把生成结果变成团队真正可维护的文档资产。无论你是要画流程图、时序图、类图还是状态图都可以照着下面的方法直接上手。1. 为什么说让 AI 画图的关键不是画图而是把需求说清楚1.1 手动画图的真正痛点布局、改版、图文分离先说说我在用 AI 画图之前手动绘图到底烦在哪里。第一是布局压力。一张流程图只要分支超过五条方框的位置就会影响整张图的可读性。我经常花大量时间在对齐、拉线、调整间距上而不是在思考流程本身。画完之后回头一看真正有价值的还是那一串节点和箭头花了最多精力的排版反而是最不该由人来做的事。第二是改版成本。业务需求一变图就得跟着动。这时最要命的不是某个框删掉而是它牵扯到的前后连线、跨层引用、判断条件统统要重排。改一版图的时间比改一次需求文字还久于是很多人最后就不改图了改着改着图就和现状彻底脱节。第三是图文分离。需求文档是一份文件图表是另一份文件评审讨论时候你很难同时维护两边的对应关系。文字改了图忘了改图改了文字没跟上。时间一长文档和图互为矛盾新成员看哪个都信不过。这些痛点的核心是同一个图表本身是需求的“投影”它的重点是逻辑结构而不是画布上的位置。而手动绘图工具把这两件事强绑在一起让人不得不同时处理“思考”和“排版”两个任务自然效率低。1.2 diagram-design 是什么一句话到一张图的翻译器diagram-design 本质上是一个”自然语言到图表代码“的转换工具。它接收一段描述性的文字输出一份结构化的图表定义代码然后由支持该语法的渲染器把代码变成实际可视化的流程图、时序图等。对于大部分技术场景输出用的都是 Mermaid 语法它有专门的结构表达方式非常适合表达顺序、分支、状态转移和实体关系。我第一次试用的感受很直接。我输入了一句“用户下单后系统先校验库存库存不足则返回提示库存充足则创建订单并调用支付接口支付成功后通知仓库发货”它立刻给我生成了一张结构完整的流程图。分支、判断、结束节点都在排版也足够清晰。对比我那天在白板上的狼狈这种体验确实让人眼前一亮。它适合的人群很多写技术方案的人用它快速出草图产品经理用它梳理业务链路开发工程师用它把接口调用顺序画成时序图甚至带新人的导师可以快速把系统流程画出来作为讲解材料。它解决的核心问题是把“脑子里或文字里已经存在的需求描述”快速翻译成“一张能反映逻辑的图”省去手动排版的时间。1.3 先明确边界它擅长结构不擅长美化不过这里必须先说清楚一件事diagram-design 不是万能的画图工具。它擅长的是结构化图形的生成也就是节点、箭头、分支、状态、实体关系这类能“用规则描述”的内容。它不擅长做精细排版和艺术美化。如果你想让它生成一张可以放在融资 PPT 首页那种极致美观的架构图或者要画一张只有特定业务逻辑才能推导出来的跨层网络拓扑图那它给你的初稿大概率只能算“逻辑正确颜值一般”。所以正确的心态是把它当“草稿快速生成器”和“逻辑校验器”而不是“最终视觉设计师”。我用它的时候90% 的场景是把生成的代码当作底稿再在需要精修的地方手工调整。至于哪些图值得手工精修、哪些图直接就能用后面章节我会根据自己的实测给出判断。2. 先摸清能力边界diagram-design 能稳定产出的几类图2.1 流程图与决策图最可靠的一档在我测过的所有类型里流程图和决策图是 output 最稳定的。因为流程本身的描述方式和人们对一行文字的理解方向高度一致顺序、分支、汇合这些都是自然语言中非常常见的表达AI 在解析时不容易出偏差。通常我会这样写 Prompt请生成一个流程图描述用户在小程序提交订单后的处理逻辑 用户提交订单系统先校验库存 库存不足则返回失败提示流程结束 库存充足则创建订单调用支付接口 支付成功后通知仓库发货同时发送短信通知用户 支付失败则订单标记为待支付流程结束。它生成出来的 Mermaid 代码大概是这个样子需要说明的是下面这段是源码你可以直接让渲染器画出来graph TD A[用户提交订单] -- B{库存校验} B -- 库存不足 -- C[返回库存不足提示] B -- 库存充足 -- D[创建订单] D -- E[调用支付接口] E -- F{支付结果} F -- 支付成功 -- G[通知仓库发货] F -- 支付成功 -- H[发送短信通知用户] F -- 支付失败 -- I[订单标记为待支付]这种输出的可靠性很高。但有两个细节会影响质量第一分支条件如果用“否则”这类模糊词容易被简化第二多个并发动作如果不显式说明“同时执行”它可能会帮你排成先后顺序。想让并发更准确就在 Prompt 里明确写“支付成功后同时通知仓库发货和发送短信给用户”而不是笼统说“然后”。2.2 时序图接口设计评审最顺手时序图是我个人在接口设计中用得最多的类型因为它非常擅长展示多个角色之间的消息往返顺序。用 diagram-design 生成时序图的体验也不错前提是你要把它理解为一个“讲顺序”的过程。你只要描述清楚谁先调用谁、每个请求的返回是什么、中间是否有异步回调它就能生成带参与者和消息箭头的时序图。举个例子我写下面这些内容画一张时序图描述用户请求重置密码的过程 用户在前端页面点击重置密码前端向后端发送获取验证码请求 后端生成验证码并发送邮件给用户 用户查收邮件后在前端提交新密码和验证码 后端校验验证码校验通过后更新密码并向前端返回更新成功通知。输出如下这一段同样可以直接用支持 Mermaid 的渲染器查看sequenceDiagram participant U as 用户 participant F as 前端 participant B as 后端 participant E as 邮件服务 U-F: 请求重置密码 F-B: 获取验证码 B-E: 发送邮件 E--U: 验证码邮件 U-F: 提交新密码与验证码 F-B: 校验并更新密码 B--F: 更新成功通知 F--U: 提示更新成功需要注意默认参与者如果少它会自动命名成 A、B、C 这种很难看的代号。所以对于重要的角色一定要在 Prompt 里把“用户”“前端”“后端”这类名词写清楚否则出来的图别人看不懂。另外一个坑是“同步调用”和“异步回调”的区别它不一定能准确区分。如果你的场景里存在回调建议在描述里明确写“这里回调”“这个响应是异步返回的”等指导性词汇。2.3 类图与 ER 图写建模草稿的加速器类图和实体关系图是日常开发中非常常用但手动绘制很费时间的类型。用手动工具画一张 20 个字段的 ER 图光调整字段排版就能吃掉半小时。而 diagram-design 在这类场景表现意外地好因为你只需要描述实体名称和它们之间的关系标签。例如我想表示用户和订单的关系可以写生成一个 ER 图一个用户可以拥有多个订单一个订单包含多个商品 用户有 id、用户名、邮箱字段 订单有 id、订单状态、创建时间字段 商品有 id、名称、价格字段。对应生成的代码类似erDiagram USER ||--o{ ORDER : places ORDER ||--|{ ORDER_ITEM : contains PRODUCT ||--o{ ORDER_ITEM : includes USER { int id PK string name string email } ORDER { int id PK string status datetime created_at } PRODUCT { int id PK string name decimal price }每次看到这种输出我都觉得类图和 ER 图是“高结构化、低美感需求”的典型代表和这类 AI 生成工具真是绝配。不过要提醒的是生成后一定要人工检查字段类型和主外键标注因为这类细节极其容易出错它适合帮你搭骨架不适合帮你背书。2.4 状态图与甘特图低频但关键时刻能救场状态图是我原本预期它做不好、但实测还不错的一类。尤其是订单状态机这种经典业务场景用自然语言列举状态转移条件后它生成的stateDiagram-v2结构很清晰。比如画一个订单状态图 订单创建后处于待支付状态 支付成功进入已支付 超时未支付进入已取消 已支付后仓库发货变成已发货 用户确认收货后变成已完成。生成的代码大致如下stateDiagram-v2 [*] -- 待支付 待支付 -- 已支付: 支付成功 待支付 -- 已取消: 超时未支付 已支付 -- 已发货: 仓库发货 已发货 -- 已完成: 用户确认收货 已完成 -- [*]甘特图则更适合排期类的需求你可以输入任务名称、起止时间、依赖关系它会输出横道图。实测下来它更适合展示静态的执行计划不太适合做需要频繁拖拽调整的项目排期毕竟项目管理工具本身已经有了更好的交互方式。但这张能力在写方案、做汇报时能省不少事。2.5 需要降低期待的类型在我测试中以下类型输出质量相对一般需要做好手工补救的心理准备。首先是复杂网络架构图。比如多数据中心、多层级网络、安全域的架构表示这类图有大量的嵌套分组和跨层连线自然语言描述很容易让 AI 在分组归属上犯迷糊。其次是精细 UI 线框图它毕竟不是专门做原型设计的生成出来的界面结构能看出布局但离可直接使用的原型还差得远。最后是大型整体架构图节点一旦超过二三十个它的布局算法和人类审美会明显脱节需要你重新调整分组和层级。我把实测能力边界整理成了一张表方便自己后续选型时快速判断图表类型可靠程度主要用途需要人工介入的程度流程图 / 决策图高业务梳理、方案展示低时序图高接口设计、流程评审低类图 / ER 图高数据建模、代码设计中需校对字段状态图中高状态机梳理低甘特图中计划展示中复杂架构图 / 线框图低总体概览高建议手绘为主这张表其实就是我自己的“期待值管理清单”提前知道它哪里强哪里弱使用的时候心情会平和很多。3. 从一句话到一张图的完整工作流Prompt 才是真正的门槛3.1 一个能稳定复用的 Prompt 模板工具本身再强Prompt 写得糊输出一样糊。我踩过几次坑之后总结了一条公式现在每次输入都按这个结构来。写 Prompt 的四步是先指定图表类型再交代场景背景然后说起点和终点最后把分支和关键约束显式列出来。举个标准模板我会这么写请生成一个{流程图/时序图/类图/状态图}场景是{一句话背景描述}。 流程从{起点}开始到{终点}结束。 过程中存在这些分支 1. 如果是{条件A}执行{动作A} 2. 如果{条件B}则执行{动作B}。 另外请注意{这里填写并发、异步、别名、方向等特殊要求}。这个模板看着简单但它把最容易导致 AI “自由发挥”的几个变量都框定了。指定类型是让它的输出符合你的预期背景场景是给 AI 上下文起点终点是框住范围显式列分支是防止条件被简化最后的特殊要求是补上那些自动解析容易漏掉的细节。3.2 完整案例把一句模糊需求变成可发布的图我用一个真实经历来说明 Prompt 的重要性。最开始我只是写了句“我看一眼登录流程帮我画个图”结果生成出来的图平平无奇分支条件只有成功和失败两条缺少验证码校验和账号锁定这些关键节点。第二次我改用模板写的是请生成一张流程图场景是网页端账号登录。 流程从用户输入账号密码开始到用户成功进入首页或看到错误提示结束。 分支包括 1. 如果账号不存在提示“用户未注册” 2. 如果密码错误提示“密码错误” 3. 如果密码错误累计超过 5 次锁定账号并提示“账号已锁定” 4. 如果校验通过跳转到首页。 注意账号锁定动作要独立成一个节点不要把提示文案写在分支线上。这次的输出质量明显提升关键节点都在锁定操作也按要求独立出来了。只需要做了两处微调一个是给判断节点起了更明确的名字另一个是调整了其中两条连线的颜色用于区分“异常路径”和“成功路径”。这个例子说明了一个道理不是 AI 不会画而是我一开始根本没把自己的需求描述清楚。它只能从文字里还原逻辑文字里没有的约束它不可能凭空变出来。所以与其说我们在使用 AI不如说是在用它倒逼自己把逻辑讲完整。3.3 生成结果如何接入现有文档拿到一份还不错的 Mermaid 代码之后接下来的问题是怎么把它用起来。这里有几个已经验证过的路径。最轻量的是直接在你的 Markdown 文档中嵌入代码块大部分文档平台和代码仓库都自带 Mermaid 渲染粘贴即可显示成图。这样图和文字同步更新改代码就等于改图彻底告别“图文不一致”。稍微重点的是导出成图片文件再插入 PPT 或者在线文档这个过程可以用命令行工具批量完成后面章节我会给出具体方案。第三个路径很多人会忽略把 Mermaid 源码当作一种“可读的图”。即使不渲染光看代码里的节点名和箭头就能读懂大部分逻辑。这意味着它可以直接进入代码评审比如给某个模块画流程图时你甚至不需要截图直接把源码发给同事对方看代码就知道你想表达什么。3.4 第二种用法让 AI 审你自己的图同一个工具不只是“从文字生成图”它还能反向工作。我会把已经画好的 Mermaid 代码扔给它让它把图里的逻辑用文字复述一遍再检查有没有分支遗漏。比如我会写“请看下面的流程图代码帮我检查是否存在分支条件缺失、循环未闭合、或者某些节点从未被引用的问题。”它通常能从逻辑角度找出几个我漏掉的边角情况。这个能力尤其在画复杂状态机时很有用人脑看多了容易默认某些路径不存在而 AI 会把所有可能路径穷举给你看。用一次就会上瘾。这个方法还有一个变体让 AI 根据你的图生成测试用例。它会把每个分支路径提取出来生成覆盖这些路径的用例列表对做技术方案评审和测试设计的人来说属于额外赚到的价值。4. 真实使用中踩过的坑四种典型翻车现场4.1 中文节点和超长文本图不丑但字挤成一团第一次在正式文档里用生成结果时我就遇到了中文文本不换行的问题。节点里写“用户提交订单并成功创建支付单”渲染出来文字被压缩成一大块整个节点变成一个长条特别难看。后来我才意识到问题出在节点命名上。Mermaid 语法里节点文本默认不会自动折行如果输入的内容太长渲染端就会硬塞。解决办法有两个。第一个是给节点起短名字把长描述放到节点标签上。第二个是主动在节点文本里加换行标记像br/这样的 HTML 换行标签在多数渲染端都能生效。我后来的习惯是Prompt 里就明确写“节点名称尽量控制在 4 到 8 个字详细动作放节点内部”这样生成出来的图一开始就是干净的。还要提一个细节判断节点的文案不适合写成长句。比如“库存是否充足”直接作为判断框内容比“检查当前订单中商品库存量是否大于用户购买数量”好读得多。详细逻辑可以在图下方的说明段落里补图本身要承担的是扫一眼就懂的职责。4.2 复杂分支被悄悄省略AI 生成分支条件时有个让我头疼的问题它会把“否则”简化成一条直接路径。比如我写“如果用户是会员走会员价否则走普通价”它有时候会生成一个判断框只画了“是会员”的路径把“否则”当成一条隐含的默认线不单独画出来。这在语义上不算错但在图表展示上就是漏信息。很多评审者看了图会追问“那非会员的路径在哪”你解释半天效果还不如一开始就把分支写清楚。针对这个问题最有效的办法是在 Prompt 里把所有分支以列表形式显式写出而不是用“如果……否则……”这种半模糊句式。另外可以加一句“所有分支都要有对应的节点和连边不要省略任何路线”给生成结果一个明确的指令。实测这句话能明显降低漏分支的概率。4.3 渲染平台版本不一致导致语法报错一个让我特别无语的场景是同样的 Mermaid 代码在本机渲染正常同事的机器上就报语法错误。原因其实很简单不同版本的 Mermaid 对语法特性的支持不同。比如某些新引入的节点样式、箭头类型在旧版本上就不认识。这个问题在接入 CI 后变得非常麻烦因为构建机上的渲染器版本往往和你本机的不一致。我遇到过一次最夸张的情况是某段代码本地显示完美到 CI 上直接失败最终排查下来是箭头定义方式在那个版本上不受支持。解决思路有两个方向第一种是统一版本把渲染器固定在项目依赖里版本锁定之后本机和 CI 跑的是同一套代码问题自然消失。第二种是尽量使用兼容性最好的基础语法不要用各种“看起来很炫”的扩展特性。其实从沟通角度出发基础语法已经能表达绝大多数场景花哨语法带来的收益远低于它带来的兼容性风险。4.4 布局方向不可控要纵向偏给横向默认情况下流程图的方向可能和你预期不一致。比如我想让流程从上往下画体现层级递进感它默认生成了从左往右的布局把一张流程硬生生拉成了横向长条打印的时候差点超出页面。这个问题的解决方法最直接在 Prompt 里或者生成的代码里显式声明方向。Mermaid 的graph TD表示从上到下graph LR表示从左到右。如果你发现自己多次生成的方向都不对就养成在 Prompt 里写“请使用从上到下的排版方向”的习惯。不过我也意识到过度纠结方向其实没有太大必要因为图的结构清晰度比方向重要得多。只要逻辑关系清楚横向或者纵向都不影响表达。我把这个坑写出来更多是想提醒你如果对方向有执念先定规则别等生成完再手动拖拽。4.5 实践后的避坑速查表我把以上几条集中整理一下方便以后踩坑时快速对照常见症状根因处理方式中文节点文字挤成块节点文本过长或不换行节点用短名长文放节点内必要时用br/换行分支路径缺失Prompt 中分支表述模糊用列表显式列出所有分支并声明不要省略同一代码不同环境报错渲染器版本不一致锁定版本使用兼容语法布局方向不符合预期未声明方向Prompt 中明确“从上到下”或“从左到右”这张表已经成了我团队里的内部参考遇到问题先查表能省下不少排查时间。5. 把图表变成文档资产团队协作和版本管理的进阶玩法5.1 图的源码入库比截图更经得起时间我最早用生成图的时候习惯是截图保存到文档里。后来发现这有一个致命问题图一旦需要修改原始代码和图片来源对不上只能从头再画一遍。后来我把 Mermaid 源码文件比如.mmd文件纳入了代码仓库和普通代码一样提交、评审、合并。图的源码入库之后所有历史版本都保存在 git 记录里每次改动可以通过 diff 看到具体改了什么节点、改了哪条连线。这比看两张截图对比有效率得多。这么做还有一个好处截图会失真源码不会。只要渲染器代码还在任何时候都能重新生成清晰的图片不受分辨率影响。团队新成员拿到一份图看到的不仅是一张静态图片还有它背后的构建方式。5.2 在 CI 里自动渲染导出失败直接阻断发布既然源码入库了下一步就是让它在构建流程里自动变成可发布的图片。用命令行渲染工具可以做到这一点我在脚本里对每个.mmd文件循环处理导出成 SVG 或 PNG渲染失败就让流水线直接失败退出。一个典型的批量导出脚本大致长这样#!/bin/bash for file in diagrams/*.mmd; do echo 渲染文件: $file mmdc -i $file -o ${file%.mmd}.svg if [ $? -ne 0 ]; then echo 渲染失败阻断流程: $file exit 1 fi done把这个脚本挂到持续集成流水线里后只要有人提交了语法错误的图表代码构建立刻失败问题在合并前就会被发现。这个机制看起来简单但它把“图表代码正确性”从人为判断变成了自动化检查对团队协作的规范性提升很大。同时还能在每次构建后生成一份最新的图片产物让文档站点或报告直接引用。5.3 多人评审时怎么看图关注逻辑不关注配色多人协作时还有一个要点评审图的重点应该是逻辑而不是样式。我参加过的图表评审里经常出现大家花大量时间讨论“这个框应该用蓝色还是绿色”“箭头是不是应该带虚线”这类问题。说实话对逻辑表达而言这些都是可选项。真正需要关注的是节点所代表的业务动作是否正确、分支条件是否覆盖完整、时序消息的先后是否准确。所以我现在会引导评审者去看源码 diff而不是看图的美观度。用源码 diff 评审时变化一目了然新增了什么节点、删掉了哪条路径、某个箭头从实线变成了虚线这些都对应着业务逻辑的变化。相比肉眼在那张图里找不同代码比对要精确得多。5.4 和团队角色如何分工用了一段时间后我觉得在这个工作流里设计师、开发工程师和 AI 各自的定位是可以分工清楚的。设计师适合输出风格模板和精修规则对最终展示质量负责开发工程师负责把流程逻辑转化成准确的 Prompt 和 Mermaid 源码并维护构建流水线AI 负责把描述快速转化为草稿和结构骨架。这个分工最舒服的地方在于每个人都只做自己擅长的事AI 承担的是最枯燥的“从文字到结构化”这一步。这也解释了为什么我不建议让 AI 一步到位生成最终图片。它生成的是“逻辑半成品”还需要人来确认边界和补充细节。真正的流程是人描述逻辑AI 画草稿人审逻辑AI 按要求微调最后人做视觉定稿。这条链路跑顺之后出图效率比纯手工操作至少翻倍。6. 实际体会别把它当画师当白板6.1 不同阶段的不同定位用了几个月之后我对 diagram-design 的定位发生了很大变化。刚开始我是把它当成“画图工具”来用的希望它直接生成能发的成品图。后来发现它更像一块智能白板。在思路探索阶段我随手输入一句需求描述它快速画出一张初稿我盯着图看哪里不对再改 Prompt再生成。这个“输入-生成-推翻-再输入”的循环速度足够快反而比在白板上折腾更有助于理清思路。你可以把它当成一种“可视化的思维草稿纸”这比它作为“最终成品生成器”的价值大得多。到了方案评审阶段我再把初稿导出手工调整节点颜色、间距和标题最后变成一张正式图。也就是说在不同阶段它的使用方法完全不同。我建议你一开始就把它定位成“第一稿生成器”这样使用心态会好很多不会因为“生成的图不够美”而失望。6.2 一个小技巧先圈动词再交给 AI分享一个我实际用下来觉得最提升生成质量的技巧写 Prompt 之前先把你需求描述里的动词圈出来。比如“用户提交订单系统校验库存创建订单调用支付通知仓库发货”里动词就是提交、校验、创建、调用、通知。把这些动词按顺序理一遍每个动词对应一个节点整个流程的骨架就出来了。这时候再补上主语、条件和分支交给 AI 的 Prompt 就天然清晰。这个技巧的原理很简单流程图本质上就是“动作的有序组合”动词是动作的浓缩。AI 的能力再强也需要在文字里识别动作词你把动作词显式列给它它就不容易乱编。我现在无论是自己画图还是帮别人调试生成结果都会先问一句你这里面核心的动作是哪几个6.3 它改变了我画图的方式但没有消灭手绘最后讲讲我对这类工具的最终看法。它确实改变了我画图的方式以前我画图是“先想清楚再落笔”现在我可以“边描述边生成边修正”整个过程更像是在对话中把逻辑逼出来。特别是当你面对一个并不完全清晰的需求时用 AI 快速画出几种可能的路径图再逐一对比比凭空想象要靠谱得多。但它没有消灭我用手绘图。在某些高度模糊、充满不确定性的讨论场景比如白板画拓扑、画地图式的自由联想图手动绘图那种“边画边想”的质感依然是 AI 给不了的。AI 适合的是把清晰逻辑变成图形而人适合探索那些还不清晰的逻辑。所以我的总结只有一句把 AI 当画师你会失望把它当白板你会惊喜。真正核心的思考能力还是你自己的AI 只是把你脑中的结构翻译成了别人能看见的东西。平时画图不妨就先圈动词、写明分支、让它出一稿你再从这稿开始雕琢慢慢你就会发现画图这个事儿最大的瓶颈早就不是工具而是你能不能把自己的需求说清楚。