面试准备材料合集

AI+消费产品技术负责人 · 系统化面试备战指南

📌 目标岗位：AI+消费产品技术负责人 🎯 核心方向：LLM Agent × 交易闭环 📅 更新日期：2026年5月

🎯

岗位画像与关键词分析

来源：01_岗位画像与关键词分析.md

🎯 目标岗位画像与关键词匹配分析

岗位基本信息

维度	内容
岗位名称	技术团队负责人 / AI+消费产品技术负责人
公司类型	AI 创业公司（已有成熟 C 端交易业务 + 千万级用户底盘）
核心方向	LLM Agent × 交易闭环
业务特点	AI 驱动供需匹配与商品结构化，技术空间大、落地即见效

一票否决项（必须具备）

技术团队管理经验 — 不是纯执行者，要能带团队
LLM/Agent 实战落地能力 — 不只是用过 API，要有完整工程化经验
创业视角 / 创业经历 — 能参与商业决策，对结果负责

核心硬技能关键词（按优先级排序）

优先级	关键词	JD原文对应	你的匹配度
P0	LLM Agent	“LLM Agent × 交易闭环”	✅ TripPlan 三阶段 Agent 工作流 + Function Calling
P0	交易闭环设计	“AI驱动供需匹配”	✅ TripPlan 完整支付+订单状态机闭环
P0	技术团队管理	“全面负责…研发管理”	✅ 携程20人团队 + 创业公司3人团队 + SGS 10人团队
P1	高并发/高可用	“保障系统高并发、高可用”	✅ 千万级订单系统重构(100万→1000万+)，99.99%可用性
P1	架构设计	“技术架构与研发管理”	✅ 微服务拆分、DDD模块划分、分库分表
P1	从0到1	“推动…落地与迭代”	✅ IoT平台0→1 + TripPlan 0→1 + 国际业务0→1
P2	RAG/知识库	“商品结构化”	✅ AI 智能客服系统 RAG 知识库问答(LlamaIndex+Qdrant)
P2	Python/FastAPI	(隐含：AI项目主流栈)	✅ 两个AI项目均使用 Python/FastAPI
P2	供需匹配算法	“AI驱动供需匹配”	✅ TripPlan 约束求解引擎(时间/地理/预算三层校验)

核心软实力关键词

关键词	说明	你的支撑证据
创业视角	能参与产品和商业决策	创业公司技术合伙人经历；TripPlan 从PRD到代码全链路决策
结果导向	对技术结果负责	CEO大奖；抢票市场占有率第一；订单系统性能提升10倍
技术战略规划	主导技术方向制定	.NET→Java转型；国际业务从0到1；IoT平台架构选型
跨领域融合	AI + 传统交易系统结合	12年Java后端 + 2个AI项目的跨栈实践

你的独特竞争优势（差异化卖点）

卖点1：稀缺的「大厂高并发 × AI Agent实战」复合背景

绝大多数人要么只有大厂后端经验（不懂AI），要么只有AI demo经验（不懂生产系统）
你同时拥有携程千万级订单系统的架构经验和两个完整的AI Agent工程项目
这意味着你既懂如何构建高可用的交易系统，又懂如何在其中嵌入LLM能力

卖点2：真正的「Agent × 交易闭环」实践经验

JD的核心诉求是”LLM Agent × 交易闭环”
大多数候选人只能讲RAG问答或Chatbot
你有TripPlan这个真正走到支付环节的Agent交易系统——11状态订单机、Stripe支付、动态定价引擎、约束求解器
这是JD最看重的匹配点，必须在简历和面试中反复强调

卖点3：技术合伙人级别的创业视角

JD明确要求”有一定的创业经历或者创业视角”
你有两次创业/类创业经历：

  - 共享智能运营平台：作为**技术合伙人**从0到1搭建，月流水破百万
  - TripPlan：独立完成PRD→架构→代码的全过程决策

这让你能以”合伙人思维”而非”执行者思维”参与讨论

简历优化策略总览

策略1：重排项目顺序——把AI项目前置

旧简历问题：AI项目被埋在最后或不突出
优化方案：工作经历中把最近的AI相关项目放在最显眼位置，每个项目描述中融入JD关键词

策略2：用JD语言重写项目描述

把”行程规划系统”改写为”LLM Agent驱动的交易闭环SaaS”
把”智能客服平台”改写为”生产级多渠道AI Agent客服系统”
在每个项目中自然植入：Agent、Function Calling、交易闭环、供需匹配、约束求解等关键词

策略3：强化”技术负责人/合伙人”身份

每段经历都强调”主导”、”负责”、”带领团队”
用数据量化管理成果（团队规模、交付周期、成本节省）
展示参与产品和商业决策的能力

策略4：个人优势看板重新定位

旧版偏传统后端 → 新版聚焦”AI + 高并发交易 + 技术领导力”三位一体

📄

优化后简历

来源：02_优化后简历.md

吴来

技术负责人 / AI+交易架构师 | 12+年经验 | 6+年技术团队管理 | LLM Agent 架构设计与工程化实践

电话： 159*9141 | *邮箱： wla****@163.com

核心优势

AI Agent × 交易闭环架构设计：主导两个 LLM Agent 商业项目的架构设计与工程落地 — TripPlan（Function Calling + 约束求解 + Stripe 支付闭环）和 AI 智能客服系统（RAG + MCP + 多渠道接入），具备「对话→决策→支付」端到端 Agent 产品设计能力。
千万级交易系统架构底盘：主导携程火车票订单系统重构，日均订单峰值 100 万→1000 万+，可用性 99.99%；抢票系统市场占有率第一，获集团 CEO 大奖。
技术领导力 × 创业决策力：6 年研发管理（最大团队 20+人），两次技术合伙人经历（IoT 平台 0→1 月流水破百万，AI SaaS 0→1 独立架构设计与落地），能参与产品与商业方向决策。
AI 增强工程实践：熟练运用 AI Coding 工具（Cursor / Trae）加速工程落地，在保持架构决策权的同时大幅提升交付效率。Java 微服务生态 + Python AI 技术栈双修，能将 AI 能力嵌入传统交易系统。

教育背景

东华理工大学 | 软件工程 | 本科（2007.09 - 2011.07）
成绩优异，提前一年毕业，GPA 4.0，多次荣获国家励志奖学金及一等奖学金。

工作经历

创业经历 | 技术负责人/技术合伙人 `2024.10 - 至今`

创业期间主导/参与三个从 0 到 1 的商业项目，覆盖 IoT 共享平台、LLM Agent 行程规划、AI 智能客服三个方向。

共享设备智能运营平台（技术合伙人）

从 0 到 1 打造 IoT 共享平台，对公司技术战略与研发交付负责。

设计 IoT 云平台架构，基于 Netty 自研设备接入层（TCP 长连接 + Protobuf），支撑海量设备连接，设备在线率 99.5%
设计在线支付分账系统，上线一年接入设备 500 台，月流水突破 100 万，验证商业模式
带领 3 人研发团队建立轻量级敏捷流程，实现每周迭代发布

TripPlan — AI 定制游行程规划 SaaS（LLM Agent × 交易闭环）

Python FastAPI(异步) PostgreSQL LLM(Function Calling) Stripe DDD

面向入境游市场，用 LLM Agent 替代旅行社人工行程规划（传统需 2-5 天），实现「自然语言对话→结构化方案→在线支付」端到端闭环。

架构设计：从 0 到 1 采用 DDD 领域驱动设计，拆分为需求收集、行程引擎、约束求解、定价服务、订单状态机、支付适配器等 9 个核心模块。

LLM Agent 三阶段工作流：
1. 需求收集 — LLM NLU 提取结构化用户画像（人数/日期/偏好/预算）
2. 行程规划 — Function Calling 调用后端资源查询 + 约束校验 + 报价接口，生成带分项报价的多日行程
3. 迭代优化 — 接收用户反馈→重新生成，形成闭环

核心设计哲学：LLM 负责理解和创意，代码负责价格/状态/资金安全。

约束求解引擎：设计三层校验 — 时间重叠检测（Segment 排序扫描 O(nlogn)）、按交通方式差异化转移缓冲（步行/包车/地铁）、预算超支检测；输出结构化违规报告供 Agent 自修正。

动态定价引擎：设计「基准价格 × 季节系数 × 数量」公式，支持跨年季节区间、6 类资源分项计价（景点/酒店/包车/导游/交通/餐饮）、USD/EUR/CNY 多币种转换。

交易闭环：设计 11 状态严格有向图订单状态机（Draft → Confirmed → DepositPaid → Reviewing → Completed/Cancelled → Refunded），Adapter 模式对接 Stripe PaymentIntent + Webhook，支持预付款 30% + 尾款两段式支付。全量自动化测试覆盖核心算法。

AI 智能客服系统（多渠道 Agent 平台）

Python FastAPI LlamaIndex Qdrant(BGE) RAG MCP Redis PostgreSQL

面向企业场景的 LLM + RAG 智能客服，支持 Web + 飞书双渠道接入。

意图路由：设计规则引擎 + LLM 双层路由，覆盖 KB 问答/插件调用/人工转接/闲聊四类意图，置信度阈值 + fallback 降级
RAG 检索：设计 LlamaIndex IngestionPipeline（SentenceSplitter + BGE Embedding + Qdrant 向量存储），语义召回 + Compact 模式生成
LLM 网关：设计本地模型/API 双模式网关，OpenAI 兼容协议，超时重试 + 降级
弹性体系：设计 Token Bucket 四层限流（全局/用户/会话/渠道）+ Circuit Breaker 熔断，OpenTelemetry 全链路 TraceId 传递
工程化：Protocol 协议编程 + 依赖注入解耦，Docker Compose 一键部署，GitHub Actions CI

SGS（通标标准技术服务有限公司）| 技术经理 `2024.05 - 2024.10`

主导企业级数字化项目架构升级，引入 DDD 重构核心模块，新业务接入成本降低约 30%
管理 10 人研发团队，建立 Code Review 和技术分享机制，交付周期缩短 20%

携程计算机技术有限公司 | 资深研发经理 `2012.04 - 2024.01`

负责火车票预订、订单、数据、国际业务等核心团队，团队规模从 5 人扩至 20+人。

订单系统重构（千万级）：主导微服务 + 分库分表方案（8 库 + 读写分离），引入订单状态机 + 消息队列解耦，日均订单峰值从 100 万→1000 万+，可用性 99.99%
抢票系统（CEO 大奖）：独立设计任务分级 + 多引擎并发抢票策略，联动余票监控实现预测与任务合并，助力市场占有率第一，获集团年度 CEO 大奖
全自动出票系统：设计多引擎互备方案（出票服务 + 调度服务 + 爬虫服务），出票成功率行业领先，年均为公司节省数百万运营成本
Global Rail GDS 国际化：组建团队从 0 到 1 研发集成中英法德等多国铁路产品的国际分销系统，成功对接多家海外供应商
动态缓存策略：设计”主动+被动”分级缓存（热数据主动推送、冷数据被动拉取），热门线路查询秒级→毫秒级，节省 60% Redis 资源
技术转型：主导核心团队 .NET → Java 栈平滑迁移

中国金融在线 | 高级开发工程师 `2011.06 - 2012.04`

参与集团金融数据基础平台建设与研发。

核心技能

类别	技能
AI/LLM	LLM Agent 架构设计、Function Calling、RAG（LlamaIndex + Qdrant + BGE）、Prompt Engineering、MCP 协议、意图路由、幻觉控制策略
AI 增强工程	AI Coding 工具链（Cursor / Trae / Claude Code）、Vibe Coding 工作流、AI 辅助架构设计与代码生成
后端开发	Java（Spring Boot / Spring Cloud / MyBatis）、Python（FastAPI 异步 / SQLAlchemy async / Pydantic v2）
架构设计	微服务、DDD 领域驱动设计、分库分表、读写分离、状态机设计、Adapter 模式、Protocol 协议编程
数据与中间件	MySQL / PostgreSQL、Redis、Elasticsearch、Qdrant（向量数据库）、Netty（TCP 长连接）
支付与交易	Stripe（PaymentIntent + Webhook）、订单状态机、动态定价引擎、分账系统
工程与运维	Docker Compose、Nginx、CI/CD（GitHub Actions）、OpenTelemetry 全链路可观测

🎤

自我介绍（多版本）

来源：03_自我介绍_多版本.md

面试自我介绍（针对 AI+消费产品技术负责人岗位）

使用说明：根据面试官身份和场景选择对应版本，理解逻辑后用自己的话讲，不要背稿

版本一：标准版（2 分钟，最常用 — 推荐 HR/技术主管一面）

面试官好，我是吴来。

我做了 12 年后端开发，其中 6 年多在带团队。我的背景其实挺有意思的——前 12 年都在携程做 Java 高并发交易系统，这两年开始往 AI Agent 方向转，做了两个完整的项目。

最近这个项目叫 TripPlan，跟咱们 JD 里说的「LLM Agent × 交易闭环」特别契合。简单说就是帮海外游客定制中国行程，传统旅行社要 2-5 天，我们用 AI 把它压缩到分钟级。

这个项目我作为技术负责人，主要做了几件事：

一个是设计了整个 Agent 的交易闭环。用户用自然语言描述需求，Agent 通过 Function Calling 调后端接口，完成需求提取、资源匹配、约束校验、报价，最后直接 Stripe 支付。从对话到付款，AI 全程驱动——这不是 demo，是真实有支付链路的商业系统。

另一个是做了个供需匹配引擎。用户需求是 LLM 从自由文本里提取的结构化画像，供给端是 6 类旅游资源，中间用约束求解器做匹配——时间合不合理、距离来不来得及、预算超不超标，不满足就自动调整。这跟 JD 里说的「AI 驱动供需匹配」思路是一样的。

还有一个完整的交易基础设施——11 个状态的订单状态机、动态定价引擎、Adapter 模式的支付层，这些我都搭好了。

另外还有个 AI 智能客服系统，RAG 知识库问答、意图路由、MCP 插件、多渠道接入，这些能力都有。

说实话，这两个 AI 项目的架构设计、模块划分、核心算法都是我主导的，工程落地我用了 AI Coding 工作流——用 AI 工具放大执行效率，一个人干了传统 3-4 人的活。我的主栈是 Java，AI 项目选 Python 是因为 LLM 生态需要，架构设计能力是跨语言的。

在携程那 12 年，我做过火车票订单系统重构，日均订单从 100 万干到 1000 万+；抢票系统做到市场占有率第一，拿了集团 CEO 大奖；还从 0 到 1 做了国际火车票 GDS。这段经历让我对千万级用户底盘的高并发、高可用架构有了很深的理解。

另外我还有两次创业经历——一次是技术合伙人做 IoT 共享平台，月流水破百万；一次就是独立做 TripPlan。这些经历让我能参与产品和商业决策，不只是纯执行。

如果加入咱们团队，我觉得我的 Agent 交易闭环设计经验、千万级系统架构能力、加上技术合伙人思维，应该能快速迁移到咱们的 AI+消费产品里。

版本二：精简版（1 分钟，时间紧 / 快速轮次时用）

面试官好，我是吴来，12 年 Java 后端，6 年带团队。

我的背景就两个标签：一个是高并发交易系统架构——携程千万级订单、CEO 大奖的抢票项目；另一个是 LLM Agent 架构设计——两个完整的 Agent 工程项目。

最近的核心项目叫 TripPlan，LLM Agent 驱动的行程规划加在线交易 SaaS，跟咱们「LLM Agent × 交易闭环」的方向完全匹配。

我作为技术负责人，设计了 Agent 三阶段工作流、AI 供需匹配引擎、还有完整的交易基础设施——11 状态订单机、动态定价、Stripe 多币种支付。另外还有个生产级 AI 智能客服系统。

两个 AI 项目的架构和技术决策都是我主导的，工程落地用 AI Coding 工作流提升效率。我的主栈是 Java，AI 项目用 Python 是生态需要，架构设计能力跨语言可迁移。

之前携程 12 年，带过 20+ 人团队，做过千万级订单重构和国际业务 0-1。还有两次技术合伙人级别的创业经历。

我觉得自己的核心价值就是：大厂高并发系统的工程功底，加上 AI Agent 落地的架构设计经验——这应该是咱们岗位最需要的复合能力。

版本三：突出创业视角版（面对创始人/CEO/CTO — 强烈推荐）

面试官好，我是吴来。

我看了咱们 JD，「已有成熟 C 端交易业务 + 千万级用户底盘」「LLM Agent × 交易闭环」「AI 驱动供需匹配」——我觉得跟我目前的经验和方向挺匹配的。

说个判断：我觉得咱们公司现在的阶段，需要的不是只会调 API 的 AI 工程师，也不是只懂传统后端的架构师，而是能把这两者结合起来、还有创业视角的人。

为什么这么说？因为 LLM Agent 要在交易场景真正落地，会碰到三个层面的挑战：

工程层面——怎么让不确定性的 LLM 输出驱动确定性的交易流程？价格不能算错、状态不能乱跳、资金不能出错。

产品层面——Agent 的能力边界在哪？哪些环节适合 AI 做，哪些必须保留人工？

商业层面——AI 落地怎么衡量 ROI？投入产出比怎么算？

这三个问题，我在最近的项目里都实际碰到过，也给出了方案。

比如 TripPlan 项目，我把 LLM 和确定性后端做了明确分工——LLM 负责理解和创意，代码负责精确和安全。两者通过 Function Calling 桥接。这就是对第一个问题的回答。

设计 11 状态订单机加人工审核双通道，就是对第二个问题的回答——自动化到什么程度、哪里需要人工兜底，架构层面就考虑清楚了。

第三个问题，我在创业公司做技术合伙人时深度参与过商业模式讨论——月流水怎么算、预付款比例为什么设 30%、审核流程怎么平衡效率和风控。这些不是纯技术决策，但技术负责人必须参与。

在携程 12 年，从一线开发做到带 20+ 人的研发经理。这段经历给了我两样东西：一个是对大规模交易系统的直觉——千万级订单怎么扛、99.99% 可用性怎么保；另一个是带团队打硬仗的经验——资源有限时怎么做正确的 trade-off。

还有一点我想坦诚说：我的主技术栈是 Java，AI 项目选 Python 是因为 LLM 生态需要。工程落地我用了 AI Coding 工作流——架构设计和技术决策我主导，AI 工具辅助代码实现。这种方式在创业场景下特别高效，一个人能完成传统 3-4 人的工作量。如果加入咱们团队，Java 主业务系统我可以直接上手，AI 模块的架构设计也是我的强项。

我希望加入咱们团队后，不只是写代码或管排期，能在技术战略、Agent 落地路径、产品与技术决策上贡献更多。我对”对结果负责”这句话是有真实体感的。

版本四：技术深度版（面对纯技术型面试官 / CTO）

面试官好，我是吴来。

我的技术经历分两条线：一条是高并发交易系统，Java 栈，做了 12 年；另一条是 LLM Agent 架构设计与工程化落地，这两年做的。

高并发这块，携程 12 年，最有代表性的三个系统：

订单中心微服务重构——老单体扛不住了，我主导拆成 8 个子系统，按订单号分 8 库加读写分离，消息队列解耦。日均订单从 100 万干到 1000 万+，可用性 99.99%。

抢票系统——设计了任务分级加余票预测的多引擎并发策略，跟爬虫资源调度联动。典型的资源受限场景下的调度优化问题。

数据系统缓存优化——“主动+被动”结合的动态刷新策略，热门线路查询从秒级降到毫秒级，省了 60% Redis 资源。核心思路是按数据新鲜度要求分级，热数据主动推、冷数据被动拉。

AI Agent 这块，近两年做了两个项目。我的主栈是 Java，AI 项目选 Python 是因为 LLM 生态——LlamaIndex、Function Calling SDK 这些在 Python 上更成熟。架构设计和技术决策我主导，工程落地用 AI Coding 工作流辅助——我定义接口、设计算法、做技术选型，AI 辅助代码实现，我负责 Review 和验收。

TripPlan 这个项目，DDD 九模块划分，模块边界和依赖关系我设计的。Agent 三阶段工作流，LLM 和确定性代码的职责边界我定义的。核心算法——约束求解器、定价引擎、状态机——都是我设计的。关键决策就是：LLM 只负责理解和创意，价格、状态、资金全部由确定性代码保证。

AI 智能客服这个项目，RAG 链路、意图路由、四层限流加熔断器、Protocol 协议编程加依赖注入，这些架构设计都是我做的。

我的核心能力是架构设计和交易系统。技术栈上 Java 是深度、Python 是广度。AI 工程化落地的关键不在于手写多少 Python 代码，而在于怎么把 LLM 能力可靠地嵌入现有系统——架构决策、模块边界、状态机设计、约束求解算法，这些是跨语言的。而且用 AI Coding 工作流后，Python 工程落地效率已经不是瓶颈了。

如果加入咱们团队，Java 主业务系统我可以直接深度参与，AI 模块的架构设计和技术决策是我的强项，Python 工程落地可以继续用 AI Coding 工作流高效推进。

自介绍使用指南

场景	推荐版本	时间
HR/BP 初筛面	版本一（标准版）	~2 分钟
时间紧张 / 快速轮次	版本二（精简版）	~1 分钟
创始人/CEO/CTO 面谈	版本三（创业视角版）	~2-3 分钟
纯技术深度面（CTO/架构师）	版本四（技术深度版）	~2-3 分钟

介绍的黄金结构

1. 我是谁 + 一句话定位（15秒）     ← 用JD关键词锚定，强调Java主栈
2. AI Agent项目（核心卖点）（60秒）   ← 重点！强调架构设计+交易闭环
3. 大厂高并发经验（背书）（30秒）    ← 证明你能搞定千万级系统
4. 创业视角（差异化）（30秒）        ← 证明你有合伙人思维
5. 收尾连接（15秒）                 ← "这与贵司XX方向很契合"

⚠️ 常见错误

❌ 一上来报菜名列举技术栈（HR 不关心你用过多少框架）
❌ 花 1 分钟讲携程历史（面试官更关心你的 AI 能力）
❌ 不提 TripPlan 的交易闭环（这是 JD 第一匹配点）
❌ 把自己包装成 Python 全栈（面试官一问 Python 细节就露馅）
❌ 超过 3 分钟（注意力窗口有限）
✅ 开头用 JD 的原话建立连接（”LLM Agent × 交易闭环”）
✅ TripPlan 至少占介绍内容的 50%
✅ 主动说明 Java 主栈 + AI Coding 辅助 Python 落地（坦诚 = 自信）
✅ 每个亮点都有数字支撑（9 模块、11 状态、3 层约束、1000万+订单）

💬

高频 Q&A 话术库

来源：04_高频Q&A话术库.md

高频面试 Q&A 话术库（针对 AI+消费产品技术负责人岗位）

使用说明：每个问题按「考察意图 → 回答策略 → 标准回答」组织
标注 ⭐ 的为最高频必考题，⚡ 的需要能展开讲技术细节

一、AI Agent 与交易闭环类（JD 核心方向，必考）

Q1: 请重点介绍一下你的 TripPlan 项目？ ⭐⭐⭐⭐⭐

考察意图：判断你的 AI Agent 实战深度、是否真正做过”对话到支付”的闭环

回答策略：按「背景痛点 → 方案架构 → Agent 设计 → 交易闭环 → 你的角色」展开

标准回答：

“TripPlan 是个面向中国入境游市场的 LLM Agent 行程规划加在线交易 SaaS 平台。

先说背景和痛点——海外游客来中国想定制行程，传统旅行社要 2-5 天人工处理：销售收集需求、查资料排行程、算报价、来回沟通修改。时间长、成本高、体验差。

我们的方案是用 LLM Agent 替代人工环节。用户用自然语言描述需求，AI 自动提取信息、匹配资源、生成行程方案、算报价。用户确认后在线付预付款，旅行社后台审核后跟进服务。

Agent 架构这块是最核心的，我设计了三阶段工作流：

阶段一是需求收集。用户用自由文本描述，比如’我想带家人来中国玩 7 天，喜欢历史文化，预算大概 5000 美元’。LLM 通过 NLU 提取结构化的 TravelerProfile——出行人数、日期范围、兴趣标签、预算区间、特殊需求这些。信息不足的话，Agent 会主动追问，就像有经验的销售在引导客户。

阶段二是行程规划。拿到结构化画像后，Agent 通过 Function Calling 调后端接口：查询可用资源、调用约束求解器校验可行性、调用定价引擎算报价、生成完整的行程方案加报价单。

阶段三是迭代优化。用户反馈’第二天太累了’或’能不能便宜点’，Agent 理解后重新生成方案，最多迭代 5 次。

交易闭环这块是跟纯 Chatbot 项目的本质区别。方案确认后，用户付 30% 预付款（Stripe），订单进人工审核，审核通过后进服务履约，结束后付尾款。

整个流程我做了几个关键决策：LLM 和确定性代码分工——LLM 负责理解和创意，但价格计算、状态管理、约束校验、资金操作全部由确定性代码保证；Function Calling 作为桥梁——LLM 不直接操作数据库或调支付 API；约束求解器作为硬守卫——不满足约束的方案不允许输出，防止 Agent 一本正经地胡说八道。

我的角色——从 PRD 讨论、架构设计到核心算法实现和全量测试，我是这个项目的技术负责人。”

Q2: LLM Agent 在交易场景中落地，最大的技术挑战是什么？你怎么解决的？ ⭐⭐⭐⭐⭐

考察意图：判断你是否真的在生产环境中用过 LLM，还是只做过 demo；对 Agent 工程化难点的理解深度

标准回答：

“我觉得最大的挑战是怎么让不确定性的 LLM 输出可靠地驱动确定性的交易流程。具体来说有三个层面：

第一层是幻觉控制——Agent 不能编造数据。

在 TripPlan 里，资源（景点、酒店、价格）只能从数据库查询结果里选，LLM 绝不能凭空创造。我的解决方案是：Function Calling 返回的资源列表来自数据库真实查询；定价计算由 PricingService 执行，LLM 只负责展示结果；约束求解器作为硬守卫，违规方案直接拦截；Prompt 里明确要求’如果没有相关信息请诚实说明’。

第二层是状态管理——订单状态不能乱跳。

我设计了 11 个状态的严格有限状态机：Draft → Confirmed → Deposit Paid → Reviewing → Approved → In Service → Completed，还有取消分支 Cancelled → Refunding → Refunded，以及审核调整分支 Major Adjustment 需要重新确认。每个状态只允许跳到预定义的下一状态，用字典映射实现 O(1) 判断。所有合法和非法跳转都写了测试覆盖。

第三层是资金安全——支付环节容错率极低。

支付层用 Adapter 模式解耦，Stripe 的 PaymentIntent + Webhook 异步确认模式；预付款（30%）+ 尾款两段式支付，降低单笔风险；Webhook 回调做幂等处理和签名验证；关键资金操作必须有用户明确确认，不是 Agent 自动执行。

总结一句话：我的核心思路是’LLM 做大脑，代码做脊梁’——让 LLM 发挥理解和创意的优势，把精确性、安全性、一致性交给确定性逻辑保证。”

Q3: 你怎么理解”AI 驱动供需匹配”？在你的项目中是怎么体现的？ ⭐⭐⭐⭐⭐

考察意图：JD 明确提到”AI驱动供需匹配与商品结构化”，这是必考的核心概念

标准回答：

“‘供需匹配’这个词在传统电商里通常指’把合适的商品推荐给合适的用户’，但在 LLM Agent 场景下，含义更深层：

传统供需匹配是：用户搜关键词 → 倒排索引/协同过滤 → 返回商品列表 → 用户选择。

Agent 时代的供需匹配是：用户用自然语言描述模糊需求 → LLM 理解意图并提取结构化画像 → Agent 主动查询和筛选供给端资源 → 智能组合成个性化方案 → 用户确认后完成交易。

关键区别有三点：

第一点是需求侧：从关键词到自然语言理解。
传统系统只能处理结构化输入（搜索词、筛选条件）。Agent 能理解’我想带老人小孩来中国玩，不要太累，喜欢看古迹’这种完全非结构化的表达，并通过 NLU 提取出：人群=家庭（老+小）、偏好=文化历史、约束=强度低。

第二点是匹配逻辑：从检索排序到约束求解。
传统匹配是打分排序。Agent 匹配是多维约束满足问题——我在 TripPlan 里实现了三层约束求解器：时间约束（同一天的活动不能重叠，排序扫描检测 O(nlogn)）；地理约束（相邻活动之间的转移时间要够，步行 15 分钟/包车 30 分钟/地铁 45 分钟差异化配置）；预算约束（总费用不能超过用户预算上限）。不满足约束的方案输出结构化的 Violation 报告，Agent 可以直接理解并自动修正。

第三点是供给侧：从静态商品库到可结构化的动态资源。
JD 提到的’商品结构化’非常关键。在 TripPlan 里我把旅游资源定义为 6 类结构化实体（景点/酒店/包车/导游/大交通/餐饮），每类都有标准化属性（价格、位置、营业时间、容量等）。这意味着 Agent 可以按统一 schema 查询和组合不同类型的资源；定价引擎可以基于结构化属性自动计算；约束求解器可以基于结构化属性做自动化校验。

如果迁移到咱们公司的场景，我觉得核心思路是一样的：先把供给侧的商品/服务做成结构化数据模型，然后让 Agent 在这个结构化空间里做智能匹配和组合优化。”

Q4: 你的 Agent 项目目前上线了吗？有多少用户？ ⭐⭐⭐⭐⭐

考察意图：诚实度检验 + 判断项目成熟度

标准回答：

“TripPlan 目前处于核心功能开发完成、进入商业化试点验证阶段。

已完成的部分：完整的后端 API（9 个模块、20+ 接口）全部开发完毕并通过测试；核心算法——约束求解器、定价引擎、11 状态订单状态机——全部有单元测试和集成测试覆盖；数据库设计与迁移脚本完整；PRD（50 个 User Stories）和领域模型文档完备；AI 智能客服系统的 RAG、意图路由、多渠道接入等能力也已实现。

当前阶段的工作：正在与首批种子旅行社洽谈合作试点；LLM 层从 mock 数据切换到真实 OpenAI/Claude API（接口契约已定义好，替换即可）；前端页面的完善。

为什么还没大规模上线——入境游行业的 B 端决策周期较长，我们在认真选择合作伙伴确保首批试点跑通完整商业链路。

但我想强调的是：这个项目对我最大的价值不在于当前的用户数字，而在于让我完整经历了’商业痛点识别 → 产品定义 → 架构设计 → Agent 交易闭环工程化 → 测试保障’的全过程。

特别是以下这些经验是可以直接迁移到咱们公司场景中的：Agent 如何可靠地驱动交易流程（防幻觉、状态机、资金安全）；供需匹配引擎的设计方法（结构化供给 × 约束求解 × 动态定价）；LLM 与确定性后端的分工边界在哪里；创业视角下技术决策怎么做 trade-off。

很多 AI 创业公司在早期都是先有技术储备和产品原型，再找方向落地。我对 AI+交易方向的深度思考和工程实践，证明了我有能力在咱们公司’技术空间大、落地即见效’的场景中快速产出。”

二、架构与技术选型类

Q5: 为什么选择 FastAPI 而不是 Java Spring Boot 来做 AI 项目？ ⭐⭐⭐⭐

考察意图：技术选型能力、对不同技术栈的理解

标准回答：

“这个问题很好。其实我有两个项目用了不同的选择逻辑：

TripPlan 选 FastAPI 的原因：

第一点是 AI/ML 生态绑定。Python 是 AI 领域的事实标准语言。LlamaIndex、LangChain、HuggingFace Transformers、OpenAI SDK 这些关键库都是 Python 优先。用 Java 做 AI 项目意味着大量的 JNI 调用或者 HTTP 中转，增加复杂度。

第二点是异步 I/O 天然匹配 AI 调用模式。LLM API 调用的特点是高延迟（5-30 秒）加流式输出。FastAPI 基于 Starlette + asyncio，原生支持 async/await。chat engine 的 process_message 返回 AsyncGenerator，逐 token 推送到前端——这正是 FastAPI 最擅长的场景。Java 虽然也有 WebFlux，但生态成熟度和开发效率不如 Python 异步栈。

第三点是 Pydantic 类型系统与 LLM 输出的契合。LLM 返回的是 JSON，Pydantic v2 可以直接做请求参数校验、响应序列化、API 文档生成。项目中行程方案（Day→Segment→Resource 嵌套结构）、报价明细（6 类资源分项列表）这些复杂 Schema 用 Pydantic 管理非常高效。

第四点是快速迭代适合 MVP 阶段。创业项目/MVP 阶段需要快速验证想法，Python 的开发效率更高。而且我采用了 AI Coding 工作流——架构设计和技术决策由我主导，AI 工具辅助 Python 代码实现，进一步放大了迭代效率。我的主栈是 Java，但架构设计能力是跨语言的，AI Coding 让 Python 工程落地不再是瓶颈。

但如果是我来做咱们公司的 AI+消费产品，我的建议可能是混合架构：AI/Agent 层用 Python FastAPI（LLM 调用、RAG、Agent 编排）；核心交易层用 Java Spring Boot（订单、支付、库存——利用团队现有积累和千万级用户的稳定性要求）；两层之间通过 gRPC 或消息队列通信。

这样既发挥了 Python 在 AI 生态上的优势，又保留了 Java 在大规模交易系统上的工程成熟度。”

Q6: 如果让你设计咱们公司的 AI+消费产品架构，你会怎么做？ ⭐⭐⭐⭐⭐

考察意图：架构思维、对业务的理解、能否将经验迁移到新场景

标准回答：

“基于我对 JD 的理解——‘已有成熟 C 端交易业务 + 千万级用户底盘’加’LLM Agent × 交易闭环’——我会这样设计：

整体原则是渐进式增强，而非推倒重来。

咱们已经有成熟的 C 端交易业务了，不能因为加 AI 就把现有系统搞挂。我的思路是在现有交易链路上嵌入 Agent 能力，而不是替代它。

架构分层是这样的：

最上层是 C 端用户触达层（App / 小程序 / Web），新增 AI 对话入口（可选）。

中间是 AI Agent 网关层（新增），包括：意图路由（咨询/搜索/下单/售后）、LLM 网关（多模型管理/fallback）、RAG 引擎（商品知识库/FAQ）、MCP 工具注册中心。

最下层是现有交易核心层（保留），包括：商品/库存/价格服务、订单/支付/履约服务、用户/营销/风控服务。

Agent 切入场景按优先级排序：

P0 是智能售前咨询（最快见效）。用户问’有什么适合送给父母的礼物？’，Agent 从商品知识库（RAG）检索推荐，理解预算/喜好/场景后给出个性化推荐清单。用户确认后直接跳转下单页面。价值是提升转化率，降低客服成本；风险低——不涉及资金操作，即使 Agent 推荐不准也只是体验问题。

P1 是 AI 辅助商品结构化（JD 提到的核心方向）。用 LLM 对非结构化商品数据（标题、描述、评论）做自动结构化提取——品类、属性、适用场景、卖点等。结构化后的数据存入向量库，供 RAG 检索和 Agent 匹配使用。价值是让海量商品数据变成 Agent 可理解的’供给’；技术点是批量 LLM 调用 + 结果校验 + 人工审核。

P2 是智能售后/客服。复用我在 AI 智能客服项目中的经验——RAG 知识库问答 + 意图路由 + 人工转接 + 多渠道接入。

P3 是 Agent 驱动的个性化推荐/搭配。类似 TripPlan 的供需匹配思路——用户画像 × 结构化商品库 → 约束匹配 → 个性化方案。

关键技术决策：

第一点是 LLM Provider 选择。初期用 API（OpenAI/Claude/国产大模型），跑通链路后有数据后再考虑 Fine-tuning。

第二点是成本控制。高频简单场景用规则/小模型，复杂场景才调大模型——我在智能客服项目中用的’规则+LLM 双层路由’就是这个思路。

第三点是可观测性。全链路 TraceId + LLM 调用的 latency/token 用量/成本监控——这对生产环境运营至关重要。

第四点是灰度发布。先在少量用户/SKU 上验证效果，逐步放量。”

Q7: RAG 知识库是怎么实现的？如何保证检索质量？ ⭐⭐⭐⭐

考察意图：RAG 实战经验、对检索质量的工程化思考

标准回答：

“我在 AI 智能客服项目中实现了一套完整的 RAG 链路：

离线索引阶段：文档上传 → LlamaIndex IngestionPipeline 自动执行流水线：SentenceSplitter 分块（chunk_size=500, overlap=50）；HuggingFace BAAI/bge-large-zh-v1.5 做 Embedding；Qdrant 向量数据库持久存储（COSINE 相似度距离）。

在线检索阶段：用户 query → 同样 BGE Embedding → Qdrant 语义相似度检索 top_k=5 → 支持 MetadataFilters 按 doc_id/source/category 过滤 → LlamaIndex VectorStoreIndex.as_query_engine(ResponseMode.COMPACT) 做 response synthesis → LLM 基于检索 chunks 生成回答 + 来源引用 citations。

质量保障策略有四层：

第一层是元数据过滤。按文档 ID、来源、分类过滤，避免跨域噪声。

第二层是分数阈值过滤。相似度低于阈值的 chunk 不纳入 context。

第三层是 Qdrant 不可用时的 fallback。直接拼接 chunks 文本作为回答，保证服务不中断。

第四层是 Prompt 约束。要求 LLM’基于以下参考内容回答，如果没有相关信息请诚实说明’。

如果要进一步提升质量，我会考虑（这也是我在项目优化评估文档中列出的改进方向）：Hybrid Retrieval（BM25 关键词召回 + 向量语义召回双路融合）；Reranker（bge-reranker-v2-m3 对初排结果重排序）；知识库版本管理（draft → staging → active → archived 的生命周期管理）。”

三、高并发与系统设计类（携程经验的迁移价值）

Q8: 你在携程做的千万级订单系统重构，跟我们公司的场景有什么关联？ ⭐⭐⭐⭐

考察意图：判断你能否将大厂经验迁移到创业公司场景

标准回答：

“虽然行业不同，但底层技术挑战是相通的。JD 说咱们有’千万级用户底盘’，这意味着：

共同挑战 1 是高并发写入。携程火车票订单峰值 1000 万+/天，咱们的 C 端交易在大促期间也会面临类似压力。我的经验是消息队列削峰 + 异步化——主逻辑同步写核心数据，旁路逻辑（日志/通知/统计）异步处理；分库分表：按 user_id 或 order_id 做 sharding，单表控制在 500 万行以内。

共同挑战 2 是数据一致性。订单-支付-库存的一致性在任何交易系统中都是核心难题。我的经验是分布式事务的务实选择——不完全依赖 2PC/Seata，而是通过最终一致性 + 补偿机制（如支付超时自动关闭订单、库存预占+超时释放）。

共同挑战 3 是缓存策略。热点数据（热门商品、用户信息）的高并发读取。我的经验是’主动+被动’结合的动态缓存刷新——热数据主动推送更新，冷数据被动按需加载，根据系统资源动态调整频率，节省 60% 缓存资源。

但我也清楚创业公司和大厂的关键差异：创业公司不需要一步到位的’完美架构’，而是能快速验证 → 可演进的架构；我在 TripPlan 项目中就体现了这一点——先用单体 FastAPI 跑通 MVP，DDD 模块划分保证了后续拆分的清晰边界；如果加入咱们团队，我会带着大厂的’坑’的经验，但用创业公司的节奏来做技术决策。”

Q9: 如果日活达到百万级，你的 AI Agent 服务怎么扛住？ ⭐⭐⭐⭐

考察意图：扩展性思维、对 AI 服务特性的理解

标准回答：

“AI Agent 服务和传统 Web 服务有一个根本区别：LLM 调用延迟高（5-30s）、成本高（token 计费）、不确定性大（可能超时/幻觉）。所以扩展策略要围绕这三个特性来设计：

第一阶段（DAU 1-10 万）是单实例优化。全链路异步：FastAPI asyncio + asyncpg，不阻塞等待 LLM 响应；连接池复用：数据库/Redis/LLM API 都用连接池；缓存分层：相同/相似问题的 RAG 结果缓存（TTL 按数据新鲜度设）；限流熔断：Token Bucket 四层限流 + Circuit Breaker（我在智能客服项目中已实现）。

第二阶段（DAU 10-50 万）是水平扩展 + 服务拆分。Agent 编排服务无状态化：可以多实例部署 + 负载均衡；LLM 调用独立为服务：因为它的延迟特性和资源需求与其他模块差异大，独立拆出便于单独扩缩容和成本核算；引入消息队列：耗时操作异步化（文档索引、会话归档、分析统计）。

第三阶段（DAU 50 万+）是智能化降本。分级路由：80% 的常见问题走缓存/规则/小模型（低成本低延迟），20% 的复杂问题走大模型；Prompt Cache / 共享上下文：相似请求复用 LLM 的前缀计算；Batch 推理：非实时场景攒批调用，降低 API 调用次数；本地模型替代：高频场景部署开源模型（Qwen/Llama），降低 API 成本。

关键指标监控：LLM 调用 P50/P99 延迟；Token 用量和成本趋势；Agent 成功率（成功完成任务的比率 vs fallback 到人工的比例）；用户满意度（任务完成后的反馈）。”

四、团队管理与创业视角类（JD 明确要求）

Q10: 你带过最大规模的团队是怎样的？怎么管理的？ ⭐⭐⭐⭐

考察意图：JD 要求”带领团队完成从需求到上线的全流程”，验证管理能力

标准回答：

“我带过三种不同规模和形态的团队：

携程 20+人研发团队（大型团队）。这是规模最大的一段。团队负责火车票预订、订单、数据、国际业务等多个领域。管理方式是分层管理——我下面有 3-4 个 Tech Lead，每个 Lead 带 5-6 人；流程建设：建立了双周迭代 + Code Review 机制 + 技术分享会（每月一次）；交付保障：通过抢票系统和国际业务的 0-1 交付，证明了团队的执行力；成果：团队从最初的 5 人扩大到 20+人，期间保持了高质量的交付（订单系统重构零重大故障）。

SGS 10 人团队（中型团队）。外企环境，更注重流程规范。建立了 Code Review 强制机制和技术分享制度；项目交付周期缩短 20%。

创业公司 3 人团队（小型/精锐团队）。这是最考验’技术合伙人’能力的场景——资源极度有限，必须每个人都是多面手。我的角色：不只写代码，还要参与产品讨论、商业模式设计、甚至跟投资人沟通；效能策略：轻量级敏捷，每周迭代，快速验证假设；成果：一年内从 0 到月流水破百万。

对于咱们公司目前的阶段，我觉得最重要的是：招对人——AI 方向需要既懂工程又懂算法的人，这类人才稀缺，需要有吸引力的技术愿景；建立快速迭代的节奏——创业公司不需要重型流程，但需要清晰的优先级和定期复盘；技术债管理——快速发展的同时要有意识地控制债务，我在携程做 .NET→Java 转型时就深刻体会到了这一点。”

Q11: 你怎么看”对技术结果负责”这句话？ ⭐⭐⭐⭐⭐

考察意图：JD 明确写了”对技术结果负责，有一定的创业经历或者创业视角”——这是核心价值观匹配题

标准回答：

“我觉得’对技术结果负责’有三层含义：

第一层是交付质量负责。不是’代码写完提交了就行’，而是’线上稳定运行、用户体验好、业务指标达成’。我在携程做订单系统重构时，不只是完成了微服务拆分和分库分表的代码，而是持续跟踪上线后的表现——日均订单从 100 万涨到 1000 万+，可用性 99.99%，稳定运行至今没有重大故障。这才是’对结果负责’。

第二层是业务价值负责。技术不是目的，是手段。我做抢票系统时，目标不是’实现一个高效的调度算法’，而是’帮助公司拿到抢票市场占有率第一’。当算法效果好的时候，年底超额完成业绩目标，拿了 CEO 大奖——这个奖不是颁给技术的，是颁给业务结果的。

第三层是投入产出比负责。创业公司资源有限，每一分钱、每一个人力都要花在刀刃上。我在 TripPlan 项目中做的很多决策都是基于 ROI 考量：为什么用 FastAPI 而不是自己造轮子？因为 MVP 阶段速度优先；为什么 LLM 层先做 mock 再接真实 API？因为业务逻辑验证不依赖真实 LLM；为什么测试覆盖率要求这么高？因为交易系统中 bug 的代价极高。

总结一下：’对技术结果负责’意味着跳出工程师的思维框架，以产品和业务的视角审视每一个技术决策。这正是创业视角的本质——你不只是 team 里写代码最快的人，你是那个能判断’这件事值不值得做、用什么方式做最划算’的人。”

五、场景题 / 白板题

Q12: 如果让你设计一个”AI 导购助手”（用户对话式购物），你会怎么设计？ ⚡⚡⚡

考察意图：白板设计能力、能否将 Agent 经验迁移到新场景

回答框架：

“好问题，我来画一下核心架构和数据流：

第一步是厘清边界。AI 导购助手不等于 ChatGPT 套壳。它的目标是提高转化率和客单价，而不是陪用户聊天。

第二步是核心架构。

用户输入 → 意图识别 → 分发处理
├── 咨询类 → RAG 检索（商品知识库/评价/FAQ）
├── 搜索类 → 结构化查询（筛选条件提取 → 商品检索）
├── 推荐类 → 供需匹配（用户画像 × 商品库 → 个性化推荐）
├── 下单类 → Agent 引导（确认商品 → 加购 → 结算）
└── 售后类 → 订单查询 / 退换货指引

第三步是关键技术设计。

第一点是商品结构化（前提条件）。类似 TripPlan 中的旅游资源建模，把商品定义为结构化实体：基础属性（品类、品牌、价格、规格）；内容属性（标题、描述、卖点评测，用于 RAG）；行为属性（销量、好评率、复购率，用于推荐排序）；关联属性（搭配商品、同类竞品，用于交叉销售）。

第二点是用户画像动态构建。显性信息：历史浏览/购买/收藏/搜索记录；隐性信息：当前对话中提取的偏好（送礼/自用/预算/风格）；画像随对话实时更新。

第三点是 Agent 推荐引擎。粗筛：基于用户画像 + 过滤条件从商品库初筛候选集；精排：LLM 结合用户当前意图对候选集做个性化排序和理由生成；兜底：候选集为空时 fallback 到热门/销量排行。

第四点是防幻觉 & 安全。价格/库存/优惠信息必须从实时 API 获取，LLM 不能编造；敏感操作（下单/支付/地址变更）必须用户二次确认；推荐结果附带商品链接，用户可点击验证真实性。

第四步是衡量成功的指标。转化率对比（AI 助手 vs 传统搜索/分类导航）；客单价变化（是否提升了连带销售）；人工客服分流率（多少问题被 AI 解决了）；用户满意度评分（对话后的反馈）。”

⚡

技术深度问题应对

来源：05_技术深度问题应对.md

技术深度问题应对（白板 / 深度追问）

本文档针对面试官可能进行的白板画图、代码追问、架构深挖场景
标注 ⚡ 的问题需要能现场手写/口述代码或画图

一、Agent 架构白板（最高频 ⚡⚡⚡）

Q1: 请画出 TripPlan 的完整系统架构图

准备好以下架构图（口述 + 白板双模式）：

```ascii
┌─────────────────────────────────────────────────────────────┐
│                     用户 (海外游客)                           │
│                  浏览器 / 移动端                              │
└──────────────────────────┬──────────────────────────────────┘
                           │ HTTPS / REST API
                           ▼
┌─────────────────────────────────────────────────────────────┐
│              FastAPI Application (异步)                      │
│                                                               │
│  ┌─────────────────────────────────────────────────────┐     │
│  │               Router Layer (app/api/)                │     │
│  │   /auth / /requirements / /itinerary / /resources    │     │
│  │   /orders / /webhooks / /admin                       │     │
│  └────────────────────┬────────────────────────────────┘     │
│                       │                                       │
│  ┌────────────────────▼────────────────────────────────┐     │
│  │              Service Layer (9 大模块)                 │     │
│  │                                                    │     │
│  │  ┌───────────┐  ┌────────────┐  ┌───────────────┐  │     │
│  │  │ Require-  │  │ Itinerary  │  │ Constraint    │  │     │
│  │  │ mentColl. │  │ Engine     │  │ Solver        │  │     │
│  │  │ (LLM NLU) │  │ (编排)     │  │ (3层校验)     │  │     │
│  │  └─────┬─────┘  └─────┬──────┘  └──────┬────────┘  │     │
│  │        │             │                │            │     │
│  │        ▼             ▼                ▼            │     │
│  │  ┌──────────────────────────────────────────┐      │     │
│  │  │         PricingService                   │      │     │
│  │  │   (季节系数 × 多币种 × 6类资源分项计价)    │      │     │
│  │  └──────────────────┬───────────────────────┘      │     │
│  │                     │                               │     │
│  │  ┌──────────────────▼───────────────────────┐      │     │
│  │  │ OrderService + StateMachine (11状态)      │      │     │
│  │  └──────────────────┬───────────────────────┘      │     │
│  │                     │                               │     │
│  │  ┌──────────────────▼───────────────────────┐      │     │
│  │  │ PaymentService (Stripe Adapter模式)       │      │     │
│  │  └──────────────────────────────────────────┘      │     │
│  │                     │                               │     │
│  │  ┌──────────────────▼───────────────────────┐      │     │
│  │  │ ReviewService (Minor/Major 双通道审核)    │      │     │
│  │  └──────────────────────────────────────────┘      │     │
│  └─────────────────────────────────────────────────────┘     │
│                                                               │
│  ┌───────────────────────────────────────────────────────┐    │
│  │              LLM Agent Bridge (Function Calling)       │    │
│  │   Tool Definitions ←→ LLM (OpenAI/Claude) →→ 后端服务  │    │
│  └───────────────────────────────────────────────────────┘    │
└──────────────────────────┬──────────────────────────────────┘
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
┌─────────────────┐ ┌─────────────┐ ┌──────────────┐
│   PostgreSQL    │ │    Redis    │ │  External    │
│ (主数据存储)     │ │ (缓存/会话) │ │  Services    │
│ · 用户/订单      │ │             │ │ · Stripe     │
│ · 行程方案       │ │ · Session   │ │ · LLM API    │
│ · 旅游资源(6类)  │ │ · 热点数据  │ │              │
│ · 配置数据       │ │             │ │              │
└─────────────────┘ └─────────────┘ └──────────────┘


**白板讲解要点**：
1. 先画用户 → API → Service → DB 的主链路
2. **重点展开 Service 层的 9 个模块和它们之间的关系**
3. 标注 LLM Function Calling 的桥接位置——这是面试官最关心的
4. 最后标注外部依赖和数据流向

---

### Q2: 画一下 LLM Agent 三阶段工作流的详细数据流 {#ch05-q2-画一下-llm-agent-三阶段工作流的详细数据流}

阶段1: 需求收集 (NLU)

══════════════════════

用户: “我想带家人来中国玩7天，喜欢历史文化，预算5000刀”
│
▼
RequirementCollector.collect(message)
│

  ├── LLM NLU 提取 (Function Calling 或 Prompt Extraction)
  │     输入: 用户自由文本
  │     输出: TravelerProfile {
  │       group_size: 4,
  |       travelers: [adult:2, senior:1, child:1],
  │       date_range: "2025-06-01 ~ 2025-06-07",
  │       interests: ["history", "culture"],
  │       budget_usd: 5000,
  │       pace: "relaxed",
  │       special_needs: ["accessibility"]
  │     }

│

  ├── 信息完整性检查
  │     缺少信息? → Agent 追问 ("请问几位成人？有老人或小孩吗？")
  │     信息完整? → 进入阶段2

│

  └── 存储 Profile 到 Session

阶段2: 行程规划 (核心!)

═══════════════════════

ItineraryEngine.generate(profile)
│

  ├── ① ResourceQuery: 查询可用资源
  │     按日期/城市/兴趣标签筛选景点/酒店/包车等
  │     返回: CandidateResources[]

│

  ├── ② ConstraintSolver.validate(itinerary_draft)
  │     ├── 时间约束: Segment 时间重叠检测 (排序扫描 O(nlogn))
  │     ├── 地理约束: 转移缓冲检查 (walk:15min / car:30min / subway:45min)
  │     └── 预算约束: 总价 ≤ profile.budget_usd
  │     返回: Violation[] (type/severity/message/details)

│

  ├── ③ PricingService.calculate(itinerary)
  │     公式: Σ(base_price × seasonal_multiplier × quantity)
  │     支持 6 类资源分项计价 + 多币种转换
  │     返回: Quotation (分项明细 + 总价)

│

  └── ④ 输出: Itinerary + Quotation

阶段3: 迭代优化

═════════════════

用户反馈: “第二天太累了，换个轻松点的”
│
▼
ItineraryEngine.iterate(feedback, current_itinerary)
│

  ├── LLM 理解反馈意图 (哪天? 什么问题? 怎么改?)

│

  ├── 重新执行 阶段2 的 ①②③

│

  └── 迭代计数 < 5? → 继续迭代
     迭代计数 >= 5? → 建议人工介入

确认后进入交易流程:

═════════════════════

OrderService.create(itinerary, quotation, user_id)
│

  ├── 状态: Draft → Confirmed

│

  ├── PaymentService.request_deposit(order, 30%)
  │     → Stripe PaymentIntent 创建
  │     → 用户支付
  │     → Webhook 确认
  │     → 状态: DepositPaid

│

  ├── ReviewService.submit(order)
  │     → 旅行社后台审核
  │     → Approved / Major Adjustment / Rejected

│

  └── 服务履约 → 尾款支付 → Completed


---

## 二、核心算法手写 ⚡ {#ch05-二-核心算法手写}
### Q3: 手写约束求解器的核心代码（时间重叠检测 + 转移缓冲） {#ch05-q3-手写约束求解器的核心代码-时间重叠检测-转移缓冲}
```python
def check_time_overlap(segments: list[dict]) -> list[Violation]:
```ascii
    """
    检测同一天内 Segment 的时间重叠
    算法：排序后相邻两两比较
    复杂度：O(n log n)，n 通常为 5-10
    """
    violations = []
    sorted_segs = sorted(segments, key=lambda s: s["start_time"])

    for i in range(len(sorted_segs) - 1):
        curr = sorted_segs[i]
        next_seg = sorted_segs[i + 1]
        curr_end = _to_minutes(curr["end_time"])
        next_start = _to_minutes(next_seg["start_time"])

        if curr_end > next_start:
            violations.append(Violation(
                type="time_overlap",
                severity="error",
                message=f"'{curr['name']}'与'{next_seg['name']}'时间重叠",
                details={"seg1_end": curr["end_time"], "seg2_start": next_seg["start_time"]}
            ))
    return violations

BUFFER_BY_TRANSPORT = {“walk”: 15, “car”: 30, “subway”: 45}

def check_transfer_buffer(segments: list[dict], default_transport: str = “car”) -> list[Violation]:

    """相邻活动间隙是否满足转移时间要求"""
    violations = []
    sorted_segs = sorted(segments, key=lambda s: s["start_time"])
    required_min = BUFFER_BY_TRANSPORT.get(default_transport, 30)

    for i in range(len(sorted_segs) - 1):
        curr, next_seg = sorted_segs[i], sorted_segs[i + 1]
        gap = _to_minutes(next_seg["start_time"]) - _to_minutes(curr["end_time"])

        if gap < required_min:
            violations.append(Violation(
                type="buffer_insufficient",
                severity="warning",
                message=f"转移时间仅{gap}min，建议至少{required_min}min",
                details={"gap": gap, "required": required_min}
            ))
    return violations


### Q4: 手写订单状态机跳转判断 {#ch05-q4-手写订单状态机跳转判断}
```python
# 11 状态严格有向图 {#ch05-11-状态严格有向图}
VALID_TRANSITIONS: dict[str, list[str]] = {
```ascii
    "draft":           ["confirmed", "cancelled"],
    "confirmed":       ["deposit_paid", "cancelled"],
    "deposit_paid":    ["reviewing", "cancelled"],
    "reviewing":       ["approved", "major_adjustment", "rejected", "cancelled"],
    "major_adjustment": ["confirmed", "cancelled"],
    "approved":        ["in_service", "cancelled"],
    "in_service":      ["completed", "cancelled"],
    "completed":       [],
    "cancelled":       ["refunding"] if refundable else [],
    "refunding":       ["refunded"],
    "refunded":        [],

}

def can_transition(current: str, target: str) -> bool:

    """O(1) 判断状态跳转是否合法"""
    return target in VALID_TRANSITIONS.get(current, [])

def transition(order: Order, new_state: str) -> None:

    """带守卫的状态变更"""
    if not can_transition(order.state, new_state):
        raise InvalidTransitionError(
            f"Cannot transition from {order.state} to {new_state}. "
            f"Valid targets: {VALID_TRANSITIONS[order.state]}"
        )
    # 记录状态变更历史（审计）
    order.state_history.append(StateChange(
        from_state=order.state,
        to_state=new_state,
        timestamp=utc_now(),
        triggered_by="system"
    ))
    order.state = new_state


---

## 三、AI 客服系统架构深挖 {#ch05-三-ai-客服系统架构深挖}
### Q5: 画一下 AI 智能客服系统的架构图 {#ch05-q5-画一下-ai-智能客服系统的架构图}

┌─────────────┐     ┌─────────────┐
│  Web Widget  │     │   飞书机器人  │
│  (React SSE) │     │  (Webhook)   │
└──────┬───────┘     └──────┬──────┘
       │ SSE                 │ Webhook
       ▼                     ▼
┌─────────────────────────────────┐
│      Channel Adapter (协议适配)   │
│   WebAdapter │ FeishuAdapter    │
└──────────────┬──────────────────┘
               ▼
┌─────────────────────────────────┐
│    RateLimit (Token Bucket)      │
│    全局/用户/会话/渠道 四层限流    │
└──────────────┬──────────────────┘
               ▼
┌─────────────────────────────────┐
│       Chat Engine (核心引擎)      │
│                                 │
│  ① IntentRouter (意图路由)       │
│     规则引擎(零成本) + LLM分类    │
│     → KB_QUERY / CHITCHAT /     │
│       PLUGIN_CALL / HUMAN_...   │
│                                 │
│  ② KBRetriever (RAG检索)        │
│     BGE Embedding → Qdrant →    │
│     Compact mode RAG 生成       │
│                                 │
│  ③ LLMGateway (LLM网关)         │
│     local/api 双模式 + fallback  │
│     超时重试 + 敏感信息脱敏      │
│                                 │
│  ④ HandoffOrchestrator (转人工)  │
│     排队队列 + 超时机制          │
└──────────────┬──────────────────┘
               ▼
┌─────────────────────────────────┐
│   基础设施层                      │
│  PostgreSQL + Redis + Qdrant     │
│  + Celery (异步任务)             │
└─────────────────────────────────┘

       ↓ 横切关注点
┌─────────────────────────────────┐
│ Observability (OTel + structlog) │
│ Auth (JWT + RBAC)                │
│ Elasticity (Circuit Breaker)     │
│ MCP Registry (插件注册中心)       │
└─────────────────────────────────┘


### Q6: 意图路由的规则+LLM双层设计怎么工作的？ {#ch05-q6-意图路由的规则-llm双层设计怎么工作的}

用户消息输入
│
▼
规则引擎 (第一层 — 零延迟零成本)
│

  ├── 检查1: HUMAN_KEYWORDS?
  │   "转人工"/"找客服"/"真人" → HUMAN_HANDOFF (conf=0.95)

│

  ├── 检查2: _is_question()?
  │   正则匹配问句特征 ("怎么"/"什么"/"吗") → KB_QUERY (conf=0.80)

│

  ├── 检查3: PLUGIN_ACTION_KEYWORDS?
  │   "查询订单"/"申请退货" → PLUGIN_CALL (conf=0.85)

│

  └── 检查4: PLUGIN_TOPIC_KEYWORDS?
      "售后"/"物流" → KB_QUERY (conf=0.75)

  规则未命中 → CHITCHAT (conf=0.60, fallback_used=True)

  ★ 关键点：
  - 规则引擎处理高频确定性场景，召回优先
  - LLM 路由处理模糊复杂意图（可选开启）
  - LLM 失败时自动 fallback 到规则引擎
  - conf < 0.5 时触发澄清反问

```

四、迁移到目标公司场景的设计题

Q7: 如果让你把 Agent 能力嵌入咱们现有的 C 端交易链路，你会从哪里开始切入？

回答框架：

“我会按’风险由低到高、见效由快到慢’的顺序来规划：

Phase 1（1-2个月）是智能售前咨询——最快见效。

这是风险最低、最容易验证价值的切入点。

用户入口是商品详情页/首页 “AI助手” 浮窗。能力范围包括：商品知识问答（”这个材质耐洗吗？”）；个性化推荐（”送给50岁妈妈送什么好？”）；使用指南（”怎么组装？”）；对比咨询（”A和B有什么区别？”）。

技术方案是 RAG（商品标题/描述/评价/FAQ → 向量库）+ 意图路由（咨询/推荐/对比/其他）+ 规则兜底（库存/价格/优惠必须实时查）。不涉及支付/订单修改/资金操作。

衡量指标：咨询解决率（不需要转人工的比例）；推荐点击率 → 加购转化率；平均响应时长 vs 传统搜索。

Phase 2（2-3个月）是商品结构化 + AI 导购。

JD 明确提到’AI驱动供需匹配与商品结构化’，这是核心方向。

目标是让海量非结构化商品数据变成 Agent 可理解的供给。方案是批量 LLM 处理 pipeline：商品标题/描述/参数 → LLM 提取结构化属性 → 品类/适用场景/目标人群/卖点/搭配建议 → 存入向量库 + 结构化数据库。

质量保障：抽样人工审核（初期100%审核）；置信度过滤（LLM confidence < 0.8 的标记待审）；版本管理（新旧版本可回滚）。

上层应用：”帮我选一套适合办公室的咖啡设备” → Agent 理解场景（办公室+多人+商用）→ 从结构化商品库匹配候选 → LLM 排序 + 理由生成 → 输出推荐清单 + 购买链接。

Phase 3（3-6个月）是交易环节 Agent 增强。

风险最高的阶段，涉及资金操作，需要谨慎推进。

场景1是智能下单辅助。”帮我下一单XXX，地址用默认的” → Agent 确认商品/规格/数量/地址 → 用户最终确认后才提交订单。

场景2是售后智能处理。”我要退货” → Agent 查询订单状态 + 退货政策 → 符合条件 → 引导走自助退货流程 → 不符合/复杂情况 → 转人工 + 附上上下文摘要。

安全原则：资金操作必须有用户明确确认；敏感操作记录完整审计日志；异常金额/频率触发风控告警。

每个 Phase 的成功标准：Phase 1 咨询解决率 > 70%，推荐转化率 > 传统搜索；Phase 2 商品结构化覆盖率 > 80%，准确率 > 90%；Phase 3 Agent 下单成功率 > 95%（含人工接管），客诉不上升。”

五、棘手问题的应对策略

Q8: “你的项目都没上线，怎么证明你能搞定生产环境？” ⚡

考察意图：压力测试你的自信度和诚实度

标准回答：

“这个问题很直接，我直接回答：

第一，我的携程 12 年经验就是生产环境经验。订单系统重构、抢票系统、国际业务——这些都是千万级用户、真金白银的交易系统。我对生产环境的理解不是来自 demo，是来自真实的高并发踩坑。

第二，TripPlan 和 AI 客服虽然没有大规模上线，但工程化标准是按生产级别做的。完整的测试覆盖（单元测试 + 集成测试）；错误处理和降级策略（Circuit Breaker、fallback）；可观测性（OpenTelemetry 全链路 TraceId）；安全设计（状态机、幂等、审计日志）。这些不是 demo 会做的事。

第三，我选择先做完整工程化再找商业落地，是因为 AI Agent + 交易闭环是一个新领域——我不想做一个’能用但不可靠’的 demo 去骗用户，而是先把工程化问题想清楚、做扎实。

第四，如果加入咱们公司，我能在已有业务底盘上快速验证 Agent 价值——因为我已经把工程化的问题解决了，剩下的就是业务适配和场景打磨。这比从零开始做要快得多。

说实话，我理解面试官对’没上线’的顾虑。但我更希望您看到的是：我有生产环境的经验基础，加上 AI Agent 的完整工程化实践——这两者结合，才是我能快速产出价值的原因。”

Q9: “你 Java 和 Python 都用，你觉得哪个更适合咱们公司？” ⚡

标准回答：

“这不是一个二选一的问题，而是一个’各司其职’的问题。

我的观点是：核心交易层用 Java，AI/Agent 层用 Python，两者通过 gRPC 或消息队列通信。

理由：

Java 的优势（核心交易层）：
- 团队已有成熟 C 端交易业务，大概率是 Java 技术栈
- Spring Cloud 生态完善（服务发现/配置中心/网关/熔断降级）
- 千万级用户的稳定性验证充分（JVM 调优、GC 优化经验丰富）
- 类型安全 + 编译期错误检查，适合资金相关逻辑

Python 的优势（AI/Agent 层）：
- AI/ML 生态事实标准（LangChain/LlamaIndex/HuggingFace/OpenAI SDK）
- FastAPI 异步原生支持，匹配 LLM 高延迟调用模式
- 快速迭代能力，适合探索性强的 AI 功能开发
- 数据科学工具链（pandas/numpy/sklearn）便于实验和分析

混合架构的实际案例：
很多头部公司都在用这种模式——字节跳动的推荐系统（C++ 服务端 + Python 模型训练）、阿里的搜索（Java 在线服务 + Python 离线训练）。AI 工程化的趋势就是’强语言做骨架，AI 语言做大脑‘。

如果让我来主导技术选型，我会：
1. 先评估团队现有技术栈和人员能力
2. 确定两层之间的接口契约（Protobuf/gRPC 定义清晰）
3. Python 层保持独立部署和扩缩容能力
4. 共享可观测性体系（统一 TraceId + 监控面板）”

❓

反问面试官问题清单

来源：06_反问面试官问题清单.md

反问面试官问题清单（针对 AI+消费产品技术负责人岗位）

原则：好问题展示你的思考深度、业务理解和创业视角
每个问题标注「考察意图」和「推荐时机」

一、业务与战略类（问创始人/CEO/产品负责人）

1. 关于 Agent 落地路径

问题	推荐时机	考察意图
「JD 提到’LLM Agent × 交易闭环’，目前团队对 Agent 切入交易链路的优先级是怎么排的？是先做售前咨询、商品推荐、还是直接切入下单环节？」	早期必问	展示你懂 Agent 能力边界和落地节奏
「在您看来，当前 C 端交易链路中哪个环节的人工成本最高或转化率最低？Agent 最有可能在哪里率先产生 ROI？」	中期	展示你有 business sense，不只关注技术
「对于 Agent 的’幻觉’问题，产品侧的容错策略是什么？是追求高准确率再上线，还是快速迭代小步快跑？」	中后期	展示你对 AI 产品化难点的真实认知

2. 关于供需匹配与商品结构化

问题	推荐时机	考察意图
「’AI 驱动供需匹配与商品结构化’——目前供给侧的数据基础怎么样？商品数据是已经结构化的还是需要从非结构化数据（标题/描述/评论）中提取？」	早期	JD 核心方向，必须搞清楚现状
「如果要做商品结构化，预计 SKU 量级多大？有没有历史数据可以用于训练或 RAG 检索？比如用户行为日志、搜索 query、客服对话记录等」	中期	展示你重视数据飞轮效应

3. 关于产品阶段与里程碑

问题	推荐时机	考察意图
「公司在 AI 方向的阶段性目标是什么？Q2/Q3 想达成什么里程碑？技术团队在这个目标中的角色是什么？」	后期	展示你是结果导向、有节奏感的人
「现有的 C 端用户画像是什么样的？他们对 AI 功能的接受度有做过调研或 A/B 测试吗？」	中期	展示你关注用户而非只关注技术

二、技术与架构类（问 CTO/技术负责人）

4. 关于 AI 技术现状

问题	推荐时机	考察意图
「团队目前的 AI 技术积累主要在哪块？Prompt Engineering / RAG / Fine-tuning / Agent Framework？有没有已经在用的 LLM 应用？」	早期必须问	了解现状，评估你能带来的增量
「LLM Provider 有偏好吗？自研模型还是调用 API（OpenAI/Claude/通义千文/DeepSeek）？成本预算大概在什么量级？」	早期	直接影响你的技术方案设计
「现有系统的技术栈是什么？有哪些历史债务？AI 能力是嵌入现有系统还是独立建设新服务？」	中期	展示你有工程现实感

5. 关于系统性能与扩展

问题	推荐时机	考察意图
「目前系统 QPS 大概什么量级？峰值是多少？延迟要求多少？这些数据能帮我更好地评估 Agent 服务如何嵌入而不影响现有性能。」	中期	展示你对高并发的理解
「千万级用户底盘下，用户行为数据、商品数据的存储和计算基础设施是怎样的？有没有实时数仓或向量数据库的规划？」	中后期	展示你重视数据基础设施

6. 关于技术决策机制

问题	推荐时机	考察意图
「团队对新技术采用的态度是怎样的？激进尝鲜还是稳健为主？比如引入新的 AI 框架或模型，决策流程是怎样的？」	后期	判断文化匹配度
「技术债情况如何？有没有想重构但一直没时间做的模块？加入后最希望我优先解决什么？」	中后期	展示你愿意承接挑战

三、团队与文化类

7. 关于角色定位

问题	推荐时机	考察意图
「您理想中的技术合伙人在团队中扮演什么角色？更偏架构决策、工程管理、还是深度参与产品和商业讨论？」	面试尾声必问	对齐期望，避免入职后落差
「JD 提到’与技术合伙人/创始人共同参与产品与商业方向决策’——具体来说，技术负责人参与决策的范围和频率大概是怎样的？」	中后期	理解决策机制
「技术团队目前的规模和构成是怎样的？未来半年的扩招计划？AI 方向会单独组建小组还是融入现有团队？」	中期	评估团队能量和成长空间

8. 关于创业阶段

问题	推荐时机	考察意图
「公司目前处于什么阶段？产品 PMF 验证了吗？还是在快速迭代找方向？」	早期	判断你是否适合当前阶段
「创始团队的背景是怎样的？之前有过创业经历吗？技术和产品背景怎么搭配？」	中期	了解创始人风格和文化

四、根据面试官身份选择推荐组合

面对 CEO/创始人 — 多问业务和战略

推荐组合（选 3-4 个）：
1. 「Agent 打算先切哪个交易环节？优先级怎么排的？」
2. 「当前哪个业务指标最需要改善？AI 能在其中扮演什么角色？」
3. 「您期望技术合伙人在决策中扮演什么角色？参与范围和频率？」
4. 「公司现阶段最大的挑战是什么？（技术/产品/商业化）」

面对 CTO/技术 VP — 多问技术现状和挑战

推荐组合（选 3-4 个）：
1. 「现有 AI 技术积累在哪块？有没有已上线的 LLM 应用？」
2. 「系统当前的瓶颈在哪？性能数据大概怎样？」
3. 「LLM 成本预算？自建 vs API 的倾向？Provider 选择？」
4. 「技术债情况？最想解决的 Top 3 是什么？」

面对 HR/BP — 多问团队和文化

推荐组合（选 2-3 个）：
1. 「技术团队规模和构成？AI 方向的人员配置？」
2. 「入职后的前 30-60-90 天预期是什么？」
3. 「公司文化中最看重的是什么？」

五、高质量反问的技巧

✅ 好问题的特征

展示你做了功课：「我看到咱们 JD 里提到’已有成熟 C 端交易业务 + 千万级用户底盘’，想了解一下…」
展示你有深度思考：用 JD 原话建立连接，追问 why 和 how
展示你关注结果：不只关心技术酷不酷，更关心能不能解决实际业务问题
双向筛选：你在判断这家公司是否值得加入，不只是被挑选

❌ 避免的问题

❌ 「公司是做什么的？」（没做功课）
❌ 「加班多吗？有双休吗？」（太早暴露关注点不对）
❌ 「我能学到什么？」（应该讲你能贡献什么）
❌ 太泛的问题（「你们技术栈是什么？」——官网就能查到）

🎯 终极必问（每个面试都准备一个）

“如果今天面试结束，您决定录用我，您希望我在第一个月内完成的最重要的一件事是什么？”

这个问题的好处：
- 展示行动导向和结果思维
- 让对方具体化对你的期望
- 帮助你判断这份工作是否真的适合你
- 如果回答模糊不清，说明对方自己也没想清楚——这本身就是一个重要信号

📋

面试前速查卡

来源：07_面试前速查卡.md

面试前速查卡（打印此页，面试前 30 分钟快速过一遍）

目标岗位：AI+消费产品技术负责人
核心匹配：LLM Agent × 交易闭环 × 千万级用户底盘 × 创业视角

✅ 面试前必查清单

知识层面

[ ] 能口述 TripPlan 的 Agent 三阶段工作流（NLU → Function Calling → 迭代优化）
[ ] 能画出订单状态机状态转移图（11 个状态 + 取消/审核分支）
[ ] 能讲清约束求解三层校验的具体逻辑和时间复杂度
[ ] 能说明定价公式和跨年季节系数处理
[ ] 能对比 Java vs Python 在 AI 项目中的选型理由（Java=交易深度，Python=AI 生态）
[ ] 准备好 AI Coding 工作流 的说明话术（架构设计我主导，AI 辅助代码实现）
[ ] 能口述 AI 智能客服系统的架构（RAG + 意图路由 + 多渠道）
[ ] 准备好 1-2 个 trade-off 决策 及其理由

材料层面

[ ] 简历已使用 02_优化后简历.md 的版本
[ ] 自我介绍已熟练（根据面试官身份选择版本，见 03_自我介绍_多版本.md）
[ ] 核心 Q&A 至少滚瓜烂熟前 6 题（见 04_高频Q&A话术库.md）

心态层面

[ ] 明确了 JD 最看重的 3 个能力：Agent 实战 / 交易闭环 / 创业视角
[ ] 准备好了”项目没上线”的应对话术
[ ] 心态：不卑不亢——你有携程千万级系统的真实战绩，也有两个完整 AI 项目的架构设计经验
[ ] 准备好”AI Coding 工作流”的坦诚说明——架构设计我主导，AI 辅助代码实现，这是效率倍增器不是能力替代

🚀 30 秒电梯演讲

我是吴来，12 年 Java 后端经验 + LLM Agent 架构设计与工程化落地。

核心标签：高并发交易系统架构（携程千万级订单）× AI Agent 架构设计（TripPlan 交易闭环 + AI 智能客服平台）× 技术合伙人视角。

一句话定位：我的主栈是 Java，AI 项目用 Python 是生态需要，架构设计能力跨语言可迁移——我能把 LLM Agent 可靠地嵌入到千万级用户的交易系统中。

📊 关键数字（脱口而出）

维度	数字	来源
总工作年限	12+ 年	—
团队管理经验	6+ 年	—
最大团队规模	20+ 人	携程
订单系统峰值	100 万 → 1000 万+/天	携程重构
系统可用性	99.99%	携程订单系统
Redis 缓存节省	60%	携程数据系统
TripPlan 业务模块	9 个	DDD 架构
订单状态数	11 个	状态机
旅游资源类型	6 类	数据模型
约束校验层数	3 层 (时间/地理/预算)	约束求解器
转移缓冲配置	步行15/包车30/地铁45 min	约束求解器
预付款比例	30%	支付设计
Agent 最大迭代	5 次	行程引擎
IoT 设备接入	500 台	创业项目
月流水突破	100 万	创业项目
开发成本节省	~30%	SGS
交付周期缩短	20%	SGS

🎯 三大核心卖点（反复强调！）

卖点 1：稀缺的「大厂高并发 × AI Agent」复合背景

话术：

“市场上找纯 Java 架构师容易，找纯 AI demo 作者也容易。但同时拥有携程千万级订单系统架构经验和两个完整 AI Agent 交易闭环工程项目的人极少。
这意味着我既懂如何构建高可用的交易系统，又懂如何在其中可靠地嵌入 LLM 能力。”

卖点 2：真正的「Agent × 交易闭环」

话术：

“TripPlan 不是 ChatGPT 套壳——它走到了真实支付环节：Stripe PaymentIntent + Webhook、11 状态订单机、动态定价引擎、人工审核双通道。
有完整的资金流转，有预付款+尾款两段式支付，有退款流程。这是 JD 最看重的’交易闭环’能力。”

卖点 3：技术合伙人级别的创业视角

话术：

“我有两次技术合伙人经历：IoT 共享平台从 0 到 1（月流水破百万），TripPlan 从 PRD 到代码全链路决策。
我参与过预付款比例为什么是 30%、审核 Major Adjustment 为什么限制 3 次——这些影响现金流和用户体验的决策。
我对’对结果负责’这句话是有真实体感的。”

🔥 LLM Agent 要点速查（被追问时展开）

Agent 设计原则:
```ascii
├── LLM 负责: 理解(NLU) + 创意(方案推荐) + 反馈分析
├── 代码负责: 价格计算 + 状态管理 + 约束校验 + 资金操作
└── 桥梁: Function Calling (工具定义 → LLM调用 → 后端执行)

防幻觉策略:

├── 资源只能从数据库查询结果中选择，不能编造
├── 价格由 PricingService 计算，LLM 不参与
├── 约束校验作为硬守卫，不过就不让输出
└── 关键操作(支付/状态变更)必须人类确认

供需匹配思路:

├── 需求侧: 自然语言 → LLM NLU → 结构化画像
├── 供给侧: 商品数据 → 结构化建模 → 向量库+关系库
└── 匹配层: 画像 × 供给 → 约束求解 → 个性化方案

```

⚡ “没上线” 应对速查

当前阶段：核心功能开发完成，进入商业化试点验证阶段

已完成：完整后端 API + 核心算法(约束/定价/状态机) + 全量测试 + PRD + 数据模型 + Stripe 对接
进行中：种子合作方洽谈 + LLM API 接入 + 前端完善

核心价值不在用户数字，而在于：
- Agent 交易闭环的设计方法论（可直接迁移到贵司场景）
- 从 0 到 1 搭建 AI 商业系统的完整经验
- 高并发系统架构功底（携程 12 年实战）

很多创业公司都是先有技术储备再找方向落地。

📋 文件索引

文件	内容	使用时机
`01_岗位画像与关键词分析.md`	JD 解读 + 关键词提取 + 匹配度分析	写简历前理解
`02_优化后简历.md`	最终版简历	投递使用
`03_自我介绍_多版本.md`	4 种版本自介绍	练习口述
`04_高频Q&A话术库.md`	12 个核心问题及详细回答	反复练习
`05_技术深度问题应对.md`	白板画图 + 手写代码 + 场景设计题	技术深挖准备
`06_反问面试官问题清单.md`	按面试官身份分类的反问	面试尾声使用
本文件 (`07_速查卡.md`)	面试前检查 + 速查卡	面试前30分钟必看

💡 最后建议

不要背答案，要理解逻辑。面试官会追问”为什么”，背诵会被识破
不确定的问题不要编造。可以说”这个方面我在项目中没有深入涉及，但我的理解是…”然后基于第一性原理推理
每次提到 TripPlan 都要强调”交易闭环”——这是你和其他候选人的最大差异化
展示热情和好奇心。AI 创业公司需要的不只是写代码的人，而是对技术和产品都有强烈兴趣的合作伙伴
准备好一个故事：项目中让你最有成就感的 moment——可以是第一次跑通 Agent 全链路时的兴奋感，也可以是解决一个棘手 bug 后的释然。真实的故事最能打动人

祝你面试顺利！🎯

📦

项目面试准备素材

来源：08_项目面试准备素材.md

项目面试准备素材

本素材围绕简历中的 4 个核心项目展开，覆盖面试官常见追问角度。每个项目配有：① 30秒电梯演讲 ② 架构决策追问 ③ 踩坑与反思 ④ JD关键词连线。

一、TripPlan — AI 定制游行程规划 SaaS

1.1 30 秒电梯演讲

“TripPlan 是一个用 LLM Agent 替代旅行社人工行程规划的 SaaS 产品。核心创新在于实现了「对话→方案→报价→支付」的完整交易闭环——用户通过自然语言描述需求，Agent 自动生成多日行程方案和分项报价，用户可以直接在线支付。技术上最大的挑战是 LLM 的不确定性 vs 交易的确定性之间的平衡——我的解决思路是让 LLM 只负责理解和创意，所有涉及价格、状态、资金的部分全部由确定性代码控制。”

1.2 面试官高频追问

Q1：为什么不直接用 LLM 生成整个行程，而要设计 DDD 9 模块架构？

「核心原因是 LLM 擅长理解意图和创意生成，但做不好精确计算和状态管理。如果把定价、约束校验、支付安全交给 LLM，就会出现幻觉报价、行程时间冲突、资金风险这些问题。9 模块拆分本质是把『LLM 擅长的』和『代码擅长的』做了明确边界划分——Agent 负责 NLU + 行程创意，后端服务负责价格计算、约束校验、状态流转、资金安全。这其实是一个 LLM Agent 工程化的核心命题：如何让 LLM 和确定性系统高效协作。」

Q2：约束求解引擎的三个层次具体怎么工作的？

「第一层是时间重叠检测——把每个行程片段看作时间段，用扫描线算法 O(nlogn) 检测是否有重叠。如果有重叠，输出具体冲突片段让 Agent 修正，而不是直接拒绝。第二层是转移缓冲——比如两个相邻景点之间的距离，步行给 15 分钟缓冲、包车 30 分钟、地铁 45 分钟，不同交通方式缓冲时间不同，基于实际地理距离计算。第三层是预算超支——当前方案总价 vs 用户预算，超支时标红提醒，Agent 可以降级酒店或减少景点来适配。三层校验结果以结构化 JSON 返回给 Agent，Agent 理解后生成修正方案。这是一个『Agent 尝试 → 系统校验 → Agent 修正』的循环。」

Q3：为什么订单状态机要设计成 11 状态的严格有向图？

「因为涉及到资金流转——预付款、尾款、退款。状态机的核心价值是保证资金安全。比如，必须从 DepositPaid 才能进 Reviewing，不能跳过；Cancelled 状态下根据是否已付款决定是否需要 Refunded。严格有向图的设计意味着每个状态只能走到特定后继状态，不存在非法跃迁路径。我在携程做订单系统时就深刻体会到：支付系统的状态机设计和测试覆盖度，是 99.99% 可用性的基石。这个经验直接复用到了 TripPlan。」

Q4：Stripe 支付对接为什么要用 Adapter 模式，而不是直接调用？

「为未来扩展预留接口——现在是 Stripe，以后可能接入微信支付、支付宝、PayPal。Adapter 模式把支付接口抽象为统一的 PaymentGateway 协议，Stripe 是一个实现。新接入一个支付渠道只需要加一个 Adapter 实现类，订单系统完全不改。这个设计思路来自携程的 GDS 经验——对接多家海外铁路供应商时，我们抽象了统一铁路产品模型屏蔽差异。本质都是 Adapter 模式的工程实践。」

Q5：你怎么保证 LLM Agent 生成方案的质量？幻觉怎么控制？

「三个层次的策略：第一是输入约束——NLU 阶段提取结构化用户画像（日期/人数/预算），缩小 Agent 的发挥空间；第二是系统校验——约束求解引擎兜底，Agent 出的方案必须过三层校验，不通过就返回违规报告让 Agent 重试；第三是人工审核——订单进入 Reviewing 状态后，实际是人工确认方案再执行支付。旅行产品客单价高（通常几千到几万），加入人工审核环节是合理的商业决策，也是一种 hallucination 的最后防线。」

1.3 踩坑与反思

坑	反思
最初把定价逻辑也交给 LLM Function Calling 返回，结果 LLM 会”算错价格”	LLM 不碰钱——定价引擎必须由确定性代码实现，Agent 只负责选择资源组合，价格由后端精确计算
行程段之间的转移时间一开始写死 30 分钟	不同交通方式实际耗时差异大，改为按交通方式差异化 + 基于地理坐标动态计算
开发初期只写集成测试，约束求解器重构后引入回归 bug	后续补上了全量单元测试覆盖约束求解和状态机流转，核心算法必须有测试护城河

1.4 与 JD 连线

JD 要求	TripPlan 对应
LLM Agent 设计	三阶段工作流（NLU → Function Calling → 迭代优化）
交易闭环	Stripe PaymentIntent + 11 状态订单状态机 + 预付款/尾款
供需匹配/约束求解	三层约束校验引擎 O(nlogn)
从 0 到 1 落地	独立完成 DDD 架构设计 + AI Coding 辅助工程落地
动态定价	季节系数 × 多币种 × 6 类资源分项计价

二、AI 智能客服系统 — 多渠道 Agent 平台

2.1 30 秒电梯演讲

“这是一个面向企业场景的生产级 AI 客服平台。核心价值在于把 LLM + RAG + 多渠道接入整合为一个开箱即用的解决方案，企业在飞书上配置一下就能用。技术亮点包括双层意图路由、LlamaIndex 全链路 RAG、Token Bucket 四层限流和 Circuit Breaker 熔断，以及 OpenTelemetry 全链路可观测。强调工程化——Protocol 协议编程 + 依赖注入让系统高度可扩展，不同企业可以配置不同的知识库和插件。”

2.2 面试官高频追问

Q1：双层意图路由为什么要规则 + LLM 两层？只用 LLM 不行吗？

「只用 LLM 有三个问题：第一是延迟——LLM 调用 2-5 秒，规则引擎毫秒级；第二是成本——每次调用都消耗 token；第三是可靠性——LLM 可能误判。所以设计是：规则引擎先做关键词/正则快速匹配（如『退款』→ 人工转接），匹配不到或置信度低时再走 LLM 意图分类。LLM 也有置信度阈值，低于阈值就 fallback 到默认策略。这样既快又省钱，还可靠。」

Q2：LlamaIndex IngestionPipeline 的设计考量？

「选 LlamaIndex 而不是 LangChain，主要因为 LlamaIndex 在 RAG 场景的索引管理和检索管道更成熟。IngestionPipeline 的链路是：文档加载 → SentenceSplitter 分块 → BGE Embedding 向量化 → Qdrant 存储。BGE 中文 Embedding 效果比 OpenAI 的通用模型好。Qdrant 选型因为它支持过滤检索和分组查询，适合按企业/知识库做隔离。」

Q3：四层限流的具体实现原理？为什么设计四层而不是两层？

「先说实现原理。四层限流全部基于 Token Bucket（令牌桶）算法——每个限流维度维护一个桶，以固定速率放入令牌，请求到达时消耗令牌，令牌不足则拒绝。相比固定窗口，Token Bucket 允许一定的突发流量（桶里攒的令牌可以一次性消耗），同时长期速率可控。」

实现细节：

层级	限流键（Key）	典型配置	解决的问题
全局	`rate_limit:global`	1000 req/s	保护系统整体不被突发流量打垮，是所有请求的第一道闸门
用户级	`rate_limit:user:{user_id}`	20 req/s	防止单个用户脚本刷接口、恶意爬取知识库
会话级	`rate_limit:session:{session_id}`	5 req/s	单次对话中 LLM 调用是最贵的（token 消耗 + 延迟），限制会话内连续请求频率，防止用户在对话中疯狂点”重新生成”
渠道级	`rate_limit:channel:{web\\|feishu}`	Web 200 / 飞书 100 req/s	不同渠道的流量模型和成本结构不同——飞书群机器人可能因多人同时 @ 瞬间涌入大量请求；Web 端用户分散，相对平稳

「实现上用的是 Redis + Lua 脚本，保证令牌操作的原子性。Lua 脚本逻辑：第一，读取当前令牌数 + 上次填充时间；第二，按时间差计算应填充的令牌；第三，判断令牌是否足够；第四，够则扣减返回 allowed，不够返回 rejected。一次 Redis 调用完成整个判断，性能开销极低（单次操作 < 1ms）。」

为什么必须是四层而不是两层？—— 设计理由：

「如果只有全局 + 用户两层，会丢两个场景：

第一点，为什么需要会话级？LLM 调用的成本不是均匀的——一个用户在一个会话里连续点 20 次”重新生成”，消耗的是 20 次 LLM API 调用的 token 和延迟，比正常对话贵几十倍。用户级 20 req/s 理论上能拦住极端情况，但如果这个用户同时开着 4 个会话窗口各发 5 req/s，用户级限不住。会话级锁定了『单次对话』这个维度，精准控制最昂贵的资源消耗。

第二点，为什么需要渠道级？飞书和 Web 是两种完全不同的流量模型。飞书群机器人：几十人的群里同时 @ 机器人，瞬间几十个请求涌进来，是典型的『脉冲型』流量。Web 端：用户分散、独立决策，是『平稳型』流量。如果共用全局 + 用户，无法为飞书的脉冲特性做独立限制——要么设得太松起不到保护作用，要么设得太紧误伤 Web 正常用户。

四层本质上是一个纵深防御体系：全局是第一道总闸，用户/会话/渠道分别从不同维度做精准控制，任何一层被绕过或被误判，下一层还能兜底。这种分层思想来自携程做高并发时的经验——单点防护永远不如多层纵深可靠。」

Q4：MCP 插件协议你们具体怎么用的？

「MCP（Model Context Protocol）是一个标准化协议，让 LLM 可以调用外部工具。在客服系统中，我们通过 MCP 暴露企业内部 API 给 LLM——比如查订单、查物流、查库存。LLM 理解用户意图后，通过 MCP 协议调用对应插件，拿到结果再组织语言返回给用户。MCP 的核心价值是标准化——新增一个插件不需要改 Agent 代码，只需要实现 MCP Server 协议。」

2.3 踩坑与反思

坑	反思
RAG 召回不准确，经常返回无关文档片段	加入 SentenceSplitter 优化分块粒度 + BGE 中文 Embedding 替换通用模型 → 召回准确率大幅提升
LLM 有时输出超出插件返回的事实范围	在 Prompt 中强化『仅基于检索结果回答，不确定时说不知道』的约束
Circuit Breaker 阈值设得太低，正常波动就触发熔断	调整为基于滑动窗口统计 + 半开状态探测，减少误触发

2.4 与 JD 连线

JD 要求	AI 客服对应
LLM Agent	Chat Engine + 意图路由 + MCP 插件
RAG	LlamaIndex + Qdrant + BGE Embedding
高可用	Token Bucket × 4 + Circuit Breaker
可观测	OpenTelemetry 全链路 TraceId
工程化	Protocol + DI + Docker Compose + CI

三、携程火车票系统簇 — 千万级高并发底盘

3.1 30 秒电梯演讲

“在携程 12 年，我负责了火车票最核心的几个系统。订单系统重构是我主导的最大工程——从单体拆分为 8 个微服务、分 8 库，日均订单峰值从 100 万提升到 1000 万+。抢票系统是我从 0 到 1 做的，市场占有率做到了第一，拿过 CEO 大奖。做这些系统的最大收获是：高并发场景下，架构决策的代价会被放大 100 倍——一个数据库索引设计失误，在千万级流量下就是灾难。这种架构体感是 AI 项目中做技术决策的重要基础。”

3.2 面试官高频追问

Q1：订单系统重构中，最难的技术决策是什么？

「分库分表方案的路由键选择。一开始按用户 ID 分，但发现订单业务的查询热点是按订单号查，而非按用户查，导致大量跨库查询。最终改为按订单号分库，同时冗余一份按用户 ID → 订单号列表的映射表。这个决策教训是：分库分表的 routing key 必须 match 核心查询 pattern，不能想当然。后来我在 TripPlan 做数据库设计时，第一件事就是梳理核心查询场景，再决定索引和分区策略——这就是经验迁移。」

Q2：消息队列 + 状态机解耦具体怎么做的？

「以前是同步流程：下单 → 锁座 → 调用出票接口 → 返回。出票接口依赖 12306，响应时间不稳定，导致下单接口经常超时。重构后改成：下单后立刻返回『处理中』，异步发消息给出票服务，出票完成后通过回调更新订单状态。订单状态机定义了严格的状态流转路径，消息队列保证出票请求不丢失。这个『主逻辑同步 + 旁路异步』的模式，在当前 TripPlan 的支付回调场景中完全复用。」

Q3：抢票系统的任务分级和余票预测思路？

「抢票本质是一个资源调度问题——大量用户同时抢限量票源。任务分级：高价值任务（长途、热门线路）分配更多引擎并发，低价值任务减少资源。余票预测：根据历史退票数据和 12306 放票规律，预测哪个时段会有余票释放，提前集中抢票资源。这套思路其实跟 AI 调度有共通之处——都是有限资源下的优化分配问题。」

3.3 与 JD 连线

JD 要求	携程经验对应
高并发/高可用	100 万→1000 万+ 日均订单，99.99% 可用性
架构决策	微服务拆分、分库分表、消息队列解耦
技术团队管理	20+人团队、跨部门协调
国际化	Global Rail GDS 多国铁路集成
结果导向	CEO 大奖 + 市场占有率第一

四、共享设备智能运营平台 — 创业 0→1 视角

4.1 30 秒电梯演讲

“这是我以技术合伙人身份从 0 到 1 打造的 IoT 共享平台，连接设备、商家和用户。技术亮点是自研的设备接入层——基于 Netty 处理 TCP 长连接，支撑海量设备在线。但更重要的是商业视角的收获：第一次直接面对收入和留存，理解到技术决策必须服务于商业目标。比如支付分账系统——不是技术有多难，而是分账比例、结算周期这些业务参数如何设计才能让商家愿意入驻。这段经历让我在做 TripPlan 时，能站在商业角度思考：这个功能用户愿意付多少钱？而不是纯技术炫技。”

4.2 面试官高频追问

Q1：技术合伙人和纯技术负责人的最大区别是什么？

「纯技术负责人的 KPI 是系统性能、可用性、交付速度。技术合伙人的 KPI 是公司是否赚钱——你不只要把系统做好，还要想这个系统能不能让用户付费、让商家入驻、让商业模式跑通。这个视角转变让我在做 TripPlan 时，第一考虑的不是用什么技术，而是『这个产品解决了谁的什么问题，用户为什么愿意付费』。然后才是技术如何支撑这个商业逻辑。」

Q2：Netty 自研设备接入层为什么不用现成的 IoT 平台？

「成本和使用场景。当时市面上 IoT 平台要么太贵、要么不支持我们的设备协议。而且自研的好处是后续定制灵活——我们设备有特殊的心跳机制和固件升级需求，自研可以深度优化。Netty 作为 NIO 框架，处理 TCP 长连接的并发能力足够强，单机支撑几千到上万连接没问题。」

Q3：设备断连和心跳机制怎么设计的？

「设备网络环境复杂，断连是常态。我们设计了三层机制：第一层是心跳检测——设备每 30 秒发一次心跳，服务端 90 秒没收到就判定离线；第二层是断线重连——Netty 的 IdleStateHandler 检测到空闲后主动断开，客户端指数退避重连（1s、2s、4s…最大 30s）；第三层是会话恢复——重连后根据设备 ID 恢复上下文，用户无需重新扫码。这套机制让设备在线率从 85% 提升到 98%。」

Q4：支付分账系统的设计难点在哪？

「技术不难，难的是业务规则设计。分账涉及三方：平台、商家、代理商。核心问题是：分账比例怎么定？结算周期多长？退款时已分账的钱怎么追回？我们最终方案是：T+1 结算（隔天到账），退款时先从平台账户垫付，再从商家后续收入扣除。技术上用了一个『待结算账户』的中间状态，资金先冻结，结算周期过后才真正划转。这个设计避免了退款时的资金纠纷。」

4.3 踩坑与反思

坑	反思
设备心跳间隔设太短（10秒），导致服务器压力过大	改为 30 秒 + 90 秒超时，平衡实时性和服务器压力
分账逻辑一开始写死在代码里，商家要求调整比例就很麻烦	抽象为可配置的分账规则引擎，支持按商家/设备类型/时段差异化配置
没有做设备状态持久化，服务重启后所有设备显示离线	增加 Redis 缓存设备状态，服务重启后从 Redis 恢复

4.4 与 JD 连线

JD 要求	创业经验对应
创业视角	技术合伙人，对商业模式和收入直接负责
从 0 到 1	完整经历了产品定义→技术落地→商业化验证
支付系统	在线支付分账系统，月流水破百万
技术选型	Netty 自研设备接入层，基于实际业务需求决策

五、项目交叉对比追问

面试官可能会问的连接不同项目的问题：

Q1：TripPlan 和 AI 客服两个 Agent 项目，设计思路上最大的不同是什么？

「最大的不同是 LLM 在系统中的角色权重。TripPlan 中 LLM 是核心引擎——行程创意生成严重依赖 LLM 的理解和推理能力。AI 客服中 LLM 更多是协调者——它负责意图识别和调用 RAG/插件，但知识来自检索而非生成。所以 TripPlan 的 Prompt Engineering 和幻觉控制更重，AI 客服的检索质量和路由逻辑更关键。」

Q2：你在携程做的高并发经验，对 AI 项目有什么实际帮助？

「太多了。举三个例子：第一，TripPlan 的订单状态机设计直接复用了携程的状态机设计模式；第二，支付 Adapter 模式来自 GDS 对接多家供应商的经验；第三，做数据库设计和索引优化时，我第一反应就是梳理核心查询场景——这是携程分库分表踩坑换来的肌肉记忆。高并发经验最大的价值是让你对『系统会怎么坏』有预判能力，在设计阶段就避开这些坑。」

Q3：你做过 Java 大型系统，又做过 Python AI 项目，选型经验是什么？

「Java 适合复杂业务逻辑和支付交易场景——类型安全、成熟的微服务生态、运维工具链。Python 适合 AI 场景——库生态丰富（LlamaIndex、LangChain）、开发效率高、FastAPI 异步性能不差。我的选型原则是：涉及资金安全和复杂状态管理的用 Java，涉及 LLM 交互和快速迭代的用 Python。TripPlan 之所以全用 Python，是因为它规模可控且需要大量 LLM 交互；如果交易量上到千万级，我可能会把支付服务独立出来用 Java。」

六、常见项目面试陷阱提醒

陷阱	应对
“这个项目你一个人做的？”	诚实说明架构设计由你主导，工程落地采用 AI Coding 辅助，强调为什么选这个方案而非”我自己牛逼”
“你觉得这个项目最大的失败是什么？”	选一个真实的踩坑经历，展示复盘和改进能力，不要说”没有失败”
“如果重新做一次，你会怎么改？”	展示架构演进思维，说明当前方案的 trade-off 和理想方案的区别
“你用了 XX 技术，为什么不用 YY？”	不要贬低其他技术，客观说明场景适配：XX 更适合你的业务约束（成本/团队/时间/生态）
追问到技术细节答不上来	诚实说”这部分当时采用的默认配置/标准方案，没有深入优化”，然后转向你真正深入的部分

🤖

Vibe Coding 面试应对策略

来源：09_Vibe_Coding面试应对策略.md

Vibe Coding 面试应对策略

核心原则：不撒谎，但重新定义叙事框架。你做的是”AI 增强工程”，不是”假装手写代码”。

一、心态校准：你比你以为的强

你真实的贡献清单

维度	你的贡献	面试可防御性
业务建模	✅ 你定义了 6 类旅游资源、11 状态订单、定价公式	🟢 极强 — 这是架构师核心能力
架构设计	✅ 你拆分了 DDD 9 模块、定义了模块边界和依赖关系	🟢 极强 — 这是技术负责人核心能力
技术选型	✅ 你决定用 Token Bucket 而非固定窗口、Adapter 而非硬编码	🟢 极强 — 选型决策比写代码更有价值
Agent 工作流	✅ 你设计了三阶段流程和 LLM/代码职责边界	🟢 极强 — 这是 AI 产品核心能力
代码实现	⚠️ AI Coding 辅助，你指挥 AI 写	🟡 需要策略 — 见下文
调试排错	⚠️ 你能定位问题方向，但修复依赖 AI	🟡 需要策略 — 见下文

关键认知

对于”技术负责人”岗位，面试官最关心的排序是：

你能不能做正确的技术决策？（架构能力）→ ✅ 你能
你能不能把业务拆解成可落地的模块？（建模能力）→ ✅ 你能
你能不能带团队交付？（管理能力）→ ✅ 你能（携程 20+人）
你能不能自己写代码？（编码能力）→ ⚠️ 需要策略

前 3 项占技术负责人评估权重的 70%+。第 4 项是”必要但不充分”条件。

二、简历措辞调整说明（已完成）

修改前	修改后	理由
LLM Agent 实战落地	LLM Agent 架构设计与工程化实践	“实战落地”暗示手写代码，”工程化实践”更准确
实现完整在线支付分账系统	设计在线支付分账系统	你设计了架构，AI 辅助实现
实现三层约束求解引擎	设计三层约束求解引擎	算法是你设计的，代码是 AI 辅助生成的
核心优势第四条：Java + Python 双修	AI 增强工程实践：熟练运用 AI Coding 工具	主动亮出 AI Coding 能力，变被动为主动
核心技能无 AI Coding	新增 AI 增强工程类别	将 vibe coding 转化为正面卖点

三、面试中的三大风险场景及应对

🔴 风险场景 1：白板手写代码

面试官：「能不能在白板上写一下约束求解引擎的时间重叠检测？」

应对策略：

❌ 不要：假装能写，然后卡住
✅ 要做：坦诚 + 展示理解深度

话术模板：

「我平时用 AI Coding 工具辅助实现，手写代码不是我的强项。但我可以画一下算法逻辑——」

（画扫描线流程图）

「核心思路是：把每个 Segment 按 start_time 排序，然后线性扫描，如果当前 Segment 的 start_time < 前一个的 end_time，就检测到重叠。时间复杂度 O(nlogn)，瓶颈在排序。我还可以写一下伪代码——」

segments.sort(key=lambda s: s.start_time) for i in range(1, len(segments)): if segments[i].start < segments[i-1].end: return Conflict(segments[i-1], segments[i]) return None

关键：伪代码比完美代码更有说服力——它证明你理解算法，而不是背代码。

🔴 风险场景 2：「这个项目你写了多少代码？」

面试官：「TripPlan 这个项目，代码量大概多少？你自己写了多少？」

应对策略：

❌ 不要：撒谎说”全部自己写的”
✅ 要做：主动介绍 AI Coding 工作流

话术模板：

「TripPlan 大约 15000 行 Python 代码。我采用 AI Coding 工作流——我负责架构设计、模块拆分、接口定义和核心算法设计，然后用 Cursor/Trae 辅助实现。具体来说，我会先写好接口定义和类型注解，AI 生成实现代码，我 Review 和调整。」

「这种方式在创业场景下特别高效——一个人就能完成原本需要 3-4 人的工作量。而且因为架构是我设计的，每一行代码我都理解它的设计意图。」

「我认为这也是未来技术负责人的重要能力——不是自己写多少代码，而是能不能用 AI 工具放大自己的架构决策力。」

关键：把”不会写代码”重新定义为”会用 AI 放大产出”。

🔴 风险场景 3：「如果 AI 工具不可用，你能独立完成吗？」

面试官：「如果不用 AI Coding，你能独立完成这些项目吗？」

应对策略：

❌ 不要：说”不能”或含糊其辞
✅ 要做：区分”能不能”和”效率”

话术模板：

「能，但效率会低很多。我有 12 年 Java 后端经验，携程期间所有代码都是手写的。Python 方面，FastAPI 的异步编程模式我理解，但手写速度不如用 AI 辅助快。」

「但我想强调一点——在咱们这个岗位上，技术负责人最重要的不是手写代码的速度，而是架构决策的正确性。我设计的 DDD 模块划分、状态机、约束求解器，这些是 AI 无法替代的。AI 能帮我更快地把设计变成代码，但设计本身必须由人来做。」

「而且说实话，如果加入咱们团队，我也会推动团队采用 AI Coding 工具——这是行业趋势，能显著提升团队效率。」

关键：用携程 12 年手写代码经验作为”能力底座”证明，AI Coding 是”效率倍增器”而非”能力替代品”。

四、必须能回答的 10 个深度问题

这些问题面试官一定会问，你必须能不看笔记、流畅回答：

架构决策类（你的强项，必须满分）

为什么用 DDD 而不是传统 MVC？ → 模块边界清晰，9 个模块各自独立演进，不会出现”大泥球”
为什么状态机要 11 个状态而不是 5 个？ → 5 个状态无法区分”已付定金”和”已付全款”，对资金安全有风险
为什么用 Token Bucket 而不是固定窗口？ → 允许突发流量，同时长期速率可控
为什么四层限流而不是两层？ → 全局保护系统、用户防恶意、会话控成本、渠道差异化
为什么 LLM 和代码要职责分离？ → LLM 有幻觉，价格/状态/资金必须由确定性代码控制

实现细节类（需要准备，但可以坦诚）

Redis + Lua 限流脚本的逻辑？ → 读取令牌数+上次填充时间→计算填充→判断→扣减/拒绝（你已准备过）
Stripe Webhook 怎么保证幂等？ → 用 PaymentIntent ID 做幂等键，重复 Webhook 不重复处理
RAG 召回率低怎么办？ → 调 chunk size/overlap、换 embedding 模型、加 keyword 检索混合
Agent 幻觉怎么控制？ → Function Calling 约束输出格式 + 约束求解引擎二次校验 + 人工确认环节
订单状态机怎么防并发冲突？ → 乐观锁（version 字段）+ 状态转移前置校验

对于 6-10，如果被追问实现细节

通用话术：「这个设计的思路我是清楚的，具体实现上我用了 AI Coding 辅助。如果让我手写，我可能需要查一下 API 文档，但设计逻辑我可以画出来——」

针对每个问题的补充策略：

Q6 Redis + Lua 限流：可以画令牌桶填充逻辑的流程图，标注关键变量（last_fill_time, current_tokens, fill_rate）

Q7 Stripe Webhook 幂等：画出幂等检查流程：收到 Webhook → 提取 PaymentIntent ID → 查数据库是否处理过 → 是则跳过，否则处理

Q8 RAG 召回优化：列出三个调优方向：chunk 策略、embedding 模型、混合检索，并说明你用的是哪个方向

Q9 Agent 幻觉控制：画三层防护流程图：Function Calling 约束 → 约束求解引擎校验 → 人工确认

Q10 订单状态机并发：画乐观锁流程：读取 version → 执行状态转移 → UPDATE WHERE version = 旧值 → 检查影响行数

五、主动亮出 AI Coding 的最佳时机

不要等面试官发现，主动在合适时机展示。

时机 1：自我介绍中

「创业期间，我采用了 AI Coding 工作流——我负责架构设计和核心算法，AI 辅助代码实现。这让一个人就能完成传统 3-4 人的工作量，也让我更专注于架构决策和业务建模。」

时机 2：被问”你的开发效率怎么样”时

「用 AI Coding 工具后，我的交付效率是传统方式的 3-5 倍。TripPlan 从 0 到 MVP 大约 2 个月，如果纯手写可能需要 6 个月。」

时机 3：被问”你怎么看 AI 对开发的影响”时

「我认为 AI Coding 是技术负责人的效率倍增器。它能替代编码执行，但替代不了架构决策。我设计的约束求解引擎——为什么用扫描线而不是暴力比较、为什么四层限流而不是两层——这些决策 AI 做不了。AI 帮我把决策变成代码更快，但决策本身必须由人来做。」

时机 4：被问”你如何保持技术竞争力”时

「我持续关注 AI 辅助开发的最佳实践，并将其融入日常工作流。比如我研究了不同 LLM 在代码生成上的优劣，总结出’先定义接口和类型、再让 AI 填充实现’的工作模式。这种能力——知道如何正确使用 AI 工具——我认为是未来工程师的核心竞争力之一。」

时机 5：被问”如果入职，你打算怎么带团队”时

「我会推动团队采用 AI Coding 工具，但前提是建立规范——比如代码 Review 必须人工过、核心架构决策必须团队讨论、AI 生成的代码必须理解后才能合并。AI 能提升团队效率，但不能替代工程师的判断力。」

六、绝对不能做的事

❌ 禁忌	原因
说”全部代码自己手写”	面试官一问细节就露馅，诚信崩塌比能力不足更致命
贬低 AI Coding（”只是辅助”）	自相矛盾，且浪费了一个正面卖点
过度强调 AI Coding（”AI 写了 90%”）	面试官会怀疑你的技术深度
被问到不会的实现细节时硬编	编造的技术细节经不起追问
回避”你写了多少代码”的问题	回避 = 心虚，坦诚 = 自信

七、底线策略：如果面试官明确要求手写代码

先问清楚考察目的：「您主要想看算法理解还是编码熟练度？」
如果是算法理解 → 写伪代码 + 画流程图，展示你理解核心逻辑
如果是编码熟练度 → 坦诚：「我平时用 AI Coding 辅助，手写速度不快，但逻辑我清楚。我可以写伪代码，或者用 AI 辅助完成这段代码，然后我解释每一行的作用。」
最坏情况 → 写不出来时说：「这个 API 我记得大概，但具体参数需要查文档。如果是在实际工作中，我会用 AI 辅助 + 文档快速完成。」

八、你的核心叙事框架

面试中所有回答都围绕这个框架：

我是"架构师型技术负责人"
```ascii
├── 我做正确的设计决策（DDD / 状态机 / 约束求解 / 限流策略）
├── 我用 AI Coding 放大执行效率（1人 = 3-4人产出）
├── 我理解每一行代码的设计意图（因为设计是我做的）
└── 我有 12 年手写代码经验作为能力底座（携程千万级系统）

```

一句话总结：「我负责做 AI 做不了的决策，AI 帮我做我能做但更高效的执行。」

📚

核心技能学习素材

来源：10_核心技能学习素材.md

核心技能学习素材

本文档针对简历中列出的核心技能，提供面试可用的知识点速查。
标注 ⚡ 的为高频追问点，必须能流畅回答。

一、AI/LLM 技能

1.1 LLM Agent 架构设计 ⚡

核心概念：
- Agent = LLM + Tools + Memory + Planning
- LLM 负责”理解”和”决策”，Tools 负责”执行”，Memory 负责”上下文”，Planning 负责”分解任务”

你项目中的体现：
- TripPlan 三阶段工作流：需求收集（LLM NLU）→ 行程规划（Function Calling）→ 迭代优化
- AI 客服：意图路由 → RAG 检索 / 插件调用 → 生成回答

面试高频问题：

Q: Agent 和普通 Chatbot 有什么区别？

Agent 能主动调用工具、维护状态、多步推理。Chatbot 只是对话，没有执行能力。

Q: 你的 Agent 架构中，LLM 和代码的职责边界是什么？

LLM 负责理解用户意图、生成创意内容、做非确定性决策。代码负责价格计算、状态管理、约束校验、资金操作——这些必须确定性保证。

1.2 Function Calling ⚡

核心概念：
- LLM 不直接执行操作，而是输出结构化的”工具调用请求”
- 后端解析请求，执行实际操作，返回结果给 LLM
- LLM 基于结果生成最终回答

工作流程：

用户输入 → LLM 理解意图 → 输出 Function Call
```ascii
    → 后端执行函数 → 返回结果 → LLM 生成回答


**你项目中的体现**：
- TripPlan：LLM 调用 `query_resources()`、`check_constraints()`、`calculate_price()` 等工具
- AI 客服：LLM 调用 `search_knowledge_base()`、`query_order()` 等工具

**关键设计点**：
- 工具定义要清晰（参数类型、返回格式）
- 敏感操作（支付、下单）需要用户确认，不能 Agent 自动执行
- 工具返回的数据必须是真实的，LLM 不能编造

**面试高频问题**：

Q: Function Calling 和直接让 LLM 输出 JSON 有什么区别？
> Function Calling 是标准化的协议，LLM 经过专门训练，输出格式更可靠。直接输出 JSON 容易格式错误、字段遗漏。

Q: 如果 Function Calling 返回错误怎么办？
> 设计 fallback 机制：错误信息返回给 LLM，LLM 可以重试或换其他工具；多次失败后转人工。

---

### 1.3 RAG（检索增强生成）⚡ {#ch10-1-3-rag-检索增强生成}
**核心概念**：
- **RAG = Retrieval + Augmentation + Generation**
- 先从知识库检索相关内容，再把检索结果作为上下文喂给 LLM，让 LLM 基于事实生成回答

**技术栈**：
- **LlamaIndex**：RAG 框架，提供文档加载、分块、索引、检索的完整流水线
- **Qdrant**：向量数据库，存储文档的向量表示，支持相似度检索
- **BGE（BAAI/bge-large-zh-v1.5）**：中文 Embedding 模型，把文本转成向量

**工作流程**：

离线：
文档 → SentenceSplitter 分块 → BGE Embedding → Qdrant 存储

在线：
用户问题 → BGE Embedding → Qdrant 相似度检索 top_k

    → 检索到的 chunks + 用户问题 → LLM → 生成回答


**你项目中的体现**：
- AI 客服：企业知识库问答，检索产品手册、FAQ、政策文档

**关键参数**：
- `chunk_size=500`：每块约 500 字符
- `overlap=50`：相邻块有 50 字符重叠，避免信息断裂
- `top_k=5`：检索最相关的 5 个文档块

**面试高频问题**：

Q: 为什么用 BGE 而不是 OpenAI 的 Embedding？
> BGE 专门针对中文优化，在中文场景下效果更好。OpenAI 的 Embedding 是通用的，中文效果不如 BGE。

Q: RAG 召回不准确怎么办？
> 三个调优方向：
> 1. 调整分块策略（chunk_size、overlap）
> 2. 换更好的 Embedding 模型
> 3. 加混合检索（BM25 关键词 + 向量语义）

Q: 如何防止 LLM 超出检索结果范围？
> 在 Prompt 中明确要求："仅基于以下参考内容回答，如果没有相关信息请诚实说明不知道"

---

### 1.4 Prompt Engineering {#ch10-1-4-prompt-engineering}
**核心技巧**：
- **角色设定**：让 LLM 扮演特定角色
- **任务分解**：把复杂任务拆成多个步骤
- **输出格式约束**：要求 LLM 输出 JSON、Markdown 等结构化格式
- **示例引导**：给出输入输出的示例
- **边界约束**：明确什么不能做

**你项目中的体现**：
- TripPlan：约束 LLM 只从数据库返回的资源中选择，不能编造景点/价格
- AI 客服：要求 LLM 基于检索结果回答，不能超出知识库范围

**面试高频问题**：

Q: 你的 Prompt 设计原则是什么？
> 清晰、具体、有边界。告诉 LLM 要做什么、不做什么、输出什么格式。避免模糊指令。

---

### 1.5 MCP 协议 {#ch10-1-5-mcp-协议}
**核心概念**：
- **MCP（Model Context Protocol）**：标准化的工具调用协议
- 让 LLM 能调用外部工具（API、数据库、文件系统等）
- 类似于"LLM 的 USB 接口"

**你项目中的体现**：
- AI 客服：通过 MCP 暴露企业内部 API（查订单、查物流、查库存）

**关键优势**：
- 标准化：新增工具不需要改 Agent 代码，只需实现 MCP Server
- 可扩展：支持多种工具类型（API、数据库、文件等）

**面试高频问题**：

Q: MCP 和 Function Calling 有什么区别？
> Function Calling 是 LLM 输出工具调用的方式，MCP 是工具注册和调用的标准协议。MCP 可以配合 Function Calling 使用。

---

### 1.6 意图路由 {#ch10-1-6-意图路由}
**核心概念**：
- 用户输入 → 判断意图 → 分发到不同处理流程
- 常见意图：知识问答、插件调用、人工转接、闲聊

**你项目中的体现**：
- AI 客服：规则引擎 + LLM 双层路由

**双层路由设计**：

用户输入
↓
规则引擎（零延迟、零成本）

  ├─ 关键词匹配："退款" → 人工转接
  ├─ 正则匹配：问句特征 → 知识问答
  └─ 未匹配 → LLM 分类
       ↓

LLM 意图分类（处理模糊场景）

  └─ 置信度低 → fallback 到默认策略


**面试高频问题**：

Q: 为什么用双层路由而不是只用 LLM？
> 三个原因：
> 1. 延迟：规则引擎毫秒级，LLM 需要 2-5 秒
> 2. 成本：规则引擎零成本，LLM 消耗 token
> 3. 可靠性：规则引擎 100% 确定性，LLM 可能误判

---

### 1.7 幻觉控制策略 ⚡ {#ch10-1-7-幻觉控制策略}
**核心问题**：
- LLM 可能"一本正经地胡说八道"，编造不存在的信息
- 在交易场景中，幻觉会导致严重的资金/法律风险

**控制策略**：

| 策略 | 实现方式 | 你项目中的体现 |
|------|---------|--------------|
| 输入约束 | 缩小 LLM 的发挥空间 | NLU 提取结构化画像，限定参数范围 |
| Function Calling 约束 | LLM 只能调用预定义的工具 | 资源/价格只能从数据库查询 |
| 系统校验 | 后端二次验证 LLM 输出 | 约束求解引擎校验行程可行性 |
| 人工审核 | 关键操作需要人工确认 | 订单进入 Reviewing 状态 |
| Prompt 约束 | 明确要求"不知道就说不知道" | "如果没有相关信息请诚实说明" |

**面试高频问题**：

Q: 你的项目中幻觉控制是怎么做的？
> 三层防护：
> 1. Function Calling 约束：LLM 只能从数据库查询结果中选择，不能编造
> 2. 约束求解引擎：校验时间冲突、预算超支等，不合法的方案拦截
> 3. 人工审核：高客单价订单需要人工确认后才能支付

---

## 二、Python 技术栈 {#ch10-二-python-技术栈}
### 2.1 FastAPI 异步 ⚡ {#ch10-2-1-fastapi-异步}
**核心概念**：
- **async/await**：异步编程语法，不阻塞等待 I/O 操作
- **ASGI**：异步服务器网关接口，FastAPI 基于 ASGI
- **适合场景**：高延迟 I/O 操作（数据库、API 调用、LLM 调用）

**为什么 AI 项目用 FastAPI**：
- LLM API 调用延迟高（5-30 秒），同步会阻塞整个服务
- 异步可以同时处理多个请求，提高并发能力
- 流式输出（逐 token 推送）需要异步支持

**关键代码模式**：
```python
# 异步路由 {#ch10-异步路由}
@app.post("/chat")
async def chat(request: ChatRequest):
```ascii
    response = await llm_client.generate(request.message)  # 异步调用 LLM
    return {"response": response}

异步数据库

async with async_session() as session:

    result = await session.execute(query)


**面试高频问题**：

Q: FastAPI 和 Flask 有什么区别？
> FastAPI 原生支持异步、自动生成 API 文档、有类型校验（Pydantic）。Flask 是同步框架，需要额外配置才能异步。

Q: 什么时候用 async，什么时候用同步？
> I/O 密集型操作（网络请求、数据库、文件读写）用 async。CPU 密集型计算用同步，因为 Python 的 GIL 限制，异步对 CPU 计算没有帮助。

---

### 2.2 Pydantic v2 {#ch10-2-2-pydantic-v2}
**核心概念**：
- **数据验证**：自动校验数据类型、格式、范围
- **序列化**：自动转换 Python 对象和 JSON
- **API 文档**：FastAPI 自动生成 OpenAPI 文档

**关键用法**：
```python
from pydantic import BaseModel, Field
from datetime import date
from typing import Optional

class TravelerProfile(BaseModel):
```ascii
    group_size: int = Field(..., ge=1, le=20)  # 1-20人
    date_range: tuple[date, date]
    budget_usd: Optional[float] = Field(None, gt=0)  # 可选，必须大于0
    interests: list[str] = Field(default_factory=list)


**你项目中的体现**：
- TripPlan：定义 TravelerProfile、Itinerary、Quotation 等数据模型
- AI 客服：定义 ChatRequest、ChatResponse、Intent 等数据模型

**面试高频问题**：

Q: Pydantic 和 dataclass 有什么区别？
> Pydantic 有数据验证、JSON 序列化、API 文档生成。dataclass 只是数据容器，没有这些功能。

---

### 2.3 SQLAlchemy async {#ch10-2-3-sqlalchemy-async}
**核心概念**：
- SQLAlchemy 的异步版本，配合 async/await 使用
- 支持异步连接池、异步查询

**关键用法**：
```python
from sqlalchemy.ext.asyncio import create_async_engine, AsyncSession

engine = create_async_engine("postgresql+asyncpg://...")
async_session = sessionmaker(engine, class_=AsyncSession)

async with async_session() as session:
```ascii
    result = await session.execute(select(User).where(User.id == 1))
    user = result.scalar_one()


**面试高频问题**：

Q: 为什么用 SQLAlchemy 而不是原生 SQL？
> ORM 提供类型安全、避免 SQL 注入、方便迁移。但复杂查询可能还是需要原生 SQL。

---

## 三、架构设计 {#ch10-三-架构设计}
### 3.1 DDD 领域驱动设计 ⚡ {#ch10-3-1-ddd-领域驱动设计}
**核心概念**：
- **领域**：业务问题的范围
- **限界上下文**：领域内的边界，不同上下文有不同的模型
- **聚合**：一组相关对象的集合，保证事务一致性
- **领域服务**：不属于任何实体的业务逻辑

**你项目中的体现**：
- TripPlan 拆分为 9 个模块：需求收集、行程引擎、约束求解、定价服务、订单服务、支付服务、审核服务、资源管理、用户管理

**为什么用 DDD**：
- 模块边界清晰，各自独立演进
- 业务逻辑集中在领域层，不分散在 Controller/Service
- 便于团队协作，不同人负责不同模块

**面试高频问题**：

Q: DDD 和 MVC 有什么区别？
> MVC 是技术分层（Controller/Service/Repository），DDD 是业务分块。DDD 更适合复杂业务，MVC 更适合简单 CRUD。

Q: 你的项目中 DDD 是怎么落地的？
> 1. 识别核心领域（行程规划、订单、支付）
> 2. 定义领域模型（Itinerary、Order、Payment）
> 3. 划分模块边界，定义模块间接口
> 4. 每个模块有自己的数据模型和业务逻辑

---

### 3.2 状态机设计 ⚡ {#ch10-3-2-状态机设计}
**核心概念**：
- **状态**：对象在某一时刻的情况
- **转移**：从一个状态到另一个状态
- **事件**：触发状态转移的条件
- **守卫**：状态转移的前置条件

**你项目中的体现**：
- TripPlan：11 状态订单状态机
- 状态：Draft → Confirmed → DepositPaid → Reviewing → Approved → InService → Completed
- 还有取消分支：Cancelled → Refunding → Refunded

**设计原则**：
- 每个状态只能转移到预定义的后继状态
- 用字典映射实现 O(1) 判断
- 所有合法/非法转移都要写测试覆盖

**面试高频问题**：

Q: 为什么用状态机而不是简单的状态字段？
> 状态机保证状态转移的合法性，防止非法跳转。比如不能从 Draft 直接跳到 Completed，必须经过 Confirmed → DepositPaid → Reviewing。

Q: 如何防止并发冲突？
> 乐观锁：在数据库表中加 version 字段，更新时检查 version 是否变化。

---

### 3.3 Adapter 模式 {#ch10-3-3-adapter-模式}
**核心概念**：
- 把一个类的接口转换成客户端期望的另一个接口
- 让原本不兼容的类可以一起工作

**你项目中的体现**：
- TripPlan：PaymentGateway 接口，StripeAdapter 实现
- 未来可以加 WechatPayAdapter、AlipayAdapter

**面试高频问题**：

Q: 为什么用 Adapter 而不是直接调用 Stripe SDK？
> 解耦。如果以后要换支付渠道，只需要加一个新的 Adapter，订单系统代码不用改。

---

### 3.4 Protocol 协议编程 {#ch10-3-4-protocol-协议编程}
**核心概念**：
- Python 的 Protocol 是一种结构化子类型
- 不需要显式继承，只要实现了 Protocol 定义的方法就是兼容类型

**关键用法**：
```python
from typing import Protocol

class PaymentGateway(Protocol):
```ascii
    async def create_payment(self, amount: float, currency: str) -> str: ...
    async def confirm_payment(self, payment_id: str) -> bool: ...

class StripeAdapter:

    async def create_payment(self, amount: float, currency: str) -> str:
        # Stripe 实现
        pass

StripeAdapter 自动满足 PaymentGateway Protocol


**面试高频问题**：

Q: Protocol 和抽象类有什么区别？
> Protocol 不需要显式继承，更灵活。抽象类需要显式继承，更严格。

---

## 四、数据与中间件 {#ch10-四-数据与中间件}
### 4.1 Qdrant 向量数据库 {#ch10-4-1-qdrant-向量数据库}
**核心概念**：
- 存储向量的数据库，支持相似度检索
- 适合 RAG、推荐系统、语义搜索

**关键操作**：
```python
from qdrant_client import QdrantClient

client = QdrantClient(":memory:")  # 内存模式，测试用

# 插入向量 {#ch10-插入向量}
client.upsert(
```ascii
    collection_name="documents",
    points=[
        {"id": 1, "vector": [0.1, 0.2, ...], "payload": {"text": "..."}}

)

检索相似向量

results = client.search(

    collection_name="documents",
    query_vector=[0.1, 0.2, ...],
    limit=5

)


**面试高频问题**：

Q: Qdrant 和 Elasticsearch 有什么区别？
> Qdrant 专门做向量检索，支持高维向量的相似度搜索。Elasticsearch 主要是全文检索，向量检索是后来加的功能。

---

### 4.2 Redis 应用场景 {#ch10-4-2-redis-应用场景}
**常见用途**：
- 缓存：热点数据缓存
- 会话存储：用户登录状态
- 限流：Token Bucket 令牌桶
- 分布式锁：SETNX

**你项目中的体现**：
- AI 客服：四层限流、会话缓存
- TripPlan：热点数据缓存

**面试高频问题**：

Q: Redis 和 Memcached 有什么区别？
> Redis 支持更多数据类型（String、Hash、List、Set、ZSet）、支持持久化、支持 Lua 脚本。Memcached 只支持简单的 key-value。

---

## 五、支付与交易 {#ch10-五-支付与交易}
### 5.1 Stripe 集成 ⚡ {#ch10-5-1-stripe-集成}
**核心概念**：
- **PaymentIntent**：代表一次支付意图，包含金额、货币、状态
- **Webhook**：Stripe 主动通知支付状态变化
- **确认流程**：创建 PaymentIntent → 用户支付 → Webhook 通知 → 更新订单状态

**关键流程**：

创建 PaymentIntent（后端）

   POST /v1/payment_intents
   {amount: 10000, currency: "usd"}

返回 client_secret（给前端）
前端调用 Stripe SDK 完成支付
Stripe 发送 Webhook 到后端

   POST /webhook
   {type: "payment_intent.succeeded", data: {...}}

后端验证签名、更新订单状态


**面试高频问题**：

Q: Webhook 怎么保证幂等？
> 用 PaymentIntent ID 做幂等键。收到 Webhook 后先查数据库是否已处理过，处理过就跳过。

Q: Webhook 怎么验证是 Stripe 发的？
> Stripe 用密钥签名，后端用密钥验证签名。不是 Stripe 发的请求签名验证会失败。

---

### 5.2 动态定价引擎 {#ch10-5-2-动态定价引擎}
**你项目中的体现**：
- 公式：`总价 = Σ(基准价格 × 季节系数 × 数量)`
- 支持 6 类资源分项计价
- 支持多币种转换

**面试高频问题**：

Q: 定价为什么不让 LLM 做？
> LLM 会算错。定价必须精确，由确定性代码计算。LLM 只负责选择资源组合。

---

## 六、工程与运维 {#ch10-六-工程与运维}
### 6.1 Docker Compose {#ch10-6-1-docker-compose}
**核心概念**：
- 定义和运行多容器应用
- docker-compose.yml 定义服务、网络、卷

**关键命令**：
```bash
docker-compose up -d      # 后台启动
docker-compose down       # 停止并删除
docker-compose logs -f    # 查看日志

面试高频问题：

Q: Docker Compose 和 Kubernetes 有什么区别？

Docker Compose 适合单机部署，简单易用。Kubernetes 适合分布式集群，功能更强大但复杂度高。

6.2 OpenTelemetry

核心概念：
- 分布式追踪标准
- TraceId 贯穿整个请求链路
- Span 代表一个操作单元

你项目中的体现：
- AI 客服：全链路 TraceId，方便排查问题

面试高频问题：

Q: OpenTelemetry 解决什么问题？

分布式系统中，一个请求可能经过多个服务。OpenTelemetry 通过 TraceId 把所有服务的日志串联起来，方便排查问题。

七、快速记忆口诀

Agent 架构

LLM 做大脑，代码做脊梁
- LLM：理解、创意、非确定性决策
- 代码：价格、状态、资金、约束校验

RAG 流程

分块 → 向量化 → 存储 → 检索 → 生成
- 分块：SentenceSplitter
- 向量化：BGE Embedding
- 存储：Qdrant
- 检索：相似度 top_k
- 生成：LLM + chunks

幻觉控制

输入约束 + Function Calling + 系统校验 + 人工审核
- 缩小 LLM 发挥空间
- LLM 只能调用预定义工具
- 后端二次验证
- 关键操作人工确认

状态机设计

状态有限、转移有向、测试覆盖
- 每个状态只能转移到预定义的后继状态
- 用字典映射 O(1) 判断
- 所有合法/非法转移都要测试

八、面试应对策略

如果被问到不会的技术细节

话术模板：

「这个技术我了解核心原理，具体实现上我用了 AI Coding 辅助。如果让我手写，我可能需要查一下文档，但设计逻辑我可以画出来——」

然后：
1. 画出流程图或架构图
2. 说明核心原理
3. 强调你理解”为什么这样设计”

如果被问到”你真的懂这个技术吗？”

话术模板：

「我理解这个技术的核心原理和适用场景。具体 API 的参数细节，我平时用 AI Coding 辅助快速查阅。我认为更重要的是理解’为什么用这个技术’、’它解决什么问题’、’有什么 trade-off’——这些我都能回答。」

如果被问到”这个技术有什么缺点？”

通用回答框架：

「每个技术都有 trade-off。XX 技术的优点是…，但缺点是…。所以在我的项目中，我采取的策略是…（如何规避缺点或做权衡）。」

面试准备材料合集

岗位画像与关键词分析

🎯 目标岗位画像与关键词匹配分析

岗位基本信息

一票否决项（必须具备）

核心硬技能关键词（按优先级排序）

核心软实力关键词

你的独特竞争优势（差异化卖点）

卖点1：稀缺的「大厂高并发 × AI Agent实战」复合背景

卖点2：真正的「Agent × 交易闭环」实践经验

卖点3：技术合伙人级别的创业视角

简历优化策略总览

策略1：重排项目顺序——把AI项目前置

策略2：用JD语言重写项目描述

策略3：强化”技术负责人/合伙人”身份

策略4：个人优势看板重新定位

优化后简历

吴来

核心优势

教育背景

工作经历

创业经历 | 技术负责人/技术合伙人 2024.10 - 至今

共享设备智能运营平台（技术合伙人）

TripPlan — AI 定制游行程规划 SaaS（LLM Agent × 交易闭环）

AI 智能客服系统（多渠道 Agent 平台）

SGS（通标标准技术服务有限公司）| 技术经理 2024.05 - 2024.10

携程计算机技术有限公司 | 资深研发经理 2012.04 - 2024.01

中国金融在线 | 高级开发工程师 2011.06 - 2012.04

核心技能

自我介绍（多版本）

面试自我介绍（针对 AI+消费产品技术负责人岗位）

版本一：标准版（2 分钟，最常用 — 推荐 HR/技术主管一面）

版本二：精简版（1 分钟，时间紧 / 快速轮次时用）

版本三：突出创业视角版（面对创始人/CEO/CTO — 强烈推荐）

版本四：技术深度版（面对纯技术型面试官 / CTO）

自介绍使用指南

介绍的黄金结构

⚠️ 常见错误

高频 Q&A 话术库

高频面试 Q&A 话术库（针对 AI+消费产品技术负责人岗位）

一、AI Agent 与交易闭环类（JD 核心方向，必考）

Q1: 请重点介绍一下你的 TripPlan 项目？ ⭐⭐⭐⭐⭐

Q2: LLM Agent 在交易场景中落地，最大的技术挑战是什么？你怎么解决的？ ⭐⭐⭐⭐⭐

Q3: 你怎么理解”AI 驱动供需匹配”？在你的项目中是怎么体现的？ ⭐⭐⭐⭐⭐

Q4: 你的 Agent 项目目前上线了吗？有多少用户？ ⭐⭐⭐⭐⭐

二、架构与技术选型类

Q5: 为什么选择 FastAPI 而不是 Java Spring Boot 来做 AI 项目？ ⭐⭐⭐⭐

Q6: 如果让你设计咱们公司的 AI+消费产品架构，你会怎么做？ ⭐⭐⭐⭐⭐

Q7: RAG 知识库是怎么实现的？如何保证检索质量？ ⭐⭐⭐⭐

三、高并发与系统设计类（携程经验的迁移价值）

Q8: 你在携程做的千万级订单系统重构，跟我们公司的场景有什么关联？ ⭐⭐⭐⭐

Q9: 如果日活达到百万级，你的 AI Agent 服务怎么扛住？ ⭐⭐⭐⭐

四、团队管理与创业视角类（JD 明确要求）

Q10: 你带过最大规模的团队是怎样的？怎么管理的？ ⭐⭐⭐⭐

Q11: 你怎么看”对技术结果负责”这句话？ ⭐⭐⭐⭐⭐

五、场景题 / 白板题

Q12: 如果让你设计一个”AI 导购助手”（用户对话式购物），你会怎么设计？ ⚡⚡⚡

技术深度问题应对

技术深度问题应对（白板 / 深度追问）

一、Agent 架构白板（最高频 ⚡⚡⚡）

Q1: 请画出 TripPlan 的完整系统架构图

四、迁移到目标公司场景的设计题

Q7: 如果让你把 Agent 能力嵌入咱们现有的 C 端交易链路，你会从哪里开始切入？

五、棘手问题的应对策略

Q8: “你的项目都没上线，怎么证明你能搞定生产环境？” ⚡

Q9: “你 Java 和 Python 都用，你觉得哪个更适合咱们公司？” ⚡

反问面试官问题清单

反问面试官问题清单（针对 AI+消费产品技术负责人岗位）

一、业务与战略类（问创始人/CEO/产品负责人）

1. 关于 Agent 落地路径

2. 关于供需匹配与商品结构化

3. 关于产品阶段与里程碑

二、技术与架构类（问 CTO/技术负责人）

4. 关于 AI 技术现状

5. 关于系统性能与扩展

6. 关于技术决策机制

三、团队与文化类

7. 关于角色定位

8. 关于创业阶段

四、根据面试官身份选择推荐组合

创业经历 | 技术负责人/技术合伙人 `2024.10 - 至今`

SGS（通标标准技术服务有限公司）| 技术经理 `2024.05 - 2024.10`

携程计算机技术有限公司 | 资深研发经理 `2012.04 - 2024.01`

中国金融在线 | 高级开发工程师 `2011.06 - 2012.04`