multi-concert-trip-planner

SKILL.md

---
name: multi-concert-trip-planner
description: 支持同时输入多个艺人名称，自动查找各自的演唱会/巡演信息，智能识别时间和地点相近的演出组合，规划一次出行看多场演出的最优方案，并搜索对应的往返机票和演出场馆附近酒店。适用于想在一次旅途中连看多位艺人演出的用户。
---

# Multi-Concert Trip Planner

支持多个艺人名称输入，自动在全球巡演信息中发现时间与地点相近的演出组合，帮助用户一次出行看多场演出，并搜索对应的往返机票和场馆附近酒店，输出完整的追星出行方案。

## 核心能力

- 同时接收多个艺人名称，并行搜索各自的巡演信息
- 三层信息采集：WebSearch 摘要 → WebFetch 可靠站点 → agent-browser 浏览器渲染（处理 JS 动态页面）
- 自动发现"时间窗口"内同城市或相邻城市的演出组合
- 按组合的紧凑程度和总花费排序推荐
- 为每个推荐组合搜索往返机票，输出一站式出行方案
- 为每个推荐组合搜索演出场馆附近酒店（飞猪实时报价），自动匹配入住/退房日期
- 场次变更追踪：自动与上次搜索结果做 diff，总结新增/取消/变更的场次

## 文件结构

| 文件 | 内容 |
|------|------|
| `SKILL.md`（本文件） | 工作流程总览、参数收集、综合推荐逻辑、注意事项 |
| `concert-search.md` | 第二步：演唱会搜索策略、WebFetch 规则、提取字段 |
| `combination-matching.md` | 第三步：组合匹配算法、评分权重、都市圈参考表 |
| `flight-search.md` | 第四步：flyai 机票搜索命令、返回数据解析 |
| `hotel-search.md` | 第四步-B：flyai 酒店搜索命令、返回数据解析、筛选策略 |
| `output-template.md` | 第六步：完整输出格式模板 + 特殊场景处理 + 场次变更总结 |
| `examples.md` | 7 个交互示例（多艺人+机票+酒店、单艺人、跨城、星级预算、仅酒店、agent-browser、变更追踪） |
| `BLOCKED_SITES.md` | WebFetch 失败站点记录（持续更新） |
| `diff-tracking.md` | 场次变更追踪：快照存储格式、diff 算法、变更分类规则 |

## 工作流程

### 第一步：收集用户需求

从用户请求中提取以下参数：

- **艺人/乐队名称列表**（必填，至少 1 个）— 如用户只给了 1 个艺人，正常执行搜索（退化为单艺人模式，跳过第三步的组合匹配）；如给了多个艺人，则进入多艺人组合匹配流程
- **出发城市**（仅开启机票搜索时必填 — 如用户未提供且需要搜索机票，必须主动询问）
- **时间窗口偏好**（可选，默认"未来 6 个月"）— 如"今年夏天"、"下半年"、"8-10 月"
- **组合容忍天数**（可选，默认 7 天）— 两场演出之间最多间隔多少天仍视为"可组合"，用户可以说"最好 1 天内"或"一周内都行"。询问时提供的选项应包含 1 天（仅限连续两天）、3 天内、7 天内、14 天内等梯度
- **是否搜索机票**（可选，默认关闭）— 机票价格来自搜索引擎摘要，仅供粗略参考，准确性有限。询问时默认关闭，用户明确要求时才开启
- **是否搜索酒店**（可选，默认关闭）— 使用飞猪搜索演出场馆附近酒店，返回实时价格和预订链接。询问时默认关闭，用户明确要求时才开启
- **酒店偏好**（可选，仅开启酒店搜索时有效）— 包括：
  - 星级偏好：如"四星以上"、"经济型就好"
  - 每晚预算上限：如"每晚不超过 800"
  - 床型偏好：如"大床房"、"双床房"
  - 酒店类型：hotel（酒店）、homestay（民宿）、inn（客栈），默认 hotel
- **预算范围**（可选，仅开启机票或酒店搜索时有效）— 如"总花费 1 万以内"、"越便宜越好"
- **地区偏好**（可选）— 如"只看亚洲"、"优先日本和韩国"、"不限地区"

若用户只提供了艺人列表，至少追问出发城市。

### 第一步-B：加载上次搜索快照

→ 详见 `diff-tracking.md`

在开始搜索前，根据本次艺人列表在 `snapshots/` 目录中查找最近一次匹配的快照。如找到，加载为 `previousSnapshot` 用于搜索完成后的 diff 对比。首次搜索该艺人组合时跳过此步。

### 第二步：并行查找各艺人演唱会信息

→ 详见 `concert-search.md`

对每个艺人使用 WebSearch 搜索巡演信息（日/英/中三语查询），通过 Task 工具并行执行。采用三层降级策略：优先从搜索摘要提取信息，对可靠站点使用 WebFetch 补充，对 JS 渲染站点使用 agent-browser 浏览器抓取。结果去重、按日期排序，过滤 14 天内场次。

### 第三步：智能组合匹配（核心逻辑）

→ 详见 `combination-matching.md`

单艺人模式跳过本步骤。多艺人模式下，用滑动窗口在时间线上扫描，按城市/都市圈分组，生成候选组合并按四维评分（艺人覆盖 40%、时间紧凑 25%、地理集中 20%、售票可行 15%）排序，取前 10 个组合。

### 第四步：搜索往返机票（可选，默认跳过）

→ 详见 `flight-search.md`

仅在用户明确要求时执行。使用 `flyai search-flight` 搜索往返机票，返回实时价格和飞猪购票链接。多组合并行搜索，每组合取最便宜的 3 个选项。

### 第四步-B：搜索演出场馆附近酒店（可选，默认跳过）

→ 详见 `hotel-search.md`

仅在用户明确要求时执行。使用 `flyai search-hotel` 以场馆名称为关键词搜索附近酒店，返回实时价格和飞猪预订链接。多城市并行搜索，每城市取前 5 家，按档次分层推荐。

### 第五步：综合整理与推荐

**如果开启了机票和/或酒店搜索：** 将组合信息、机票信息、酒店信息和城际交通（如有）合并，计算每个方案的总花费估算（总花费 = 各场门票之和 + 往返机票 + 住宿费用 + 城际交通）。

**如果未开启机票和酒店搜索（默认）：** 仅基于演出信息整理推荐，不涉及机票、酒店和总花费。

**推荐逻辑：**

- 首要指标：能覆盖的艺人数量（越多越好）
- 次要指标：时间紧凑度（间隔天数越少越好）
- 参考指标：地理集中度、售票可行性
- 如有机票数据，额外参考总花费
- 标注"最佳覆盖"（看到最多艺人）和"最紧凑"（间隔最短）方案

### 第六步：呈现总结

→ 详见 `output-template.md`

按标准模板输出方案（演出安排表 + 购票链接 + 机票信息 + 酒店推荐 + 总花费估算），并处理特殊场景（艺人无演出、无可组合方案、音乐节等）。

### 第七步：保存快照 + 场次变更总结

→ 详见 `diff-tracking.md`

将本次搜索结果保存为 JSON 快照文件。如存在上次快照（第一步-B 加载），自动执行 diff 对比，在输出末尾生成「场次变更总结」，包含新增/取消/场馆变更/售票状态变更/票价变更 5 类变化。首次搜索时仅保存快照并提示用户。

## 注意事项

- 出发城市仅在用户开启机票搜索时需要，不要在未开启时追问。
- 为提升效率，多个艺人的搜索必须使用 Task 工具并行执行，而非逐一串行搜索。
- agent-browser 是最重量级的信息采集手段，仅在 WebSearch 摘要和 WebFetch 都无法获取关键信息时使用。每次使用后及时 `agent-browser close` 释放资源。详见 `concert-search.md` 第三层策略和 `BLOCKED_SITES.md` 中标记为 🟢 的站点。
- 机票价格波动较大，提醒用户价格仅供参考，建议尽早预订。
- 酒店价格同样会波动（尤其是演唱会期间热门城市），提醒用户看到合适的酒店尽早预订。
- 搜索酒店时优先使用场馆名称作为 `--key-words`，确保推荐的酒店距离场馆较近，方便观演。
- 如果场馆关键词搜索结果较少，退而使用城市核心区域（如"新宿"、"涩谷"、"梅田"）作为关键词补充搜索。
- 转售平台（StubHub 等）的门票价格可能高于原价，需标注说明。
- 搜索机票时考虑演出城市对应的主要机场（如东京对应 NRT/HND，伦敦对应 LHR/LGW/STN）。
- 默认展示最多 5 个组合方案 + 未能组合的场次，除非用户要求更多。
- 尊重各网站的请求限制，合理控制搜索频率。
- 如果用户指定了预算，优先过滤掉超出预算的方案。
- 组合评分算法中的权重为默认值，如用户明确偏好（如"我更在乎省钱"），应动态调整权重。
- 每次搜索结束后必须保存快照到 `snapshots/` 目录。如存在上次快照，必须在输出末尾附上场次变更总结。详见 `diff-tracking.md`。

## 交互示例

→ 详见 `examples.md`（含 7 个完整场景：多艺人+机票+酒店、单艺人+机票、多艺人跨城、带星级预算的酒店搜索、仅搜酒店不搜机票、agent-browser 处理 JS 渲染官网、场次变更追踪 diff）