"帮我画个架构图"是一个含糊的需求。研发说的架构图通常是系统分层架构图，产品说的多半是功能架构图，运维说的往往是部署拓扑图——三种图的读者、粒度和用途完全不同，混在一张里画，谁都看不明白。
所以画架构图的第一步不是打开工具，而是问清楚这张图给谁看、他要用它回答什么问题。
一、三种架构图的分工
| 类型 | 回答的问题 | 主要读者 | 节点是什么 |
|---|---|---|---|
| 系统分层架构图 | 系统由哪些技术层构成，如何依赖 | 研发、架构师 | 技术组件、服务 |
| 功能架构图 | 产品有哪些功能，怎么分组 | 产品、业务方、老板 | 功能模块 |
| 部署拓扑图 | 服务跑在哪，怎么连通 | 运维、SRE | 服务器、容器、网络节点 |
一个判断口诀：问"这里跑的是什么"就画部署图，问"这里能做什么"就画功能图，问"这里用了什么技术"就画系统图。
二、系统分层架构图怎么画
标准的分层结构从上到下四层，这是最通用的骨架：
- 应用层——直接面向用户的应用，Web 端、移动端、管理后台
- 服务层——业务逻辑，微服务、API 网关、业务中台
- 数据层——数据库、缓存、消息队列、对象存储
- 基础设施层——服务器、容器编排、网络、监控
三条画法要点：
1. 同层内的组件是平级的，不要在同一层里画出上下关系。真有依赖，说明其中一个应该下沉到下一层。
2. 依赖方向统一向下。 上层调用下层是正常的，下层反过来调用上层（回调、事件通知除外）通常是设计问题，图里画出来就能暴露。
3. 连线表示依赖，不是顺序。 这是最容易被误读的一点——架构图里 A 连到 B，意思是"A 依赖 B"或"A 调用 B"，不是"先做 A 再做 B"。需要表达顺序时该画流程图或时序图。
三、功能架构图怎么画
功能架构图的难点在分组，不在画图。从功能清单到成图的三步：
第一步：列全功能点。 从 PRD、需求池或现有产品里把所有功能列出来，先不管归属。
第二步：按用户目标分组。 关键在于按"用户想完成什么"分，而不是按"技术上怎么实现"分。用户不关心"消息推送服务"和"站内信服务"是两套系统，他只知道"我要收到通知"。
第三步：定层级。 一级模块 4–8 个，二级模块每组 3–7 个，三级到具体功能点。超过三层就该考虑拆图。
功能架构图最常见的问题是层级混乱——一级模块里既有"用户中心"这样的大模块，又有"忘记密码"这样的具体功能。检查方法：把同一层的名称念一遍，粒度明显不齐的就要调整。
四、部署拓扑图怎么画
部署图关心的是物理或逻辑的部署位置和连通性，三个必备信息：
- 环境边界——生产 / 预发 / 测试，或者可用区、VPC 的边界要画出来
- 节点类型——是物理机、虚拟机、容器还是托管服务，用不同图形或标注区分
- 链路与协议——节点之间怎么连，走什么协议和端口，跨边界的链路尤其要标清
部署图容易过度详细。判断标准：这张图是给人看的还是给机器看的？ 给人看就只画关键节点和链路，全量清单放在配套文档里。
五、四个高频错误
1. 三种图混画。 一张图里既有"用户管理模块"（功能）又有"MySQL 主从"（部署），读者不知道该按哪个维度理解。
2. 分层过多。 分了七八层，每层只有一两个组件。四层足够表达大多数系统，实在需要细分就在层内做分组。
3. 只画正常路径。 没有画降级链路、灾备节点、异常处理组件。这些恰恰是评审时最需要讨论的部分。
4. 缺少图例。 用了不同颜色和形状却没有说明，读者要靠猜。任何用了两种以上视觉编码的架构图都应该有图例。
六、从文本描述起图
大多数架构图的前置材料是一份技术方案文档或系统设计说明。从文本到图的做法：
- 先提取组件清单——把文档里提到的所有系统、服务、中间件列出来
- 标出依赖关系——文档里"调用""依赖""读取"这类动词对应连线
- 分层归类——按前面说的四层结构把组件归位
- 补全文档没写的——监控、日志、鉴权这类横向能力文档里常常省略，但架构图里应该有
这几步里，第一步和第二步可以交给 AI 从文档里提取，生成初版结构后再人工分层和补全。生成结果是画布上的可编辑图形，节点可以拖动、分组、改配色，不是一张固定的图片。
七、架构图要能跟着系统一起改
架构图的半衰期很短。上线三个月后加了个新服务、换了个存储，如果图不能低成本更新，它很快就会变成误导。
两个实际建议：
把架构图放在能被改的地方。 存成 PNG 塞进网盘的图，没人会更新。放在可编辑的画布上，改一个节点是十秒钟的事。
让相关的图放在一起。 系统架构图旁边挂着对应的ER 图和核心业务的流程图，改数据模型时能立刻看到哪些服务受影响。无限画布支持多种图同屏组合，缩小能看全局，放大能看细节。
配合实时协作和节点级批注，评审时的意见直接标在具体组件上，讨论历史留在图里，下次改的人能看到当初为什么这么定。
常见问题
系统架构图和功能架构图有什么区别？
系统架构图描述技术组件和依赖关系，读者是研发；功能架构图描述产品功能和分组，读者是产品和业务方。同一个产品的两张图长得会完全不同。
架构图的连线表示什么？
表示依赖或调用关系，不表示执行顺序。需要表达顺序时应该用流程图或时序图。
分几层合适？
系统架构图四层（应用、服务、数据、基础设施）通常够用；功能架构图一级模块 4–8 个，总层级不超过三层。
能从技术方案文档生成架构图吗？
可以把文档拖进画布让 AI 提取组件和依赖关系生成初版结构，再人工分层和补全横向能力。
架构图能和其他图放在一起吗？
可以。无限画布支持在同一空间放置架构图、ER 图、流程图等多种图形，并支持多人实时协作与节点级批注。
结语
画架构图之前先确定是哪一种架构图，这一步做对，后面基本不会跑偏。系统图讲技术依赖，功能图讲产品能力，部署图讲运行位置——三种图各画各的，比一张万能图有用得多。
画完之后记得留个能改的版本。想了解画布上的可视化能力，可以看AI 内容可视化功能页。