流程图常见的使用方式有基础流程图、业务流程图、泳道图、页面流程图、系统流程图、数据流程图和程序流程图。讲清做事顺序，用基础或业务流程图；查责任交接，用泳道图；梳理界面跳转，用页面流程图；分析调用、数据或算法，再分别选择系统、数据或程序流程图。
这些名称并不互斥：同一张退款业务流程图也可以采用泳道布局。选好表达重点后，可在墨刀流程图工具中使用对应图形与连线，把同一任务的不同视角分开绘制。
七类流程图分别解决什么问题
| 类型 | 主要回答 | 常见场景 |
|---|---|---|
| 基础流程图 | 事情按什么顺序进行 | 操作说明、简单审批、活动步骤 |
| 业务流程图 | 业务如何跨角色和环节运转 | 订单、售后、审批、服务流程 |
| 泳道图 | 每一步由谁负责，在哪里交接 | 跨部门审批、售后协作、岗位交接 |
| 页面流程图 | 用户在页面之间怎样移动 | 登录、下单、发布、注册路径 |
| 系统流程图 | 系统组件及处理关系是什么 | 应用、服务、设备或模块交互 |
| 数据流程图 | 数据从哪里来、如何处理、到哪里去 | 数据采集、存储、报表、接口分析 |
| 程序流程图 | 算法按什么条件执行与循环 | 程序逻辑、计算步骤、异常分支 |
基础流程图：先把顺序说清
适合步骤较少、角色不复杂的任务，例如报销提交、内容发布或设备巡检说明。它强调开始、过程、判断与结束，不需要为了完整而加入系统架构。
业务流程图：追踪一项业务结果
围绕订单、线索、工单或审批等业务对象，说明它如何跨角色流转。评审重点是规则、责任和结果，不是页面长什么样。
泳道图：看清责任交接
当同一步骤可能由不同部门承担，或交接经常出现遗漏时，泳道能把责任边界放到图面上。泳道过多时应拆分子流程，否则横向阅读会失控。
页面流程图：整理用户路径
以页面和用户动作作为主要节点，适合原型设计前确认登录、下单、发布等路径。页面流程应包含关键反馈状态，但不必复制全部后端规则。
系统流程图：说明组件如何协同
用于表达应用、服务、设备或模块之间的处理关系。系统边界、依赖方向和外部接口比视觉样式更重要，必要时链接到架构或接口文档。
数据流程图：追踪数据的来去
关注数据来源、处理过程、存储位置和输出对象，适合分析数据采集、报表和接口交换。它不等同于数据库表结构，也不应省略外部实体。
数据流程图（DFD）的箭头写“订单信息”“审核结果”等数据名称，而不是“点击”“同意”“下一步”等控制动作；处理节点写“校验申请”“生成报表”。如果你主要想表达事情先后发生的顺序，应画业务流程图，而不是给DFD继续添加判断菱形。
程序流程图：展开条件与循环
把算法步骤、判断、循环和异常画出来，便于讨论控制逻辑。复杂程序应按函数或模块拆分，避免在一张图中展开全部代码路径。
符号是表达语言，不是流程图类型
开始/结束、过程、判断、输入输出和连接线会出现在多种流程图里。它们帮助读者理解节点含义，但“用了菱形”并不能说明这是一张业务流程图或程序流程图。类型由图要回答的问题和信息边界决定。
平行四边形通常表示输入或输出，例如“输入订单编号”“输出审核结果”；跨页连接应使用团队选定的连接符，并标明跳转编号。不要把同一形状在一张图中同时解释成输入输出与跨页连接。
当业务流程需要表达并行审批、任选分支与重新汇合时，可以采用BPMN的专门符号。不要把普通“是/否”判断直接当作并行网关，具体可看BPMN网关的分流与汇合规则。
容易混淆的三组类型
业务流程图与页面流程图
业务流程图可跨多个角色和系统，终点通常是业务结果；页面流程图围绕用户操作和页面反馈，粒度更细。需要同时使用时，先画业务总览，再为关键业务节点补页面流程。可继续查看业务流程图与功能流程图的区别。
业务流程图与泳道图
泳道图不是另一套业务规则，而是一种突出责任归属的组织方式。只有当“谁负责、在哪里交接”是核心问题时，才需要把角色或部门分成泳道。
系统流程图与数据流程图
系统流程图强调组件与处理关系，数据流程图强调数据的来源、处理、存储和去向。系统名称可以出现在两类图中，但审查问题不同：前者看依赖与调用，后者看数据边界与变化。
同一笔退款，为什么会需要不同的图
假设用户申请退款，由客服审核，审核通过后调用支付服务。下面的写法分别回答不同角色的问题，不是要求把所有信息塞进一张大图。
| 当前要解决的问题 | 图中写什么 | 先不展开什么 |
|---|---|---|
| 退款申请如何处理？ | 业务流程：提交申请 → 审核 → 退款处理 → 通知结果；审核不通过返回原因 | 按钮位置、数据库字段 |
| 申请为什么卡在客服与财务之间？ | 泳道：用户、客服、财务、支付服务；跨泳道箭头写交付的材料或处理结果 | 各页面的完整视觉设计 |
| 用户提交后到哪里看进度？ | 页面流程：订单详情 → 退款表单 → 提交结果 → 进度页；失败返回表单并保留输入 | 内部结算与对账算法 |
| 退款信息怎样进入报表？ | 数据流程：申请资料进入校验处理，写入退款记录，汇总为报表数据 | 用户点击顺序、按钮是否高亮 |
| 何时停止重试支付请求？ | 程序流程：检查请求结果、可重试条件、重试次数、停止与人工处理出口 | 客服组织结构 |
若评审中反复出现“图里怎么没有这个”，先判断问题是否属于另一种视角。可以在“退款处理”节点链接系统调用图，或在“提交申请”节点链接页面流程；不用把主图扩成难以阅读的混合图。
按工作阶段选择流程图
需求早期先用基础流程图或业务流程图跑通主线；跨部门讨论责任时改用泳道图；进入界面设计后补页面流程图；技术方案需要说明模块协同时使用系统流程图；数据治理或报表需求再单独维护数据流程图。程序流程图则适合拆解某段明确算法，不宜替代完整系统设计。
同一项目可以同时存在多种图，但每张图都要写明范围和维护人。例如“退款业务总览”与“退款申请页面流程”可以共享节点名称，却分别由业务规则和产品交互负责人维护。
一张图承担一个主要任务
需要同时讨论业务、页面和系统时，先建立一张总览，再拆分子图并用相同节点名称关联。这样每张图都能保持合适粒度，也方便不同角色评审。
可以用三个问题快速判断：读者是谁、看完要决定什么、哪些信息必须留给下一张图。业务负责人要决定责任和规则，就不要让页面细节占据主体；研发要检查算法分支，就不要用抽象的“系统处理”代替条件。
在墨刀中，可用模板、图形库与连线先建立结构，再请参与流程的同事一起查看。模板适合起稿，选用后需要删除无关节点，把动作、条件和角色替换成团队实际使用的名称。
让AI生成初稿时，提示中要直接写明图种。例如：“画退款审批泳道图，泳道为用户、客服和财务；从提交申请开始，到到账通知结束；必须有资料不全退回补充、审核拒绝和退款失败三条路径。”如果只输入“退款流程”，生成结果往往无法确定要表现页面、角色还是系统调用。
拿到草图后，沿每条分支走到一个明确结果，重点查退回后从哪里重新进入、失败后谁处理。涉及退款条件、金额或时限的节点，应使用团队已确认的规则，不能让生成结果替代规则制定。
类型选定后的交付检查
- 标题是否直接说明图的对象和范围；
- 节点粒度是否一致，是否混入另一类图的大量细节；
- 判断分支是否有文字条件和明确去向；
- 角色、系统、数据或页面名称是否与项目资料一致；
- 子图与总览是否通过同名节点或链接建立关系。
流程图类型不是固定等级。同一项目可能同时需要业务流程图、页面流程图和系统流程图，关键是让每张图都能独立回答一个问题，并能在变化后继续维护。
如果读者需要在一张图中不断放大才能判断当前层级，通常说明内容需要拆分；如果拆成多张图后找不到相互关系，则需要用统一命名、编号或链接重新连接。类型选择和信息组织应同时完成。
对于经常更新的流程，可在标题或说明中标注适用范围与确认日期，并把修改原因写入版本记录。这样读者能判断图是否仍适用于当前业务，而不是把旧流程当作现行规则。
被替换的流程应明确标记，避免继续被引用。
子图标题建议同时包含业务对象和图的类型，例如“退款申请页面流程”或“退款审批泳道图”，让读者无需打开文件就能判断用途。
