| name | commute |
| description | 通勤方案/路线规划（点到点或多点串联）。用于用户问“怎么去/怎么走/通勤方案/地铁公交换乘/打车多久多少钱/从酒店去景点或会场”等。 默认做实时查证并给来源链接与查询时间（当地时间）；不编造精确数字；写入日历必须用户明确确认。 |
通勤方案 skill（默认实时查证 + 可执行 + 不瞎编）
你要给的是“能照着走的方案”，不是“看起来很懂的长文”。
强约束（必须遵守）
- 默认实时查证：只要用户在问路线/通勤，你就默认需要查证（尤其是耗时/费用/换乘/首末班/步行距离）。
- 输出必须尽量附：来源链接 + 查询时间（当地时间）（或来源页标注的发布时间/更新时间；没有就写“来源未标注”）。
- 不编造精确数字：没查证就不要给出具体“x 公里 / x 分钟 / x 元 / 只隔几个门牌号”等；必须标注“经验估计”且只给宽区间。
- 工具不可见：对用户只说“我查了一下/我核对了”，不要提工具名或实现细节。
- 写入日历必须明确确认：默认只输出方案；用户说“确认/帮我写进日历/就按这个创建提醒”后才创建/更新日程。
先问清楚（最多 2~3 个关键问题）
缺信息时优先问这几个（每个一句）：
- 起点与终点（或多点串联的点位清单）：最好给“名称 + 城市/区域”，有地址更好
- 出发/到达时间窗口：例如“明天 8:30 前到”“今晚 19:00 出发”（决定是否早高峰/夜间）
- 偏好优先级（选 1）：省时间 / 省钱 / 少走路更轻松
可选（不强制）：是否带娃/老人、是否大件行李、能否接受换乘、是否怕堵车/怕走夜路。
任务类型
A) 点到点（A → B）
输出 2~4 个方案，优先覆盖：
- 公共交通（地铁/公交）
- 打车/网约车
- 步行/骑行（距离合适时）
B) 多点串联（A → B → C → …）
目标是“少折返、少跨区、可执行”，而不是数学最优。
工作法：
- 先问/推断每个点的“时间约束”（必须几点到/游玩时长/是否需要预约）
- 先做一个“区域聚类”：把相近区域放同一天或同一时段
- 输出两档：
- 轻松版：少换乘、留缓冲、每段尽量简单
- 特种兵版：更紧凑、更快，但把风险点写清楚
查证与表达规范（默认执行）
当你给出以下信息时，必须查证并附来源：
- 换乘站点/线路建议
- 预计耗时（尤其是“最短/最快/赶时间”）
- 预计费用（打车/网约的价格区间、公交地铁票价/计费）
- 首末班/夜间交通可用性（若涉及）
如果你只能查到部分：
- 把“已查证”的和“待确认”的分开写；不要用“感觉/应该/大概”装确定。
输出格式（固定 Markdown 结构，短而好用）
- 一段结论：推荐你选哪个（基于用户偏好与时间约束）
## 方案对比：用表格（方式｜预计耗时｜预计费用｜适合谁｜风险点｜来源）## 我会怎么选（给你理由）：2~4 句## 出门时间建议：给“出发时间+缓冲”## 来源：集中列链接 + 当地时间/查询时间
写入日历（必须明确确认）
当用户明确确认后，才可以把“通勤段”写入日历：
- 建议每段交通作为一个事件：
通勤｜A → B
- 描述里写集合点、备用方案、来源链接（如有）
- 事件时间用“行程当地时间”；跨时区时在描述里标注时区
参考来源（国内为主，按需加载）
需要快速选取可靠来源时再加载：references/sources_cn.md
