TRIP HACKATHON 2026 /入境游 AI 创新

第一次来中国,落地后该做什么?

机票和酒店已经订好,接下来还要确认手机能否上网、支付应用怎么用,以及如何从机场到酒店。Landing Check 希望把这些准备和操作放进 Trip.com,在游客需要时,告诉他接下来可以怎么做。

01聚焦落地第一小时
03上网 · 支付 · 到酒店
05知识库场景
FIRST HOUR, SORTED.可交互原型
行前准备检查界面
落地后的第一步联网界面
给司机看的中文酒店地址卡
准备在起飞前,指引在需要时。
为谁而做首次来华 · 自由行 · 主动做准备产品形态面向 Trip.com 的嵌入式功能设计当前:H5 + API 演示
01 / THE NEED

为什么做 Landing Check

在公开旅行社区里,我们看到一些游客已经查过攻略、装好应用,甚至完成了绑卡,却仍然担心到了中国不能付款。也有人在落地后才发现,自己不知道怎样完成买水这样简单的一笔消费。这些具体的提问让我们开始关注:游客做过准备之后,怎样才能在现场把工具用起来?

因此,我们把目标用户收窄为首次来华、能够自己安排机票和酒店的外国自由行游客。他们通常愿意做准备,需要的是知道自己的设备和账户适用哪种办法,以及出问题后还能怎么办。我们选择从起飞前到离开机场这一段开始,把上网、支付和去酒店的步骤放到同一个行程里。

这个选择也有边界。社区里的求助说明问题确实存在,但不能告诉我们有多少游客会遇到,也不能证明一套连续引导一定比攻略更好。“第一小时”只是我们用来控制产品范围的说法,实际是否能减少摸索,还需要让目标用户完成具体任务来比较。

02 / THE EXPERIENCE

产品怎么用

Landing Check 被设计为 Trip.com 内的一项功能。我们希望利用用户已有的航班和酒店信息,在起飞前提醒他确认准备情况,落地后再按当前需要给出联网、支付和交通指引。下面的 H5 原型展示了这条流程;点击不同阶段,可以查看具体页面和操作方式。

支付准备按一件事来检查

行前检查里,支付宝和 TenPayGo 放在同一个“境内支付”板块。用户选择一种方式完成小额测试后,这项任务就显示为已完成,另一种可以作为备用;如果测试失败,页面会解释对应错误,并提供切换方式的入口。当前测试使用模拟交易,正式使用前仍需确认支付渠道、退款和结果回调是否能够接入。

支付任务完成后,交通页还会检查具体方案需要什么。例如,支付宝里的滴滴不能通过 TenPayGo 叫车,所以只验证了 TenPayGo 时,页面会提醒用户准备支付宝,或者选择可以付现金的交通方式。我们希望这些条件直接出现在需要做决定的地方。

演示视频

约 57 秒 · 英文配音 · 中英字幕
LANDING CHECK / THE FIRST HOUR

跟随一位第一次来中国的旅客,看看 Landing Check 如何串起行前准备和落地后的几个步骤。

打开交互原型

当前在线原型包含支付宝与 TenPayGo,支付验证、航班与行程使用模拟数据。动画说明产品思路,具体操作以在线原型为准;正式 App 集成、真实扣款和自动推送尚未接入。界面截图保留原型中的英文。

03 / TECH STACK

技术栈

H5 前端承载任务和教程,Python 后端负责规则、识别与知识库。

前端与原型

HTML、CSS、JavaScript 构建交互界面。appearance.pen 经 pen.dev 导出,由 Python 脚本组装为 H5;后端不可用时可体验静态流程。

后端与规则

Python + FastAPI 提供接口,Uvicorn 运行服务,Pydantic 校验数据,HTTPX 调用模型。行前检查和交通推荐采用规则计算。

AI 场景识别

DeepSeek(deepseek-flash)匹配截图或文字中的问题,再从知识库读取步骤。不确定时提供候选,模型不可用时回退到关键词规则;库外建议标注为未经核验。

知识库与教程

JSON 维护 5 类场景、41 条记录,保存步骤、备用办法、来源和核验日期。Python 脚本校验内容并导出图文教程。

测试与部署

pytest + Playwright 检查接口和完整流程。GitHub Pages 托管展示页与 H5,Render 运行后端,模型密钥保留在服务端。

04 / OUR REFLECTIONS

我们的思考

  • 范围收窄,才能把流程做完整。 聚焦上网、支付和到酒店后,我们才把准备与现场操作接了起来。做取舍时,要先看游客当前要完成什么,以及现有办法还缺什么,避免功能越来越多,重点却越来越模糊。
  • 多一种选择,也要理清前后关系。 接入 TenPayGo 后,合并支付待办只是一步,还要检查交通方案能否衔接。这提醒我们,新增功能要沿着用户的操作走一遍,看看有没有把额外的判断和麻烦留给用户。
  • 用真实场景检验自己的判断。 真实截图暴露了攻略样本没呈现的问题。评测要多看错例,判断模糊时让用户确认;还要继续验证,给出的指引是否真的能帮人解决问题。
  • 指引要能照着做,也要持续更新。 整理知识库时,我们发现解释报错之后,还要写清按哪里、做不下去怎么办。内容积累以后,核对步骤是否仍适用,就和补充新条目一样重要。
  • 把失败后的路也设计好。 联调中的超时和重复操作提醒我们,等待多久、怎样重试、退出后怎么接着做,都需要提前想清楚。检查流程时,也要主动走一遍这些不顺利的情况。
05 / WHAT'S NEXT

接下来做什么

  • 真实用户测试。 请首次来华的游客完成联网、支付和到酒店的任务,比较原型与现有攻略,补充真实失败案例。
  • 知识库与多模态。 完善 I’m Stuck 的知识库,补充常见卡点、失败案例和解决步骤,并接入现场照片、语音等多模态能力,让游客更方便地描述问题。
  • 离线与多语言。 行前缓存联网指引、酒店地址和常用教程,预翻译并复核关键步骤,让弱网时也能查看。
  • 平台与支付接入。 确认 Trip.com 行程、航班通知和客服转接能力,以及真实支付、退款和结果回调。上述接入尚待确认,演示继续使用模拟数据。
LANDING CHECK / PROTOTYPE

打开原型,试走一遍落地流程

体验原型
RESEARCH / SOURCE