1. 为什么说架构设计是AI应用的第一步
这些年我接触的AI应用项目多了之后，一个感受越来越强烈：大多数从零起步的AI应用团队，第一步都不是选模型、也不是调Prompt，而是应该把架构图画出来。标题里“图解”这两个字，恰恰是整个工程问题的核心——AI应用和传统软件开发最大的区别在于，它多了一大堆不确定性系统组件，从用户请求到模型返回结果，这条链路上任何一个环节设计不好，后面都会被反复返工。
先说一个真实的场景。前段时间有个朋友带着自己的创意来找我，他想做一个基于大模型的知识库问答产品。他开开心心告诉我他已经把核心Prompt调得很好了，效果很满意，准备直接上线。我问他：“你的知识库数据存在哪里？分片怎么做？用户问的问题如果超出知识范围，模型会说不知道吗？有没有内容过滤机制？并发上来之后模型调用怎么控制成本？”他愣住了。这就是典型的“只做了模型层，没做应用层”的问题。
架构设计不是画一张好看的图交差，它是在回答一组关键问题：数据从哪来、怎么存、怎么检索；模型怎么选、怎么调用、怎么降本；业务逻辑放在哪一层、怎么跟模型交互；用户请求和模型返回之间还要经过哪些处理；出错了怎么办、怎么监控和恢复。这些问题不提前想清楚，做的就不是AI应用，而是一个包着接口的模型Demo。
所以这篇内容适合谁？正要开始做AI应用的产品经理、后端开发、运维工程师，以及那些想把AI能力引入现有系统的技术负责人。不管你是准备用开源模型自建，还是走API调用的轻量路线，架构设计的方法论是通用的。接下来我按自己画过几十张架构图的经验，把整套拆解思路原原本本讲一遍。
2. AI应用架构的整体拆分：六大核心板块
2.1 接入层：用户和系统之间的第一道门
接入层的设计往往被低估，但实际项目中它决定了整个应用的上限。这个层面对的是最终用户，关联的是小程序、Web端、App、企业微信、钉钉这类具体入口。架构里面需要明确接入方式，是HTTP接口、WebSocket长连接，还是消息队列异步处理。
我见过不少新手在AI应用里直接让用户请求打到模型API上，这是非常危险的做法。接入层至少要承担三件事：身份认证、流量控制、会话管理。身份认证要保证调用者合法；流量控制要防止突发请求把成本打爆；会话管理要维护多轮对话的上下文状态。
画架构图时，接入层我习惯用一个独立的区域框出来，和业务逻辑分开。因为接入层的选型直接跟部署环境挂钩，比如你打算部署在云服务器上，那这层会涉及负载均衡、防火墙策略；如果只是做企业内部工具，可能就简单一个服务入口。这一层设计清楚，后面加再多的功能模块，都不用回头动地基。
2.2 应用编排层：业务逻辑的真正载体
很多初次接触AI应用的人有一个认知误区：认为大模型承担了业务逻辑。其实恰恰相反，大模型只是完成“生成”这样一个动作，业务逻辑必须放在应用编排层，由代码或流程引擎来控制。
用生活化的例子解释：你把大模型当成一个非常聪明的实习生，他能写出不错的文字、能回答不少问题，但你不会把公司所有重要决策都直接交给他。真正把关的流程、数据校验、决策分支，都控制在你自己手里。
应用编排层具体做的事包括：接收接入层传来的用户输入，解析用户意图，判断要不要调用模型、调用哪个模型、用什么样的Prompt模板，模型返回结果后做格式校验、敏感信息过滤，再决定是直接返回给用户还是触发下一步工具调用。这些流程在架构图中要清清楚楚地画出来，不能含糊成“业务逻辑”四个大字就算完事。
2.3 模型服务层：所有智能能力的来源
模型服务层是AI应用架构里最核心、也最容易被过度关注的一块。这层要回答的问题非常具体：用闭源商用API还是开源自建模型？用通用大模型还是领域微调模型？不同场景是否要接入多个模型做路由？
我的建议是架构图上至少空出三个模型槽位：主模型槽位、备用模型槽位、专用小模型槽位。主模型承担日常绝大多数对话任务；备用模型在主模型限流或故障时自动切换；专用小模型负责一些简单但高频的分类、抽取任务——比如判断用户问题属于哪个业务域，这种任务没必要都交给大模型处理。
模型服务层还需要关注推理参数配置。温度、Top-P、最大输出长度这些参数的设置，直接影响生成结果的稳定性和成本。架构图上每个模型组件旁边，我都习惯标注清楚它的关键参数默认值，这样排查问题和优化时一目了然。
2.4 知识增强层：让模型真正了解你的业务
对大多数垂直领域AI应用来说，光靠模型自身的通用知识远远不够。这就是知识增强层存在的意义。目前主流做法是RAG（检索增强生成），核心思路是：先把用户的私有知识文档做切分、向量化存入向量数据库，用户提问时先在知识库里检索出相关内容，再把这些内容作为上下文拼进Prompt，最后交给模型生成回答。
画知识增强层的时候，至少要包含四个子模块：文档解析模块、向量化模块、检索模块、重排序模块。文档解析负责把PDF、Word、Markdown等不同格式的内容转成可处理的文本；向量化模块把文本切成合适的块并生成向量；检索模块根据用户问题的向量相似度找出候选文档；重排序模块在候选文档里精挑细选最相关的一批内容，避免一次性把大量低质量内容塞进上下文。
知识增强层是AI应用架构里相对独立的一块，所以架构图中用虚线框分别标注离线流程和在线流程很重要。离线流程指文档进库的过程，在线流程是用户提问时检索的过程。两个流程不要混画在一起，否则后面排查检索质量问题时非常麻烦。
2.5 数据基础层：底层的数据底座
数据基础层是最容易被画图时一笔带过、但项目落地时最折磨人的部分。它包含业务数据库、向量数据库、文件存储、缓存、消息队列等基础设施。
业务数据库存用户账号、订单、交互记录这类结构化数据；向量数据库存文档切块后的向量数据；文件存储承载原始文件和小型附件；缓存用来加速高频读取的数据，比如热门的Prompt模板和频繁检索的知识摘要；消息队列在异步场景中解耦调用关系，比如文档解析是耗时操作，可以先丢进队列，后台慢慢处理。
架构设计里数据基础层有一点特别重要：数据流向不能画成蛛网状。我曾经在评审一个项目时，看到架构图上从数据库到模型、到应用、到接入层拉了十几根线，复杂得根本没法审查。好的数据流向应该是清晰的一条链路：接入层接入请求，应用编排层处理请求，需要知识时访问检索模块，检索模块查向量库，模型从应用层拿到拼好的上下文后生成回答，结果回传。这样一个流程走下来，数据流向是单向的、干净的。
2.6 可观测与治理层：没有监控的架构是空中楼阁
在架构图里加上可观测层，是从Demo走向生产的关键标志。AI应用比传统应用复杂的地方在于，它不仅会报“系统错误”这类技术故障，还会出现“模型输出结果不准确”“回答内容包含风险信息”“同一问题不同时间回答不一致”这类业务层面的问题。
可观测与治理层至少包括三个部分：调用链路追踪，记录每一个请求从进入到返回经过了哪些模块、耗时多少、消耗了多少Token；质量评测，定期用评测集跑一批典型问题，检查回答准确率和相关性指标有没有明显波动；安全治理，对输入进行提示词注入检测、对输出进行敏感信息过滤和内容合规校验。
这层在架构图中我建议画在整个系统的上层，用横向带状的区块覆盖所有下游模块。因为它本质上是横切关注点，不是某一个链路上的独立节点。
3. 实操环节：把一张架构图画规范的完整步骤
3.1 画图之前的四件事
很多开发者的习惯是打开画图工具就开始拖组件，画到一半发现缺了模块又往里面塞，最后图的布局一团乱。我建议动手之前先花半小时做四件事：
第一，理清使用方和场景。这个应用是给内部员工用的效率工具，还是给外部客户用的产品？是单租户还是多租户？这决定了接入层权限设计的复杂度。第二，明确数据从哪里来、初始数据量大概多少。如果是企业知识库场景，文档少则几百篇、多则几十万篇，向量化和检索方案完全不一样。第三，把要用的模型API列出来。是纯走第三方API，还是混合使用开源模型部署，这是架构里模型层的核心变量。第四，想好交付形态。部署在自己服务器还是上云？容器化还是传统虚拟机？这影响架构图中是否要画容器编排和弹性伸缩模块。
第四件事最容易被忽略，但对运维兄弟来说却最重要。如果项目上线后突然涌进大量用户，架构图上没有体现扩展策略，整个系统的可用性就要打问号了。
3.2 三个层次：系统级、应用级、模块级
“图解架构”不是画一张图就万事大吉。我自己的经验是至少要分出三个层次的图。
系统级架构图面向汇报和技术选型评审，重点展示系统跟周边系统之间的关系、网络边界、主要技术栈。比如整个系统分几大块、用了哪些数据库、模型部署在哪个环境、有哪些外部依赖。这种图看的人大多不是天天写代码的人，所以组件不要画太细，标注清楚核心交互即可。
应用级架构图面向开发团队，重点是整个应用的内部模块划分和调用关系。这张图需要把应用编排层里的流程画清楚，用户请求进来经历哪些环节、每个环节调用什么模块、失败以后走什么支路。团队成员拿到这张图以后，应该能直接找到自己需要开发的模块边界。
模块级架构图聚焦某一个复杂模块。比如检索模块，要画清楚索引构建流程、查询改写逻辑、向量检索和倒排索引怎么结合、重排序策略怎么配置。这类图对本人维护者最有用，因为细节最多，也最容易被遗忘。我自己通常等模块开发完以后，再对照代码把图更新一遍，避免图上画的东西跟实际跑的逻辑有偏差。
三种层级图更新的频率也不一样。系统级半年更新一次就行，应用级每次大版本迭代后更新，模块级只要逻辑变了就随时改。这个习惯帮我避免了很多“图上写着A，代码跑的是B”的尴尬。
3.3 画法规范和视觉语言
用Excalidraw、draw.io、ProcessOn或者PlantUML都可以，画图工具的偏好不强求，但视觉语言必须统一。我自己固定使用一套约定，这里分享出来供参考。
组件形状的约定：外部系统用圆角矩形加虚线边框，内部服务用直角矩形，数据存储用圆柱形，消息队列用带小圆弧的长方块，模型的图标用多边形嵌套表示。颜色也有讲究：模型层统一用一种颜色，数据存储用另一种颜色，接入和编排用暖色系，知识增强层用冷色系。颜色不要超过五种，不然打印成黑白稿或者投影到会议室屏幕上，看起来完全是一团乱麻。
连线规范方面：实线代表同步调用，虚线代表异步消息，粗线代表数据流，细线代表控制流。每一条线上都要用小字标注协议或大致的数据格式，比如“HTTPS/JSON”“Kafka Topic”。不要画箭头不标注含义的线，那种图过一个月你自己都看不懂。
还有一个细节是图幅控制。一张应用级架构图，组件数量控制在15到25个之间比较合适。超过25个，信息密度太大，很难一眼抓住核心链路；少于15个则说明拆分粒度太粗，看不出系统真实结构。画完之后，把图缩放到50%再检查一遍，如果能大致看出主流程和高亮模块，说明信息层次是合格的。
4. 四种典型架构模式与选型建议
4.1 轻量直连模式
这是最小可用的AI应用架构：前端直接通过后端接口调用模型API，没有知识库、没有复杂的编排流程，甚至业务逻辑都极简化。典型场景是个人助手类小工具、原型验证项目、短期的企业内部提效脚本。
这种模式的架构图最简单：接入层和编排层可以合并，模型层直接挂在下面，数据层只需要交互日志存储。优点是开发速度快、成本低，适合快速验证一个想法是否值得继续投入。缺点也非常明显：模型知识停留在通用层面，回答不了垂直领域问题；没有知识增强手段，准确率上限很低；逻辑都藏在代码里，流程复杂以后很难维护。
如果只是想测试产品有没有人用、没人愿意付费，其实根本不用一上来就上RAG和Agent架构，先把轻量直连版本丢出去试错，是最经济的选择。架构服务于阶段目标，这句话在这里体现得最充分。
4.2 标准RAG模式
当前落地最广泛的AI应用架构就是RAG模式，它解决的核心问题是让模型回答覆盖企业私有知识。架构上在轻量直连的基础上多了知识增强层：文档解析入库、向量化、检索、重排序，再拼接到Prompt里。
这种模式适合客服问答、内部知识库检索、法律和金融辅助、产品使用帮助等场景。架构图上最大的变化就是出现了两条链路：离线索引链路和在线问答链路。
离线链路对实时性要求不高，但要注意文档更新频率。如果知识库每周更新一次，那可以设计成每天凌晨跑批任务；如果知识库需要小时级更新，就得引入增量索引机制。在线链路是整个系统的核心，用户请求进来后先并行做检索和对话历史组装，检索结果回来后再拼Prompt并调用模型，整个过程要在2到5秒内完成才算合格。
选型时要注意一点：不是所有场景都需要向量数据库。如果知识库内容量在几万篇以下、检索逻辑以关键词为主，传统数据库加全文索引也完全够用。盲目上向量库只会增加运维成本和架构复杂度。
4.3 Agent智能体模式
Agent模式是最近一年最火的方向，也是在架构设计上最容易走偏的模式。Agent的核心能力不是“回答问题”，而是“完成多步任务”。它把大模型当成一个拥有计划能力的调度大脑，让模型自己决定调用哪些工具、按什么顺序调用、如何根据中间结果调整下一步行动。
架构上Agent模式比RAG多了一个关键组件：工具调用管理。系统里预先注册一批工具，比如查天气、查库存、发邮件、访问数据库，模型在推理过程中生成需要调用工具的指令，应用层解析这些指令并实际执行，再把执行结果送回给模型继续推理。
画Agent架构图时要注意，模型不是直接连接所有工具的。模型只输出结构化指令，实际工具调用必须由应用编排层的执行器完成。这个设计既是为了安全，又是为了可审计。没有经过执行器的工具调用，相当于让模型直接操作生产系统，风险太高了。
Agent模式的架构图复杂度明显上升，通常包含计划模块、工具注册中心、执行模块、记忆模块和反馈循环。组件之间的连接不再是一条直线，而可能有环状结构。画这种图更要克制，不然很容易画成蜘蛛网。
4.4 多层协同模式
当业务足够复杂，比如既要做客服知识问答，又要处理工单流转，还要自动生成报表，甚至需要多模型配合工作，单一模式就不够用了。这时需要多层协同架构：接入层统一入口，编排层按业务流程路由到不同的能力模块，每个模块内部再各自选用合适的模型和策略。
多层协同模式的核心在设计原则：业务编排与模型调用解耦。不要把复杂的业务判断全部丢进Prompt里，让模型顺带完成路由、工具选择、格式解析、内容校验等工作。正确做法是能用规则判断的用规则，只有规则处理不了的部分才交给模型。比如“用户属于哪个会员等级”这种问题，直接查数据库就行，不要让模型从对话里猜。
架构图上的体现就是应用编排层内部会多一个“能力路由”节点，旁边挂一张路由规则表。这张规则表是系统的决策核心，它的可维护性决定了后续系统演进的灵活性。多层协同模式不适合初创小团队，因为维护成本高，更适合组织架构已经成熟、业务链路天然复杂的场景。
5. 选型要点与设计决策的深层逻辑
5.1 模型选型：API调用还是私有化部署
架构图上模型层的选型，直接影响成本、隐私和运维方式。商用API的优势是开箱即用、推理质量高、不用管底层硬件，劣势是数据要出网、单次调用成本随并发上升明显、受制于供应方的限流策略。私有化部署的优势是数据完全在内部、单次推理边际成本可控、可以针对业务做定制优化，劣势是前期硬件投入高、需要专门的推理优化人员维护。
我见过一个实际案例：某企业内部知识库系统最初用API方案，上线后爆发了数据合规问题，被迫整体迁移到私有化部署。如果他们在画架构图的第一天就把数据合规要求画进去，迁移成本完全可以避免。架构图里的每一层标注，本质上都是在提前管理未来的风险和成本。
5.2 RAG还是微调，架构上怎么体现
这个争论在技术社区几乎每周都会出现。我的答案是：默认先考虑RAG，把微调作为进阶选项。RAG的优势在于知识更新方便——内容变了重新索引一遍就行；微调的优势在于改变模型的行为风格和格式遵循能力，但它无法注入实时知识，而且需要准备高质量的标注数据集。
架构图中至少要为微调预留一个扩展位置，哪怕初期不上线。我用虚线框画一个“模型微调流水线”，里面放上数据准备、训练任务、模型评估三个子模块。等系统跑起来以后，如果发现RAG无论如何做都满足不了特定领域的输出格式要求，再启动微调工作流。这种设计让架构图既反映现状，又能容纳演进。
5.3 上下文管理与Token成本控制
Token成本是AI应用架构里最隐秘的黑洞。以RAG模式为例，一个回答消耗的Token大约等于“系统提示词加历史对话加检索文档拼接加模型输出”的总和。如果一次检索把上万字的文档都塞进Prompt，很快就会发现，模型质量没提升多少，月度账单却翻了好几倍。
架构图上每个调用模型的环节旁边，我都建议标注一个“预估Token消耗区间”。这个区间不是拍脑袋填的，而是根据历史平均对话轮数、每轮检索文档的默认块数和输出长度上限估算出来的。有了这个数字，运维同学在监控里看到某个接口Token消耗异常时，能够立刻定位到是哪一层出了问题，而不是查半天日志才发现是Prompt构造逻辑被改了一行。
5.4 缓存策略也是架构的一部分
很多人画AI应用架构时不画缓存，这是不对的。对高频重复的问题，完全可以做一层缓存处理：把用户问题做规范化处理后计算语义哈希，在缓存里命中相同或近似的历史问题，直接返回上次的模型输出。这样可以省掉大量模型调用成本，尤其在知识库内容基本不变的情况下，缓存命中率可以到三成以上。
当然缓存策略要谨慎，不能对结果实时性要求高的场景使用。但架构图里保留一个缓存组件的位置，后续系统优化时你会感谢当初这个决定。
6. 实操记录：一个RAG应用从构想到架构落地的完整过程
6.1 场景背景与需求梳理
今年上半年我参与了一个面向企业内部员工的规章制度问答项目，需求是让员工随时询问关于差旅报销、绩效考核、请假流程等制度问题，回答要基于公司发布的文件，不能编造。这是一个典型的RAG应用场景。
第一步先梳理用户量和访问特征。企业内部员工大约上千人，峰值并发预计在每分钟几十次请求的规模，对话轮次平均在2到4轮。这个量级意味着单机部署完全可以承载，不需要引入复杂的分布式架构。但我还是在架构图中预留了水平扩展能力，因为上线后如果使用率超出预期，加机器就行，不用返工。
数据量摸底后发现制度文件有一百多份，总计约八十万字。这个规模对向量检索来说非常轻松，但对切分和索引策略有一定要求，因为部分文档里大量存在“根据《XX规定》第三条”这类交叉引用，单纯按固定长度切分会把上下文关系切断。
6.2 架构图第一版怎么画的
我画的第一版架构图分为四个横向区域。最上部是接入层，容器里画了企业微信入口和Web管理后台两个组件。中间是应用编排层，核心组件包括意图识别模块、RAG检索编排模块、回答生成模块、反馈收集模块。
第二层是模型服务层，标注了主模型采用通用商用API，备用模型是同供应商的轻量版本，两个模型之间有一条带虚线标注的“熔断切换”关系。再往下是知识增强层，画了离线文档解析管道、向量库和在线检索组件。最底部是数据基础层，包括业务数据库、向量数据库、对象存储和日志存储。
这张图画完以后，团队花了三个小时开会评审，最终改了三处：一是在接入层增加了白名单限制，只有内网IP段才能访问管理后台；二是把文档解析管道从同步调用改成异步消息驱动，避免超大文档解析时阻塞系统；三是在回答生成模块增加了敏感信息脱敏发布订阅逻辑，因为制度文件中可能包含薪酬信息。
6.3 开发过程中对架构图的修正
真正开发起来以后，有一个细节暴露出了架构图的问题。文档里有大量的表格，比如报销标准表、绩效考核评分表，这些表格数据如果按文本切分再向量化，检索效果非常差。因为表格被切碎以后，表头信息对不上内容，模型看了半天也不知道“一级城市住宿标准”对应的是多少钱。
我们给知识增强层补了一个“表格结构化抽取”模块：先用规则识别文档里的表格区域，把每张表格转为结构化的键值对描述，再独立向量化存储。检索时如果命中表格内容，会把整张表的关键结构作为上下文传给模型，而不是几块零零散散的文本碎片。这个模块上线后，表格类问题的回答准确率从六成提升到了九成以上。
这让我再次确认一个规律：架构图永远不可能一次画完美，但好的架构设计能留出修正空间。因为当初把知识增强层拆成了独立的模块，增加表格结构化模块时才没有影响到检索链路和模型调用逻辑。
6.4 上线后的架构演化和容量评估
上线后的数据跟预期基本一致。日均请求量几百次，模型调用平均耗时约1.8秒，检索模块耗时约300毫秒，整体回答链路在2.5秒左右。Token成本方面，每轮对话平均消耗约2400个Token，月度成本完全在可控范围内。
随后我们做了一次容量评估：按现有架构，如果用户量翻五倍，单机部署的实例CPU使用率会接近阈值，需要额外增加一个服务实例，前置负载均衡。向量数据库切换到集群模式，加一个副本节点。模型调用层面因为走的是商用API，由供应商负责扩展，我们只需要注意限流策略。这些扩展动作在架构图上都能找到对应的挂载点，真正做到按图索骥。
7. 常见问题与排查技巧实录
7.1 检索结果总是很差，问题可能出在哪
RAG架构里最常被吐槽的问题就是“答非所问”。遇到这种情况，不要急着怀疑模型能力，先排查知识增强层。我整理了一个从易到难排查顺序，实际测试下来命中率很高：
第一步，检查检索TopK和重排序。很多团队对检索到的文档不做重排序，直接把Top3结果塞进Prompt。如果候选文档质量问题多，回答效果必然受影响。第二步，检查切分策略。固定500字切块和按语义段落切块，检索效果可能差一大截。第三步，检查向量化的维度适配。文本向量模型和检索模型维度不匹配是低级错误，但时有发生。第四步，检查Prompt模板中知识指令的表述。模型如果不知道“优先依据提供的材料回答”，就算检索到正确答案也可能自由发挥。
7.2 模型回答变慢之后的瓶颈定位
AI应用响应变慢，排查思路和传统应用完全不同。传统应用慢大概率是数据库查询慢或后端计算密集，而AI应用慢通常集中在模型生成环节。如果发现回答耗时长，先用链路追踪数据判断是“模型调用前慢”还是“模型调用本身慢”。
模型调用前慢，包括检索慢、上下文构造慢、安全检测慢；模型调用本身慢，主要受输出Token数和并发排队影响。一条经验法则：输出Token数每增加一倍，生成耗时大约增加一倍半到两倍。所以对追求响应速度的场景，把回答长度上限设置短一些，是见效最快的优化手段。
7.3 每日成本超标应该从哪里开始查
成本超标通常不是模型单价涨了，而是Token消耗失控。首选排查对象是上下文膨胀——多轮对话场景下，历史消息不断累加，如果不做截断或者摘要压缩，每轮都会把完整历史塞给模型，Token消耗呈线性甚至超线性增长。
我的做法是在架构图上标注清楚“上下文管理模块”的位置，并且规定：超过N轮以上的历史消息必须做摘要压缩，超过M字符的消息体必须截断。这两个阈值写进代码里，成本就基本可控了。其次排查的是检索块数量，不要贪多，三到五块有效内容比二十块无关内容对回答质量贡献更大。
7.4 知识更新后模型还在答旧内容
很多团队上线RAG后遇到一个问题：明明确权部门和内容都更新了，员工问起来，模型回答的还是旧数据。绝大多数原因出在向量库的更新策略上。
如果向量库只做新增不做删除，旧版本文档的向量块依然参与检索，就可能导致模型拿到新旧两套矛盾信息，然后给出混乱回答。正确做法是在离线索引链路里实现“按文档ID全量替换”的语义：同一份文档重新解析后，先删掉该文档ID下的所有旧向量块，再写入新的向量块。数据库层面要支持按文档ID批量删除的接口，而不是简单清空全库重建。
这个坑我踩过两次之后才长记性，现在我在架构图上一定会明确标注“文档版本替换机制”，并作为知识增强层的必选模块。
8. 给初学者的三条核心建议
画AI应用架构这件事不要求你一开始就是架构师，但至少有三种能力需要刻意练习。第一，学会用分层视角看系统。不管画什么系统，先从“接入、应用、模型、数据、治理”这几层往下套，再根据场景增减模块。分层不是形式主义，而是让系统的复杂性问题分散到不同维度，每个维度能独立演化和扩展。
第二，学会画“当前状态”和“目标状态”两张图。很多人一上来就画理想架构，结果跟团队手头代码完全对不上，久而久之大家对架构图失去信任。正确的做法是先画一张跟现状一致的图，诚实反映系统当前的长相；再画一张目标架构图，让整个团队看到演进方向。两张图之间的差距，就是未来几个迭代的开发任务清单。
第三，架构设计的关键成果不一定能被量化评价，但一定能在风险到来时被验证。当用户量翻了十倍、当知识库突然要接入新的数据源、当模型服务商升价限流、当安全审查要求提供完整数据链路说明，架构图就是支撑你做判断的底图。没有这层底图，所有这些突发状况都会变成救火行动。
我在实际项目里还有一个习惯：每次项目交接或者大版本总结时，把最新架构图单独打印出来，贴在团队白板上。让新加入的同事从这张图开始读代码、了解系统，让评审的人先看图再谈细节。一张好的AI应用架构图，能替团队省掉大量靠口口相传的隐性知识流失成本，这也是为什么我一直坚持先把图画出来再写代码的根本原因。
