where-to-eat

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: 计算出行时间（改进版）

⚠️ 关键改进：必须区分"纯运行时间"和"总出行时间"

🚨 优先级原则（必须遵守）：

1. 优先调用高德地图API获取实时数据（这是默认且必须的方式）
2. 只有在API不可用时才使用估算（Tool not found / API限流 / API错误）
3. 使用估算时必须明确标注"估算"，不得以"精确值"的口吻输出

错误做法示例：

❌ 来广营 → 安贞门：约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返回的时间包含：

• 步行到地铁站的时间
• 地铁/公交运行时间（核心）
• 站内换乘步行时间
• 出站后步行时间

必须解析和区分：

# 从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错误 等，不得继续以“精确值”口吻输出，必须切换到兜底模式：

1. 明确声明：以下时间为估算区间（而非API实时结果）
2. 估算方法：
   • 距离：使用直线距离（Haversine）并乘以道路系数 (1.2~1.4)
   • 打车/驾车：城市道路平均速度 18~28 km/h（视时段），并提示高峰不确定性
   • 自行车：15~18 km/h（普通自行车）
   • 步行：4~5 km/h
3. 输出格式强制：

（兜底估算）来广营 → 北苑：
  距离：约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 推荐策略

不要只推荐一种方案，而是：

1. 展示所有方案的对比
2. 说明各自的优缺点
3. 根据用户偏好推荐（如询问："您更倾向于哪种出行方式？"）
4. 如果用户没有偏好，推荐时间相似度最好的方案

Step 5: 搜索餐厅

在中心地点周围搜索符合美食偏好的餐厅：

使用 mcp_tool_amap-maps_maps_text_search:

keywords: 用户指定的菜系或餐厅名称
city: 城市名
→ 返回: POI列表（名称、地址、坐标、评分等）

Step 6: 提取餐厅详情（API调用控制）

关键限制：为避免API限制，查询详情数量≤25次

策略：

1. 优先从搜索结果中按评分筛选前15-20家餐厅
2. 计算每家餐厅到中心点的直线距离，过滤距离>3km的餐厅
3. 对筛选后的前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家）。

优先级：

1. 完全符合美食偏好的餐厅优先
2. 评分相同时，评论数越多越优先
3. 评分评论相同时，距离越近越优先

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 内容，无需额外脚本。

1. 收集所有数据：

   • 参与者信息（出发地、坐标）
   • 推荐中间地点（名称、坐标）
   • 出行时间数据（各方案的时间、方差、详细路线）
   • 餐厅推荐列表（TOP 5，包含所有详细信息）
   • 出发时间表
   • 聚餐建议

2. 按照格式（10.2节）生成 Markdown 内容：

   • 使用标准 Markdown 语法
   • 表格使用 Markdown 表格格式
   • 标题层级清晰（# ## ###）
   • 使用 emoji 增强可读性（📍 🍽️ 💡）
   • 直接按照 10.2 节的格式模板填充数据

3. 保存文件：

   • 使用 write 工具将生成的 Markdown 内容保存为文件
   • 文件名格式：聚餐推荐_[日期]_[时间].md
   • 例如：聚餐推荐_2026-01-27_14-30.md
   • 保存后告知用户文件路径

4. 输出提示：

   ✅ 推荐方案已生成并保存为 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）

基于实际使用反馈的关键改进：

1. 🚨 API调用优先级原则（新增，关键）：

   • 必须优先调用高德地图API获取实时数据（这是默认且必须的方式）
   • 只有在API不可用时才使用估算（Tool not found / API限流 / API错误）
   • 使用估算时必须明确标注"估算"，不得以"精确值"的口吻输出
   • 错误示例：来广营 → 安贞门：约50分钟（未标注估算）
   • 正确示例：来广营 → 安贞门：53.7分钟（API实时数据） 或 约50分钟（估算，当前无法调用API）

2. API数据解析优化：

   • 区分"纯运行时间"和"总出行时间"
   • 解析API响应，提取各段时间（步行、地铁、换乘）
   • 明确标注时间类型，避免误导

3. 主动利用用户知识：

   • 询问用户是否知道最优路线
   • 验证用户提供的路线信息
   • 用户纠正后及时更新

4. 时间上下文处理：

   • 明确询问聚餐时间
   • 区分"现在出发"和"指定时间到达"
   • 考虑高峰时段影响

5. 多方案对比：

   • 同时计算驾车、地铁、公交方案
   • 说明各自优缺点
   • 让用户选择，不强制推荐单一方案

6. 数据验证机制：

   • 合理性检查（异常时间质疑）
   • 多路线对比，选择最优
   • 异常时主动询问用户

7. 工具不可用兜底（新增）：

   • 遇到工具不可用/限流，必须切换到“估算区间”输出
   • 明确标注不确定性，避免把估算说成精确结果

8. 严格遵守用户交通偏好（新增）：

   • 用户说“不要电单车/只要自行车”，必须彻底排除不符合项

参考：CHANGELOG.md、references/improved_examples.md

---

此技能帮助多人快速找到最优聚餐地点和餐厅，考虑时间均衡、出行方式多元、API限制等实际因素。通过主动利用用户知识和数据验证，提供更准确、更实用的推荐方案。 🎉