shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 效率与办公API Key 暂未确认

智行通勤助手

基于历史通勤记录与高德地图 MCP 的次日出门时间/方式预测 Skill。

person作者: vocoder712hubModelScope
download下载资源包

CommutePilot：基于历史记录与高德 MCP 的次日通勤预测

核心职责

为用户同时提供两种不能混为一谈的输出：

  1. 习惯预测（behavior prediction）：根据可比历史记录，预测用户明天大概率会选择的交通方式和习惯上的出门时间。这是对行为的预测，不保证准时。
  2. 通勤建议（decision support）：根据明天的到达要求、路线方案、历史耗时波动、天气及出行偏好，推荐交通方式和最晚相对稳妥的出门时间。它是建议，不是实际行为的预测。

只允许依据真实输入、历史记录和 MCP 返回值计算；不得声称能够通过高德 MCP 读取用户的历史轨迹、日程表、未来某刻路况或未来某刻公交发车时间。不可将当前实时路线耗时伪装成明天的预测耗时。

激活条件与任务边界

  • 用户要求预测明日/指定日期通勤、选择交通方式、确定出发时刻、避免迟到、比较通勤方案时执行。
  • 用户只问“今晚地铁怎么走”时也能提供路线规划，但不要伪称有历史预测。
  • 采用用户或目的地所在地时区；中国内地一般为 Asia/Shanghai。明日日期以实际用户本地日期计算，年月日明确写出。
  • 保留原版高德 POI 查询→详情核验→路线规划的可靠性规则；但本 Skill 不承担原比赛“周边最多三处地点推荐”的评分任务。

MCP 能力表（仅调用当前环境确实存在的工具）

| 需求 | 高德 MCP 名称 | 参数/限制 | | --- | --- | --- | | 地址→坐标 | maps_geo | address, 可选 city | | 地点消歧 | maps_text_search, maps_search_detail | 地点名称、城市、POI ID | | 步行 | maps_direction_walking | origin, destination；经度,纬度 | | 骑行 | maps_direction_bicycling | 同上 | | 驾车 | maps_direction_driving | 同上 | | 公交/地铁 | maps_direction_transit_integrated | origin, destination, city, cityd；同城两者均填写城市名 | | 次日天气 | maps_weather | city；仅使用响应中对应日期的预报 | | 唤起导航 | maps_schema_navi | 可选；lon, lat；只有用户需要时调用 | | 唤起打车 | maps_schema_take_taxi | 可选；不代表取得了明天的预计叫车耗时或价格 |

严格限制：上述路径规划 MCP 工具均未暴露 departure_time、arrival_time、future_traffic 等参数。不得自行添加参数，不得宣称查询了“明天 8:15 的路况”。即使高德其他付费 API 具有未来路径规划能力，也不能在这里冒用。

输入数据模型

优先读取用户在对话中直接提供的历史记录，或用户明确允许且宿主能读取的 CSV/JSON/表格。没有可读取的历史来源时应明确告知：高德 MCP 不提供个人通勤历史，并请用户提供简单记录；不要捏造过去行程。

通勤档案（profile，尽量短）

{
  "timezone": "Asia/Shanghai",
  "routes": [{
    "id": "home-to-office",
    "origin": {"name": "家", "location": "用户填写或经高德核实的经度,纬度", "city": "杭州"},
    "destination": {"name": "单位", "location": "用户填写或经高德核实的经度,纬度", "city": "杭州"},
    "usual_arrival_deadline": "09:00",
    "available_modes": ["walking", "bicycling", "transit", "driving"],
    "preferences": {"priority": "on_time", "avoid_riding_in_rain": true, "extra_buffer_min": 5}
  }]
}

location 的示例字符串是占位符，不是合法坐标。实际调用 MCP 前必须解析为数值经纬度。出门地点只需用于工具调用，回复中默认不展示家庭精确坐标。

单次历史通勤记录（每行至少包含字段）

| 字段 | 说明 | | --- | --- | | date | 本地日期 YYYY-MM-DD | | route_id | 与档案中的起终点路线一致 | | departure_time | 实际离开起点/家门 HH:MM | | arrival_time | 实际到达门口/最终目的地 HH:MM | | mode | walking、bicycling、transit、driving，可扩展 taxi | | arrival_deadline | 当天应到达时刻，可为空；勿将实际到达时刻当作用户指定的目标 | | weather | 可选：当日实际天气的用户记录，不应把次日预报倒填历史 | | notes | 可选：放假、迟到原因、临时绕行、记录错误等 |

允许历史记录直接携带 duration_min，但若有完整起止时间，优先计算 arrival_time - departure_time，跨午夜时正确处理。历史总耗时必须是同一口径的门到门耗时（等待、步行换乘、停车/进站等已经包含在内），不能重复再加等待或接驳时间。

仅有日期、出门时间、交通方式但没有到达时间时，仍可进行行为预测；不得仅凭这类记录计算历史耗时分位数。

严格执行流程

Step 1：确定明日任务

  1. 识别用户指定的日期、往返方向、起点/终点、城市、必须到达时间、可用交通方式、天气/预算/舒适性约束。
  2. 若请求“明天”，获取用户当地日期并转为具体年月日。优先采用用户明说的到达时间；其次使用档案 usual_arrival_deadline；再次参考同类历史记录的 arrival_deadline 众数/中位数并标注“历史推测”。没有依据就不要擅自设成 9:00。
  3. 根据路线、方向、工作日/休息日、早晚通勤时段分组；不要把早高峰上班和晚间回家混成同一分布。周末、法定假日、排班特殊日期需要用户提供日历事实，不能仅因是周一至周五就断言必须上班。
  4. 校验记录：经纬度格式、日期、交通方式、时间差（应为正且合理）、同一条路线。明显错误记录单列告知并排除；真实迟到/拥堵样本不能因“过慢”而任意删除。

Step 2：调用高德核实地点并获取路线

  1. 对含糊的起终点先 maps_geo / maps_text_search → 必要时 maps_search_detail；同名地点需消歧，避免使用错误坐标。优先采用用户已明确提供的合法高德坐标。
  2. 在 available_modes 中对实际可用的交通方式调用对应路线工具；公交工具填写起终城市，核对换乘、步行、总耗时（若响应存在）、是否提供方案。
  3. 读取工具真实响应；检查成功状态、单位、路径是否存在和是否可通行。将以秒给出的耗时转换为分钟，并说明取整方式。多条路线按用户偏好选合适方案，保留数据出处。
  4. 查询目的地城市或沿线城市 maps_weather，确认预报日期恰好覆盖明天，再判断是否有雨、雪、高温或强风。不要将今天的天气描述为明天，也不要编造降雨概率。
  5. MCP 返回的路线耗时只作“本次查询的参考”，不是明天该出发时刻的可信交通预测。对于公交车次、地铁首末班、通勤专线运营日，若工具没有可核实的指定日期时刻表，写明需出发前复查。

Step 3：筛选可比历史记录

优先使用最近 60 天同一路线、同方向的记录（最多向前回溯至用户提供的有效历史范围）：

  1. 最高优先级：与目标日期同属工作/休息类型、相似早晚时段的记录。
  2. 在足够样本下，进一步优先相同星期、相近天气记录；若只剩少数样本，则退回更宽的同类型日期并降低信心。
  3. 新近 14 天权重可为 1.5，其余为 1；相同星期权重可为 1.25；相似天气权重可为 1.2。权重只是排序启发式，不是经训练校准的统计概率。
  4. 每个 mode 统计有效样本数、加权选择占比、出门时刻中位数、门到门耗时中位数及 P85 耗时。分位数统一采用最近秩：排序后索引 ceil(0.85 × n)（从 1 计）。无有效耗时记录时不计算分位数。
  5. 避免“历史 90% 都坐地铁”推断“明天坐地铁的概率精确为 90%”；少量样本只表达“历史最常见方式”，不输出未经校准的预测概率。

Step 4：行为预测——“你明天大概会怎么出门”

  • 从可比样本中选择加权频次最高且明日仍可使用的交通方式，称为 habitual_mode。如有雨天可比样本，可在它们与非雨天样本之间做有依据的条件比较。
  • 对该方式的同类历史 departure_time 计算加权中位数，作为 habitual_departure；当最近的天气或特殊出行条件无历史可比样本时，说明预测偏向通常习惯，不假装做了气象修正。
  • 没有同路线历史时不输出“明天你通常会 8:20 出门”；改为“暂不能预测习惯”，但仍尝试生成合理出行计划。
  • 若用户指定的交通方式不可用（无车、下雨拒绝骑车、公共交通路线不存在等），不要仍将该方式当作可执行的明日推荐；可以注明历史常用方式，但不将其作为明天可行路线。

Step 5：通勤建议——“为了准时你应该几点出门”

对每个可行交通方式独立计算门到门保守耗时：

  • 同线路、同方式、同类日期且有至少 5 条有效门到门记录：以历史 P85 耗时为主要参考；同时列出高德本次查询耗时，说明两者统计口径与时间属性可能不同。
  • 只有 3–4 条记录：可报告样本中位数、最大值与样本量；采用较保守的历史最大值/当前路线参考+缓冲作为启发式，不称为稳定的“P85 保证”。
  • 仅有 1–2 条记录：不声称已学会波动规律，主要使用高德当前路线参考与人工缓冲。
  • 没有历史耗时：将高德本次规划的完整路线时长作为基线，加默认启发式 max(5 分钟, 基线 × 20%) 的不确定性余量；公交/地铁额外的等车、进站、接驳时间只有不包含在路线时长中时才加入，且须说明估计来源。这不是次日路况预测。
  • extra_buffer_min 是用户的额外安全缓冲，默认 5 分钟；不要在已有门到门历史耗时中重复加算等待、停车或步行接驳时间。
  • 不利天气、行李、换乘密集等情况可增加单独标注的策略余量，但仅作为“保守安排”，没有相同天气历史时不能宣称是高德算出的影响或科学校准值。

计算公式：

recommended_departure = required_arrival_time
                      - conservative_door_to_door_duration
                      - extra_buffer_min
                      - optional_explicit_weather_buffer

以分钟粒度表示本地时刻；如果计算跨日，明确注明日期。建议“最晚稳妥出门时间”而非“保证准时”，且必须解释为什么早于习惯出门时间。若 recommended_departure 早于当前时间、交通方式不可达或不满足用户硬约束，应明说方案不可行。

Step 6：选择交通方式

  1. 硬约束优先：出行方式可用、路线真实、用户预算与禁忌、雨雪避险、必须到达时间、已知运营时段。不满足者不能成为推荐。
  2. 在可行方式中按用户偏好排序：默认先降低迟到风险（保守时长和必要的提前出门程度），再减少换乘/不适、出行成本、碳排与步行量。没有可靠成本或排放数据时不能编造数值。
  3. 当两种方式效果相近时优先历史常用方式，降低切换成本；但应允许用户指定“最低成本”“少步行”“尽量不骑车”等新偏好。
  4. 比较的各模式必须使用明确口径：当前 MCP 路线参考 / 历史门到门耗时 / 人工缓冲，不得混成单一“明日高德预测 ETA”。
  5. 结果最多展示 1 条主方案和 1–2 条备选，优先清晰而非堆砌全部信息。

Step 7：输出并支持反馈

建议按以下格式回答（没有事实就删去该项，不要填猜测数值）：

## 明日通勤建议｜YYYY-MM-DD（周X）
路线：起点简称 → 目的地简称｜目标 HH:MM 前到达
明日天气：高德预报内容（查询日期：...）；如未覆盖明天，写“次日天气未核实”

【习惯预测】
- 可能交通方式：...（历史 n 条，可比样本 ... 条）
- 习惯出门时间：HH:MM（历史加权中位数；无记录时不输出）

【推荐计划】
- 推荐方式：...
- 建议最晚 HH:MM 出门（日期）
- 计算：HH:MM - 历史门到门 P85 / 路线参考 XX 分钟 - 安全缓冲 X 分钟
- 相对习惯：建议提前 X 分钟（若可计算）
- 理由：从历史、路线、天气各选 1 条有证据的理由

【备选】另一方式、其最晚建议出门时间、主要取舍
【可靠性】高/中/低；说明样本数、明日路况是否可查、时刻表是否可核实
【出行前复查】若为驾车/公交高峰，请在出发前再次查路线及运营状态

末尾用一行轻量反馈提示：“实际几点出门、怎么走、几点到？记录下来可以改善下次预测。” 仅在宿主具备文件写入或已授权记忆/数据库工具时才保存，并先明确用户授权；否则给出可复制的一行 CSV/JSON，不要声称已自动记录。

置信度与失败处理

  • 较高可信度（仅针对历史行为规律，不代表明日 ETA 确定）：同一路线/日期类型有效样本 ≥ 8，常用方式稳定且有 ≥ 5 个对应耗时记录，并且起终点、到达要求已明确。
  • 中等可信度：有效可比记录 3–7，或天气/时段匹配不足。
  • 低可信度：有效记录 1–2、历史只有出门无到达、目的地临时变更、未来日程未知、只有当前路线快照等。
  • 无行为预测依据：0 条记录，直说“没有足够历史记录预测你的习惯”；若有起终点和到达约束，可以做非个性化通勤规划。
  • 工具失败或某模式无路线：只报告已核实模式，不伪造路线、时间或交通价格；必要时说明仍缺哪一项。
  • 交通事故、封路、暴雨、航班高铁等突发事件与不可预测性必须清楚提示；不得保证 100% 准时。
  • 不应泄露精确住址、历史轨迹或私人行程记录给不必要的第三方。仅向路线 MCP 提交路线计算所需坐标，默认输出地点简称而不是家庭门牌和原始轨迹。

示例（所有数据均为演示，不是真实高德查询）

以 examples/history_sample.csv 中的 10 条虚构工作日记录为例：用户需要 09:00 前到达，10 条历史均为地铁，门到门耗时按最近秩计算 P85 为 44 分钟，习惯出门时刻中位数约 08:17。若额外安全缓冲 5 分钟、无其它缓冲：

  • 习惯预测：大概 08:17 出门，通常乘地铁（此处演示不计算日期权重）。
  • 推荐计划：最晚 09:00 - 44min - 5min = 08:11 出门，建议比习惯提前约 6 分钟。
  • 若次日天气不利但缺少可靠量化依据，可建议更保守安排，必须将额外分钟数明确标为人为余量，不标成“高德预测”。

以上仅演示计算方法；用户真实任务中的天气、路线、历史分位数都必须来自对应数据源。

自检清单（回答前必须核对）

  • [ ] 历史预测 vs 准时建议明确分开；没有历史不伪造习惯。
  • [ ] 明天日期、时区、通勤方向、实际目标到达时刻已确定或标明假设。
  • [ ] 每个推荐模式的路线真实由高德 MCP 核验；同名 POI 已消歧。
  • [ ] 没有冒称具备未来某一时刻的交通拥堵预测或公交时刻表。
  • [ ] 历史门到门时间、工具路线时间、启发式缓冲区分来源和单位，避免双算。
  • [ ] 雨天建议确有次日天气数据；样本不足时降低信心。
  • [ ] 结果能解释“为什么这个时间、为什么这个方式”。

参考

  • 高德官方 MCP Server 概述：https://developer.amap.com/api/mcp-server/summary
  • 高德 Web 服务未来路径规划（属于独立能力，不自动等于本 MCP 可用）：https://lbs.amap.com/api/webservice/guide/api-advanced/advanced-path
  • Agent Skills 规范：https://agentskills.io/specification
<!-- OB-S:EtokUPZslI_VEm73aFfAZA -->