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