local-itinerary-planner

name	local-itinerary-planner
description	基于真实高德 POI 与天气的多日/半日动线；须覆盖餐饮与娱乐/文化；输出「理想回答」级长文与表格。

出行动线规划（真实 POI + Mock 偏好）

何时使用

• 大阶段一：槽位已齐（或已由 travel-intake / 用户「全部默认」）后，用户需要 首版 完整路线安排。
• 大阶段二 · 模式②：用户改槽位（午饭、室内、人数、景点类型等，未整趟换纲）→ 复述变更后 再调工具（get_weather + search_places 至少对变更 POI；动线变则 plan_route），输出 新一版 完整方案（结构要求同下），不 再走 intake 问卷。
• 模式② 禁止：不调工具、只改店名/地址文字；改版方案中 POI 无 amap.com/place/ 链接。
• 大阶段二 · 模式①：用户只问行程细节 → 不用 本 skill 重出全文；短答即可。
• 大阶段二 · 模式③ / 整趟换纲：回到 intake + 本 skill 产出新方案。

工具顺序（仅本 skill 出首版/改版完整方案时）：get_weather → search_places（可多轮关键词）→ plan_route（相邻锚点成对）。intake 选择题阶段 不要 调搜点/算路；纯天气/闲聊 不要 进入本 skill。

禁止（仅 planning 阶段）：

• 未在本轮 search_places 结果中出现过的 POI，不得写进方案当「已检索确认」。
• 天气工具失败或日期错位时，不得写「实时气温 xx℃」。

交付与硬约束

• 品类：至少包含 餐饮 与 娱乐或文化 两大类 POI（高德 type/关键词侧尽量对齐）。
• 规模（与「只给两个点」划清界限）
  • 半天（约 4–6h）：至少 3 个可玩/可逛锚点 + 1 餐（或 2 锚点 + 2 餐），并写清时段；禁止只输出 2 个店名结束。
  • 全天：至少 4～6 个时段块（含午/晚餐之一或二 + 多个玩乐/文化）。
  • 多日：按天重复「速览表 + 分时段」，参照团队 理想回答.md 的信息密度（分区说明、每日主题、餐饮展开、预算表、Tips）。
• 首 Token <10s（仅在 已进入本 skill 后）：先短句「正在并行查天气 / 搜点…」再调工具；不要在槽位未齐时进入本 skill。
• 主数据链路：lifecare__lifecare_get_weather；lifecare__lifecare_search_places（可分页 page，与实现一致）；lifecare__lifecare_plan_route。不依赖沙盒 catalog 作为前置条件。

输出结构（必须逐项出现）

1. 标题与总览句。
2. 出行日天气：单独一节，数值来自本轮 get_weather；日期不一致须说明。
3. 行程速览：Markdown 表格（天数/时段 | 安排 | 交通）；交通列优先 打车约 X km / Y 分钟。
4. 分块详述：每段含 停留时长估算、选点理由、排队/预约/口味 提示。
5. 动线可视化：至少一种 — Mermaid（flowchart / timeline）或「点 A → 点 B」+ lifecare__lifecare_plan_route 的 分钟/公里。
6. 预算表：分项 + 总计区间（标注估算）。
7. Tips：预约、天气穿搭、闭馆、带娃等。
8. 图与链接：每个写入方案的 POI，若工具 JSON 里有 amap_place_url，必须在正文用 Markdown 链出 至少 1 条可点击地址；模式② 改版时新推荐的每个 POI 亦同（无 link = 未合规检索）。若有 photo_urls 则在 该 POI 所在时段段落中间 插 1～2 张 ![](url)（禁止全部配图堆在文末）。都无则 Mermaid/表格即可。

步骤

1. 读取结构化槽位（含 场景：A|B）。
   • 场景 A（城市出行）：天气查目的地城市；搜点围绕目的地；表格「交通」写 到达站/驾车/停车；自驾段用 plan_route 并提停车场。
   • 场景 B（周边游玩）：天气查出发地所在城市；搜点围绕区/地标；最后一程回 return_to（默认定位出发区）。表格「交通」与用户选的 地铁/公交/步行/自驾 一致——选地铁则写 线路+站名+步行，禁止全文只写自驾。
   • 场景 B 读摘要：place_type、depart_window、play_duration、T_now（仅 now）、return_to。按 SOUL.md「场景 B · 周边时段」分支排表（now+距23:00<2h → 30 分钟打车圈；≥23:00 → 夜间 POI）。
   • place_type 搜词（宜短，拼区名；count=0 换词）：natural→森林公园/湿地公园；cultural→古镇/博物馆；urban_leisure→步行街/城市公园；theme→游乐园/水上乐园；rural_outdoor→露营地/农家乐/采摘园；any→至少 3 轮跨类（如博物馆+城市公园+本帮菜）。禁止只搜「附近景点」。
   • hub 同日往返（场景 A，到达站 + 返程发车）：先按 SOUL.md「往返/赶车场景」算 户外可玩起止 与半径，再搜点排表；顺序为 时间轴 → 分批 search_places → plan_route，禁止先搜「车站附近」再用「站内休息数小时」填空白。可玩 >6h 时至少 3 轮 不同关键词搜点；最后一程回站 route ≤60 分钟（超时预警）；站内等候 ≤20 分钟（用户反对空等 ≤10 分钟）。
2. 并行：lifecare__lifecare_get_weather；多轮 lifecare__lifecare_search_places（玩乐/文化 + 餐饮）。
   • 关键词宜短、单一意图；勿把「景点+餐饮+热门」拼成一句。若 count=0 换词再搜。
3. 结合 mock-user-prefs-reviews 做筛选说明。
4. 打分与 Top-K + 估停留；禁止把 review_count_proxy 说成真实点评条数。
5. 访问顺序：成对 lifecare__lifecare_plan_route（场景 B 且用户选地铁时，驾车 route 仅作可选对比或停车场段，正文以公共交通叙述为主）。
6. 输出按 输出结构 排版；语言可长，以可执行为准。

边界

• 沙盒（排队、Mock 下单）：可选，仅演示异常时再用；主链路不强制。
• 大交通（高铁票等）只做约束，不伪造订票结果。