北京
周三下午，我对着屏幕删掉了画了三小时的架构图。不是因为设计有问题，是因为我突然意识到——这张图除了好看，没人能看懂。
这是我做系统设计的常态。每次开干前，第一个念头不是"这个系统该怎么跑"，而是"画什么图才能显得专业"。高层架构图？复杂时序图？要不要加点渐变色让线条更"高级"？我盯着空白画布拖拖拽拽，删了画、画了删，像在完成一件艺术品，而不是解决技术问题。
这种压力是真实的。我想让图看起来像那些 polished 的工程博客、高端会议的幻灯片。但结果往往是 paralysis by analysis——图越画越复杂，沟通效率反而越低。
后来我才想通：系统设计图的首要目标不是"好看"，是让思考可见。
工具不是装饰品
工程领域的图不是框和箭头的堆砌，是沟通装置。它要回答硬问题：谁在用这个系统？数据存在哪？流量暴涨时会发生什么？瓶颈在哪？
你可以用长段落解释 API 流向，但一张好图能让团队瞬间 grasp 核心逻辑。价值不在图标数量或线条复杂度，在清晰度。如果团队需要 20 分钟讲解才能看懂你的图，这张图就失败了。
先问"为什么"再问"画什么"
多数人开口就问"我该画什么图"，更好的问题是"我现在为什么要可视化这个"。
这个细微转向会改变整个工作流。需要定义职责边界？从系统上下文图（System Context Diagram）开始。要展示主要构建模块？用高层架构图。时序和事件顺序是关键？选时序图。形式必须追随功能。选图不是因为"看起来专业"，是因为它是回答特定问题的最高效方式。
让 trade-off 看得见
系统设计的本质是权衡的艺术。加缓存可能干掉延迟，但引入数据陈旧噩梦。分片数据库帮你扩展，却让查询复杂度飙升。
一张好图让这些后果显性化。当你在应用服务和数据库之间画一个缓存，你不是在加框，是在告诉团队：我们用简单性换了性能。这让讨论变得 concrete。所有人看着同一张图，对话就从模糊概念转向 real-world problem-solving。
别往一张图里塞所有东西
我以前最大的错误是试图把所有东西塞进一张"主图"。用户、服务、数据库、缓存、消息队列、监控、部署流程……最后得到一张密密麻麻的怪物，没人敢打开第二次。
现在我拆。上下文一张，架构一张，关键流程一张。每张图只回答一个问题。团队翻页的速度，远快于在一张图里找线索的速度。
这个转变的代价是：我的图不再"惊艳"了。没有复杂的配色，没有炫目的布局，有时候就是白底黑框。但评审会议变短了， junior 工程师敢提问了，上线后的返工少了。
系统设计图是思考的载体，不是能力的证明。当你放下"这张图够不够酷"的焦虑，才能真正开始解决"这个系统该怎么跑"的问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
