如果你最近两年一直在做 AI 相关的应用大概率会遇到一个共同困惑明明单个模型调用很简单组合起来做产品却总觉得别扭。Prompt 加长了效果不稳定、多个 Agent 协作分叉失控、一次对话的时间从几秒涨到几十秒、账单月底一看翻了十倍——这些问题的根源往往不在模型本身而在你压根没有完成AI 应用架构的思考。不夸张地说绝大多数 AI 项目的翻车现场翻的不是模型是架构。把 LLM 当成 API 裸调和把 LLM 当成系统里一个具备不确定性的组件去设计走的是完全不同的两条路。我接触过好几个从 Demo 到上线阶段崩溃的项目死法惊人一致没有把上下文管理当成独立模块、没有给模型调用设计降级与容错、没有可视化全局的数据流。而这三点恰恰是 AI 应用架构设计的核心命题。这篇文章想做的事是抛开 PPT 式的抽象概念直接拆解一套可落地的图解 AI 应用架构方法论。所谓图解不是让你画几张漂亮的架构图交差而是用可视化思维重新审视 AI 应用的每一层从模型接入、上下文工程、Agent 编排、工具调用再到可观测性和成本控制。我会把我画图时常用的视角、踩过的坑、以及最终验证有效的模式讲清楚你可以直接照着画也可以拿它当脚手架去设计自己的系统。1. AI 应用架构的分水岭确定性系统 vs 不确定性系统很多人在设计 AI 应用时犯的第一个根本性错误是仍然用传统软件的确定性思维去套 LLM。传统架构里每个函数只要输入相同输出就必相同每个模块的错误码是可枚举的调用链路的耗时是可控的。而 LLM 加入后这套假设几乎全部崩塌。你面对的不再是一台可预测的机器而是一个概率性的文本生成引擎。1.1 为什么API 裸调模式撑不过第二周我见过太多 MVP 的起点是调一下 OpenAI 的 API 或国内大模型接口拿 JSON 回来解析一下展示。这种模式做 Demo 没问题但撑不过第二周。原因有三第一模型返回的格式不稳定你让模型输出 JSON它偶尔会夹带 Markdown 代码块标记或者在中途截断前端解析直接崩溃第二你没有上下文管理策略每一轮对话都把历史消息全部塞进去Token 消耗线性膨胀到月底账单吓人第三没有任何降级方案模型服务一抖动你的应用就跟着一块抖动。这些问题的本质是你把模型当成了整个应用的主干而不是把它当成一个可替换的推理组件。在架构图上API 裸调的数据流是用户请求 → HTTP 调用 LLM → 返回 → 展示。没有中间层、没有缓存、没有上下文管理器、没有输出校验器。这不是架构这是串联电路——一个灯泡坏了整条线全灭。1.2 把 LLM 当黑盒推理引擎来看待正确的架构心智是把 LLM 当成一个黑盒推理引擎输出的是概率上最合理的文本而不是正确的结果。基于这个心智你需要围绕它构建四个缓冲层输入缓冲把用户请求转换成结构化的、可供模型稳定理解的消息序列进行敏感词过滤、指令注入防护、用户意图预分类。输出缓冲对模型输出做结构化解析、合法性校验、安全过滤必要时触发重试或修复机制。状态缓冲管理对话状态、临时记忆、长短期记忆的读写避免每次请求都从零开始。故障缓冲超时重试、模型降级、缓存命中、静态兜底回复。这些缓冲层在架构图上的样子是 LLM 被夹在中间——所有的请求必须先经过预处理管线所有的响应必须先经过后处理管线——模型本身不直接对接业务逻辑。一个合格的 AI 应用架构图画出来以后 LLM 应该被画在中间靠右的位置而不是最左边入口处。1.3 图解的第一原则先画数据流再画模块我之前指导团队画架构图发现大家普遍有个习惯先画系统有哪些模块Agent、RAG、Prompt Manager再用箭头连起来。这个顺序其实是反的。正确的顺序是先画数据流——用户输入从哪里进入、经过哪些处理步骤、在哪一步调用模型、结果回到哪里——数据流顺了模块之间的边界自然就清楚了。这就像你要画一张城市交通图先要明确人流从哪个站进、经过哪些换乘点、最后目的地是哪而不是先画商场和写字楼。一个反例是我见过有人把架构图画成了一个所有模块互连的蜘蛛网Agent 连向量库、向量库连缓存、缓存连模型、模型又连 Agent……看着很热闹但没有任何一张图能说清楚数据到底怎么从头流到尾。后来我让他换了一种画法每一步处理都用一个圆角矩形箭头只表示数据流转方向凡是没参与这条数据流的模块一律扔到旁边标注为支撑服务。图立刻变清爽了架构问题也暴露出来了。2. 图解架构的核心模块一张图看清 AI 应用的全链路这里我给出一个经过实战检验的 AI 应用架构参考分层。它不是标准答案但适合 80 的对话式、Agent 式、RAG 式应用。你画图时可以参照这个分层来落位每画一个模块就问自己一个问题这个模块到底是干什么的如果答不上来就说明它不应该在这个架构里。2.1 交互层不止是聊天窗口交互层是用户直接接触的部分但很多架构图对这一层的设计过于单薄——一个手机图标、一个网页图标就完了。实际上交互层在 AI 应用里承担的任务比传统 UI 多得多。流式输出是这一层必须画进去的第一个关键组件。LLM 生成动辄几百个 Token如果等完整生成完再一把推给用户体验会非常差等你把几百字的完整文本推给前端用户早以为页面卡死了。所以说交互层和 LLM 之间的连接必须是流式的你可能需要一个 SSE 通道或 WebSocket 来做 Token 级推送而不是一个普通的 HTTP JSON 响应。多模态输入也是交互层需要考虑的。用户可能上传图片、文档链接甚至语音这些输入要在交互层完成类型识别和预处理再决定是走文本模型、视觉模型还是先做文件解析。如果你在设计架构图这里的箭头至少有三条文本进文本模型、图片进视觉模型、文档进解析服务。第二个容易被忽略的是中间状态反馈。用户发出一个复杂请求系统需要经过召回 → 推理 → 生成 → 验证多个步骤全程可能要 20 秒。如果界面上一片空白用户大概率会再发一条消息导致两个请求互相干扰。架构设计上必须预留一个状态上报通道让处理管线里各个节点能把进度、中间结果发出来由交互层渲染成正在读取资料正在分析文档等可见状态。这段设计很容易被忽略但它对用户体验影响极大。2.2 模型接入层叫接入但绝不只是 SDK 封装很多人把模型接入层理解成一个统一的 API 封装即 you 调 OpenAI 还是一个国内模型都走同一个 SDK通过切换基地址来换模型。这个理解太浅了。模型接入层真正的价值在于策略而不是封装。第一个策略是模型路由。不同的请求应该走不同的模型一个简单的分类任务用快速廉价的小模型即可复杂推理必须用参数量更大的模型。在架构图里模型接入层向上对接的是一个意图分类器的输出它在拿到请求复杂度评估后决定将请求路由给哪个模型。比如内部我在做项目时固定用一个 7B 级别的模型来把用户请求分成闲聊、问答、任务型、复杂分析只有复杂分析才进入大模型的完整推理链。这么做成本直接降了一半响应速度也快了一截。第二个策略是模型降级和灾备。没有一个模型服务商会承诺 100 可用所以模型接入层必须包含一个可用性状态判断如果主模型连续超时超过 N 次就自动把流量切换给备用模型或备用供应商。架构图上这里应该画一个模型健康状态表或配置中心容量和故障转移规则的配置集中管理。第三个策略是统一输入输出格式适配。不同厂商的 API参数命名不同、上下文窗口不同、系统提示词支持的格式不同但你的业务层不应当感知到这些差异。模型接入层应该负责把业务层传入的标准消息格式转换为各家 API 需要的数据结构再把各家 API 返回的无结构文本标准化成带有消耗 Token 数、延迟、状态码的固定结构。这样即使你第二天把某个模型换掉业务层代码一行都不用动。这些都做到了模型接入层在架构图上就不是一个简单的矩形而是一个包含路由引擎、状态管理、适配器集群的内聚模块它是整个 AI 应用的发动机舱。2.3 上下文管理层AI 应用最容易失控的模块上下文管理是 AI 应用架构和传统应用架构差异最大的一层。传统应用的状态管理是把用户数据存进数据库然后查询出来每次都是确定性的。但 AI 应用的上下文管理面对的是哪些内容应该进入模型的视野哪些是历史对话哪些是知识库召回片段它们之间谁更重要总量超过了模型窗口怎么办这层设计的好坏直接决定应用智商的上限。我在实践中把上下文管理拆成三个子模块短期会话记录器维护当前对话窗口内的消息队列负责截断、压缩、优先级排序。长期记忆仓库把用户的历史偏好、关键事实抽取成结构化条目存入向量库或 KV 存储下次对话时按需检索注入。上下文构建器把短期消息、长期记忆、RAG 召回内容、工具返回结果拼装成最终发送给模型的 Prompt。这里有一个关键设计决策上下文构建器必须遵守越靠近输入的地方越重要的原则——最新用户的指令、系统级约束必须固定在 Prompt 的首部或尾部中间才是可被压缩的历史内容。如果你把一段历史对话塞在中间不打散模型很可能在长上下文中迷失。另外我在生产环境中强力建议做上下文压缩。当成千上万的对话历史累积到超出窗口时不要简单粗暴地把最早的记录扔掉而是用一个摘要模型把老对话改写成一两句话的记忆摘要。这个摘要会保留关键信息和意图倾向比直接截断好得多。架构图画到这里你需要标出摘要模型这个节点它是上下文管理层的内部组件。注意上下文管理层的失败模式是上下文污染。当来自不同来源的内容历史、知识库、工具结果混杂无序地拼进一个 Prompt 时模型会分不清优先级回答质量急剧下滑。在架构设计阶段就要明确标注每类上下文的权重区间和插入位置。2.4 工具层与 Agent 编排层从生成文本到采取行动如果应用只是对话和问答到上下文管理层就可以打住了。但真正的 AI 应用高级形态必然涉及工具调用和 Agent 行为。工具层和编排层的设计决定了你的 AI 是会聊天的聊天机器人还是能帮用户解决问题的智能体。工具层的本质是把 AI 的决策转化为可执行的操作。一个工具在架构上需要有名称、用途描述、参数 Schema、执行端点、鉴权信息。在设计工具层时我建议所有工具执行都应该通过一层统一的工具网关——它来做参数校验、权限控制、执行超时、错误映射。不要允许模型直接通过函数调用来执行任意代码或访问任意资源。网关的作用像机场安检模型画了一张我要去登机口的牌但能不能过闸机得由安检系统做最终决定。Agent 编排层的核心是决策与控制。这里出现了两个路线单 Agent 工具循环和多 Agent 协作。单 Agent 模式里编排器就是一个循环——模型根据当前状态决定调用哪个工具工具返回结果再喂给模型循环往复直到任务完成或达到最大轮次。这张循环图在架构图上是最简单也最清晰的User Input → Agent 决策 → 工具调用 → 结果回填 → 再次决策。多 Agent 协作的复杂度就高多了。你需要一个调度中心来决定子任务的拆分、哪个 Agent 负责哪段、结果如何汇总。图解多 Agent 架构时最容易画成五六个 Agent 相互乱连的群聊图这种图基本没法指导开发。我更推荐的画法是以调度者为中心所有子 Agent 通过调度者间接通信不建立直接的 Agent 间通道。子 Agent 的输入输出都走统一的消息总线调度者负责任务路由和结果合并。从实现角度看也不需要用黄仁勋式的那种不知道什么格式的高级协议一个简单的 JSON 消息队列加上严格的任务状态定义就够了。2.5 RAG 管线检索增强生成也有自己的瓶颈RAG 是 AI 应用架构里讨论度最高的模块我这里不赘述它是什么重点说图解架构时容易忽略的三个节点。*第一是文档解析与结构化节点。*一堆 PDF、Word、Excel 进来不是直接切成文本块就完事了。你需要识别标题层级、表格结构、图片中的文字为每个文本块打上与之关联的文档 ID、页码、章节等元数据。这些元数据在后续检索时会非常有用。*第二是在线检索与重排序节点。*用向量相似度检索出的 Top-K 结果往往混着噪音。一个独立的重排序Rerank节点用交叉编码器重新计算检索结果与查询的相关性能显著提升最终喂给模型的片段质量。很多架构图画到向量检索就停了少了重排序这一步RAG 的效果会打折。*第三是引用溯源节点。*架构图上必须有引用来源的输出接口。用户在界面上看到回答时应当能点开一个引用的文档原文。这不仅是体验问题也是合规责任的底线。设计上文本块在进入向量库时就要保留原始文档 ID 与片段位置生成的回答里通过字符串匹配或元数据注入把引用标记串联起来。3. 图解的一手视角一张 AI 应用架构图怎样才算合格前面把模块讲全了但很多读者真正关心的问题其实是我这图要怎么画才像回事我面试过不少候选人也给别人做过代码评审见了太多不合格的架构图。这里直接列出几条我判断合格的硬性标准。3.1 自顶向下的层级感必须清晰一张合格的 AI 应用架构图首先层级感必须一目了然。通常从上到下是交互接入层 → 应用服务层业务逻辑、会话管理 → AI 能力层上下文构建、Agent 编排、RAG 管线 → 模型接入层 → 基础设施向量库、缓存、消息队列、对象存储。每一层横向铺开层与层之间用明确的箭头标注协议或数据类型而不是一层一个色块摆在那里。我在画图时有个习惯每一层用一个统一的底色层内的矩形是具体模块外部依赖如第三方 API、数据库用不同颜色并在图例里标明区别。这样即使一个完全没参与项目的人拿过图来 30 秒内就能看出请求是从哪里进来的、流程走了哪些关键节点、外部依赖有哪些。3.2 图中必须标注关键信任边界AI 应用要面对一种与传统应用不同的威胁模型注入。恶意用户可以通过精心构造的 Prompt试图让模型忽略系统指令、泄露系统提示词、或者执行越权工具调用。架构图上必须明确画出信任边界——哪些输入被视为不可信哪些模块是安全边界。正常情况下用户的输入始终是不可信的交互层和数据进入内部环境之前必须经过指令注入防护、内容过滤、参数校验。模型返回的内容同样不可信模型可能在输出里包含恶意链接或编造的事实输出解析后过一层校验器才能进入业务逻辑。这条信任边界你在图上画出来了等于在架构评审时把安全责任写在了明面上实现时就不会漏。3.3 每个箭头都要回答三个问题我最烦的是架构图上密密麻麻全是箭头但说不清每个箭头代表什么。建议画完图后自查任意挑一根箭头回答三个问题它传递的是什么数据数据格式是什么这个传输是同步还是异步如果三分钟答不上来这个箭头就是画错了的或者是多余的。比如 Agent 编排层到工具网关的箭头你要能说清楚这是调用了什么工具、参数以什么结构传递、是 encode 请求还是异步任务下发模型接入层到模型的箭头你要能说清楚这是用什么协议发的请求、载荷里包含什么、返回是流式还是非流式。这样做的好处是架构图从装饰图变成了实施蓝图的索引开发人员不需要靠猜来补齐实现细节。4. 实战拆解三个典型 AI 应用场景的架构图解讲完原则我带你拆解三个真实场景的架构设计。这三个场景覆盖了大多数 AI 应用的需求简单客服助手单模型 RAG、需要写文案和做数据分析的复杂 Agent多工具 多轮规划、以及一个高并发的企业级知识问答系统多模型路由 缓存 异步管线。我不用那种只有很抽象箭头的泛泛架构图而是采用表格 步骤拆解的方式把每个场景的关键链路、瓶颈和设计决策写清楚。4.1 场景一基于 RAG 的客服助手这是最典型的新手项目在架构上符合主流模式但做好的话也有不少细节。数据流大致是用户提问 → 改写优化 → 向量检索 关键词检索 → 重排序 → 拼装上下文 → 调 LLM → 返回答案和引用。这里最容易被新手忽略的是检索改写。直接用用户的原话去检索效果往往不好因为口语里带语气词、指代关系比如那个怎么弄来着。所以在进入检索之前用一个轻量模型做一次查询改写把口语转换成适合检索的书面表述检索准确率会提高一大截。这套架构里还有一个容易出问题的环节——知识库更新。知识库里的文档不是永远不变的产品文档更新后旧的切片如果还留在向量库里就会和新的切片产生语义冲突。所以架构图上必须画出一条知识摄入更新管线文档入库 → 解析 → 切片 → 向量化 → 入库 / 更新 / 删除。很多项目的 RAG 架构图里没有这条管线导致上线后知识库越用越脏回答质量一天不如一天。4.2 场景二多工具 多轮规划的智能 Agent第二个场景是企业里一个内容中台助手它能根据用户的一句话完成调研资料 → 写大纲 → 生成 PPT 文案 → 配图建议的完整任务。这类 Agent 的架构核心是计划 → 执行 → 观察 → 再计划的循环但和简单的工具调用不同的是它需要多轮规划而且每一步都可能产生中间文件。它的架构图解应该是这样的用户指令进入一个任务规划器规划器把大任务拆解成子任务清单生成一个依赖图然后进入执行调度器调度器按依赖顺序有并行就并行把子任务分发到不同的执行器。执行器由工具网关调用具体工具搜索引擎、文档库、内部画布 API、图像生成服务等。每个子任务执行完后结果回传到调度器更新任务状态。直到所有子任务完成最终产出一份完整的输出。这里面任务状态管理是体验的决定性因素。任务状态不能全部内存存——进程一重启就全没了至少需要一个 Redis 或数据库表来存状态机。用户刷新页面后能通过一个任务 ID 查询进度和中间结果。架构图上这一层要放在应用服务层用一个任务状态存储组件表示。我在做这类项目中踩过的最大坑是不要把工具的选择权完全交给模型。如果让模型每一步自由选工具你会发现它经常在一个工具上反复调用原因只是它以为这个工具可能成功结果浪费了大量 Token 和时间。后来通过调整 Prompt把工具选择限为一个增量选项比如在已完成步骤的上下文里添加候选工具清单效果显著改善。架构设计上这也意味着工具路由要由编排器的业务逻辑决定而不是完全由模型自由发挥。4.3 场景三高并发的企业知识问答系统第三个场景是从 4.1 升级到高并发级别每天几十万次查询需要支撑 2000 QPS。这个时候架构设计走向完全变了核心矛盾不再是答案质量而是成本、延迟、可用性的三元平衡。技术方案核心是三级缓存 异步召回 模型路由一级缓存完全相同的用户问题直接命中 Redis返回历史答案不消耗模型调用。适合 FAQ 类问题设置较短过期时间。二级缓存把问题进行语义归一化对相似问题做近似匹配如果召回内容高度一致直接复用答案这能覆盖大量同义问题但需要设置更高的相似度阈值来避免答非所问。三级模式缓存未命中时进入异步 RAG 管线请求先进入消息队列后端 Worker 批量消费调用检索 重排序 模型生成。这个模式的设计要点在于把同步的超时压力转化为异步的任务状态——前端轮询任务状态后台异步返回结果。图解这套架构时最能体现水平的是缓存旁路与一致性的标注知识库更新后哪些缓存项需要失效必须画出一条从更新管线到缓存层的失效链路。很多在这个场景栽跟头的人问题就出在这里——知识库都更新了用户还在拿到旧答案然后客服被骂技术团队花了一下午排查找到原因是缓存没刷新。模型路由的策略在高并发环境下也更精细常见简单问题用轻量模型直接回答成本约为大模型的十分之一只有复杂问题才路由到更强的大模型。在图上标注模型的 Token 成本、平均延迟和并发上限等于在架构评审时就把账算清楚了上线以后不用等账单到了再吃惊。5. 图解背后的不可见领域可观测性、成本与安全设计架构图上画得再完整总有一批不可见的部分需要设计——它们不参与数据主链路但决定了系统能跑多久、踩坑时能不能快速恢复。这些部分是 AI 应用架构的护城河。5.1 可观测性设计LLM 调用链路是新的调试难题传统可观测性是日志 指标 链路追踪。但 AI 应用增加了一个新维度Prompt 和模型的输入输出本身需要被观测。Prompt 是一段有逻辑的文本某一个系统提示词的措辞变化可能导致模型输出的偏移。你若没有保存 Prompt 现场的能力出问题时你根本没法回溯。我的做法是在模型接入层统一埋点把每次调用的完整请求含 Prompt 拼装前的上下文片段和完整响应含 Token 用量、延迟记录到日志存储。这一层数据量巨大所以要有采样策略建议对低价值请求做 10 采样对报错请求 100 全量保存对高价值用户 100 保存。在用图上画面的右下角一般会画一个可观测性收集器它从模型接入层、工具网关、上下文构建器三个点各拉一条虚线代表日志采集而不参与主流程。这个收集器最终汇总到一套可视化看板看板里至少要有三张图Token 消耗趋势图、各模型延迟分布图、错误类型分布图。没有这套东西你会经常经历这样的崩溃时刻线上用户说回答质量暴跌了你却不知道是哪一天暴跌、是哪个模型变了参数、还是哪段 Prompt 被改了。有了可观测性数据和对应的架构链路分析你可以三分钟内定位到昨天把某个系统提示词里的条件从句改短后分类召回权重变了。在架构设计阶段就规划可观测性比上线后再补要便宜十倍。5.2 成本设计Token 用量本身就是一种系统资源传统架构里CPU、内存、带宽是资源。在 AI 应用里Token 是新的资源——它不是无限的而且按量计费。架构设计里必须把 Token 当成内存来规划和监控。成本控制从架构层面有很多抓手第一是模型路由简单问题走便宜模型第二是上下文压缩减少每次请求的 Token 量第三是缓存复用第四是 max_tokens 的显式限制——很多开发者的请求里根本不设置这个参数结果模型无限制生成账单惊到麻木。我建议在架构图上明确标注一个Token 预算管理器组件它负责给每一次请求分配 Token 预算并在请求完成后把实际消耗上报给计量系统。当某个用户的 Token 消耗超过阈值自动触发限流或预警。这么做的好处是成本问题不再是事后看账单而是实时看仪表盘。安全设计这块还要再强调一次。AI 应用的攻击面分为两类传统网络安全攻击注入攻击、提权、DDoS和 AI 特有攻击提示注入、数据投毒、提示词泄露。在架构图层面至少要做三件事对所有外部输入做输入过滤器对所有模型输出做输出校验器对所有工具调用做权限校验。这三件事的放置位置分别在交互层之后、模型接入层之后和工具网关内。没有这三道闸门你的 AI 应用就像一条没有安检的机场跑道早晚出事。6. 从图到代码架构落地时最容易忽略的工程细节画完架构图接下来就是落地。但落地这两个字坑比画图多得多。这一小节我不展开代码只挑几个架构图上不太容易看出来、但实际开发时几乎是生死关的工程问题。6.1 流式输出的架构适配不只是加一个 WebSocket如果架构图上标了流式输出那么从模型接入层开始所有对模型调用的请求都要支持流式模式。这意味着你的内部接口不能设计成传入一个请求返回一个完整结果的同步方法而必须是一个回调驱动的异步接口。这个转变会影响上游的所有模块Agent 编排器在订阅流式 Token 片段时如何判断这一轮生成什么时候算结束、如何在生成结束前并发启动工具调用都是新问题。我推荐的做法是在内部定义一个统一的事件流接口模型接入层将流式 Token 包成标准事件——token 事件、工具调用事件、完成事件、错误事件——由订阅方自行处理。开发时用异步迭代器或响应式流框架来接收调试时能直观看到事件的先后顺序问题定位会快很多。6.2 幂等性和重试LLM 调用不是天然幂等的传统接口设计中按 ID 查询是幂等的用户用 POST 创建订单通常会做幂等处理。LLM 调用不具备天然的幂等性——同一个请求发两次返回结果可能在语义上一致但生成时间和消耗成本都会翻倍。在做重试时如果不加控制模型可能被同一请求打到十几次既浪费钱又污染上下文。我见过一个团队做模型调用失败重试没有熔断逻辑模型服务商限流五分钟结果他们还在持续重试最后不但限流没解除还白白烧了一大笔钱。正确做法是加上指数退避和抖动并设置最大重试次数连续失败超过阈值后启动熔断直接返回降级兜底文案。6.3 上下文窗口边界测试你需要一个压力测试用例集无论你选了哪个型号的模型它都有上下文窗口上限这是硬约束。很多人在架构上画了个上下文构建器但从来没定义过当上下文字符数超出窗口上限时应该按什么策略取舍。结果上线某一天用户历史对话特别长拼接的 Prompt 直接超过了窗口限制请求报错。错误信息里写得很清楚超长但业务方不懂还以为系统崩溃。建议在架构落地前期建一个上下文压力测试用例集包括超长历史对话、超大知识库召回、超多工具返回结果等边界输入。每个用例明确写出期望行为是截断、压缩摘要还是调整优先级丢弃部分片段。这些测试用例在架构评审时就应该制定出来开发完后逐条跑通。做这件事只需要半天时间但为你省下的线上排查时间可能是好几天。把工程细节想清楚之后架构图才真正变成可执行的东西。你会发现画图的目的从来不是画图本身。它是让团队在动手写代码之前就达成对系统结构的共识——模型在哪、数据往哪流、出问题时去哪查。这张图沉淀下来的判断力会在你换模型、加功能、扛并发时反复给到回报。
)
