一个 AI 问题，把我问进了文旅行业的深水区

*本文为评论员程小雨（路书科技创始人，十年文旅 SaaS 老兵）投稿， 不代表环球旅讯立场

上周的文章在环球旅讯发布后，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总问酒店能不能直连大模型，这本质上不是一个技术问题，而是：你愿不愿意把自己的数据主权拿回来？

而我在路书这十年一直在做的事，其实也是同一件事：把那些散落在世界各地的旅行体验，变成一种可以被理解、被传递、被精准匹配的语言。

只是现在，这种语言，终于有了一个足够聪明的读者。

如果你在文旅产业的供应链端深耕，欢迎来聊。我最近在想的，正是这些。