Travel Plan

---
name: travel-plan
description: 为一次完整出行生成可落地的行程方案：先拆解行程清单，再逐段串行落实各段交通与住宿，最后汇总输出一份行程方案。当用户提到规划行程、出差规划、安排行程、帮我规划、几天行程、去某地几天、需要交通和酒店、怎么走怎么住、中转、换乘、没有直达时触发。
description_zh: 把一次完整出行规划成行程方案（各段交通 + 住宿 + 日程），逐段串行落实。
description_en: Plan a complete trip itinerary, break down the demand, resolve each leg's transport and lodging serially, and output a trip plan.
version: 1.0.0
author: 梓如商旅
---

# 行程规划

把用户的一次完整出行（多段交通 + 住宿 + 日程）规划成一份可落地的行程方案。

## 与其它技能的分工

- 只想查班次/舱位/房型、看有哪些选项、对比某两趟车（单点问题）→ 用 `travel-query`
- 要一整段行程（多段交通 + 住宿 + 日程，需要排先后、定日期）→ 用本技能
- 已选定方案、要买 → 用 `travel-booking` 生成购票链接
- 本技能只做**规划与查询**，不生成购票链接；与用户沟通禁用"下单"，统一用"预订/推荐"

## 工具

| 工具 | 用途 |
|---|---|
| `ziru_train_list` | 某线路某天的车次列表 |
| `ziru_flight_list` | 某航线某天的航班列表 |
| `ziru_flight_cabin` | 某个具体航班的全部舱位 |
| `ziru_hotel_list` | 某城市的酒店列表 |
| `ziru_hotel_room` | 某个具体酒店的房型与价格方案 |
| `ziru_transfer_plan` | 跨城走廊全景（有哪几条路径、经哪个枢纽换乘、每段的城市与枢纽、火车/飞机、预估耗时，**不含班次**） |

字段口径与参数细节同「出行查询」技能（火车地名口径、机票三字码、酒店 cityCode 等），关键点见下。

## 核心规则

### 1. 严格串行，一段一段来

按时间顺序推进：**先把这一段的交通定下来（拿到真实到达时刻）→ 再用它定这一段的住宿 → 才进下一段**。不要把所有交通/酒店并行铺开查。

理由是住宿的入离日期直接依赖交通的真实到达/出发时刻，串行能天然对齐，避免"排了酒店后来发现车次对不上"。

### 2. 一律先查列表，再用列表里的标识查详情

- `ziru_flight_list` 拿 `flightNo` → 再用 `ziru_flight_cabin` 查舱位
- `ziru_hotel_list` 拿 `hotelId` 和 `hotelName` → 再用 `ziru_hotel_room` 查房型（两者都必填）

### 3. 三类工具的参数口径

- **火车**：地名用 12306 口径、**不带行政后缀**（`北京` ✅ / `北京市` ❌；`北京南` ✅ / `北京南站` ❌）；只查 15 天内。
- **机票**：传 IATA 三字码（`PEK`/`SHA`），不传城市名。
- **酒店**：`cityCode`（行政区划代码，如南京 `320100`）**必填**；用户提到"靠近某地"时把该地经纬度传 `lon`/`lat` 并配 `distanceMeters`；偏好传 `intent`。
- **中转方案**：`ziru_transfer_plan` 的城市名口径**比火车宽松**（带不带行政后缀都行，还支持 `PEK` 这类机场三字码和景点名），**不要套用上面火车那条"去掉后缀"的规则**；县级地名（如 鲁山）先按原话传，查不到再试上位地级市或就近枢纽名。可选 `mode`：`all` 不限（默认）／`flight` 仅飞机／`rail` 仅火车，**`rail` 含普速 K/T/Z，不是只含高铁动车**，只要动车组需在 `ziru_train_list` 结果里自行筛。

### 4. 日期由交通锚定，不拍脑袋

- 酒店入住日 = 到达日（**凌晨 <06:00 到达 → 记为前一天入住**）；离店日 = 离开交通的出发日；**不规划返程段时，离店日按停留天数（用户说的天数）**。**同城连住合并为一段。**
- **返程只在用户明确要返回时才规划**；用户没提回程就不排返程段（多城单程链在终点就地收束）。
- "出差 X 天" = 出发日算第 1 天，返程日 = 出发日 + X，住到返程日退房。
- **当天往返不排住宿**（只有过夜才排住宿）。
- 用户没给时刻时的默认时段：首段去目的地 → 上午出发；末段返程 → 下午出发；中间段依到达侧日程。

### 5. 锚点是"到场时刻"，两侧都要核算

**到达侧**：需求里"到达后的日程"（如"当天下午须赴某地参会""上午 9 点须到某地开会"）是硬约束——
**最晚到达时刻 = 日程时刻 − 市内接驳 − 缓冲**。当日班次无法按时到达时，自动改期（提前一天）重查。

**出发侧**：下一段的出发时刻同样是硬约束——
**最晚离开住宿地的时刻 = 出发时刻 − 到出发站/机场的接驳 − 缓冲**。
住得离出发站越远，这道减法越要算全：住山顶/景区内要**先扣下山时间、再扣到站车程**；凌晨到、早班走这类也要按实际接驳核。

两侧任一算不通：**先换住宿位置或换班次**，都不行才如实说明。**方案里出现"赶不上"的一律不可接受**，宁可选不优雅的班次也不能迟到。

### 6. 约束忠实保留

用户明确提出的偏好、时间、人数、座位/舱位、酒店品牌、价格等，贴近原话写进对应段，不删改、不弱化；"优先/最好/均可"等程度词与备选项原样保留（"高铁/火车优先"不能缩成"高铁"）。

### 7. 查不到就是没有，如实说，不要编

`ziru_train_list` / `ziru_flight_list` 空数组 = 该线路当天没有班次；`ziru_hotel_room` 失败且 message 写明"无可售房型" = 该酒店这些日期没房。不为了"给个方案"编造班次/酒店/价格，也不拿别的日期或城市的数据顶上。

### 8. 只推火车/飞机，不推汽车大巴

中转时至少有一段符合用户要求的交通方式；**严禁**推荐汽车、大巴、顺风车等其他方式。

### 9. 退改签、行李、取消政策直接引用

`ziru_flight_cabin` 的 `refundRule`/`changeRule`/`luggage`、`ziru_hotel_room` 的 `cancelRule.refundStr` 都是拼好的中文，**原样转述**，不改写、不补充未返回的内容。

### 10. 未开售火车要提示开售时间

`ziru_train_list` 的每个车次带 `saleStatus`（`正常`/`暂停发售`/`未开售`/`暂售至`）与 `saleDateTime`。未开售的车次照常返回，但要明确告诉用户"**该车次 {saleDateTime} 才开售**"，不要当成已可预订推荐出去。

### 11. 出发地、目的地、日期缺任一就先问

不用"今天/明天"之类的假设去查。地点/日期推不出时先反问，不编造。

### 12. 住宿没交代清就先问

用户只说"去某地出差"这类、没说停留几天、也没说要住宿时，先反问：**是否需要安排住宿、住哪几天？** 不要默认排住宿，也不要默认不排。

### 13. 范围门禁

用户说"不用酒店/不用安排住宿/只安排交通"→ 只排交通；说"只要住宿"→ 只排住宿。用户没明说就按默认给全（交通 + 住宿）。

---

## 三步流程

### 第一步：需求拆解（内部完成，不对用户输出过程）

从用户原话和上下文里拆出：

- **出发城市**：用户明说 > 消息里的线索 > 反问。只出现一个城市又推不出出发地时，反问"请问您从哪里出发？"。
- **有序节点清单**：`交通`（一段，从 A 到 B + 日期）/ `住宿`（一段，城市 + 入离日期），按执行顺序排列。
- **日程**：日期 + 事项（+ 用户明说的开始/结束时刻）。
- **每段交通的边界**：最早出发时刻 / 最晚到达时刻（用户明说，或由日程推得）。

日期要换算成绝对日期（相对日期按当前日期推算，"下周"默认下周一）。反问/拒绝的情形：
- 出发地、目的地、日期推不出 → 反问一句，就此结束。
- 住宿没交代（说了去哪但没说停留几天、也没说要住宿）→ 反问"是否需要安排住宿、住哪几天"。
- 日期早于当前日期 → 反问确认。
- 出发城市 = 到达城市 → 直接说明需求无效。
- 出发或到达在中国大陆以外（港澳台及国外）→ 直接说明暂不支持。

### 第二步：逐段串行落实

按节点顺序，**一次处理一个节点**：

**交通节点**
1. 定方式：用户指定 > 用户偏好 > 距离/常识（能从出发地直接到的优先）。
2. 查班次：**先调 `ziru_transfer_plan(fromCity, toCity)` 取跨城走廊**（有哪几条路径、经哪个枢纽换乘、换乘几次、每段的城市与枢纽、火车还是飞机、预估耗时，**不含班次**），再按走廊里的城市用火车 `ziru_train_list`、飞机 `ziru_flight_list` 逐段查真实班次——**不要先只试直达、直达不满足才回头取走廊**。走廊里出现「**需自行从 X 前往 Y**」时，表示两段分属不同城市/枢纽、中间要自行接驳，**不是**同一枢纽内换乘。**它按历史运营数据汇总，图上有的走廊当天可能一班都没有（走廊有服务 ≠ 当天有班次）**——某条查不出班次、或两段接不上，就回返回里换下一条重查（**依次最多 3 条**）；都走不通才如实说明暂无可行中转，不要硬凑、不要编造。**严禁凭地理知识自己猜换乘城市，换乘城市只能来自 `ziru_transfer_plan` 的返回。**
3. 查完列表**立即**看最早到达能否满足最晚到达约束；能满足就挑班次，不能就改期（提前/推迟一天）重查。
4. 需要票价/退改/行李 → 航班走 `ziru_flight_cabin`；火车坐席在 `ziru_train_list` 的 `seats` 里。
5. **记下到达时刻**，作为本段住宿的入住依据、以及下一段最早出发的依据。

**住宿节点**
1. 前置：拿到该城**到达交通的到达时刻**和**离开交通的出发时刻**。
2. **先按第 5 条出发侧核算**：这家酒店的位置能不能在**离开交通出发时刻**前赶到出发站/机场（扣接驳 + 缓冲）？算不通就换位置更近的（离出发站近优先），不要选了酒店才发现第二天赶不上。
3. 查列表 `ziru_hotel_list`（`cityCode` 必填）→ 挑出主推的一家。
4. 查房型 `ziru_hotel_room`（`hotelId` + `hotelName` + 入离日期）。
5. 无房就如实说这家这些日期没房，换一家。**全部无房或用户要住的位置系统内根本没有房源（如山顶/景区内）**，只能写成"**建议自行预订**"并说明它对后续段的影响（如"需自行解决住宿，次日 08:44 发车"），**不得当成已确定的住宿节点推荐出去**。

**日程节点**：不查工具，直接按日期插入时间线。

一段的到达时刻确定后，才把日期交给下一段；**交之前还要过一遍出发侧核算**（住宿位置到下一段出发站/机场的接驳能不能赶上），过不了就先换住宿或班次，别把"赶不上"往后传。

### 第三步：汇总输出

按时间顺序输出一份**简洁文本清单**：

```
根据您的需求，已为您规划如下行程，请参考：

**去程交通** 9/20 北京南→上海虹桥 高铁 G1 二等座 08:12-14:23
推荐理由：早出午达，为当天下午的会议留足时间。

**日程** 9/20-9/22 上海 参加行业会议
**酒店** 9/20-9/22 上海某某酒店（豪华大床房，连住2晚）
推荐理由：距会场 1.5 公里，符合差标。

**返程交通** 9/22 上海虹桥→北京南 高铁 G2 二等座 15:00-20:55
推荐理由：会议结束后下午出发，当晚返回。

出行建议：请携带身份证件，提前预留市内接驳时间……
```

**输出规则**
- 每条行程一段，首行 `**{类型}** {日期} {详情}`，推荐理由另起一行 `推荐理由：…`；日程行不写推荐理由。
- 类型标签：首段交通 `去程交通`；**只有末段确实回到首段起点（真返程）才标 `返程交通`**，其余（含不回起点的单程链末段）标 `交通`；住宿 `酒店`；日程 `日程`。
- 日期一律用 `M/D`。
- 详情格式：
  - 火车：`{出发站}→{到达站} 高铁/动车 {车次} {坐席} {出发HH:mm}-{到达HH:mm}`
  - 飞机：`{出发机场}→{到达机场} 飞机 {航班号} {舱位} {起飞HH:mm}-{到达HH:mm}`
  - 中转：两段各写一小段、用"；"连接，写清换乘城市（**取自 `ziru_transfer_plan` 的返回**），如 `A→枢纽 高铁 G1 二等座 08:00-10:00；枢纽→C 高铁 G5 二等座 11:00-13:30（换乘枢纽，预留 60 分钟）`
  - 酒店：`{入住M/D} - {离店M/D} {酒店名}（{房型}，连住X晚）`
  - 日程：`{日期} {城市} {事项}`
- **推荐理由只讲已确认的事实**（班次/时刻/坐席/酒店/价格/距离/是否含早/能否取消等），**不无中生有**，不拿偏好或猜测当理由。
- 车次/航班/酒店必须是**第二步实际查到的**，不得编造。
- 未开售的车次：在推荐理由里**加粗**提示"**该车次 {saleDateTime} 才开售**"。
- 某段确实无合适方案：如实写"暂无合适班次/酒店"，并建议调整日期或更换交通方式，不要编造。
- 清单末尾写一段出行建议（行李证件、市内接驳、天气提示等）。

---

## 异常与鉴权

- 鉴权失败或提示凭据无效时，告知用户**重新授权**（凭据已失效，请在所用平台的连接器设置中重新登录授权），不要反复重试。
- 接口返回失败时，把 message 里的原因如实转达（如"该酒店 2026-09-20 至 2026-09-22 无可售房型"），不吞掉、不改写成模糊说法。

## 不做的事

- 不生成购票链接、不创建订单——本技能只负责规划与查询，购买走 `travel-booking`。
- 不编造班次、酒店、价格、退改规则。
- 不跨日期、跨城市"借用"数据凑方案。
- 不推荐汽车、大巴、顺风车等非火车/飞机交通方式。