shaozhengmao/where-to-eat

聚餐地点和餐厅推荐技能

帮助多人聚餐找到时间最优的中间地点和最佳餐厅。

快速开始

工作流程概览（改进版）

用户提供出发地列表和聚餐时间
           ↓
地理编码 → 获取精确坐标
           ↓
询问用户：是否知道最优地铁路线？（主动利用用户知识）
           ↓
计算地理中心点（重心）
           ↓
计算多种出行方式时间（驾车/地铁/公交）
  - 区分：纯运行时间 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限制等实际因素。通过主动利用用户知识和数据验证，提供更准确、更实用的推荐方案。 🎉