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）