commute

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

Commuting Plan Skill (Default Real-Time Verification + Executable + No Fabrication)

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

What you provide should be a "followable plan", not a "long essay that sounds knowledgeable".

强约束（必须遵守）

Strong Constraints (Must Comply)

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

Default Real-Time Verification: As long as the user asks about routes/commuting, you must verify by default (especially for travel time/cost/transfers/first/last train times/walking distance).
- The output must include as much as possible: source link + query time (local time) (or the release/update time marked on the source page; write "Source not marked" if unavailable).
No Fabrication of Precise Figures: Do not provide specific figures like "x kilometers / x minutes / x yuan / only a few house numbers apart" without verification; you must mark it as "Experience-based estimate" and only give a wide range.
Tool Invisibility: Only say "I checked/I verified" to users; do not mention tool names or implementation details.
Explicit Confirmation Required for Calendar Entry: Only output the plan by default; create/update the schedule only after the user says "Confirm/Help me add to the calendar/Create a reminder based on this".

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

Clarify First (Maximum 2~3 Key Questions)

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

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

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

When information is missing, prioritize asking these (one per question):

Starting Point and Destination (or list of points for multi-stop routing): Preferably provide "Name + City/Area", address is better
Departure/Arrival Time Window: For example, "Arrive before 8:30 tomorrow" "Depart at 19:00 tonight" (determines peak hours/nighttime)
Preference Priority (Choose 1): Save time / Save money / Less walking for comfort

Optional (Not Mandatory): Whether traveling with kids/elderly, whether with large luggage, whether transfers are acceptable, whether worried about traffic jams/walking at night.

任务类型

Task Types

A) 点到点（A → B）

A) Point-to-Point (A → B)

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

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

Output 2~4 plans, prioritizing coverage of:

Public Transportation (Subway/Bus)
Taxi/Ride-Hailing
Walking/Cycling (When the distance is appropriate)

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

B) Multi-Stop Routing (A → B → C → …)

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

工作法：

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

The goal is "Less backtracking, less cross-region travel, executable", not mathematically optimal.

Workflow:

First ask/infer the "time constraints" for each point (must arrive by a certain time/duration of visit/whether reservation is required)
First do a "regional clustering": Group nearby areas into the same day or same time period
Output two versions:
- Relaxed Version: Fewer transfers, buffer time reserved, each segment as simple as possible
- Speed Version: More compact, faster, but clearly state the risk points

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

Verification and Expression Specifications (Default Execution)

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

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

如果你只能查到部分：

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

When providing the following information, you must verify and attach the source:

Transfer station/route suggestions
Estimated travel time (especially for "shortest/fastest/rush")
Estimated cost (price range for taxi/ride-hailing, bus/subway fares/billing)
Availability of first/last train/night transportation (if involved)

If you can only verify part of the information:

Separate "Verified" and "To be confirmed" content; do not pretend to be certain with words like "I think/should/probably".

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

Output Format (Fixed Markdown Structure, Short and Useful)

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

A concluding paragraph: Recommend which one to choose (based on user preferences and time constraints)
```
## Plan Comparison
```
: Use a table (Mode | Estimated Time | Estimated Cost | Suitable For | Risk Points | Source)
```
## My Recommendation (With Reasons)
```
: 2~4 sentences
```
## Departure Time Suggestion
```
: Provide "Departure time + buffer"
```
## Sources
```
: List links collectively + local time/query time

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

Calendar Entry (Explicit Confirmation Required)

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

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

Only after the user explicitly confirms can you add the "commuting segment" to the calendar:

It is recommended to create each commuting segment as an event:
```
Commute｜A → B
```
Write the meeting point, backup plan, and source link (if available) in the description
Use "local time of the trip" for the event time; mark the time zone in the description when crossing time zones

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

Reference Sources (Mainly Domestic, Load On Demand)

需要快速选取可靠来源时再加载：

references/sources_cn.md

Load only when you need to quickly select reliable sources:

references/sources_cn.md