没有业务架构时先别急着画技术架构上一篇有个判断技术架构不能凭空画业务架构应该是技术架构的输入。放在成熟团队里这个条件成立。麻烦在于很多公司没有这个输入。有些团队压根就没有过业务架构图。有些业务刚开始做产品文档还在改。有些老系统跑了几年业务边界早被需求冲散。没人能拿出一张业务架构图。但我们不能卡在这里然后跟老板说需要你给我一张业务架构。这时要先梳理核心业务流程。你要沿着这条线把状态归属、同步边界、模块关系、异常兜底和支撑能力一步步梳理出来。动手之前先识别关键需求在梳理核心业务流程之前还有一个更前置的问题这个系统的关键需求是什么这里先说一个结论关键需求决定架构其余需求验证架构。放在 AI 客服这个场景里关键需求至少有三类。第一类是关键功能性需求。用户从提问到拿到有效回复这条链路必须走通。如果这条链路走不同系统就没有存在的业务价值。这是最长的职责协作链也是架构的主心骨。第二类是关键非功能需求也叫质量足球。端到端响应延迟要控制在2秒以内。服务可用性不能低于 99.9%。同时支持1w并发。多租户之间的数据必须严格隔离。这些是硬性约束。任何一个没满足就无法满足设计预期。第三类是关键约束、限制。公司已经有的订单系统、CRM、物流系统接口协议等都不是我们能随意更改的。数据合规要求也摆在那里不能绕过。必须要选择某个中间件、数据库等比如信创要求。这三类关键需求决定了核心域包括会话、机器人编排、知识检索运营看板、数据报表、训练平台等只能归到非核心域。也决定了为什么外部依赖必须画在边界外并且要有熔断降级、支持横向扩展。关键需求没想清楚后面画的每一个框都缺乏依据。框摆得再整齐也只是系统清单。第一步梳理核心业务流程先把用户怎么进来画清楚AI 客服这类系统先画一条最核心的用户路径用户发起对话。系统识别租户、用户身份和机器人配置。会话被创建或恢复。用户消息进入会话服务。机器人编排判断路径。可能查 FAQ。可能走知识库检索。可能调用订单、物流、退款这些业务系统。也可能转给人工坐席。系统把结果返回给用户。会话记录、质检数据、日志和运营分析在后面处理。这一步的产出是架构图的主线。有了这条线每个模块都要回答我服务于这条链路的哪一段有些模块重要但不在主线上就先放在一边。比如数据看板很重要知识运营也很重要但用户等回复时这些模块不是核心。第二步标出状态机流转和数据归属很多图看着像技术架构图但实际上只能回答有哪些服务。一到评审别人问核心状态流转、数据流向等单纯一张图就撑不住需要额外对着图讲一通。画图的人要回答的是两个问题状态怎么变数据从哪里来到哪里去前者是状态流转。后者是数据归属。AI 客服系统里至少要把几类关键状态标出来。会话状态新建 → 机器人处理中 → 已回复 / 待人工 → 人工处理中 → 已关闭。这条状态线应该由会话服务维护最终落到会话库。坐席系统、质检系统、运营看板可以读取会话状态也可以消费会话事件属于下游系统。下游系统一般不会修改上游系统否则会出现几套状态互相打架。消息状态已接收 → 处理中 → 已发送 / 发送失败 → 用户已读。消息状态应该以消息表或消息日志为准。质检分析、数仓宽表、运营报表都是从消息记录加工出来的结果。知识库状态草稿 → 待审核 → 已发布 → 已下线。这里还要多画一个索引状态待切片 → 向量化中 → 索引构建中 → 索引可用。知识内容和版本以知识管理系统为准。向量库、搜索索引、召回缓存只是为了服务于检索加速或提升准确度。可能会有延迟可能会重建也可能短时间和知识管理系统不一致。所以图上要标清楚知识是否发布要以知识管理系统为准。知识能否被机器人检索到还要看索引状态是否编程可用。工具调用状态待调用 → 调用中 → 成功 / 失败 / 超时 → 待重试。工具调用结果要看业务系统返回、调用流水和幂等记录。比如查订单、查物流、发起退款最终结果都应该以业务系统返回为准。这一步做完技术架构图里就不只是有框了。每个关键状态由谁维护、谁能更新、谁只是读取副本开始有边界了。后面讨论故障恢复、补偿任务、对账逻辑时就不至于纯靠拍脑袋。比如知识库已发布但索引还在重建。这时客服机器人能不能用新知识如果回答错了是知识管理系统的问题还是索引构建的问题第三步判断同步和异步边界判断同步异步要显式的思考并标记出来不能做的时候在考虑。用户提问到拿到回复走同步链路还是异步要看关键质量需求里响应延迟是2秒以内的硬约束。主线和状态有了再判断哪些动作要让用户等待。AI 客服里用户提问到拿到回复通常在同步链路上。渠道到接入网关。接入网关到会话服务。会话服务到机器人编排。机器人编排到知识检索、工具调用或模型服务。结果回到会话服务再返回用户。这条线是核心链路要加粗。它是用户等待路径。但用户等待路径不能什么都塞。会话日志落库可以先保证主记录后续分析异步。质检分析可以异步。训练样本沉淀可以异步。运营看板统计可以异步。满意度和解决率这类业务效果指标也不应该抢用户等待链路。它们可以从会话结束事件、人工接管事件、用户反馈事件里异步计算。这一步图上要做三件事同步调用用实线。异步消息用虚线。数据同步用点线或单独标注。线上不要只写调用两个字。能具体就具体。比如 HTTP超时三秒失败降级到备用模型。比如 MQ会话结束事件消费者幂等键是 session_id。比如知识索引发布后异步重建允许分钟级延迟。同一根箭头有人默认同步调用有人默认 MQ有人默认可以重试有人默认失败就丢。箭头不说清楚争论就会从图上转到口头。第四步把模块摆回技术架构骨架里到这里才开始把模块摆回技术架构图。第一篇讲的分层、分域、模块、关系这时就派上用场了。我一般先画四层主架构再把旁路能力和外部边界放进去。第一层是接入层。App、Web、小程序、企微、电话/予以你、开放 API 放在这里。第二层是接入与会话层。接入网关、鉴权、限流、协议适配、会话服务、上下文管理、消息记录放在这里。第三层是核心业务能力层。这里不要按微服务名平铺要先在这一层里画一个独立内框再按业务域摆模块。这个独立内框要和上下两层留出边界不要贴着接入层和数据层画。会话域会话创建、消息收发、上下文管理、会话状态。对话机器人域意图理解、策略编排、prompt管理、上下文管理、模型路由、回复生成。知识域知识管理、文档解析、索引、检索、向量库。工具集成域业务系统连接、接口编排、权限控制、结果封装。人工服务域转人工、坐席工作台、工单、服务记录。但要注意人工服务域不是和知识域、工具域完全并列的常规查询路径。知识和工具更像并行能力。人工是条件跳转是兜底和接管。图上最好用不同线型表达出来别让读者误以为三者地位完全一样。第四层是数据与中间件层。会话库、消息日志、知识库、向量库、搜索索引、缓存、MQ、对象存储、数据同步。分层之外再放三个旁路和边界。左侧靠近分层标签的位置放支撑与治理平面。监控、日志、链路追踪、告警、配置、注册、灰度、开关、任务调度、审计。效果评估要拆开看不要随手塞进支撑平台里。模型调用成功率、响应耗时、召回命中率可以放在技术观测侧。满意度、解决率、转人工率更像业务效果分析适合放在右侧的运营与分析域不要和监控告警混成一团。运营与分析域是系统内部能力但不在用户等待主链路上。它消费会话数据、消息日志、质检结果和成本数据再反哺知识、策略和模型评估。最右侧是外部依赖也就是风险入口。大模型供应商、语音服务、CRM、订单系统、物流系统、工单系统、短信服务都放在边界外。这些外部系统不是可选组件而是关键约束。它们的存在直接决定了工具集成域必须独立成域。也决定了熔断、降级、幂等不是架构洁癖而是外部系统的可用性不受我们控制必须用技术手段解决。这两个位置一定要分清。一个是你自己系统的支撑能力。一个是你无法完全控制的外部边界。很多图在这里画乱是因为内部支撑和外部依赖混在一边。一旦模型供应商超时、CRM 接口抖动、语音服务不可用团队不知道该看内部告警还是该走外部故障预案。第五步补异常、风险和支撑能力生产环境里核心流程从来不是最难画的。难的是失败以后谁兜底。AI 客服这类系统我会在主图上至少标四类异常。第一类模型超时。机器人编排到 LLM 网关这条线要标超时、重试、熔断、备用模型和兜底回复。不要只写外部模型。评审时要追到这些细节用户最多等几秒超时后是换模型、降级模板回复还是转人工第二类知识未召回。知识服务到向量库、搜索索引这条线要标知识版本、索引延迟、召回阈值和兜底策略。如果召回结果不可信是澄清问题还是转人工第三类幻觉、工具调用失败、未调用。调用订单、退款、物流这类业务系统时要标权限、幂等、超时、失败提示。这里有一条红线工具调用失败一定要有明确的降级规则第四类转人工失败、上下文丢失。会话服务到坐席工作台这条线要标上下文包、转接状态、人工接管事件。坐席接手时看不到前面几轮对话技术上不一定会触发 P0但客户体验会明显变差。这些异常标完再把支撑能力补上。限流、鉴权、防刷放在接入侧。重试、幂等、熔断、降级放在业务链路旁。日志、监控、链路追踪、告警放在支撑侧。审计、脱敏、备份、补偿任务放在数据侧。这样画出来的主图仍然是技术架构图。主图成型以后不要硬塞所有细节主图基于核心链路确定之后不要急着往下拆。先用其余需求来验证这个骨架是否足够包容。运营看板需要消费会话数据当前架构有没有暴露合适的事件或接口知识运营后台需要独立的审核流程会不会污染核心链路的状态机训练平台要回流样本会不会反向干扰线上推理如果其余需求在主图上找不到落点或者需要扭曲核心架构才能硬塞进去说明主图的模块边界或分层有问题。这时候应该回退调整而不是在细化层打补丁。这正是关键需求决定架构其余需求验证架构的闭环。主图不是一张面面俱到包含所有细枝末节的图。一张图要建立全局共识不要承担所有解释工作。什么时候该拆下一层我一般看四个点。第一线已经开始交叉读者的视线跟不住。不一定非要数到五条交叉线才拆。但如果你讲图时需要不停用鼠标绕来绕去这张主图已经过载了。第二同一个领域里有超过三个状态要解释。比如会话域既有机器人处理中、待人工、人工处理中、已关闭又有超时、撤回、重复消息就应该拆会话状态图。第三某条链路里有多个异常分支。比如知识发布涉及上传、解析、切片、索引、灰度、回滚主图里只留知识域和风险标注细节拆知识发布图。第四评审时连续围绕同一块内容讨论。如果大家一直追问 prompt、RAG、工具调用、模型路由就别在主图上硬解释拆机器人编排逻辑的详图。对 AI 客服来说常见的下一层图有四张会话状态和消息流转图。机器人编排与模型路由图。知识入库、索引、发布和回滚图。转人工和上下文传递图。第一张图负责建立全局。第二张图负责讲清领域。第三张图负责解释关键链路。第四张图才落到实现细节。验证关键需求是否满足这一步需要根据最开始的关键需求确认这个架构是否满足所有关键功能需求核心链路有没有遗漏一票否决的功能是否满足所有关键质量需求延迟、可用性、安全、扩展性是否可度量、可验证是否满足所有关键约束遗留系统对接、合规要求、技术栈限制是否都有明确的落点如果答案都是肯定的说明架构设计合格。如果评审中发现某个关键需求无法被满足不要试图在细化层打补丁要回退到概念架构阶段重新调整。这些问题能在图上被讨论清楚图才有价值。如果每个问题都要靠画图的人口头补充说明这张图画的还不够到位。结语第一篇讲的是骨架。分层、分域、模块、关系、支撑能力。第二篇讲的是脉搏。主链路、状态、同步边界、异常兜底、拆图策略。骨架和脉搏不是凭空来的。它们来自对关键需求的识别来自关键需求对架构的裁剪也来自其余需求对架构的验证。画架构图不是在训练大家把框画得多整齐。是在让团队把这些问题摆到桌面上业务结果是什么关键需求有哪些系统主线怎么走状态以谁为准失败时谁兜底这块谁负责如果一张图能让这些问题被讨论清楚它就有价值。如果它只是把所有系统或应用摆上去再好看也只是系统清单。下次你准备画一张技术架构图可以先不急着打开工具。先拿一条真实链路问自己用户从哪里进来系统第一跳到哪里关键需求是什么状态落在哪里失败时谁兜底其余需求能不能在这个骨架上自然生长学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】