commute

---
name: commute
description: >-
license: MIT
---

# 通勤方案 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`