如果有人告訴你，有25%前往希臘的游客去過米克諾斯島，那么即使你不知道那有什么好吃的好玩的，你是不是也會考慮去一趟？如果再有人告訴你，提供這組數據的人可能就是和你一樣的普通人，你會不會更信服一點？

這就是窮游做行程助手的優勢。

窮游行程助手產品經理梅子說，做這個產品的初衷是看到論壇上有用戶會上傳自己的行程，還有更多的用戶在評論里“跪求行程”，那時候用戶用word或者excel做行程，整個過程中要無數次翻墻搜Google map，漫天找攻略。梅子覺得這是種需求，也許值得做個產品，但最初整個團隊其實很不確定。

和今天的行程助手類產品相比，這款產品在框架上并沒有太多特別之處：選定目的地，添加目的地內部的城市、游玩時間、游玩景點、住宿和餐飲，補上目的地小交通和一些其他細節，最后打包生成行程。

用戶既可以在PC端網頁上設計行程，然后同步到app，也可以直接在app上完成行程設計。在我看來，這個產品有這么幾個亮點：

• 基于用戶數據的目的地：在很早版本的窮游論壇上，就有基于POI的“去過”和“想去”功能，這個數據積累為行程助手提供了幫助。在每個目的地和當地的大部分POI，行程助手可以用一個百分比展示這個景點在用戶心中的受歡迎程度，例如去日本的87%都會去京都，去伊斯坦布爾必去藍色清真寺。此外，在目的地小交通上，行程助手也會展示多少人搭乘飛機、多少人搭乘火車，單程所需時間等諸如此類。

• 基于用戶數據的行程調整：行程助手有智能調整行程的功能，這套智能調整除了基于地理位置的相互關系之外，還會考慮其他用戶歷史習慣，例如用戶去了景點A之后，有較大概率會去附近的景點B，那就會智能推薦的行程就會把B放在A的后邊。

• 問路卡：用戶選定一個POI（餐館、景點等）后，產品可以展示它的當地語言，并在屏幕上變成一張卡片，用戶可以直接拿著手機屏幕去找當地人問路。

• 接入Uber：行程助手通過API接入的方式，讓用戶可以直接預訂Uber的車輛，當然這只限于Uber運營的國家和地區。

我們都能看到窮游做這款產品的優勢，比如很多年積累下來的高質量用戶（梅子說他們提供了大量有效的產品建議），比如基于窮游錦囊和目的地的大量結構化POI數據等?；跀祿?，窮游行程助手在一開始所覆蓋的境外目的地就比較全，功能也實用，加上忠實用戶的試用，這讓產品團隊在過去兩年中積累了不少數據，后臺算法也基于這些數據進行滾動調整，POI數量也隨之增加，進入了一個正向循環。

這也是為什么一個初創公司從零開始做一個行程助手并不容易——沒有足夠用戶試用積累數據，數據庫信息有限，很容易陷入惡性循環。梅子也認同這個觀點。

作為一個誕生在PC時代的產品，行程助手也在嘗試迎合移動端使用習慣。比如用戶可以在app上隨時增減行程，例如今天心情不好，原計劃6個景點，現在減少到3個，“搖一搖”之后系統就會重新推薦一個新行程；再比如，行程助手還提供基于LBS的周邊景點、餐飲的基本信息和評價的功能。這些簡介一部分是來自于窮游的游記和論壇內容的，和其他競爭對手一樣，窮游也在考慮如何將有價值的、包含POI的內容做結構化處理。梅子認為，行程助手就是很巧妙的解決方案，因為所有行程助手內的信息全部是結構化的。

窮游也在試圖通過行程助手導向交易，現在PC端就提供添加景點后直接購買門票的功能——當然是導向”窮游折扣“。梅子說，目前工作的重點一個是擴大窮游折扣的SKU，另外就是加強app上的即時預訂功能。但即時預訂并不容易，因為窮游折扣的目的地產品大多是來自不同供應商的，供應鏈管理和實時的預訂確認是兩個難點。

目前窮游行程助手境外打開比例達到40%以上，已經積累了百萬級別的用戶，上千萬個行程。

最后我跟梅子討論了兩個小問題：

做行程是不是入口：梅子認為“是的”，因為根據用戶習慣，一般先有旅游靈感，然后確定目的地做行程，之后才考慮酒店機票（當然也有用戶是先搶到便宜機票才做行程），因此通過行程助手導向其他交易是可行的，比如窮游的酒店信息就來自于Booking.com的產品庫。

做行程助手遇到什么坑？梅子覺得最大的坑就是如何提升算法，讓行程推薦更智能、更準確。另外通過PGC和UGC方法擴大POI也是一個難點，如我們上面所說只有覆蓋較多目的地的行程助手才有意義。另外梅子認為，行程計劃是一件復雜的事情，因為產品就變得復雜，這和用戶的易用性是矛盾的。因為功能越多，用戶就越難上手，而恰好小白用戶是數量最多的一群人。梅子希望窮游行程助手能夠讓資深用戶覺得好用（因為窮游匯集了用戶群中相對資深的一幫游客），同時小白也很容易上手，比如優化智能推薦的功能（這個功能有時候對于資深用戶來說其實是很雞肋的）。