Google AI Mode 新增机票价格追踪与酒店预订功能之后旅行搜索正在从“用户自己翻列表比价”变成“由 AI 持续代管一段旅行决策”。这里的核心变化不是把航班和酒店列表换成一段聊天文字而是把一次性的查询目标拆成价格监控、条件筛选、预订跳转和后续通知多个环节并尽量在同一个对话上下文里完成。这篇文章会从产品逻辑、使用方式、参数边界、常见问题和工程启示几个角度把机票价格追踪与酒店预订这两块新增能力拆开讲清楚。对经常需要在多个日期、多个城市之间比价的旅客有价值对做搜索产品、旅行 Agent 或机票酒店比价工具的开发者也有参考意义。1. AI Mode 是什么为什么旅行场景适合它1.1 从“搜一次”到“聊一路”多轮对话改变搜索形态传统搜索里用户和搜索引擎之间是“一次请求、一次响应”的关系。搜“东京到京都新干线票价”得到一组结果页用户点开链接看完再回到搜索框输入下一个问题。如果要比三个日期、两家航司、两种中转方案就要重复多轮搜索并且自己把零散结果记在脑子里或表格里。AI Mode 的差别在于它保留对话上下文。用户可以在同一段对话里不断追加条件“加上 6 月 12 日出发的班次。”“只看上午飞、下午到的。”“如果价格超过 3000 元就不用提醒我。”这些条件各自是一条独立约束但合在一起以后就变成一组结构化需求。对旅行搜索来说这种交互方式比传统搜索框更接近人的真实决策过程我们不是一次性知道自己要什么而是边看边调整。从产品形态上看AI Mode 相当于把“搜索引擎”和“个人旅行助手”放在同一个入口。它既能像搜索引擎那样提供候选结果也能像助手那样记住用户说过的日期、预算和偏好。1.2 旅行搜索的信息密度远高于普通关键词搜索旅行决策不是一个简单的关键词匹配问题。用户判断一个航班或酒店是否值得选择时通常同时在看多组信息信息维度航班例子酒店例子时间约束出发日期、起飞时段、总时长入住日期、退房日期、住宿天数价格约束含税总价、退改费用、行李费用每晚房价、税费、清洁费空间约束出发机场、到达机场、中转地地理位置、距景点或会议场馆距离条件约束直飞或转机、舱位等级取消政策、免费早餐、停车评价约束航司准点率、退改体验用户评分、设施评分、差评分布普通关键词搜索适合回答“有哪些航班”但很难回答“哪个航班最符合我这一堆条件”。AI Mode 的真正价值在于把自然语言变成条件组合再把这组条件用于筛选、推荐和后续跟踪。1.3 核心价值把“查资料”变成“做安排”机票价格追踪和酒店预订两个功能的共同点是“行动闭环”。只提供搜索结果时产品对用户负责的终点是“内容展示是否准确”。提供价格追踪时产品还要负责“价格变化是否被及时感知”。提供酒店预订时产品还要负责“交易是否顺利闭环”。所以 AI Mode 在旅行方向上的核心能力不是“更会聊天”而是能理解一段包含多个条件的旅行需求。能把需求拆成结构化的规则。能在时间维度上持续执行规则。能在用户决定后把结果导向可操作的交易或提醒。对开发者的启示是AI 搜索产品评估质量的指标不能只看回答相关性还要看任务完成率。用户建立追踪规则之后有没有收到有效通知用户完成预订之后有没有拿到明确确认这些才是行动闭环里真正重要的指标。2. 机票价格追踪功能用户如何建立一条“盯价规则”2.1 不是所有航班搜索都会出现追踪入口机票价格追踪功能并不会在每次航班搜索时都出现。产品通常需要识别出用户有“持续关注价格”的意图才提供追踪入口。常见触发方式有几种用户直接表达“帮我盯一下”“降价提醒”“跟踪这趟航班”。搜索结果页出现“开启价格提醒”之类的按钮。用户在一段对话里反复查询同一航线系统推断其有持续比较需求。实际产品实现中前两种方式最可靠第三种有误判风险。如果用户只是临时比较两个航班系统弹出一个“是否追踪”的引导会增加干扰。比较好的设计是在用户明确表达追踪意图时才进入规则收集流程。这里有一个容易误解的地方追踪不等于立即预订。用户建立追踪规则只代表系统到了某个价格条件时通知用户不代表系统会自动下单。对大多数用户来说这种“半托管”状态更符合心理预期既保留人做最终决策的权利又减少反复手查的负担。2.2 从设置规则到收到通知一条完整链路一次机票价格追踪的完整链路可以拆成六段用户表达追踪意图 - 系统补齐航线、日期、舱位、预算等参数 - 转换为结构化追踪规则并存储 - 按更新频率拉取多个报价源 - 价格满足条件或发生明显变化 - 通过应用、邮件或系统通知触达用户这六段里最容易出问题的是“结构化追踪规则”和“拉取报价源”两段。自然语言里容易漏参数。用户说“帮我看看下个月去大阪的机票”系统需要确认“下个月”的具体日期、“去”是单程还是往返、出发城市是否沿用上一轮对话里的地点。很多“忘记追踪”的问题根源都在参数没有补齐时系统就急着创建了规则。报价源决定价格真实性。系统不可能只依赖一个数据源否则就会出现“系统让我盯着价格但价格永远来自同一家代理”的偏差。合理做法是同时比较航司官网报价和多个分销渠道至少让用户在通知里看到报价来自哪里。2.3 需要确认的关键参数用户在 AI Mode 里建立价格追踪规则时真正重要的不是记住每个操作的路径而是知道自己需要提供哪些参数。参数含义常见选项没有设置时的默认行为出发地航班从哪里起飞城市或机场代码使用用户定位或上一轮对话中的地点目的地航班飞往哪里城市或机场代码必须明确否则无法追踪单程/往返行程方向单程、往返默认往返容易误判出发日期目标航班日期具体日期或日期范围若只有“下个月”需要二次确认回程日期往返行程返程日期具体日期或日期范围单程时忽略舱位等级机票舱位经济舱、高端经济舱、公务舱默认经济舱转机次数允许几次中转直飞、一次转机、不限默认不限价格阈值低于多少钱才通知具体金额可能改为“降价时通知”通知方式结果如何触达应用推送、邮件、系统通知使用账号绑定的通知渠道币种价格比较基准人民币、美元、日元等使用用户常用币种“往返”“经济舱”“不限转机”这几个默认值最需要确认。用户说“帮我盯一下上海到首尔的机票”如果系统默默按往返、经济舱、不限转机去建规则第二周用户可能收到一条“价格下降”通知点开才发现是凌晨中转航班。2.4 用自然语言建立一条最小追踪规则下面示例只用于说明交互思路不代表 Google AI Mode 的官方返回结果。用户在一段对话里输入帮我盯一下6 月 10 日从首尔飞东京6 月 14 日返回经济舱允许一次转机总价超过 2800 元就不用通知我。系统在理解并补齐参数后背后的规则结构大体是{ tracking_rule: { origin: ICN, destination: HND, trip_type: round_trip, outbound_date: 2026-06-10, return_date: 2026-06-14, cabin_class: economy, max_stops: 1, price_threshold: 2800, currency: CNY, notify_channel: email } }这个结构看起来简单但它决定了整个追踪系统的行为边界。如果用户后续说“回程改到 6 月 15 日”系统只需要更新return_date字段如果用户说“直飞也可以”系统要把max_stops改为 0 并重新拉取报价如果用户说“公务舱也可以接受”系统就要在cabin_class里支持多值。实际项目里这种规则结构还要补充rule_id、created_at、user_id和source字段否则无法做去重、过期和审计。默认情况下建议给追踪规则加一个有效期避免用户已经飞完了系统还在推送“价格下降”。3. 酒店预订功能AI 怎么从推荐走到下单3.1 AI Mode 推荐酒店时通常会围绕哪几组约束展开酒店预订和机票追踪的最大区别是机票追踪的终点是“通知”酒店预订的终点是“交易”。交易会带来身份信息、支付方式、取消政策、确认号和售后责任因此 AI Mode 在酒店场景里的输出必须比机票场景更谨慎。推荐酒店时产品通常围绕四组约束展开第一组是时间和人数。入住日期、退房日期、房间数量和入住人数量决定了可订库存。同一家酒店6 月淡季和展会期间的价格可能差出数倍AI 必须先把这些基础参数确认好。第二组是位置和出行目的。是去旅游、出差、还是赶早班机偏好不同推荐逻辑完全不同。旅游看重景点步行距离出差看重交通和会议室赶早班机则应该优先推荐机场附近。第三组是价格和政策。每晚预算、是否预付、能否免费取消。用户说“帮我订一家可以免费取消的酒店”比说“帮我订一家便宜酒店”更容易推荐出符合预期的结果。第四组是评价和设施。评分、早餐、停车、健身房、儿童设施、宠物友好等。这些不是所有用户都关心但 AI 应该能在用户提到时正确过滤。3.2 一条典型酒店预订对话用户在 AI Mode 里发起的需求可能是帮我找 6 月 15 日到 6 月 18 日住东京站附近、评分 8.5 分以上的酒店需要有免费取消预算每晚不超过 900 元。这条需求包含了五组明确条件日期6 月 15 日入住6 月 18 日退房。地点东京站附近。评分8.5 分以上。政策免费取消。预算每晚不超过 900 元。AI Mode 要做的不是立刻给出酒店名称而是先确认这些条件是否互斥。比如“东京站附近”和“每晚 900 元以内”可能能过滤掉一半酒店而“评分 8.5 分以上”和“免费取消”可能让候选数量进一步缩小。如果条件组合后没有结果系统应该主动提示放宽某个条件而不是假装有结果。这个环节最容易踩的坑是用户没有意识到“免费取消”通常比“不可取消”价格更高。AI 推荐时应该把价格差异说清楚而不是只强调免费取消的好处。3.3 从对话到交易预订链路的数据闭环酒店预订功能如果只是“推荐完让用户打开 OTA 自己订”那它只是换了一种展示形态的搜索列表。真正的预订功能需要让用户能在对话流程里完成操作或在提示后进入一个参数已填好的预订页面。完整链路如下用户提出酒店需求 - 系统基于位置、日期、政策、预算筛选库存 - 展示候选酒店并说明推荐理由 - 用户选择具体房型 - 确认入住人、联系方式和支付信息 - 生成订单并返回确认号 - 后续通知订单状态或取消结果商品消费者最关心的其实是最后一步确认号。没有确认号的“预订成功”是不可接受的。无论系统在中间使用了多少 AI 能力用户看到“预订成功”时都应该拿到酒店方或平台方承认的订单号并能在后续改期或取消时引用。从实现角度看这里涉及至少三套系统的配合对话系统负责理解需求并展示结果。库存与价格系统负责返回真实可订的酒店和房型。订单系统负责生成订单、保存支付信息、返回确认号。三个系统之间必须共用一个订单状态机。对话系统说“已下单”订单系统里就必须有对应的booked状态。如果两个系统的状态对不上排错成本会非常高。3.4 与“搜索结果列表”在能力边界上的差异搜索结果列表的酒店预订本质是“展示 跳转”。AI Mode 的酒店预订至少应该是“对话筛选 参数传递 订单确认”。能力传统搜索结果列表AI Mode 酒店预订方向筛选方式用户手动加筛选器对话里用自然语言追加条件条件记忆每次筛选重新设置同一次对话内持续生效预订跳转用户自己打开 OTA系统可携带日期、房型参数跳转订单闭环通常回到 OTA 完成需确认号或跳转到可查订单的页面异常处理用户自己联系客服需要提供订单查询和取消入口这里要注意不要因为 AI 能推荐酒店就认为 AI 承担了全部售后责任。实际产品中AI 只是帮用户更快找到合适选项并完成下单用户和酒店之间的履约条款仍然由订单所属的平台或酒店方负责。这也是为什么 AI 输出里需要写明价格、退改规则和供应商来源。4. 使用前先确认这几点可用性、权限与价格口径4.1 功能可用区域和账号环境机票价格追踪和酒店预订功能属于 AI Mode 的新增能力通常不是所有地区、所有账号、所有语言下同时可用。搜索产品上线新功能时普遍采用分批开放策略先在小范围用户里验证再逐步扩大。所以第一次使用前建议先确认三件事当前账号是否在功能灰度范围内。谷歌应用或浏览器是否已更新到支持 AI Mode 的版本。当前区域的语言界面是否显示追踪或预订入口。如果看不到入口不一定代表功能失效更可能是还没有开放到这个账号。这时不要马上认为账号有问题换成更通用的查询词或查看官方更新说明通常能得到更准确的信息。4.2 通知渠道和权限影响体验机票价格追踪的核心体验是“通知准确到达”。价格确实降了但通知没有发出去这个功能就等于没有做。用户在创建追踪规则前应确认系统推送权限已经打开。邮件通知相对稳定但存在延迟应用推送速度最快但需要接受通知权限弹窗。如果用户同时打开多个通知渠道还要注意会出现一条价格变动触发多次通知的情况。实际使用中比较稳妥的方式是应用推送作为主渠道邮件作为备份渠道。系统只发送一次推送邮件延迟十几分钟也问题不大。如果两个渠道同时投递用户大概率会认为消息重复而不是觉得系统更可靠。4.3 价格比较要看口径币种、含税与行李机票和酒店价格从不同入口看到完全不同的金额是旅行搜索最常见的困惑原因几乎总是口径不一致。机票价格至少要区分含税价还是裸价。包含行李额还是不含。单程价还是往返价。人民币报价还是日元、美元等外币报价。酒店价格至少要区分每晚房价是否含税费和服务费。是否含早餐。是否含清洁费。是否预付退订时扣除多少。AI Mode 在展示价格时最好能明确写出“含税总价”“不含行李”“每晚含税价”等口径。用户在比较不同平台价格时也应当先统一口径再判断哪个更便宜。很多“AI 推荐的价格和官网不一致”的问题根因不在 AI而在比较基准不同。4.4 隐私与数据使用边界使用 AI Mode 管理旅行计划意味着旅行日期、目的地、预算范围、甚至住宿偏好都会被对话系统记录。这是该功能的便利基础也是隐私边界所在。用户在输入敏感信息前要有基本判断不要直接输入护照号、身份证号、银行卡号等敏感信息。支付环节应当跳转到受信任的预订页面完成而不是在对话里发送完整卡号。确认取消、退款、投诉纠纷时应联系订单所属平台或酒店方而不是继续依赖 AI 回复。产品的做法应当是默认不过度收集信息能完成任务时只保留必要参数。开发者在实现这类功能时也要把用户输入信息的最小化和存储时限纳入设计不能因为 AI 能理解自然语言就默认允许它接收并保存一切个人信息。5. 典型使用场景与功能边界什么值得用什么不能依赖5.1 适合 AI Mode 的旅行决策AI Mode 最适合的场景有几个共同点条件多、计划性强、结果可比较、用户希望减少重复操作。典型场景包括多日期比价。用户可以把五个不同出发日期的要求一次性告诉 AI让它分别计算并汇总。多城市行程。用户要比较“先到东京再去大阪”和“直接住大阪”哪个更划算。长期盯价。距离出行还有两个月用户希望价格下跌时得到提醒。复杂政策筛选。用户明确指出“可以免费取消”“评分 8.5 以上”“每晚不超过 900 元”。这些场景里AI 的价值不是替代用户判断而是帮用户节省“反复查询和整理条件”的时间。用户的最终决策权仍然被保留系统只是把信息整理得更适合决策。5.2 不适合的用法和原因有几类旅行场景不适合依赖 AI Mode原因是它们的需求过于依赖实时状态和人工沟通。短暂且紧急的行程不适合。比如飞机两小时后起飞需要立刻改签用户应该直接打开航司应用或联系客服。AI Mode 的回答速度再快在紧急场景里也多了一层不确定。政策极其特殊的航班不适合。某些特价机票的退改规则非常复杂可能涉及代金券、积分、旅行社代理二次确认。AI 很难在对话里完整处理这类规则强行自动化反而会带来风险。小语种地区的异常情况不适合。偏远地区的酒店可能没有稳定的在线库存接口AI 返回的信息可能不是最新状态。遇到酒店客满、临时维修、押金规则不明时人工确认仍是必要补充。5.3 面向实际用户的三条使用建议给真实用户的三条建议可以直接用于日常操作第一把条件一次说完整。出发地、目的地、日期、预算、舱位、转机次数能一次提供就不要拆成十次追问。条件越完整AI 生成的追踪规则越接近预期。第二创建规则后检查一遍关键参数。系统返回“已为您盯住以下航班”时不要直接关掉。看一眼日期、币种、价格阈值和通知渠道发现问题当场修改比等通知出错再排查容易得多。第三预订流程中只把对话当成“筛选器”把支付当成“关键节点”。筛选和推荐可以交给 AI支付、确认号和退改操作一定要回到正式订单页面并保存订单截图或确认邮件。6. 常见问题与排查路径6.1 提示没有出现追踪入口现象用户搜索航班但没有看到任何价格追踪按钮AI Mode 也没有主动询问是否需要盯价。可能原因当前账号不在功能灰度范围内。应用或浏览器版本过旧。查询词本身是具体航班号而不是可追踪的航线查询。当前区域暂未开放该能力。检查方式先换一条简单查询例如“上海到东京的机票”看是否出现追踪入口。再检查应用版本和账号设置。处理建议如果排查后仍无入口直接回到普通搜索列表使用传统价格提醒功能不要反复用不同措辞触发 AI Mode避免把“功能未开放”误判成“搜索理解能力不足”。6.2 价格通知没有按时到达现象用户创建了追踪规则系统也提示追踪成功但价格下降后没有收到任何通知。可能原因通知权限没有打开。设置的是邮件通知但邮箱填错或邮件进入垃圾箱。系统判定价格变化未达到通知阈值。报价源没有更新系统拉取到的价格仍然是旧值。检查方式先查看追踪规则里的通知渠道和阈值再检查邮件垃圾箱和应用通知设置。如果规则、权限都正常最后判断这个价格是否存在可以用航司官网或 OTA 手动查一次。处理建议通知类产品建议做“规则状态可见”设计。用户打开追踪页面后能看到“最近一次价格检查时间”和“上次通知时间”这样问题出在哪一段链路会更容易定位。6.3 预订流程在跳转后中断现象AI Mode 推荐了酒店用户点击预订后跳转到外部页面但页面没有自动带入入住日期和房型甚至出现“无房”提示。可能原因对话中确认的日期没有正确传递给预订页面。库存不是实时的AI 推荐时显示有房用户点击时已被预订。外部页面需要登录登录后未保留跳转参数。检查方式回到对话记录里确认系统展示的“入住日期”和“退房日期”是否与用户输入一致。再确认跳转页面里的日期参数是否带过来。处理建议最稳妥的方案是让跳转页面保留完整参数用户只需要登录和支付。任何一个环节丢失参数都会让用户觉得是系统“乱跳转”。对于库存不一致问题AI 推荐结果里应增加“该价格更新于 xx 分钟前”的提示。6.4 价格结果与航司官网不一致现象AI Mode 显示的价格比航司官网便宜很多或贵很多。可能原因报价源是 OTA和航司官网是不同渠道。显示价格未含税或未含行李费。比较的是不同舱位等级。报价源存在缓存更新不及时。检查方式把价格口径列出来对比看是否是含税总价、是否包含同样行李额、是否同一舱位。再点击报价详情查看来源确认是哪家在卖。处理建议看到低价时要多看一眼来源。正常渠道里某个来源突然便宜 30% 以上大概率是价格展示口径不同或者库存剩余极少。不要只看数字要看计价规则。问题现象可能原因检查方式处理建议无追踪入口灰度未开放、版本过旧换通用查询词、检查版本回退到普通提醒功能通知未到达权限、邮箱、阈值检查设置和垃圾箱增加规则状态与最近检查时间预订跳转中断参数丢失、库存过期核对日期参数、来源跳转页保留完整参数价格不一致渠道不同、口径不同对比含税与来源以航司官网确认为准7. 对旅行工具开发者的启示与落地清单7.1 真正产生价值的是“从回答到行动”的闭环做 AI 旅行工具的开发者容易陷入“把回答做得很漂亮”的误区。AI 能列出十个航班、五个酒店看起来理解能力很强但用户还是没有完成预订仍然需要自己打电话、自己开 OTA、自己重新填写日期。从产品角度衡量AI Mode 机票追踪和酒店预订的价值不在于它能回答得有多像人而在于它能不能减少用户从“得到答案”到“完成行动”之间的步骤用户说“帮我盯价”系统是否真的在后端按规则检查了。用户说“帮我订酒店”系统是否能生成有效订单。用户改变条件系统是否能在一句话之后更新整条规则。这些问题才是产品闭环的硬指标。7.2 意图解析在实现层面对应的最小数据结构如果把追踪功能落到工程实现至少需要一个数据类来保存用户规则。下面的示例用于说明思路不是官方实现from dataclasses import dataclass, field from typing import Optional, List dataclass class PriceTrackRule: rule_id: str user_id: str origin: str destination: str trip_type: str # oneway / round_trip outbound_date: str return_date: Optional[str] None cabin_class: List[str] field(default_factorylambda: [economy]) max_stops: int 2 price_threshold: float 0 currency: str CNY notify_channel: List[str] field(default_factorylambda: [email]) enabled: bool True created_at: str updated_at: str def should_notify(rule: PriceTrackRule, current_price: float) - bool: if not rule.enabled: return False if rule.price_threshold 0: return True return current_price rule.price_threshold这个结构说明三个工程判断cabin_class和notify_channel使用列表因为用户可能同时接受经济舱和公务舱也可能同时要邮件和应用通知。return_date使用可选类型因为用户可能只追踪单程。should_notify独立成函数便于后续加入“最近已通知时间”“价格降幅比例”等更细的触发条件。生产环境里这个类还要加上版本号、数据源来源、通知去重键和过期时间字段。规则结构越清晰后续扩展越容易。7.3 AI 输出必须可解释、可回退、可追踪AI 旅行功能有很强的用户信任问题。用户不确定“这个价格哪来的”“这个推荐为什么符合我的条件”“这个订单到底订上没有”任何一环不透明都会导致用户流失。所以在工程落地时至少要做到每个推荐结果都有来源标识用户能知道价格来自航司官网还是 OTA。每个关键结论都有条件说明例如“因为您要求免费取消所以推荐这家”。每条追踪规则都能被用户手动关闭不能让用户进入“想停又停不了”的状态。每个订单都有可查询状态用户至少能看到“预订中”“已确认”“已取消”之一。可解释性不是上线后补的功能而是在设计数据结构时就要保证每个字段都能追溯到一次用户操作或一个上游系统。7.4 项目落地前的检查清单把 AI 旅行功能从演示 Demo 推向真实环境前建议按下面的清单逐项确认自然语言生成的追踪规则是否会在创建前让用户确认关键参数。价格追踪是否设置了有效期用户出行后是否自动停止。通知是否去重是否重复发送同一条价格变化。推荐结果是否标注来源和更新时间。预订跳转参数是否完整是否经过未登录场景测试。订单状态能否统一查询确认号是否在界面上可见。支付和个人敏感信息是否在受信任页面完成不在对话中传输。用户关闭追踪或取消订单后相关数据是否按策略保留或删除。每个关键环节是否有日志记录用于回放用户操作链路。是否在高价或低价两端都做过提醒测试避免只验证正常路径。实际项目里最值得优先做的是规则确认和状态可见。规则确认能减少用户被误导的可能状态可见能减少用户问客服的比例。AI 旅行产品刚上线时用户不是在等一个最聪明的回答而是在等一个能放心完成预订的流程。先把流程闭环做好再把回答质量提上去迭代顺序不要反过来。
AI Mode新增机票价格追踪与酒店预订，旅行搜索迈向行动闭环
Google AI Mode 新增机票价格追踪与酒店预订功能之后旅行搜索正在从“用户自己翻列表比价”变成“由 AI 持续代管一段旅行决策”。这里的核心变化不是把航班和酒店列表换成一段聊天文字而是把一次性的查询目标拆成价格监控、条件筛选、预订跳转和后续通知多个环节并尽量在同一个对话上下文里完成。这篇文章会从产品逻辑、使用方式、参数边界、常见问题和工程启示几个角度把机票价格追踪与酒店预订这两块新增能力拆开讲清楚。对经常需要在多个日期、多个城市之间比价的旅客有价值对做搜索产品、旅行 Agent 或机票酒店比价工具的开发者也有参考意义。1. AI Mode 是什么为什么旅行场景适合它1.1 从“搜一次”到“聊一路”多轮对话改变搜索形态传统搜索里用户和搜索引擎之间是“一次请求、一次响应”的关系。搜“东京到京都新干线票价”得到一组结果页用户点开链接看完再回到搜索框输入下一个问题。如果要比三个日期、两家航司、两种中转方案就要重复多轮搜索并且自己把零散结果记在脑子里或表格里。AI Mode 的差别在于它保留对话上下文。用户可以在同一段对话里不断追加条件“加上 6 月 12 日出发的班次。”“只看上午飞、下午到的。”“如果价格超过 3000 元就不用提醒我。”这些条件各自是一条独立约束但合在一起以后就变成一组结构化需求。对旅行搜索来说这种交互方式比传统搜索框更接近人的真实决策过程我们不是一次性知道自己要什么而是边看边调整。从产品形态上看AI Mode 相当于把“搜索引擎”和“个人旅行助手”放在同一个入口。它既能像搜索引擎那样提供候选结果也能像助手那样记住用户说过的日期、预算和偏好。1.2 旅行搜索的信息密度远高于普通关键词搜索旅行决策不是一个简单的关键词匹配问题。用户判断一个航班或酒店是否值得选择时通常同时在看多组信息信息维度航班例子酒店例子时间约束出发日期、起飞时段、总时长入住日期、退房日期、住宿天数价格约束含税总价、退改费用、行李费用每晚房价、税费、清洁费空间约束出发机场、到达机场、中转地地理位置、距景点或会议场馆距离条件约束直飞或转机、舱位等级取消政策、免费早餐、停车评价约束航司准点率、退改体验用户评分、设施评分、差评分布普通关键词搜索适合回答“有哪些航班”但很难回答“哪个航班最符合我这一堆条件”。AI Mode 的真正价值在于把自然语言变成条件组合再把这组条件用于筛选、推荐和后续跟踪。1.3 核心价值把“查资料”变成“做安排”机票价格追踪和酒店预订两个功能的共同点是“行动闭环”。只提供搜索结果时产品对用户负责的终点是“内容展示是否准确”。提供价格追踪时产品还要负责“价格变化是否被及时感知”。提供酒店预订时产品还要负责“交易是否顺利闭环”。所以 AI Mode 在旅行方向上的核心能力不是“更会聊天”而是能理解一段包含多个条件的旅行需求。能把需求拆成结构化的规则。能在时间维度上持续执行规则。能在用户决定后把结果导向可操作的交易或提醒。对开发者的启示是AI 搜索产品评估质量的指标不能只看回答相关性还要看任务完成率。用户建立追踪规则之后有没有收到有效通知用户完成预订之后有没有拿到明确确认这些才是行动闭环里真正重要的指标。2. 机票价格追踪功能用户如何建立一条“盯价规则”2.1 不是所有航班搜索都会出现追踪入口机票价格追踪功能并不会在每次航班搜索时都出现。产品通常需要识别出用户有“持续关注价格”的意图才提供追踪入口。常见触发方式有几种用户直接表达“帮我盯一下”“降价提醒”“跟踪这趟航班”。搜索结果页出现“开启价格提醒”之类的按钮。用户在一段对话里反复查询同一航线系统推断其有持续比较需求。实际产品实现中前两种方式最可靠第三种有误判风险。如果用户只是临时比较两个航班系统弹出一个“是否追踪”的引导会增加干扰。比较好的设计是在用户明确表达追踪意图时才进入规则收集流程。这里有一个容易误解的地方追踪不等于立即预订。用户建立追踪规则只代表系统到了某个价格条件时通知用户不代表系统会自动下单。对大多数用户来说这种“半托管”状态更符合心理预期既保留人做最终决策的权利又减少反复手查的负担。2.2 从设置规则到收到通知一条完整链路一次机票价格追踪的完整链路可以拆成六段用户表达追踪意图 - 系统补齐航线、日期、舱位、预算等参数 - 转换为结构化追踪规则并存储 - 按更新频率拉取多个报价源 - 价格满足条件或发生明显变化 - 通过应用、邮件或系统通知触达用户这六段里最容易出问题的是“结构化追踪规则”和“拉取报价源”两段。自然语言里容易漏参数。用户说“帮我看看下个月去大阪的机票”系统需要确认“下个月”的具体日期、“去”是单程还是往返、出发城市是否沿用上一轮对话里的地点。很多“忘记追踪”的问题根源都在参数没有补齐时系统就急着创建了规则。报价源决定价格真实性。系统不可能只依赖一个数据源否则就会出现“系统让我盯着价格但价格永远来自同一家代理”的偏差。合理做法是同时比较航司官网报价和多个分销渠道至少让用户在通知里看到报价来自哪里。2.3 需要确认的关键参数用户在 AI Mode 里建立价格追踪规则时真正重要的不是记住每个操作的路径而是知道自己需要提供哪些参数。参数含义常见选项没有设置时的默认行为出发地航班从哪里起飞城市或机场代码使用用户定位或上一轮对话中的地点目的地航班飞往哪里城市或机场代码必须明确否则无法追踪单程/往返行程方向单程、往返默认往返容易误判出发日期目标航班日期具体日期或日期范围若只有“下个月”需要二次确认回程日期往返行程返程日期具体日期或日期范围单程时忽略舱位等级机票舱位经济舱、高端经济舱、公务舱默认经济舱转机次数允许几次中转直飞、一次转机、不限默认不限价格阈值低于多少钱才通知具体金额可能改为“降价时通知”通知方式结果如何触达应用推送、邮件、系统通知使用账号绑定的通知渠道币种价格比较基准人民币、美元、日元等使用用户常用币种“往返”“经济舱”“不限转机”这几个默认值最需要确认。用户说“帮我盯一下上海到首尔的机票”如果系统默默按往返、经济舱、不限转机去建规则第二周用户可能收到一条“价格下降”通知点开才发现是凌晨中转航班。2.4 用自然语言建立一条最小追踪规则下面示例只用于说明交互思路不代表 Google AI Mode 的官方返回结果。用户在一段对话里输入帮我盯一下6 月 10 日从首尔飞东京6 月 14 日返回经济舱允许一次转机总价超过 2800 元就不用通知我。系统在理解并补齐参数后背后的规则结构大体是{ tracking_rule: { origin: ICN, destination: HND, trip_type: round_trip, outbound_date: 2026-06-10, return_date: 2026-06-14, cabin_class: economy, max_stops: 1, price_threshold: 2800, currency: CNY, notify_channel: email } }这个结构看起来简单但它决定了整个追踪系统的行为边界。如果用户后续说“回程改到 6 月 15 日”系统只需要更新return_date字段如果用户说“直飞也可以”系统要把max_stops改为 0 并重新拉取报价如果用户说“公务舱也可以接受”系统就要在cabin_class里支持多值。实际项目里这种规则结构还要补充rule_id、created_at、user_id和source字段否则无法做去重、过期和审计。默认情况下建议给追踪规则加一个有效期避免用户已经飞完了系统还在推送“价格下降”。3. 酒店预订功能AI 怎么从推荐走到下单3.1 AI Mode 推荐酒店时通常会围绕哪几组约束展开酒店预订和机票追踪的最大区别是机票追踪的终点是“通知”酒店预订的终点是“交易”。交易会带来身份信息、支付方式、取消政策、确认号和售后责任因此 AI Mode 在酒店场景里的输出必须比机票场景更谨慎。推荐酒店时产品通常围绕四组约束展开第一组是时间和人数。入住日期、退房日期、房间数量和入住人数量决定了可订库存。同一家酒店6 月淡季和展会期间的价格可能差出数倍AI 必须先把这些基础参数确认好。第二组是位置和出行目的。是去旅游、出差、还是赶早班机偏好不同推荐逻辑完全不同。旅游看重景点步行距离出差看重交通和会议室赶早班机则应该优先推荐机场附近。第三组是价格和政策。每晚预算、是否预付、能否免费取消。用户说“帮我订一家可以免费取消的酒店”比说“帮我订一家便宜酒店”更容易推荐出符合预期的结果。第四组是评价和设施。评分、早餐、停车、健身房、儿童设施、宠物友好等。这些不是所有用户都关心但 AI 应该能在用户提到时正确过滤。3.2 一条典型酒店预订对话用户在 AI Mode 里发起的需求可能是帮我找 6 月 15 日到 6 月 18 日住东京站附近、评分 8.5 分以上的酒店需要有免费取消预算每晚不超过 900 元。这条需求包含了五组明确条件日期6 月 15 日入住6 月 18 日退房。地点东京站附近。评分8.5 分以上。政策免费取消。预算每晚不超过 900 元。AI Mode 要做的不是立刻给出酒店名称而是先确认这些条件是否互斥。比如“东京站附近”和“每晚 900 元以内”可能能过滤掉一半酒店而“评分 8.5 分以上”和“免费取消”可能让候选数量进一步缩小。如果条件组合后没有结果系统应该主动提示放宽某个条件而不是假装有结果。这个环节最容易踩的坑是用户没有意识到“免费取消”通常比“不可取消”价格更高。AI 推荐时应该把价格差异说清楚而不是只强调免费取消的好处。3.3 从对话到交易预订链路的数据闭环酒店预订功能如果只是“推荐完让用户打开 OTA 自己订”那它只是换了一种展示形态的搜索列表。真正的预订功能需要让用户能在对话流程里完成操作或在提示后进入一个参数已填好的预订页面。完整链路如下用户提出酒店需求 - 系统基于位置、日期、政策、预算筛选库存 - 展示候选酒店并说明推荐理由 - 用户选择具体房型 - 确认入住人、联系方式和支付信息 - 生成订单并返回确认号 - 后续通知订单状态或取消结果商品消费者最关心的其实是最后一步确认号。没有确认号的“预订成功”是不可接受的。无论系统在中间使用了多少 AI 能力用户看到“预订成功”时都应该拿到酒店方或平台方承认的订单号并能在后续改期或取消时引用。从实现角度看这里涉及至少三套系统的配合对话系统负责理解需求并展示结果。库存与价格系统负责返回真实可订的酒店和房型。订单系统负责生成订单、保存支付信息、返回确认号。三个系统之间必须共用一个订单状态机。对话系统说“已下单”订单系统里就必须有对应的booked状态。如果两个系统的状态对不上排错成本会非常高。3.4 与“搜索结果列表”在能力边界上的差异搜索结果列表的酒店预订本质是“展示 跳转”。AI Mode 的酒店预订至少应该是“对话筛选 参数传递 订单确认”。能力传统搜索结果列表AI Mode 酒店预订方向筛选方式用户手动加筛选器对话里用自然语言追加条件条件记忆每次筛选重新设置同一次对话内持续生效预订跳转用户自己打开 OTA系统可携带日期、房型参数跳转订单闭环通常回到 OTA 完成需确认号或跳转到可查订单的页面异常处理用户自己联系客服需要提供订单查询和取消入口这里要注意不要因为 AI 能推荐酒店就认为 AI 承担了全部售后责任。实际产品中AI 只是帮用户更快找到合适选项并完成下单用户和酒店之间的履约条款仍然由订单所属的平台或酒店方负责。这也是为什么 AI 输出里需要写明价格、退改规则和供应商来源。4. 使用前先确认这几点可用性、权限与价格口径4.1 功能可用区域和账号环境机票价格追踪和酒店预订功能属于 AI Mode 的新增能力通常不是所有地区、所有账号、所有语言下同时可用。搜索产品上线新功能时普遍采用分批开放策略先在小范围用户里验证再逐步扩大。所以第一次使用前建议先确认三件事当前账号是否在功能灰度范围内。谷歌应用或浏览器是否已更新到支持 AI Mode 的版本。当前区域的语言界面是否显示追踪或预订入口。如果看不到入口不一定代表功能失效更可能是还没有开放到这个账号。这时不要马上认为账号有问题换成更通用的查询词或查看官方更新说明通常能得到更准确的信息。4.2 通知渠道和权限影响体验机票价格追踪的核心体验是“通知准确到达”。价格确实降了但通知没有发出去这个功能就等于没有做。用户在创建追踪规则前应确认系统推送权限已经打开。邮件通知相对稳定但存在延迟应用推送速度最快但需要接受通知权限弹窗。如果用户同时打开多个通知渠道还要注意会出现一条价格变动触发多次通知的情况。实际使用中比较稳妥的方式是应用推送作为主渠道邮件作为备份渠道。系统只发送一次推送邮件延迟十几分钟也问题不大。如果两个渠道同时投递用户大概率会认为消息重复而不是觉得系统更可靠。4.3 价格比较要看口径币种、含税与行李机票和酒店价格从不同入口看到完全不同的金额是旅行搜索最常见的困惑原因几乎总是口径不一致。机票价格至少要区分含税价还是裸价。包含行李额还是不含。单程价还是往返价。人民币报价还是日元、美元等外币报价。酒店价格至少要区分每晚房价是否含税费和服务费。是否含早餐。是否含清洁费。是否预付退订时扣除多少。AI Mode 在展示价格时最好能明确写出“含税总价”“不含行李”“每晚含税价”等口径。用户在比较不同平台价格时也应当先统一口径再判断哪个更便宜。很多“AI 推荐的价格和官网不一致”的问题根因不在 AI而在比较基准不同。4.4 隐私与数据使用边界使用 AI Mode 管理旅行计划意味着旅行日期、目的地、预算范围、甚至住宿偏好都会被对话系统记录。这是该功能的便利基础也是隐私边界所在。用户在输入敏感信息前要有基本判断不要直接输入护照号、身份证号、银行卡号等敏感信息。支付环节应当跳转到受信任的预订页面完成而不是在对话里发送完整卡号。确认取消、退款、投诉纠纷时应联系订单所属平台或酒店方而不是继续依赖 AI 回复。产品的做法应当是默认不过度收集信息能完成任务时只保留必要参数。开发者在实现这类功能时也要把用户输入信息的最小化和存储时限纳入设计不能因为 AI 能理解自然语言就默认允许它接收并保存一切个人信息。5. 典型使用场景与功能边界什么值得用什么不能依赖5.1 适合 AI Mode 的旅行决策AI Mode 最适合的场景有几个共同点条件多、计划性强、结果可比较、用户希望减少重复操作。典型场景包括多日期比价。用户可以把五个不同出发日期的要求一次性告诉 AI让它分别计算并汇总。多城市行程。用户要比较“先到东京再去大阪”和“直接住大阪”哪个更划算。长期盯价。距离出行还有两个月用户希望价格下跌时得到提醒。复杂政策筛选。用户明确指出“可以免费取消”“评分 8.5 以上”“每晚不超过 900 元”。这些场景里AI 的价值不是替代用户判断而是帮用户节省“反复查询和整理条件”的时间。用户的最终决策权仍然被保留系统只是把信息整理得更适合决策。5.2 不适合的用法和原因有几类旅行场景不适合依赖 AI Mode原因是它们的需求过于依赖实时状态和人工沟通。短暂且紧急的行程不适合。比如飞机两小时后起飞需要立刻改签用户应该直接打开航司应用或联系客服。AI Mode 的回答速度再快在紧急场景里也多了一层不确定。政策极其特殊的航班不适合。某些特价机票的退改规则非常复杂可能涉及代金券、积分、旅行社代理二次确认。AI 很难在对话里完整处理这类规则强行自动化反而会带来风险。小语种地区的异常情况不适合。偏远地区的酒店可能没有稳定的在线库存接口AI 返回的信息可能不是最新状态。遇到酒店客满、临时维修、押金规则不明时人工确认仍是必要补充。5.3 面向实际用户的三条使用建议给真实用户的三条建议可以直接用于日常操作第一把条件一次说完整。出发地、目的地、日期、预算、舱位、转机次数能一次提供就不要拆成十次追问。条件越完整AI 生成的追踪规则越接近预期。第二创建规则后检查一遍关键参数。系统返回“已为您盯住以下航班”时不要直接关掉。看一眼日期、币种、价格阈值和通知渠道发现问题当场修改比等通知出错再排查容易得多。第三预订流程中只把对话当成“筛选器”把支付当成“关键节点”。筛选和推荐可以交给 AI支付、确认号和退改操作一定要回到正式订单页面并保存订单截图或确认邮件。6. 常见问题与排查路径6.1 提示没有出现追踪入口现象用户搜索航班但没有看到任何价格追踪按钮AI Mode 也没有主动询问是否需要盯价。可能原因当前账号不在功能灰度范围内。应用或浏览器版本过旧。查询词本身是具体航班号而不是可追踪的航线查询。当前区域暂未开放该能力。检查方式先换一条简单查询例如“上海到东京的机票”看是否出现追踪入口。再检查应用版本和账号设置。处理建议如果排查后仍无入口直接回到普通搜索列表使用传统价格提醒功能不要反复用不同措辞触发 AI Mode避免把“功能未开放”误判成“搜索理解能力不足”。6.2 价格通知没有按时到达现象用户创建了追踪规则系统也提示追踪成功但价格下降后没有收到任何通知。可能原因通知权限没有打开。设置的是邮件通知但邮箱填错或邮件进入垃圾箱。系统判定价格变化未达到通知阈值。报价源没有更新系统拉取到的价格仍然是旧值。检查方式先查看追踪规则里的通知渠道和阈值再检查邮件垃圾箱和应用通知设置。如果规则、权限都正常最后判断这个价格是否存在可以用航司官网或 OTA 手动查一次。处理建议通知类产品建议做“规则状态可见”设计。用户打开追踪页面后能看到“最近一次价格检查时间”和“上次通知时间”这样问题出在哪一段链路会更容易定位。6.3 预订流程在跳转后中断现象AI Mode 推荐了酒店用户点击预订后跳转到外部页面但页面没有自动带入入住日期和房型甚至出现“无房”提示。可能原因对话中确认的日期没有正确传递给预订页面。库存不是实时的AI 推荐时显示有房用户点击时已被预订。外部页面需要登录登录后未保留跳转参数。检查方式回到对话记录里确认系统展示的“入住日期”和“退房日期”是否与用户输入一致。再确认跳转页面里的日期参数是否带过来。处理建议最稳妥的方案是让跳转页面保留完整参数用户只需要登录和支付。任何一个环节丢失参数都会让用户觉得是系统“乱跳转”。对于库存不一致问题AI 推荐结果里应增加“该价格更新于 xx 分钟前”的提示。6.4 价格结果与航司官网不一致现象AI Mode 显示的价格比航司官网便宜很多或贵很多。可能原因报价源是 OTA和航司官网是不同渠道。显示价格未含税或未含行李费。比较的是不同舱位等级。报价源存在缓存更新不及时。检查方式把价格口径列出来对比看是否是含税总价、是否包含同样行李额、是否同一舱位。再点击报价详情查看来源确认是哪家在卖。处理建议看到低价时要多看一眼来源。正常渠道里某个来源突然便宜 30% 以上大概率是价格展示口径不同或者库存剩余极少。不要只看数字要看计价规则。问题现象可能原因检查方式处理建议无追踪入口灰度未开放、版本过旧换通用查询词、检查版本回退到普通提醒功能通知未到达权限、邮箱、阈值检查设置和垃圾箱增加规则状态与最近检查时间预订跳转中断参数丢失、库存过期核对日期参数、来源跳转页保留完整参数价格不一致渠道不同、口径不同对比含税与来源以航司官网确认为准7. 对旅行工具开发者的启示与落地清单7.1 真正产生价值的是“从回答到行动”的闭环做 AI 旅行工具的开发者容易陷入“把回答做得很漂亮”的误区。AI 能列出十个航班、五个酒店看起来理解能力很强但用户还是没有完成预订仍然需要自己打电话、自己开 OTA、自己重新填写日期。从产品角度衡量AI Mode 机票追踪和酒店预订的价值不在于它能回答得有多像人而在于它能不能减少用户从“得到答案”到“完成行动”之间的步骤用户说“帮我盯价”系统是否真的在后端按规则检查了。用户说“帮我订酒店”系统是否能生成有效订单。用户改变条件系统是否能在一句话之后更新整条规则。这些问题才是产品闭环的硬指标。7.2 意图解析在实现层面对应的最小数据结构如果把追踪功能落到工程实现至少需要一个数据类来保存用户规则。下面的示例用于说明思路不是官方实现from dataclasses import dataclass, field from typing import Optional, List dataclass class PriceTrackRule: rule_id: str user_id: str origin: str destination: str trip_type: str # oneway / round_trip outbound_date: str return_date: Optional[str] None cabin_class: List[str] field(default_factorylambda: [economy]) max_stops: int 2 price_threshold: float 0 currency: str CNY notify_channel: List[str] field(default_factorylambda: [email]) enabled: bool True created_at: str updated_at: str def should_notify(rule: PriceTrackRule, current_price: float) - bool: if not rule.enabled: return False if rule.price_threshold 0: return True return current_price rule.price_threshold这个结构说明三个工程判断cabin_class和notify_channel使用列表因为用户可能同时接受经济舱和公务舱也可能同时要邮件和应用通知。return_date使用可选类型因为用户可能只追踪单程。should_notify独立成函数便于后续加入“最近已通知时间”“价格降幅比例”等更细的触发条件。生产环境里这个类还要加上版本号、数据源来源、通知去重键和过期时间字段。规则结构越清晰后续扩展越容易。7.3 AI 输出必须可解释、可回退、可追踪AI 旅行功能有很强的用户信任问题。用户不确定“这个价格哪来的”“这个推荐为什么符合我的条件”“这个订单到底订上没有”任何一环不透明都会导致用户流失。所以在工程落地时至少要做到每个推荐结果都有来源标识用户能知道价格来自航司官网还是 OTA。每个关键结论都有条件说明例如“因为您要求免费取消所以推荐这家”。每条追踪规则都能被用户手动关闭不能让用户进入“想停又停不了”的状态。每个订单都有可查询状态用户至少能看到“预订中”“已确认”“已取消”之一。可解释性不是上线后补的功能而是在设计数据结构时就要保证每个字段都能追溯到一次用户操作或一个上游系统。7.4 项目落地前的检查清单把 AI 旅行功能从演示 Demo 推向真实环境前建议按下面的清单逐项确认自然语言生成的追踪规则是否会在创建前让用户确认关键参数。价格追踪是否设置了有效期用户出行后是否自动停止。通知是否去重是否重复发送同一条价格变化。推荐结果是否标注来源和更新时间。预订跳转参数是否完整是否经过未登录场景测试。订单状态能否统一查询确认号是否在界面上可见。支付和个人敏感信息是否在受信任页面完成不在对话中传输。用户关闭追踪或取消订单后相关数据是否按策略保留或删除。每个关键环节是否有日志记录用于回放用户操作链路。是否在高价或低价两端都做过提醒测试避免只验证正常路径。实际项目里最值得优先做的是规则确认和状态可见。规则确认能减少用户被误导的可能状态可见能减少用户问客服的比例。AI 旅行产品刚上线时用户不是在等一个最聪明的回答而是在等一个能放心完成预订的流程。先把流程闭环做好再把回答质量提上去迭代顺序不要反过来。
