企业官网建设流程全解析

1. 这不是画PPT，是给AI系统搭骨架

“图解AI应用架构设计”这六个字，最近在技术社区里出现频率高得有点反常——不是出现在论文摘要里，也不是写在招聘JD的“加分项”栏，而是扎扎实实挂在一线工程师的周报标题、架构评审会议纪要、甚至新项目立项书的第一页。我去年带过三个从0到1的AI产品落地项目，每次启动会第一件事，不是写代码，不是调模型，而是围坐在白板前，用不同颜色的马克笔，把“用户请求怎么进来”“中间要过几道关卡”“哪块算力扛不住”“失败了往哪儿退”这些事，一笔一划画成图。有人管这叫“画架构图”，但说实话，真正在现场干过的人都知道：这不是美化汇报材料的PPT技巧，而是一套可执行、可验证、可拆解的工程决策语言。

核心关键词就藏在这标题里：“图解”不是配图说明，是把模糊的业务意图翻译成确定性的组件关系；“AI应用”不是指跑通一个ResNet或微调个LLM，而是指那个能被用户点击、能和数据库交互、能扛住并发、能出错后不崩盘的真实服务；“架构设计”更不是堆砌K8s、Redis、LangChain这些名词，而是回答“为什么这里必须用消息队列而不是直连？”“为什么这个模型推理要单独部署而不是嵌入API服务？”“为什么缓存策略要按数据新鲜度分三级？”——每一个箭头、每一块色块、每一条虚线，背后都是成本、延迟、容错性、运维复杂度的硬博弈。

适合谁来看？如果你是刚接手AI模块的后端工程师，看到需求文档里写着“支持多轮对话”，却不知道该从API网关开始拆，还是从向量库选型开始想；如果你是算法同学，模型指标刷到了98%，但上线后用户反馈“响应慢得像在等泡面”，却找不到瓶颈在哪一层；如果你是技术负责人，需要在“两周内上线POC”和“未来三年能平稳迭代”之间做取舍，又怕画出来的图最后变成墙上挂的装饰画——那这篇就是为你写的。它不教你怎么写PyTorch，也不讲Transformer原理，只聚焦一件事：当AI能力要真正长进产品血肉里时，那个支撑它的骨架，到底该怎么搭、为什么这么搭、哪里最容易断。

我见过太多项目死在“图没画对”。比如某智能客服项目，初期图上只画了“用户→API→大模型→返回”，上线后发现单次响应要8秒，排查发现所有请求都挤在同一个GPU实例上排队；再比如一个文档分析工具，架构图里把OCR、文本提取、语义理解全塞进一个服务，结果一次PDF解析失败，整个API直接500。这些都不是模型问题，是骨架没承住力。所以接下来，我们不聊虚的，直接拆解一张真正能指导开发的AI应用架构图，从设计逻辑、细节颗粒度、落地陷阱，一层层剥开。

2. 架构图不是装饰画，是工程决策的快照

2.1 为什么必须用“图”来设计AI应用？

很多人觉得架构设计就是写文档、开评审会，图只是辅助。但在AI应用领域，这种认知非常危险。原因有三：

第一，AI组件的不确定性远高于传统服务。一个MySQL查询超时，你大概率能归因到慢SQL或连接池；但一个LLM响应延迟飙升，可能是GPU显存碎片、KV Cache未复用、Prompt长度突增、甚至模型权重加载异常——这些因素交织在一起，文字描述极易遗漏关键路径。而一张图，强制你把“输入→预处理→路由→模型加载→推理→后处理→输出”的每个环节显式画出来，漏掉任何一个节点，整条链路就断了。

第二，跨角色协作依赖视觉共识。算法同学关注的是模型输入输出格式、token限制、batch size；后端关心的是QPS、超时时间、重试策略；运维盯着GPU利用率、内存泄漏、日志埋点位置。如果只靠文字描述，算法说“模型支持流式输出”，后端可能默认为HTTP chunked，结果发现模型实际需要WebSocket长连接——这种偏差，一张标注了协议类型、数据格式、超时阈值的图，比十页文档更有效。

第三，演进过程需要可追溯的基线。AI应用极少一次性定型。上周还在用Embedding+FAISS做检索，这周要接入RAG加LLM生成，下个月可能要切到MoE架构分流请求。如果初始架构图只画了最终态，那每次变更都得推倒重来。而一张分层清晰（接入层/编排层/模型层/数据层）、带版本标记、标注了各组件替换边界的图，能让团队清楚知道：“这次升级只动模型层，编排层配置不变”，极大降低协作成本。

我经手的一个金融风控项目，初期架构图用不同颜色区分了“规则引擎”（绿色）、“传统ML模型”（蓝色）、“新引入的图神经网络”（橙色），并用虚线框标出“可插拔模型区”。后来业务方要求增加实时图谱计算，我们直接在橙色区域里新增一个子模块，其他部分完全不动。上线后回看这张图，连实习生都能快速定位到新增模块的上下游依赖——这就是好架构图的价值：它不是静态快照，而是动态演进的导航地图。

2.2 真正有效的AI架构图，必须包含哪四类核心元素？

市面上很多所谓“AI架构图”，要么是云厂商宣传图（堆满Logo），要么是学术论文里的抽象框图（Input→Model→Output）。但能指导真实开发的图，必须包含以下四类不可省略的元素，缺一不可：

1. 显式的数据流向与协议标识
不能只画箭头，必须标注：

• 协议类型（HTTP/1.1、gRPC、WebSocket、Kafka）
• 数据格式（JSON Schema、Protobuf、Base64编码的图片二进制）
• 关键参数（HTTP超时设为3s还是30s？gRPC最大message size是4MB还是16MB？）
  例如：用户上传PDF的请求，如果图上只画“前端→API服务”，那是无效信息；必须标明“前端通过multipart/form-data POST至/api/upload，API服务解析后以base64字符串发往OCR服务，超时15s”。

2. 明确的组件边界与职责声明
每个矩形框不能只写“LLM Service”，而要注明：

• 核心职责（“仅负责模型加载与推理，不处理Prompt工程”）
• 输入约束（“接受max_tokens≤2048的prompt，拒绝含特殊控制字符的输入”）
• 输出契约（“返回结构化JSON，包含text、usage、finish_reason字段”）
  这能避免后期扯皮：“为什么没做敏感词过滤？”——因为图上已声明该组件不负责内容安全。

3. 关键非功能属性的可视化标注
在组件旁用小标签标出：

• 性能指标（“P99延迟≤1.2s”、“支持500 QPS”）
• 容错策略（“下游故障时降级返回缓存结果”、“重试2次，间隔100ms”）
• 资源约束（“独占1张A10 GPU，显存预留2GB用于KV Cache”）
  这些数字不是拍脑袋，而是基于压测或历史流量估算的，图上标出来，就是对齐底线。

4. 变更影响域的隔离标识
用虚线框或阴影区域标出：

• “热更新区”（模型权重可在线替换，无需重启服务）
• “强耦合区”（修改此处需全链路回归测试）
• “灰度发布区”（新版本流量先导入1%）
  这直接决定后续迭代节奏。比如某项目把“Prompt模板管理”放在热更新区，运营同学改个话术第二天就能生效；而把“向量库schema”放在强耦合区，意味着改字段必须停服。

提示：画图时有个铁律——所有文字标注必须能直接转化为代码注释或配置项。如果图上写了“高性能缓存”，但代码里找不到对应的Redis连接池配置，那这张图就是废纸。我习惯在画完图后，拉着开发同学逐个组件核对：“这个超时值，配置文件里对应哪一行？这个降级逻辑，代码里哪个if分支实现？”

2.3 常见错误：把架构图画成“技术栈罗列墙”

新手最容易犯的错，是把架构图变成技术名词展览馆。比如这样：

[用户] → [Nginx] → [FastAPI] → [LangChain] → [Llama3] → [PostgreSQL] → [Redis] → [Prometheus]

表面看很“全”，实则毫无价值。问题在于：

• 隐藏了关键决策：为什么选FastAPI而不是Flask？图上没体现——实际是因为FastAPI的异步IO能更好利用GPU等待时间；
• 混淆了抽象层级：LangChain是框架，Llama3是模型，PostgreSQL是数据库，它们不在同一维度，强行并列导致逻辑混乱；
• 缺失责任归属：Redis到底缓存什么？Token还是Embedding？图上没说，结果开发时各猜各的；
• 无视数据形态变化：用户发来的是语音，到模型输入时已是MFCC特征向量，中间经历了ASR、特征提取、归一化三步，图上却只画了一个箭头。

正确的画法，是按数据处理阶段分层。我推荐采用四层模型：

1. 接入层（Ingress Layer）：处理协议转换、认证鉴权、限流熔断。组件如API网关、WAF、OAuth2.0服务。
2. 编排层（Orchestration Layer）：协调多步骤任务，处理分支逻辑、状态管理、错误恢复。组件如工作流引擎（Temporal）、规则引擎、轻量级编排服务。
3. 模型层（Model Layer）：封装具体AI能力，提供标准化接口。组件如独立部署的OCR服务、Embedding API、LLM推理集群。
4. 数据层（Data Layer）：存储与检索AI所需数据。组件如向量数据库、特征存储、知识图谱、原始文档库。

每一层内部再细化组件，层与层之间用带标注的箭头连接。这样画出来，一眼就能看出“语音识别失败时，编排层是否触发备用ASR？”“向量库查询超时，是否降级到关键词检索？”——这才是架构图该有的样子。

3. 从零开始画一张能落地的AI架构图：分步实操指南

3.1 第一步：锁定核心业务场景，定义“最小可行数据流”

别一上来就画全貌。先问自己三个问题：

• 用户最痛的一个动作是什么？（不是“用AI提升体验”，而是“用户上传合同PDF，3秒内返回关键条款摘要”）
• 这个动作里，AI参与的唯一不可替代环节是什么？（不是“整个流程”，而是“从非结构化PDF中精准抽取法律实体名称”）
• 如果只做这一件事，数据从进来到出去，必须经过哪几个硬性环节？（上传→解析→文本提取→实体识别→结构化输出）

以“合同条款摘要”为例，我们定义最小数据流：
用户上传PDF → 后端接收 → OCR识别文字 → NLP模型抽取条款 → 生成摘要 → 返回JSON

注意：这里刻意排除了“用户登录鉴权”“PDF存储到OSS”“摘要结果存数据库”等非核心环节。因为架构图的第一版，只解决“AI能力能否正确交付”这个生死问题。其他环节后续再叠加。

实操技巧：用便利贴写每个环节，贴在白板上，只保留必须项。我曾见一个团队在初稿画了17个组件，删掉6个后发现，真正影响摘要质量的只有OCR精度和NER模型两个环节——其他全是干扰项。

3.2 第二步：为每个环节选择技术方案，并标注决策依据

针对最小数据流中的每个环节，列出候选方案，用一句话写明选择理由。例如：

• OCR识别：

  • 候选：Tesseract（开源）、Google Vision API（SaaS）、自研CNN模型
  • 选择：Tesseract + 自定义版式分析模块
  • 决策依据：合同PDF版式高度统一（固定页眉/表格结构），Tesseract在规则版式下准确率92%，且无需网络调用，规避第三方服务SLA风险；自研模块解决表格线识别问题，将准确率提升至96.5%。

• 实体识别（NER）：

  • 候选：spaCy规则匹配、BERT微调模型、商用API
  • 选择：微调的RoBERTa-base模型
  • 决策依据：法律文本实体类型固定（甲方/乙方/金额/日期/违约金），标注2000份合同后F1达0.89；相比规则匹配，泛化性更好（能识别“人民币贰拾万元整”等变体）；相比商用API，成本降低70%，且数据不出域。

注意：这里的“决策依据”必须量化。不能写“效果更好”，要写“F1提升12个百分点”；不能写“成本更低”，要写“月均费用从￥12,000降至￥3,500”。这些数字，就是后续压测和验收的基准线。

3.3 第三步：绘制分层架构图，严格遵循四层模型

按之前定义的四层，把选定的组件填进去。关键细节：

接入层：

• 组件：Kong网关（替代Nginx，支持JWT鉴权、请求限流）
• 标注：/api/contract/summary 接收multipart/form-data，单文件≤50MB，超时30s
• 特殊设计：网关层做PDF文件MD5校验，相同文件直接返回缓存摘要（命中率约40%）

编排层：

• 组件：自研轻量编排服务（Python + Celery）
• 标注：顺序执行：OCR→TextClean→NER→Summary，任一环节失败触发降级：OCR失败则跳过，直接用PDF文本做NER；NER失败则返回空数组
• 关键参数：Celery worker concurrency=4，预取数量=1（防GPU饥饿）

模型层：

• 组件：OCR服务（Flask + Tesseract）、NER服务（FastAPI + PyTorch）
• 标注：OCR服务：GPU加速（CUDA 12.1），P95延迟≤800ms；NER服务：CPU推理，batch_size=16，P95延迟≤300ms
• 隔离设计：两个服务独立部署，NER不依赖OCR输出格式（接收纯文本，自动处理换行符）

数据层：

• 组件：MinIO（对象存储）、PostgreSQL（结构化结果）、Redis（摘要缓存）
• 标注：Redis key=sha256(pdf_bytes)，TTL=7天；PostgreSQL表contract_summary含id、pdf_hash、summary_json、created_at字段

画图时，用不同颜色区分四层（如接入层蓝色、编排层绿色、模型层橙色、数据层紫色），箭头用实线表示主数据流，虚线表示控制流（如编排层向Redis发缓存指令）。

3.4 第四步：注入非功能需求，让图具备工程约束力

现在图有了骨架，必须加上肌肉——非功能属性。重点补充三类：

1. 性能契约
在每个组件旁标出硬性指标：

• Kong网关：支持2000 QPS，平均延迟≤15ms（不含后端）
• OCR服务：单页PDF处理≤1.2s，GPU显存占用≤8GB
• NER服务：吞吐量≥120 req/s，CPU使用率≤70%
  这些数字来自压测报告，不是理论值。例如OCR的1.2s，是用1000份真实合同PDF在A10上实测的P95值。

2. 容错策略
用小图标或文字标注：

• OCR失败 → 编排层降级：跳过OCR，直接用PDF文本（含乱码）做NER
• NER服务不可用 → 返回HTTP 503，前端显示“条款分析暂时不可用，请稍后再试”
• Redis宕机 → 缓存失效，不影响主流程，但P95延迟上升至1.8s

3. 安全与合规
在数据流上加锁形图标：

• PDF文件上传后立即加密（AES-256）存储于MinIO
• NER服务输出的实体名称，经脱敏模块过滤（屏蔽身份证号、银行卡号）
• 所有API调用记录审计日志，留存180天

实操心得：我在某项目中吃过亏——图上写了“NER输出需脱敏”，但没明确脱敏规则。上线后发现算法同学只过滤了手机号，没处理银行账号，导致合规审查不通过。后来补救：在图上直接写脱敏规则：正则匹配\d{16,19}（银行卡）、\d{18}（身份证）、1[3-9]\d{9}（手机号），替换为***。从此，图就是法典。

3.5 第五步：验证与迭代——用这张图驱动第一次开发

画完不是结束，而是开始。用这张图做三件事：

1. 开发任务拆解
按图上组件，分配任务：

• 接入层：后端同学配置Kong路由、JWT验证、文件大小限制
• 编排层：写Celery任务链，实现OCR→NER→Summary的串行调用及降级逻辑
• 模型层：OCR同学封装Tesseract为Flask服务，暴露/ocr接口；NER同学导出PyTorch模型为TorchScript，部署到FastAPI

2. 环境准备清单
从图中提取资源需求：

• GPU服务器：1台A10（OCR服务）
• CPU服务器：2台（NER服务，主备）
• 中间件：Kong集群（3节点）、Redis（哨兵模式）、MinIO（4节点）
• 监控：Prometheus抓取各服务metrics，Grafana看板监控GPU显存、NER延迟、缓存命中率

3. 首轮测试用例设计
基于图上标注的契约：

• 测试OCR：上传100份合同PDF，验证P95延迟≤1.2s，准确率≥96.5%
• 测试降级：手动停OCR服务，验证编排层是否跳过并继续执行NER
• 测试缓存：上传同一PDF两次，验证第二次响应时间≤50ms

首轮开发完成后，拿着实测数据回头检查架构图：如果OCR实际P95是1.5s，那就得调整——要么优化Tesseract参数，要么加GPU，或者承认当前架构无法满足需求。图不是用来证明设计正确，而是用来暴露设计缺陷的镜子。

4. 避坑指南：那些让AI架构图失效的致命细节

4.1 细节陷阱一：忽略“数据形态转换”，导致上下游撕裂

AI应用里，数据在不同环节的形态差异巨大，但架构图常把它画成“一个东西流过去”。典型例子：语音识别流程。

错误画法：
[麦克风] → [ASR服务] → [文本分析服务] → [返回结果]

问题在哪？

• 麦克风输出的是PCM音频流（二进制）
• ASR服务输入要求是WAV格式（带header），采样率16kHz
• 文本分析服务输入是UTF-8字符串，但ASR输出可能含乱码（如“合冋”而非“合同”）
• 如果图上不标注这些转换点，开发时ASR同学按标准WAV封装，文本分析同学直接当字符串处理，结果乱码传到下游，调试三天才发现是编码问题。

正确做法：在箭头上明确标注数据形态：
[麦克风] --(PCM, 44.1kHz)--> [音频预处理] --(WAV, 16kHz)--> [ASR服务] --(UTF-8 JSON, 含text字段)--> [文本清洗] --(标准化中文)--> [文本分析服务]

我经手的一个医疗问诊项目，就因忽略此细节栽跟头。ASR输出的JSON里，text字段是GBK编码，但文本分析服务默认UTF-8解析，导致“高血压”变成乱码。修复方案是在架构图上加了一块“编码转换”组件，并规定：所有服务间JSON必须UTF-8，ASR服务输出前自动转码。

4.2 细节陷阱二：把“模型服务”当成黑盒，忽视内部资源争抢

很多图把“LLM推理服务”画成一个方块，标注“支持Chat API”。但实际部署时，这个方块内部可能同时跑着多个模型（Llama3-8B、Qwen1.5-7B、Phi-3），共享同一GPU。如果图上不体现资源隔离，就会出问题。

常见错误：

• 不区分模型实例：所有请求都打到同一个服务端口，由内部路由分发
• 不标注显存预算：Llama3-8B需8GB显存，Qwen1.5-7B需6GB，但GPU只有16GB，理论上可并行2个，实际因KV Cache碎片化只能跑1.5个

解决方案：在架构图中，将“LLM推理服务”拆分为：

• 模型调度器（CPU）：接收请求，根据模型、负载、优先级分发
• Llama3实例组（GPU）：独立Pod，显存限制8GB，最多2副本
• Qwen实例组（GPU）：独立Pod，显存限制6GB，最多2副本
• 共享资源池：标注GPU显存总量16GB，调度器确保各组显存不超限

并在调度器旁注明策略：高优先级请求（VIP用户）优先分配Llama3实例；普通请求按轮询分发；若某组GPU利用率＞90%，暂停新请求接入

4.3 细节陷阱三：低估“冷启动延迟”，让用户体验断崖下跌

AI模型加载耗时，常被架构图忽略。尤其大模型，首次请求可能要花10-30秒加载权重到GPU。如果图上只写“P95延迟≤2s”，却不提冷启动，上线后用户首屏等待半分钟，投诉就来了。

真实案例：某教育APP的作文批改功能，架构图标注“响应≤3s”，但没区分冷热。上线后发现，凌晨低峰期用户首请求平均耗时22s。根本原因是：模型服务采用按需启动（K8s HPA），流量低时Pod被缩容，新请求触发重建+加载。

修正方案：在架构图中增加预热机制组件：

• 定时任务：每日04:00触发，向各模型实例发送空请求，保持GPU显存常驻
• 健康检查：/health端点返回模型加载状态，K8s readinessProbe检测此状态
• 标注：冷启动延迟≤500ms（预热后），未预热时延迟≤25s（需前端提示“正在加载AI引擎，请稍候”）

注意：预热不是万能的。我见过一个项目，预热脚本每天跑一次，但下午流量高峰时Pod被自动扩缩，新Pod仍需冷启动。后来改成：HPA扩缩容时，新Pod启动后自动执行预热请求，完成后再加入服务发现。这个逻辑，必须画在图上。

4.4 细节陷阱四：混淆“开发环境”与“生产环境”，导致上线即崩

最隐蔽的坑，是架构图默认画的是生产态，但开发时用的是简化版。比如图上画了“Kong网关→Auth服务→业务API”，开发同学本地调试却直接访问业务API，绕过鉴权。结果上线后，Auth服务配置错误，所有请求401。

解决方案：在架构图右下角加环境差异标注栏：

并强调：所有环境必须共用同一套API契约（OpenAPI Spec），本地Mock需严格遵循Spec。我们用Swagger Codegen自动生成各环境客户端，确保调用一致。

4.5 细节陷阱五：忘记“可观测性”不是附加功能，而是架构必需品

很多图把监控、日志、链路追踪画在角落，标注“运维组件”。但AI应用的故障，90%需要靠可观测性定位。没有它，架构图就是一张废纸。

必须在图中显式集成：

• 每个服务暴露/metrics端点（Prometheus格式）
• 所有HTTP/gRPC调用注入trace_id，通过Jaeger上报
• OCR服务日志包含page_num、confidence_score、processing_time
• NER服务日志记录input_length、entity_count、model_version

特别提醒：AI服务的日志字段，必须包含业务语义。不能只记"request_id": "abc123", "status": "200"，而要记"doc_hash": "sha256_xxx", "entities_found": ["甲方", "违约金", "人民币伍拾万元"], "ner_model_v2.1"。这样出问题时，运维才能直接关联到具体合同和模型版本。

我曾处理一个故障：用户反馈“某些合同摘要漏掉金额”。查日志发现，NER服务对含“¥”符号的金额识别率低。因为训练数据里多用“人民币”字样，少用符号。这个洞察，就来自日志里entities_found字段的聚合分析——如果图上没强制要求记录这个字段，问题可能永远定位不到。

5. 架构图的生命周期管理：如何让它持续指导迭代

5.1 版本化：把架构图当作代码一样管理

架构图不是画完就扔的文档。我们用Git管理.drawio文件（Draw.io开源格式），每次变更提交PR，并关联Jira任务。关键实践：

• 主干分支（main）：始终保存当前线上运行的架构图
• 特性分支（feature/rag-integration）：新增RAG模块的设计图
• 合并前必做：
  1. 对比新旧图，自动生成变更摘要（如“新增向量库组件，修改编排层数据流”）
  2. 检查新图是否违反现有性能契约（如新增组件后，端到端延迟预测超限）
  3. 更新配套文档：OpenAPI Spec、部署清单、监控看板

这样，任何时候都能回溯：“v2.3版本上线时，架构图做了哪些改动？”——答案就在Git历史里。

5.2 自动化：用代码生成图，再用图生成代码

最高阶的实践，是让架构图与代码双向同步。我们用Python脚本解析Draw.io XML，提取组件、连接、标注，生成：

• 部署脚本：根据组件类型（GPU/CPU/无状态），自动生成K8s YAML
• 配置文件：从图中标注的超时、重试次数，生成Envoy配置
• 测试用例：从数据流路径，生成Postman集合，覆盖主路径+降级路径

反过来，CI流水线中，代码提交后自动扫描：

• 若新增HTTP接口但图上无对应组件 → 阻断合并
• 若图上标注P95≤1.2s但压测报告超限 → 阻断发布

这听起来很重，但实际只需200行Python+Jinja2模板。核心思想：架构图不是设计产物，而是系统契约的权威来源。

5.3 团队共建：让每个人都能修改图，但必须通过“契约校验”

我们禁止“一个人画图，一群人看图”。规则是：

• 所有成员有权限编辑Draw.io文件
• 但每次保存前，必须运行本地校验脚本：

  # 检查是否所有组件都有性能标注 python validate_arch.py --check-performance # 检查数据流是否闭环（无悬空箭头） python validate_arch.py --check-flow-closure # 检查新组件是否在部署清单中有对应条目 python validate_arch.py --check-deployment-match

• 校验失败，Draw.io自动弹窗提示：“缺少NER服务的P95延迟标注，请补充”，无法保存。

刚开始大家嫌麻烦，但三个月后，团队自发形成了习惯：开会讨论新需求时，第一句话是“先更新架构图，再写代码”。因为图上的每一个字，都意味着要写对应的代码、配置、测试——它不再是纸上谈兵，而是开发承诺。

5.4 持续演进：从“单点AI”到“AI能力网络”

最后，分享一个真实演进路径。我们最初的架构图，只服务于一个场景：“合同摘要”。随着业务扩展，陆续增加了：

• 场景2：“招标文件比对”（需OCR+文本相似度计算）
• 场景3：“法律条文问答”（需向量检索+LLM生成）

如果为每个场景画独立架构图，很快就会失控。我们的解法是：构建AI能力网络（AI Capability Network）。

在原图基础上，新增一层：

• 能力注册中心：所有AI服务（OCR、NER、Embedding、LLM）向中心注册，声明能力类型、输入输出Schema、SLA
• 智能路由网关：接收用户请求，根据请求内容（如含“比对”关键词）自动路由到OCR+Similarity服务组合
• 统一监控平台：聚合各能力的延迟、错误率、成本，生成能力健康度评分

这样，新场景上线，不再重画全图，只需：

1. 开发新能力服务（如Similarity服务）
2. 向注册中心注册
3. 在路由网关配置规则

架构图本身，从一张静态图，进化为一个动态网络拓扑。而这张图的每一次演进，都忠实记录着团队对AI工程化的认知深化——它不再只是“怎么搭”，更是“怎么让AI能力像水电一样即插即用”。

我在最后一次架构评审会上，指着这张图对所有人说：“这张图里，没有一个组件是‘我的’，也没有一个问题是‘他的’。它只回答一个问题：当用户按下那个按钮时，我们承诺交付的体验，是否真的能兑现。” 这就是图解AI应用架构设计的全部意义——不是炫技，不是交差，而是用最朴素的线条和文字，守住工程人的底线。