1. 澄清需求：用户规模、QPS、延迟要求、数据量
2. 明确系统类型：匹配 / 推荐 / 搜索 / 规划 / Agent
3. 画出架构：数据流 → 核心组件 → 外部依赖
4. 讨论挑战：性能 / 准确性 / 多样性 / 冷启动
5. 演进路线：MVP → 优化 → 规模化

需求澄清：
- 有多少教室？（100 / 10000）
- 查询 QPS？（10 / 1000）
- 延迟要求？（小于 100ms / 小于 1s）

方案设计：
1. 基础：SQL 查询（WHERE NOT EXISTS + 时间重叠判断）
   SELECT * FROM classrooms WHERE capacity >= ? AND floor = ?
   AND NOT EXISTS (SELECT 1 FROM bookings WHERE classroom_id = classrooms.id
                   AND (start, end) OVERLAPS (?, ?))
2. 优化：预计算可用时段矩阵（位图）
   - 每个教室一个 bitset，每位表示 15 分钟时段
   - 查询时做位运算（AND + 取反）
   - 适合高频查询，O(1) 查询
3. 扩展：缓存 + 增量更新
   - Redis 缓存热点查询
   - 预订变更时更新缓存（而不是全量重建）

追问应对：
- 1000 万用户同时查？则分片 + 缓存 + 预计算
- 有人临时取消？则异步更新缓存，保证最终一致性

核心问题：两人同时预订同一间会议室
1. 数据库层面：唯一约束 + 事务（SERIALIZABLE 隔离级别）
2. 应用层面：分布式锁（Redis SETNX）+ 乐观锁（版本号）
3. 冲突检测算法：时间区间重叠判断
   (start1 小于 end2) AND (start2 小于 end1)

重复预订处理：
- RRULE 标准（iCalendar RFC 5545）
- 异常情况：某天节假日跳过，则用例外列表

追问：
- 有人不来的检测？则签到机制 + 自动释放
- 会议室资源变动？则自动重分配 + 通知

匹配约束：
- 时间窗口（出发时间 ± 15 分钟）
- 路线相似度（起点/终点距离 小于 3km）
- 空位数 大于等于 乘客数
- 评分阈值

技术方案：
1. 空间索引：GeoHash / S2 网格，快速筛选附近
2. 路线匹配：DTW（动态时间规整）或简化为起点+终点距离
3. 实时匹配：乘客发布，广播到附近司机，司机响应，排序推荐

评分排序：
score = w1 × 路线匹配度 + w2 × 司机评分 + w3 × 时间接近度 + w4 × 价格

追问：
- 如何避免匹配后司机不来？则双向确认 + 超时重试
- 高峰期匹配率下降？则扩大搜索半径 + 动态调价

方案分层：
1. 硬规则层：学历、年限、技能关键词（SQL 过滤）
2. 语义匹配层：LLM 提取简历实体，与 JD 做语义相似度
3. 排序层：多特征综合评分

技术实现：
- 简历解析：LLM 提取（姓名/学历/技能/经历），结构化
- 匹配策略：
  - 精确匹配：技能名称、证书
  - 模糊匹配：相似技能（Python 和 PyTorch，相关度高）
  - 语义匹配：项目经历描述与 JD 的向量相似度

追问：
- 如何避免误筛？则人工复核边界候选人 + 反馈调优
- LLM 解析不一致？则 Schema 约束 + 结构化输出验证

过滤：出发地 + 目的地 + 日期（精确匹配）
排序：price, duration, departure_time, airline_rating

技术方案：
1. 数据源：航司 API / GDS 系统（Amadeus, Sabre）
2. 缓存：热门航线预计算（北京到上海，未来 7 天）
3. 排序：加权综合分 = w1 × price + w2 × duration + w3 × 偏好

追问：
- 航班变动怎么办？则推送通知 + 自动改签建议
- 多段联程？则图搜索（Dijkstra，节点是机场，边是航班）

推荐三阶段：
1. 召回（从 10 万，到 500）
   - 地理召回：用户 5km 内所有餐厅
   - 类目召回：火锅类/川菜/粤菜（用户偏好）
   - 热门召回：同城热门 Top 100
   - 语义召回：向量检索（"适合聚餐的火锅店"，语义匹配）
2. 排序（从 500，到 20）
   特征：
   - 用户特征：历史偏好、消费水平、常去时段
   - 餐厅特征：评分、距离、人均、标签
   - 交叉特征：用户-餐厅匹配度
   模型：LightGBM / 深度学习排序模型
3. 重排（从 20，到 5 展示）
   - 去重：同一品牌不连续出现
   - 多样性：不同价位、不同距离混合
   - 业务规则：新餐厅加权、广告插入

冷启动：
- 新用户：基于位置 + 热门榜单
- 新餐厅：内容特征（标签/图片）匹配相似用户

追问：
- 推荐结果太单一？则 MMR 多样性重排算法
- 用户抱怨推荐不准？则显式反馈（点赞/不感兴趣）+ 在线学习

核心架构：

召回层（多路召回，每路 500-1000）：
- 协同过滤：看了 A 的人也看了 B
- 内容召回：视频标签/分类匹配用户兴趣
- 热门召回：trending 视频
- 社交召回：关注的人点赞的视频
- 探索召回：5% 流量用于发现新兴趣

排序层：
- 特征工程：
  - 用户：历史行为序列、兴趣标签、活跃时段
  - 视频：时长、标签、发布者、质量分数
  - 上下文：时间、地点、网络环境
- 模型：DeepFM / DIN（深度兴趣网络）
- 目标：多目标优化（完播率 + 点赞率 + 分享率）

重排层：
- 打散：同类视频不连续出现
- 新鲜度：新视频一定比例曝光
- 多样性：不同类目混合

冷启动：
- 新视频：小流量探索，数据达标，进入主推荐池
- 新用户：引导选择兴趣，基于兴趣池推荐

实时反馈：
- 用户滑动行为实时采集（播放时长、滑动时机）
- 在线学习更新用户兴趣向量

追问：
- 信息茧房？则探索与利用（E&E）策略，固定比例探索
- 低质内容？则内容审核 + 质量分过滤

特色：音乐是强序列、强上下文的场景

技术方案：
1. 序列建模：用户历史听歌序列，用 Transformer/SASRec 预测下一首
2. 上下文感知：
   - 时段：早上推荐轻音乐，晚上推荐放松
   - 场景：运动则快节奏，工作则纯音乐
3. 探索与利用：
   - ε-greedy：90% 推荐已知兴趣，10% 探索新风格
   - Thompson Sampling：对新歌的不确定性建模

多模态特征：
- 音频特征：BPM、调性、能量值（从音频信号提取）
- 文本特征：歌词情感分析
- 社交特征：朋友在听什么

追问：
- 用户切歌怎么办？则负反馈实时响应，立刻降权同类
- 歌单推荐？则 Set Recommendation，考虑歌曲间的连贯性

核心挑战：新闻时效性强（几小时后就过时了）

技术方案：
1. 实时召回：新文章发布，实时推入召回池
2. 多兴趣建模：用户可能有多个兴趣（科技 + 体育 + 美食）
   - MIND 模型：多兴趣向量表示
   - 不同场景激活不同兴趣
3. 时效性衰减：
   - 新闻评分 = 基础分 × e^(-λ × 时间差)
   - 热点新闻衰减慢，普通新闻衰减快
4. 多样性：
   - 不同类目混合
   - 同一事件不同角度（报道/评论/分析）

追问：
- 假新闻怎么办？则可信度评分 + 来源权重
- 信息过载？则摘要生成 + 去重合并

技术方案：
1. 行为序列建模：
   - 浏览、加购、收藏、购买 的转化路径
   - Session-based Recommendation（GRU4Rec）
2. 实时特征：
   - 当前 session 行为（刚看了什么）
   - 短期兴趣（最近 1 小时）vs 长期兴趣（最近 30 天）
3. 多目标优化：
   - CTR（点击率）：用户会不会点
   - CVR（转化率）：点了会不会买
   - GMV 预估：买了值多少钱

特色策略：
- 关联推荐：买了手机，推荐手机壳/充电器
- 复购提醒：日用品快用完时提醒
- 价格敏感：降价商品优先推荐

追问：
- 用户只看不买？则降低 CVR 权重，提高 CTR 权重
- 推荐结果太贵？则加入价格带过滤

技术方案：
1. 多模态特征：
   - 图片：CNN 提取酒店视觉特征
   - 评价：NLP 情感分析（好评率、关键词提取）
   - 位置：到景点/地铁的距离
   - 设施：WiFi、早餐、停车场
2. 用户建模：
   - 旅行类型：商务/度假/亲子（影响偏好）
   - 价格敏感度：历史订单均价
3. 排序策略：
   score = 匹配度 × 0.3 + 评分 × 0.3 + 价格适配 × 0.2 + 新鲜度 × 0.2

追问：
- 旺季房源紧张？则预订热度作为动态权重
- 差评酒店？则差评关键词识别，降权/过滤

技术方案：
1. 图建模：
   - 节点：建筑物/路口
   - 边：路径（权重 = 距离 + 时间 + 坡度）
   - 特殊边：电梯、天桥、地下通道
2. 路径规划：
   - A* 算法（启发式搜索）
   - 多目标：最短路径 / 最省力 / 室内优先
3. 意图理解：
   - 自然语言，转结构化查询（起点/终点/偏好）
   - LLM 解析："从图书馆南门出来，往东走最近的教学楼"

多模态输入：
- 语音："我现在的位置去食堂"
- 图片：拍照当前建筑，视觉定位，找起点
- 文字："三教在哪？我从宿舍过去"

追问：
- 施工封路？则动态更新图权重
- 室内导航？则 WiFi/蓝牙信标定位 + 室内地图

核心架构：
1. 意图识别层：
   - 分类模型：退款/查账/投诉/咨询/其他
   - 置信度：低于阈值，转人工
2. 知识检索层（RAG）：
   - 知识库：FAQ + 政策文档 + 工单历史
   - 检索：BM25 + 向量混合
   - 生成：基于检索结果生成回答
3. 拒识机制：
   - 不在知识范围内，回复"我目前无法回答这个问题"
   - 敏感问题（法律/金融），转人工
   - 情绪识别：用户愤怒，优先转人工
4. 人工接管：
   - HITL：高风险操作（退款、改密码）必须人工确认
   - 无缝切换：Agent 对话历史完整传递给人工

评估指标：
- 自助解决率（目标 大于 70%）
- 转人工率
- 用户满意度
- 平均处理时长

追问：
- 知识库更新滞后？则工单反馈闭环，自动发现知识缺口
- 多轮对话？则对话状态管理（Dialog State Tracking）

技术方案：
1. 知识处理：
   - 文档切分：按语义边界（段落/章节），非固定长度
   - 向量化：embedding 模型 + 元数据（来源/时间/权限）
   - 索引：混合检索（BM25 + 向量 + 元数据过滤）
2. 检索增强：
   - 多路召回：关键词 + 语义 + 热门文档
   - CrossEncoder 重排序：精确相关性打分
   - 多跳推理：如果单文档不够，自动扩展检索
3. 回答生成：
   - 基于检索结果生成，附带引用链接
   - 置信度评估：检索结果质量低，表示不确定
   - 引用溯源：每个答案标注来源文档和段落
4. 权限控制：
   - 检索时过滤无权限文档
   - 不同角色看到不同答案

追问：
- 文档过时？则时间衰减 + 版本管理
- 冲突信息？则来源权重 + 最新优先

技术方案：
1. 上下文构建：
   - 当前文件：光标前后 N 行
   - 导入依赖：import 的模块/类
   - 项目结构：相关文件（同模块的其他文件）
   - AST 信息：当前在函数体内 / 类定义内 / 循环内
2. 模型推理：
   - 流式生成：首 token 延迟 小于 300ms
   - 多候选：生成 3-5 个补全建议
   - 置信度过滤：低于阈值不展示
3. 优化策略：
   - 缓存：相同上下文缓存补全结果
   - 渐进式：短补全（一行内）vs 长补全（完整函数）
   - 语法约束：只生成合法语法（AST 验证）
4. 评估：
   - 采纳率：补全被接受的百分比
   - 延迟：P50 / P99 首 token 时间

追问：
- 大文件上下文太长？则选择性上下文（只取相关片段）
- 多语言支持？则统一模型 + 语言特定后处理

约束类型：
- 硬约束（必须满足）：
  - 老师不能同时上两门课
  - 教室不能同时上两门课
  - 教室容量 大于等于 学生人数
  - 课程时间段内教室可用
- 软约束（尽量满足）：
  - 老师偏好时间段
  - 同一门课间隔均匀
  - 学生课表不冲突

技术方案：
1. 约束建模：
   - CSP 形式化：变量（课程-时间-教室）、域、约束
   - SAT Solver / OR-Tools 求解
2. 贪心 + 回溯：
   - 先排约束最多的课（实验室课、大班课）
   - 冲突时回溯重排
3. 冲突消解：
   - 学生选课冲突检测，调整课程时间
   - 优先级：必修课 大于 选修课 大于 公选课
4. 实时调整：
   - 老师请假，自动找替代时间/老师
   - 教室维修，重新分配

追问：
- 求解时间太长？则启发式 + 局部搜索（禁忌搜索、模拟退火）
- 学生投诉课表冲突？则自动检测 + 调整建议

技术方案：
1. 路径规划：
   - TSP 变种：骑手取多个订单送到多个地点
   - VRP（车辆路径问题）：带时间窗口的 VRP
   - 实时路况：地图 API + 历史数据预估时间
2. 动态调度：
   - 新订单到达，实时匹配最近空闲骑手
   - 骑手状态：空闲/取餐中/配送中
   - 超时预警：预计超时，重新分配
3. 优化目标：
   - 最小化总配送时间
   - 最小化超时率
   - 骑手负载均衡
4. 批量合并：
   - 同一商家多个订单，同一骑手取
   - 同一方向多个配送，顺路合并

追问：
- 骑手迟到/失联？则超时自动重分配 + 备用骑手
- 恶劣天气？则扩大预估时间 + 动态加价

约束：
- 飞机：维护周期、机型匹配航线
- 机组：飞行时长限制（法规）、休息时间
- 机场：起降时段（Slot）、地面保障

技术方案：
1. 分解问题：
   - 飞机排班：分配飞机到航线
   - 机组排班：分配机组到航班
   - 分别求解，再协调
2. 优化算法：
   - 列生成（Column Generation）
   - 整数规划（IP）
   - 启发式初始解 + 局部优化
3. 异常处理：
   - 天气延误，全局重排
   - 飞机故障，替换 + 连锁调整

追问：
- 连锁延误？则缓冲时间设计 + 优先级策略
- 国际航班机组？则签证/资质约束建模

约束：
- 硬约束：
  - 演讲者不能同时出现在两个会场
  - 会场容量 大于等于 预计参会人数
  - 时间段可用（布展/撤展时间）
- 软约束：
  - 相关主题相邻
  - 热门话题大会议室
  - 午餐前后轻松话题

技术方案：
1. 主题聚类：相关演讲分到同一 Track
2. 演讲者冲突检测：一人多演讲，必须错开
3. 会场分配：按预估人数排序，大需求优先
4. 时间优化：热门话题黄金时段

追问：
- 临时换演讲者？则自动检测新冲突 + 调整建议
- 爆满？则实时人流监控 + 直播分流

架构设计（多模式叠加）：
1. Router（分类路由）：
   用户输入，分类器，专业 Agent
   - 技术问题，技术 Agent
   - 账单问题，账单 Agent
   - 退款请求，退款 Agent（+ HITL）
   - 投诉，投诉 Agent（+ HITL）
2. ReAct（技术 Agent 内部）：
   查询工单，查询用户信息，查询产品知识，综合回答
3. HITL（高风险场景）：
   退款金额 大于 500，人工审核
   法律相关，必须人工

工具设计：
- search_knowledge(query)：知识库搜索
- get_user_info(user_id)：用户信息
- get_order_status(order_id)：订单状态
- create_ticket(content, priority)：创建工单

状态管理：
- 对话历史（工作记忆）
- 用户画像（长期记忆）
- 工单状态（持久化）

追问：
- Router 分类错误？则再分类机制 + 置信度路由
- Agent 跑偏？则最大步数限制 + 人工干预

Plan-and-Execute 架构：

1. Planner（计划制定）：
   输入："日本 7 天"
   计划：
   - Day 1-2: 东京（浅草寺、涩谷、秋叶原）
   - Day 3-4: 京都（清水寺、岚山、伏见稻荷）
   - Day 5: 大阪（道顿堀、环球影城）
   - Day 6-7: 奈良 + 返程

2. Executor（逐步执行）：
   - 每个景点：调用 API 获取开放时间、门票价格、交通方式
   - 酒店：根据预算和位置推荐
   - 交通：计算景点间交通时间和费用

3. Synthesizer（汇总）：
   - 整合为完整的行程单
   - 包含时间线、预算、交通、注意事项

工具：
- search_attractions(city, interests)：景点列表
- get_hotel(city, budget, dates)：酒店推荐
- calc_transport(from, to)：交通方案
- get_weather(city, dates)：天气预报
- calc_budget(hotel, transport, food)：预算估算

追问：
- 用户临时改主意？则局部重新规划，保留未改动部分
- 景点临时关闭？则动态替换推荐

架构：CodeAgent 模式

1. 数据理解：
   - 读取 CSV schema（列名、类型、缺失值）
   - 生成数据摘要（行数、列数、统计量）
2. 分析执行（代码生成 + 沙箱）：
   - 生成 pandas 代码
   - 沙箱执行（限制网络/文件系统访问）
   - 捕获执行结果和错误
3. 可视化：
   - 根据数据类型自动选择图表
   - 数值分布，直方图
   - 时间序列，折线图
   - 相关性，热力图
4. 报告生成：
   - 用 LLM 基于分析结果生成文字报告
   - 嵌入图表

安全考量：
- 沙箱隔离（Docker / RestrictedPython）
- 超时限制
- 内存限制
- 禁止系统调用

追问：
- 代码执行失败？则错误反馈，Agent 自动修正
- 大数据集？则采样分析 + 分块处理

架构（AutoGen 风格）：

Agent 1（正方）：
- 系统提示："你是正方，支持 XXX。请用事实和逻辑论证。"
- 目标：提出有力论点，反驳对方观点

Agent 2（反方）：
- 系统提示："你是反方，反对 XXX。请用事实和逻辑论证。"
- 目标：提出有力论点，反驳对方观点

Moderator（裁判）：
- 系统提示："你是辩论裁判，评估双方论点质量。"
- 职责：判断论点是否有事实支撑、逻辑是否严密

对话循环：
1. 正方发言，2. 反方反驳，3. 正方回应，...
4. 每 3 轮后 Moderator 评估，5. 10 轮后结束

终止条件：
- 最大轮次（10 轮）
- Moderator 判定一方明显胜出
- 一方主动认输

评估：
- 论点质量：事实支撑度、逻辑严密性
- 反驳质量：是否有效回应对方论点
- 最终判决：Moderator 给出评判

追问：
- 陷入循环重复？则检测重复论点，要求新论点
- 一方过于强势？则 Moderator 平衡发言机会

1. 明确约束条件（硬约束 vs 软约束）
2. 基础方案（SQL/规则引擎）
3. 性能优化（缓存/预计算/索引）
4. 冲突检测与消解
5. 扩展方案（分片/分布式）

1. 召回层（多路召回，每路保证一定覆盖）
2. 排序层（特征工程 + 模型选择）
3. 重排层（多样性/去重/业务规则）
4. 冷启动策略
5. 评估与反馈闭环

1. 意图理解（分类/NER/槽位填充）
2. 检索策略（关键词/向量/混合）
3. 结果验证（置信度/引用溯源）
4. 拒识机制（不在范围内怎么办）
5. 人工接管（HITL）

1. 约束建模（硬约束 vs 软约束）
2. 求解算法（精确求解 vs 启发式）
3. 实时调整（动态调度）
4. 异常处理（超时/失败/冲突）
5. 评估指标（满意度/效率/公平性）

1. 模式选择（ReAct / Router / Plan-and-Execute / HITL）
2. 工具设计（命名/Schema/错误处理）
3. 状态管理（工作记忆/长期记忆/持久化）
4. 安全控制（最大步数/沙箱/人工介入）
5. 可观测性（Trace/日志/评估）