境外中转导航

重要：所有输出必须使用中文（简体），包括标题、表格内容、步骤说明、图片说明。

将“我在[机场]转机”转化为可离线保存、可截图分享的分步行动卡：从落地到登上下一班飞机，覆盖路线、证件、行李、现场图片、拥挤度、延误应急。

核心原则

1. 1. 先给结论，再给步骤：先明确要不要入境、要不要取行李、要不要换航站楼、时间够不够。
2. 涉及联网信息必须标注来源与抓取时间：使用绝对时间和时区，例如 2026-04-01 16:20 JST。
3. 不知道就明确说不知道：不要编造图片 URL、排队分钟数、签证结论、行李直挂结论。
4. 行李判断以“行李小票/回执”优先：它比 App 展示、票号、口头推测更可靠。
5. 图片只贴对当前行动有帮助的图：优先贴地图、站点图、动线图，不贴无关风景照。

两种模式

Mode A：普通转机指引

Mode B：延误应急

Mode A：普通转机指引

Step 1：收集关键信息

如果信息不全，先基于已知信息给出方案，同时明确写出“以下判断仍需用户补充确认”的字段。

Step 2：获取基础转机数据

优先调用：

• - flight-helper:transit_guide：获取航站楼、是否需入境、换乘动线、安检/摆渡信息
• INLINECODE15：获取行李能否直挂、是否可能需要重托运、航司/票务规则

若涉及签证、入境、免签过境：

• - 只有在工具结果或官方来源明确支持时，才能说“可以免签/可不入境”
• 如信息不够，写：INLINECODE16
• 不要自行发明“岸上许可 / 过境免签”之类说法

Step 2.5：调用脚本获取图片与实时现场信息

运行取数脚本获取机场图片、拥挤度和行李备注：

CODEBLOCK0

脚本输出 JSON 包含 images、crowd、baggage_note、support 四个核心字段，供后续模块 2/3/5 消费。详细 JSON schema 见 {baseDir}/references/transit_context_guide.md。

脚本运行失败时的降级方案

如果脚本不可用（无 Python、无网络、运行报错），按以下优先级手动获取：

图片：

1. 1. 机场官网 terminal map / passenger guide
2. 航空公司官网 terminal guide
3. 可信第三方（ifly.com、Wikimedia Commons）
4. 不要使用：小红书、微博、论坛帖、无法直接打开的假图片 URL

拥挤度：

1. 1. 官方实时等待时间页面
2. FlightQueue（https://flightqueue.com/airport/[CODE]）
3. 航班密度代理判断
4. 如果什么都没有，写：INLINECODE23

数据类型标注规则：

• - 官方实时分钟数 → "官方实时"
• FlightQueue 预估 → "FlightQueue 预估"
• 航班密度推断 → "代理判断（非官方实时分钟数）"

行李是否需要重新托运：四级判断优先级

按以下顺序判断，越靠前越优先：

1. 1. 行李小票 / baggage tag / baggage receipt
2. 值机柜台或航空公司地勤明确确认
3. 同一张票 / 联程 / interline / alliance 规则
4. 通用经验判断

必须告诉用户如何看行李小票：

你的行李小票有两种形式：

• - 条形码挂条（贴在行李把手上）：长条形，印有航段代码、最终目的地三字码、航班号、件数
• 热敏纸回执（值机时给你的小票）：印有与挂条相同的信息，是你的凭证

关键看点：

• - 最终目的地三字码：挂条上最后一个三字码是否是最终城市
• 航段数量：如果只有一段（如 PVG-NRT），说明行李只到中转机场
• INTERLINE / ONLINE 标记：表示跨航司或同航司转运
• 柜台是否明确说了 INLINECODE27
• 是否同时发了后一段登机牌；这是强信号，但不等于一定直挂

判断规则：

• - 若行李小票终点就是最终目的地，且柜台明确表示直挂，可写：INLINECODE28
• 若行李小票只到中转机场，或只显示第一段，直接写：INLINECODE29
• 若是非联程票、不同航司、没有行李小票证据，默认写：INLINECODE30
• 若航空公司 App、订单页、客服说法互相矛盾，以行李小票 + 现场柜台答复为准

Step 3：生成“可执行”的转机行动卡

输出结构必须尽量接近下面格式：

CODEBLOCK1

然后继续输出下面几个模块。

模块 1：分步转机指引

必须用有序步骤，每一步包含：

• - 当前动作
• 跟随什么标识牌
• 预计用时
• 需要准备什么
• 如果走错最常见会错在哪里

示例格式：

CODEBLOCK2

模块 2：现场图片导航

普通转机模式下，尽量提供 2-4 张图片，优先级如下：

1. 1. 航站楼总图 / 楼层图
2. 航站楼摆渡车站点图 / 轨道交通换乘图
3. 值机区或安检入口示意图
4. 连接通道 / 卫星厅 / gate 区示意图

输出格式：

CODEBLOCK3

要求：

• - 优先贴“对当前下一步最有帮助”的图，而不是贴得多
• 每张图都要有“你要看什么”
• 如果只有 PDF 地图，没有直接图片 URL，就给地图链接并说明“当前未拿到可直接嵌入的图片”

模块 3：实时人流 / 排队情况

普通转机模式下，能抓到就加；抓不到就诚实说明。

输出格式：

CODEBLOCK4

如果没有官方实时数据，可用“代理判断”：

• - 低：用户落地/出发前后 60 分钟内，同航站楼国际到达/出发较少
• INLINECODE32：航班密度正常
• INLINECODE33：同一时间段密集到达或密集出发，且需经过入境/安检/摆渡

不要把代理判断写成“官方实时排队时间”。

模块 4：时间预算与 MCT

必须量化：

• - 各步骤预计耗时
• 总预计耗时
• 剩余缓冲
• 若能拿到 MCT，则同时展示 INLINECODE34

模块 5：行李是否需要重新托运

必须单独成段，不要只藏在某一步里。

输出格式：

CODEBLOCK5

必须提醒：

• - 国际航司系统同步可能滞后
• 非联程票即使工作人员口头说“可能能转”，也要以行李小票打印结果为准

模块 6：离线信息包

• - 航司客服电话
• 机场问讯处位置或联系方式
• 免费 Wi-Fi
• 关键柜台 / 帮助台位置
• 若用户第一次出国，再加“最容易走错的 3 个点”

Step 4：时间压力分层

Mode B：延误应急

当用户提到前序航班延误或提供 delay_minutes 时，切换到本模式。

Step 1：先做能否赶上的量化判断

至少比较下面几项：

• - 剩余中转时间 = 原中转时间 - 延误时间
• MCT（若可得）
• 实际预计需求 = 下机 + 转运 + 入境/安检 + 步行 + 登机截止

如果能拿到实时/近实时排队信息，也一起纳入判断。

Step 2：先输出结论，再给动作

赶得上

CODEBLOCK6

必须包含：

• - 让机组帮忙优先下机
• 直奔转机安检/转机柜台
• 跳过吃饭/购物/取现等非必要动作
• 如果行李状态不清楚，优先确认“人能不能登机”，再补查行李

大概率赶不上

CODEBLOCK7

若是联程票，优先说明航司改签责任；若是非联程票，明确说明风险更高。

Step 3：延误模式中的图片与拥挤度

• - 图片不是主角，只在“找转机柜台 / 找摆渡车 / 找值机区”非常关键时补 1-2 张
• 拥挤度优先展示最影响结果的环节：转机安检、入境审查、摆渡、值机柜台

机场覆盖范围

Tier 1：重点机场（注册表中有自定义 URL + 官方数据源，详见 {baseDir}/references/airport_registry.json）
NRT, HND, HKG, DXB, SIN, ICN, BKK, DOH, IST, KUL

Tier 2：较好覆盖
LHR, CDG, FRA, AMS, TPE, SYD, LAX, JFK, ORD

全球覆盖（通过第三方聚合站自动支持）
其他所有机场通过 airportguide.com（图片，375+ 机场）+ flightqueue.com（等待时间，8000+ 机场）自动覆盖，无需在注册表中手动添加，脚本自动构造 URL。

非注册机场仍然应尝试补充：

• - 机场官网地图 / 转机页面
• 航司 terminal guide
• 官方或第三方等待时间 / 航班密度代理信号

常见边界情况

与其他技能联动

• - 如果用户担心重新托运后的行李规则、超重、锂电池、液体限制，建议联动 flight-baggage-check
• 如果用户带老人、婴儿、轮椅需求，建议联动 family-travel-care