数据流图DFD怎么画：符号、分层分解与父子平衡避坑

简介：围绕数据流图（DFD）的入门讲解与实例演示，这份PPT课件面向管理信息系统课程学习者、系统分析初学者以及需要备课或完成作业的师生，帮助建立从符号识别到分层绘制的完整认知。压缩包仅含1个PPT文件，大小约312KB，内容集中，适合课堂展示或自学翻阅。课件从数据流、加工、数据存储、外部项四类基本符号讲起，说明加工、数据存储与外部项的编号规则及数据流命名要求，并梳理确定外部项、输入输出流、主要处理功能、自顶向下逐层分解、检查完善等绘制步骤，补充布局原则、编号规范与常见注意事项；银行取款处理等实例可对照理解关联图、顶层图与逐层分解之间的关系。已有626人学习，可作为DFD入门梳理、课堂讲义和实例参照的轻量资料。

1. 数据流图不是画着好看：一张图救回的三天返工

评审室里，一位开发把系统架构图摊在桌上讲业务流程，业务方指着其中一根箭头问“这条线上到底跑的是什么数据”，全场沉默了半分钟，没人答得上来。那张图后来被推翻重画，改用数据流图（DFD）重做，前后三天。这件事让我一直保留一个习惯：只要涉及“信息从谁那里来、中间被什么处理、最后落到哪个存储”，先画数据流图，再谈框架和选型。它不解决性能，也不解决部署，它解决的是一件事——让业务方、分析人员和开发对同一套信息流转过程形成同一个理解，而且是能签字确认的那种理解。刚接手需求的新人、做系统分析的老手，只要图要给别人看，这一关都绕不过去。

2. 四个符号定下一张图的下限：数据流、加工、存储、外部项怎么摆

数据流图容易给人一个错觉：不就是画几个圈、几个框、连几根线吗。真实情况是，符号本身没有难度，难的是每个符号背后要填什么、能填什么、绝对不能填什么。这套讲义用的是 Yourdon/DeMarco 风格的符号：圆或椭圆表示加工，矩形表示外部项，开口矩形表示数据存储，带箭头的线表示数据流，前缀分别是 P、S、D、F。符号选错，图就是废的；符号选对但不守规则，图照样是废的。

2.1 先定符号体系，别在一张图里混两套

主流 DFD 符号有两套。Yourdon/DeMarco 一套用圆圈画加工；Gane-Sarson 一套用圆角矩形画加工、用左端开口的矩形画数据存储、用双线箭头画数据流。这两套各自都是自洽的，混用之后外行看不出问题，内行一眼就知道这张图没有统一过口径——最典型的后果是评审时有人把椭圆当成数据存储，或者把开口矩形当成一个子系统。动漫、教材、咨询公司的模板来源五花八门，一份图里出现三种画法的情况我见过不止一次。

我的处理办法是画之前就写一句约定，贴在图的标题下方：本图采用 Yourdon/DeMarco 符号，加工=P，存储=D，外部项=S，数据流=F。这句话占不了一行篇幅，但能挡掉后续一半的符号争议。工具上，draw.io 直接有 DFD 图元库，Visio 有数据流图模板，用 PPT 手画也能画，但要保证节点是矢量对象而不是图片，否则改一层图就得重画一遍。

2.2 数据流：名字、方向、同名规则，以及“实物不能当数据流”

数据流由一个或一组确定的数据组成，它的名字必须能直观反映内容。“数据”“信息”“输入”“结果”这类名字在评审里几乎必然被追问“什么数据”，然后你要现场解释，解释完对方还是记不住。合格的名字长这样：取款单、合格订单、汇总订单、图书目录、结算清单——看到名字就知道线上跑的是什么东西。

方向必须标。数据流是单向的，一条线只能指一个方向，双向数据交换就画两根线，或者明确拆分出输入流和输出流。两个符号之间允许多条数据流同时存在，DFD 不表达它们之间的先后、主次、同步关系——这一点经常被误解，有人试图用线的粗细或者箭头长短暗示“这条先走那条后走”，那是流程图该干的事，不是数据流图。

数据流可以同名，但同名的两条流必须指同样的数据结构且含义一致；反过来，结构相同但含义不同的数据，就不能共用同一个名字。讲义里反复强调的一条是：不能画成 N 个不同含义的东西都叫“通知”。同名不是省事，同名是要保证“看到这个名字就知道是同一类数据”。

这里有个坑必须提前说：实物不能当数据流。银行取款例子里，现金是实物，不能画成一条从系统流向储户的数据流。讲义的处理方式是把返回给储户的东西写成“存折、利息单、结算清单”，现金通过注释或者说明补充。货物流、资金流在物理层面走的是另外一条通道，DFD 只描述信息，画进去会让整张图的语义立刻不纯。

还有一条更隐蔽：不要把控制流当数据流。比如“定时触发”“超时信号”“开关状态”，这些是控制信息，不是被加工处理的数据。DFD 里出现大量这种线，说明这张图已经开始向流程图漂移了。

提示：判断一条线该不该画，问一句“这条线上跑的东西，会不会被存进数据库或者被写进报表”。答案是会，就是数据流；不会，多半是控制流或实物。

2.3 加工：编号、动宾式命名和分解到什么程度停

加工表示对数据流的操作，符号分上下两部分：上面是标识部分，写加工编号，以 P 开头，编号在全图内唯一；下面是功能描述部分，写加工名，要求简洁、能概括行为，详细逻辑放到数据词典里去定义，不要塞进圆圈里。

命名上我坚持动宾结构：审核取款单、检查订单、汇总订单、发送订单、打印账簿。名词化的加工名（“订单管理”“数据处理”）会让读者无法判断这个加工到底干了什么，也无法判断它该不该继续往下分解——一个叫“数据处理”的圆圈，你永远不知道它是不是基本加工。

分解深度是另一个高频争议点。原则是逐层分解到“基本加工”，也就是加工功能足够简单、能用一小段文字说清、不需要再拆。经验值一般三到五层，超过五层通常不是系统太复杂，而是上层切分切错了。分解不足的典型症状是某个加工下面挂着七八条输入、五六条输出，读者看到这个圆圈必须停下来猜；分解过度的症状是某一层出现一堆只连一根线的小加工，那说明这一层只是把一句话拆成了几截，没有信息增量。

加工最容易犯的三种结构性错误：

• 黑洞：只有输入没有输出，数据进去就没了。
• 奇迹：只有输出没有输入，数据凭空产生。
• 灰洞：有输入也有输出，但输入的数据不足以产生输出，中间缺了来源。

这三种错误在图面上都不显眼，评审时靠人眼盯很容易漏。后面第 6 章我会给一段脚本，把这类问题变成可自动检查的项。

2.4 数据存储与外部项：编号、复用画法和边界感

数据存储用来存数据，名字写在开口矩形里，要概要说明里面主要放什么，编号以 D 开头。讲义里提了一个很实用的细节：在分层 DFD 中，数据存储一般只属于某一层或某几层，所以也叫局部文件；为了避免图面出现大量交叉线，同一个数据存储在图中可以画多处，用重复符号表示。这一点新手常常不敢做，觉得“一个存储画两次是不是画错了”，其实这是标准做法，比拉一条横穿整张图的长线要清楚得多。

数据存储的两条硬性要求：第一，存储上一定要有数据流，只进不出是死库，只出不进是凭空造数据；第二，存储不是加工，它不产生任何转换，不能给它写“整理数据”“更新记录”这种动作性名字，那是加工该干的事。

外部项又叫源点和终点，是系统之外的实体，可以是人，也可以是别的系统。它编号以 S 开头，通常在图上不需要详细描述，因为它不在系统边界内。外部项的作用是标出系统界面：从外部项到系统的流是输入，从系统到外部项的流是输出。明确系统界面是绘制原则里的第一条，而外部项就是把这条原则画出来的那个符号。

外部项最常见的错误是被当成了系统内部模块。比如把“财务部”“仓储系统”画在图的中央，还给它连了一堆加工，读者根本分不清哪里是系统内、哪里是系统外。我的习惯是把所有外部项贴着图的边缘放，左边放输入源，右边放输出终点，中间留给加工和存储，视觉上一眼就能看出边界在哪。

3. 从关联图拆到二层图：自顶向下七步怎么落地

符号摆对了只是及格线，真正的活儿在分解。讲义给出的绘制步骤是七步：确定外部项、确定输入输出流画出关联图、确定主要信息处理功能并分解子系统、自顶向下逐层分解、重复分解、检查布局与命名编号、与用户交流确认。这七步听着像流程口号，落到纸上其实每一步都有具体的判断点，尤其是“这一层该拆成几个加工”这个问题，讲义没有给公式，得靠对业务的理解。

3.1 关联图：把整个系统压成一个加工

关联图是第 0 层，画法极其克制：中间一个加工代表整个系统，四周是外部项，之间只有输入流和输出流。银行取款例子里，关联图就是一个“取款处理”圆圈，左边是储户，右边也是储户，输入流是“取款单、存折”，输出流是“存折、利息单、结算清单”。注意输出流里没有现金，因为现金是实物。

关联图的价值在于逼你回答两个问题：这个系统到底跟几个外部实体打交道，以及它对每个外部实体收什么、给什么。很多项目在关联图阶段就暴露问题——外部项数出来十几个，说明系统边界根本没划清；或者某个外部项只有输入没有输出，说明这个实体的诉求还没被想明白。

画关联图时，系统内部的数据库、模块、接口一律不出现。这一点经常有人忍不住，觉得“不画出来讲不清楚”，那就说明他脑子里还停留在物理实现层，没有切到逻辑层。

3.2 顶层图：找出主要信息处理功能与数据存储

关联图之后是顶层图，也就是把中间那个大圆圈拆成几个主要加工，同时把这一层需要的数据存储摆出来。拆几个？一般三到七个，超过七个说明这一层粒度太粗，需要再往上一层收敛；只有两个说明拆得不够，还得继续找功能。

图书预订系统的顶层图拆成三个加工：订单检查 P1、订单处理 P2、发送订单 P3，配上图书目录 D1、合格订单 D2、待发出订单 D3、出版社要求 D4 四个数据存储，外部项是顾客 S1 和出版社 S2。这张图能被读懂，是因为每个加工对应一句业务动作：检查订单合格不合格、处理合格订单、把汇总结果发出去。如果当时拆成“订单管理”“订单服务”这种名字，后面二层图就没法落笔。

数据存储在这一层的取舍也有讲究。只放这一层真正用到的存储，不要把数据库里的每张表都摆上来。D1 图书目录、D2 合格订单这类是这一层加工直接读写的；如果某个存储只在更下层才出现，就留到那一层再画，顶层图上不出现。这叫“数据存储作为两个加工之间的界面来安排”——它通常负责衔接上下游两个加工，而不是孤立存在。

3.3 父子平衡：分解时最容易断的一条链

分解不是随便往下切，切完要满足父子平衡：子图的所有输入输出数据流，必须和父加工在父图中对应的输入输出完全一致。父加工 P2 有输入“合格订单”和输出“汇总订单”，那么 P2 分解出来的二层图里，这些流必须原样出现在子图的边界上，一条不多一条不少。

不平衡的两种形态都很常见。一种是子图里凭空多出一条流，比如二层图里突然从外部项直接引一条线进到某个子加工，那说明父图漏画了这条流。另一种是子图里少了一条流，父加工明明输出“汇总订单”，子图里却找不到谁产生它，那说明分解不完整。这两种毛病在图上都不刺眼，但会让后续设计阶段的对齐工作变成灾难——接口对不上，数据库表设计对不上，最后返工的是代码。

提示：子图边界上的数据流，用父加工的名字做一次核对，把父图的输入集合、输出集合列成两行，再和子图边界逐一对照，比盯着图看快得多。

分层编号也要跟上：父加工是 P2，子加工就是 P2.1、P2.2、P2.3、P2.4。编号不只是标签，它是父子关系的锚点，评审时别人说“P2.3 那块我看不懂”，你能一秒钟定位到哪张图的哪个圆圈。

3.4 银行取款实例走一遍

关联图之后是顶层图。取款系统拆成两个加工：取款审核 P1 和取款处理 P2，数据存储是帐目库 D1 和取款记录 D2，外部项仍是储户 S1。输入流“取款单、存折”进 P1，P1 分出两路：不合格的“不合格存折、取款单”退回储户，合格的“合格存折、取款单”进入 P2。P2 读写 D1 修改帐目，把记录写进 D2 存档，输出“存折、利息单、结算清单”给储户。

这张图之所以经得起推敲，是因为每一步的输入输出都能在业务描述里找到对应句：审核并查对帐目、不合格退回、合格送取款处理、处理取款修改帐目、存档。凡是业务描述里没有的流，图上就不该有；凡是业务描述里提到的流转，图上必须有一条线。这个来回对照的方法，比任何画图技巧都管用。

这个例子还演示了前面那条规则的落地：现金不出现在任何一条数据流上。第一次画这张图的人几乎都会把“现金”画到 P2 的输出里，因为业务上确实是给钱。但只要记住 DFD 描述的是信息流，现金的交付就必须让位给“利息单、结算清单”这些单据，实物交付另行说明。

3.5 图书预订系统：为什么必须拆到第二层

图书预订的顶层图画完并不算结束。P2 订单处理在顶层图上是一个圆圈，但业务描述里它包含“根据顾客情况和订单数目分类”“随时处理优先订单”“定期处理正常订单”三件事，一个圆圈装不下这么多含义，必须继续分解。

二层图把 P2 拆成四个子加工：数目统计 P2.1、订单分类 P2.2、随时处理 P2.3、定期处理 P2.4，并补进订单数目 D5、顾客情况 D6、优先订单 D7、正常订单 D8 四个存储。这时图面开始变复杂，交叉线风险陡增，就需要靠布局规则来控制：把 P2.1、P2.2 放在左侧作为分类段，P2.3、P2.4 放在右侧作为处理段，存储夹在中间，让数据从左往右单向推进。

这一步也是检验分解是否合理的时刻。如果拆完之后发现某个子加工只连一根线、没有自己的处理逻辑，那它就不该独立成节点，应该合并回上一级；反过来，如果某个子加工又挂了七八条流，说明还得再往下拆一层。判断标准只有一个：这一层的每个加工，能不能用一句话说清它在干什么。

4. 避坑：六条翻车记录和现场处置办法

数据流图的规则不多，但每条规则被违反的方式都很隐蔽，图面上看着挺整齐，一评审全是问题。下面这几条是我在评审里反复见到的，按“现象—原因—解决”记下来，照着对一遍能省掉大半返工。

4.1 数据流直接连两个数据存储

现象：图上出现一条箭头，从 D1 图书目录直接指向 D2 合格订单，中间没有经过任何加工。

原因：画图的人脑子里的模型是“把目录里的数据搬进合格订单表”，这是数据库操作的思维，不是信息处理的思维。数据存储本身不加工任何东西，它只是放着。

解决：中间补一个加工承接这个动作，比如“订单检查 P1”读 D1、写 D2。判断口诀很简单——数据流必须通过加工，两个存储之间不允许存在直接连线，两个外部项之间同理。这条规则一旦放开，整张图就会退化成一张表关系图。

4.2 把实物画成了数据流

现象：银行取款图里，P2 输出一条叫“现金”的流指向储户；仓储系统图里，出库加工输出一条“货物”流指向客户。

原因：业务人员描述流程时说的就是“把钱给客户”“把货发出去”，画图的人照着原话抄，没有做信息与实物的区分。

解决：把实物替换成承载信息的单据或记录，比如“结算清单”“出库单”“发货通知”，实物交付在图的注释里说明，或者另画一张物流图。这条不处理，图在业务侧看着亲切，在设计和开发侧完全没法用。

4.3 子图和父图对不上

现象：父图里 P2 的输出是“汇总订单”，拆到二层图之后，找遍整张子图也找不到谁产生“汇总订单”，反而多出一条父图里没有的“出版社反馈”。

原因：分解的时候是按“我觉得这里应该有什么”往下画，而不是按父图的边界往下拆。多出来的流通常是画图过程中新想到的需求，漏掉的流通常是拆到一半忘了回头对。

解决：分解前先把父加工的输入集合、输出集合抄在纸上，子图画完逐个打勾。这一步花不了五分钟，但不做的话，等到详细设计阶段对接口时，代价是按天算的。

4.4 加工成了黑洞或者奇迹

现象：某个加工有两条输入流，一条输出都没有；或者某个加工只往外输出“报表”，没有任何输入。

原因：分解时注意力集中在主干路径上，边缘加工草草收尾；也可能是上游的数据来源还没确定，画图的人索性先空着。

解决：每个加工至少一进一出，这是底线。真遇到“暂时不确定来源”的情况，也要画一个外部项或者数据存储占位，并在旁边标注待确认，而不是留一个没有输入的圆圈在图上——留白在评审时会被当成画完了。

4.5 一层图里塞了十几个加工

现象：顶层图上密密麻麻排了十二个圆圈，连线交叉，图例比图还大。

原因：把“功能清单”直接翻译成了加工，系统有几个模块就画几个圆圈，没有做归并。

解决：顶层图控制在三到七个加工，超出的部分合并同类项或者下沉到下一层。判断能不能合并，看它们是不是围绕同一批数据在干活：围绕订单的检查、分类、汇总可以合并成“订单处理”，等下一层再拆开。层次感是 DFD 最值钱的地方，一层画满就等于放弃了分层。

4.6 编号乱、命名飘

现象：同一张图上出现 P1、P3、P1.2 混排，数据存储一会儿叫 D1 一会儿叫“图书库”，加工名有的写“审核”有的写“审核处理模块”。

原因：多人协作画图，没有统一的命名和编号约定，各画各的，最后拼在一起。

解决：开工前定一张命名表，加工用动宾短语、存储用名词、外部项用实体名，编号严格按层级走。数据存储在多层图里重复出现时，编号必须一致——这一点尤其容易出错，同一个库在顶层叫 D1，在二层叫 D5，读者会以为是两个不同的东西。

5. 布局、编号与评审：让图从“能看懂”变成“能签字”

图画对了和图画好了是两件事。前者说的是语义没错，后者说的是别人愿不愿意看、能不能在十分钟内理解。讲义里把“合理布局”单列为一条绘制原则，不是客套话——同一套逻辑，布局好的图评审半小时过，布局差的图要开两次会。

5.1 布局：减少交叉线，保持单向推进

布局的第一目标是减少交叉线。手段有三个：一是把数据存储重复画，讲义明确允许这么做，一个存储在上游和下游各画一次，比拉一条横穿全图的长线清楚得多；二是按数据流向排布，输入源放左边，输出终点放右边，加工按处理顺序从左到右排，让主干流呈现一个大致的方向感；三是把同层的加工对齐，别让圆圈高低错落，读者会以为位置本身有含义。

第二目标是控制单图规模。一张图上加工超过九个、连线超过二十条，基本就到了该拆的临界点。这时候不要硬撑着画，问问自己这一层是不是本来就应该再分一层。

第三目标是层级一致。同一张图上的加工，粒度要接近。如果图里既有“处理订单”这种大颗粒，又有“累加金额”这种小颗粒，读者会困惑于这一层到底在讲什么。粒度不一致通常意味着分解没做完，某个分支被提前展开了。

5.2 编号体系：P、D、S、F 四套编号的对齐规则

编号看起来是琐事，实际上是对齐工具。四套前缀各自的规则要记牢：

对齐的关键在 P 和 D。P 的层级编号是父子关系的唯一凭证，评审时定位问题全靠它；D 的跨层一致性则是判断“这张图有没有被人中途改乱”的最快方式——如果同一个存储在顶层是 D1、在二层变成 D6，那大概率是两个人各画各的拼起来的。

5.3 数据词典：DFD 的另一半

DFD 只画流转，不解释内容。每个数据流、每个数据存储里到底有哪些字段、什么类型、取值范围如何，全在数据词典里。讲义里多次提到“详细描述在数据词典中定义”，这句话的分量比它看起来重。

实际操作中，数据词典至少要为每个数据流列出入组成部分，为每个数据存储列出记录结构，并给出每个数据项的别名、类型、长度、取值范围。没有词典的 DFD，交付时等于只交了一半：开发看着图知道数据从哪来、到哪去，但不知道数据长什么样，接口还是没法定义。

我的习惯是图和词典同步做，画到哪写到哪，绝不图先画完再补词典。补词典的过程往往能反过来发现图上的问题——比如某个数据流写不出组成成分，说明这条流的含义还没想清楚，很可能是个控制流混进来了。

5.4 与用户走查：把图交给不懂技术的人讲一遍

讲义把“和用户交流”写进了绘制步骤和绘制原则里，这不是流程装饰。DFD 最大的价值就是面向用户、不涉及技术细节，那么这个价值只能在用户身上验证。

走查的方法我一般这么用：把图推给业务方，让对方顺着数据流讲一遍业务过程，讲不通的地方就是图有问题的地方。这个方法比我自己讲一遍有效得多，因为讲解时人会不自觉地填补空白，而让对方讲，卡壳的位置一定是图没表达清楚的位置。

走查时重点问三类问题：这条数据流是从哪个环节产生的，中途有没有别的处理，最后存在哪里、被谁用。三个问题问下来，遗漏的加工和存储基本都会浮出来。走查完当场改图，改完再复述一遍，比事后发邮件确认有效。

6. 把 DFD 做成可校验的模型：一段脚本兜住父子平衡

图画多了会发现，最难自查的不是符号和命名，而是父子平衡和孤立节点这两类结构性错误，人眼盯三张图还行，盯十张必然漏。我的做法是把每层图先用结构化文本描述一遍，再用脚本跑检查，跑通了再画正式图。

6.1 用字典把图描述成数据

节点和流先写成 Python 字典，字段含义固定：in是本加工的输入流编号集合，out是输出流集合，children记录分解关系。这样父图和子图可以放在同一份数据里做比较。

# dfd_model.py # 每条数据流用编号表示，节点 key 即编号（P/D/S） dfd = { "P0": {"name": "图书预订系统", "in": {"F1"}, "out": {"F2"}}, "P1": {"name": "订单检查", "in": {"F1"}, "out": {"F2", "F3"}}, "P2": {"name": "订单处理", "in": {"F2"}, "out": {"F4"}}, "P3": {"name": "发送订单", "in": {"F4"}, "out": {"F2"}}, } # 分解关系：父加工 -> 子加工列表 children = {"P0": ["P1", "P2", "P3"]} # 每层图边界上出现的数据流（用于核对父子平衡） boundary = { "P0": {"in": {"F1"}, "out": {"F2"}}, "P2": {"in": {"F2"}, "out": {"F4"}}, }

6.2 平衡检查脚本

脚本做三件事：核对父子边界流是否一致、找出只有输入或只有输出的加工、找出没有被任何加工读写的孤立存储。

# check_dfd.py def check_balance(dfd, children, boundary): problems = [] for parent, kids in children.items(): child_in, child_out = set(), set() for k in kids: child_in |= dfd[k]["in"] child_out |= dfd[k]["out"] b = boundary[parent] # 子图缺了父图声明的输入/输出，说明分解不完整 if b["in"] - child_in: problems.append(f"{parent} 子图缺失输入: {b['in'] - child_in}") if b["out"] - child_out: problems.append(f"{parent} 子图缺失输出: {b['out'] - child_out}") # 子图多出父图没有的流，说明父图漏画 if child_in - b["in"]: problems.append(f"{parent} 子图多出输入: {child_in - b['in']}") if child_out - b["out"]: problems.append(f"{parent} 子图多出输出: {child_out - b['out']}") # 黑洞与奇迹 for pid, node in dfd.items(): if not pid.startswith("P"): continue if node["in"] and not node["out"]: problems.append(f"{pid} 只有输入，疑似黑洞") if node["out"] and not node["in"]: problems.append(f"{pid} 只有输出，疑似奇迹") return problems for p in check_balance(dfd, children, boundary): print(p)

参数说明：dfd存所有节点及其输入输出流编号，编号必须与图面完全一致，这是脚本能起作用的前提；children只记录有分解关系的父加工，没有子图的叶子加工不要写进去，否则会误报；boundary记录每层边界上的流，来源就是父图，它和dfd里的字段分开存，避免边改子图边改父图时互相污染。脚本输出的每一条都是一处需要回到图面确认的位置，不自动改图，因为多出来的流可能是漏画，也可能是子图画错，得人判断。

6.3 让模型和图面同源

模型校验通过后，用 Graphviz 直接出草图，能省掉手工摆位置的重复劳动。开口矩形在 DOT 里用shape=folder近似，正式交付再换 draw.io 精修。

digraph DFD { rankdir=LR; node [fontname="SimHei", fontsize=11]; S1 [label="S1 顾客", shape=box]; P1 [label="P1 订单检查", shape=ellipse]; D1 [label="D1 图书目录", shape=folder]; S1 -> P1 [label="F1 订单"]; D1 -> P1 [label="图书目录"]; P1 -> P2 [label="F2 合格订单"]; }

这段只画了顶层的一小段，完整图按同一模式补节点即可。它的价值不在美观，在于改一处模型就能重出一版图，不会出现图和词典脱节的情况。

从那以后我每次画完一层图，都会先跑一遍这段检查再拿去评审，宁可被脚本挑刺，也不想在会议室里被人指着一条线问“这个从哪来的”。这个习惯帮我挡掉的返工，比任何画图技巧都多。希望帮到你。

本文还有配套的精品资源，点击获取