Back to Details

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)

缺信息时优先问这几个（每个一句）：
  1. 起点与终点（或多点串联的点位清单）：最好给“名称 + 城市/区域”，有地址更好
  2. 出发/到达时间窗口：例如“明天 8:30 前到”“今晚 19:00 出发”（决定是否早高峰/夜间）
  3. 偏好优先级（选 1）：省时间 / 省钱 / 少走路更轻松
可选（不强制）：是否带娃/老人、是否大件行李、能否接受换乘、是否怕堵车/怕走夜路。
When information is missing, prioritize asking these (one per question):
  1. Starting Point and Destination (or list of points for multi-stop routing): Preferably provide "Name + City/Area", address is better
  2. Departure/Arrival Time Window: For example, "Arrive before 8:30 tomorrow" "Depart at 19:00 tonight" (determines peak hours/nighttime)
  3. 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 → …)

目标是“少折返、少跨区、可执行”，而不是数学最优。
工作法：
  1. 先问/推断每个点的“时间约束”（必须几点到/游玩时长/是否需要预约）
  2. 先做一个“区域聚类”：把相近区域放同一天或同一时段
  3. 输出两档：
    • 轻松版：少换乘、留缓冲、每段尽量简单
    • 特种兵版：更紧凑、更快，但把风险点写清楚
The goal is "Less backtracking, less cross-region travel, executable", not mathematically optimal.
Workflow:
  1. First ask/infer the "time constraints" for each point (must arrive by a certain time/duration of visit/whether reservation is required)
  2. First do a "regional clustering": Group nearby areas into the same day or same time period
  3. 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)

  1. 一段结论：推荐你选哪个（基于用户偏好与时间约束）
  2. ## 方案对比
    ：用表格（方式｜预计耗时｜预计费用｜适合谁｜风险点｜来源）
  3. ## 我会怎么选（给你理由）
    ：2~4 句
  4. ## 出门时间建议
    ：给“出发时间+缓冲”
  5. ## 来源
    ：集中列链接 + 当地时间/查询时间
  1. A concluding paragraph: Recommend which one to choose (based on user preferences and time constraints)
  2. ## Plan Comparison
    : Use a table (Mode | Estimated Time | Estimated Cost | Suitable For | Risk Points | Source)
  3. ## My Recommendation (With Reasons)
    : 2~4 sentences
  4. ## Departure Time Suggestion
    : Provide "Departure time + buffer"
  5. ## 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