【外滩大会2026】飞猪 Travel-Itinerary · 把出行安排妥当的 AI 助手

[yinshubinysb-dotcom]

参赛项目名称

Travel-Itinerary

团队 / 作者

殷树斌、王馨祥、王威、张赞涓

我做了什么

我们做了一个 travel-itinerary Skill：不是一个"更会聊天"的出行助手，而是一个让 AI 生成的出行方案真的能走、能校验、能在风险点停住的执行型助手。

解决的问题：出行规划最容易出现"每一段单独看都对，串起来就走不通"。

• 早班机看起来赶得上，实际值机已停。

• 车次没错，但会议结束时间 + 晚高峰打车 + 高铁缓冲加起来还是赶不上。

• 带娃暑期三日游把迪士尼、崇明、外滩塞进同一天，走不动。

我们的做法：把系统拆成三层，能用规则解决的不让概率模型猜：

• LLM 负责识别意图、抽取槽位、把结构化方案说成人话；
• 规则 负责判断什么必须问、什么不能做、什么场景必须兜底（业务出差 / 旅游 / 暑期高峰 / 外卖等规则文件）；
• 脚本 负责查询真实数据、计算时间、生成链接、校验方案。

一条请求经过四轮流水线：R1 理解需求（init_all.py，槽位澄清）→ R2 并行查询（parallel_query.py，火车/航班/酒店/天气/POI）→ R3 组装方案（build_plan.py，门到门时间线、打车衔接、费用合计）→ R4 输出门禁（validate_itinerary.py，30+ 检查项，算不过就不输出）。

四个核心能力：

1. 门到门执行链路：不是查一张票，而是接驳 + 干线 + 尾程 + 缓冲的完整时间线。典型 case：苏州 18:40 散会，规则反推出最晚 18:33 必须离开会场才能赶上 19:53 的车——结论是"车次没错，但这个人赶不上"。
2. 时间缓冲是硬约束：机场提前 90 分钟、高铁站提前 30 分钟、落地取行李预留 60 分钟，全部写进自检脚本，不是文案提醒。
3. 交易前必须停住：只做到 dry-run / renderOrder，用户确认前不触发真实 createOrder，不自动支付；外卖有地址状态机（resolved / recommend_only / blocked），宁可不成事，不可乱下单。
4. 查不到就说查不到：数据源白名单，火车/航班/酒店/POI 必须来自脚本返回，查询失败保留失败原因，不让 LLM"合理推测"。

使用的工具

• OpenWork / 百炼 CLI
• 百炼能力 / 模型：意图识别、槽位抽取、多轮问答、方案表达生成（模型推理 + 文本生成）
• Skill 名称：travel-itinerary（Aone Skill 市场：yinshubin-ysb-travel-itinerary）
• 其他：
  -- 核心脚本：init_all.py（环境/偏好/场景识别）、parallel_query.py（并行查询）、build_plan.py（方案组装）、validate_itinerary.py（输出自检门禁）、execution_planner.py（订单草稿，默认 dry-run）
  -- 规则文件：business.md（出差反推）、tourism.md（POI 距离/每日上限）、peak_season.md（暑期/高温 B 计划）、waimai.md（地址状态机与交易门禁）
  -- 数据源：train-cli、FlyAI、高德坐标/导航

效果展示

演示视频：https://oss-ata.alibaba.com/articleVideo/2026/07/6898f9a4-517e-425a-837e-ebf0518c1cd3.mp4

项目链接（可选）

网页(打开后，需要登录淘宝)：https://aifliggys.m.taobao.com/ai-trip/fl-travel-itinerary
Aone Skill 市场：https://open.aone.alibaba-inc.com/skill/yinshubin-ysb-travel-itinerary?tab=skill-md
代码仓库：https://code.alibaba-inc.com/alitriptraffic/travel-itinerary

踩坑记录（可选）

1. 靠 prompt 写常识不稳定：一开始试图用更长的 prompt 让模型记住"高铁站提前 30 分钟""带娃每日景点上限"，模型会说、会推荐，但不会稳定地在方案里为你算。最终解法是把常识翻译成规则和脚本，接到输出门禁上——算不过就不输出。
2. LLM 会"合理推测"补数据：酒店查不到、POI 被风控时，模型倾向于编一个看起来完整的答案。解法是数据源白名单 + 保留真实失败原因，查不到就标"待确认"，绝不让 LLM 补。
3. 单点正确 ≠ 全局可行：车次、景点单独看都对，串起来就崩。解法是用脚本反推整条链路（会议结束时间 → 晚高峰打车 → 车站缓冲），把"能不能赶上"变成机械化计算而不是感觉。
4. 交易动作必须有刹车：最危险的不是说错话，而是替用户下错单。解法是 dry-run → renderOrder →用户确认的分级门禁 + 外卖地址状态机，地址不确定就降级为"只推荐，不下单"。