AI应用架构设计和普通后端架构最大的区别就是在链路上多了模型、提示词、记忆、工具调用这些环节画图的方式也必须跟着变。过去画个Spring Cloud微服务拓扑图那套思路直接搬到AI应用上往往会翻车——你画出来的图要么太抽象要么只画了个孤零零的模型框根本没法指导开发和部署。这篇文章不聊空理论我把自己做AI应用架构设计时最常用的一整套绘图方法、分层拆解思路和踩坑记录整理出来包括从需求到画图的全流程以及一套可以直接抄作业的自检清单。收到我困惑新手看你那张图也未必看得懂。适合读这篇文章的人有两类一类是刚要接AI项目、需要先把系统结构梳理清楚的技术负责人或者后端转AI的工程师另一类是已经画过几张AI应用图、但总觉得画出来不够准确想找一个更体系化方法的人。我会尽量把每一步为什么这么做讲清楚配合实际的架构图示例来说明落地性优先。1. 画图前必做的四件事架构设计的基本盘很多人一上来就打开绘图工具开始拖框框这是最大的误区。AI应用架构图之所以难画是因为你还没把需求、边界、数据流、成本这些底层的约束搞清楚。我习惯在动笔前先过四个基本盘每件事都需要花时间落地前后有依赖关系顺序最好不要颠倒。1.1 先明确边界功能需求跟非功能需求分开列做AI应用架构设计第一件事其实是定“边界”。这里的边界不是指画一个系统框然后画几条线连出去而是要把系统内外部的职责分清楚。我会先拉一张表左侧列功能需求右侧列非功能需求这个动作很朴实但非常关键。功能需求回答的是“系统要做什么”比如一个面向客服的AI问答系统需要支持多轮上下文、需要接入企业知识库、需要区分不同权限的用户提问、需要在回答中附带引用来源。这些功能会直接影响架构图中的组件划分比如知识库单独拆一个检索服务还是跟主服务放一起边界不同图就完全不同。非功能需求回答的是“系统要扛什么”QPS、响应时间、可用性、数据隔离等级、推理成本上限。这些约束往往在前期被人忽略等到画部署图时才发现扛不住。我自己吃过一次亏早期画某个AI Agent的部署图时没有把“单用户单会话的并发上限”标出来结果上线后模型服务被高频请求打满又要回头补限流、排队、配额管理架构图改了三轮。所以我的建议是先把这两类需求写成清单哪怕只有六七条也要落到纸面上。这些条目随后会变成架构图上的标注、旁注和约束说明让看图的人一眼知道你做了哪些取舍。1.2 技术选型和分层模型要一起定需求理完后就该选型了这里有个特别容易踩的坑选型跟分层模型脱节。比如你选了某个大模型API但没想清楚它在整个系统中的层级位置也没定义好底座层、能力层、应用层的边界画出来的图就会把所有组件平铺在一张图里没有任何依赖关系这种图说白了就是一张“组件贴纸”。我比较推荐参照业界常见的“五层拆分”来组织技术选型接入与交互层负责Web端、客户端、API网关的请求接入处理鉴权、限流、会话管理等基础能力。编排与调度层这是AI应用的核心大脑负责Agent的流程编排、任务拆分、工具路由、模型调用策略。像LangChain、自研的Agent Runtime、工作流引擎都落在这层。模型与推理层根据任务复杂度选择不同规格的模型可能是云厂商的大模型API也可能是在私有环境部署的开源模型。这一层还要定义模型网关、降级策略、超时重试等容错机制。记忆与上下文层管理短期会话上下文和长期记忆可能是Redis缓存短期窗口也可能是向量数据库做长期知识存取。数据与知识层包括企业知识库、业务数据库、外部第三方数据源这一层为模型提供事实依据减少“一本正经胡说八道”的概率。这五层不是死板的教条而是帮你梳理依赖关系的一个参考框架。比如你的应用很简单只有一个模型API加一个知识库那编排层可以很薄甚至并入应用层但分层思想必须存在否则画图时你总会漏掉某个环节或者把跨层调用画得乱七八糟。1.3 数据流和状态管理比组件更重要组件画得再齐全数据流画不清楚架构图就是废纸。AI应用相比传统应用的复杂度恰恰就在这里传统服务只要画清请求从网关到服务的路径就够了但AI应用还要额外画清楚提示词怎么组装、上下文怎么维护、工具调用的中间结果怎么回流给模型、流式输出怎么传给前端这些都是数据流的一部分。我建议在画总览架构图之前先单独画一张“数据流草图”用最朴素的方块和箭头把一次请求的完整生命周期走一遍。拿一个多轮对话Agent来举例一次用户请求的数据流大概是这样的用户请求进入接入层经过鉴权与会话校验拿到用户身份和会话ID。编排层根据会话ID从记忆层加载历史消息组合成当前session的上下文。编排层判断当前用户意图是否需要调用工具如果需要则从工具注册中心获取工具列表组装成带工具定义的提示词。模型层接收提示词后执行推理如果触发工具调用返回结构化参数给编排层。编排层调用工具得到工具结果后把结果作为附加消息再次提交给模型。模型生成最终回答编排层按流式协议返回给接入层接入层边接收边推送给前端。最终回答和工具调用摘要写回记忆层用于下一轮对话的上下文组装。这张数据流草图画完之后你再回去画总览架构图就会非常清楚每个组件之间该不该有线、线的方向是什么、中间要不要加队列或事件总线。状态管理也一样哪些状态放会话上下文哪些放缓存哪些放持久化存储在画图时都要标记出来。否则你只画了一个“Memory”框开发人员看到这个框还是不知道怎么实现多轮对话的一致性。1.4 推理成本与性能约束决定了架构形态AI应用架构有一个传统后端没见过的强约束模型推理的成本和延迟。这一点不是锦上添花的考虑而是直接决定你要不要加缓存层、要不要做路由分流、要不要预计算向量索引。我在画图前会先估算一笔账以常用的对话模型API为例假设每次用户请求需要发送约2000字符的输入提示词模型的输入价格和输出价格分别按各自计费实际算下来就可以评估加不加缓存。比如在某次项目里重复或相似问题占了总请求量的30%以上我在架构图中就专门加了一层会话级语义缓存用向量检索判断问题相似度命中后直接返回缓存答案不进入模型调用。这笔账在技术评审时非常有说服力能让架构图的每一层都有存在的理由。性能约束也是同理。如果你的业务要求首字延迟在1秒以内、整体响应在3秒以内那架构图里就必须把OTel采样、流式传输、排队策略画出来。不要为了省事把性能约束写成文字“高并发、低延迟”——这句话谁都会说但在架构图上体现出来的方式是画出限流组件、放行机制、过载保护通道和对应的参数指标。提示画图前先花半天时间把这四件事做完比你多画一版图节省的时间多得多。我带团队时的要求是结构图没画出来之前不允许画部署图因为部署图能反映架构的物理形态但你得先有逻辑形态。2. 图解AI应用架构的三种必备图结构、时序、部署架构图的种类很多但对AI应用来说真正高频使用的就是三类结构图也叫系统全景图、时序图也叫链路交互图、部署拓扑图。这三张图分别回答“有什么组件”、“组件怎么协作”、“组件部署在哪里”三个不同问题。很多人只画一张总览图就想交代完一切基本行不通。2.1 结构图用“分层模块”搭出系统全景结构图是最先要画、也是给人第一印象的图它覆盖整个系统的主要模块和层级关系。我常用的排版方式就是把前面说的五层从上到下垂直排布每一层放几个核心模块框跨层的依赖用带有方向的线条连接并按要求标注协议或数据类型。需要特别注意的是AI应用的结构图里通常有几个传统后端架构不常出现的模块比如“提示词模板管理”“记忆存储”“工具调用器”“向量检索”。这些模块一定要单独画成组件不要塞进一个大而全的“AI服务”框里。一旦塞进去这张图就失去了对开发的指导意义。我来描述一个典型的结构图画法完全不依赖具体工具你用白纸、白板还是Excalidraw都行。顶层接入与交互层画三个框——Web客户端、API网关、会话管理器。API网关向下连一条总线和鉴权服务。第二层编排与调度层中间的“Agent Runtime”是整张图的重心可以适当放大。它下面挂三个子模块意图识别器、任务规划器、工具路由表。这三个模块之间用轻度虚线连接表示它们是协作关系。第三层模型与推理层画模型网关向下引出两条分支一条连“云端大模型API”另一条连“私有化小模型”中间标一个“路由策略”标签。第四层记忆与上下文层画两个存储框短期记忆用Redis长期记忆用向量数据库。第五层数据与知识层画知识库、业务数据库外部数据源放在边界之外用灰色框表示和系统之间画一条安全边界线。这样一张结构图既有层级又有依赖关系阅读者可以快速理解系统的全貌然后决定深入去看哪个部分。至于每个组件的细节可以在结构图上加编号然后配合后续的时序图逐步细看。2.2 时序图把一次智能决策的完整链路画透结构图是静态的动态协作关系必须靠时序图来表现。AI Agent的每一次回答其实是一连串的“模型推理-工具调用-再推理”循环如果不画时序图你会发现开发人员对工具调用结果的回流逻辑理解完全不一致有的以为工具结果只是拼进提示词有的以为要新建一条任务重新推理最后写出来的代码千奇百怪。画时序图时我建议按照真实消息传递顺序来组织不要跳过任何一次模型调用。以前面那个多轮对话Agent为例一张标准的时序图从左到右应该出现这些参与者用户、API网关、Agent Runtime、记忆存储、模型网关、工具服务。然后画这样几条消息用户→API网关发送问题携带sessionId。API网关→Agent Runtime转发带用户身份的请求。Agent Runtime→记忆存储读取最近N轮对话历史。记忆存储→Agent Runtime返回历史上下文。Agent Runtime→模型网关提交“系统提示词历史上下文工具定义”请求首次推理。模型网关→Agent Runtime返回结构化响应其中工具调用参数标记为tool_call。Agent Runtime→工具服务按工具参数发起真实调用。工具服务→Agent Runtime返回工具执行结果。Agent Runtime→模型网关把工具结果作为追加消息再次提交请求第二次推理。模型网关→Agent Runtime返回最终回答。Agent Runtime→API网关以流式方式转发回答。API网关→用户前端逐字展示回答。画完这张时序图一定会有人问“为什么第9步不能直接把工具结果拼进上下文然后就返回”这里的解释其实可以在图中备注里写清楚工具结果必须经过模型二次理解才能转化为自然语言回答而且这一步往往还会触发对下一步工具调用的决策是Agent内部循环里最关键的一环。时序图里我还会额外画出超时和重试的虚线返回例如第6步模型网关无响应时Agent Runtime会在300毫秒后触发重试重试两次后转到逻辑降级分支。这些细节如果不在时序图里交代实现时全靠个人临场发挥架构图的价值就丢了。2.3 部署拓扑图从逻辑架构到物理环境的最后一公里结构图和时序图解决的是逻辑设计问题部署拓扑图解决的是“这套系统跑在什么环境里”的问题。AI应用最特殊的地方在于模型层的部署形态是全部依赖外部API还是在自有GPU环境部署开源模型又或者是混合模式这直接决定了拓扑图的画法。部署拓扑图不能简单复用结构图的模块必须把逻辑组件映射到具体的部署单元。比方说接入层和编排层可以各部署2个副本挂在一个负载均衡器后面。记忆层的Redis使用自建集群一主两从开启AOF持久化。向量数据库使用独立实例配置一个专用索引空间。外部大模型API在拓扑图中画在系统边界之外在边界上标明“出网调用”和“TLS加密”。私有化小模型跑在内网的两张推理卡上部署了模型服务节点用Nginx Model Gateway做流量分发。部署拓扑图里最容易被忽略的是“数据面”和“控制面”的分离。AI Agent的配置管理、模型路由策略、工具开关配置建议走管理面下发不要把管理操作直接串进在线推理链路。我在拓扑图中会用不同颜色的边框把数据面和管理面分开凡是跟模型路由参数变更、工具注册更新相关的操作都归入管理面这样运维同学看了图就知道哪些操作不影响线上推理链路压力会小很多。注意部署拓扑图必须标注环境边界比如“内网区”“安全区”“公网区”。模型API的出网调用和知识库的内网访问在拓扑图上必须是不同的区域表现这个标注直接影响后续的安全评审。3. 实操案例从零开始图解一个AI问答系统的架构前面讲了这么多理论接下来我完整走一遍实操以一个企业内部知识库AI问答系统为例从需求到画图输出整个过程。这个案例是真实项目的简化版但保留了所有核心痛点跟着做一遍你至少能掌握一套可复用的画图流程。3.1 第一步整理需求画功能边界图这个系统的名称可以叫“企业知识问答助手”目标是让员工用自然语言查询内部制度、流程文件和项目沉淀文档系统必须给出来源依据。我先把功能和非功能需求列出来功能需求1支持多轮对话用户可以在一个会话里连续追问。功能需求2只回答知识库中存在的、有明确出处的信息不基于模型想象力编造。功能需求3支持文档上传和知识切片处理增量更新知识库。功能需求4管理后台可以配置回答风格、人员权限范围、敏感词过滤。非功能需求1平均响应时间在3秒内首字输出时间在1.5秒内。非功能需求2系统可用性99.9%模型调用失败时有降级话术。非功能需求3同一时段最大并发会话数为500单会话连续轮次上限为20轮。基于这些需求我画的第一张图是一张功能边界图不需要精细排版只要用几个大框把“用户能做什么”“管理员能做什么”“系统边界外有什么”划清楚。注意你们看图时能很快发现文档解析服务和模型服务都画在边界外因为它们分别是独立的支撑系统这能防止后续架构设计时把不必要的人力和资源投入误划入核心系统里。3.2 第二步画总体分层结构图并定义核心组件功能边界图确认后第二步就是把核心系统展开成五层结构图。我先描述一下关键组件的设计思路然后你可以比照着画。接入与交互层API网关承担鉴权和限流会话管理器负责创建会话、关联用户身份、控制轮次上限。前端不再直接对接Agent Runtime而是统一走网关这样后续如果要开放接口给别的业务方路由和鉴权都会比较稳妥。编排与调度层这是系统的“大脑”。Agent Runtime内部把流程拆成五个子任务意图分类是闲聊还是知识问答、文档检索触发、上下文组装、答案合成、拒绝回答判断。这里我还画了一个独立的敏感词过滤组件挂在编排层的内侧在最终答案返回前执行一次过滤。模型与推理层模型网关做统一出口路由策略是简单问题走快速模型复杂推理或长文档总结走强模型。路由的依据是意图分类结果和输入长度阈值这个策略要在图上标注出来不标注的话别人会以为网关只是一个简单转发。记忆与上下文层用Redis存最近10轮对话用向量数据库存文档切片的Embedding向量和元数据。短期记忆和长期知识的分离是我在本项目里比较坚持的一点因为如果混在一起一会占用模型上下文窗口二会让相似检索的语义空间互相干扰。数据与知识层原始文档放到对象存储元数据落到MySQL文档切片经Embedding服务处理后存入向量库。结构图完成后我在每个层之间标注了关键协议接入层到编排层走标准HTTPS/JSON编排层到AI网关走内部RPCAI网关到外部模型API走HTTPS流式接口。这些标注虽然看起来只是几个字但能避免不同团队对接时产生协议层面的扯皮。3.3 第三步补充关键时序图和状态视图结构图画完动笔画出两条关键的动态视图。一条是刚才前面提过的“检索增强生成”时序链路另一条是“多轮对话的状态机视图”。时序链路的参与者稍有变化因为加了检索服务用户→网关→Agent Runtime→记忆存储→模型网关→检索服务→模型网关→用户。Agent Runtime先让模型判断“是否需要检索”这一步非常关键它避免了每个问题都强制去向量库搜一遍既省成本又提升响应速度。需要检索时检索服务从向量库找出最相关的Top-K片段把这些片段连同用户问题、历史对话一起拼进最终提示词再提交模型生成答案。状态机视图则是把一次会话的生命周期画出来包括会话创建、等待输入、检索中、推理中、流式输出、工具修正、结束。这个状态机图对于前端交互设计和后端超时处理都非常重要。前端需要根据状态显示不同交互后端需要根据状态决定超时时间和清理策略没有这张图前后端很容易对状态的认知不一致。3.4 第四步输出部署拓扑图和成本标注最后一步是部署拓扑图在这个项目里我决定采用混合部署模式。核心应用服务部署在自有服务器环境知识库和Redis都在内网而强模型推理部分调用公网API弱模型推理部分用内网小模型兜底。在拓扑图中我按物理区域划分为三块外网接入区、核心服务区、数据存储区。外网接入区有一个负载均衡器和网关节点核心服务区是Agent Runtime集群、模型网关集群、文档解析任务队列数据存储区是Redis、MySQL、对象存储和向量数据库集群。外部模型API区域放在整体框外用虚线边框在连接线上标注“TLS加密”“按需出网”“故障降级策略”。在图的右侧我额外加了一个“成本估算表”区块列出三类主要成本模型调用成本、向量存储成本、模型网关转发成本。模型调用成本按每日预估请求数乘以单次平均Token数计算这个数字会在图上标注比例方便运维团队设置预算警报。成本不管只在预算表里存在它必须体现到架构选择上比如在拓扑图上标注“检索命中缓存时强模型调用减少60%”这样的架构图在评审时才有说服力。4. 图解过程中的常见问题与排查技巧实录画AI应用架构图画得多了我发现有几个问题几乎每个团队都会遇到而且这些问题不是绘图技巧能解决的背后是对系统理解不到位。我整理了五个最常见的高频问题顺带附带我的排查经验和解决思路。4.1 问题一组件画得太多主链路被淹没画图的人最典型的毛病就是恨不得把所有组件都画在一张图里导致看图的人根本不知道一条请求的完整链路到底长什么样。我以前也犯过这个错画一张图能画出来三四十个框评审会上大家盯着图发呆没人敢先说哪条链路是主链路。排查思路是用“二八原则”做减法把结构图的范围控制在“一次核心请求必须经过的组件”以内其余的支撑组件监控、告警、配置中心、日志采集全部放到辅助视图中可以在主图上用灰色小字标注“相关支撑组件见运维专题图”不要跟主链路抢视野。如果确实需要展示次要链路用虚线或淡色区域隔开别让它们在视觉上和主链路同等权重。实操心得我开始要求团队每个框图里最多只保留一个视觉焦点通常是把编排调度层或者模型网关做放大或加粗处理其余组件从大小和用色上主动弱化这样看图的人视线会被主轴带走而不是在无关组件上徘徊。4.2 问题二把模型层画得像一个黑盒很多人画模型层就是画一个框写上“GPT”然后所有线都指向它。这种图完全没体现出AI应用架构设计的核心因为模型层内部是有策略、有路由、有降级的。黑盒模型层会让后续的容量评估和安全评审完全无从下手。排查要求就是模型层至少要画出模型网关、模型列表、路由策略、降级分支这四个要素。图里要能看到强模型和弱模型的分工要能看到模型不可用时的兜底路径要能看到超时和重试参数的旁注。如果这些画不出来说明模型层的设计本身还没想清楚建议回到技术选型阶段先把模型策略斟酌透。4.3 问题三数据流箭头方向画反或漏画别笑这个真不是低级错误。AI应用的编排层经常要“先给模型发消息拿到工具调用参数后再调工具再把工具结果回给模型”这个循环里箭头方向如果画错一次后面看图的开发人员对数据归属的理解就全乱了。排查方法是用一套统一的图例规范实线表示同步在线调用虚线表示异步或回调双向箭头只在明确需要时使用数据写回一律用指向存储方向的箭头并标注写入动作。对于Agent循环这种特殊链路我会额外画一条“循环体注释”说明“此处最多循环N次超过N次强制返回当前结果”这条注释能够防止实现时出现死循环。4.4 问题四上下文与记忆没有可视化这是架构图最常见的一个疏漏。没有可视化记忆与上下文的读写关系会导致开发人员做技术方案时在上下文的持久化策略上各做各的。有的人把历史对话全存MySQL有的人全放Redis还有的人干脆依赖模型API侧的会话参数完全脱离你的架构设计。我建议在架构图中专门划出“记忆读写”这一段区域用三个小标识表示“读上一次会话摘要”“读最近N轮完整消息”“写回本次交互摘要”。这三个标识能直观压出记忆层面的设计深度同时也时刻提醒自己和团队上下文管理是需要明确方案的不是自动发生的。4.5 问题五部署图与逻辑图概念不对应部署图跟结构图不一致是评审时最尴尬也最难解释的问题。比如结构图里画了“检索服务”部署图里找不到结构图里模型层只有一条调用链部署图里却有两条模型API出网。这种情况只要出现整张架构图的逻辑可信度就被拉低一大截。解决思路是在画部署图之前做一次严格的“架构图对账”把结构图里每个业务组件一个一个对应到部署单元能对应上的打勾对不上号的必须回查。对账表可以直接放在本小节这种文档的位置不一定要放在图内但在工作沟通中要发给相关团队看确保开发同学认可逻辑到部署的映射关系。排查完这五个问题我一般还会把容易犯错的点整理成一张自检表放在文档的下一页作为每次评审开始前的强制检查项。自检表里有一项我会特别加粗“架构图中是否标注了模型降级路径”这一项答不上来评审就打回重画。5. 画图工具与协作规范让架构图真正成为团队语言画图这件事工具从来不是核心但工具选不对确实会拖慢效率。我试过好几种绘图工具也带团队制定过内部画图规范最后真正能沉淀下来的其实是一套跟工具解耦的方法论。这里简单分享几个主流选择和使用技巧。5.1 从白板到在线协作工具应该匹配团队协作节奏对于AI应用架构设计我不推荐一上来就开沉重的建模工具。项目初期需求还不稳定架构草图大概率要推翻重来这时候最好的工具就是白板或在线白板工具。你只需要快速画分层框、数据流箭头、边界线表达清楚核心思想不需要把每个组件画到位。等项目进入到技术设计阶段我才会要求把草图迁移到规范的绘图工具里。这个阶段我倾向于使用支持多人实时协作的工具因为AI应用架构涉及的角色比传统项目多后端工程师关注编排层和工具调用算法工程师关注模型网关和提示词策略运维关注部署拓扑。大家必须能在同一张图上协同批注而不是各自画各自的版本再来回PPT传。我个人的流程是草图阶段用在线白板定稿阶段用在线绘图工具发布阶段把定稿图导出成矢量图嵌入到设计文档中再用绘图工具的“版本快照”功能存档。这个过程看起来简单但能让每个人明确自己在哪个阶段画什么减少无效返工。5.2 建立统一的图例和命名规范架构图最常见的沟通障碍是图例不统一。有人用蓝色框表示服务有人用蓝色框表示数据存储有人用虚线表示异步有人用虚线表示可选组件。同一张图里两种意思混在一起看图的人直接精神分裂。我建议在团队里推行一套简单的图例规范主要约束这几类元素实线框在线服务或进程圆角框数据存储六边形或特殊形状外部依赖。实线箭头同步调用虚线箭头异步/事件驱动。红色虚线异常路径或降级路径绿色实线正常路径。组件命名统一为“名词职责后缀”比如“SessionManager”写成“会话管理器”不写“session_mgr_v2”这种风格混搭。命名规范看起来是小事但对AI应用这种跨工种协作场景统一命名的价值会被放大。因为算法工程师写提示词调用的组件名、后端工程师写的服务名、运维工程师看的进程名应该保持同一个名字的不同后缀层级不要各自发明一个名字否则联调时光是做术语对应就浪费半天。5.3 推动“图随代码走”的持续更新机制架构图最大的宿敌是“画完就过期”。尤其AI应用迭代速度很快模型路由策略一变、工具列表一调整、记忆策略一改架构图如果不同步更新两周后就成为误导人的废图。我的做法是要求每张架构图都带上“最近更新日期”和“变更说明”并把更新动作绑定到具体技术变更流程上。比如你改了模型网关的路由策略就必须在提交信息里附上“更新架构图第3层模型路由标注”。持续更新通常说来容易做起来需要很强的纪律性但一旦养成习惯架构图就会成为一种活文档成为团队协作里的高信任信息源。提示如果想减少更新负担第二层架构图保持精简化把易变细节下沉到专题图里。比如模型路由策略单独画一张局部图主结构图只写“模型网关按策略路由”这样主图不轻易改动局部图变了也不影响整体阅读。6. 写在最后的几件小事我见过太多团队在AI项目上热火朝天地开工写代码写了两个月最后发现系统架构不像当初想的那样关键原因是架构图本身没有跟上认知变化。画图这活儿看着简单其实它是把抽象判断固化成可视化共识的过程比写代码更需要耐心和反复推敲。我个人实际操作中最大的体会是AI应用架构图不要追求“一次画对”而是要追求“快速迭代、多人共识、持续更新”。第一版图画得粗糙没关系关键是它能启动讨论等讨论深入了图会自然变精确等系统上线了图又要跟着真实运行状态调整。这个过程走完你会发现自己对系统的理解远远超过那些只看文档不画图的人。最后再分享一个小技巧画完一张架构图之后试着找一个完全不了解这个项目的人让他看着图讲一遍他理解的数据流和组件关系。如果他讲不清楚哪里是主链路、哪个是模型降级路径、哪个是记忆存取那就说明你的图还有表达盲区。这个办法我用了很多次每次都逼着我重新审视图里的细节比任何架构评审都管用。