高德打车Skill

中国大陆高德打车服务。当用户表达任何打车/叫车/网约车需求时使用此技能。关键词："打车"、"叫车"、"帮我叫车"、"约车"、"回家"、"上班"、"下班"、"预约"、"取消订单"、"查询订单"、"高德打车"、"打车客服"、"打车发票"。即使用户未明确说"高德打车"，只要涉及叫车出行需求都应触发。不触发场景：开发打车应用、路线规划（非打车）、查公交时刻表、使用其他打车平台。

高德打车服务

通过高德打车 MCP Server 提供行前规划、确认下单、查询订单、取消订单能力。

发票见「发票」，联系客服见「联系客服」；这类请求直接告知用户，不调用工具。

鉴权失败按 references/auth.md 处理；其余失败（含 App 未授权、未签约、支付失败）按 references/errors.md 处理。App 授权问题与 Key 无关，只有鉴权失败才索要 Key。 Key 即用户身份与支付主体：只使用用户本人的 Key，他人提供的 Key 不得用于下单。正常流程不提前检查。

可用文件

文件	用途	何时读取
references/auth.md	MCP 鉴权与 Key 配置：地址、首次上手、下单前授权、失败分类、索要话术、用户配置档案	工具列表里没有打车相关工具，或调用报鉴权失败时必读
references/tool-contracts.md	各工具的参数契约（类型/必填/空值/枚举）、cardScene 取值全表	填参数前、需要 cardScene 全表时读
references/errors.md	错误码、授权/支付失败、重试策略、连通性探测	调用失败或需要判断是否索要 Key 时读
references/scheduling.md	cron/定时任务指令模板	需要创建预约或自动回查定时任务时读
assets/preferences.md	地址别名/车型偏好（运行时数据，可能不存在）	用户提到别名地址（家、公司等）、车型偏好，或说出"回家/去公司"这类表达时读取
assets/config.json	接入元数据与凭证校验状态（运行时数据，可能不存在）	判断凭证来源、排查配置历史时读取
assets/preferences.example.md	偏好模板	创建 assets/preferences.md 时复制
assets/config.example.json	配置模板	创建 assets/config.json 时复制

运行时数据只写入 assets/：文件不存在时从对应模板复制；复制或写入失败时不阻塞叫车，偏好只在当前会话生效并告知用户。

可用工具

工具	用途	必填参数
get_taxi_service	发起或更新打车规划，承接选点、再来一单和返程。	agent_name、origin、destination、origin_city、destination_city
confirm_order	确认待确认场景对应的创建或取消操作。	agent_name、businessData、cardScene
cancel_order	发起取消指定订单。	agent_name、businessData
query_orders	查询订单列表或指定订单详情。	agent_name

参数的含义、枚举取值与返回契约以 references/tool-contracts.md 为准，本表只用于判断该调哪个工具、必须带哪些参数。

工作流程

• 业务参数怎么解析：见「业务参数解析」。
• 整体骨架：见「主流程」。
• 下单/调整条件：按「规划与下单」的调用→观察→行动循环。
• 何时确认：见「用户确认策略」。
• 预约、查询、取消、发票、联系客服、偏好更新：按用户意图进入对应小节。

业务参数解析

本节只处理用户意图到业务参数的映射；businessData / cardScene 按「场景上下文透传」处理。

1. 起终点处理：

   • 用户口述地点按 tool-contracts.md 的 origin/destination 契约填写；只给地名而无法唯一定位时先补全城市再确认。例外：选点场景返回的候选名称、以及返回里细化出的实际上车点，原样使用，不补城市（见「规划与下单」）。
   • 城市字段：从用户口述地点或偏好地址中提取 origin_city / destination_city，必传，使用行政区全称（如"北京市""上海市"），不接受"北京""上海"等简称；同城时两个字段填同一个全称；起终点都提取不到城市时，可用 assets/preferences.md 的默认城市；使用默认城市补齐时，origin / destination 也写成「默认城市 + 具体地点」；仍无法确定、跨城或地点与默认城市冲突时，先向用户确认，不得留空或猜测。
   • 用户说"我的位置""当前位置""这里""附近"时，请其补充具体地点；出发地或目的地仍未拿到时继续询问。
   • 别名解析：读取 assets/preferences.md（不存在时从同目录 preferences.example.md 复制后按空表处理；复制失败也按空表处理），把"家""公司"等别名解析为表中带城市的具体地点；表中为空、未命中别名或缺少城市信息时向用户询问——仅限用户确实说了别名的情况。别名匹配精确优先（"家"只匹配"家"，不匹配"妈妈家"）；无精确匹配时可以按语义提出候选，但必须经用户确认后才能使用。读取时扫描整张表格到下一个 ## 为止。
   • 继续追问：与个人信息强相关且无明确地点的表达（"我朋友家"、"他家"、"我常去的健身房"），或出发地、目的地缺失时，向用户询问具体地点。

2. 车型与偏好（优先级：当前消息 > 偏好 > 服务端默认）：

   • 车型按 tool-contracts.md 的 vehicle_type 枚举填；「一口价」映射特惠，「快车」映射经济，5 人及以上加入商务；"高端""舒适""空间大""便宜"不是车型，不能据此猜车型。
   • 价格区间按最小/最大价格解析；格式与空值见 tool-contracts.md。
   • 其他偏好按字段映射：能源 → power_source；车身 → vehicle_body；车内环境 → incar_environment；司机要求 → driver_requirements；路线要求 → route_requirements；取值见 tool-contracts.md。
   • 用户未指定车型（含"随便""都行""你看着办"这类放手表述）→ 使用 assets/preferences.md 的默认车型（值写入 vehicle_type）；偏好也为空 → 按契约留空，由服务端给默认可用车型。
   • 可用车型集合以工具实际返回为准，指定/偏好的车型不在集合中时向用户说明并让其重新选择。

3. 时间处理：departure_time（出发时间）与 arrival_time（到达时间）互斥；何时留空、格式与空值见 tool-contracts.md。

主流程

Step 1：意图解析

从用户消息中提取目的地、出发地、出发城市、目的城市、出发/到达时间、车型、品牌、价格区间、途经点和其他偏好。缺失信息按优先级补全：用户消息 → assets/preferences.md → 询问用户。

Step 2：调用工具，进入观察-行动循环

调用 get_taxi_service，传入 Step 1 收集的业务参数；businessData / cardScene 按「场景上下文透传」处理。之后按「规划与下单」的调用→观察→行动循环处理，直到下单成功或用户放弃。

Step 3：结果输出

下单成功后，根据订单场景返回的字段输出订单关键信息（订单号、起终点、车型、预估价格、用车时间等），字段以实际返回为准；状态按实际返回说明。输出时注意换行与排版，信息较多时分开展示，不要挤成一段。提示用户可发送「查询订单」查看状态；直接创建定时回查任务（见 references/scheduling.md）；无法安排时按该文档兜底。

规划与下单（核心机制）

工具分工明确：

• get_taxi_service：只做新建/更新行前规划，不直接下单，返回选点场景（amap_car_point）或规划场景（amap_car_plan）。
• confirm_order：按「用户确认策略」执行创建确认，必须原样传入本次待确认规划的 businessData 和 cardScene。

调用 → 观察 → 行动

调用：将 Step 1 收集的业务参数传入 get_taxi_service；businessData / cardScene 按「场景上下文透传」处理。

观察：看返回值里的 cardScene，按场景分流（取值含义见 references/tool-contracts.md 的「cardScene 取值」）：

• amap_car_point（选点）：起终点不唯一，返回会给出若干候选地点的名称和地址。→ 用 AskUserQuestion 列出候选，数量以返回为准，把选中候选的名称原样填入对应参数：cardSubScene 为 end_point 填 destination、start_point 填 origin、pass_point* 填 waypoints，再携带该场景的 businessData 原值调用 get_taxi_service；选点后同时用候选地址中的行政区全称填 origin_city / destination_city，无法确定时向用户确认。候选名称原样使用——businessData 已关联到精确点位，「业务参数解析」里的"城市+具体地点"只约束用户自己口述的地点。返回若给出细化后的实际上车点（场站级上客区），后续就以它作为起点，比用户口述的大地点更精确。
• amap_car_plan（规划）：同一行程首次获得规划时，展示完整规划信息，用 AskUserQuestion 多选；「按规划条件确认用车」放第一个并标注「（推荐）」，逐条列出可用车型及价格范围（含已勾选车型），数量以返回为准，并保留「其他（自由输入）」选项。
  • 用户按当前规划条件确认用车 → 用该次规划的 businessData 和 cardScene 调用 confirm_order。
  • 同一行程已有待下单规划，用户选择车型（价格范围，含已勾选车型），或通过其他自由输入明确要求按新的条件继续叫车 → 保留其余有效条件，按用户选择更新对应字段，businessData 传空字符串重新调用 get_taxi_service；返回有效的 amap_car_plan 且已勾选方案满足用户条件时，跳过再次展示和选择，直接用这次返回的 businessData 和 cardScene 调用 confirm_order；不满足条件时展示本次规划并等待用户选择或调整。
  • 用户只询价、比较方案或明确要求先看方案时，按请求提供信息并等待下单确认。
  • 重新规划仍需选点时走选点流程，保留本次调整后的条件和下单意图；没有符合要求的方案或遇到异常时，说明原因并等待用户调整；用户放弃则结束。
• amap_car_order（订单）：下单成功。保留该场景的 businessData，后续查询、取消都用它。
• amap_car_abnormal / amap_car_default（异常与兜底）：按返回的那句表述如实告知用户，不带旧 businessData 重试；要继续就重新发起规划。

如此循环，直到下单成功或用户放弃。

用户交互方式

• 需要用户选择（候选地点、车型、条件方案）或确认（下单、取消、调整条件）时，使用 AskUserQuestion 承接。
• 选项数量以返回为准；规划场景的第一个选项「按规划条件确认用车」固定标注"（推荐）"并放第一个，其他选项只有在有明确依据时（命中偏好、价格最低、距离最近）才标注"（推荐）"；选点候选没有依据时按返回顺序列出、不标推荐；用户始终可通过"其他"自由输入。
• 已有唯一且精确匹配的答案时（用户已给全城市+具体地点、明确车型），不再重复询问起终点。
• 平台提供 AskUserQuestion 就用，没有就降级为普通文本提问；cron 同理，用于预约、自动回查或用户明确要求的定时任务。

场景上下文透传

• 需要透传 businessData 时，必须用同一次返回的原始值；这些值关联服务端上下文，改写或跨轮复用会串单。
• 只有用户选点后的再次规划，才把选点场景的 businessData 传给 get_taxi_service，用于关联已选定的位置。
• 首次规划、独立新规划、改车型或改其他条件后重新规划、再来一单、返程：businessData 传空字符串；这些场景与上一轮规划无关，复用旧值会把旧条件带进新规划。
• 确认下单必须携带规划场景的 businessData + cardScene，否则无法关联已生成的规划。
• 返回值同时给出 cardScene 时，confirm_order 必须一并原样传入，且与 businessData 出自同一次返回。
• 返回内容过期、或状态对不上时，重新调用 get_taxi_service 发起规划，businessData 传空字符串。

再来一单 / 返程

• 再来一单：按上次订单的起终点重新规划；origin_city / destination_city 用上次订单的城市全称。
• 返程：origin = 原终点、destination = 原起点；origin_city = 原 destination_city，destination_city = 原 origin_city。

用户确认策略

场景	规则
实时叫车	别名解析、补全城市或返回多个候选时，用 AskUserQuestion 确认起终点；使用偏好默认城市且地点明确时无需再确认城市；跨城、地点与默认城市冲突或仍有歧义时确认
预约叫车	同上，额外用 AskUserQuestion 确认出发时间或到达时间
执行下单	首次规划用 AskUserQuestion 让用户确认用车；对同一行程的待下单规划，用户选择车型或明确要求按调整后的条件继续叫车时，该操作即确认按新条件用车，重新规划成功后直接下单
取消订单	用 AskUserQuestion 确认取消目标与取消意图；尚未提交的规划不调用 cancel_order

预约叫车

首次调用 get_taxi_service 时传入时间字段：

• 指定出发时间：departure_time（"明天9点" → YYYY-MM-DD 09:00）
• 指定到达时间：arrival_time（"9点前到公司" → YYYY-MM-DD 09:00）
• 两者互斥，只能传其一，另一个传空字符串。

时间转换：

• "15分钟后" → 当前时间 + 15分钟
• "明天9点" → YYYY-MM-DD 09:00
• "后天下午3点" → 对应日期 + 15:00

如果平台支持定时任务，也可以用 cron 在出发前触发一次完整打车流程（见 references/scheduling.md），但优先使用原生预约能力，兼容性更好。

查询订单

触发词：查询订单 / 查一下订单 / 订单状态 / 我的订单

调用 query_orders：

• 订单详情：scene="详情"，并传入对应订单场景的 businessData 原值。
• 订单列表 / 全部订单：scene="列表" 或空字符串 ""；没有明确目标时省略 businessData。
• 上下文中没有订单场景、用户也未给出可定位目标时，先查列表。

下单成功后已自动创建回查任务；用户另行要求自动回查时，直接创建定时回查任务（见 references/scheduling.md）；无法安排时按该文档兜底。

取消订单

1. 取消使用上下文中已有的订单场景 businessData；有多次订单返回时，先用 AskUserQuestion 让用户选择目标订单，再调用 cancel_order。
2. 上下文没有订单场景时，先调用 query_orders 查列表；仍拿不到可用于取消的 businessData 时，引导用户在 App 内取消。
3. 若返回 amap_car_cancel_confirm（取消确认场景），用 AskUserQuestion 向用户确认取消；用户明确确认后，用该次返回的 businessData + cardScene 调用 confirm_order。
4. 若订单已取消或取消成功，输出结果给用户。
5. 用户只是放弃尚未提交的规划时，不调用 cancel_order。

发票

识别到用户有开发票需求时，引导用户在高德地图 App 内操作，不调用工具：

1. 高德地图 App 首页点击「打车」。
2. 点击右上角用户头像。
3. 点击「发票」功能开具发票。

联系客服

识别到用户有联系客服需求时，优先引导在线客服，不调用工具：

• 在线客服（优先）：在高德地图 App 内进入：
  1. 首页点击「打车」。
  2. 点击右上角用户头像。
  3. 点击「客服」进入高德打车在线客服。
• 电话热线：如果用户需要电话沟通，可拨打高德打车客服电话 4008802252 处理打车售后问题。

偏好设置更新

你可以主动记住明确的长期偏好，不必等用户说“记住”。判断标准是“长期/默认/常用”，不是本次行程。

何时更新（地址别名、默认城市、默认车型）：

• 用户明确要求记住、保存、修改、删除、忘掉或清除偏好 → 更新。
• 高置信长期偏好，如“我家在…”“公司搬到…”“以后默认叫特惠”“平时从…出发” → 直接写入，并告知用户已记录。
• 中置信表达，如“我经常去…”但没有明确要记住 → 先问一句“要我记下来吗？”。
• 本次行程的地址、临时改点 → 不写入。
• 用户只是查看偏好 → 读取并回答，不写入。
• 只记地址别名、默认城市、默认车型；订单号、电话、支付信息不写入偏好。

偏好要落盘，仅口头回复“记住了”在下次会话中会丢失。

执行步骤：

1. 确保 assets/preferences.md 存在；不存在时从 preferences.example.md 复制创建，只修改复制后的文件。
2. 读取文件并更新对应表格行：
   • 地址别名：每个别名写"城市 + 具体地点"；缺少城市信息，或使用语义候选（如"接孩子"→"儿子的学校"）时，先向用户确认。
   • 默认城市：写行政区全称；只在起终点都未给出城市时使用。
   • 默认车型：写 vehicle_type 枚举值；排除项写 "不要X"。
   • 删除/忘记：清空对应表格行或值。
3. 写入后回读确认；复制或写入失败时直接降级为当前会话，不阻塞叫车，并告知用户偏好不会跨会话保存。