当我们需要计划一次旅行时通常要来回切换好几个网站先查机票再去常旅客网站看里程余额和兑换规则最后还要在 OTA 平台上横向对比酒店价格。整个过程非常消耗精力而且信息分散在不同系统里。Google 搜索的 AI Mode 正是因为这类“多步骤、多来源、需要实时数据”的复杂查询而设计的。近期 AI Mode 在旅行规划场景中新增了三类能力机票价格追踪、积分里程查询、酒店预订。本文会拆解这三个能力到底是什么、怎么用、有什么边界并从开发者视角补充一套可以自己动手实现的旅行价格追踪与提醒方案。阅读本文后你能理解 AI Mode 在旅行场景的工作原理学会用更精准的提示词获取结构化答案也能参考 Python 代码实现一个简单的“价格录入—趋势判断—邮件提醒”工具。无论你是普通用户还是后端开发者都能从里面找到可以直接上手的内容。1. AI Mode搜索正在从“给链接”变成“给答案”1.1 什么是 Google 搜索 AI Mode传统的 Google 搜索返回的是一组蓝色链接用户需要自己点开多个网页再人工比对信息。AI Mode 则是搜索结果页中的一种交互模式它会在回答区域直接生成一段经过整理的 AI 摘要内容不只是把网页内容拼在一起而是根据用户的问题把多个来源的信息重新组织成结构化答案。从产品形态上看Google 搜索在逐步把所有搜索结果都加入 AI 摘要能力同时面向部分国家和地区开放更完整的 AI Mode 页面。用户可以在搜索框中输入自然语言问题例如“从上海去首尔玩 4 天往返机票什么价位什么时候买最划算”AI Mode 会综合航班价格、历史数据、目的地信息等内容给出一个相对完整的回答。这里有个关键点AI Mode 不是简单的大语言模型聊天窗口它背后依赖的是搜索索引和实时数据源。也就是说它回答航班价格时不是凭空生成一个价格而是基于当前可检索到的实时数据做归纳。1.2 为什么旅行规划天然适合 AI Mode旅行规划是一类典型的复杂查询它同时具备三个特征多步骤先查交通再查住宿还要计算总预算。多来源航班数据、酒店数据、常旅客规则分散在不同平台。强实时性机票和酒店价格每天都在变甚至一天内多次变化。这三个特征决定了传统搜索很难一次性给出可用答案。用户需要在十几个标签页之间跳转然后自己手动做表格对比。而 AI Mode 可以把这些步骤压缩成一次对话用结构化的方式输出对比结果。从技术角度来看这类查询也适合大语言模型处理。因为价格数据本身是结构化数据模型只需要理解用户意图再去调用对应的数据接口或检索数据源最后把结果整理成人类可读的段落。1.3 与传统旅行搜索的差异传统旅行搜索的代表是 Google Flights、Google Hotels 这类垂直产品它们的特点是“筛选器非常强”用户可以通过出发时间、航空公司、价格区间、中转次数等条件快速把结果缩小到一个精确范围。AI Mode 的定位不太一样它更适合回答“我该怎么做”的问题而不是“有哪些选项”的问题。举个例子Google Flights 适合回答“下周三 PVG 到 ICN 有哪些航班按价格排序”。AI Mode 适合回答“我四月上旬想去首尔玩 4 天现在订机票划不划算还是再等等”前者是筛选工具后者是规划助手。两者不是替代关系而是互补关系。2. AI Mode 新增的三种旅行规划能力2.1 机票价格追踪把“价格波动”变成“购买建议”机票价格追踪是这次更新中最实用的能力。用户关心的往往不是某一个航班的精确价格而是“这个价格处于历史什么水平”“现在买还是再等等”。AI Mode 会结合历史价格数据给出类似下面这些信息当前价格处于过去三个月的低位、中位还是高位。该航线是否有明显的大促规律。建议立即购买还是继续等待。是否需要考虑附近机场或调整出行日期。使用这类功能时建议在提问中带上足够明确的上下文。固定出发城市、目的地、大致日期和出行人数AI 才能给出更有参考价值的判断。2.2 积分里程查询把“会员规则”变成“兑换方案”常旅客里程是旅行规划里最复杂的信息之一。每个航司的积分规则不同不同联盟之间的兑换表也不同再加上税费、燃油附加费、旺季浮动等因素普通用户很难判断“用里程兑换到底值不值”。AI Mode 在这方面的价值是信息聚合。它会阅读航司公开发布的常旅客计划条款然后根据你的提问给出兑换所需里程、税费估算、不同航司之间的对比等结论。比如说你可以问“用美联航里程兑换全日空的商务舱从北京飞东京大概需要多少里程税费大概多少”AI Mode 会尝试把两家航司的公开规则拆出来整理成兑换建议。需要注意的是个人账户中的里程余额、专属促销码、会员等级折扣AI 是无法获取的。这类数据必须登录航司官网或 App 查看。2.3 酒店预订把“房源筛选”变成“对比推荐”酒店预订能力解决的问题是在预算、评分、位置、日期等多个条件同时存在时怎么快速选出合适的酒店。你可以用自然语言描述完整需求例如“帮我找杭州西湖附近5 月 1 日入住两晚、评分 4.6 以上、每晚 800 元以内的酒店推荐三家并对比优缺点”。AI Mode 会依据 Google Hotels 的房源信息生成一份带理由的推荐列表。它和 OTA 平台的区别在于OTA 展示的是标准筛选结果列表而 AI Mode 更像一个了解你需求的助手它会解释为什么推荐某家酒店比如“这家距离西湖步行 10 分钟虽然价格略高但含双早综合性价比不错”。2.4 三种能力如何组合使用这三个能力并不是孤立的。AI Mode 的对话式交互允许你在同一个会话里连续提问它会保留上下文。你可以先问机票再问酒店最后再回来确认“如果我提前一天出发机票价格会不会更低”。这比在多个网站之间来回切换要流畅得多。从商业角度看这三种能力覆盖了旅行规划中最高频的决策环节我什么时候去、怎么去、住哪。这也是为什么 Google 会把它们作为 AI Mode 旅行场景的首批重点能力。3. 实战用 AI Mode 完成一次完整的旅行规划3.1 使用前的准备在开始之前先确认几件事需要一个可正常登录的 Google 账户。建议使用 Chrome 浏览器访问 google.com保留完整搜索体验。AI Mode 目前按地区和语言逐步开放入口位置和可用性以页面实际显示为准。部分用户将语言设置为 English 后可以看到入口但这不是绝对的请以官方支持范围为准。尽量不要使用刚注册、信息不完整的账户。如果账户被风控提示异常先按 Google 的指引完成验证或申诉流程不要反复注册新账号这类操作会进一步触发安全限制。如果你遇到“AI Mode 入口没有显示”的情况优先检查两点浏览器版本是否太旧、Google 账户语言设置是否符合功能开放要求。3.2 机票价格追踪操作示例在 AI Mode 输入框中尝试下面这个问题从上海出发去首尔玩 4 天4 月中旬出发往返机票目前大概什么价位过去三个月的价格走势如何现在订还是再等等更划算AI Mode 可能会返回以下内容过去三个月的价格区间例如 1200 到 2600 元。当前价格所处的位置例如“处于中位接近历史低位”。建议的购买窗口例如“距离出发还有 6 周历史数据显示出发前 3 到 5 周通常价格较低”。这类回答的参考价值很大但你必须清楚一点AI 给出的价格是基于搜索时点的数据不是实时出票价。最终下单价格要以航司官网或票务平台显示为准。3.3 积分里程查询操作示例如果你持有某家航司的里程或者想比较不同航司的里程价值可以这样提问星空联盟哪家航司的里程兑换中日航线最划算用美联航里程兑换全日空东京飞北京的商务舱需要多少里程税费大概多少AI Mode 会尽量整理出兑换表、税费估算和比较结论。不过里程规则经常变动而且不同渠道看到的兑换表可能有细微差别建议把 AI 给的结果当作“初步筛选”最后一定要到航司官网的兑换页面确认实际所需里程。3.4 酒店预订操作示例酒店选择的提问信息维度要更细否则 AI 给不出有差异化的结果。推荐这样写帮我找杭州西湖附近5 月 1 日到 5 月 3 日入住两晚评分 4.6 以上每晚预算 800 元以内的酒店。推荐三家说明每家离景点的距离、是否含早餐、退改政策并给出最终选择建议。AI Mode 会从 Google Hotels 的房源数据中筛选符合条件的酒店并生成对比说明。这个功能在出行时间不固定、需求描述复杂的场景下尤其好用。比如“带老人小孩不想走太多路离地铁近最好有家庭房”这种需求在传统 OTA 里要设置很多筛选项而在 AI Mode 里直接描述即可。3.5 拿到结果后如何交叉验证AI Mode 的输出再智能也只是一个“信息整理助手”不是最终决策依据。原因有三条数据存在延迟价格会变。AI 在归纳规则时可能出现简化或偏差。部分信息来自第三方站点存在不准确的可能。所以我的建议是遵循“双源验证”原则凡是涉及付款的决定至少在两个独立渠道核对。机票去 Google Flights 或航司官网核对里程去常旅客账户确认酒店到 OTA 或酒店官网看实时价格和退改政策。4. 开发者方案自己写一个旅行价格追踪与提醒工具如果你对 AI Mode 这类能力背后的实现感兴趣或者想做一个针对特定航线的自定义价格提醒工具下面这部分可以直接参考。我们会从数据源选择、代码实现到定时运行完整走一遍。4.1 整体架构思路一个最简版的旅行价格追踪工具包含四个模块数据采集定时获取目标航班或酒店的最新价格。数据存储把每次采集到的价格写入 SQLite形成历史数据。趋势判断基于历史数据计算均值、最低价判断当前价格是否值得购买。提醒通知当价格低于阈值时通过邮件或消息推送通知用户。整个流程可以概括为采集 → 存储 → 分析 → 通知。4.2 数据源三种获取方式的取舍获取价格数据主要有三种方式方式优点缺点适用场景官方开放 API数据稳定、合法合规需要申请密钥通常有调用限额个人学习、小型工具第三方聚合 API接入简单覆盖面广成本较高有预算的创业项目网页抓取免费用可自定义有法律风险页面结构易变仅用于学习原理不建议生产使用这里有一个重要提醒任何爬虫方式都要遵守目标网站的 robots 协议和相关法律法规。生产环境优先使用官方 API 或已授权数据源不要为了省成本去抓取其他平台的数据。4.3 示例一调用航班价格开放 API下面以航空业常见的 Amadeus 自服务 API 为例演示航班价格查询的基本写法。使用前需要在 Amadeus for Developers 注册并获取 API Key 和 API Secret。示例代码中的接口地址、字段名请以官方文档为准。# 文件路径flight_price/amadeus_client.py # 说明基于 Amadeus 自服务 API 的通用调用思路运行前请替换密钥并确认接口版本。 import requests CLIENT_ID 你的_CLIENT_ID CLIENT_SECRET 你的_CLIENT_SECRET BASE_URL https://test.api.amadeus.com def get_access_token(): 获取 OAuth2 访问令牌Token 通常有效期为 30 分钟。 url f{BASE_URL}/v1/security/oauth2/token payload { grant_type: client_credentials, client_id: CLIENT_ID, client_secret: CLIENT_SECRET, } resp requests.post(url, datapayload, timeout10) resp.raise_for_status() return resp.json()[access_token] def search_flight_offers(origin, destination, depart_date, adults1): 查询指定日期、指定航线的航班报价。 token get_access_token() url f{BASE_URL}/v2/shopping/flight-offers headers {Authorization: fBearer {token}} params { originLocationCode: origin, # 示例PVG 上海浦东 destinationLocationCode: destination, # 示例ICN 首尔仁川 departureDate: depart_date, # 示例2025-04-10 adults: adults, currencyCode: CNY, max: 10, } resp requests.get(url, headersheaders, paramsparams, timeout15) resp.raise_for_status() return resp.json().get(data, []) if __name__ __main__: offers search_flight_offers(PVG, ICN, 2025-04-10) print(f共返回 {len(offers)} 条报价) for offer in offers[:3]: total offer[price][total] currency offer[price][currency] print(f总价: {total} {currency}) for segment in offer[itineraries][0][segments]: dep segment[departure][iataCode] arr segment[arrival][iataCode] dep_at segment[departure][at] print(f {dep} - {arr}, 起飞时间 {dep_at})这段代码的逻辑是先通过客户端凭证获取访问令牌再用令牌请求航班报价接口。返回的数据是 JSON 数组每条报价包含总价、货币类型、航线信息。你可以把这个函数封装成定时任务每天固定时间拉取一次价格。4.4 示例二实现价格记录与趋势判断拿到价格数据后需要把它存起来形成历史价格曲线。这里用 SQLite 做本地存储它不需要额外安装数据库服务非常适合个人工具。# 文件路径flight_price/price_tracker.py # 说明将采集到的价格写入 SQLite并基于历史数据判断当前价格水平。 import sqlite3 from datetime import datetime DB_PATH prices.db def init_db(): 初始化数据库表结构。 conn sqlite3.connect(DB_PATH) conn.execute( CREATE TABLE IF NOT EXISTS price_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, route TEXT NOT NULL, price REAL NOT NULL, currency TEXT DEFAULT CNY, checked_at TEXT NOT NULL ) ) conn.commit() conn.close() def save_price(route, price): 记录一次价格采集结果。 conn sqlite3.connect(DB_PATH) conn.execute( INSERT INTO price_log (route, price, checked_at) VALUES (?, ?, ?), (route, price, datetime.now().isoformat()), ) conn.commit() conn.close() def get_history(route, limit180): 获取最近 N 条价格记录用于计算趋势。 conn sqlite3.connect(DB_PATH) rows conn.execute( SELECT price FROM price_log WHERE route ? ORDER BY checked_at DESC LIMIT ?, (route, limit), ).fetchall() conn.close() return [row[0] for row in rows] def judge_price(route, current_price): 判断当前价格处于历史什么水平。 history get_history(route) if len(history) 5: return 历史数据不足暂不判断 avg_price sum(history) / len(history) min_price min(history) ratio current_price / avg_price if avg_price else 1 if ratio 0.85: return f低于历史均价 {avg_price:.2f} 的 85%处于低位可考虑入手 if ratio 1.0: return f约等于历史均价 {avg_price:.2f}处于正常区间 return f高于历史均价 {avg_price:.2f}建议继续观察 if __name__ __main__: init_db() route PVG-ICN # 实际使用时current_price 应替换为 API 或抓取返回的实时价格 current_price 1850 save_price(route, current_price) print(judge_price(route, current_price))这段代码强调了一个容易被忽略的点趋势判断需要足够的样本量。如果只采集了两三天的数据就做判断结论基本没有参考价值。建议至少连续跑一个月再根据历史分位数做决策。4.5 示例三里程兑换价值计算里程价值的计算是很多旅行爱好者的刚需。不同航司的里程价值差异很大通过一个简单函数就能量化比较。# 文件路径flight_price/miles_calculator.py # 说明计算里程兑换的每万里程价值用于比较不同兑换方案。 def compare_redemption(cash_price, miles_required, taxes_fees): 对比现金购票与里程兑换的价值。 参数 cash_price: 现金购票价格人民币 miles_required: 兑换所需里程数 taxes_fees: 兑换时需支付的税费人民币 返回 每 10000 里程对应的现金价值人民币 if miles_required 0: return 0 mile_value (cash_price - taxes_fees) / miles_required * 10000 return round(mile_value, 2) if __name__ __main__: # 示例某航班现金价 3000 元需要 25000 里程税费 200 元 value compare_redemption(3000, 25000, 200) print(f每万里程价值约 {value} 元) # 对比另一种方案现金价 5000 元需要 40000 里程税费 300 元 value2 compare_redemption(5000, 40000, 300) print(f每万里程价值约 {value2} 元)这个计算逻辑是通用的。你只需要把里程规则中的“所需里程”和“税费”提取出来就能在不同航司之间做横向比较。如果某个方案的每万里程价值明显高于其他方案说明它的兑换更划算。4.6 定时运行与提醒通道最后一步是把服务跑起来。个人项目最简单的方案是用 Linux 服务器上的 crontab或者 Windows 的任务计划程序。例如每天早晨 8 点采集一次价格# crontab 示例每天 08:00 执行价格采集和判断 0 8 * * * cd /path/to/flight_price python3 price_tracker.py tracker.log 21提醒通道可以选邮件。用 Python 的 smtplib 发送邮件核心代码大致如下# 文件路径flight_price/notifier.py import smtplib from email.mime.text import MIMEText def send_alert(route, price, to_addr): 发送价格提醒邮件。 smtp_host smtp.example.com smtp_port 465 sender your_accountexample.com password your_authorization_code msg MIMEText(f检测到 {route} 当前价格 {price} 元已达到你的预期区间。, plain, utf-8) msg[Subject] f{route} 价格提醒 msg[From] sender msg[To] to_addr with smtplib.SMTP_SSL(smtp_host, smtp_port) as server: server.login(sender, password) server.sendmail(sender, [to_addr], msg.as_string())这里有几个工程上的小坑邮箱密码要使用授权码而不是登录密码提醒频率要控制好每天最多一次避免在深夜打扰发送失败要记录日志并重试。5. 常见问题与排查思路在尝试使用 AI Mode 或运行上面的代码时你可能会遇到下面这些问题整理成表格方便对照排查。问题现象常见原因解决思路搜索页没有 AI Mode 入口功能按地区和语言逐步开放账户未进入白名单确认浏览器版本检查账户语言设置关注官方支持范围更新Google 账户提示异常短时间内异常登录、批量创建账户等触发风控前往账户安全中心完成验证或申诉不要反复注册新账号AI 给出的机票价格和实际下单不一致AI 基于搜索时点的缓存数据非实时出票价以下单页面的实时价格为准把 AI 结果当作参考区间里程余额和兑换规则查不到AI 无法访问个人账户数据登录航司官网或 App 查询AI 只适合查公开规则酒店价格与 OTA 平台显示不同不同渠道的佣金、促销、库存不一致多重平台比价核对退改政策和隐藏费用Python 调用 API 报 401访问令牌过期或密钥错误重新获取 Token检查 CLIENT_ID 和 CLIENT_SECRET 是否正确SQLite 写入失败数据目录无写入权限检查脚本运行目录权限或改用绝对路径如果你在运行时遇到某个具体报错先看报错信息的关键字段再用关键词搜索。大部分问题都能通过“版本号 报错信息 官方文档”定位到原因。6. 最佳实践与工程建议6.1 普通用户建议把 AI Mode 当作“整理信息”的助手而不是“最终决策”的依据。所有涉及付款的决定至少在两个独立渠道做二次确认。不要在 AI Mode 里输入自己的常旅客号、护照号、身份证号等敏感信息。启用 Google 账户的两步验证推荐用正规的验证器应用例如 Google Authenticator 这类减少账户被风控或盗用的风险。如果账户被提示“无法订阅 Google AI 方案”或“账户违反了政策”不要反复尝试注册新账号先通过官方渠道申诉。6.2 开发者建议数据合规是第一优先级。能用官方 API 就别爬网页爬虫只适合学习用途。如果做爬虫必须限速、设置合理 User-Agent、处理失败重试并在代码里保留日志。价格数据要设计缓存和增量更新机制避免频繁请求导致接口被限流或封禁。提醒系统要控制频率默认每天最多一次并且允许用户手动关闭。用户行程数据、邮箱地址属于敏感信息存储在本地时要加密不要打印到日志中。如果你的旅行类 App 要发布到 Google Play需要关注 AAB 包体大小限制。资源文件较大时建议用 Play Asset Delivery 做分包避免安装时间过长或审核问题。如果希望把价格查询、截图识别等 AI 能力放到端上可以关注 Google AI Edge、MediaPipe 这类端侧推理工具链它们更适合对延迟敏感的场景。7. 总结Google 搜索 AI Mode 在旅行规划场景中的三个新能力本质上反映了搜索产品的一个趋势从“帮你找到信息”到“帮你做完决策”。机票价格追踪、积分里程查询、酒店预订都是用户在做旅行决策时最耗费精力的环节。AI Mode 做的事情是把这些信息整合成可执行的建议而不是再丢给你一堆链接。对普通用户来说最值得掌握的是一件事把需求描述清楚然后永远保持交叉验证的习惯。对开发者来说本文提供了一条从零搭建价格追踪工具的路径你可以先跑通 API 调用再逐步加上历史趋势判断和邮件通知最终做成一个真正能用的个人旅行助手。最后留一个可执行的建议先用本文中的提示词模板把 AI Mode 用起来再从第三节的代码里挑一节跑一个最简单的价格追踪脚本。等真正收到一次“价格已低于历史均价”的提醒时你会对“实时数据 自动判断”这件事有更直观的理解。