流程图里的异常分支,不是把“失败”“出错”几个字挂在主线旁边,而是要回答四个问题:异常在什么条件下发生、谁负责处理、处理后回到哪里、无法恢复时如何结束。画图前先把这四个答案写出来,再决定节点和连线,图会比直接拖形状更清楚。
本文用“订单退款”作为贯穿案例,给出一套适合产品、运营、研发和客服共同评审的画法。你可以把案例中的字段替换成自己的审批、支付、注册或售后流程。

先判断:哪些情况值得单独画成异常分支
不是每个例外都需要一个菱形节点。可以用下面的判断规则筛选:
- 该情况是否会改变下一步动作?如果只是备注,不改变路径,就放在节点说明中。
- 是否需要不同角色处理?需要转人工、补资料或升级时,通常应该单独分支。
- 是否会影响状态或数据?例如扣款成功但订单未更新,必须画出补偿或对账路径。
- 是否有明确的恢复、重试或终止条件?没有出口的异常分支,后续执行时容易变成“人工看着办”。
可以把异常分支分成三类:可自动恢复(重试、等待回调)、需要补充信息(补资料、重新提交)、不可恢复(拒绝、关闭、转人工)。分类后,分支数量会更可控。
画图前先写出正常路径和异常清单
先只写正常路径,不急着画图。以退款为例,正常路径可以是:提交申请 → 校验订单 → 审核通过 → 发起退款 → 退款完成 → 通知用户。
接着做一张异常清单。每行只写一个触发条件,避免把“支付异常、库存异常、权限异常”塞进同一个节点。
| 异常触发条件 | 可观察信号 | 处理责任人 | 处理结果 |
|---|---|---|---|
| 订单不存在或已关闭 | 订单状态不满足退款条件 | 客服或订单服务 | 拒绝并说明原因 |
| 退款金额超过可退金额 | 金额校验失败 | 客服 | 补充凭证或转人工审核 |
| 支付渠道超时 | 发起后未收到回调 | 支付服务 | 按间隔重试,超过上限转人工 |
| 退款成功但订单未更新 | 渠道状态与本地状态不一致 | 订单与财务 | 对账修复,保留处理记录 |
这张表同时是流程图的输入和评审依据。每个异常都应有一个结果,不能只记录“发现问题”而没有后续动作。
异常分支怎么画:五步法
第一步:在真正发生判断的位置放节点
判断节点应紧跟触发条件,而不是放在流程末尾。例如“订单是否满足退款条件”应出现在提交申请之后。节点文字用问题句,分支标签用“是/否”或明确状态,避免使用没有边界的“异常/正常”。
第二步:让每条分支只表达一个结果
一个判断节点最好只做一个二选一判断。若同时判断“订单是否存在、金额是否合规、用户是否有权限”,读者无法知道哪一项失败。可以拆成连续节点,或者先用规则表完成预校验,再把结果带入流程图。
第三步:异常路径向下或向侧边展开
主流程保持从左到右,异常路径统一向下展开;同类异常用同一方向,读者可以快速区分主线与例外。连接线置于节点后方,箭头从节点边缘开始,不穿过节点文字。
第四步:补上处理动作、负责人和时限
“处理异常”不是动作。应写成“重试 3 次”“通知客服补充凭证”“创建对账工单”等可执行表达。如果时限会影响业务结果,在动作节点中写明计时起点和超时出口。
第五步:明确回流点或终止点
可恢复异常必须回到一个已定义的节点,例如重试成功后回到“等待渠道回调”,而不是直接连到“完成”。不可恢复异常要以“拒绝”“关闭”“转人工”等终止状态结束,并保留通知和记录动作。
退款案例:异常分支的完整结构
可以按下面的节点顺序落图:
- 用户提交退款申请。
- 判断订单是否存在且状态可退;否 → 说明原因 → 结束。
- 判断金额是否在可退范围;否 → 请求凭证 → 人工审核。
- 发起渠道退款。
- 判断是否收到成功回调;是 → 更新订单状态 → 通知用户 → 结束;否 → 进入重试计时。
- 判断重试次数是否达到上限;否 → 等待后重试;是 → 创建对账工单 → 通知客服 → 结束。
这里的关键不是节点数量,而是每个出口都能对应一种状态。若“人工审核”可能批准或拒绝,应在该节点后继续画出两条有标签的路径;不要把结果藏在一段说明里。
在 Boardmix 中落图的操作顺序
先在画布上放置主流程节点并统一间距,再复制判断节点和动作节点,最后连接异常路径。建议给主流程、可恢复异常、人工处理、终止状态使用不同的颜色,但同时保留文字标签,避免只靠颜色传达含义。
完成后可以邀请研发、运营和客服分别检查自己负责的节点:研发看状态和回调,运营看责任人与时限,客服看用户通知和转人工条件。讨论结论直接写在对应节点旁,确认后再整理成版本说明。
常见画错方式与修正方法
| 问题 | 为什么影响执行 | 修正 |
|---|---|---|
| 所有异常都连到“人工处理” | 自动恢复机会被隐藏,责任边界不清 | 区分重试、补资料、升级和终止 |
| 分支线上没有标签 | 读者不知道哪条是满足条件的路径 | 使用是/否或具体状态标签 |
| 异常线穿过主流程节点 | 阅读顺序和回流位置容易误判 | 让线条从节点边缘出发,统一向下展开 |
| 回流直接连到完成 | 成功状态没有经过必要校验 | 回到“等待回调”“状态校验”等明确节点 |
| 用颜色代替状态文字 | 打印、色弱或移动端查看时信息丢失 | 颜色只做辅助,节点写清状态 |
发布前用这张检查表验收
- 每个判断节点都有清晰的问题句和分支标签。
- 每条异常路径都写明触发条件、处理动作和负责人。
- 可恢复分支有重试上限、等待条件和回流点。
- 不可恢复分支有明确终止状态和用户通知。
- 主流程方向统一,连线不遮挡节点文字。
- 图中的状态名称与需求文档、接口字段或客服话术一致。
- 缩小到手机宽度后仍能分辨主线、异常线和箭头方向。
常见问题
异常分支很多,应该拆成多张图吗?
当一张图需要同时表达业务流程、技术重试和客服处理时,建议保留一张“业务总览图”,再为高复杂度异常单独画子流程。总览图只保留入口、关键判断、责任交接和出口,子流程负责具体规则。
异常分支可以用红色表示吗?
可以把红色用于需要关注的状态,但不要让颜色承担唯一含义。必须同时写出“超时”“拒绝”“转人工”等状态,并检查黑白打印和移动端显示效果。
什么时候需要把日志或告警画出来?
当日志、告警会触发重试、升级或对账动作时,才把它作为节点或注释放进图里。纯记录信息可放在节点说明或配套表格中,避免主流程被技术细节淹没。
如何确认异常分支真的可执行?
让实际执行者按图口述一次:从触发条件开始,下一步由谁在什么时限内做什么,结果回到哪里。任何需要临时询问“接下来怎么办”的位置,都说明分支还不完整。

