![]()
![]()
*本文為評論員程小雨(路書科技創始人,十年文旅 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總問酒店能不能直連大模型,這本質上不是一個技術問題,而是:你愿不愿意把自己的數據主權拿回來?
而我在路書這十年一直在做的事,其實也是同一件事:把那些散落在世界各地的旅行體驗,變成一種可以被理解、被傳遞、被精準匹配的語言。
只是現在,這種語言,終于有了一個足夠聰明的讀者。
如果你在文旅產業的供應鏈端深耕,歡迎來聊。我最近在想的,正是這些。
![]()
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.