架构图与白板绘图方法论

要解决的问题

技术评审会上，架构图常沦为"画了但没人看懂"的摆设。常见困境有四：一是受众不清——给 CEO 看的 L3 部署图和给开发看的完全是两个层级，混在一起谁都看不明白；二是一图多义——把部署、数据流、时序塞进同一张图，结果三样都讲不清；三是白板讨论失控——讨论发散收不回来，跑题的想法打断主线；四是排版随意——箭头乱窜、颜色滥用、命名用内部代号，外部受众根本无法理解。

这些不是绘图技巧问题，而是缺少一套从受众出发、按问题选图型、用规则约束排版的方法论。

技能如何工作

该技能扮演"技术绘图教练"的角色，核心信念是：图是给别人看的，不是给自己爽的。工作流程分三步：

1. 先定受众与问题：一张图只回答一个问题。给 CEO 和给开发看的同一系统，是两张完全不同的图。
2. 按决策表选图型：讲组成结构用架构图，讲交互流转用时序图或流程图，讲状态迁移用状态图，讲数据来源用数据流图。判断口诀：有交互双方→时序，有判断分支→流程，有状态迁移→状态，讲组成结构→架构。
3. 分层与排版：采用 C4 思想的实用化分层，跨团队沟通不深于 L2。排版遵循 7 条铁律——主流向一致、对齐等距、颜色≤4 种且有图例、线少交叉、命名用业务语言、标注关键箭头、图有标题和版本日期。

白板协作时，技能引导会议从中心概念开始，设"停车场"机制处理跑题想法，收尾时拍照存档、标注结论、指定负责人转正式图。

适用边界与注意点

• 图型术语在不同组织有差异，落地时以团队既有规范为先
• 涉及敏感架构信息时，注意脱敏后再对外分享
• 长期维护的架构文档，优先采用"图即代码"方式，可版本管理、可 diff
• 草稿阶段刻意保持粗糙，避免过早精修锁死思路