跳到主要内容

大麦AI简历撰写指南

本文是在小伙伴学习完大麦AI项目后，教大家如何在简历中写好此项目，让面试官一眼看到你的价值点。

关于项目和简历的思考​

简历的内容​

  • 首先简历上的内容并不是越多越好，内容在于质量而不在于数量，写上去的内容自己一定要从里到外，从底层原理到细节设计再到问题的解决都要弄懂。所以建议小伙伴一定要把大麦AI项目的内容弄懂，来应对面试官的各种轰炸。

  • 把简历上的每一处内容，都要准备成属于自己的一套话术流程。当面试官问到其中一个内容时，自己能非常的有条理性和流畅地把这部分回答清楚，做到指哪打哪，哪怕面试官追问你细节，也能回答上来。

  • 大厂很看重你这个人在介绍自己的项目时，是不是逻辑清晰、有条理，问你场景问题时是不是有自己思考的过程，这样能做到的话，让人感觉你是能够胜任的。

一、技术选型​

Spring Boot 3、Spring AI、Vue 3、DeepSeek、通义千问（阿里百炼）、RAG、Function Call、MCP Protocol、SSE、Elasticsearch、Prometheus、VectorStore（向量数据库）、MyBatis-Plus、MySQL、Ollama/OpenAI

二、项目描述​

这是一个面向"购票系统智能化服务"的 AI 实战项目，基于 Spring AI 框架开发，为大麦高并发购票系统打造智能服务平台。项目集成 购票咨询助手（麦小蜜）、运维分析助手（麦小维）、规则知识库助手 三大核心能力，覆盖从用户咨询到故障排查的全场景 AI 赋能。

系统采用 多模型协同架构，对接 DeepSeek 负责对话推理，通义千问 text-embedding-v3 负责文档向量化，通过 Spring AI 统一接口实现模型切换透明化。核心技术包括：Function Call 实现业务工具自动调用（节目推荐、票档查询、订单创建）；RAG 检索增强生成 实现规则文档的智能问答与幻觉防控；MCP 协议 将日志查询、监控指标能力封装为独立工具服务；Advisor 链式架构 实现对话历史持久化、会话标题智能生成、消息窗口记忆的功能解耦；SSE 流式输出 解决大模型推理延迟的用户体验问题。

项目上线后，购票助手承接日常咨询量的 80% 以上，显著减轻客服压力；运维助手将故障排查时间从平均 15 分钟缩短到 2 分钟以内，效率提升 7 倍；同时建立了完善的 AI 可观测体系，支持 Token 消耗统计、响应延迟监控、费用估算与调用成功率追踪。

三、负责内容​

3.1 架构方面​

1. 设计多模型协同与统一接入架构​

基于 Spring AI 框架实现多模型统一接入，对接 DeepSeek、通义千问、Ollama、OpenAI 四类模型，DeepSeek 负责对话推理与工具调用，通义千问 text-embedding-v3 负责文档向量化。通过 Spring AI 的 ChatClient 抽象接口 实现模型切换透明化，支持按场景动态选择模型，保障系统的可扩展性与灵活性。

2. 构建 Function Call 业务工具体系​

设计并实现购票业务工具集，包括 节目推荐、节目查询、节目详情、票档查询、订单创建 五大核心功能。通过 @Tool/@ToolParam 注解 定义工具函数与参数描述，实现大模型根据用户意图 自主选择工具链，支持 多工具组合调用 完成复杂业务流程（如：推荐节目 → 查询详情 → 选择票档 → 创建订单）。

3. 设计 Advisor 链式架构实现功能解耦​

设计 ChatTypeHistoryAdvisor、ChatTypeTitleAdvisor、MessageChatMemoryAdvisor 三层 Advisor，分别处理 会话历史持久化、会话标题智能生成、消息窗口记忆。通过 order 属性 控制 Advisor 执行顺序，实现功能模块的完全解耦与灵活复用，支持按场景动态组合 Advisor 链。

4. 实现 RAG 检索增强生成系统​

构建规则文档的向量化存储和检索能力，使用 MarkdownDocumentReader 解析规则文档，通过 text-embedding-v3 模型 生成 1024 维向量，存储至向量数据库。配置 QuestionAnswerAdvisor 实现检索增强生成，检索参数 topK=8、similarityThreshold=0.3，prompt 层面增加 "禁止编造"约束 防止大模型幻觉，保障回答准确性与可信度。

5. 独立开发 MCP 日志查询工具服务​

基于 MCP Protocol（Model Context Protocol） 独立开发日志查询服务 damai-mcp-log-service，对接 Elasticsearch 日志系统。封装 getServiceList、searchLogsByKeyword、getLogsByTraceId、getLatestLogs、getErrorLogs、getLogStats、analyzeLogTrend 共 7 个工具函数，支持 关键词搜索、链路追踪、错误日志筛选、日志趋势分析 等完整运维能力。

6. 独立开发 MCP 监控指标工具服务​

基于 MCP Protocol 独立开发监控指标服务 damai-mcp-metrics-service，对接 Prometheus 监控系统。封装 getJvmMemory、getCpuMetrics、getGcMetrics、getThreadMetrics、getHttpRequestMetrics、getServiceHealthOverview 共 6 个工具函数，支持 JVM 内存、CPU 使用率、GC 状态、线程状态、HTTP 请求、服务健康概览 等全方位监控能力。

7. 实现 SSE 流式对话输出优化​

基于 SSE（Server-Sent Events） 技术实现 AI 回复的流式输出，使用 Flux 响应式流 处理大模型返回内容，配合前端逐字渲染实现 打字机效果。解决大模型推理延迟导致的用户等待问题，首字节响应时间优化到 1 秒以内，显著提升用户交互体验。

8. 设计会话管理与多轮对话记忆机制​

基于 MessageWindowChatMemory 实现多轮对话上下文管理，支持 20 轮对话历史 的窗口式记忆，超出窗口的历史消息自动总结压缩，避免 Token 超限。结合数据库持久化，实现会话列表管理、历史会话恢复、会话标题智能生成等完整会话生命周期管理。

9. 构建 AI 可观测与调用追踪体系​

设计 AI 调用的全链路可观测能力，追踪监控每一次 AI 调用的关键指标：输入 Token、输出 Token、总 Token 消耗、响应延迟、费用估算、调用成功率。支持 今日概览、按类型统计、最近调用记录、会话统计详情 等多维度数据分析，为模型调优与成本控制提供数据支撑。

10. 基于 Spring Boot 自动装配设计通用组件​

利用 Spring Boot 自动装配机制 封装 AI 相关组件，包括 参数类型转换器、基础数据表配置、分页封装工具、基础数据初始化、HTTP 封装调用 等通用能力，实现"配置 → 注入 → 使用"的标准化接入流程，降低业务代码侵入性。

3.2 业务方面​

1. 购票助手（麦小蜜）- 全流程购票服务​

设计并实现面向普通用户的购票智能助手，支持 节目推荐、节目咨询、票档查询、下单购买 全流程服务。用户通过自然语言描述需求（如"我想在北京看周杰伦的演唱会"），AI 自动调用工具查询节目、展示票档、引导收集购票信息（手机号、证件号、票档、数量），最终调用订单服务完成购票闭环。设计安全防护 prompt 规则，防止用户通过 prompt 注入 绕过业务限制。

2. 运维助手（麦小维）- 智能故障排查​

设计并实现面向运维人员的智能分析助手，整合 日志查询、分布式链路追踪、监控指标分析 三大核心能力。运维人员无需在多个系统间来回切换，直接通过自然语言发起查询（如"帮我查一下 order-service 最近的错误日志"），AI 自动调用 MCP 工具服务执行查询，返回结构化结果并给出智能分析建议。

核心能力：

  • 日志智能检索：支持按服务名、关键词、日志级别、时间范围多维度搜索日志，快速定位异常日志记录
  • 分布式链路追踪：基于 traceId 追踪完整的跨服务调用链路，一次查询即可展示请求经过的所有微服务节点、每个节点的日志详情、调用耗时与执行顺序，清晰呈现分布式系统中请求的完整流转路径，快速定位链路中的故障节点
  • 监控指标分析：实时查询 JVM 内存使用、CPU 使用率、GC 状态、线程池状态、HTTP 请求指标，AI 自动分析指标异常并给出优化建议
  • 服务健康概览：一键获取所有微服务的运行状态、资源使用情况与健康评分

典型排查场景：

  1. 运维收到"order-service 接口超时"告警后，直接询问麦小维，AI 先查询错误日志发现是调用 pay-service 超时
  2. 然后 根据 traceId 追踪完整调用链路，展示请求从 gateway → order-service → pay-service 的完整路径与每个节点的耗时
  3. 最后查询 pay-service 的 JVM 指标发现堆内存使用率 90%，综合分析后给出"pay-service 内存不足触发 Full GC 导致响应超时"的结论与重启建议
  4. 整个排查过程从传统的 15 分钟缩短到 2 分钟，效率提升 7 倍。

3. 规则助手 - RAG 知识库智能问答​

基于 RAG 技术实现规则知识库问答能力，将 节目购买规则、儿童票规则、节目转让规则、德云社规则、节目取消规则、节目退票规则、退票到账规则、门票作废规则 等 8 类规则文档向量化入库。用户咨询政策类问题时（如"演唱会能退票吗"），系统先从向量数据库检索相关文档片段，再结合 prompt 约束生成准确回答，知识检索准确率 85%+，有效解决大模型幻觉问题。

4. 会话标题智能生成与列表管理​

利用 AI 自动根据首轮对话内容生成 简洁准确的会话标题，便于用户识别和管理历史会话。设计会话列表管理功能，支持 创建新会话、切换历史会话、删除会话，每个会话维护独立的对话历史和上下文，实现多任务并行处理。

5. 多场景 ChatClient 差异化配置​

针对 贴心助手、运维助手、规则助手 三个场景，设计差异化的 ChatClient 配置：贴心助手配置 Function Call 工具集与用户友好型 prompt；运维助手配置 MCP 工具服务与专业分析型 prompt；规则助手配置 RAG Advisor 与禁止编造约束。通过场景隔离保障各助手的专业性与安全边界。

6. RAG 召回率优化与混合检索​

针对 RAG 检索召回率低的问题，实施多项优化措施：调整文档分块策略（语义段落切分替代固定长度切分）、优化向量检索参数（topK 从 5 调整到 8、similarityThreshold 从 0.5 降到 0.3）、增加元数据增强（为文档片段添加标题、分类等结构化信息）、实验混合检索（向量检索 + 关键词检索双通道融合），最终将召回率从 65% 提升到 85%。

四、项目亮点总结​

4.1 技术架构亮点​

  1. 多模型协同架构 — DeepSeek 推理 + 通义千问向量化，Spring AI 统一接口实现模型切换透明化
  2. Function Call 业务闭环 — @Tool 注解定义工具，大模型自主选择工具链，多工具组合完成复杂业务
  3. Advisor 链式架构 — 三层 Advisor 解耦会话历史、标题生成、消息记忆，order 属性控制执行顺序
  4. RAG 检索增强生成 — 向量相似度检索 + prompt 禁止编造约束，知识检索准确率 85%+
  5. MCP 协议工具服务化 — 日志服务 7 个工具 + 监控服务 6 个工具，独立部署、即插即用
  6. SSE 流式输出 — Flux 响应式流处理，首字节响应 1 秒内，打字机效果提升体验
  7. AI 可观测体系 — Token 消耗、响应延迟、费用估算、成功率全链路追踪
  8. 会话生命周期管理 — 20 轮窗口记忆 + 历史压缩 + 数据库持久化，完整会话管理闭环
  9. 安全防护机制 — prompt 注入防护、工具调用权限控制、场景隔离安全边界
  10. Spring Boot 自动装配 — 组件化封装，配置 → 注入 → 使用标准化流程

4.2 业务价值亮点​

  1. 客服效率提升 — 购票助手承接 80%+ 日常咨询，显著减轻客服压力
  2. 故障排查提速 — 运维助手将排查时间从 15 分钟缩短到 2 分钟，效率提升 7 倍
  3. 知识库激活 — RAG 让规则文档真正被用起来，用户问答即得准确答案
  4. 用户体验优化 — 流式输出 + 多轮对话 + 会话管理，AI 交互自然流畅
  5. 运维无人值守 — AI 24 小时响应，夜间告警秒级处理，降低人工介入成本
  6. 购票全流程自动化 — 从推荐到下单全链路 AI 引导，提升购票转化率
  7. 成本可控可观测 — Token 消耗与费用可追踪，支撑模型选型与成本优化决策
  8. 可扩展工具体系 — MCP 服务独立扩展，新增工具零侵入主服务

五、面试话术建议​

5.1 当面试官问"简单介绍一下你的项目"时​

回答示例：

"这个项目是大麦购票系统的 AI 智能助手，解决的是购票咨询和运维效率两个痛点。购票系统每天要处理大量用户咨询，很多问题都是重复的，比如'还有票吗'、'怎么退票'，客服压力很大。运维这边也是，排查一个问题要在日志系统、监控系统之间来回切换，效率很低。

所以我们做了三个 AI 助手：购票助手麦小蜜帮用户查节目、买票；运维助手麦小维帮运维查日志、看监控；规则助手用 RAG 技术回答政策类问题。技术栈是 Spring Boot + Spring AI + Vue，对接了 DeepSeek 和通义千问大模型，用 MCP 协议封装了日志查询和监控查询的工具服务。

上线后效果挺明显，购票助手能处理 80% 以上的日常咨询，运维助手把故障排查从十几分钟缩短到两分钟。"

5.2 当面试官问"为什么选择 Spring AI 而不是 LangChain"时​

回答示例：

"这个要从实际情况来分析。首先我们是 Java 团队，用 Spring 生态，Spring AI 是 Spring 官方的 AI 框架，和 Spring Boot 无缝集成，不用引入新的技术栈。其次 Java 是强类型语言，Spring AI 的接口设计也是强类型的，定义工具函数时参数类型在编译期就确定了，不会出现运行时类型错误。另外 Spring 生态经过多年验证，稳定性有保障。Spring AI 提供了 VectorStore 抽象接口、ChatMemory 实现、Advisor 机制，可以灵活扩展。如果是 Python 团队或者需要快速原型验证，LangChain 可能更合适。"

5.3 当面试官问"MCP 是什么、为什么要用 MCP"时​

回答示例：

"MCP 全称 Model Context Protocol，是 Anthropic 提出的一个开放协议，用于标准化大模型与外部工具/数据源的交互方式。它定义了工具的发现、调用、结果返回的标准格式，让工具服务可以独立部署、独立扩展。

我们选择 MCP 主要是解耦的考虑。运维工具涉及到 ES 和 Prometheus，逻辑比较复杂，如果直接写在主服务里代码会很臃肿。用 MCP 把工具抽成独立服务，主服务不用关心工具的实现细节。另外同一套工具服务可以被多个 AI 服务复用，比如以后其他团队要用日志查询能力，直接调用就行。而且 MCP 是业界标准协议，换框架、换模型工具服务不用改。"

5.4 当面试官问"SSE 和 WebSocket 有什么区别、为什么选 SSE"时​

回答示例：

"SSE 和 WebSocket 都可以实现服务端推送，但适用场景不同。WebSocket 是全双工通信，客户端和服务端都可以主动发消息，适合聊天室、游戏这种双向交互场景。SSE 是单向推送，只能服务端向客户端推，基于 HTTP 协议实现，不需要额外的握手升级。

我们的场景是 AI 生成回复逐字推送给前端，典型的单向推送，不需要双向通信。SSE 实现更简单，不需要处理连接管理、心跳这些问题，浏览器原生支持。如果以后有双向通信需求，比如用户可以中途打断 AI 回答，可以考虑切换到 WebSocket。"

六、项目价值总结​

  1. AI 落地能力全面 — Function Call 业务执行、RAG 知识问答、MCP 运维分析、Advisor 链式架构
  2. 多场景覆盖 — 购票咨询、故障排查、规则问答，从用户到运维全链路 AI 赋能
  3. 工程化程度高 — 组件化封装、可观测体系、安全防护、会话管理，生产级可用
  4. 可扩展性强 — MCP 工具即插即用、Advisor 灵活组合、多模型透明切换
  5. 效果可量化 — 80% 咨询分流、7 倍效率提升、85% 检索准确率

七、使用建议​

  1. 简历中的项目描述 — 控制在 200 字左右，突出 Spring AI、RAG、Function Call、MCP 等核心关键词
  2. 负责内容 — 选择 4-6 个你最熟悉的架构亮点展开，务必能深入讲解技术原理
  3. 熟悉面试话术 — 准备好对 RAG、Function Call、MCP、SSE、Advisor 的深入追问
  4. 准备量化数据 — 80% 咨询分流、7 倍效率提升、85% 检索准确率的计算依据
  5. 技术深度 — 能够解释每个技术方案背后的原理和为什么要这样设计

八、注意事项​

  1. 根据真实参与度调整措辞，切勿全量复制
  2. 不熟悉的技术点提前补课，能解释设计动机与权衡
  3. 强调"问题—方案—效果"的闭环，避免只罗列技术名词
  4. 技术名词要准确：Spring AI（不是 Spring-AI）、Function Call（首字母大写）、RAG（全大写）、MCP（Model Context Protocol）
  5. 数字要真实可解释，编的数字经不起追问
🎁优惠