PickTrip建造術：產品閉環如何長出Travel Pack

Transcript

大家好，我是 Kai。 前兩集我們一路聊到 PickTrip 怎麼從一個 AI 旅行顧問， 慢慢補上登入、資料、地圖、協作和各種後端基礎設施。

也就是說，它不只是「看起來會聊天」，而是開始變成一個真的能承載旅行流程的產品。 Luna: 對啊，上一集我印象最深的是你說 PickTrip 正在從 AI 聊天工具，

變成一個「旅遊作業系統」。 這個詞聽起來很大，可是也很危險耶。 因為什麼都想做，很容易就變成什麼都做一點點。

完全正確。 所以今天這一集，其實就是要回答一個更核心的問題：PickTrip 的產品閉環到底是什麼？

它不是功能清單，也不是把 AI、購物車、地圖、相機、Travel Pack 全部放在一起就算完成。

Luna: 喔喔，所以今天不是在講「我們有好多功能」， 而是在講這些功能為什麼要連在一起？

沒錯。 你可以把 PickTrip 想像成一趟旅行從開始到結束的容器。 最中心的東西不是 AI，也不是 Travel Pack， 而是「行程」。

也就是 itinerary。 Luna: 行程？ 可是聽起來好普通喔。 很多 app 都有行程表啊。

對，行程表這三個字聽起來很普通，但 PickTrip 要做的行程不是一張靜態表格。 它比較像一個活的旅行物件。

裡面有每天的 timeline，有景點、餐廳、航班、飯店、 票券、note、todo，還有誰已經買了票、誰還沒買、誰被邀請進來、 誰修改了內容。

Luna: 等一下，這就不太一樣了。 它不是「我排了一張表」，而是「這趟旅行的所有狀態都掛在這張行程上」。

對。 這就是 PickTrip 的第一個判斷：行程是核心物件。 AI 是幫你操作行程的助手； Commerce 是讓行程可以被購買和執行；

地圖和 MiniApp 是讓行程在旅行中變成互動介面； 旅行相機是讓行程在結束後變成回憶； Travel Pack 則是把一趟被實際玩過的行程，變成可以分享、 複製、再次下單的模板。

Luna: 哇，這樣 Travel Pack 的位置就很清楚了。 它不是一開始憑空冒出來的攻略，而是旅行完成後長出來的成果。

這個差別非常重要。 很多旅遊產品會直接做攻略、做內容、做分享，但 PickTrip 如果要成立， 它應該先讓人真的完成一趟旅行。

因為只有被用過、被調整過、被朋友一起走過的行程，才有資格變成有價值的 Travel Pack。 Luna: 好，我想像一下。

假設我看到 Instagram 上有人分享東京咖啡廳，我很喜歡。 我先把它收藏起來。 這時候它是在 PickTrip 的哪裡？

它會進到「收藏庫」。 這裡也要講清楚，收藏庫是一個母功能，不是只有 social import。

你可以收藏 PickTrip 裡面的景點，也可以收藏別人的 Travel Pack， 也可以收藏外部連結，像 IG、小紅書、Threads、Reddit 或一般網站。

Luna: 所以 social import 只是入口之一， 不是整個功能本身。

對。 而且收藏庫背後其實很有價值。 因為它會記錄來源、時間、內容類型、多少人收藏、後來有沒有被加入行程。

你想想看，如果很多人都從 Instagram 收藏同一個東京餐廳， 這其實就是一個很強的偏好信號。

Luna: 喔！ 所以收藏不是單純的書籤，它是 PickTrip 了解我旅行喜好的第一層資料。

沒錯。 接著，當你要規劃東京行程時，你可以從收藏庫挑幾個東西丟進去， 像幾個餐廳、朋友分享的 Travel Pack、幾個必去景點。

AI 就可以把它們整理成一份行程。 Luna: 那 AI 不只是生成文字，它是在把我的收藏、 偏好、旅伴需求，變成真的可以走的 itinerary。

對，而且這裡還有多人旅行最麻煩的部分。 今天如果是四個朋友去東京，每個人的旅行人格不一樣。 有人喜歡美食，有人想拍照，有人想買東西，有人怕走太多路。

AI 要做的不是給出最熱門的清單，而是把這幾個人的偏好調和成一趟能一起完成的旅行。 Luna: 這聽起來比「幫我排五天東京行程」難很多耶。

因為它要處理人的衝突。

對，所以 PickTrip 需要使用者畫像。 剛開始可以用旅行人格測驗，比方說你是美食探索型、鬆散漫遊型、 效率打卡型，這是一個很粗的起點。

之後真正有價值的是行為資料：你收藏什麼、你刪掉什麼、你最後去了哪裡、 你旅途中打開什麼功能、你回來後分享了什麼。

Luna: 這樣 AI 才會越來越像懂我的旅伴，而不是每次都重新問我「你喜歡什麼風格」。

正是如此。 然後行程排好以後，下一步是 Commerce，也就是把行程變成可以下單的東西。 Luna: 這就是之前提到的「可預訂行程」？

對。 一般旅遊 app 可能是你先買票、訂飯店，再把資訊手動塞進行程。 PickTrip 想反過來：你先有一個行程，系統知道哪些地方需要票、

哪些天需要飯店、哪段需要交通、是不是要 eSIM 或接送。 然後它把這些可購買項目整理成購物車。

Luna: 所以行程表會標示哪些東西已經買了、哪些還沒買。 到景點時，我點開那個景點，就能看到票券，甚至直接使用。

對。 還有一個很務實但很重要的細節：checkout 表單。 訂機票、飯店、票券常常都要填護照、生日、電話、email。

PickTrip 如果真的要節省時間，就不應該讓主揪每個表單重填一次。 Luna: 天啊，這個我超有感。

幫朋友買票的時候，問護照名字、生日、電話，問到快崩潰。

所以 PickTrip 可以把旅客資料做成一次填寫、多處預填。 資料有授權、有最小化、有可刪除。

旅伴如果缺資料，就發一個連結讓他自己補，不需要主揪一直當表單機器。 Luna: 那你剛剛說票券還有一個缺口？

對，分票。 現在可以先讓大家查看票券，或由主揪管理全部票券。 但未來如果要更完整，就應該支援分票、轉交、誰持有哪張票、 誰還沒確認。

這會直接影響多人旅行的真實使用。 Luna: 好，規劃和購買都講完了。 那旅行中呢？ 很多 app 出發後就沒用了，行程表最後只剩截圖。

這正是 PickTrip 想突破的地方。 旅行中，行程應該變成 live surface。 互動地圖會顯示景點位置、自己的位置、朋友的位置，還可以設定集合點。

Luna: 我懂！ 尤其多人旅行，大家很常在車站或商場走散。 你傳 LINE 說「我在那個門口」，結果對方根本不知道是哪個門口。

對，集合點就是官方 MiniApp 的好例子。 MiniApp 可以想像成旅程裡的小工具，有點像 Apple Shortcuts 或 Chrome extensions，

但它是針對一趟旅行安裝的。 Luna: 所以 MiniApp 不是單純 widget， 它可以讀取這趟 trip 的 scope，例如地圖、成員、 位置、訂單、行程？

對，但前提是權限要清楚。 它可以做分帳，可以做投票，可以做城市尋寶，也可以在地圖上疊加任務點。 未來甚至可以讓 AI 幫你產生一個小工具。

比如你跟朋友去京都，AI 幫你做一個「拉麵投票 MiniApp」或「神社集章 MiniApp」。

Luna: 這就很有趣了。 它把旅行從一張計畫表，變成一個大家一起玩的空間。

另外一個官方 MiniApp 是旅行相機。 這個功能的意義也不只是拍照。 它會把照片綁到行程裡的景點或活動上，同時存到手機相簿，也能讓朋友在共享相簿裡看到。

Luna: 所以回來以後，我不是只有一堆散在手機裡的照片， 而是可以看到「這張是在淺草那個下午拍的」、「這張是在某個餐廳拍的」。

對。 這讓 itinerary 從事前規劃工具，變成事後回憶容器。 旅行結束後，它就有機會被整理成 Journal 或 Travel Pack。

Luna: 現在閉環開始出現了。 靈感進收藏，收藏加上 AI 變行程，行程變購物車，旅行中用地圖、 MiniApp、相機，旅行後變回憶，回憶再變 Travel Pack 分享出去。

這就是核心 loop。 然後 Travel Pack 分享出去之後，其他人看到， 可能先保存，之後複製成自己的行程，再透過 PickTrip 下單。

平台可以從交易抽佣，創作者可以被 attribution， 未來才有分潤的可能。 Luna: 所以商業模式不是「賣內容」，而是「讓被驗證過的旅行經驗帶來下一次交易」。

很好，這句話抓到重點了。 Luna: 那問題來了。 這麼完整的閉環，聽起來要做超久。 我們現在到底要先驗證什麼？

這裡要分順序。 第一階段不是直接找一堆人發 Travel Pack，也不是馬上衝 B 端。 第一階段應該是內部 dogfood，也就是團隊自己跑完一趟標準任務。

Luna: 像你們之前說的東京五天四人自由行？

對。 任務應該很具體：從收藏或 Travel Pack 開始， 讓 AI 排出東京行程，邀請朋友加入，標示已買未買，跑一次購物車和 checkout mock，

旅途中用地圖和集合點，至少使用一個 MiniApp，拍幾張旅行相機照片， 最後把這趟旅程整理成 Travel Pack 分享出去。

Luna: 也就是說，團隊自己要先證明這條路走得通。 不是畫流程圖覺得合理，而是真的每一步都能完成。

對。 這個 dogfood 是第一個里程碑。 它的成功標準不應該是「畫面好不好看」，而是任務能不能不靠工程師現場救火就完成；

每一步有沒有明確阻塞； 哪些是必修，哪些可以延後。 Luna: 那 dogfood 過了之後，就分成 B 端和 C 端兩條線？

沒錯。 B 端驗證的是：行程編輯器能不能成為專業交付工具。 目標對象可能是旅行社、公司旅遊承辦、活動 PM、企業行政、 秘書。

尤其像秘書幫董事長或主管排行程，她需要的是快速整理機票、 飯店、會議、交通，最後分享一個可更新的連結給對方。

Luna: 還有商務出差的 VP，可能很在意會議、交通、 附件、票券、報銷，行程不能只是好玩，還要可靠。

對。 B 端看的是效率、版本、交付和信任。 比 Excel、PDF、LINE 更快嗎？ 客戶或主管打開連結能看懂嗎？

修改後不用一直重傳檔案嗎？ 對方願不願意拿下一個真實案子試用，甚至付 pilot fee？ Luna: 那 C 端呢？

C 端有三條驗證線。 第一條是 Travel Pack 傳播：自己先做幾份高品質 Travel Pack， 再找 micro creator 或旅遊創作者使用和分享，

觀察點擊、保存、複製、建立行程、邀請朋友和下單意圖。 Luna: 第二條應該是多人旅行中體驗？

對。 找正在規劃或即將出發的朋友團，讓他們真的在旅行中打開地圖、 設定集合點、用 MiniApp、用旅行相機。

這裡看的不是下載數，而是旅行中是否自然打開。 Luna: 因為如果出發後沒人打開，那再多功能都只是 demo。

正是。 第三條是回憶和留存。 旅行結束後，他們會不會回來看共享相簿？ 會不會把照片和路線整理成 Travel Pack？

會不會分享給下一組人？ Luna: 聽起來 PickTrip 的北極星指標也不能只是 DAU 或 GMV。

我會建議看「每月完成的共同旅程數」。 也就是至少兩個人共同參與、旅途中至少有實際打開、最後完成的一趟 trip。

因為 PickTrip 最核心的承諾，是讓一群人更容易一起完成一趟好旅行。 Luna: 這比單純看 Travel Pack 發布數更準。

因為一個 Travel Pack 發出去但沒有人真的用， 其實不代表產品成立。

對。 當然底下還是要拆漏斗。 C 端看 view、save、copy、created itinerary、 friend invited、cart created、

checkout、map open、meeting point、 camera use、Travel Pack publish。

B 端看 meeting booked、time to first itinerary、 client opens、revision、approval、

quote accepted、second itinerary、 paid pilot。 Luna: 我覺得今天這集最重要的提醒是：不要被最酷的功能牽著走。

Travel Pack 很酷，MiniApp 很酷，旅行相機也很酷， 但它們都要服務同一個閉環。

對。 PickTrip 真正要驗證的不是「使用者會不會喜歡某個功能」， 而是這些功能串起來後，能不能讓旅行從靈感、規劃、購買、同行、 回憶到分享，形成一個會自己轉動的循環。

Luna: 那如果要用一句話總結今天這集，我會說：PickTrip 不是要做一本更聰明的旅遊攻略， 而是要讓一趟真實旅行，變成可以被協作、被購買、被體驗、被記錄，

最後被分享和再利用的資產。

說得很好。 下一集我們就可以接著聊更落地的問題：第一批使用者到底去哪裡找？ Reddit、Threads、小紅書、旅遊創作者、旅行社、

企業行政，這些渠道要怎麼測，才不會只是發文碰碰運氣。 Luna: 好期待！ 那今天就先到這裡。 你正在打造旅行產品，或只是很喜歡看一個產品怎麼從想法長成系統，

都歡迎繼續跟我們一起追蹤 PickTrip 的建造過程。 我們下週同一時間再見囉！

掰掰！