1. 活动图到底在画什么从一张“没人看的图”说起如果你做过几年系统设计或者业务梳理大概率见过这样一种场面会议室里白板上画满了圈圈框框产品经理指着其中一条线说“这个分支走完再回到这里”开发在旁边点头测试在低头记等会议结束图擦掉谁也没再看过它一眼。这张图十有八九就是活动图。它本来是用来描述一个流程里“先做什么、后做什么、什么条件下走哪条路、哪些事能同时干”的图结果经常沦为会议道具。我这些年带过不少项目活动图是我要求团队必须画、但也是最容易被画废的一类图。画得好它是需求评审时最省口舌的武器是开发拆任务时的路线图是测试设计用例时的骨架画得烂它就是一堆箭头连起来的装饰画谁也读不出信息。所以这篇东西不打算给你背UML规范而是从一个实际画图、实际被图坑过的人的角度把活动图这件事拆开讲清楚它解决什么问题、核心元素怎么用、什么场景该画什么场景别画、以及那些只有踩过坑才知道的细节。先说清楚它适合谁看。如果你是刚接触流程建模的新人这篇能让你少走我当年走过的弯路如果你是已经画了几年图但总觉得“画了没用”的老手里面关于分区、并发、异常路径的处理思路可能会让你重新认识这张图的价值。活动图的核心关键词就几个流程控制、分支判断、并发分叉、泳道分区、异常路径。这几个词贯穿全文你读的时候可以对照自己手头的项目想一想。我个人的判断标准很直接一个流程如果涉及三个以上的角色、两条以上的分支、或者存在“同时进行”的环节就值得画活动图如果只是“提交—审核—通过”这种一条线走到底的事画它纯属浪费时间。这个判断后面还会展开讲先记住这个门槛。2. 核心元素拆解每个符号背后都是一次决策2.1 起始与结束节点别小看这两个圆活动图的起点是一个实心圆终点是一个套着圆环的实心圆。看起来最简单但实际画的时候问题最多。我见过太多图起点画了三四个理由是“这个流程可以从好几个入口进来”。这在语义上是错的——一张活动图描述的是一次流程执行多个入口意味着你其实画了好几个流程挤在一张图上。正确的做法是如果确实有多个触发入口要么拆成多张图要么在起点后加一个判断节点用不同的触发条件汇聚到主干。终点同理一个流程可以有多个结束状态但每个结束状态应该对应明确的业务结果比如“审核通过结束”和“审核驳回结束”是两个不同的终点而不是随便画两个圈了事。注意起点只能有一个这是硬规矩。多个起点不会让你的图显得“全面”只会让读图的人搞不清这次执行到底从哪开始。2.2 活动节点与转移动词才是灵魂活动节点就是那些圆角矩形里面写的是“做什么”。这里有个特别实用的经验节点名称必须是动宾结构比如“校验身份信息”“生成对账单”“发送通知”而不是“身份信息”“对账单”“通知”这种名词。为什么因为活动图描述的是行为名词化之后你就分不清这是一个动作、一个数据还是一个状态读图的人得猜。转移就是箭头代表一个活动做完之后流向哪里。箭头本身不复杂复杂的是箭头上要不要写条件。我的习惯是只有从判断节点出来的箭头才写条件普通顺序流转的箭头不写。有些人喜欢在每个箭头上都标“完成后”纯属噪音。2.3 判断与合并菱形里的学问菱形是判断节点一个入口多个出口出口上标条件比如“[余额充足]”“[余额不足]”。合并节点也是菱形多个入口一个出口表示不同分支汇合。这两个东西经常被混用我见过把合并菱形当成判断菱形画的图一个入口三个出口条件还写得模棱两可读起来像猜谜。判断节点的关键不在菱形本身而在条件是否互斥且完备。互斥是说同一时刻只能走一条路完备是说所有可能的情况都被覆盖了。举个常见的坑判断“用户是否登录”出口写了“[已登录]”和“[未登录]”看起来完备了但如果登录状态还有“登录过期”这种中间态呢实际项目里这种边界情况才是bug的温床。所以画判断节点时我通常会强迫自己多问一句有没有第三种可能2.4 分叉与汇合并发不是随便画的粗横线代表分叉和汇合分叉是一个入口多个出口同时走汇合是多个入口都完成后才继续。这是活动图里最能体现价值、也最容易被滥用的元素。很多人一看到“可以并行”就画分叉结果画出来的流程根本没法实现——比如“同时扣款”和“同时发货”这两件事在业务上就不该并行扣款失败还发什么货分叉的正确使用场景是真正独立、互不依赖、且都需要完成的活动。比如“生成订单记录”和“写入操作日志”这两件事可以同时做谁先谁后不影响结果汇合之后继续走下一步。判断能不能分叉我的土办法是问自己这两件事如果其中一件失败了另一件还需要继续吗如果答案是“需要”那可以分叉如果答案是“不需要得回滚”那它们之间就有依赖不该用分叉。2.5 泳道分区把“谁来做”画清楚泳道是把活动按执行者分组的区域横向或纵向都行。这是活动图区别于普通流程图的最大价值点——它不只说“做什么”还说“谁来做”。一个跨部门的审批流程如果不分泳道你根本看不出哪个环节卡在谁手里。分泳道的原则是按角色分不按系统分。我见过按“前端”“后端”“数据库”分泳道的图那是架构图该干的事不是活动图。活动图的泳道应该对应业务角色比如“申请人”“部门主管”“财务”“系统”这样读图的人一眼能看出交接点在哪里而交接点往往就是流程最容易出问题的地方。元素图形核心作用常见误用起始节点实心圆标记流程唯一入口画多个起点活动节点圆角矩形描述一个动作用名词命名判断节点菱形条件分支条件不完备分叉汇合粗横线并发执行对依赖活动强行分叉泳道分区框区分执行角色按技术层分而非角色分3. 什么场景该画、什么场景别画一张图的投入产出账3.1 值得画活动图的四类场景第一类是跨角色协作流程。只要流程涉及两个以上角色交接活动图加泳道就是最高效的沟通工具。比如报销审批申请人提交、主管审批、财务复核、出纳付款四个角色四个泳道谁在什么时候做什么一目了然。这种图拿去评审比写三千字需求文档管用。第二类是带复杂分支的业务规则。比如订单状态流转什么条件下可以取消、什么条件下必须走退款、什么条件下转人工处理这些分支用文字描述容易漏画成判断节点逼着你把每种情况想全。第三类是需要识别并发优化的流程。有些流程串行执行很慢画成活动图之后一眼能看出哪几段可以并行。我做过一个内容审核流程原本是“机器审核—人工复审—发布”串行画完图发现机器审核和格式检查完全可以并行改完之后整体耗时降了一截。这种收益是画图之前想不到的。第四类是异常路径多的流程。正常路径谁都会写异常路径才是考验。活动图允许你把异常分支画出来比如“支付超时”“库存不足”“接口失败重试”这些路径在文字需求里经常被一句“异常情况另行处理”带过画图的时候你就没法糊弄了。3.2 三种别浪费时间的场景第一种是线性流程。三步走完、没有分支、没有并发、没有角色交接这种流程用一句话就能说清画图是负收益。我见过把“用户注册—填写信息—提交”画成活动图的三个框两个箭头除了占篇幅没有任何信息增量。第二种是纯技术调用链。活动图描述的是业务行为不是代码调用关系。方法A调方法B再调方法C这是时序图或者调用链该干的事硬画成活动图只会让业务人员看不懂、技术人员觉得多余。第三种是状态机特征明显的流程。如果一个对象的核心是“状态”而不是“动作”比如订单从待支付到已支付到已发货重点在于状态之间的迁移条件那状态图比活动图更合适。活动图关注的是“做了什么导致状态变化”状态图关注的是“状态之间怎么跳”侧重点不同别混用。我的经验是画图之前先问一句“这张图给谁看、看完要解决什么问题”。答不上来就别画画了也没人看。4. 从零画一张能用的活动图完整实操流程4.1 第一步先把流程“说”出来别急着开工具我见过太多人打开画图工具就开始拖框结果画到一半发现漏了分支回头改得面目全非。正确顺序是先不碰工具拿张纸或者开个空白文档把流程用大白话从头到尾讲一遍讲的时候录音或者记关键词。这一步的目的是把“隐性知识”倒出来很多人对流程的理解是模糊的一开口讲就会发现“哎这里好像还有个情况”。讲完之后做一件事标出所有“如果”和“同时”。“如果”对应判断节点“同时”对应分叉。这两个词是活动图的信息富矿出现得越多图的价值越大。我通常会数一下这两个词出现的次数如果加起来不到三个基本可以判断这流程不值得画图。4.2 第二步定角色、划泳道角色清单从流程参与者里提取注意是业务角色不是人名。比如“提交人”“审批人”“系统”是角色“张三”“李四”不是。角色定完之后按流程经过的顺序从左到右或从上到下排泳道顺序本身就有信息量——排在前面的角色先介入排在后面的后介入读图的人顺着泳道顺序就能理解流程走向。这里有个细节系统要不要单独一条泳道。我的做法是如果系统承担了实质性的业务动作比如自动校验、自动生成、定时触发就给它一条泳道如果系统只是被动记录就不单独列避免泳道过多。泳道超过五条就要考虑拆图了否则横向拉得太长读起来像看清明上河图。4.3 第三步铺主干再补分支先画正常路径从起点到终点一条线走通每个活动节点用动宾结构命名。主干画完再回头补判断和分支这时候你会发现主干上某些节点其实需要拆开——比如“处理申请”这个节点太粗实际包含“校验材料”和“录入系统”两步拆开之后分支才有地方挂。补分支的顺序建议是先补业务分支不同条件走不同路再补异常分支失败、超时、驳回最后补并发能并行的环节。异常分支最容易被漏我的土办法是每个活动节点都问一句“这一步失败了怎么办”答案要么是回到上一步重试要么是走异常终点要么是转人工总得有个去处。4.4 第四步走查与精简图画完不等于结束必须走查。走查的方法是拿一个具体案例在图上跑一遍从起点开始每到一个判断节点就代入真实数据看走哪条路一直跑到终点。跑的过程中重点看三件事有没有走不通的死路、有没有条件重叠导致歧义、有没有该汇合的地方没汇合。走查完做精简。活动图最常见的毛病是“太满”每个细节都想画上去结果图比需求文档还长。精简的原则是一张图只讲一个粒度的故事要么全是业务级活动要么全是操作级步骤别混着画。业务级的图里出现“点击保存按钮”这种操作级节点就是粒度失控。画图流程速记 1. 口头讲流程标出所有如果和同时 2. 提取业务角色按介入顺序排泳道 3. 铺正常路径主干动宾结构命名节点 4. 补业务分支 → 补异常分支 → 补并发 5. 代入真实案例走查砍掉粒度不一致的节点5. 那些只有踩过坑才知道的细节5.1 判断条件写成“是/否”是灾难的开始新手最爱写“[是]”和“[否]”问题是读图的人不知道你在判断什么。判断节点的条件必须自带主语和判据比如“[材料齐全]”“[金额超过五千]”“[库存大于零]”。我定过一个规矩条件里必须出现一个可验证的判据要么是数值比较要么是状态判断光写“是/否”打回去重画。5.2 汇合节点不是可有可无的装饰分叉之后必须有汇合这是语义要求不是审美要求。分叉表示并发开始汇合表示并发结束、所有分支都完成了才继续。有些人分叉之后直接把几条线连到同一个活动节点上省掉了汇合菱形这在语义上是模糊的——到底是所有分支都完成才继续还是任意一个完成就继续这两种语义完全不同省掉汇合节点等于把歧义留给了实现的人。5.3 循环别画成死循环活动图允许循环比如“审核不通过打回修改”打回的箭头指回前面的节点。但循环必须有出口条件否则就是死循环。我见过打回箭头指回起点、但没有任何“最终通过”路径的图读起来像流程永远结束不了。画循环时强迫自己标出循环的终止条件哪怕只是“[重试次数达到上限]”这种兜底。5.4 泳道之间的箭头越少越好跨泳道的箭头代表交接交接越多流程越脆弱。如果一张图里跨泳道箭头密密麻麻说明角色分工有问题要么是某个角色承担了过多职责要么是流程设计本身在来回踢皮球。这时候该做的不是优化图而是回头优化流程本身。我处理过一张跨泳道箭头多达十几条的图最后发现根因是两个部门的职责边界没划清图只是把问题暴露出来了。5.5 图要配文字说明但文字不能重复图活动图旁边配一段流程说明是必要的但说明里别把图上每个节点再念一遍。说明应该写图上画不出来的东西业务背景、关键规则的计算口径、异常处理的兜底策略、以及那些“约定俗成但没画出来”的隐含条件。图和文字是互补关系不是复读关系。常见问题表现根因处理方式多起点一张图多个实心圆把多个流程挤在一起拆图或加汇聚判断条件模糊只写是/否判据没想清补可验证判据分叉无汇合并发线直接连到同一节点语义不清补汇合节点死循环打回无终止条件兜底路径缺失加重试上限判断跨泳道箭头过多交接密集职责边界不清回头优化流程分工6. 活动图与其他图的配合别指望一张图打天下活动图不是孤立的。实际项目里它通常和另外几种图配合使用各管一段。用例图回答“系统给谁提供什么价值”活动图回答“这个价值通过什么流程实现”时序图回答“流程里的对象之间怎么交互”状态图回答“关键对象的状态怎么迁移”。这四张图是一条链活动图处在中间位置往上承接用例往下细化成交互。我个人的组合习惯是需求阶段画用例图圈定范围然后对每个核心用例画活动图理清流程活动图里识别出的关键交互再画时序图涉及状态复杂的对象补一张状态图。这个组合下来需求评审基本不用靠嘴解释图往那一放问题自己会浮出来。需要提醒的是活动图不要试图替代时序图。活动图能表达“谁做了什么”但表达不了“消息按什么顺序在对象之间传递”。有些流程的复杂性恰恰在交互顺序上比如先查库存还是先锁库存顺序错了结果完全不同这种细节活动图画不出来得靠时序图。分清楚每张图的边界比把一张图画到极致更有用。7. 工具选择够用就好别在工具上内耗画活动图的工具分三类。第一类是通用绘图工具拖拽自由、上手快适合快速沟通和草图缺点是图形语义靠自觉画错了工具不会提醒你。第二类是建模工具图形元素有严格语义约束画错了会有提示适合需要长期维护、多人协作的正式文档缺点是学习成本高、画起来慢。第三类是文本描述生成图用类似代码的方式描述流程然后渲染成图适合版本管理和diff对比缺点是调整布局不直观。我的实际选择是分场景内部快速讨论用通用绘图工具十分钟出图够用就行正式交付的流程文档用建模工具语义严谨后续维护不容易走样需要进版本库、频繁修改的流程用文本描述方式改起来像改代码一样清晰。工具本身不产生价值图里的信息才产生价值别在选工具上纠结超过半小时。一个实用建议不管用什么工具导出时同时存一份源文件和一份图片。源文件用于后续修改图片用于文档嵌入和评审展示。我吃过只存图片的亏半年后要改一个细节发现源文件没了只能重画。8. 最后聊几句实在的活动图这东西画得好不好跟工具没关系跟对流程的理解深度有关系。我见过用记事本字符画出来的活动图信息密度比某些精美工具画出来的还高因为画图的人真的把每个分支都想清楚了。反过来工具再高级流程本身没想明白画出来的图也只是把混乱可视化了一遍。如果你手头正好有一个流程要梳理我的建议是别急着画全先挑最复杂的那一段画。一段画通了剩下的自然顺。画的过程中如果发现某个地方怎么画都别扭大概率不是画法问题是流程设计本身有矛盾这时候停下来改流程比硬画下去有价值得多。图是思考的产物不是思考的替代品这句话我用了很多年依然觉得是画图这件事最核心的一条。 
长河君 · 2026/11/3 11:40:43 · 阅读 1.2k 活动图实战指南：核心元素、场景选择与避坑细节
1. 活动图到底在画什么从一张“没人看的图”说起如果你做过几年系统设计或者业务梳理大概率见过这样一种场面会议室里白板上画满了圈圈框框产品经理指着其中一条线说“这个分支走完再回到这里”开发在旁边点头测试在低头记等会议结束图擦掉谁也没再看过它一眼。这张图十有八九就是活动图。它本来是用来描述一个流程里“先做什么、后做什么、什么条件下走哪条路、哪些事能同时干”的图结果经常沦为会议道具。我这些年带过不少项目活动图是我要求团队必须画、但也是最容易被画废的一类图。画得好它是需求评审时最省口舌的武器是开发拆任务时的路线图是测试设计用例时的骨架画得烂它就是一堆箭头连起来的装饰画谁也读不出信息。所以这篇东西不打算给你背UML规范而是从一个实际画图、实际被图坑过的人的角度把活动图这件事拆开讲清楚它解决什么问题、核心元素怎么用、什么场景该画什么场景别画、以及那些只有踩过坑才知道的细节。先说清楚它适合谁看。如果你是刚接触流程建模的新人这篇能让你少走我当年走过的弯路如果你是已经画了几年图但总觉得“画了没用”的老手里面关于分区、并发、异常路径的处理思路可能会让你重新认识这张图的价值。活动图的核心关键词就几个流程控制、分支判断、并发分叉、泳道分区、异常路径。这几个词贯穿全文你读的时候可以对照自己手头的项目想一想。我个人的判断标准很直接一个流程如果涉及三个以上的角色、两条以上的分支、或者存在“同时进行”的环节就值得画活动图如果只是“提交—审核—通过”这种一条线走到底的事画它纯属浪费时间。这个判断后面还会展开讲先记住这个门槛。2. 核心元素拆解每个符号背后都是一次决策2.1 起始与结束节点别小看这两个圆活动图的起点是一个实心圆终点是一个套着圆环的实心圆。看起来最简单但实际画的时候问题最多。我见过太多图起点画了三四个理由是“这个流程可以从好几个入口进来”。这在语义上是错的——一张活动图描述的是一次流程执行多个入口意味着你其实画了好几个流程挤在一张图上。正确的做法是如果确实有多个触发入口要么拆成多张图要么在起点后加一个判断节点用不同的触发条件汇聚到主干。终点同理一个流程可以有多个结束状态但每个结束状态应该对应明确的业务结果比如“审核通过结束”和“审核驳回结束”是两个不同的终点而不是随便画两个圈了事。注意起点只能有一个这是硬规矩。多个起点不会让你的图显得“全面”只会让读图的人搞不清这次执行到底从哪开始。2.2 活动节点与转移动词才是灵魂活动节点就是那些圆角矩形里面写的是“做什么”。这里有个特别实用的经验节点名称必须是动宾结构比如“校验身份信息”“生成对账单”“发送通知”而不是“身份信息”“对账单”“通知”这种名词。为什么因为活动图描述的是行为名词化之后你就分不清这是一个动作、一个数据还是一个状态读图的人得猜。转移就是箭头代表一个活动做完之后流向哪里。箭头本身不复杂复杂的是箭头上要不要写条件。我的习惯是只有从判断节点出来的箭头才写条件普通顺序流转的箭头不写。有些人喜欢在每个箭头上都标“完成后”纯属噪音。2.3 判断与合并菱形里的学问菱形是判断节点一个入口多个出口出口上标条件比如“[余额充足]”“[余额不足]”。合并节点也是菱形多个入口一个出口表示不同分支汇合。这两个东西经常被混用我见过把合并菱形当成判断菱形画的图一个入口三个出口条件还写得模棱两可读起来像猜谜。判断节点的关键不在菱形本身而在条件是否互斥且完备。互斥是说同一时刻只能走一条路完备是说所有可能的情况都被覆盖了。举个常见的坑判断“用户是否登录”出口写了“[已登录]”和“[未登录]”看起来完备了但如果登录状态还有“登录过期”这种中间态呢实际项目里这种边界情况才是bug的温床。所以画判断节点时我通常会强迫自己多问一句有没有第三种可能2.4 分叉与汇合并发不是随便画的粗横线代表分叉和汇合分叉是一个入口多个出口同时走汇合是多个入口都完成后才继续。这是活动图里最能体现价值、也最容易被滥用的元素。很多人一看到“可以并行”就画分叉结果画出来的流程根本没法实现——比如“同时扣款”和“同时发货”这两件事在业务上就不该并行扣款失败还发什么货分叉的正确使用场景是真正独立、互不依赖、且都需要完成的活动。比如“生成订单记录”和“写入操作日志”这两件事可以同时做谁先谁后不影响结果汇合之后继续走下一步。判断能不能分叉我的土办法是问自己这两件事如果其中一件失败了另一件还需要继续吗如果答案是“需要”那可以分叉如果答案是“不需要得回滚”那它们之间就有依赖不该用分叉。2.5 泳道分区把“谁来做”画清楚泳道是把活动按执行者分组的区域横向或纵向都行。这是活动图区别于普通流程图的最大价值点——它不只说“做什么”还说“谁来做”。一个跨部门的审批流程如果不分泳道你根本看不出哪个环节卡在谁手里。分泳道的原则是按角色分不按系统分。我见过按“前端”“后端”“数据库”分泳道的图那是架构图该干的事不是活动图。活动图的泳道应该对应业务角色比如“申请人”“部门主管”“财务”“系统”这样读图的人一眼能看出交接点在哪里而交接点往往就是流程最容易出问题的地方。元素图形核心作用常见误用起始节点实心圆标记流程唯一入口画多个起点活动节点圆角矩形描述一个动作用名词命名判断节点菱形条件分支条件不完备分叉汇合粗横线并发执行对依赖活动强行分叉泳道分区框区分执行角色按技术层分而非角色分3. 什么场景该画、什么场景别画一张图的投入产出账3.1 值得画活动图的四类场景第一类是跨角色协作流程。只要流程涉及两个以上角色交接活动图加泳道就是最高效的沟通工具。比如报销审批申请人提交、主管审批、财务复核、出纳付款四个角色四个泳道谁在什么时候做什么一目了然。这种图拿去评审比写三千字需求文档管用。第二类是带复杂分支的业务规则。比如订单状态流转什么条件下可以取消、什么条件下必须走退款、什么条件下转人工处理这些分支用文字描述容易漏画成判断节点逼着你把每种情况想全。第三类是需要识别并发优化的流程。有些流程串行执行很慢画成活动图之后一眼能看出哪几段可以并行。我做过一个内容审核流程原本是“机器审核—人工复审—发布”串行画完图发现机器审核和格式检查完全可以并行改完之后整体耗时降了一截。这种收益是画图之前想不到的。第四类是异常路径多的流程。正常路径谁都会写异常路径才是考验。活动图允许你把异常分支画出来比如“支付超时”“库存不足”“接口失败重试”这些路径在文字需求里经常被一句“异常情况另行处理”带过画图的时候你就没法糊弄了。3.2 三种别浪费时间的场景第一种是线性流程。三步走完、没有分支、没有并发、没有角色交接这种流程用一句话就能说清画图是负收益。我见过把“用户注册—填写信息—提交”画成活动图的三个框两个箭头除了占篇幅没有任何信息增量。第二种是纯技术调用链。活动图描述的是业务行为不是代码调用关系。方法A调方法B再调方法C这是时序图或者调用链该干的事硬画成活动图只会让业务人员看不懂、技术人员觉得多余。第三种是状态机特征明显的流程。如果一个对象的核心是“状态”而不是“动作”比如订单从待支付到已支付到已发货重点在于状态之间的迁移条件那状态图比活动图更合适。活动图关注的是“做了什么导致状态变化”状态图关注的是“状态之间怎么跳”侧重点不同别混用。我的经验是画图之前先问一句“这张图给谁看、看完要解决什么问题”。答不上来就别画画了也没人看。4. 从零画一张能用的活动图完整实操流程4.1 第一步先把流程“说”出来别急着开工具我见过太多人打开画图工具就开始拖框结果画到一半发现漏了分支回头改得面目全非。正确顺序是先不碰工具拿张纸或者开个空白文档把流程用大白话从头到尾讲一遍讲的时候录音或者记关键词。这一步的目的是把“隐性知识”倒出来很多人对流程的理解是模糊的一开口讲就会发现“哎这里好像还有个情况”。讲完之后做一件事标出所有“如果”和“同时”。“如果”对应判断节点“同时”对应分叉。这两个词是活动图的信息富矿出现得越多图的价值越大。我通常会数一下这两个词出现的次数如果加起来不到三个基本可以判断这流程不值得画图。4.2 第二步定角色、划泳道角色清单从流程参与者里提取注意是业务角色不是人名。比如“提交人”“审批人”“系统”是角色“张三”“李四”不是。角色定完之后按流程经过的顺序从左到右或从上到下排泳道顺序本身就有信息量——排在前面的角色先介入排在后面的后介入读图的人顺着泳道顺序就能理解流程走向。这里有个细节系统要不要单独一条泳道。我的做法是如果系统承担了实质性的业务动作比如自动校验、自动生成、定时触发就给它一条泳道如果系统只是被动记录就不单独列避免泳道过多。泳道超过五条就要考虑拆图了否则横向拉得太长读起来像看清明上河图。4.3 第三步铺主干再补分支先画正常路径从起点到终点一条线走通每个活动节点用动宾结构命名。主干画完再回头补判断和分支这时候你会发现主干上某些节点其实需要拆开——比如“处理申请”这个节点太粗实际包含“校验材料”和“录入系统”两步拆开之后分支才有地方挂。补分支的顺序建议是先补业务分支不同条件走不同路再补异常分支失败、超时、驳回最后补并发能并行的环节。异常分支最容易被漏我的土办法是每个活动节点都问一句“这一步失败了怎么办”答案要么是回到上一步重试要么是走异常终点要么是转人工总得有个去处。4.4 第四步走查与精简图画完不等于结束必须走查。走查的方法是拿一个具体案例在图上跑一遍从起点开始每到一个判断节点就代入真实数据看走哪条路一直跑到终点。跑的过程中重点看三件事有没有走不通的死路、有没有条件重叠导致歧义、有没有该汇合的地方没汇合。走查完做精简。活动图最常见的毛病是“太满”每个细节都想画上去结果图比需求文档还长。精简的原则是一张图只讲一个粒度的故事要么全是业务级活动要么全是操作级步骤别混着画。业务级的图里出现“点击保存按钮”这种操作级节点就是粒度失控。画图流程速记 1. 口头讲流程标出所有如果和同时 2. 提取业务角色按介入顺序排泳道 3. 铺正常路径主干动宾结构命名节点 4. 补业务分支 → 补异常分支 → 补并发 5. 代入真实案例走查砍掉粒度不一致的节点5. 那些只有踩过坑才知道的细节5.1 判断条件写成“是/否”是灾难的开始新手最爱写“[是]”和“[否]”问题是读图的人不知道你在判断什么。判断节点的条件必须自带主语和判据比如“[材料齐全]”“[金额超过五千]”“[库存大于零]”。我定过一个规矩条件里必须出现一个可验证的判据要么是数值比较要么是状态判断光写“是/否”打回去重画。5.2 汇合节点不是可有可无的装饰分叉之后必须有汇合这是语义要求不是审美要求。分叉表示并发开始汇合表示并发结束、所有分支都完成了才继续。有些人分叉之后直接把几条线连到同一个活动节点上省掉了汇合菱形这在语义上是模糊的——到底是所有分支都完成才继续还是任意一个完成就继续这两种语义完全不同省掉汇合节点等于把歧义留给了实现的人。5.3 循环别画成死循环活动图允许循环比如“审核不通过打回修改”打回的箭头指回前面的节点。但循环必须有出口条件否则就是死循环。我见过打回箭头指回起点、但没有任何“最终通过”路径的图读起来像流程永远结束不了。画循环时强迫自己标出循环的终止条件哪怕只是“[重试次数达到上限]”这种兜底。5.4 泳道之间的箭头越少越好跨泳道的箭头代表交接交接越多流程越脆弱。如果一张图里跨泳道箭头密密麻麻说明角色分工有问题要么是某个角色承担了过多职责要么是流程设计本身在来回踢皮球。这时候该做的不是优化图而是回头优化流程本身。我处理过一张跨泳道箭头多达十几条的图最后发现根因是两个部门的职责边界没划清图只是把问题暴露出来了。5.5 图要配文字说明但文字不能重复图活动图旁边配一段流程说明是必要的但说明里别把图上每个节点再念一遍。说明应该写图上画不出来的东西业务背景、关键规则的计算口径、异常处理的兜底策略、以及那些“约定俗成但没画出来”的隐含条件。图和文字是互补关系不是复读关系。常见问题表现根因处理方式多起点一张图多个实心圆把多个流程挤在一起拆图或加汇聚判断条件模糊只写是/否判据没想清补可验证判据分叉无汇合并发线直接连到同一节点语义不清补汇合节点死循环打回无终止条件兜底路径缺失加重试上限判断跨泳道箭头过多交接密集职责边界不清回头优化流程分工6. 活动图与其他图的配合别指望一张图打天下活动图不是孤立的。实际项目里它通常和另外几种图配合使用各管一段。用例图回答“系统给谁提供什么价值”活动图回答“这个价值通过什么流程实现”时序图回答“流程里的对象之间怎么交互”状态图回答“关键对象的状态怎么迁移”。这四张图是一条链活动图处在中间位置往上承接用例往下细化成交互。我个人的组合习惯是需求阶段画用例图圈定范围然后对每个核心用例画活动图理清流程活动图里识别出的关键交互再画时序图涉及状态复杂的对象补一张状态图。这个组合下来需求评审基本不用靠嘴解释图往那一放问题自己会浮出来。需要提醒的是活动图不要试图替代时序图。活动图能表达“谁做了什么”但表达不了“消息按什么顺序在对象之间传递”。有些流程的复杂性恰恰在交互顺序上比如先查库存还是先锁库存顺序错了结果完全不同这种细节活动图画不出来得靠时序图。分清楚每张图的边界比把一张图画到极致更有用。7. 工具选择够用就好别在工具上内耗画活动图的工具分三类。第一类是通用绘图工具拖拽自由、上手快适合快速沟通和草图缺点是图形语义靠自觉画错了工具不会提醒你。第二类是建模工具图形元素有严格语义约束画错了会有提示适合需要长期维护、多人协作的正式文档缺点是学习成本高、画起来慢。第三类是文本描述生成图用类似代码的方式描述流程然后渲染成图适合版本管理和diff对比缺点是调整布局不直观。我的实际选择是分场景内部快速讨论用通用绘图工具十分钟出图够用就行正式交付的流程文档用建模工具语义严谨后续维护不容易走样需要进版本库、频繁修改的流程用文本描述方式改起来像改代码一样清晰。工具本身不产生价值图里的信息才产生价值别在选工具上纠结超过半小时。一个实用建议不管用什么工具导出时同时存一份源文件和一份图片。源文件用于后续修改图片用于文档嵌入和评审展示。我吃过只存图片的亏半年后要改一个细节发现源文件没了只能重画。8. 最后聊几句实在的活动图这东西画得好不好跟工具没关系跟对流程的理解深度有关系。我见过用记事本字符画出来的活动图信息密度比某些精美工具画出来的还高因为画图的人真的把每个分支都想清楚了。反过来工具再高级流程本身没想明白画出来的图也只是把混乱可视化了一遍。如果你手头正好有一个流程要梳理我的建议是别急着画全先挑最复杂的那一段画。一段画通了剩下的自然顺。画的过程中如果发现某个地方怎么画都别扭大概率不是画法问题是流程设计本身有矛盾这时候停下来改流程比硬画下去有价值得多。图是思考的产物不是思考的替代品这句话我用了很多年依然觉得是画图这件事最核心的一条。