Itinerary

可选信息（没有就给两档方案）：

• 人数、是否带娃/老人、预算区间、每日最早/最晚可活动时间、必去点/禁忌（比如不吃辣/不爬山/不走太多路）。

产出结构（Markdown 固定版式）

按下面结构输出，保证“能直接照着走”，并且方便用户二次改：

1. # 行程总览：城市链路 + 节奏（轻松/均衡/特种兵）
2. ## 核心假设（请你确认/改）：3~8 条（把不确定项摊开）
3. ## 每日时间表（可导入日历）：用表格输出（建议时间块，不是外部事实）
4. ## 交通与衔接：跨城段落逐条写；涉及时刻/价格/规则时必须带来源与当地时间
5. ## 预算粗算：按“交通/门票/市内交通/餐饮”粗颗粒拆分；不硬编住宿价格
6. ## Plan B（备选）：下雨/晚点/没票/体力不支的替代安排
7. ## 来源：把用到的外部链接集中列出（带来源当地时间/“来源未标注”）

时间表颗粒度（为了日历）

• 默认给出可导入日历的时间块：例如 09:30–11:30、14:00–17:00。
• 若用户未给“每天最早/最晚”，先用温和默认（例如 09:30 出门、21:30 收工），并放进“核心假设”里等确认。
• 对“必须准点”的事件（航班/高铁/会议/预约）优先固定时间；对游玩部分用建议时间块。

“轻松版 / 特种兵版”双方案

用户没指定时，默认同时给两档：

• 轻松版：留足机动 + 少换乘 + 少跨区 + 每天 1~2 个重点
• 特种兵版：更多点位 + 更紧凑的交通衔接（但要标注风险点）

住宿边界（按你的约定）

• 本 skill 不做酒店筛选/比价/选房型（避免把“住宿选择”塞进这个 skill 里导致变大）。
• 如果用户明确要“选酒店/挑区域/比价”，建议：先问清预算与偏好，再单独走住宿相关流程/skill（如已有），或在不编造的前提下给“选址思路 + 需要你确认的条件”。

查证来源（国内常用，按需加载）

需要可靠来源时再去看：references/sources_cn.md

通勤/多点串联（按需激活）

• 当用户需要“酒店/景点/会场/车站之间怎么走”、或需要把多点安排得更顺（A→B→C），可以按需激活 commute skill。
• itinerary 负责“排骨架与时间块”，commute 负责“把某一段路线做成可查证、可执行的通勤方案（含来源+查询时间）”。

写入日历（必须“明确确认”后才能做）

• 默认只给计划，不直接写入日历。
• 当用户给出明确确认（例如“就按这个来，帮我写进日历”“确认创建日程/提醒”）后，才可以创建/更新日历事件。
• 如果用户表达模糊（例如“差不多”“看着办”），要再问一句确认：
  “我可以把这些安排写进你的日历并设置提醒吗？你回复‘确认’我就执行。”

写入时的体验规范：

• 每天建议拆成 2~4 个时间块事件（别把一天塞成一个超长事件，也别碎成十几个）。
• 标题清晰：城市｜事项（可选：轻松版/特种兵版）；描述里写集合点/注意事项/来源链接（如有）。
• 事件时间使用行程当地时间；如涉及跨时区，要在描述里标注时区信息。