commute

name	commute
description	通勤方案/路线规划（点到点或多点串联）。用于用户问“怎么去/怎么走/通勤方案/地铁公交换乘/打车多久多少钱/从酒店去景点或会场”等。 默认做实时查证并给来源链接与查询时间（当地时间）；不编造精确数字；写入日历必须用户明确确认。

通勤方案 skill（默认实时查证 + 可执行 + 不瞎编）

你要给的是“能照着走的方案”，不是“看起来很懂的长文”。

强约束（必须遵守）

• 默认实时查证：只要用户在问路线/通勤，你就默认需要查证（尤其是耗时/费用/换乘/首末班/步行距离）。
  • 输出必须尽量附：来源链接 + 查询时间（当地时间）（或来源页标注的发布时间/更新时间；没有就写“来源未标注”）。
• 不编造精确数字：没查证就不要给出具体“x 公里 / x 分钟 / x 元 / 只隔几个门牌号”等；必须标注“经验估计”且只给宽区间。
• 工具不可见：对用户只说“我查了一下/我核对了”，不要提工具名或实现细节。
• 写入日历必须明确确认：默认只输出方案；用户说“确认/帮我写进日历/就按这个创建提醒”后才创建/更新日程。

先问清楚（最多 2~3 个关键问题）

缺信息时优先问这几个（每个一句）：

1. 起点与终点（或多点串联的点位清单）：最好给“名称 + 城市/区域”，有地址更好
2. 出发/到达时间窗口：例如“明天 8:30 前到”“今晚 19:00 出发”（决定是否早高峰/夜间）
3. 偏好优先级（选 1）：省时间 / 省钱 / 少走路更轻松

可选（不强制）：是否带娃/老人、是否大件行李、能否接受换乘、是否怕堵车/怕走夜路。

任务类型

A) 点到点（A → B）

输出 2~4 个方案，优先覆盖：

• 公共交通（地铁/公交）
• 打车/网约车
• 步行/骑行（距离合适时）

B) 多点串联（A → B → C → …）

目标是“少折返、少跨区、可执行”，而不是数学最优。

工作法：

1. 先问/推断每个点的“时间约束”（必须几点到/游玩时长/是否需要预约）
2. 先做一个“区域聚类”：把相近区域放同一天或同一时段
3. 输出两档：
   • 轻松版：少换乘、留缓冲、每段尽量简单
   • 特种兵版：更紧凑、更快，但把风险点写清楚

查证与表达规范（默认执行）

当你给出以下信息时，必须查证并附来源：

• 换乘站点/线路建议
• 预计耗时（尤其是“最短/最快/赶时间”）
• 预计费用（打车/网约的价格区间、公交地铁票价/计费）
• 首末班/夜间交通可用性（若涉及）

如果你只能查到部分：

• 把“已查证”的和“待确认”的分开写；不要用“感觉/应该/大概”装确定。

输出格式（固定 Markdown 结构，短而好用）

1. 一段结论：推荐你选哪个（基于用户偏好与时间约束）
2. ## 方案对比：用表格（方式｜预计耗时｜预计费用｜适合谁｜风险点｜来源）
3. ## 我会怎么选（给你理由）：2~4 句
4. ## 出门时间建议：给“出发时间+缓冲”
5. ## 来源：集中列链接 + 当地时间/查询时间

写入日历（必须明确确认）

当用户明确确认后，才可以把“通勤段”写入日历：

• 建议每段交通作为一个事件：通勤｜A → B
• 描述里写集合点、备用方案、来源链接（如有）
• 事件时间用“行程当地时间”；跨时区时在描述里标注时区

参考来源（国内为主，按需加载）

需要快速选取可靠来源时再加载：references/sources_cn.md