travel-planner

name travel-planner description 生成详细的多日旅行计划，输出为精美的中文 HTML 页面。涵盖天气预报、每日行程（景点+交通）、 餐饮推荐（含人均价格）、酒店住宿对比、详细预算。通过多源网络搜索（含小红书真实用户反馈） 采集信息。支持目的地未知时的推荐与对比决策。 适用于个人自由行、家庭出游（含婴幼儿/老人）、多人旅行等场景。 当用户提到以下内容时使用此 skill：旅行计划、旅游攻略、出行规划、行程安排、去哪里玩、 假期安排、旅行推荐、目的地推荐、holiday plan、travel itinerary、trip planning， 即使用户没有说"旅行计划"但描述了目的地+时间+想玩的意图，也应触发。 即使用户只说了时间和人员但不确定去哪里，也应触发（进入目的地推荐流程）。 Travel Planner 生成结构化、可操作的旅行计划。输出为中文 HTML 页面，信息全部来自实时网络搜索+社区验证。 工具可用性说明 本 skill 涉及的外部数据工具均为 CLI 命令 ，需通过 Bash 工具调用，而非 MCP 工具或 Skill： 工具 类型 调用方式 用途 flyai npm CLI Bash: flyai search-flight ... 机票、酒店、景点门票实时数据（飞猪） mcporter npm CLI Bash: mcporter call xiaohongshu.search_feeds ... 小红书笔记搜索与详情 mcp__grok-search__web_search MCP 工具 直接调用 通用网络搜索（降级方案） Agent 委派规则 ：当使用 Agent 工具并行搜索时，subagent prompt 中 必须明确指示 通过 Bash 调用 flyai 和 mcporter CLI，而非仅依赖 mcp__grok-search__web_search 。示例 prompt 片段： Use Bash to run these CLI commands for real-time data: - flyai search-flight --origin "成都" --destination "昆明" --dep-date 2026-04-02 - flyai search-hotels --dest-name "弥勒" --check-in-date 2026-04-03 --check-out-date 2026-04-05 - mcporter call xiaohongshu.search_feeds keyword="弥勒 带娃 亲子游" Fall back to mcp__grok-search__web_search only when CLI tools fail or return no results. 第一步：收集旅行要素 在开始研究之前，先确认以下信息（已知的跳过，缺失的向用户询问）： 要素 说明 必需 出发地 从哪里出发（决定交通方案和可达性筛选） 是 出行日期 具体日期或月份 是 天数 行程总天数 是 人员构成 谁去、有无老人小孩（含年龄） 是 目的地 城市/地区， 可以为空 （进入推荐流程） 否 预算范围 总预算或每日预算 否 偏好 饮食禁忌、兴趣方向、小众/热门、体力水平 否 第二步：目的地推荐（如目的地未知） 当用户不确定去哪里时， 先做目的地筛选，再做行程规划 。 关键依赖 ：目的地推荐分为多个阶段，Phase A 的结果是后续阶段的输入， 严禁跳过 ： Phase A （可并行）：候选发现 + 季节检查 + 人群适配 → 输出候选短名单 Phase B （依赖 Phase A）：仅对短名单中的候选地搜索交通 → 输出可行性排名 Phase B2 （依赖 Phase A，与 Phase B 可并行）：获取候选地出行日期的天气预报 → 降雨天数统计 Phase C （依赖 Phase B + B2）：综合对比（含天气） → 呈现给用户决策 Phase A：候选目的地发现与初筛 Phase A 内部的三个子步骤可通过 Agent 按区域并行 执行（如同时搜索"广西候选"和"云南候选"），每个 Agent 负责一个区域的完整初筛（发现 + 季节 + 人群适配）。 A1. 候选目的地发现 当用户给出的是 区域范围 （如"广西"、"云南"、"东南亚"）而非具体城市时， 必须先通过搜索获取候选目的地列表 ，严禁仅凭一般知识预设。 搜索策略 （每个区域 Agent 内部执行以下搜索）： FlyAI 极速搜索 — 从真实旅行产品反推目的地 ： flyai fliggy-fast-search --query "[区域] [天数]天 自由行" flyai fliggy-fast-search --query "[区域] [月份] [特殊人群]游 攻略" flyai fliggy-fast-search --query "[出发地]出发 [区域] [天数]日游" 返回的产品列表天然反映了哪些目的地有成熟旅游基础设施和可预订产品。从产品标题中提取目的地城市/地区。 小红书获取真实用户验证的目的地 （优先 mcporter）： mcporter call xiaohongshu.search_feeds keyword= "[区域] [月份] 旅游 推荐" mcporter call xiaohongshu.search_feeds keyword= "[出发地]出发 [区域] [特殊人群]游" 如 mcporter/MCP 不可用，降级用 mcp__grok-search__web_search 搜索 site:xiaohongshu.com [区域] [月份] 旅游 推荐 。 mcp__grok-search__web_search 获取攻略型推荐 ： 搜索示例： - "[区域] [月份] 旅游推荐 目的地 [年份]" - "[区域] [特殊人群] 旅游 去哪里好" - "[出发地]出发 [区域] [天数]天 推荐" A2. 季节性陷阱检查（与 A1 同一 Agent 内执行） 每个候选目的地必须检查： 核心吸引物在出行时段是否处于最佳状态 。 常见陷阱： 瀑布/水景 → 检查是否枯水期（如德天瀑布4月枯水，7-11月最佳） 花海/红叶 → 检查花期/叶期是否匹配 海滩 → 检查是否台风季/禁渔期 雪景/滑雪 → 检查是否已化雪 A3. 特殊人群适配评估（与 A1 同一 Agent 内执行） 如有婴幼儿（0-3岁），必须评估： 推车友好度 ：景区路面是否平整可推车，是否有台阶/石板路/湿滑路段 母婴设施 ：当地超市是否有奶粉/尿不湿，酒店是否提供婴儿床 医疗距离 ：距最近有儿科的医院多远 安全风险 ：是否有深水区/陡崖/湿滑台阶等 节奏适配 ：是否适合慢节奏、是否有午休条件 如有老人，额外评估：海拔高反风险、无障碍设施、医疗可及性。 Phase A 输出 ：每个区域 Agent 返回候选城市/地区列表（通常 3-5 个），附带季节评估和人群适配结论。汇总后形成 候选短名单 （跨区域去重，淘汰季节陷阱严重的）。 Phase B：交通可行性筛选（依赖 Phase A 结果） 仅对 Phase A 输出的候选短名单搜索交通 ，不预设目的地。 交通耗时决定目的地是否可行。从出发地到候选目的地的单程时间直接决定有效游玩天数。 判断标准： 单程 ≤ 4h → 理想，不浪费游玩时间 单程 4-6h → 可接受，需占用半天 单程 6-8h → 勉强，带婴幼儿/老人需谨慎 单程 > 8h → 除非行程 ≥ 7天，否则不推荐 搜索方法：查12306高铁时刻、航班直飞情况、自驾距离。 用 Agent 并行搜索 短名单中多个候选地的交通。 Phase B2：出行日期天气预报（依赖 Phase A 结果，与 Phase B 可并行） 当出行日期在15天预报范围内时，必须在 Phase C 对比决策之前获取所有候选目的地的逐日天气预报。 降雨情况直接影响户外游玩体验，尤其对带婴幼儿/老人的行程影响极大，是目的地选择的关键决策因素。 触发条件 ：出发日期距今 ≤ 15天 → 强制执行；> 15天 → 跳过，在第三步再查。 执行方法 ：对 Phase A 短名单中的所有候选目的地， 并行搜索 各地出行日期段的天气预报。 数据源优先级： 中国天气网 (weather.com.cn) 15天预报 — mcp__grok-search__web_search 搜索 [目的地] 15天天气预报 site:weather.com.cn 和风天气 (qweather.com) — 搜索获取页面URL后 mcp__grok-search__web_fetch 抓取 AccuWeather — 英文备选 必须提取的信息 （出行日期内每日）： 天气状况（晴/多云/阴/雨） 最高/最低气温 是否有降雨 输出格式 ：各候选目的地的逐日天气对比表 + 降雨天数统计。 淘汰规则 ： 出行日期内 ≥ 50% 天数降雨 → 标记为"天气风险高"，在 Phase C 中降权 带婴幼儿/老人时，连续降雨 ≥ 3天 → 建议优先排除 Phase C：多目的地对比决策 将候选目的地按以下维度做横向对比表格呈现给用户： 维度 权重 交通可达性 最高 出行日期天气（降雨） 最高 特殊人群适配 高 季节时令匹配 高 小众/人流量 中 景点丰富度 中 费用水平 低 天气对比必须包含 ：各目的地出行日期内的降雨天数、逐日天气摘要、气温范围。如 Phase B2 已获取预报数据，直接引用；否则标注"超出预报范围，仅参考气候均值"。 给出明确的排名和推荐理由，让用户做最终决策。 第三步：多维信息采集 目的地确定后进入深度采集。使用 Agent 并行搜索 提高效率。 维度 1：精确天气预报（前置，影响穿衣和行程安排） 如 Phase B2 已获取天气预报，直接复用数据，补充穿衣建议即可，无需重复搜索。 若 Phase B2 未执行（目的地已确定或出行日期当时超出15天范围），则必须从权威天气数据源获取逐日预报，不能仅靠搜索引擎的笼统描述。 数据源优先级： 中国天气网 (weather.com.cn) 15天预报 — 通过 mcp__grok-search__web_search 搜索 [目的地] 15天天气预报 site:weather.com.cn 和风天气 (qweather.com) 30天预报 — 搜索获取页面URL后 mcp__grok-search__web_fetch 抓取 wttr.in API — 直接 curl "https://wttr.in/[城市]?format=j1" 获取3天JSON预报（适合近期出行） AccuWeather — 英文备选 必须输出的天气信息（逐日）： 日期、天气状况（晴/多云/阴/雨） 最高/最低气温 降水概率或是否下雨 穿衣建议 维度 2：交通方案 + 衔接验证（关键！） 搜索大交通方案后， 必须验证关键衔接点的可行性 。 机票搜索优先使用 FlyAI （飞猪实时数据，含价格+航班号+可预订链接）： flyai search-flight --origin "[出发地]" --destination "[目的地]" --dep-date YYYY-MM-DD --sort-type 3 # 往返加 --back-date，直飞加 --journey-type 1，限价加 --max-price FlyAI 返回的 adultPrice 、航班号、时刻为实时数据，可直接用于行程编排和预算。 高铁/市内交通仍用 mcp__grok-search__web_search ： 搜索示例： - "[出发地]到[目的地] 高铁 时刻表 [年份]" - "[目的地] 市内交通 地铁/公交/打车/包车" 衔接验证清单 （涉及转机/转高铁的行程必做）： 对每个"A交通→B交通"的转换节点，必须搜索并确认： A的到达时间 和 B的末班时间 — 确保来得及 A→B的转场方式和耗时 — 如"机场→火车站"需确认距离、打车/地铁/大巴耗时 缓冲时间是否充足 — 飞机落地后取行李+转场，至少预留1.5小时缓冲 衔接验证搜索示例： - "[机场]到[火车站] 怎么去 多久 打车 地铁" - "[火车站]到[目的地] 末班车 最晚几点" - "[机场] 空港快线 [火车站] 时刻表 末班" 如果衔接不可行（如末班车赶不上），必须调整方案： 方案A：改更早的航班 方案B：到达城市住一晚，次日再转 方案C：机场直接包车/租车到目的地（跳过火车） 在行程中明确标注衔接风险 ，如"末班高铁约21:00，建议选17:00前落地的航班"。 维度 3：景点与活动（含门票价格） 景点门票优先使用 FlyAI （含门票价格、收费状态、可预订链接）： flyai search-poi --city-name "[目的地]" --category "历史古迹" # 可选：--keyword "景点名"、--poi-level 5（5A景区） FlyAI 返回 ticketInfo.price 和 freePoiStatus （免费/收费），可直接用于预算。 攻略和小众推荐仍用 mcp__grok-search__web_search 补充 ： 搜索示例： - "[目的地] 必去景点 推荐 攻略 [年份]" - "[目的地] 亲子/家庭 玩法 推荐"（如有老人小孩） - "[目的地] 小众景点 本地人推荐" 维度 4：美食与餐饮 搜索示例： - "[目的地] 必吃美食 餐厅推荐 人均" - "[目的地] 当地人推荐 小吃 美食攻略" 维度 5：住宿方案 优先使用 FlyAI 搜索酒店 （飞猪实时数据，支持指定入住日期获取报价）： flyai search-hotels --dest-name "[目的地]" --check-in-date YYYY-MM-DD --check-out-date YYYY-MM-DD # 可选：--poi-name "景点名"（按周边筛选）、--hotel-stars "4,5"、--max-price 800、--sort price_asc FlyAI 返回 price （指定日期报价）、 score 、 review 、 detailUrl （预订链接），数据质量显著优于 mcp__grok-search__web_search。 小红书住客真实体验 （优先 mcporter）： mcporter call xiaohongshu.search_feeds keyword= "[目的地] 亲子酒店 带娃" filters.sort_by= "最多收藏" 如 mcporter 不可用，降级用 mcp__grok-search__web_search 搜索 site:xiaohongshu.com [目的地] 亲子酒店 。 预算中住宿价格处理 ：FlyAI 传入具体日期获取的报价可标注为"实查"；未传日期或 mcp__grok-search__web_search 获取的标注为"参考价"。 维度 6：小红书/社区真实反馈（关键增量信息） 小红书上的真实用户帖子能提供搜索引擎找不到的细节（如推车是否真的好推、具体哪家店踩雷）。 通过 mcporter 调用小红书 MCP （已配置，端口 18060）： 搜索帖子 — 获取高赞笔记列表： mcporter call xiaohongshu.search_feeds keyword= "[目的地] 亲子游 带娃" filters.sort_by= "最多收藏" filters.note_type= "图文" filters.publish_time= "半年内" 获取详情 — 从搜索结果中取 点赞/收藏最高 的 2-3 篇，用返回的 id 和 xsecToken 抓取全文： mcporter call xiaohongshu.get_feed_detail feed_id= "笔记ID" xsec_token= "token值" 提取关键信息 ：真实行程、避雷指南、酒店餐厅推荐、带娃tips 如 mcporter/MCP 不可用，降级用 mcp__grok-search__web_search 搜索 site:xiaohongshu.com [目的地] 亲子 作为替代。 第四步：行程编排 路线串联原则 地理聚类 ：相近景点同一天，减少无效通勤 节奏交替 ：暴走日后安排休闲日 就近用餐 ：餐厅选在当日景点附近 弹性时间 ：每天留 1-2 小时缓冲 到达日轻松 ：第一天只安排入住和周边，不赶景点 特殊人群适配 婴幼儿（0-3岁）： 每日最多 2 个景点，上午1个+下午1个 保留午睡时间（13:00-15:00 段不安排活动或安排车程） 标注每个景点是否需要推车/背带 餐厅选有儿童座椅或空间宽敞的 老人： 每日步行量 < 1.5万步 避免海拔 > 3000m 的景点（除非提前适应） 安排午休时间 每日行程结构 上午（9:00-12:00）：主要景点 + 交通方式 午餐（12:00-13:30）：推荐餐厅 + 特色菜 + 人均 下午（14:00-17:30）：次要景点或休闲活动（婴幼儿场景可安排午睡+轻活动） 晚餐（18:00-19:30）：推荐餐厅 晚上（19:30+）：夜间活动（夜市/散步/温泉/休息） 第五步：预算编制（含可靠度标注） 价格数据的精确程度取决于数据来源。 每项费用必须标注可靠度等级 ： 可靠度分级 等级 含义 标注方式 示例 实查 从权威平台（12306/官网）或 FlyAI（飞猪实时数据）获取的具体价格 无标注 高铁票¥34、FlyAI机票¥400 参考 来自搜索结果但非实时报价（起步价/区间/往年价） 价格后加"~" 酒店~¥750/晚 估算 无直接数据源，基于同类经验推断 价格后加"≈" 市内打车≈¥500 预算表结构 分类 细项 注意 交通 大交通 + 市内 婴儿机票(2岁以下约成人10%)、婴儿高铁免票 住宿 房价 × 间数 × 晚数 4+大人通常需2间房， 标注为参考价 餐饮 人均 × 人数 × 餐数 婴幼儿不单独计餐费 门票 各景点门票 1.2m以下/6岁以下通常免票 其他 保险、伴手礼、杂项 动态价格声明 在预算区域底部和 tips 中必须包含以下提醒： 机票和酒店为动态定价，以上为参考估算。出行前请在携程/12306确认实际价格并预订。 机票价格处理 优先通过 FlyAI search-flight 获取实时报价 ，返回的 adultPrice 为飞猪当前售价，可标注为"实查"。 如 FlyAI 不可用或未返回结果，则搜索 [出发地]到[目的地] 机票 [月份] 价格 获取大致区间，标注为"参考价"。 在 tips 中建议用户出行前在飞猪/携程确认最终价格并预订。 最终给出： 预估总费用 和 人均费用 ，并注明"含参考价成分，实际以预订为准"。 第六步：生成 HTML 每次旅行计划应生成 独特的视觉外观 ，而非千篇一律的固定模板。不同目的地、天气、季节、节日应有不同的色调、风格和氛围。 生成方法（两步） Step 1：准备 tripData JSON 将所有行程数据组装为 tripData JSON 对象（结构见下方），额外添加 "generationDate": "YYYY-MM-DD" 字段。用 Write 工具写入目标文件夹（如 [目的地]-[出发年月]/tripData.json ）。 Step 2：调用 ui-ux-pro-max 生成定制 HTML（首选） 根据目的地特征确定设计方向，然后调用 ui-ux-pro-max skill 生成单文件 HTML 页面。 关键原则：动态 UI ≠ 换皮。 不同目的地的页面必须在 布局结构 上有明显差异，而非仅更换配色/字体。以下是差异化维度： 维度 要求变化 示例 页面布局 必须不同 Bento Grid / 杂志分栏 / 横向滚动 / 卡片瀑布流 行程展示 必须不同 纵向时间轴 / 横向日卡选择器 / 手风琴折叠 / 卡片轮播 预算展示 必须不同 甜甜圈图+图例 / 堆叠条形图+表格 / 环形进度条 酒店展示 建议不同 横向滚动 / 网格 / 左图右文交替 色调/字体 必须不同 根据目的地自然特征选配色和字体风格 装饰元素 建议不同 目的地特色图形 motif（如铁轨虚线、海浪、山水轮廓） 设计方向提示词模板 （根据实际目的地调整）：