1. 活动图到底在画什么：从一张“没人看”的图说起
第一次接触活动图，是在一个内部工单系统的重构项目里。当时需求方丢过来一份二十多页的文档，流程图、状态图、时序图混在一起，开发看完一头雾水，测试看完直接问“到底有几个分支”。后来我们把整条业务链路重新梳理成一张活动图，从“用户提交工单”到“归档关闭”，每个判断节点、每条并行路径都摆在明面上，原本吵了三天的问题，一张图讲清楚了。
活动图本质上是一种行为建模图，用来描述一个流程从起点到终点的动态执行过程。它关注的不是“系统有哪些对象”，而是“事情按什么顺序发生、在哪些点分叉、哪些步骤可以同时干”。换句话说，它回答的是“这个业务到底怎么跑起来”的问题。适合看这张图的人很广：产品用它对齐需求边界，开发用它确认分支覆盖，测试用它设计用例，运维用它理解异常处理路径。哪怕你只是刚入行的新人，只要手上有一个“有步骤、有判断、有并行”的流程，活动图就是最顺手的表达工具。
我见过太多团队把活动图当成“交差用的文档插图”，画完就锁进文件夹。真正有价值的活动图，是画给自己和协作方看的：分支有没有漏、循环会不会死、并行汇合点对不对，这些问题在图上一目了然。接下来我会把这张图从设计思路到落地细节完整拆一遍，包括我踩过的坑和那些文档里不会写的经验。
2. 整体设计与思路拆解：为什么偏偏选活动图
2.1 活动图和其他行为图的边界在哪
很多人分不清活动图、流程图和状态图，画着画着就串了。我的判断标准很简单：看焦点是“动作”还是“状态”。状态图关心的是“一个对象在生命周期里经历哪些状态”，比如订单从待支付到已完成的流转；活动图关心的是“一串动作如何协作完成一件事”，比如订单从创建到履约涉及哪些步骤、哪些步骤能并行。
普通流程图和活动图的区别则在于表达力。流程图能画顺序和判断，但遇到并行、汇合、分叉这些结构就显得吃力，而活动图原生支持并发路径和同步汇合，这在涉及多系统协作、多角色并行的场景里非常关键。我做过一个对账系统，日终要对多个渠道的数据同时拉取、分别校验、最后汇总，用流程图只能画成一条线，用活动图就能把“并行拉取”和“汇合校验”表达得清清楚楚。
选活动图的另一个理由是它天然适合跨角色沟通。泳道把“谁负责哪一步”直接画在图上，产品、开发、运营坐在一起看同一张图，不需要额外解释“这一步是前端做还是后端做”。这种把职责可视化的能力，是其他行为图很难替代的。
2.2 一张活动图的信息分层设计
我习惯把活动图拆成三层来看，画的时候也按这个顺序推进，避免一上来就陷进细节。
第一层是主干流程，也就是从起点到终点最顺的那条路。先把这条线画出来，确认业务主链路没有理解偏差。第二层是分支与异常，把每个判断节点的所有出口都补上，尤其是那些“看起来不会发生”的异常分支。第三层是并行与汇合，识别哪些步骤可以同时进行，哪些步骤必须等前面全部完成才能继续。
这个分层顺序的好处是可控。主干没对齐就画分支，等于在错误的地基上盖楼；分支没画全就加并行，很容易出现“汇合点等一个永远不会到达的分支”这种死锁结构。我见过一张图，并行分叉出去三条路，汇合点却只连了两条，第三条悬空，评审时没人发现，开发按图实现后线上直接卡死。这种问题在分层推进的过程中基本不会出现，因为每一层都会单独检查完整性。
2.3 方案选型的现实考量
工具层面，我一般用支持标准建模语法的绘图工具，团队协作时优先选能版本管理、能多人同时编辑的。这里不展开具体产品，重点说选型逻辑：图要能跟着代码一起迭代。活动图最大的价值在需求澄清和设计阶段，一旦进入开发，图如果和实现脱节就变成了负担。所以我倾向于把图源文件和项目仓库放在一起，改需求的时候顺手改图，评审的时候对着图讲，而不是另开一个文档系统单独维护。
另一个考量是图的粒度。一张活动图塞进三十个活动节点，基本没人看得下去。我的经验是单张图控制在十五个活动节点以内，超了就拆成子图，用“子流程”节点引用。这样每张图都能在一屏内看完，讨论的时候不用来回滚动。
3. 核心细节解析与实操要点：节点、分支、并行的正确画法
3.1 起点终点与活动节点的规范
活动图的起点用实心圆表示，终点用带圆环的实心圆表示。看起来是小事，但我见过不少图起点画成空心圆、终点画成实心圆，和状态图的初始状态混淆，评审时被追问半天。规范画法不只是为了好看，而是让读图的人一眼分清“这是流程的开始”还是“这是某个对象的状态”。
活动节点用圆角矩形，命名上我坚持一个原则：动词开头，宾语明确。“校验参数”比“参数校验”好，“发送通知”比“通知发送”好。原因很实际，活动图描述的是动作序列，动词开头的命名读起来就是一条连贯的动作链，评审时顺着念一遍就能发现逻辑断点。我见过一张图里混用“订单创建”“创建订单”“订单已创建”，读图的人根本分不清哪个是动作、哪个是结果。
注意：活动节点不要写成“系统A调用系统B”这种实现细节，活动图描述的是业务动作，不是技术调用。技术调用留给时序图。
3.2 判断分支与合并的完整性检查
判断节点用菱形表示，一个入口、多个出口，每个出口上标注守卫条件。这里最容易出的问题是分支不全。比如“校验通过”走正常流程，“校验不通过”走异常流程，但“校验超时”呢？很多图里没有这个分支，开发实现时要么默认超时算失败，要么自己拍脑袋加一个，最后和需求对不上。
我的检查方法是：对每个判断节点，把所有可能的输入结果列出来，逐一确认有没有对应出口。守卫条件要写成互斥且完备的，比如“金额大于零”“金额等于零”“金额小于零”三个出口覆盖全部情况，而不是只写“金额大于零”和“金额不大于零”两个出口却漏掉边界。合并节点同样用菱形，多个入口汇成一个出口，它的作用是收拢分支，让后续流程只有一个入口，避免线条交叉混乱。
3.3 并行分叉与汇合的同步语义
并行分叉用粗实线表示，一个入口分出多条路径，这些路径同时开始执行。汇合同样用粗实线，多条路径汇入后同时结束，后续流程才继续。这里的核心语义是同步：汇合点必须等所有入边都到达才能往下走，少一条都不行。
这个语义在实际业务里对应的是“全部完成才能继续”的场景。比如批量审批，多个审批人并行处理，全部通过后才进入下一环节；只要有一个驳回，就走另一条异常路径。画的时候要注意，并行分叉出去的每条路径最终都要能到达汇合点，或者有明确的终止出口。我见过一张图，并行出去三条路，其中一条走到一半直接连到终点，另外两条汇合后继续，这种结构在语义上是混乱的，读图的人会问“到底等不等那条提前结束的路”。
提示：并行路径里如果有判断分支，每个分支都要能回到汇合点或者走到终止节点，不能出现“某条分支走到一半没下文”的情况。
3.4 泳道划分与职责边界
泳道把活动按执行者分组，横向或纵向排列，每个活动落在对应执行者的泳道里。泳道划分的关键是边界清晰：一个活动只属于一个泳道，跨泳道的连线表示职责交接。我见过把“审批”放在两个泳道交界处的画法，读图的人根本不知道这一步到底谁做。
划分泳道时我一般按角色分，不按系统分。按角色分的好处是业务方看得懂，按系统分容易变成技术架构图。如果确实需要体现系统边界，可以在活动命名里带上系统标识，但泳道还是保持角色维度。另外，泳道数量控制在五个以内，超了就说明流程涉及的角色太多，考虑拆成多张图或者用子流程收拢。
4. 实操过程与核心环节实现：从零画出一张能用的活动图
4.1 需求梳理阶段的动作清单提取
画图之前先别打开工具，拿一张纸把流程里所有的“动作”列出来。我的做法是找一段真实的业务描述，逐句拆解，每遇到一个“做某事”就记一条。比如“用户提交申请后，系统校验资料，校验通过则进入初审，不通过则退回补充”，拆出来就是：提交申请、校验资料、进入初审、退回补充，外加一个判断节点“校验是否通过”。
这个阶段不要管顺序和分支，先把动作清单列全。清单列完后再排顺序，把明显有先后依赖的连起来，把可以并行的标出来。我习惯用不同颜色的便签纸区分“动作”“判断”“并行”，贴在白板上调整顺序，比直接在工具里拖拽快得多。等顺序和分支都确认了，再落到工具里画正式图。
4.2 主干先行与分支补全的绘制顺序
落到工具里之后，先画主干：起点、第一个活动、判断节点、正常路径上的活动、终点。这条线画完，找业务方确认一遍，确认“最顺的那条路”没有理解偏差。这一步花十分钟，能省掉后面大量返工。
主干确认后补分支。对每个判断节点，把异常出口和边界出口都补上，每个出口连到对应的处理活动，处理完再连回主干或者连到终止节点。补分支的时候我会刻意问自己三个问题：这个判断有没有“什么都不做”的出口？有没有“超时”的出口？有没有“部分成功”的出口？这三个问题能挖出大部分被遗漏的分支。
分支补全后再加并行结构。识别哪些活动之间没有数据依赖、可以同时进行，用分叉和汇合把它们框起来。加并行的时候同步检查汇合点的入边数量是否和分叉点的出边数量一致，不一致就是结构错误。
4.3 守卫条件的写法与参数化表达
守卫条件写在判断节点的出口连线上，用方括号括起来。写法上我坚持可判定原则：条件必须是明确的、可验证的，不能写“资料齐全”这种模糊表述，要写成“资料项数等于要求项数”。模糊条件在评审时一定会被追问，开发实现时也只能靠猜。
涉及数值判断的，把参数写进条件里，比如“[库存量 >= 下单量]”“[重试次数 < 3]”。这样图本身就是一份可执行的规格说明，开发照着写判断逻辑不会跑偏。我做过一个库存扣减的流程，守卫条件里直接写了库存和下单量的比较关系，开发实现时连需求文档都没再翻，直接按图上的条件写，联调时一次通过。
4.4 子流程节点的拆分与引用
流程超过十五个活动节点就拆子流程。子流程节点画成带子流程标记的活动节点，双击进去是另一张活动图。拆分的依据是功能内聚：把“校验资料”相关的所有活动和判断收进一个子流程，主图上只留一个“校验资料”节点，读图的人先看主干，需要细节再点进去。
拆子流程时要注意输入输出对齐。子流程的入口对应主图上进入该节点的连线，出口对应离开该节点的连线，子流程内部的起点和终点要和外部衔接一致。我见过子流程内部有两个终点、外部只连了一条线的情况，读图的人不知道另一个终点对应什么场景。拆分完成后，主图和子图要一起评审，确保引用关系没有断链。
5. 常见问题与排查技巧实录：那些评审时被问住的瞬间
5.1 分支遗漏与死循环的排查方法
分支遗漏是活动图最高频的问题，排查方法我总结成“三查”：查判断节点的出口数量是否等于可能结果数量，查每个出口是否都有后续活动，查异常出口是否最终能到达终止节点。第三查最容易被忽略，很多图里异常分支画到“记录日志”就断了，没有连到终点，读图的人不知道记录完日志之后流程是结束还是回到主干。
死循环的排查靠追踪路径。从起点出发，沿着每条路径走一遍，看有没有回到之前经过的节点且没有退出条件的结构。活动图里的循环通常表现为“某个活动连回前面的判断节点”，这时候要确认判断节点有退出条件，否则就是死循环。我见过一张图，重试逻辑连回判断节点，但判断节点的守卫条件里没有“重试次数上限”，这条路径理论上可以无限循环。
5.2 并行结构中的资源冲突识别
并行路径同时执行时，如果两条路径操作同一个资源，就可能产生冲突。活动图本身不表达资源锁，但画图的人要在评审时主动识别。比如两条并行路径都要“扣减库存”，汇合后库存可能被扣了两次，这种问题在图上看不出来，但业务上就是错的。
我的做法是在并行结构旁边加注释，标明共享资源，评审时专门过一遍。如果冲突无法避免，就把并行改成串行，或者在其中一条路径上加“加锁”活动。这个细节文档里很少提，但实际项目里踩过一次就记住了。
5.3 泳道错位与职责模糊的修正
泳道错位表现为活动落在错误的泳道里，或者跨泳道连线绕来绕去。修正方法是重新确认每个活动的执行者，把活动拖回正确的泳道。跨泳道连线尽量保持单向、少交叉，如果连线太乱，说明泳道划分有问题，考虑调整泳道顺序或者拆图。
职责模糊的典型表现是“审批”这类活动不知道放哪个泳道。我的处理方式是看这个活动由谁发起、由谁完成，放在完成方的泳道里，发起方通过连线表达交接。如果实在分不清，就说明这个活动的职责定义本身有问题，需要先和业务方对齐再画图。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查动作 | 修正方式 |
|---|---|---|---|
| 流程走不到终点 | 某分支未连到终止节点 | 沿每条路径追踪到终点 | 补全分支连线或加终止节点 |
| 汇合点卡死 | 汇合入边数量与分叉出边不一致 | 数分叉出边和汇合入边 | 补齐缺失路径或调整汇合结构 |
| 判断节点出口条件重叠 | 守卫条件不互斥 | 逐条检查条件表达式 | 改写为互斥且完备的条件 |
| 并行路径资源冲突 | 多条路径操作同一资源 | 标注共享资源逐一核对 | 改串行或加锁活动 |
| 泳道连线混乱 | 泳道划分粒度过细 | 检查泳道数量和跨道连线 | 合并泳道或拆分子流程 |
| 子流程引用断链 | 子流程输入输出与主图不对齐 | 核对子流程起终点与外部连线 | 调整子流程边界或主图连线 |
这张表我一般贴在项目 wiki 里，评审前过一遍，能挡掉大部分低级问题。
6. 让活动图真正被用起来：版本管理与协作习惯
图画完只是开始，能不能被持续使用才是关键。我的习惯是把活动图的源文件放进项目仓库，和需求文档、接口定义放在同一层级，改需求的时候强制要求同步改图。评审会上对着图讲，而不是对着文字文档讲，讲的过程中发现的问题当场在图上改，改完截图发群里留痕。
另一个习惯是给活动图加版本号和变更说明。每次修改在图的角落标注版本和日期，重大结构调整在变更说明里写清楚改了什么、为什么改。这个习惯来自一次教训：一个流程改了三个月，图还是最初版本，新来的同事按图理解业务，结果和线上完全对不上，排查问题时走了大弯路。
协作上，我倾向于让开发和测试都参与画图，而不是产品一个人画完丢过来。开发画图时会自然考虑分支覆盖和异常处理，测试画图时会自然考虑用例设计，多方一起画出来的图，遗漏明显更少。画图的过程本身就是对齐认知的过程，这比图本身更有价值。
最后分享一个我常用的检查技巧：画完图后，找一个没参与需求讨论的同事，让他只看图讲一遍流程。如果他讲的过程中卡壳或者理解偏差，说明图上有表达不清的地方，当场修正。这个“陌生人读图”测试，比任何自查清单都管用。
