扫码打开虎嗅APP
本文来自微信公众号: 环球旅讯 ,作者:程小雨,原文标题:《一个 AI 问题,把我问进了文旅行业的深水区》
上周的文章在环球旅讯发布后,C总发来微信。
他没有聊稿子的事,直接抛了一个问题过来:“小雨,你觉得大模型可以改变酒店集团接入渠道的方式吗?现在酒店和OTA的对接,都是通过德比(DerbySoft)这样的公司来做中间层。以后酒店集团能不能直接把接口喂给大模型,自己实现数据对接?"
我盯着这条消息,愣了一下。
这个问题表面上在聊技术,但它背后藏着一个文旅行业几十年都没解决的深层矛盾:酒店明明是服务的提供者,但它的客人,却一直掌握在别人手里。
我做了十年文旅SaaS,见过太多酒店的CIO在这件事上的无奈。
德比这样的公司,本质上是在做一件事:翻译。每家酒店集团的后台系统(CRS)格式不一,数据标准各异,OTA们要接入几千家酒店,不可能一家一家去适配。于是就有了德比——它修了一套“万能适配器”,把混乱的接口统一成OTA能读懂的语言。
这个生意做了几十年,做得很稳。
但C总的问题戳到了一个正在松动的地方:如果AI能直接读懂任何格式的数据,那这个“翻译官”还有存在的必要吗?
我想了很久,觉得这件事可能真的要发生,但不是以大家想象的方式。
AI不会直接干掉德比,但它会让连接的门槛降到接近于零。今年技术圈最火的协议叫MCP(Model Context Protocol),它的逻辑很简单:不再要求你把数据推给谁,而是在你家门口开一个“AI专用窗口”,让各种AI Agent按需来取。
如果一家酒店实现了MCP,它就不再需要等待德比去帮它适配每一个新渠道。任何一个AI助手——无论是ChatGPT、Claude,还是某个垂直旅游App的Agent——都可以直接来读它的房态和价格。
酒店第一次有机会,把自己的数据主权拿回来。
但我随即想到了另一个问题:酒店的数据真的“干净”到可以被AI直接读吗?
这里有个我在行业里观察了很久的现象,但很少有人直说:文旅行业的技术债,可能是所有行业里最重的。
很多酒店集团的核心系统,是二三十年前搭的。房型的命名规则,每个品牌不一样;同一家酒店,在不同渠道上的描述可能完全矛盾;历史订单数据散落在各个系统里,格式混乱,几乎无法直接使用。
过去,清理这些数据需要大量的人工,成本高到没有人愿意动。
但AI来了之后,这件事的逻辑反转了。
大模型处理非结构化数据的能力,是它最强的地方。酒店完全可以用AI来做一件以前不敢想的事:把几十年的技术债,原地转化成可被AI读取的资产。
不需要推倒重建,只需要在旧系统之上盖一层“语义层”。AI负责理解那些混乱的历史数据,把它们整理成结构清晰、可被任何Agent调用的知识库。
这是一个窗口期。先动的人,会在AI时代拥有真正的数据护城河。
聊到这里,我的思路开始往外延伸。
酒店是标准化产品,它的核心参数就那几个:位置、价格、房型、日期。即便AI直连再顺畅,这个市场的竞争逻辑不会根本性地改变:OTA的流量优势短期内依然存在,酒店的直销比例提升是一个漫长的过程。
但有一个细分市场,让我觉得AI的冲击会来得更快、更猛:
非标的本地体验产品。
一日游、半日游、私人向导、小众工坊……这是文旅供应链里信息化程度最低的一块。很多优质的体验根本不在任何OTA上,它们藏在某个博主的私藏清单里,或者一个清迈向导发在Instagram上的行程海报里。
传统的分发逻辑在这里完全失效。OTA要求供应商有系统、有接口,但一个只带10个人的私人茶道体验,哪来的IT团队?
这恰恰是AI Agent的主场。
Agent不需要对方有系统,它能直接读取那张Instagram海报,提取出时间、价格、人数限制,然后帮用户完成预约。它甚至可以直接发一封邮件给向导,问明天还有没有位置。
这种模拟人工的自动化,让那些从来没有机会被数字化的体验产品,第一次进入了可被AI分发的范围。
但如果顺着这个逻辑往下想,一个非常现实、甚至有些刺痛的问题就摆在面前了:算得过来账吗?我身边有很多同行,在文旅场景里真刀真枪地试过AI,最后往往卡在一个地方:Token经济学。
旅游行业的毛利率本来就薄如刀片。如果让大模型从头去生成一条10天的欧洲定制线,光是行程逻辑校验、POI匹配、价格核实这几个环节叠加,Token的消耗量可能是普通对话的50到100倍。你用AI替代了人工,但付给大模型厂商的API费用,可能比人工工资还要高。这根本形成不了商业闭环。
所以,文旅AI的出路,绝对不是让大模型去包揽一切,而是"混合动力"。不要让AI去写行程,要让AI去选行程。
让AI只做它最值钱的那10%——理解意图、处理模糊需求、生成情感化语言。剩下90%的结构化查询、库存匹配、逻辑校验,必须交给传统的软件工程和数据库。
这不是对AI的妥协,这是更合理的架构。
今天舍不得投入做数据结构化的公司,明天会发现自己的Token消耗永远比别人贵三倍,因为你的AI要花大量昂贵的算力去猜那些本来可以直接查到的东西。
想到这里,我忍不住把这个逻辑往路书身上套了一下。
路书做了十年,核心是什么?是8000多个目的地的结构化数据,是百万条被人工筛选过的POI,是无数定制师用经验积累下来的行程逻辑。
这些东西,在SaaS时代,是工具,定制师用它来提高效率,减少查资料的时间。
但在Agent时代,这些东西的性质变了。
它们变成了AI能够跑起来的轨道。
如果没有这些结构化的数据和行程逻辑,AI生成的旅行计划就是在沙滩上盖楼。看起来很美,但一碰就塌。它会把一个腿脚不便的老人安排去爬陡坡,会把一个清真饮食的家庭带去猪肉餐厅,会在博物馆闭馆的周一安排参观。
大模型的通识,需要行业数据的校正,才能变成真正可用的服务。
这让我想到了一个更大的问题:未来的文旅SaaS,究竟是什么形态?
我思考了很久,最后用了一个比喻来描述它。
传统的SaaS,是一台缝纫机。它很快,很稳,功能齐全。但你要用它做出一件合身的衣服,必须自己量体、打版、踩踏板。工具是工具,活还是你来干。
未来的Agent-Native产品,是一个私厨。
你不需要告诉他怎么做,你只需要说:我今天胃口不太好,想吃点清淡的。他会根据当季的食材,根据他对你口味的了解,端出一道不在菜单上、但正合你心意的菜。
用户的需求,才是第一性的。技术是手段,不是目的。
这听起来像是一句正确的废话,但它在文旅行业里,意味着一场真实的商业模式重构。
现在的文旅SaaS,卖的是账号——你付年费,我给你用工具。未来的Agent-Native产品,卖的是结果——你告诉我你想要什么旅行,我直接交付给你一个可执行的、个性化的方案,甚至帮你完成预订。
从卖工具,到卖服务。从教你怎么做,到直接帮你做。
这个转变,对文旅行业的每一个CIO来说,都意味着要重新回答一个问题:我们的产品,到底是在服务谁?
我把这些想法整理了一遍,发现自己绕了一个很大的圈,但最后落脚的地方,其实很朴素。
C总问酒店能不能直连大模型,这本质上不是一个技术问题,而是:你愿不愿意把自己的数据主权拿回来?
而我在路书这十年一直在做的事,其实也是同一件事:把那些散落在世界各地的旅行体验,变成一种可以被理解、被传递、被精准匹配的语言。
只是现在,这种语言,终于有了一个足够聪明的读者。
如果你在文旅产业的供应链端深耕,欢迎来聊。我最近在想的,正是这些。