经常想起这几年的经历，老板经常对着技术方案的文档评论：这个地方补一张大而全让人一眼看懂信息量大的技术架构图。当我画了数个深夜，绘制了一张自以为完整的系统架构图后，老板皱着眉头看了半天，说这个图没有主题、还要改改。有时还会说，这个图没说清楚解决了什么业务问题，或者没说清楚主线逻辑是什么，又或是数据到底怎么跑通的。

这不仅仅发生在我自己或者身边，而是在很多研发团队里，经常会出现这样尴尬的局面。我曾认为对方忽视技术，不注重工程的严肃性，对计算机学科理论的严谨度不高。而身边画图的高手，能把一张图画得天花乱坠、让人直呼牛掰。在面对复杂的项目汇报、冗长的会议和文档、盘根错节的技术细节，一图胜千言，让老板啧啧称赞。

直到现在，我才彻底明白：技术人员习惯绘制的、偏“学院派”的「系统架构图」，与决策者或跨部门同事真正需要的「信息结构图」，所面对并试图解决的是两类截然不同的认知问题。在观摩与学习了不少优秀图例之后，我一直在追问：到底什么样的「架构图」，才是老板真正想要的？结合最近的阅读、和 AI 对话与思考，我逐渐形成了几个结论。

一、选图很关键

这里我给「架构图」加了引号，因为本质上这些图往往并非传统意义上的系统架构图，其中相当一部分更接近信息图。技术专家和架构师在向上汇报、技术深度评审、跨团队协作或技术治理等不同场景下，也会有针对性地选用业务全景图、数据流图、部署拓扑图、技术栈全景图、服务蓝图等图形表达方式，把关键点澄清。

写技术文档时，选对一张图、画好一张图，往往比写一大段文字更有效——这对一线研发来说，是一项非常关键的基本功。但日常工作中，我经常观察到，甚至我自己也常常会出现这几个问题：

• 混淆了几种不同性质的图，把各种图杂糅在一起，追求一个大而全（被吐槽不规范）；
• 为了像架构图而进行过度设计，比如没有职责隔离的伪分层，过度追求复杂而刻意增加框图连线（被吐槽不真实）；
• 选的图不对，在和重业务的汇报场景选用重业务细节的图（被吐槽没有主线逻辑）；
• 一张图走天下，给老板看细节满满的交互图（被吐槽没有重点）；

等等，不胜枚举。很多时候，我们的问题不是怎么绘制，而是不知道应该选择哪种图来绘制。而方向一旦选错，或者根本就没有选方向的话，那最终的结果当然也不让人满意了。对于一线研发而言，清晰区分这几类“图”的呈现形式，区分出不同的场景下需要绘制哪类图，也算是提升技术影响力与沟通效率的必备工程素养。

二、如何选图

选图的本质，是先明确这张图的目的是什么、要传达给读者什么信息。基于这一点，你可以从研发所处阶段来选定，也可以从受众角色来选择。

1、研发阶段选图

2、受众角色

3、最简原则

如果只选一张图，往往是信息图、系统全景图、系统架构图进行三选一。最简易的选择原则如下：

可以看到，老板需要的是信息图或者系统全景图，而非传统意义上的系统架构图。

下一篇，我想和你谈谈怎么画技术图。