注册与邮箱验证
字段校验、邮箱已注册那条岔路,还有 24 小时验证窗口 —— 最后这段通常要等客服问「链接过期了会怎样」才想起来画。
14 个步骤 · 15 条连线
8 张分支画满的流程图。打开就在画布上。然后把它聊成你的流程:「金额超过 500 加一道主管审批、短信那步删掉、驳回退回表单」。
这里每张图都和你导入后拿到的出自同一份结构化定义 —— 没有一张是精修过的截图。卡片上的预览省掉了分支标签,这样缩到卡片大小还看得清结构;点开任意一张能看到完整版,每个条件都写着。「进对话微调」把流程放进画布并打开对话面板,你的第一句话就能开始改它;「用这个模板」只把它放进编辑器,剩下的你自己来。
字段校验、邮箱已注册那条岔路,还有 24 小时验证窗口 —— 最后这段通常要等客服问「链接过期了会怎样」才想起来画。
14 个步骤 · 15 条连线
游客还是已登录、地址能不能送、库存够不够、支付会不会失败。真实的结账流程差不多就是这四个判断。
17 个步骤 · 20 条连线
静态检查、单测、E2E、主干分支闸门,外加一个能触发回滚的健康检查。放进 README 里,别人就不用先去读 YAML。
18 个步骤 · 21 条连线
先挡掉已知故障,再引导自助文档,然后按套餐分流,最后是升级给研发。你们的响应时长指标就是这张图决定的。
16 个步骤 · 20 条连线
退货期限、特批、虚拟商品和实物分开、到货验收,再加一个「超过额度往上报」。这里分支最密的一张。
17 个步骤 · 21 条连线
密码、频率限制、第二因子、验证码过期,以及新设备提醒。做安全评审时用得上 —— 重点往往在锁定那条路径上。
15 个步骤 · 18 条连线
机器打分,灰区交给人工,按严重程度处置,再留一条申诉回到复审的环。
16 个步骤 · 19 条连线
从告警到恢复:先确认是否真的影响用户,定级,怀疑最近一次发布,回滚或者继续查,最后写复盘。可以直接当 runbook。
16 个步骤 · 18 条连线
有点反直觉但确实好使:选判断比你以为需要的更多的模板。看着图删掉一条分支是两秒钟的事,而漏掉的边界情况要等线上出问题才知道。
页面加载完流程就在画布上,每个判断的两条出边都带标签,所有终态也都画了 —— 包括没人喜欢的那几个。
打开对话面板,用句子纠正它:「金额超过 500 加一道主管审批、短信那步删掉、驳回退回到表单」。助手改的就是你眼前这张结构化的流程,所以每一轮返回的是重画后的版本,而不是重新猜一张。
分屏视图把 Mermaid 源码和预览摆在一起,做最后几处微调。然后:文档里会被放大的用 SVG,幻灯片和工单用 PNG,或者把源码提交到它描述的那段代码旁边。
流程图画的是一个过程:步骤的先后、把它劈开的判断,以及通向每个结局的路径。它回答「先做什么再做什么」—— 而不是「谁调用了谁」(那是时序图),也不是「这东西现在处于什么状态」(那是状态图)。
它是工程文档里用得最多的一种图,原因很实在:流程图不写代码的人也读得懂。客服负责人、财务、法务都会对着一张由方块和菱形画出来的退款流程提意见 —— 而这场争论本身就是价值,它发生在代码写出来之前,而不是客户投诉之后。
Mermaid 的 flowchart 语法覆盖了文档真正需要的东西:几种常用节点形状、带标签的边、子图,以及两种布局方向。它不是完整的 BPMN:没有带泳道池的角色分区,也没有事件语义。对 README、runbook 和技术方案来说,这份克制恰好让图还读得动。
流程图的信息量几乎全在这六样东西上。节点形状和分支标签画对了,图就是流程文档;画错了,它会悄悄描述另一套流程。
flowchart TD / LRTD 从上往下,LR 从左往右。长审批链用 LR 更好读 —— 十五步的 TD 流程,高度会超过任何一张幻灯片。
((...))圆角节点标出流程从哪开始、到哪结束。所有终态都要画上,包括不顺利的那些:只有一个出口的流程,多半是漏了一条分支。
[...]矩形是系统或人做的一件事。用动词命名 —— 写「扣款」而不是「支付」—— 这样整张图读起来才是一串动作。
{...}菱形提一个是非问题。文字写成问句,并且每条出边都要有标签;没标签的分叉是流程图被读错的头号原因。
-->|文字|两个竖线之间的文字会贴在箭头上。分支条件用它,回流也用它 —— 标签负责解释「为什么退回去」。
a --> c多条箭头可以指向同一个节点。把分支收回来,图才不会裂成几列平行、再也不相交的路径。
两条路,各管一类改动。对话管「结构性」的:「支付前加一道审批」「这两条分支合了」「退款完成之后的全删掉」—— 说一轮重画一张。分屏编辑器管「精细」的:步骤文字打错了、分支标签换个词、节点顺序调一调。多数人的用法是:导入 → 在对话里把形状聊定 → 回编辑器抛光。
看得懂,因为模板是结构化数据,不是一张图片或者一坨文本。导入的节点和连线直接成为这轮对话的工作状态,所以「把短信那步删了」删的就是那个节点,并且会把断掉的线接上 —— 助手不是在根据一段描述重新猜你的图。
默认从上往下,短流程这样读最自然。流程长而且基本是线性的,就换成从左往右 —— 十五步的竖版图,高度会超过任何一张要放它的幻灯片。在对话里说一句「改成从左往右」,方向就变了,步骤一个不动。
流程图讲步骤的顺序和分支条件,不关心每一步是谁做的。时序图讲的是哪个参与者、在什么时候、给谁发了什么消息。你的问题是「接下来会怎样」,画流程图;是「哪个服务调了哪个」,画时序图。
限制来自可读性,不是工具。超过二十个节点左右,人就不跟着箭头看了。把相对独立的一段拆成单独一张,再从父文档链过去 —— 几张各说一件事的图,胜过一张挂图。这里的模板刻意都压在这条线以内。
判断节点出去的每条边都要写。没标签的分叉是流程图被读错的头号原因:读的人猜哪边是「是」,猜反了,然后照反的实现。这里的模板每个判断的两条出边都有标签。
SVG、PNG,以及 Mermaid 源码本身。SVG 放多大都不糊,画长流程时有用;PNG 贴幻灯片和工单最省事;源码则可以跟代码一起提交,让图和别的东西一样走评审。