系统流程图栏目 ·

用文本快速画流程图：连线格式、节点类型与 10 个示例模板

用“文本连线”把流程写清楚，再一键自动排版成流程图：给出最小语法、命名规范、判断/循环/异常分支写法，以及可直接复制的模板与交付导出清单。

当你需要把一段「描述性的流程」变成一张能交付的流程图（放进 PRD、方案评审、运维 SOP、作业报告都行），最耗时间的往往不是逻辑本身，而是：拖拽对齐、找形状、拉线、改字号、重新排版。

更稳的做法是：先用文本把节点与连线关系写清楚，再交给工具自动排版。你会得到几个额外好处：

  • 可版本管理：文本天然适合 Git diff；评审时能清楚看到改了哪条分支。
  • 可复用：同类流程可以从模板演进，避免每次从空画布开始。
  • 可审计：规则化的命名与条件写法，能减少“图看起来对但逻辑不完整”的情况。

如果你想直接体验“写文本 → 自动生成流程图”的方式，可以把下面任意模板粘贴进去：

本文是教程百科 + 落地页结合：先给你一套可执行的写法规范，再给一组可复制模板，最后给交付清单与排错 FAQ。你不需要“会画图”，只要会把流程写成句子。

1. 最小语法：只要写“连线”，就能生成图

文本流程图的核心是一行一条边（连线）：

  • 基础格式：源节点 目标节点
  • 带说明/条件：源节点 -说明 目标节点

建议你遵守两条最小约束（能显著降低解析歧义）：

  1. 节点名称尽量不要包含空格（用中文短语或下划线替代）。
  2. 一张图至少包含：起始、结束、以及 4 个以上“处理中间节点”。

1.1 最小可用示例（能跑通就行）

开始 结束

这当然太短，但它告诉你“语法就是这么简单”。真正可交付的流程图，通常会有 8～25 个节点。

1.2 带条件/说明的连线（判断分支最常用）

校验参数 -通过 执行业务
校验参数 -失败 返回错误

写条件时，推荐用“可枚举”的词：通过/失败、是/否、存在/不存在、命中/未命中、成功/失败。避免“可能/大概/一般”这种模糊词。

2. 节点类型：可选，但能让图更规范、更像“系统图”

在很多团队里，流程图之所以看起来不专业，常见原因是：所有节点都长得一样，评审时看不出哪里是判断、哪里是输入输出、哪里是开始结束。

你可以在节点前面加类型（可选）：类型 节点名称。

常见类型（不同工具命名略有差异，但思路一致）：

  • 起始：开始
  • 结束：结束
  • 处理：一般步骤（默认类型）
  • 判断：分支节点（会出现多条带条件的出边）
  • 输入/输出：用户输入、展示结果、接口响应等
  • 数据：读取/写入数据库、缓存、文件
  • 连接符：跨区域跳转、避免长线回绕

2.1 类型写法示例

起始 开始
输入/输出 填写信息
处理 校验信息
判断 是否通过
处理 提交保存
结束 结束

开始 填写信息
填写信息 校验信息
校验信息 是否通过
是否通过 -是 提交保存
是否通过 -否 填写信息
提交保存 结束

实操建议：不必每个节点都写类型。写流程图时最值钱的是“逻辑结构”，类型只要把关键节点（开始/结束/判断/输入输出/数据）标出来，就足够让图更清晰。

3. 一套能落地的“文本流程图写作规范”（不是模板，是真规则）

把流程写成文本时，你会遇到一个问题：同样一张图，不同人写出来的节点名和分支名差异很大，导致可读性、可复用性、可审计性都变差。

下面这套规范可以直接抄到你团队的 SOP 里。

3.1 节点命名：动词开头 + 对象清晰

推荐：动词 + 宾语/对象，尽量具体。

  • 好：校验库存、创建订单、计算应付金额、写入支付记录、返回结果
  • 坏：处理、操作一下、结果、继续

一个很实用的小技巧：

  • 处理节点尽量用动词：创建/更新/查询/计算/发送/写入/记录/回滚
  • 数据节点尽量写清楚存储介质：写入DB/读取缓存/写入日志/写入消息队列
  • 输入输出节点写清楚面向谁：用户输入/前端展示/接口响应/回调通知

3.2 分支条件：写成“可判定”的条件，而不是结果

  • 推荐：-手机号已注册 / -手机号未注册
  • 不推荐：-不能注册 / -可以注册（这其实是“结论”，不是“条件”）

如果你的判断有三种以上的分支，建议这样写：

  • -命中白名单
  • -命中黑名单
  • -未命中

把条件写成“互斥且完备”的集合，评审时更容易发现漏分支。

3.3 循环/重试：把“回到哪一步”写出来

很多流程的关键不是“失败”，而是“失败后怎么恢复”。文本表达循环时，一定要写清楚回到哪一步：

发送验证码 输入验证码
输入验证码 校验验证码
校验验证码 -通过 创建账号
校验验证码 -失败 提示错误
提示错误 输入验证码

这里的最后一行就是“重试回路”。

3.4 异常分支：要么结束，要么回滚，要么人工介入

画异常分支时，最怕的是：你写了一个“失败”，但失败后没有交代系统做什么，图就变成“故事”而不是“规范”。

异常分支至少要落到以下三类之一：

  • 结束：返回错误/提示失败/终止流程
  • 回滚：撤销写入/恢复库存/解除锁/补偿交易
  • 人工介入：创建工单/告警通知/人工审核

你可以在文本里显式写出“人工节点”：

支付回调校验 -失败 告警通知
告警通知 人工核对
人工核对 -确认成功 更新订单状态
人工核对 -确认失败 发起退款

3.5 复杂流程拆分：用“子流程”而不是一张巨图

当节点数超过 30，或者出现多个不同角色（用户/系统/运营/财务）交织时，推荐拆分：

  • 主流程只保留关键路径
  • 把复杂步骤抽成「子流程」节点（例如：风控校验子流程、退款子流程）
  • 子流程再单独写一张文本图

这样做的独有好处是：主图不需要牺牲可读性，细节也不会丢。

4. 从 0 到 1 的写作步骤：10 分钟做出可评审的流程图

你可以按下面顺序写（这是“写得快、改得少”的顺序）：

  1. 先写边界：开始/结束，流程目标是什么
  2. 先写主干（happy path）：不考虑异常，先把最顺的一条线写通
  3. 补判断节点：在哪些点需要分支（权限、库存、风控、支付结果、审批结果）
  4. 补异常与回路：失败后结束/回滚/重试/人工介入
  5. 统一命名：动词开头、对象明确、条件可枚举
  6. 交付导出：PNG（汇报/文档）或 draw.io（协作编辑）

当你写完文本，最省事的验证方式是：直接丢进在线生成器看排版是否合理。

5. 10+ 个可复制模板（覆盖常见业务/作业场景）

下面的模板是为了“拿来就用”。你可以先复制一个最接近的，再改节点名与分支条件。

提示：模板里节点名都尽量短、无空格，复制后更容易一次成功。

模板 1：通用「输入→校验→处理→输出」（带错误回路）

开始 收集输入
收集输入 校验输入
校验输入 -通过 执行业务
校验输入 -失败 提示错误
提示错误 收集输入
执行业务 输出结果
输出结果 结束

模板 2：注册（含验证码重试 + 已注册分支）

开始 选择注册方式
选择注册方式 -手机号 手机号校验
选择注册方式 -邮箱 邮箱校验
手机号校验 -已注册 提示已注册
手机号校验 -未注册 发送验证码
发送验证码 输入验证码
输入验证码 校验验证码
校验验证码 -通过 设置密码
校验验证码 -失败 提示验证码错误
提示验证码错误 输入验证码
设置密码 创建账号
创建账号 注册成功
提示已注册 结束
注册成功 结束
邮箱校验 -通过 设置密码
邮箱校验 -失败 提示邮箱错误
提示邮箱错误 结束

模板 3：登录（含多次失败锁定）

开始 输入账号密码
输入账号密码 校验格式
校验格式 -通过 校验密码
校验格式 -失败 提示格式错误
提示格式错误 输入账号密码
校验密码 -正确 创建会话
校验密码 -错误 记录失败次数
记录失败次数 判断是否锁定
判断是否锁定 -未锁定 提示密码错误
判断是否锁定 -已锁定 提示账号锁定
提示密码错误 输入账号密码
创建会话 登录成功
登录成功 结束
提示账号锁定 结束

模板 4：找回密码（邮箱/短信二选一）

开始 选择找回方式
选择找回方式 -短信 手机号校验
选择找回方式 -邮箱 邮箱校验
手机号校验 -通过 发送验证码
手机号校验 -失败 提示手机号错误
邮箱校验 -通过 发送重置链接
邮箱校验 -失败 提示邮箱错误
发送验证码 输入验证码
输入验证码 校验验证码
校验验证码 -通过 设置新密码
校验验证码 -失败 提示验证码错误
提示验证码错误 输入验证码
发送重置链接 用户点击链接
用户点击链接 设置新密码
设置新密码 重置成功
提示手机号错误 结束
提示邮箱错误 结束
重置成功 结束

模板 5：下单支付（含库存、优惠、支付失败）

开始 创建订单
创建订单 校验库存
校验库存 -有库存 计算金额
校验库存 -无库存 提示缺货
计算金额 选择优惠
选择优惠 -使用优惠券 校验优惠券
选择优惠 -不使用 发起支付
校验优惠券 -通过 应用优惠
校验优惠券 -失败 提示优惠无效
提示优惠无效 选择优惠
应用优惠 发起支付
发起支付 等待支付结果
等待支付结果 -成功 更新订单状态
等待支付结果 -失败 提示支付失败
提示支付失败 重新支付
重新支付 发起支付
更新订单状态 支付完成
支付完成 结束
提示缺货 结束

模板 6：退款流程（含风控/人工介入）

开始 提交退款申请
提交退款申请 校验订单状态
校验订单状态 -不可退 提示不可退款
校验订单状态 -可退 风控校验
风控校验 -通过 发起退款
风控校验 -需人工 告警通知
告警通知 人工审核
人工审核 -通过 发起退款
人工审核 -驳回 提示退款驳回
发起退款 退款结果
退款结果 -成功 更新退款状态
退款结果 -失败 创建工单
创建工单 人工处理
更新退款状态 退款完成
提示不可退款 结束
提示退款驳回 结束
退款完成 结束
人工处理 结束

模板 7：审批流程（单人审批 + 驳回修改回路）

开始 提交申请
提交申请 校验材料
校验材料 -通过 主管审批
校验材料 -失败 通知补充
通知补充 修改材料
修改材料 提交申请
主管审批 -通过 归档
主管审批 -驳回 通知修改
通知修改 修改材料
归档 结束

模板 8：会签/多角色审批（简化版）

开始 提交申请
提交申请 初审
初审 -通过 会签A
初审 -驳回 通知驳回
会签A -通过 会签B
会签A -驳回 通知驳回
会签B -通过 终审
会签B -驳回 通知驳回
终审 -通过 归档
终审 -驳回 通知驳回
归档 结束
通知驳回 结束

模板 9：客服工单处理（含升级与回访）

开始 用户提交工单
用户提交工单 自动分类
自动分类 分配处理人
分配处理人 处理问题
处理问题 -可解决 回复用户
处理问题 -需升级 升级处理
升级处理 专家处理
专家处理 回复用户
回复用户 等待用户确认
等待用户确认 -已解决 回访
等待用户确认 -未解决 继续处理
继续处理 处理问题
回访 关闭工单
关闭工单 结束

模板 10：API 调用（含重试、降级、熔断概念化表达）

开始 构造请求
构造请求 发送请求
发送请求 接收响应
接收响应 -成功 解析结果
接收响应 -超时 记录失败
接收响应 -错误码 记录失败
记录失败 判断是否重试
判断是否重试 -是 等待退避
等待退避 发送请求
判断是否重试 -否 走降级
走降级 返回兜底结果
解析结果 返回结果
返回兜底结果 结束
返回结果 结束

模板 11：数据同步（批处理 + 断点续跑）

开始 拉取任务配置
拉取任务配置 获取上次游标
获取上次游标 查询源数据
查询源数据 -无数据 写入完成标记
查询源数据 -有数据 清洗转换
清洗转换 写入目标库
写入目标库 更新游标
更新游标 查询源数据
写入完成标记 结束

模板 12：新员工入职流程（业务管理类场景）

开始 发起入职申请
发起入职申请 人事审核
人事审核 -通过 创建账号
人事审核 -驳回 通知补充
通知补充 补充材料
补充材料 发起入职申请
创建账号 分配权限
分配权限 发放设备
发放设备 入职培训
入职培训 试用期跟进
试用期跟进 转正评估
转正评估 -通过 转正
转正评估 -不通过 延长试用
转正 结束
延长试用 结束

复制完模板后，最省力的下一步是：直接粘贴到生成器里看效果，哪里线绕得难看，就调整节点拆分或改短命名。

6. 反例与排错：为什么“文本没问题，图却看着怪”？

6.1 反例：节点名太泛，图会变成“看不懂的故事”

  • 反例：处理、继续、完成、结果
  • 修正：把动作说清楚：校验权限、写入订单表、生成对账单、返回支付结果

6.2 反例：条件不互斥，评审时会吵起来

  • 反例：-成功 与 -完成（其实是同义）
  • 修正：用互斥集合：-成功 / -失败；或 -命中 / -未命中

6.3 反例：异常分支悬空（失败了然后呢？）

  • 反例：支付结果 -失败 支付失败
  • 修正：要落地到动作：提示支付失败、记录失败原因、创建工单、告警通知、结束

6.4 反例：一张图塞进所有细节

当你发现自己在写：

  • 过多“并行发生”的事
  • 角色/系统太多
  • 每条线都要解释

通常说明：需要拆成主流程 + 子流程。主流程保留关键节点，子流程单独成图，协作效率会更高。

7. 交付导出清单：让流程图真正“可用、可审、可交付”

写完流程图，交付不是“导出一张图”就结束。下面是一个更专业的交付清单：

  • 命名清楚：文件名包含业务 + 版本 + 日期（例如：支付流程_v2_2026-04-02.png）
  • 图中要有边界：开始/结束明确；入口/出口不混乱
  • 分支写条件：判断节点的每条出边都有条件/说明
  • 异常有落点：结束/回滚/人工介入三选一（或组合）
  • 导出两份：
    • PNG：用于文档、汇报、飞书/Notion/Confluence
    • draw.io：用于后续协作编辑与二次加工

如果你希望把“文本 → PNG/draw.io”这条链路固定下来，建议把生成器链接放进团队文档的工具区：

8. FAQ：常见问题（以及更省时间的做法）

Q1：我到底该先写文本还是先画图？

当流程需要评审、会迭代、会有人在意“漏分支/漏异常”时，先写文本更好：它让你先把逻辑写成可检查的结构，再生成图形。

如果只是临时在白板上讲个大概，手画也没问题，但那张图往往不适合作为“规范”。

Q2：节点数量多少合适？

  • 8～25：通常最适合一张可读的流程图
  • 25～40：开始需要考虑拆分
  • 40+：强烈建议主流程 + 子流程，不然维护成本会爆炸

Q3：模板会不会让我“写得都一样”？

不会。模板只是“骨架”。真正决定流程独特性的，是：

  • 你的业务边界（哪些情况算失败/可重试/需人工）
  • 你的数据写入点（哪些表/缓存/日志）
  • 你的风控/权限策略（命中规则如何分支）

用模板的正确姿势是：先用它快速跑通主干，再把你业务的独有逻辑写进去。

Q4：有没有一句话的自检规则？

有：每一个“判断”，都要能回答“如果不满足，会发生什么？”

答不出来的判断，就是需要你补流程的地方。

9. 结尾：把“画图”变成“写规则”

流程图真正的价值，不是图形本身，而是把业务规则写成团队都能复用的结构。你用文本写出来的每一条连线，都是一次“把规则钉在纸面上”的过程；图只是更直观的展示。

如果你今天就要交付一张流程图：选一个上面的模板，替换成你的节点与条件，贴进生成器，导出 PNG 或 draw.io，就能完成一次从 0 到交付的闭环。