| name | where-to-eat |
| description | 多人聚餐地点和餐厅推荐。当用户提出"大家一起吃饭"、"找个中间地点"、"约饭"、"聚餐地点"、"怎么分配地点"、"聚个餐"或讨论"多人聚餐"、"最方便的地点"、"几个人怎么约饭"、"餐厅推荐"时使用此技能。基于参与者所在地点（如地铁站名或小区），自动计算地理中心点，使用高德地图API计算多种出行方式时间（驾车/地铁/公交/骑行，≤3km可考虑骑行），考虑出行时间（高峰期，平峰期），找出花费时间最相似（方差最小）的最优见面点，然后基于美食偏好搜索周边餐厅，按评分倒排推荐TOP 5。⚠️ 为控制API调用限制，餐厅详情查询数量≤25次。 |
| version | 1.1.3 |
聚餐地点和餐厅推荐技能
帮助多人聚餐找到时间最优的中间地点和最佳餐厅。
快速开始
工作流程概览（改进版）
用户提供出发地列表和聚餐时间
↓
地理编码 → 获取精确坐标
↓
询问用户：是否知道最优地铁路线？（主动利用用户知识）
↓
计算地理中心点（重心）
↓
计算多种出行方式时间（驾车/地铁/公交）
- 区分：纯运行时间 vs 总出行时间
- 解析API响应：提取步行、地铁、换乘各段时间
↓
数据验证：时间是否合理？
- 如果异常 → 询问用户确认
- 对比多条路线，选择最优
↓
计算时间相似度（多种方案对比）
↓
推荐多个方案（驾车、地铁、公交）
- 说明优缺点
- 让用户选择
↓
根据聚餐时间计算出发时间
- 考虑高峰时段影响
- 含缓冲时间
↓
基于美食偏好搜索周边餐厅
↓
按评分倒排推荐 TOP 5 餐厅
↓
展示完整推荐方案（明确标注时间类型 + 详细路线）
↓
生成并保存 Markdown 文档（必须执行，见 Step 10）
核心概念
- 地理中心点（重心）: 多个出发地的平均坐标，作为理想的聚餐地点基准
- 时间相似度: 用方差衡量，方差越小说明所有人花费时间越接近
- 最优地点: 兼顾时间相似度、交通便利性、商业设施、知名度
收集参数
必需参数
| 参数 | 说明 | 示例 |
|---|
| 出发地列表 | 参与者所在位置（≥2个） | 来广营、霍营、朱辛庄 |
| 美食偏好 | 菜系或餐厅类型（1-3个） | 烤肉、日料、海底捞 |
可选参数
| 参数 | 说明 | 默认值 | 重要性 |
|---|
| 出行方式 | 驾车/地铁/公交 | 都计算 | ⭐⭐⭐ |
| 预算范围 | 人均消费范围 | 不限 | ⭐⭐ |
| 聚餐时间 | 计划聚餐时间（如"晚上7点"） | 当前时间 | ⭐⭐⭐⭐ 关键 |
| 特殊需求 | 素食/无海鲜等 | 无 | ⭐⭐ |
| 出行偏好 | 环保/成本/便利性 | 无 | ⭐⭐ |
| 交通工具禁忌/偏好 | 例如：只要自行车（非电）、不要电单车、可/不可打车 | 无 | ⭐⭐⭐ |
⚠️ 重要：必须明确询问聚餐时间，区分"现在出发"和"指定时间到达"
⚠️ 重要：如果用户明确“不要某种方式”（例如不要电单车），必须彻底排除，不要在推荐里出现
使用示例:
"我们三个人在来广营、霍营、朱辛庄，想一起吃烤肉，帮我们找聚餐地点和餐厅"
收集参数：
origins: ["来广营地铁站", "霍营地铁站", "朱辛庄地铁站"] // 若无特定地址，视为地铁站
food_preference: ["烤肉"] // 支持1-3个美食选项
transportation: ["驾车", "地铁", "公交"] // 自动计算所有方式
执行步骤
Step 1: 地理编码 - 规范化出发地
使用高德地图 mcp_tool_amap-maps_maps_geo API：
对每个出发地调用地理编码
→ 获取精确坐标（纬度、经度）
→ 验证地址完整性
→ 存储坐标用于后续计算
处理地址规则:
- 如果输入未指定具体小区或位置，默认视为地铁站
- 输入: "来广营" → "来广营地铁站" + 坐标
- 如果输入已指定具体地点（如"滨河花园"），使用该地点
- 如有多个结果，优先选择地铁站或商圈中心
Step 2: 计算地理中心点
使用重心算法：
中心纬度 = (lat1 + lat2 + ... + latn) / n
中心经度 = (lon1 + lon2 + ... + lonn) / n
然后使用高德地图 mcp_tool_amap-maps_maps_regeocode 反向编码：
输入: 中心坐标
→ 输出: 地点名称（如"呼家楼商圈"）
Step 3: 计算出行时间（改进版）
⚠️ 关键改进：必须区分"纯运行时间"和"总出行时间"
🚨 优先级原则（必须遵守）：
- 优先调用高德地图API获取实时数据（这是默认且必须的方式）
- 只有在API不可用时才使用估算（Tool not found / API限流 / API错误）
- 使用估算时必须明确标注"估算"，不得以"精确值"的口吻输出
错误做法示例：
❌ 来广营 → 安贞门：约50分钟（这是估算，但没有标注）
正确做法示例：
✅ 来广营 → 安贞门：53.7分钟（API实时数据）
✅ 或：来广营 → 安贞门：约50分钟（估算，当前无法调用API）
对每个参与者，计算到中心点的多种出行方式时间：
3.1 驾车时间计算
必须优先调用 mcp_tool_amap-maps_maps_direction_driving:
返回: 距离、预计时间、路线建议
时间类型：
- 纯驾车时间：API返回的duration（秒）转换为分钟
- 总时间 = 纯驾车时间 + 停车时间（5分钟缓冲）
3.2 地铁/公交时间计算（关键改进）
必须优先调用 mcp_tool_amap-maps_maps_direction_transit_integrated:
⚠️ API返回的时间包含：
- 步行到地铁站的时间
- 地铁/公交运行时间（核心）
- 站内换乘步行时间
- 出站后步行时间
必须解析和区分：
transit_response = {
"route": {
"transits": [{
"duration": "总时间（秒）",
"walking_distance": "总步行距离",
"segments": [
{
"walking": {"duration": "步行时间"},
"bus/railway": {"duration": "运行时间"}
}
]
}]
}
}
纯地铁运行时间 = sum(segment中railway/bus的duration)
总步行时间 = sum(segment中walking的duration)
换乘时间 = 换乘次数 × 3-5分钟
总出行时间 = 纯运行时间 + 总步行时间 + 换乘时间
输出格式：
地铁出行时间：
纯地铁运行时间：30分钟（站到站）
总出行时间：45分钟（含步行15分钟）
详细路线：
（示例）8号线：朱辛庄站 → 霍营站
（示例）换乘13号线：霍营站 → 北苑站
⚠️ 若用户纠正线路（如“北苑站在13号线”），以用户路线为准并写入详细路线
3.3 数据验证和合理性检查
检查规则：
if 地铁运行时间 > 60分钟 and 直线距离 < 20km:
警告：时间可能不合理
询问用户："您知道从XX到XX更快的路线吗？"
对比多条路线，选择最优
多路线对比：
- 获取API返回的所有路线方案
- 对比选择最优（时间最短、换乘最少）
- 如果用户提供了路线信息，优先验证用户路线
3.4 骑行时间（自行车/步行的规则化处理）
默认建议范围：
- ≤ 3km：优先给出骑行（自行车）方案
- 3-8km：可给出骑行方案（自行车），并提示体力/红绿灯影响
-
8km：除非用户明确要骑车，否则不主动推荐；若用户坚持，给“粗略估算”并标注误差来源
如果骑行路线 API 可用：使用 mcp_tool_amap-maps_maps_bicycling 获取更准确时间
如果骑行路线 API 不可用：必须输出为“估算”，示例：
骑行（自行车）时间（估算）：
距离：约6km（按直线距离×1.2~1.4估算）
速度：15~18km/h（普通自行车）
时间：约20~30分钟（含红绿灯不确定性）
⚠️ 禁止默认推荐电单车：只有用户明确说“电单车/电助力/共享电单车”才可以提及，否则一律按“普通自行车”估算
3.5 工具不可用兜底（必须执行）
当出现 Tool not found / API限流 / API错误 等，不得继续以“精确值”口吻输出，必须切换到兜底模式：
- 明确声明：以下时间为估算区间（而非API实时结果）
- 估算方法：
- 距离：使用直线距离（Haversine）并乘以道路系数 (1.2~1.4)
- 打车/驾车：城市道路平均速度 18~28 km/h（视时段），并提示高峰不确定性
- 自行车：15~18 km/h（普通自行车）
- 步行：4~5 km/h
- 输出格式强制：
（兜底估算）来广营 → 北苑：
距离：约6km（估算）
打车：15~25分钟（估算，受路况影响）
自行车：20~30分钟（估算）
备注：当前无法调用路线API，以上为区间估算
Step 4: 评估时间相似度（多方案对比）
⚠️ 关键改进：同时计算多种出行方式的时间相似度，让用户选择
4.1 计算各方案的时间相似度
对每种出行方式（驾车、地铁、公交）分别计算：
方差 = Σ(ti - t_avg)² / n
评分标准:
✅ 方差 < 50 (最大差 < 10分钟) → 非常理想
✅ 方差 50-100 (最大差 10-15分钟) → 良好
⚠️ 方差 100-200 (最大差 15-25分钟) → 一般
❌ 方差 > 200 (最大差 > 25分钟) → 不理想
4.2 多方案对比表
| 出行方式 | 平均时间 | 方差 | 最大差值 | 优点 | 缺点 |
|---|
| 驾车 | 18.4分钟 | 55.3 | 17.3分钟 | 时间短、灵活 | 需找停车位、成本高 |
| 地铁 | 43分钟 | 15 | 10分钟 | 时间均衡、环保 | 总时间较长 |
| 公交 | 65分钟 | 418 | 50分钟 | 成本低 | 时间差异大 |
4.3 推荐策略
不要只推荐一种方案，而是：
- 展示所有方案的对比
- 说明各自的优缺点
- 根据用户偏好推荐（如询问："您更倾向于哪种出行方式？"）
- 如果用户没有偏好，推荐时间相似度最好的方案
Step 5: 搜索餐厅
在中心地点周围搜索符合美食偏好的餐厅：
使用 mcp_tool_amap-maps_maps_text_search:
keywords: 用户指定的菜系或餐厅名称
city: 城市名
→ 返回: POI列表（名称、地址、坐标、评分等）
Step 6: 提取餐厅详情（API调用控制）
关键限制：为避免API限制，查询详情数量≤25次
策略：
- 优先从搜索结果中按评分筛选前15-20家餐厅
- 计算每家餐厅到中心点的直线距离，过滤距离>3km的餐厅
- 对筛选后的前10-15家餐厅调用
mcp_tool_amap-maps_maps_search_detail
必需信息:
✅ 完整地址
✅ 坐标
✅ 评分和评论数
✅ 营业时间
✅ 人均消费
✅ 电话号码
Step 7: 排序和过滤
过滤条件:
- 距离中心地点 ≤ 3km
- 评分 ≥ 3.5（避免极差的选择）
- 评论数 ≥ 50（确保一定的真实度）
排序公式:
score = (评分×0.7) + (评论数标准化×0.2) + (距离标准化×0.1)
按分数从高到低排序，取TOP 5-10（最多10家）。
优先级：
- 完全符合美食偏好的餐厅优先
- 评分相同时，评论数越多越优先
- 评分评论相同时，距离越近越优先
Step 8: 计算到各餐厅的出行时间
为用户明确显示每人到各推荐餐厅的出行时间：
对每个参与者:
对每个推荐的餐厅:
根据出行方式（驾车/地铁/公交/骑行）计算时间
优先展示最优方式
→ 整理成表格展示
优化策略：
- 对所有餐厅使用同一个参与者作为代表计算时间
- 只展示最快的1-2种出行方式
- 若餐厅≤3km，自动提示可骑行
Step 9: 生成推荐方案（改进版）
⚠️ 关键改进：明确时间上下文，区分"现在出发"和"指定时间到达"
9.1 时间计算逻辑
if 用户提供了聚餐时间（如"晚上7点"）:
出发时间 = 聚餐时间 - 出行时间 - 缓冲时间
说明：为了在19:00到达，需要几点出发
else:
到达时间 = 当前时间 + 出行时间
说明：现在出发，预计几点到达
9.2 考虑高峰时段影响
if 聚餐时间在17:00-19:00（晚高峰）:
地铁时间 = 平峰时间 + 5分钟（拥挤）
驾车时间 = 平峰时间 × 1.25（更堵）
if 聚餐时间在07:00-09:00（早高峰）:
地铁时间 = 平峰时间 + 5分钟（拥挤）
驾车时间 = 平峰时间 × 1.3（更堵）
9.3 完整推荐报告格式
# 聚餐方案推荐
## 📍 推荐中间地点
- 地点名称
- 多方案出行时间对比表
- 驾车方案：时间、方差、优缺点
- 地铁方案：时间、方差、优缺点
- 公交方案：时间、方差、优缺点
## 🍽️ TOP 5 餐厅推荐
（按评分倒排）
对每家餐厅：
- 基本信息（地址、电话、营业时间）
- 评分和评价数
- 人均消费
- 支付方式
- 推荐菜品
- 到此餐厅的出行时间表（明确标注时间类型）
- 纯运行时间：XX分钟
- 总出行时间：XX分钟（含步行XX分钟）
- 详细路线说明
- 用户评价亮点
## 💡 聚餐建议
### 约定聚餐时间：19:00
### 出发时间表（含5分钟缓冲）：
| 出发地 | 出发时间 | 出行方式 | 预计到达时间 | 详细路线 |
|--------|---------|---------|------------|---------|
| 来广营 | 18:05 | 公交+地铁 | 19:00 | [详细路线] |
| 霍营 | 18:10 | 地铁 | 19:00 | [详细路线] |
| 朱辛庄 | 18:10 | 地铁 | 19:00 | [详细路线] |
### 出行建议：
- 推荐出行方式：地铁（时间更均衡）
- 高峰时段提示：晚高峰可能更拥挤，建议提前5分钟出发
- 预订建议：建议提前预订，避免等位
- 停车信息：如选择驾车，需注意停车位
Step 10: 生成 Markdown 文档（新增）
⚠️ 必须执行：在完成推荐方案后，将完整结果保存为 Markdown 文档。
10.1 文档保存位置
默认保存路径：
聚餐推荐_[日期时间].md
例如：聚餐推荐_2026-01-27_14-30.md
保存位置：
- 优先保存在用户当前工作目录
- 如果用户指定了路径，使用用户指定的路径
- 如果无法确定工作目录，保存在临时目录并告知用户
10.2 Markdown 文档格式
文档应包含以下完整内容：
# 聚餐方案推荐
**生成时间**：2026-01-27 14:30
**参与人数**：3人
**聚餐偏好**：日料
---
## 📍 推荐中间地点
**地点名称**：安贞门地铁站附近（朝阳区）
**地理坐标**：116.406424, 39.973240
### 出行时间对比（多方案）
| 出行方式 | 平均时间 | 方差 | 最大差值 | 评级 | 优点 | 缺点 |
|---------|---------|------|---------|------|------|------|
| 地铁 | 71.6分钟 | 182.8 | 32.7分钟 | ⭐⭐⭐ 一般 | 时间均衡、环保 | 总时间较长 |
| 驾车 | 45.2分钟 | 120.5 | 25.3分钟 | ⭐⭐⭐ 一般 | 时间短、灵活 | 需找停车位、成本高 |
**推荐方案**：地铁（时间更均衡，环保）
### 详细出行时间表
#### 地铁方案
| 出发地 | 纯地铁运行时间 | 总出行时间（含步行） | 换乘次数 | 详细路线 |
|--------|---------------|-------------------|---------|---------|
| 来广营地铁站 | 30.5分钟 | 53.7分钟 | 4次 | 14号线→望京→15号线→望京西→13号线→芍药居→10号线→安贞门 |
| 朱辛庄 | 40.5分钟 | 74.6分钟 | 2次 | 步行→生命科学园→昌平线→西土城→10号线→安贞门 |
| 旧宫 | 52.5分钟 | 86.4分钟 | 2次 | 步行→旧宫地铁站→亦庄线→宋家庄→10号线→安贞门 |
---
## 🍽️ TOP 5 餐厅推荐
### 1. 伊豆野菜村(中海环宇荟店) ⭐⭐⭐⭐⭐
**基本信息**：
- **地址**：安定路6号(安贞门地铁站B东北口步行50米)
- **评分**：4.6/5.0
- **人均消费**：¥166/人
- **营业时间**：周一至周日 11:00-14:00, 17:00-21:30
- **距离地铁站**：约50米（步行1分钟）
**推荐理由**：距离地铁站最近，评分高，日式火锅自助
**出行时间**（从推荐中间地点）：
- 步行：1分钟
---
### 2. 牛角烧肉专门店(安贞环宇会店) ⭐⭐⭐⭐⭐
**基本信息**：
- **地址**：中海环宇荟购物中心L5层L504单元商铺
- **评分**：4.6/5.0
- **人均消费**：¥183/人
- **营业时间**：周一至周日 11:00-21:00
- **距离地铁站**：约100米（步行2分钟）
**推荐理由**：评分高，日式烧肉专门店，品牌连锁
**出行时间**（从推荐中间地点）：
- 步行：2分钟
---
（继续列出其他3家餐厅...）
---
## 💡 聚餐建议
### 约定聚餐时间：现在出发
### 出发时间表（含5分钟缓冲）
| 出发地 | 出发时间 | 出行方式 | 预计到达时间 | 详细路线 |
|--------|---------|---------|------------|---------|
| 来广营地铁站 | 现在 | 地铁 | 约54分钟后 | 14号线→望京→15号线→望京西→13号线→芍药居→10号线→安贞门 |
| 朱辛庄 | 现在 | 地铁 | 约75分钟后 | 步行→生命科学园→昌平线→西土城→10号线→安贞门 |
| 旧宫 | 现在 | 地铁 | 约86分钟后 | 步行→旧宫地铁站→亦庄线→宋家庄→10号线→安贞门 |
### 出行建议
- **推荐出行方式**：地铁（时间更均衡，环保）
- **高峰时段提示**：当前为平峰时段，出行时间相对稳定
- **预订建议**：建议提前预订，避免等位
- **会合建议**：来广营的朋友最早到达（约54分钟），可以先去餐厅点菜或在地铁站附近等待
### 注意事项
- 所有时间均为API实时数据（非估算）
- 出行时间包含步行、换乘等全部时间
- 建议提前5-10分钟出发，预留缓冲时间
- 如遇高峰时段，实际时间可能增加5-10分钟
---
**文档生成工具**：where-to-eat skill v1.1.3
**数据来源**：高德地图API
10.3 生成文档的步骤
⚠️ 重要：按照上述格式（10.2节）直接生成 Markdown 内容，无需额外脚本。
-
收集所有数据：
- 参与者信息（出发地、坐标）
- 推荐中间地点（名称、坐标）
- 出行时间数据（各方案的时间、方差、详细路线）
- 餐厅推荐列表（TOP 5，包含所有详细信息）
- 出发时间表
- 聚餐建议
-
按照格式（10.2节）生成 Markdown 内容：
- 使用标准 Markdown 语法
- 表格使用 Markdown 表格格式
- 标题层级清晰（# ## ###）
- 使用 emoji 增强可读性（📍 🍽️ 💡）
- 直接按照 10.2 节的格式模板填充数据
-
保存文件：
- 使用
write 工具将生成的 Markdown 内容保存为文件
- 文件名格式：
聚餐推荐_[日期]_[时间].md
- 例如：
聚餐推荐_2026-01-27_14-30.md
- 保存后告知用户文件路径
-
输出提示：
✅ 推荐方案已生成并保存为 Markdown 文档
📄 文件路径：聚餐推荐_2026-01-27_14-30.md
💡 您可以将此文档分享给其他参与者
执行方式：按照 10.2 节的格式模板，将收集到的数据填充到模板中，生成完整的 Markdown 字符串，然后使用 write 工具保存即可。无需编写额外的脚本文件。
10.4 文档质量要求
- ✅ 包含所有关键信息（地点、时间、餐厅、路线）
- ✅ 格式清晰，易于阅读
- ✅ 表格对齐正确
- ✅ 时间数据明确标注（API实时数据 vs 估算）
- ✅ 包含生成时间和数据来源说明
- ✅ 文件保存成功，路径明确
数据处理和质量标准（改进版）
处理特殊情况
某个人出发地特别远:
- 生成多个方案，明确显示时间差异
- 提示用户是否有其他选择
- 询问用户："XX出发地较远，是否考虑其他地点？"
没有找到合适餐厅:
- 扩大搜索范围（3km → 5km）
- 放宽美食偏好（如"烤肉" → "烤"）
- 降低评分要求（≥4.0 → ≥3.5）
多个餐厅方案相似:
API返回时间异常:
- 如果地铁运行时间 > 60分钟且距离 < 20km，质疑合理性
- 询问用户："您知道从XX到XX更快的路线吗？"
- 对比多条路线，选择最优
- 如果用户提供了路线信息，优先验证用户路线
路线工具不可用 / 查不到时间:
- 进入“工具不可用兜底”模式（见 Step 3.5）
- 所有时间必须用区间，并明确标注“估算”
- 优先让方案可执行：例如改用“打车/自行车（普通）”与其他人地铁会合
用户纠正路线:
- 接受用户纠正，更新计算
- 记录用户提供的正确路线，用于后续参考
- 感谢用户纠正，说明这是改进skill的重要反馈
质量保证清单（改进版）
- ✅ 每个出发地都成功地理编码
- ✅ 中心点计算正确
- ✅ 明确询问聚餐时间（区分"现在出发"和"指定时间到达"）
- ✅ 主动询问用户是否知道最优路线（利用用户本地知识）
- ✅ 区分纯运行时间和总出行时间（明确标注）
- ✅ 解析API响应，提取各段时间（步行、地铁、换乘）
- ✅ 数据验证：时间是否合理？（异常时询问用户）
- ✅ 多方案对比（驾车、地铁、公交，说明优缺点）
- ✅ 每个参与者的出行时间都计算了
- ✅ 生成并保存 Markdown 文档（包含完整推荐方案）
- ✅ 出行时间方差评分正确（多种方案）
- ✅ 餐厅搜索结果充足（≥5家）
- ✅ 每个餐厅都有完整的高德地图数据
- ✅ 餐厅按评分倒排
- ✅ 计算到各餐厅的出行时间（明确标注时间类型）
- ✅ 详细路线说明（包含换乘站、换乘方式）
- ✅ 推荐方案清晰、实用
关键优化点（改进版）
1. 出行方式智能选择（多方案对比）
不要只推荐一种方式，而是同时计算和对比：
| 距离范围 | 驾车 | 地铁 | 公交 | 推荐策略 |
|---|
| ≤3km | 10-15分 | 10-20分 | 15-25分 | 同时推荐，说明优缺点 |
| 3-10km | 20-40分 | 20-45分 | 30-60分 | 对比时间相似度，让用户选择 |
| >10km | 30+分 | 30-60分 | 45+分 | 优先推荐时间相似度最好的 |
2. API限制处理
- 地理编码、搜索：无特殊限制
- 路线规划：对3个人×多个地点，最多9-15次调用
- 餐厅详情查询：≤25次（重点控制）
3. 用户知识利用（新增）
主动询问：
- "您知道从XX到XX的最优地铁路线吗？"
- "您平时是怎么去的？"
- "您更倾向于哪种出行方式？"
验证用户输入：
- 如果用户提供了路线，优先验证用户路线
- 对比用户路线和API路线，选择最优
4. 数据验证机制（新增）
合理性检查：
if 地铁运行时间 > 60分钟 and 直线距离 < 20km:
警告：时间可能不合理
询问用户确认
对比多条路线
多路线对比：
- 获取API返回的所有路线方案
- 选择最优（时间最短、换乘最少）
- 如果用户提供了路线，优先验证
5. 时间上下文处理（新增）
明确时间概念：
- 询问聚餐时间（如"晚上7点"）
- 区分"现在出发"和"指定时间到达"
- 考虑高峰时段影响（早高峰、晚高峰）
时间计算逻辑：
if 聚餐时间:
出发时间 = 聚餐时间 - 出行时间 - 缓冲时间
说明：为了在19:00到达，需要几点出发
else:
到达时间 = 当前时间 + 出行时间
说明：现在出发，预计几点到达
参考资源
详细的实现指导请参考：
references/api-guide.md - 高德地图API详细使用说明references/algorithm.md - 地理计算和优化算法详解references/examples.md - 完整的使用示例和案例
工具依赖
-
✅ 高德地图 MCP 工具集（必需）
mcp_tool_amap-maps_maps_geo - 地理编码mcp_tool_amap-maps_maps_regeocode - 反向编码mcp_tool_amap-maps_maps_direction_driving - 驾车路线mcp_tool_amap-maps_maps_direction_transit_integrated - 公交/地铁路线mcp_tool_amap-maps_maps_text_search - 关键词搜索mcp_tool_amap-maps_maps_search_detail - 详情查询
-
🔄 备选方案
- Google Maps MCP（如高德地图不可用）
重要改进说明（v1.1.3）
新增功能
Markdown 文档输出（新增）
- 新增：Step 10 - 生成并保存 Markdown 文档
- 功能：将完整推荐方案保存为格式化的 Markdown 文档
- 用途：方便分享给其他参与者，便于查看和保存
- 格式：包含所有关键信息（地点、时间、餐厅、路线、建议）
- 文件命名：
聚餐推荐_[日期]_[时间].md
重要改进说明（v1.1.2）
基于实际使用反馈的关键改进：
-
🚨 API调用优先级原则（新增，关键）：
- 必须优先调用高德地图API获取实时数据（这是默认且必须的方式）
- 只有在API不可用时才使用估算（Tool not found / API限流 / API错误）
- 使用估算时必须明确标注"估算"，不得以"精确值"的口吻输出
- 错误示例：
来广营 → 安贞门：约50分钟（未标注估算）
- 正确示例：
来广营 → 安贞门：53.7分钟（API实时数据） 或 约50分钟（估算，当前无法调用API）
-
API数据解析优化：
- 区分"纯运行时间"和"总出行时间"
- 解析API响应，提取各段时间（步行、地铁、换乘）
- 明确标注时间类型，避免误导
-
主动利用用户知识：
- 询问用户是否知道最优路线
- 验证用户提供的路线信息
- 用户纠正后及时更新
-
时间上下文处理：
- 明确询问聚餐时间
- 区分"现在出发"和"指定时间到达"
- 考虑高峰时段影响
-
多方案对比：
- 同时计算驾车、地铁、公交方案
- 说明各自优缺点
- 让用户选择，不强制推荐单一方案
-
数据验证机制：
- 合理性检查（异常时间质疑）
- 多路线对比，选择最优
- 异常时主动询问用户
-
工具不可用兜底（新增）：
- 遇到工具不可用/限流，必须切换到“估算区间”输出
- 明确标注不确定性，避免把估算说成精确结果
-
严格遵守用户交通偏好（新增）：
- 用户说“不要电单车/只要自行车”，必须彻底排除不符合项
参考：CHANGELOG.md、references/improved_examples.md
此技能帮助多人快速找到最优聚餐地点和餐厅，考虑时间均衡、出行方式多元、API限制等实际因素。通过主动利用用户知识和数据验证，提供更准确、更实用的推荐方案。 🎉
