程序流图画法这件事说简单也简单几个框连几条线就完事说难也真难。我见过太多交上来的流图代码跑得挺好图却没人看得懂判断框两个箭头都不标条件循环绕回去的线从框顶穿过去一处 return 直接画成断头线悬在半空。评审会上大家对着图猜逻辑最后干脆打开代码一行行念——那这张图就白画了。这份内容想解决的就是这个问题。我把这些年画程序流图踩过的坑、定过的规矩、以及一套能直接照着走的操作流程整理出来从符号语义、三种基本结构的画法到嵌套循环、多处 return、圈复杂度体检再到评审和版本维护。适合刚入行、正在被画流程图作业折磨的同学也适合带团队、需要统一图示规范的技术负责人。看完你不一定能画出漂亮得能当壁纸的图但至少能保证图上的每一条线都能对上代码里的每一次跳转。1. 先弄明白程序流图到底要回答哪些问题很多人一上手就打开绘图工具拖框这是最容易返工的开局。动笔之前得先想清楚这张图是给谁看的要回答什么问题。程序流图和算法描述、时序图、状态图不是一回事混着用最后画出来的东西谁都不满意。1.1 程序流图与相邻图种的职责边界程序流图的核心职责只有一件事描述控制流如何在一个处理单元内部流转——从哪进、经过哪些处理、在哪个点分叉、什么时候回到之前的步骤、从哪出。它关心的是顺序和分支不关心时间顺序上的跨对象交互也不关心数据结构的形状。举个具体的对比。一个下单接口调用支付服务画程序流图时关注的是校验通过没通过、失败要不要重试、重试几次后放弃而本系统和支付服务之间来回发了几次请求、每次请求带什么字段这种问题属于时序图的活儿。你要是把服务之间的往返也塞进程序流图图会迅速膨胀成一张网可读性归零。再比如状态图它描述的是一个对象在生命周期内状态怎么迁移。而程序流图里那个当前处于哪个步骤是执行位置不是对象状态。这两者在用户登录这种场景里特别容易混淆状态图会画未登录 → 已登录 → 锁定程序流图则画取参数 → 校验格式 → 查库 → 比对密码 → 返回。我自己的判断标准很简单如果一个问题能用先做什么、然后判断什么、否则做什么这种句式讲清楚就用程序流图如果必须说当 A 发生时 B 转到 C 状态就换状态图如果说客户端发第一条消息服务端回第二条客户端再发第三条就换时序图。1.2 哪些场景值得画哪些场景别硬画不是所有函数都配得上一张流图。我的经验是分三档处理。值得单独画一张的判定节点在 3 个以上的业务流程比如订单校验、资格判定、费率计算、权限过滤涉及重试、退避、超时降级的容错逻辑以及会被多人反复修改的核心算法。这类内容画出来收益是实打实的——新人接手能少读几百行代码。可以合并画一张的同一个模块内若干个高度相似的小函数比如五六个不同字段的格式化方法它们结构完全一样画一个通用形态加一张参数对照表就够了。硬画五六张除了凑页数没别的用。不建议画的纯数据搬运的 getter/setter、单层 if 的简单判断、以及那种一眼能读完的十行代码。给这种代码配流图属于用大炮打蚊子维护成本反而更高——代码改一行图就得跟着改最后图和代码必然对不上。提示团队里最好约定一条硬线比如判定节点数量 ≥ 3 或函数超过 50 行才要求配流图其余情况写在注释里即可。没有这条线要么到处是图没人看要么该有的地方一张都没有。还有一个容易被忽略的判断维度这张图的寿命。如果是需求评审阶段用来对齐理解画完就废那怎么快怎么来手绘拍照都行如果是要随代码长期归档的那必须用可版本管理的文本格式后面第 6 节会细说。2. 符号规范别在框的形状上翻车符号这东西看起来是形式主义实际是沟通成本。同一个符号在不同人眼里含义不同图就失去了作为共同语言的价值。国内常用的那套符号体系基本源自国家标准里的流程图规范虽然没有强制约束力但绝大多数团队和技术文档都在沿用跟着走最省事。2.1 基础符号与各自的语义边界我按使用频率从高到低列一遍顺便说清楚每个符号最容易出错的地方。起止框圆角矩形或椭圆只表示流程的开始和结束。开始框只有一个出口、没有入口结束框只有入口、没有出口。常见错误是把主流程结束和异常退出画成两个不同的结束框其实规范做法是多个流程线都能汇入同一个结束框或者用不同的出口点标记区分。处理框矩形表示一个或一组赋值、计算操作。关键判断标准是这个动作会不会产生分支不会就进处理框。所以x x 1是处理框判断 x 是否超过了上限是判断框不能混。判断框菱形表示条件判断至少有一个入口和两个出口。经典结构化规范里要求判断框单入单出——入口唯一多个出口最终要能重新汇合。这一点后面 3.2 节会重点展开。出口必须标注条件文字比如是/否或成功/失败不能靠线的左右位置暗示。输入输出框平行四边形表示与外部交换数据比如读文件、发请求、打印输出。这个符号在纯算法图里可以省略把输入输出当成处理也行但在描述带 IO 的流程时最好保留因为它提示读者这里有副作用和延迟。预定义处理框两侧带双竖线的矩形表示调用另一个已定义的子流程或函数。这个符号在实际工作中被严重低估。把调用风控服务画成普通矩形读者就得猜它是不是还有内部逻辑用预定义处理框一眼就知道这里是个黑盒细节在别处。连接点小圆圈用于跨页或跨图衔接。当一张图必须分成多页时用同名连接点表示这条线从上一页的那个圈接过来。注意是同一张图的续接不是调用关系。注释框用虚线或折线连到目标元素上写说明文字。图里放不下的信息都往这里塞比硬挤在框里强。下面这张表是我给团队新人发的速查表直接抄走就行符号形状入口数出口数典型用法最容易犯的错起止框圆角矩形/椭圆开始框 0 个结束框 0 个流程起点与终点画出两个结束处理框矩形11赋值、计算、累加把判断写进去判断框菱形1≥2条件分支出口不标条件输入输出框平行四边形11读文件、发请求与处理框混用预定义处理框双竖线矩形11调用子流程展开成整张子图连接点小圆圈11跨页续接当成跳转用2.2 那些看起来无所谓、实际很致命的细节尺寸和文字量这件事很多教程不提但它是可读性的第一杀手。我的经验值是单个框内的文字不超过两行每行不超过十二个汉字。超过了就拆成两个处理框或者把补充说明挪到注释里。一个塞了四十个字的矩形读者得先花十秒读文字再花十秒找它的入口在哪翻页还得重读一遍。连线方向也有约定。默认自上而下、自左而右所以从下往上走的线必须带箭头不能指望读者脑补。箭头要落在框的边界上不能戳进框内部也不能停在离框还有一段距离的地方——尤其是打印出来或者缩放后箭头飘在半空会让入口位置变得有歧义。判断框的标注位置我习惯统一放在流程线靠近出口的那一段文字方向与线平行。三路分支时比如成功/参数错误/其他出口最好按顺时针排在判断框的右侧、下方、左侧形成稳定的阅读节奏而不是随机分布。还有一个隐藏坑同名变量多个框。同一个变量在流程中被多次修改有些图会用同一个框反复出现视觉上很乱。规范做法是每个修改点单独一个处理框框里写清楚i i 1重复出现没问题读图的人跟着流程线走就行。2.3 画图前该准备的清单我一般会先花十分钟做这几件事比直接开画省时间。先通读代码标出所有会让控制流拐弯的位置if、switch、for、while、break、continue、return、throw、以及可能抛异常的调用。然后用纸笔把这些拐点按出现顺序列成一列粗略数一下数量——超过二十个的说明这个函数该拆了先拆函数再画图。接着确认输入输出这个流程从哪拿数据、往哪写数据、对外部有什么副作用。这一步能帮你决定哪些地方要用预定义处理框。最后定图的范围。划一条明确的边界函数内部全画被调函数只画成预定义处理框不展开除非评审时需要深入某个子流程那时候再单独出一张。提示这一步做完最好用一句话把整个流程概括出来写在图的上方作为说明比如校验订单合法性失败时按指数退避重试三次。这句话是图的标题句画出偏差时能第一时间发现。3. 三种基本结构的标准画法与嵌套处理结构化程序设计有个经典结论任何算法都可以只用顺序、选择、循环三种结构组合出来不需要无条件跳转。这个结论对画图的意义是——你手上的图如果出现了无法归入这三类的连线八成是代码本身写得有问题或者你理解错了代码逻辑。这一节把三种结构逐个拆开讲。3.1 顺序结构合并框的取舍顺序结构就是一条直线处理框一个接一个最简单也最容易画歪。真正需要决策的是哪些操作可以合并进一个框。我的原则是合并后仍能看出逻辑边界就合并一旦合并会掩盖某个有意义的状态变化就分开。比如初始化三个变量retry 0、max 3、result 空写进一个框完全没问题读者一眼能看明白这是初始化阶段。但retry retry 1和sleep(200 * 2^retry)这两个操作就不建议合并——它们一个改变循环状态、一个产生外部等待是两种性质的动作合在一起反而让人看不清重试机制的重点在哪。还有一个常见问题流程线要不要画得绝对垂直。多段顺序结构如果严格对齐成一列图会非常长一页放不下。这时候我会把主干拆成两列第一列从上往下到底部横向接到第二列的顶部继续往下形成一个Z字走向。这样比跨页用连接点更直观前提是中间不能有分支有分支就必须用连接点。3.2 选择结构if、if-else、switch 的差异画法这是最容易画乱的一块因为代码里的写法太灵活了。单分支 if没有 else在流图上表现为判断框出一个是分支去做事做完之后通过一条线绕回主干否分支直接沿主干往下走。关键是这个绕回主干的动作要画清楚两条线必须在同一个汇合点重新合流不能一条连到后面的处理框、另一条连到更后面的位置。if-else是两个分支各自处理完再合流。这里有个细节如果两个分支的处理长度差别很大短的会形成一大片空白。我的做法是主动调整判断框的位置把它放在偏短分支那一侧让两条线尽量等长看起来更平衡。switch/多路选择有两种画法。一种是串行的多个判断框嵌套呈阶梯状展开分支少的时候3 个以内很清楚另一种是画一个大判断框引出多条带标签的出口线分支多的时候更节省空间。我自己的分界线是四路四路以内用嵌套超过四路改用多出口判断框并配一张分支说明表。有个规范问题经常被争论判断框能不能多入多出。经典结构化流图要求单入单出好处是每个判断点的语义清晰、便于计算复杂度、也便于机械转成测试用例。但在描述带break、return、异常处理的真实代码时强行单入单出会画出极其扭曲的绕线。我的折中方案是主流程尽量保持单入单出确实需要提前退出的地方允许一条线直接指向结束框但必须在线的旁注标明提前返回原因 X。这样既保留了可读性也让异常出口可视化。第 4 节会讲具体的收口画法。代码形态推荐画法判断框出口数是否需要汇合点单分支 if判断框 一条回流线2是if-else判断框 两条对称支路2是if-else if-else≤4 路阶梯嵌套判断框每层 2是switch≥5 路多出口判断框 分支表≥5是除直接返回异常捕获虚线出口 异常处理框2视情况3.3 循环结构while 与 do-while 的区别画法循环画错的比例非常高而且错得很隐蔽——图和代码看起来对应实际执行次数差一次。根源就在于没分清三种循环。while前测循环先判断条件为真才执行循环体执行完绕回判断点。这意味着循环体有可能一次都不执行。画图时判断框在循环体之前这是最直观的形态。do-while后测循环先执行一次循环体再判断条件为真则回到循环体开头。这意味着循环体至少执行一次。画图时判断框在循环体之后从判断框的是分支回到循环体入口。这两个的差别看着只有一步但在重试三次这种场景里实际就是重试 3 次还是 4 次的区别是实打实的 bug。我遇到过好几次评审时发现图和代码对不上最后都是这里搞错了。for 循环可以按 while 的形态画把初始化放循环外条件判断和自增放对应位置。也可以在图旁边用文字标注步长 1从 0 到 n-1。我倾向于用前者的标准形态因为在有continue的情况下自增的执行时机容易被搞混——continue会跳过循环体剩余部分直接去自增这个细节必须画出来。循环的出口条件也值得说一句。循环结束有两条路条件不成立自然退出或者中途break强制退出。如果图里只画了自然退出那你漏掉了一条控制流。规范做法是把break画成从循环体内部直接指向循环后第一个处理框的线并标注break。3.4 嵌套与跨层跳转的规范处理嵌套两层还好三层以上就开始考验图的组织能力了。我一般把外层循环框画在最外侧内层循环整体作为一个块嵌套在里侧块内细节正常展开。为避免线条互相穿越嵌套层数超过两层时我会把内层循环抽成一个预定义处理框内层循环详见子图 A只在需要看细节时才展开。这是控制图面复杂度的关键手段。跨层跳转——break跳出两层循环、continue跳过内层剩余逻辑——是最难画的部分。坦白说我在真实项目中很少见到有人把多层嵌套加多重跳转画得又准确又好看因为这种代码本身就是可读性灾难。我的处理策略分两步走先建议重构把内层循环抽成独立函数用返回值表达是否需要提前终止外层如果因为工期或历史原因不能重构就老老实实画用带标签的出口线标签统一命名如break-L1break-L2并在图下方加一个短表格说明每个标签的含义。丑是丑但准确。提示如果你发现自己在为某个函数画流图时需要超过三个跳转标签这基本可以作为该重构了的硬信号比任何代码规范工具给出的提示都直接。4. 从代码到流图的完整实操前面讲的都是规则这一节拿一个真实场景从头走一遍。案例是订单校验加指数退避重试涉及循环、多路判断、提前返回和计数累加基本把常见结构都用上了。4.1 案例背景与代码骨架需求是这样的校验一个订单如果校验服务返回成功就直接返回成功如果返回的是参数错误说明这个订单本身有问题重试也没用立即返回失败其他情况网络抖动、服务繁忙等认为可以重试最多试三次每次等待时间按 200 毫秒乘以 2 的当前次数递增超过三次仍失败则返回超时。用伪代码写出来大概是这样函数 校验订单(订单): 如果 订单 为空: 返回 失败(参数错误) retry 0 maxRetry 3 当 retry maxRetry: result 调用校验服务(订单) 如果 result 成功: 返回 成功 否则 如果 result 参数错误: 返回 失败(参数错误) 否则: retry retry 1 sleep(200 * 2^retry) 返回 失败(超时)三十来行四个判定点。这段代码看着简单但真要画得滴水不漏得处理好几处细节。4.2 第一步到第三步初始化、循环骨架、分支展开先说第一个决策空订单检查要不要单独画一个判断框。从纯逻辑上说它是主循环之外的前置守卫画上去会让图多一层。我的做法是画因为它的行为和其他分支不同——它返回的是参数错误和循环体内的参数错误汇入同一个出口。不画的话这个函数的入口契约就不完整。这是要不要画判断的一个实用标准这个检查会不会改变函数的对外行为会就必须画。第二步搭循环骨架。在纸上先画出四样东西开始框、初始化处理框retry0、maxRetry3 合并成一个框因为它们是同一次初始化的不同部分、循环判断菱形retry maxRetry、以及循环体之后的返回失败(超时)处理框和结束框。先不填循环体内容把骨架连起来。这样做的意义是提前确定主干方向避免画到一半发现空间不够。第三步填充循环体。循环体内有三个动作调用校验服务、判断结果、以及失败分支里的计数加一和等待。调用校验服务我建议用预定义处理框写调用校验服务(订单)因为它是外部依赖内部细节不该在这张图里展开如果后面需要分析它单独出一张子图。判断结果用阶梯嵌套第一层判断result 成功是分支直接指向结束框并标注返回成功否分支往下走到第二层判断result 参数错误是分支同样指向结束框并标注返回失败(参数错误)否分支进入失败处理。4.3 多处 return 与循环退出的收口画法到这里就遇上了本案例最棘手的部分这段代码有四个 return全都在循环内部或循环之后。如果严格按单入单出的要求你得为每个 return 设一个变量记录返回结果然后一路带着这个变量穿到循环结束最后统一返回。这样画出来的图会多出三四个处理框和一堆汇合线逻辑反而更难读因为读者要一直追踪当前 result 变量是什么值。我的做法是允许提前返回的线直接指向结束框但做三件事保证清晰。第一所有指向结束框的线在靠近结束框的一段标注返回内容比如返回成功返回失败(参数错误)。这样读者不用回头找判断条件就能知道这条路的结局。第二把这些线用统一的走向排列——比如全部走图的右侧竖直向下避免交叉。三条提前返回的线如果分别从不同方向扎向结束框画面会非常乱。第三图的下方加一句说明本流程共 4 个出口分别为空订单、首次成功、参数错误、重试超限。这句话让复杂度一目了然。再说循环的退出路径。这里有两个循环体内部通过 return 跳出属于提前返回以及条件retry maxRetry不成立时的自然退出。自然退出的线从判断框的否分支出来向下连到返回失败(超时)处理框再进结束框。这条线绝对不能漏——它是最容易在画图时忘记画的一条而且忘记之后图看起来还挺完整因为看起来流程总能走到结束框。还有一个细节失败分支里的sleep(200 * 2^retry)。这个等待时间依赖当前 retry 值如果你的图里只写等待读者不知道等待多久。我习惯把计算式和结果都写进去或者写成等待 200 × 2^retry 毫秒。参数补全这件事在流图里很值钱它让图从逻辑示意升级为可复现方案。4.4 用圈复杂度给图做一次体检图基本成型之后还有一步很多人不做但特别有用的事算一下圈复杂度顺便验证路径覆盖是否完整。圈复杂度有个很实用的估算方式V(G) 判定节点数 1单个连通图的情况。严格定义是 V(G) E - N 2PE 是边数、N 是节点数、P 是连通分量数但实际画图时数判定框最快。回到我们的案例数一下判定框空订单检查、循环条件、result 成功判断、result 参数错误判断一共 4 个。所以 V(G) 4 1 5。这意味着这个函数至少有 5 条互相独立的执行路径也就意味着至少要设计 5 组测试数据才能把独立路径覆盖一遍。我把它们列出来路径编号条件组合预期结果P1订单为空返回失败(参数错误)P2订单非空第一次调用成功返回成功P3订单非空第一次返回参数错误返回失败(参数错误)P4订单非空三次都返回可重试错误返回失败(超时)P5订单非空前两次可重试、第三次成功返回成功数一数确实是 5 条。这套路径就是我画完图之后直接交给测试同事的东西——图不只是文档它本身就是测试用例的骨架。提示如果算出来的圈复杂度超过 10说明这个流程的分支已经多到容易出错我的建议是不要硬画先拆函数。拆完再画图和代码都会清爽很多。4.5 分层画法复杂模块怎么拆上面这个案例还只是单函数。真实系统里的一个完整业务流比如用户下单到支付完成判定节点轻松上二十个画成一张图必然糊成一团。分层是我这些年最依赖的手段。具体做法顶层图画业务流程的主干比如下单 → 校验库存 → 计算价格 → 生成订单 → 发起支付 → 回调处理每个环节用预定义处理框表示然后每个环节单独出一张子图编号与顶层对应。顶层图上标注环节 3 详见子图 3-1这类指引。分层的好处是每一层的复杂度都被控制在可读范围内。顶层五到七个框子图每个控制在十个判定以内任何人读的时候都能快速定位到自己关心的那一层。而且拆分之后某一层改动只需要更新对应的子图不用重画整张大图。分层也有代价跨层追踪需要频繁跳页。所以我在顶层图上会尽量标注每个环节的输入输出和关键异常出口让读者不翻子图也能掌握主线。5. 常见问题与排查速查图画出问题通常不是不会画而是没意识到自己画错了。这一节把高频错误整理成速查形式评审前对着过一遍能筛掉八成问题。5.1 图与代码不等价的典型症状症状一条件写反了。最常见的形态是把while (i n)画成i ≥ n 时继续。这类错误在评审时很难靠肉眼发现因为图本身是自洽的。我的对策是读图法拿图走一遍每一步念出当前变量是什么值读出最终的返回值和代码的返回值对一遍。念一遍比看十遍有用。症状二循环次数差一。前测和后测搞混就是前面 3.3 节讲的问题。检验方法很土但有效找一个循环体执行零次的输入看图能不能正确走到零次执行的出口。如果图的结构强迫循环体至少执行一次那就是画错了。症状三漏掉异常出口。调用了可能抛异常的接口图上却只有一条正常出口。这类遗漏在评审时特别多。我的习惯是只要用了预定义处理框就顺手问一句它失败了走哪条路答不上来就在图旁边挂个注释框标出待确认。症状四continue被吃掉。循环体里有continue图上却画成直接回到循环入口——这会让自增操作被跳过语义就错了。规范画法是continue的线指向自增框再回到判断框。5.2 版式问题交叉线与间距版式问题看着是审美实际直接影响读图效率。最常见的三种交叉线过多。三条以上交叉线读者就开始迷路。解决办法不是换颜色而是调整节点位置把被反复引用的判断框往中间挪让分支呈扇形散开或者把其中一条绕行的线改走图的边缘通道。连线过长。一条线跨越半张图去找目的地中间还穿过好几个框这是设计的信号——要么调整布局要么用连接点把小圆圈分别放在两端。间距不均。有的地方框挤成一坨有的地方大片空白。这通常是因为画图时按代码顺序摆放没有做整体规划。我的习惯是先摆关键节点起止、主要判断、结束定好整体骨架再填中间的框。下面这张速查表我贴在团队共享文档里出图前对照一遍现象根因处理办法判断框出口没标条件依赖位置暗示每条出口线补文字标签循环绕回线不清晰回流线太短或穿过框体加长回流线走框体外侧多个框挤在一起未规划整体布局先摆关键节点再填充提前返回线方向杂乱未统一出口走向统一走一侧靠近结束框标注返回内容图与代码对不上未做读图验证按变量取值走图核对返回值一处判断引出四条线分支过多拆成阶梯嵌套或多出口判断框5.3 评审环节的检查清单评审别人的图我一般按这个顺序过一遍五分钟能发现绝大多数问题。先看图的范围是否明确图上方有没有一句话描述整个流程是不是有清晰的起止边界。接着数判定框数出来的数量和代码里的条件分支数量对不对得上对不上就说明有漏画或多画。然后看出口所有可能的返回值在图上是不是都有对应的线包括异常和超时。最后走一遍变量随便挑两条路径顺着图念变量取值看结果和代码一致不一致。还有一个容易被忽略的检查项图上的处理框描述是不是动作而非状态。写校验通过是状态写校验订单参数是动作。流程图描述的是做什么不是处于什么状态。状态是状态图的活儿混进来会让读者困惑。提示评审流图的时候不要同时看代码。先只看图理解它的行为再打开代码对比。这样能真实检验这张图是否具备脱离代码独立表达逻辑的能力而这正是它的核心价值。6. 图的版本管理与长期维护画图不难难的是半年后这张图还能用。我见过太多项目的流图在第一次迭代后就彻底失效最后沦为文档目录里的装饰品。这一节讲讲怎么让图活下来。6.1 用文本描述生成图形让图跟着代码走传统绘图工具的致命问题是图是二进制文件改图要打开工具、拖框、连线、导出、提交一套动作下来十几分钟。以至于大多数人都懒得更新。我的做法是把关键的、需要长期维护的流图改用文本描述生成图形的方式。原理是用一段结构化的文本描述节点和连接关系再由工具渲染成图片。这样图就变成了纯文本文件能进版本控制能看 diff能跟代码放在同一个仓库里改动的时候改几行文本就行。这类工具里比较常用的有 Graphviz、PlantUML 等各自语法不同但思路一致。我通常把生成脚本挂到构建流程里图源文件和代码一起提交谁改了逻辑谁负责改图源代码评审时顺便看图的变化。这套机制跑起来之后流图的时效性问题基本解决了。对于偏流程、偏业务、需要给非技术同学看的图我还是会用矢量绘图工具手工画因为美观度和排版自由度更高。两类图分工明确工程内部用的走文本生成对外沟通用的走手工绘制。6.2 命名、归档与失效标记命名规范这件事越早定越好。我用的格式是模块名-功能名-层级-v版本号比如订单中心-下单校验-流程-子图3-1-v2。加上层级和子图编号是为了和分层画法对应找图的时候不用翻目录树。归档位置和代码仓库对齐。我的习惯是在模块目录下建一个flows子目录存图源文件和导出的图片README 里放一张索引表列清楚哪张图对应哪个入口函数。这样新人接手时从代码跳到图的路径非常短。失效标记是很多人忽略的一环。当一个流程被重构或下线对应图不能直接删因为可能还有人在引用。我的做法是在图顶部加一行醒目的状态标记[有效]、[已过期替代版本见 xxx]、[草案]。状态标记放在最显眼的位置比写在元数据里管用得多。最后分享一个我自己一直在用的小习惯。每次画完一张图我会把画图过程中产生的疑问单独记在一个清单里比如这个接口的超时时间是 3 秒还是 5 秒代码里看不出来。这些问题往往比图本身更有价值——它们暴露了文档缺失、命名含糊、逻辑隐蔽的地方。图画完了这些疑问也就成了一份现成的问题清单推动团队去补齐。一张好图的价值很多时候不在于它画出了什么而在于它逼着你问出了什么。
