业务流程图关注“业务怎样跨角色运转”，功能流程图关注“用户操作后产品怎样响应”。前者用来统一业务规则和责任边界，后者用来指导页面、交互、研发与测试。两者不是互相替代，而是从业务层逐步落到功能层。
业务流程图先说明角色、规则和结果
业务流程图以一条完整业务链路为对象。电商订单场景中，用户、商家、仓库、物流和售后分别承担动作；图中需要说明订单何时成立、库存何时占用、哪个角色接手，以及取消或退款后进入什么结果。
它通常不会展开每个按钮和页面，而是帮助业务、运营、产品和管理者判断流程是否完整、责任是否清楚、规则是否冲突。
功能流程图再说明操作、反馈和状态
功能流程图把范围缩小到一个功能。以“提交订单”为例，用户选择规格、确认地址、选择支付方式并提交；系统需要反馈库存不足、优惠失效、支付取消或成功等状态。图中的动作往往能对应页面、弹窗、按钮和接口结果。
评审这类图时，产品、设计、研发和测试更关心路径是否闭环、状态是否齐全，以及异常后能否继续操作。
功能流程图不要求展示全部业务后台动作。例如仓库分配策略可以在业务或系统资料中说明；功能图只需明确用户提交后看到“处理中”，以及何时收到成功或失败反馈。
两类流程图的核心区别
| 对比项 | 业务流程图 | 功能流程图 |
|---|---|---|
| 观察对象 | 业务链路、角色和价值流转 | 单一功能中的用户操作与系统反馈 |
| 常见节点 | 角色动作、规则、审批、交接、业务结果 | 页面、操作、判断、状态、异常提示 |
| 颗粒度 | 跨部门或跨系统的整体过程 | 一个功能内的详细路径 |
| 主要评审者 | 业务、运营、产品、管理者 | 产品、设计、研发、测试 |
| 典型问题 | 谁负责、规则是否冲突、交接是否断裂 | 怎么操作、页面如何反馈、失败后去哪 |
绘制顺序不同，评审问题也不同
业务流程图通常从业务对象出发，例如订单、工单或审批单。先列参与角色和业务结果，再连接关键交接与判断。功能流程图则从用户目标出发，先画入口、主要操作和完成状态，再补错误提示、返回路径和中断后的恢复方式。
评审业务流程图时，可以逐段追问：谁拥有这个节点，进入和离开的条件是什么，规则冲突由谁决定，异常是否会让业务对象停在无人负责的状态。评审功能流程图时，则要检查用户是否知道当前状态、操作失败后能否继续、页面与系统结果是否一致。
| 发现的问题 | 先回到哪张图 | 处理方式 |
|---|---|---|
| 部门职责不清 | 业务流程图 | 补角色、交接条件和负责人 |
| 按钮点击后无反馈 | 功能流程图 | 补处理中、成功、失败等状态 |
| 业务规则与页面提示冲突 | 先业务后功能 | 确认规则，再同步页面文案与路径 |
| 接口异常没有用户出口 | 先功能再关联技术资料 | 补重试、返回或人工处理路径 |
用电商下单把两张图接起来
先画业务流程：用户下单后，商家确认、仓库出库、物流配送，完成或进入售后。然后选择“用户提交订单”这个关键节点，另起一张功能流程图，展开地址、库存、优惠、支付和结果页。
两张图通过业务节点名称对应即可，不必把功能细节全部塞回业务总览。这样业务讨论不会被界面细节打断，设计和研发也能从功能图继续工作。
| 业务节点 | 对应功能内容 | 还需关联的资料 |
|---|---|---|
| 创建订单 | 确认商品、地址、优惠与支付方式 | 订单字段与价格规则 |
| 确认履约 | 用户查看订单状态和预计进度 | 库存、仓储或服务规则 |
| 支付结果 | 成功、取消、失败与重试反馈 | 支付渠道与状态定义 |
| 售后处理 | 申请入口、材料提交、进度与结果 | 售后政策和审批规则 |
在同一项目中维护两种视图
使用墨刀流程图时，可以先建立业务总览，再为关键节点补充更细的功能流程；需要评审时围绕节点评论，需要展示页面时再连接原型。AI生成的流程草图适合提供初始结构，但角色、条件、异常和业务口径仍要由项目成员核对。
不确定该选哪种图时，先问“这次评审要决定业务怎么跑，还是功能怎么用”。需要继续比较其他表达方式，可查看常见流程图类型。
常见混画问题怎样修正
- 业务图里出现大量按钮和弹窗：把这些节点拆到功能流程图，业务图只保留对应业务结果。
- 功能图里写满部门审批：回到业务流程确认角色和规则，再把用户可见反馈同步到功能图。
- 两个图的节点名称不同：建立对应表，统一订单、支付、履约和售后等核心术语。
- 修改一张图后另一张未更新：在关键节点添加关联链接，并在评审结论中记录受影响图。
判断是否画对的简单方法，是让业务人员只看业务图仍能解释整条链路，让设计和研发只看功能图仍能说明用户操作与系统反馈；两组人再通过同名关键节点对齐。
从讨论稿到交付稿如何维护
讨论阶段可以用便签和简短节点快速调整，但进入交付前，应统一角色名称、业务状态和页面名称，删除已经否定的分支，并为仍未确定的规则标注负责人和截止时间。复杂链路可以拆成总览与子流程，避免一张图无限扩张。
当订单规则变化时，先更新业务流程的判断条件，再检查功能流程中的页面提示、按钮可用状态和结果页是否受影响。两张图都应记录更新结论；只改其中一张，会让后续设计、研发和测试依据不同版本工作。
若团队需要在线共同维护，可以把业务总览、功能子流程和相关原型放在同一项目结构中，用链接建立对应关系。发布评审链接前，再确认访问权限以及图中是否包含客户、交易或内部策略等敏感信息。
两类图也可以采用不同视觉密度：业务总览强调角色和阶段，功能子流程强调状态和分支。样式差异应服务阅读，不要用颜色暗示未经说明的业务含义。对外展示时，可隐藏内部负责人和系统名称，但应保留流程逻辑，另存展示副本而不是覆盖工作版本。
评审结束后，应把结论同步到两张图对应的节点。
若同一业务存在多个渠道，还应分别标出网页、移动端和线下环节，避免把渠道差异误画成功能异常。
