PickTrip建造術：把競品整台拆開——TREK 深度解剖報告

Summary

本集是一趟偵察任務：demo 倒數之中，團隊把開源自架的競品 TREK 拆到原始碼層級，產出二十多頁的調查報告。三大發現：訂位是純紀錄型、但「確認信丟進去自動變成行程＋地圖釘＋帳本」的 AI 匯入鏈非常聰明；Splitwise 式分帳（付款人與分攤者分離、貪婪演算法結算、記帳當下凍結匯率）是 PickTrip 最明確的功能缺口；Addon 與 Plugin 其實是兩套系統，plugin 的沙盒信任邊界（獨立行程四層隔離、宣告式權限、擴權需重新同意）做得極紮實，但「裝了卻找不到」是可發現性的反面教材。結論：旅程管理完整度我們落後、AI 體驗與商務閉環我們領先一個世代。四條行動建議：做分帳、把自購上傳升級成 AI 訂位匯入、mini-app 開放第三方前拿 TREK 當安全 checklist、評估開放 MCP。

Transcript

歡迎回到 PickTrip 產品建造筆記。 昨天說好 demo 倒數要每天陪大家看，不過今天這一集先不報衝刺進度， 要講一個不太一樣的任務——偵察。

團隊今天把一個競品整台拆開來看，一路拆到原始碼、拆到資料庫裡的每一張表。 Luna: 等一下，怎麼有辦法拆到原始碼？

競品不是都只能從外面看嗎？

因為這個對手是開源的。 它叫 TREK，一個「自己架伺服器」的協作旅行規劃器，程式碼全部公開在 GitHub 上。

今天我們派了四個研究 agent 平行去讀它的程式碼和官方文件， 每一條結論都對到具體的檔案和行號，最後整理成一份二十幾頁的 PDF 報告。

這一集就是把報告裡最重要的發現講給你聽。 Luna: 先問最基本的：它跟 PickTrip 是同一種東西嗎？

定位幾乎是鏡像。 先把事情講簡單：TREK 是一個工具箱——你在自己家的伺服器上跑一個 Docker， 行程、記帳、打包清單全部存在自己家，主打「你的資料、你的伺服器」。

但它完全沒有商業功能：不能訂飯店、不能買票、沒有金流。 PickTrip 是反過來的：AI 幫你把行程做出來，然後直接在裡面訂到好。

Luna: 它不能訂票？ 那它介面上那些機票、飯店是怎麼回事？

這是第一個發現：純紀錄型。 你自己去訂房網、航空公司訂好，回頭把結果記進 TREK。 但真正關鍵的是，它把「記錄」這個動作做得非常聰明——你把訂房確認信、

機票 PDF、甚至 Apple Wallet 的票卡整包丟進去， 它先用一個結構化解析器去讀，讀不出來的才交給 AI 解析，

而且解析出來的訂位會自動掛到行程的日期上、自動在地圖上長出一根圖釘、 有價格就自動記進帳本、原始檔案還自動掛回訂位當附件。

一封確認信丟進去，行程、地圖、帳本三個地方同時就緒。 Luna: 這個聽起來……我們是不是也該有？

使用者自己訂的高鐵、自己訂的民宿，現在在 PickTrip 的行程上就是一片空白吧？

對，這就是報告裡的行動建議之一。 我們現在有「自行上傳票券」，但只是存檔案； 把它升級成「丟給 Pika，自動變成行程上的結構化項目」，

我們本來就有現成的 AI 管線，做這件事其實比 TREK 還順手——它得靠一個外部解析器加選配的模型才拼出這條流程。

Luna: 好，第二個發現？

分帳。 TREK 有一套完整的、類似 Splitwise 的旅行分帳： 誰付錢、誰分攤是兩件分開記的事，所以「A 一個人刷卡、三個人平分」這種情境天生就能表達。

分攤有平均分、自訂金額、逐項目分三種模式； 旅程結束按一顆「結算」，系統用貪婪演算法算出最少的轉帳次數——誰該轉多少給誰， 一目了然。

Luna: 貪婪演算法這個詞，幫聽眾翻譯一下？

把每個人的淨額算出來之後，欠最多的跟被欠最多的先配對沖銷， 沖掉一個換下一個。 不是數學上絕對最優，但對一團十個人以內的旅行已經接近最優， 而且實作簡單。

另外有個細節我很欣賞：記帳當下就把匯率凍結寫進資料庫，之後匯率再怎麼跳， 已經結清的帳不會冒出尾差——這是他們踩過真實的 bug 之後改出來的設計。

Luna: 這一整塊，我們完全沒有，對吧？

完全沒有，這是報告認定我們最明確的功能缺口。 而且你想，行程規劃一趟旅行用一次，記帳是旅途中每天都會打開的東西——黏著度完全不是同一個量級。

好消息是它的資料模型可以直接參考，我們不用重新發明。 Luna: 好，那重頭戲呢？ 今天花最多力氣調查的，是它的外掛系統。

對，這也是整份報告最厚的一章。 先講一個關鍵澄清，不然一定混淆：TREK 有兩套名字很像、 但完全不同的系統。

一套叫 Addon——官方內建十二個功能模組的「開關」， 記帳、旅誌、去過國家的地圖都在裡面，管理員一鍵開關，但不能安裝新的。

另一套才叫 Plugin——第三方開發者寫的外掛，有開發套件、 有一個叫 Discover 的商店目錄、可以上傳安裝。

Luna: 所以如果有人在 Addon 那一頁找「安裝」按鈕， 本來就不存在？

正是。 而且我們實際玩它的時候真的撞到一個困惑：裝了一個 plugin， 卻找不到它顯示在哪裡。

調查完發現，這不是 bug，是設計。 每個 plugin 要宣告一個類型，類型決定它唯一會出現的位置：

儀表板的小卡片、獨立頁面、行程裡的分頁——還有一種叫 integration 的類型， 官方文件白紙黑字寫著「Nowhere visible」，

本來就沒有自己的畫面，只在特定條件成立時，在既有畫面裡留一點痕跡， 像行程頂端多一條健檢警告。 再加上：安裝完預設是關閉的，要再手動啟用；

手機版的導覽列根本沒有給 plugin 留入口。 幾個原因疊在一起，「裝了卻看不到」反而是最正常的結果。

Luna: 這對我們是一記警鐘吧？ 我們自己也有 mini-app 小工具。

這正是我接下來要說的。 但先講它做對的地方，因為底層做得非常紮實：每個 plugin 的後端程式碼跑在一個完全獨立的行程裡，

環境變數白名單、作業系統層級的檔案權限、對外連線白名單加防資料滲出， 一共疊了四層隔離； 前端則關在一個完全隔離的 iframe 裡，拿不到登入憑證。

權限是宣告式的——沒被授權的能力，對 plugin 來說「根本不存在」， 不是「呼叫了被擋下」。

更新版本如果想要更多權限，一定要管理員重新點頭，不能靜默擴權。 每一次資料存取還記進一條防竄改的稽核鏈。

Luna: 聽起來像自己蓋了一座小型的 App Store 信任體系。

就是這個意思。 所以報告對這一章的結論是兩面的。 架構上——如果哪天 PickTrip 的 mini-app 要開放第三方開發者進來，

TREK 等於把整份「信任邊界怎麼設計」的參考答案開源給我們抄， 連每個安全決策的理由都寫在程式註解裡。

體驗上——它是反面教材：架構深度沒有換來可發現性，使用者裝完最直接的感受是「咦， 東西呢？ 」我們做 mini-app 就要反著來：裝完立刻在地圖上看得到、

有清楚的空狀態、手機是一等公民。 Luna: 它還有一個 MCP 是什麼？ 跟外掛是同一件事嗎？

不是，這也是常見誤會。 MCP 是讓使用者拿外面的 AI 助理——比如 Claude Desktop——直接連上自己的 TREK 帳號去建行程、 記帳。

它跟外掛系統是兩套完全不相干的機制。 TREK 自己不做對話式 AI，它選擇把介面開放給別人的 AI。

這個策略我們可以評估：PickTrip 有自己的 Pika， 但額外開一個 MCP 端點，讓使用者慣用的 AI 工具也能操作行程， 是成本不高的曝光面。

Luna: 最後總結一下吧。 拆完這一整台，我們跟它到底誰強？

分領域講。 旅程管理的完整度——分帳、訂位收納、打包清單、天氣、匯出——它全覆蓋， 我們差距明顯，這些是黏著度功能。

AI 體驗——它沒有第一方的 AI 規劃，我們領先一個世代。 商務閉環——它的開源自架模式結構上就接不了供應商和金流， 這是我們的護城河。

擴充架構——它深我們淺，但答案是公開的，追趕成本主要是工程時間。 Luna: 所以這趟偵察的產出，就是四條行動建議？

對。 第一，做分帳，資料模型直接參考它。 第二，把自購票券上傳升級成 AI 訂位匯入。 第三，mini-app 開放第三方之前，拿它的安全設計當檢查清單， 同時記取它可發現性的教訓。

第四，評估開放 MCP。 完整的 PDF 報告今天已經發給團隊了。 Luna: 好，偵察結束，明天回到倒數。

dogfooding 第一天到底跑得怎麼樣？ 昨天那張風險清單消掉幾條了？ 明天就知道。

明天同一時間，PickTrip 產品建造筆記，每日更新。 Luna: 掰掰！