Travel Booking

---
name: travel-booking
description: 把用户选定的交通或住宿方案生成购票链接。当用户表达购买意图时触发，如买票、订票、预订、购买、就要这个、帮我订、生成购票链接、"订方案一"、"就要这趟 G1 二等座"。注意：只说车次/航班号但没有购买意图时，视为查询，走 travel-query。
description_zh: 按用户选定的航班舱位/车次座席/酒店房型生成购票链接。
description_en: Generate booking links for the flight cabin, train seat or hotel room the user selected.
version: 1.0.0
author: 梓如商旅
---

# 购票预订

把用户选定的交通/住宿方案生成**购票链接**。用户点击链接确认后才真正完成预订。

## 与查询、规划的分工

- 只想查班次/舱位/房型 → `travel-query`
- 要规划一整段行程（多段交通 + 住宿）→ `travel-plan`
- 已经选定方案、要买 → 本技能

## 核心规则

### 1. 生成的是链接，不是订单

创单工具（`ziru_flight_order_link` / `ziru_train_order_link` / `ziru_hotel_order_link` / 合并用的 `ziru_merge_order_link`）都是**前置流程、不真正落单**：返回一条**购票链接**（`orderLinkUrl`，1 小时内有效）和方案摘要（`orderInfo`）。

给用户时必须说明这是**已生成的购票链接、不是已完成的订单**，措辞用"已为您生成购票链接"，**禁用"下单"**，也不要说"已预订/已出票/已确认"。链接以**裸 URL 独占一行**输出，前缀 `预订链接: `，不要包成 Markdown 超链接，详见「输出规则」。

### 2. 各项各调对应工具，入参保取自前序结果，不得自己编

| 场景 | 工具 | 入参（来源） |
|---|---|---|
| 机票 | `ziru_flight_order_link` | `cabinId`（取自 `ziru_flight_cabin` 返回的 `cabinId`） |
| 火车票 | `ziru_train_order_link` | `trainNo`、`fromStation`、`toStation`、`date`、`seatCode`（`seatCode` 取自 `ziru_train_list` 的 `seats[].seatCode`） |
| 酒店 | `ziru_hotel_order_link` | `hotelId`、`hotelName`、`roomTypeKeyID`、`productNo`（后两者取自 `ziru_hotel_room` 的 `ratePlan[]`）、`checkInDate`、`checkOutDate` |
| 合并成一条链接 | `ziru_merge_order_link` | `detailIds`（前面各创单工具返回的 `detailId` 列表） |

四个创单工具的完整入参、返回字段与失败情形见 `@references/order.md`。

### 3. 标识缺失就先补齐，不要凭空编

- 要订机票但还没查过舱位 → 先 `ziru_flight_cabin` 拿到 `cabinId`
- 要订酒店但还没查过房型 → 先 `ziru_hotel_room` 拿到 `roomTypeKeyID` + `productNo`

`cabinId` / `seatCode` / `roomTypeKeyID` / `productNo` 都只能来自工具返回，**严禁编造或用相似值顶替**。

### 4. 待订项要精确到"哪一档"

一个航班有多个舱位、一个酒店有多个房型产品、一趟车有多个座席——必须确认用户要的是哪一档。日期、人数也要明确。

- 用户已在前文选定（"订方案一""就要这个 G1 二等座"）→ 直接按选定的那一档生成。
- 待订项不明确、或一次要订多项 → 先把待订清单列给用户确认，再生成。

### 5. 多段出行：先逐项生成，再合并成一条链接

一趟行程有去程/返程/住宿多项时，按行程顺序**逐项调用**各自的创单工具（各自拿到一个 `detailId`），全部生成完后用 `ziru_merge_order_link` 把 `detailIds` 合成**一条**链接，只把这一条输出给用户——逐项各贴一条链接，用户要点很多次。

- **只有一项**要订时不合并（多一次调用没有意义），直接输出那一条链接。
- 生成失败的项（如"无房""未找到座席"）没有 `detailId`：**只把生成成功的 `detailId` 传去合并**，并如实说明哪一项没订上、原因是什么。
- 合并要求每个 `detailId` 都还在有效期内（1 小时）；报"不存在或已过期"时，把那一项重新生成后再合并。

### 6. 未开售的火车票订不了

车次 `saleStatus` 为 `未开售`/`暂停发售`/`暂售至` 时不能生成链接。已知未开售就**不要调用创单工具**，直接提示用户 **`saleDateTime` 才开售**；若仍调用，工具会按实时状态拦下并返回失败原因（见 `@references/order.md`），如实转达即可。

### 7. 实时校验由工具完成

创单工具内部会按实时数据重新匹配车次/座席/舱位/房态。匹配不上（如"未查到车次""未找到座席码""无房"）就是当下订不了，**如实转达 message**，建议用户重新查询后再订，不要硬凑。

---

## 流程

1. 从对话中确定要订的**具体项**及其标识（哪一趟/哪一档/哪些日期）。
2. 标识不全 → 用查询工具补齐（见规则 3）。
3. 逐项调用对应的创单工具，记下各自的 `detailId` 与摘要。
4. 两项及以上 → 调用 `ziru_merge_order_link` 合并成一条链接（见规则 5）。
5. 汇总输出：列出各项方案摘要 + **一条裸 URL 形式**的购票链接（`预订链接: <url>`）+ 失效时间。

## 输出示例

> **购票链接必须原样输出成裸 URL**（`预订链接: <url>`），不要包成 Markdown 超链接（`[文字](url)`）——调用方（聊天客户端）靠识别裸 URL 渲染成可点击入口，Markdown 写法反而不渲染。

```
已为您生成购票链接（1 小时内有效，点击链接确认后才完成预订）：

火车 G1 北京南→上海虹桥 9/20 08:12 发车，二等座 525 元
酒店 上海某某酒店 9/20-9/22 豪华大床房，双早、可取消，780 元/晚

已合并为一条链接，点一次即可把以上各项一起确认：
预订链接: https://...

本次链接 2026-09-17 18:30 前有效，逾期请重新生成。
```

**输出规则**
- **多段出行只输出一条链接**：逐项生成后用 `ziru_merge_order_link` 合并（规则 5），不要把各项链接分别贴出来。
- **购票链接用裸 URL 独占一行**：把工具返回的 `orderLinkUrl` 原样放在 `预订链接: ` 之后，**不写成 Markdown 超链接**（`[文字](url)`），不缩略、不改写、不拼接进句子。
- **明确告诉调用方这是什么**：这是为用户生成的**可点击购票链接**，点开确认后才真正完成预订，**不是已完成的订单**。
- 摘要用工具返回的 `orderInfo`（已含方案摘要与失效时间）。
- 只写工具返回里确有的信息，不补充金额合计、不承诺余票。
- 说明期限：链接 **1 小时内有效**。

## 异常与鉴权

- 鉴权失败或提示凭据无效时，告知用户**重新授权**（凭据已失效，请在所用平台的连接器设置中重新登录授权），不要反复重试。
- 接口失败时把 message 里的原因如实转达（如"未查到车次 G1""未找到座席码 O 的座席""无房"），不要吞掉或改写成模糊说法。
- 合并报"订单标识 xxx 不存在或已过期"时，说明这一项的链接已过期，重新生成该项后再合并。

## 不做的事

- 不生成"订单"，不承诺已出票/已预订成功——只生成购票链接，由用户点击确认。
- 不编造 `cabinId`/`seatCode`/`roomTypeKeyID`/`productNo`/`detailId` 等标识。
- 不逐项输出多条链接——多段出行按规则 5 合并成一条。
- 与用户沟通禁用"下单"一词，统一用"预订""购票""生成购票链接"。