企业官网建设流程全解析

diagram-design 这门手艺，看起来是在画图，实际上是在给“信息”做排版。我见过不少这样的场景：某开发者把做好的系统架构图投到会议室大屏上，信心满满地开始讲，结果底下的人盯着屏幕看了十来秒，开口第一句是：这图从哪看起？那一刻我就知道，图本身的技术细节再完整，也已经输在了 diagram-design 这一步。会画图不等于画得好，放得下不等于讲得清。这篇内容就围绕 diagram-design 聊透：它到底解决什么问题、动手前要想什么、怎么把一张图从“能看懂”做到“耐看”，再加上我踩过的坑和一套可以直接照做的过程。适合经常画架构图、流程图、可视化汇报材料，或者被各种图折腾得头疼的运维、开发、产品、设计同学。

1. 先弄清楚 diagram-design 在画什么：信息的关系图，不是美术作品

1.1 先从一张“惨图”说起

以前帮某团队评审过一张业务全景图，打开文件的那一刻，我的第一反应不是“这个系统真复杂”，而是“这图为什么会画成这样”。几十个方块排得密密麻麻，每个方块都有不同的圆角、边框颜色、阴影效果，连线五花八门，有直线、曲线、折线，有些线甚至穿过了别的节点的标题文字。作者是个挺有经验的开发者，他说：“我熬了两个晚上，把每个模块都画进去了，连每个服务之间的接口名都标上了。”

问题就在这里。他把 diagram-design 理解成了“把所有信息都画上去”，把画图当成了事无巨细的记录。但真正好的图，最重要的能力不是承载信息，而是筛选信息。一张图如果第一眼让人抓不住重点，不管里面写了多少细节，都是失败的。后来我帮他做了一件事：只保留三层内容——核心链路、关键依赖、必要的支撑模块。删掉将近一半节点后，反而评审会上每个人都看懂了系统的主流程。

1.2 diagram-design 和画图的区别

很多人会把 diagram-design 等同于“画图”，这是最大的误解。画图关注的是外观：形状好不好看、配色是否漂亮、图标用哪个更精致。而 diagram-design 关注的是关系：节点之间是包含、依赖、调用还是时序先后？这种关系用什么样的图形语言表达最容易被理解？设计图纸不是涂鸦，它是一张承载关系的语义网。

我用一个特别直白的类比：diagram-design 就像给陌生人指路。指路时你不会把这条路上的每一家店铺、每一个路灯位置都讲一遍，你只会说：从这走到第一个路口右转，再直行两百米，左手边那栋楼就是。图也一样，读者要的是清晰的路径、关键的节点、明确的终点。把关系讲清楚，比把外形画漂亮重要一百倍。所以我在画任何图之前，脑子里闪过的第一个词不是“好看”，而是“关系”。

1.3 常见 diagram 类型与各自的设计侧重点

diagram 这个词的范围很广，常见的有架构图、流程图、时序图、组织关系图、数据流图、思维导图等等。同样叫“画图”，每种图的设计侧重点完全不同，按同一套思路去画必然出问题。我整理了一张表，方便对照：

不同类型的图，要优先保证的“核心关系”不同。画架构图，如果分层乱了，那这张图的骨架就塌了；画流程图，如果某个条件分支没画完整，读者按路径走不通，那图再漂亮也没用。diagram-design 的第一步，其实是确定这张图到底要表达哪一类关系，再根据关系类型决定所有图形元素的选择。脱离关系谈设计，和脱离菜品谈摆盘是一个道理。

2. 动手前压住鼠标的三个问题：受众、层级、阅读顺序

2.1 先回答“给谁看”：受众决定抽象程度

很多图之所以画完没人看，往往不是画得不好，而是压根就没有想过“给谁看”。同一套系统，画给技术团队看和画给业务领导看，内容可以差一大半。技术团队关心模块拆分、调用关系、数据存储，那图里就可以放服务名、端口、协议细节；业务领导关心的是系统能支持什么业务能力、核心流程走通没有，你塞一堆内部服务名，人家只会觉得这图是一团乱麻。

我在实践中养成了一个习惯：动笔画图之前，先写一行字贴在画布角落——“这张图的读者是谁，他看完之后要做什么判断”。如果读者是来做技术选型的，那就把候选方案和它们之间的边界问题画明白；如果读者是来审批预算的，那就要突出系统规模、核心价值和风险节点；如果读者是要照着图去开发的，那图要精确到模块接口的粒度。给不同的人看，可以画同一个系统的两版图，这很正常，也不是浪费时间，因为受众不同，抽象层次就不同，硬要用一版图通吃所有人，最后往往是所有人都不满意。

2.2 把信息分成三层：主干、分支、叶子

画图时最容易犯的毛病，是想把所有信息平等对待。实际上，任何一张好图里的信息都应该分成三层：主干、分支、叶子。主干是这张图要讲的核心故事线，比如订单系统里的“下单到履约”这条主线；分支是支撑主干的关键模块或关键路径，比如支付、库存、优惠计算；叶子是那些细节补充，比如某接口的超时设置、某策略的具体规则，这些根本不需要占一个节点，用脚注、颜色标记或者干脆删掉。

有一次我帮某开发者梳理一张用户权限图。他一开始把所有角色、所有权限点、所有菜单项全部铺在图上，密密麻麻五六层。我让他先标出主干：用户从登录到进入某个页面的过程。再圈分支：角色分组、权限判断、数据范围控制。剩下的菜单项全部下沉为附件说明。图改完之后，节点数从四十多个降到十五个，他反而觉得逻辑清楚多了。这就是信息分层的作用：让主干从视觉上跳出来，而不是淹没在对细节的执念里。

2.3 为读者设计一条阅读动线

图和人一样，有条“动线”。所谓动线，就是读者眼球会跟着走的路线。一张图如果没有动线，读者的视线就会在图上跳来跳去，想从任何一个入口开始都行，结果是哪个入口都进不去。阅读动线一般有两种：从左到右，从上到下。这两种方向符合大多数人的阅读习惯。在画图前，你可以先用铅笔在草稿纸上画个大方向箭头：用户从左上角进来，主流程往右下走，辅助信息在右边或底部。

为了让动线更明确，我常用三个手段：一是给主干链路上的节点加粗边框或加填充色，让它和次要节点形成对比；二是给关键路径的连线加粗，让视觉自然跟上粗线走；三是在图的角落标序号，比如 1、2、3，或者把主流程的节点摆成一条不受阻挡的通道。类比来说，动线就是导游手上的小旗子，读者不需要思考“我该看哪里”，扫一眼就知道从哪个节点出发、到哪里结束。等读者能毫不费力地讲出“这张图画的是某某事情的完整过程”，这张图的动线就已经成功了。

3. 视觉落地中的六条硬规则：从能看懂到耐看

3.1 形状语义要保持稳定

很多人画图时随手用形状，矩形方框和圆角矩形混着用，今天方块代表服务，明天圆角代表服务。等到读者看图时，就会下意识地猜测“这个形状和那个形状有什么区别”，而一张图如果让人停在形状差异上做阅读理解，那它就已经失败了。形状是 diagram-design 里最早被感知到的语义层，必须保持稳定。

我在团队内部定的习惯是这样的：普通矩形代表服务、系统、模块；圆角矩形代表页面、界面或操作动作；菱形代表判断和分支节点；圆柱体代表数据库或存储；胶囊形的圆角条代表外部角色或出入口。规则一旦定下来，图里所有同类型的东西必须全程用同一种形状。如果形状本身承载不了复杂语义，用文字标注，不要为了“好看”随便换形状。尤其是团队协作时，最好把形状约定写进文档，不然每个人画的图形状不一样，拼在一起就是一场语义灾难。

3.2 连线方式表达的关系不止一种

图上最容易被随手乱画的就是线。很多图里所有连线都一样粗细、一样颜色，看不出哪个是主流程、哪个是广播通知、哪个是异步回调。这样一来，读图的人只能靠猜，甚至只能把图放大逐一核对接口，效率极低。我整理了一套连线的语义约定，可以参考：

连线的方向也要统一。通常我让箭头指向数据流动的方向，或者指向被依赖的一方。同一张图里，不要有时候箭头指向调用方，有时候箭头指向被调方，那等于让读者每次都要重新判断规则。顺带一提，连线尽量不要穿过节点文字，能绕着走就绕着走，实在绕不过去，优先让横线保持水平，让读者能顺畅地追着线走。

3.3 对齐与留白：专业感的一半来源

一张图的“专业感”，很大程度不取决于配色和图标，而取决于对齐和留白。你去看那些设计稿和随手画的图，核心差异就是每个节点之间的间距是否统一、是否对齐到网格。我画图时默认打开网格对齐，所有节点统一以 8 的倍数作为间距基准：间距 8、16、24、32。容器内部的内边距至少留 16 或 24，容器和画布边缘至少留 32。这样的间距节奏，会让图看起来“顺”，不是靠哪根线画得多直，而是整体的呼吸感对了。

留白不是浪费，而是必要的“空气”。很多图挤到极致，每个方块间距只有 4 像素，生怕一页纸放不下内容，结果读起来眼睛都累。我相信一个原则：一页画布上如果全部塞满，读者会在视觉上产生抵抗，远不如留出足够空白，让每一组模块清晰独立。宁可多分几页，也不要挤压在一页里。

3.4 取色克制：一套图只用三到四种颜色

颜色是很多人画图时的兴奋点，也是最容易翻车的地方。红橙黄绿青蓝紫全用上，最后看起来像一块调色盘，没有任何重点。真正有效的取色方案是非常克制的：一套图里，基础色不超过三种，强调色用一种，状态色用一两种且和基础色区分开。

我常用的做法是：先选一个主色系，例如蓝灰色系，用它作为大面积背景和节点底色；再用同色系里的浅色区分层级；然后用一个强对比色（比如橙色或深蓝色）专门标核心链路或关键节点。状态色比如成功、警告、失败，只在需要表达状态的图上使用，而且最好搭配图标或文字一起出现。还有一个容易被忽略的细节：红绿不要同时大面积出现，因为红绿色盲读者会把两张图完全读反。颜色应该是语义的一部分，而不是装饰的一部分，这一点怎么强调都不过分。

3.5 三层字号体系：标题、实体、说明

图里的文字大小如果不分层，视觉权重就会全部持平，读者抓不住什么重要、什么次要。我对字号的要求很固定：第一层是容器标题和图的主题，用最大字号和加粗；第二层是节点名称，也就是大多数人第一眼就要看的信息，用中等字号；第三层是补充说明、端口号、注解，用小字号。层级之间至少差 1 到 2 个字号，例如 16pt、12pt、9pt 或者 14pt、11pt、9pt。

字体尽量用一套，不要一会儿衬线一会儿无衬线。同一个画布里，字体种类超过两种，基本就可以判定为排版失控。国内的技术文档和项目文档，用无衬线字体更稳妥，字号定好之后，全图统一执行。小字作为说明，不需要每个节点都堆满，只写关键补充，否则层级又会被细节淹没。

3.6 信息密度控制：一张图放三十个节点已经算多

信息密度是 diagram-design 里最容易被低估的问题。很多图之所以让人“不想看”，就是一眼扫过去节点多得吓人。我个人的经验值是：一张示意图，主要节点在二十到三十个之间比较适合；一旦超过三十个，读者就需要不停分辨哪些是核心、哪些是辅助，认知负担陡然上升。超过这个量，就应该考虑拆图：一张全景概览图放主干，一张或多张子图展开分支细节，通过编号或者超链接把子图和主图关联起来。

拆图的另一个好处是方便维护。一张几百节点的巨型图，稍微改个模块名，连带着所有布局都要重排；但拆成多张图，每张图独立演进，改动的成本会小很多。判断信息密度合不合格，有一个简单方法：把整个画布缩放到 50%，如果缩放到这个比例时文字和节点边界仍然能清楚辨认，说明密度适当；如果已经糊成一团，趁早拆开。

4. 工具选型的真实体验：不同阶段用不同家伙什

4.1 快速构思期：先别打开正经绘图工具

很多人一上来就打开绘图工具，从零开始摆方块、拉线，结果为了调整一个节点的位置消耗了半小时，思路反而被工具绑架了。快速构思期的目标只有一个：把关系和动线定下来。这时候我强烈建议用白板，或者几张纸一支笔。白板上可以随手画圈、画箭头、写模块名，画错了也就擦掉重画，成本极低。关键不是画得精致，而是快速验证几个问题：主干是哪条线、分支有哪些、分几层、哪里会交叉。

我自己在画正式图之前，至少有一版纯手绘的草稿。草稿不需要给别人看，但它是整张图的骨架。没有这版草稿直接进绘图工具，很容易陷入“边画边想”的泥潭，画到一半发现层级不对，又要全部推倒重来，那才是最耗时的。

4.2 正式产出期：绘图工具的四个判断标准

构思定下来之后，再打开正式的绘图工具。选择工具我一般看四个标准：对齐能力、图层管理、导出格式、协作便利性。对齐能力决定你画出来的图是否整齐，这比任何花哨功能都重要；图层管理决定你是否能把背景、主流程、标注分开维护；导出格式决定你能不能放进文档或演示文稿；协作便利性决定团队成员是否能同时编辑。

市面上的绘图工具五花八门，有的适合在线协作，有的离线可用，有的导出效果精美，有的支持插件扩展。我的建议是不要追求“最强工具”，而是选一个你愿意天天打开的工具。工具越顺手，越会减少画图的心理负担。很多项目里，真正被频繁使用的往往不是功能最全的，而是打开最快、导出最方便的那个。选错工具的结果，就是每次画图都像上刑。

4.3 代码驱动与协作场景：版本管理友好的方向

有几个场景值得单独说：一是图和代码一起维护的场景，比如系统架构图跟着代码仓库走，这种时候文本形式的图定义就有优势，因为可以走版本管理、代码评审、变更记录。二是多人同时在线的场景，团队协作时，绘图工具的实时同步能力比单机精美渲染更重要。三是文档自动化场景，希望图随文档一起编译输出，那就要考虑文本化方案的生态兼容性。

需要提醒的是，文本化工具图适合节点不多、逻辑清晰的图，一旦节点增多，纯文本维护的布局调整会让人抓狂。遇到复杂大图，我宁可先用可视化工具拖拽出主结构，再交给其他同学用代码维护后续改动。工具没有绝对的好和坏，只有适不适合当前场景。

4.4 我的组合打法

现在我自己的固定组合是：构思阶段手绘或白板，正式阶段用绘图工具，需要版本管理时把主要架构图导出为通用格式并附加说明文字。如果一个图需要长期维护，我会在文档里同时保留图、源文件和一段说明，说明里写上“这张图的修改原则”和“当前已知问题”，这样后续维护的人不会对着图无从下手。这里想重点强调的是，工具只是承载思想的表面层，真正值钱的是前面几节讲的关系梳理和视觉规则，把那些想清楚了，用什么工具都能画出一张合格图。

5. 完整复现一次 diagram-design：某系统架构图从需求到成品

5.1 一个具体的模拟场景

为了把前几节的方法串起来，我虚构一个常见场景。某团队要设计一个“内容管理平台”的架构图，用于项目立项评审。评审会上既有技术负责人，也有产品负责人。已知系统的业务范围是：编辑创建内容、审核发布、用户在 Web 和移动端浏览内容、支持搜索和推荐、有评论功能、需要基本的监控告警。

面对这样的需求，如果直接打开绘图工具开始摆方块，大概率会画成一张既没有重点也没有清晰层次的“全栈图”。正确的做法，是走完接下来的五步。

5.2 第一步：先收集模块清单，不急着画

我先让团队把所有能想到的模块写下来，先不排序、不分类。得到的清单大概是：Web 端、移动端、管理后台、API 网关、用户服务、内容服务、推荐服务、搜索服务、评论服务、消息队列、定时任务、关系型数据库、缓存、对象存储、搜索引擎、监控告警、日志采集、配置中心、通知服务。一共十九个模块。

这个阶段不要怕多，宁可先多列一些，也不要漏。接下来要做的是逐个问两个问题：“这个模块的输入是什么？输出给谁？”通过这两问，能筛掉一批其实是另一个模块内部能力的候选模块。比如定时任务，如果只是为了内容状态流转，可以归到内容服务内部，不单独占一层；通知服务在初期评审中可以降级为说明文字。最终我把清单收敛为十五个左右，留在图上的每个节点都有明确的存在价值。

5.3 第二步：划分层次与容器边界

拿到收敛后的清单，开始画骨架。我先在画布上画四个横排容器：接入层、应用层、数据层、横切层。接入层放 Web 端、移动端、管理后台；应用层放 API 网关、用户服务、内容服务、推荐服务、搜索服务、评论服务；数据层放关系型数据库、缓存、对象存储、搜索引擎；横切层放监控告警和日志采集，这两个是横贯所有层的支撑能力。

画容器的时候，脑子里要有“边界意识”：一个模块只能归属到一个容器里，不能一会儿放在应用层，一会儿出现在数据层。跨层的关系用连线表达，而不是通过把模块挪过去表达。这一步做完，图的大骨架已经出来了，读者首先看到的是四层清晰的分组，再进一步看每组内部有哪些模块，层级关系一目了然。

5.4 第三步：确定连线的逻辑与方向

骨架搭好后，开始连线。我先把主链路标出来：用户从 Web 端或移动端发起请求，经过 API 网关进入应用层，由内容服务返回内容数据，中间涉及用户服务的登录鉴权和推荐服务的推荐策略。这条主链路用加粗实线。然后标次要链路：内容服务去对象存储取文，搜索服务去同步内容索引，评论服务把评论写入数据库，这些用普通实线。

异步和消息性质的依赖用虚线，比如发布内容成功后发通知、刷新推荐缓存、记录日志。连线方向统一指向数据流向的方向，避免语义混乱。这一步是画图过程里最容易让人急躁的，因为线一多就乱。我的技巧是分层画线：先画层与层之间的主干主线，再画同层内的辅助线，最后画跨层虚线。每画一条线，就问一次自己：“这条线对读者理解主流程有必要吗？”如果不必要，先取消它，放进说明文字。

5.5 第四步：颜色、字体、间距的收尾

主体关系定下来后，才进入视觉细化。我给四个容器分别上浅底色：接入层浅蓝灰、应用层更浅的灰蓝、数据层浅灰色、横切层浅橙灰。基础填充用同色系的不同深浅，保证整体协调。核心链路涉及的内容服务和 API 网关，用强调色描边或加亮填充，让读者一眼看到主路径。

字号按三层走：容器标题大一些加粗，节点名称中等字号，端口和注解用小字。之前编完模块清单后，我把所有节点间距统一到倍数网格，容器内边距统一，画布四周留白至少 32。最后把图的标题、版本号、作者信息放在画布左上角或右下角，方便后续维护归档，图本身的视觉收尾就完成了。

5.6 交付前的自检清单

画完不是结束，我每次交付前会过一遍自检清单：

• 缩放到 50% 时，主链路是否仍然一眼可见？
• 所有节点的形状语义是否一致？
• 连线的粗细、虚实是否区分了同步、异步、主链路？
• 有没有节点互相遮挡或线穿过文字？
• 颜色是否全部限制在基础色、强调色、状态色三类？
• 所有容器边界是否清晰，归属关系是否无歧义？
• 如果我是第一次看这张图的读者，我能用一句话说出它想表达什么吗？

这七条过了，图基本可以拿出去见人。没过的话，宁愿多花半小时修好再发，也不要让一张半成品流向评审会，图上的每一个模糊之处，都会在会议上变成十倍的质疑。

6. 翻车现场复盘：我踩过的 diagram 大坑与补救办法

6.1 信息堆积：想把所有内容塞进一张图

这是最常见、也最伤人的坑。曾经某开发者在画业务全景图时，把所有角色、所有模块、所有状态流转全部摊到一张画布上，最后变成了七十多个节点和十几类颜色的巨幅海报。评审时根本没法看。修复方式很简单，但执行起来需要狠心：先保存一张“全量图”留档，只把核心链路和关键分支画出来，其余细节全部拆到附录或者彻底删除。删完之后他说了句很真实的话：“原来这张图想讲什么，我现在才看清。”

这个教训告诉我，画图时你往往觉得每个模块都很重要，但其实读者根本消化不了这么多信息。一张图的信息承载量是有上限的，尊重这个上限，比尊重“完整性”重要。要完整，可以拆多张图，不要用一张图硬扛。

6.2 颜色语义打架：红绿状态和强调色混用

另一个坑来自颜色。某团队画系统状态图时，用红色表示故障模块，用绿色表示正常模块，同时又用红色给“核心模块”描边。结果评审会上有人指着核心模块问：“这个模块是不是现在故障了？”图上的信息表达出现了直接冲突。

从那以后我给自己立了条规矩：颜色承担什么语义就只承担什么语义。表示状态的颜色，绝不兼作分组或强调色；表示分组的颜色，也不要用来标记状态。如果确实需要状态和强调同时出现，比如核心模块刚好处于故障状态，就用图标或文字来说明，而不是让读者靠颜色去猜。颜色语义打架的图，比没有颜色的图更难读懂。

6.3 连线交叉灾难：节点布局没有规划

画图时最容易崩溃的瞬间就是连线交叉成乱麻。有一段时间，我图里的模块位置是“想到哪放哪”，结果画到一半发现 A 和 B 之间、C 和 D 之间互相穿线，只能把模块重新挪一遍，越挪越乱。后来调整了思路：画图前先在草稿上定好“主干线”所在的行和列，重要节点占据主通道，次要节点放在两侧，同方向的连线尽量平行排列，这样交叉会少很多。

万一某些交叉避不开，我采取“小过线桥”的办法：让一条线在交叉点稍微做成拱形跳过去，这在不少绘图工具里也有现成功能。但要记得，过线桥越多说明布局越有问题，它只是救急手段，不能当常规武器。

6.4 只有快记没有精修：草稿直接当文档发

会议桌上几个同事围着一块白板，你一笔我一笔把想法画了出来，思路确实清晰了。结果有人拍张照，直接把照片贴进文档，图上的箭头有粗有细、字写得歪歪扭扭、还有好几个涂改的圈。这种“快记”图对当时在场的人来说完全没问题，但对不在场的读者来说就是灾难：他们不知道哪个箭头是定论，哪个是废弃方案。

我的建议是把图的用途分成两类：讨论草稿和正式文档。草稿只用于实时交流，尽量不要外发；正式文档必须重画一遍，把临时涂改清理干净，箭头语义统一，文字清晰可读。这里没有捷径，重画的过程其实就是把思路从“想到什么算什么”变成“按逻辑梳理一遍”的过程，价值比看起来大得多。

6.5 一张被评审推翻的图带来的教训

最后一个案例让我印象最深。某团队画了一张系统请求时序图，图中参与对象沿横向排列，消息也是从左往右发送的，但每个参与对象下面还挂着状态变更，又得从上往下看，整张图两个方向混在一起。评审会上有人顺着横向看了一遍，又顺着纵向看了一遍，最后憋出一句：“这条链路的先后顺序到底哪个算数？”那张图最后被推翻了，重画成了参与对象横向表头、时间轴垂直向下的标准时序样式，问题瞬间清晰。

这件事让我认识到一个容易被忽略的点：图的阅读方向本身就是信息。如果一张图有两个方向在同时表达不同语义，读者必须不断切换阅读模式，很容易读错。选定了一种方向约定，就要在整个图里贯彻到底。

7. 保持手感的方法与最后几句实在话

7.1 每周重画一张旧图

diagram-design 和所有手艺一样，靠练。我给自己定的规矩是每周至少重画一张旧图：从本周画的图里挑一张，强制要求删掉至少三分之一的信息，同时还要保证核心意思不丢。这个练习看起来是“做减法”，实际上逼着你去重新思考什么是这张图的主干。每次做完这个练习，回头看原图都会惊觉“原来有这么多内容都是可以不要的”。

如果手边没有自己的图，画别人的也行。找一张你觉得凌乱的原图，重新梳理层级、调整布局、简化颜色，你会发现自己对关系的敏感度提升得很快。这种东西不用天天练，每周固定一次，几个月之后，画图的思路会明显不一样。

7.2 把优秀图反过来拆解

除了自己画，我有一个很上瘾的爱好：拆解别人画得好的图。看到一张赏心悦目的架构图或流程图，我不会只扫一眼就过，而是反过来问自己几个问题：它的主链路画在哪条通道上？为什么这个节点放在这个角落？颜色选取的逻辑是什么？信息密度控制在什么水平？每个问题都像是从作者的草稿里倒推他的设计决策。

拆解的图多了，你就会发现，好图之间往往有一些共性：克制、对齐、分层清晰、主链路一眼可见。而这些共性不是天赋，是方法。把方法沉淀下来，再变成自己的习惯，这才是拆解图的真正目的。

7.3 最后几句实在话

以我自己的体会，diagram-design 最大的价值，不是让你把图画得多好看，而是逼你把问题想清楚。关系整理不清楚的人，画的图一定乱；关系想透了的人，即使画得朴素，读者也能一眼看懂。每次在动手前，我会在心里默念三句话：少画一点，对齐一点，讲清楚一点。少画一点是筛选信息的勇气，对齐一点是视觉整齐的水准，讲清楚一点是设身处地替读者想一遍。做技术的、做产品的、做设计的，只要需要表达复杂关系，这三句话都用得上。