PickTrip建造術：狗糧開飯第一口——訂購三大件全趴，行程引擎卻學會了自己開車

Summary

dogfooding 開跑，招牌閉環第一口就硬：訂購三大件全趴——票券入不了車、飯店房型載不出、機票搜尋失敗且去回程資訊缺失，全開高優先並立「單一供應商失敗不得拖累其他」的隔離驗收；eSIM 反而成模範生。產品缺口浮現，拍板做「獨立購買流程」，節奏是先修既有訂購頁再接 Web；iOS 當日落地購買體驗重設計規格＋Figma＋實作計畫，並修好來回機票購物車顯示。Mini App 可發現性迴力鏢——入口收回 Partner Dashboard；待辦缺口三倉庫連補（後端四端點重用即時同步、Web 與 iOS 橋接＋相容墊片），官方待辦小工具從降級變全功能。前端效能票「詐屍」加班：編輯器主檔 4400→2100 行純搬家、地圖與對話面板隔離重繪、zod 邊界推進到 15 批、三套待辦客戶端合一。貨幣第三章搬進 AI 管線（resolve_cart_currency＋resolve_party_mapping），順手修掉 TREK 點名的分帳金額錯誤、下架國籍原始值 PII。行程引擎 DAG 37→40、旗標仍關：best_value 自選飯店、author_trip_todos 自動行前清單、global-deadline 死線守門，把「減少不確定性」升級成自動駕駛；上線前靠「跑況健康守門」把關——一次 OpenRouter 額度凍結揭穿「死掉的流程假裝良性跳過」，重訂健康定義、死跑一律標紅絕不放行。進度條 40 步收斂成約 10 個多語階段、假日休館資料補齊；Travel Pack 加 JSON-LD 與 SSR 讓 AI 爬蟲讀得到。長會記帳：token 開銷要省、旅程共賞規格 Notion→Linear、外部合作與政府經費重評。風險清單：貨幣收官待驗、iOS 可用性半條往上一格、訂購供應商整包大票外加五張新票，demo 剩四天。

Transcript

歡迎回到 PickTrip 產品建造筆記。 昨天結尾我們留的問題很具體：全團隊開始拿 PickTrip 排自己的旅行， 第一口狗糧到底什麼味道？

這兩天可以回答了——有點硬，還吃出蟲； 但更重要的是，這兩天我們的行程引擎，長出了一顆自動駕駛的心臟。

先講味道。 dogfooding 開跑當晚，團隊開了一場二十八分鐘的盤點會， 會後追蹤系統一口氣多了六張票。

Luna: 六張！ 第一天就六張。 快說，吃出什麼蟲？

六張裡有一張是手滑開重複的，馬上標成重複票，實收五張。 但內容不輕，最大的一窩在訂購。 先把事情講簡單：PickTrip 的招牌是「從規劃到預訂的閉環」，

而 dogfooding 第一天，大家真的去按「訂」的時候， 發現三大件全趴——票券加不進購物車、飯店房型載不出來所以訂不了、

機票搜尋會失敗，就算搜到了，去回程跟轉機的詳細資訊也載不出來。

Luna: 等一下，這不就是我們的招牌菜嗎？ 行程排得再漂亮，最後一哩路按不下去，那不就是一本很會講話的旅遊雜誌？

對，所以這批票全開成高優先。 盤點時還挖出一個更陰險的疑慮：供應商之間可能互相拖累——某一家接口掛掉， 錯誤沒隔離好，會把其他家一起拉下水。

這條被寫進驗收條件：單一供應商失敗，不准影響其他供應商。 有趣的是，整桌菜裡活得最好的是 eSIM，它一切正常，直接被排除在修復範圍外。

Luna: 前天才把 eSIM 節點插進管線，今天它就變成模範生。 不過我更好奇那個「三大件全趴」後來怎麼了。

這個你一定要知道，因為迴力鏢兩天後就飛回來了。 今天 iOS 端上了一張修復：把來回機票在購物車裡的顯示穩住了——就是昨天那隻「去回程資訊載不出來」的蟲， 被正面打了一槍。

這是「修復引擎沒有停」最好的證據：問題昨天挖出來，今天就有第一塊補丁。

Luna: 好，這叫有始有終。 那昨天會議上還吵出一個方向對吧？ 我記得不只修蟲。

對，這是第二層發現：dogfooding 不只咬出 bug， 還咬出產品形態的缺口。 會議正式決定要做「獨立購買流程」——使用者應該可以像逛一般訂票網站一樣，

不先建行程、不先跟 AI 聊天，直接買票券、訂飯店，買完再決定要不要把商品掛回某個行程。 而這個決定，今天就不只是白板上的一句話了。

Luna: 喔？ 這麼快就動工？

今天 iOS 端進來一份「購買體驗重設計」的完整規格，附了 Figma 對照圖跟實作計畫。 但真正關鍵的是節奏決策：會議明確拍板，先修既有訂購頁的可用性，

再接網頁版的訂購流程，先讓現在的路能走，再開新路。 所以你看，決策、修復、規格，三天內排成一直線。

Luna: 這節奏我喜歡。 那 Mini App 呢？ 前幾天才講完 TREK 的教訓，「裝了卻找不到」是可發現性的反面教材。

這題迴力鏢正中自己後腦勺。 dogfooding 時大家發現：分享入口找不到。 QR code、深層連結明明做了，但開發者主控台上不能建立、 不能編輯、也不能分享。

決策是把入口統一收回 Partner Dashboard， 讓建立、編輯、分享、安裝在同一個地方發生。

不過要幫工程側說句公道話，Mini App 這條線這兩天打了一場漂亮的仗——還記得那個缺口嗎？ 待辦權限宣告了、卻沒有對應的資料通道，官方待辦小工具只能降級運作。

Luna: 記得，你還說「缺口不怕有，怕的是沒人記」。

記下來的缺口，被連補三刀，而且橫跨三個倉庫：小工具跑在沙盒 iframe 裡不能直接打網路， 只能丟訊息給宿主。

所以後端先開四個待辦端點，直接重用多人協作那套即時同步引擎； Web 的宿主橋接把方法接上端點；

iOS 的橋接也跟上，還順手上了相容墊片、附三百行測試。 三端合龍，官方待辦小工具從「降級運作」變成「全功能」。

Luna: 一天打通三個倉庫，這應該是我們跨端合作最快的一次吧。 那昨天的另一個主角呢——那張前端效能大票，你可是親口宣布「清晨六點十八分正式關掉」。

呃，關於這件事……它詐屍了。 宣布關掉之後，票號下面又默默追加了一整天的工，加的都是好東西。 最大的一件是動手術：行程編輯器的主檔案長到四千四百多行，

這次拆成兩千一百多行加一疊獨立元件，主函式逐位元不變——純搬家、 零行為改動。 拆完才能做第二件事：隔離重繪。

原本你在編輯器裡做任何小動作——掃過一個景點、打一個字、 開關面板——最重的那塊地圖都會整張重畫，AI 對話面板也陪跑；

現在兩者都被包進記憶化的邊界，只有相關資料變了才重繪。 打字歸打字，地圖是地圖。 收尾兩件：邊界資料驗證從十三批推進到十五批；

另外掃出一個歷史共業——同一個「待辦事項」竟有三套客戶端實作， 這次合併成一個共用模組。

Luna: 好，效能票安息。 那後端呢？ 貨幣那條線，前天收官、昨天埋探針，該不會又有第三章？

有，而且第三章的舞台換了——從顯示層搬進 AI 管線。 行程管線的圖上多了兩個節點：一個叫「解析購物車幣別」，AI 準備下單時用決定性的規則決定這一車該用什麼幣別結算，

尊重使用者的偏好幣別，跟整個工作階段保持一致； 另一個叫「解析旅客對應」，把「誰買、買給誰」翻譯成供應商要的旅客名單格式。

這也順手還了 TREK 那份報告點名的最大缺口——分帳， 這一輪修掉了一整排「誰付誰分」的金額計算錯誤。

Luna: 也就是說，之前的貨幣課是「別把日幣當台幣顯示」， 現在是「AI 自己買東西的時候也不能算錯錢、不能分錯帳」。

這門課從櫃檯一路教到了倉庫。

而且教材裡還有一頁隱私：這些節點會記遙測方便除錯，這次特別把「國籍」的原始值從事件裡拿掉， 只留一個「這資訊從哪來」的標記——除錯需要知道來源，不需要知道你是哪國人。

但真正關鍵的是，這兩天這條管線不只在修 bug，它學會了自己開車。

Luna: 自己開車？ 你是說那個一直掛著「旗標關」的行程引擎？

對。 記得前天它還是三十七個步驟、旗標關著。 這兩天長到了四十步，多出來的三步，每一步都是在把「幫你排」升級成「幫你決定」。

第一步，AI 現在會自己挑「最超值」的飯店，不是列一排丟給你， 是按策略選一間。 第二步，它會自動生出一份「行前待辦清單」——這趟要辦的簽證、

要準備的東西，行程排完就順手幫你列好，而且是決定性規則產生的， 不交給小模型亂寫。 第三步最像安全帶：裝了一個「全域死線」守門員，哪個環節卡住太久， 整趟自動中止，不讓它無限空轉。

Luna: 等等，這不就是我們一路在講的「減少旅途不確定性」長出實體了嗎？ 從前天的假日休館、eSIM，到今天會自己選房、自己列清單。

而且我猜——旗標還是關著對吧？

你很懂。 旗標還關著，因為自動駕駛上路前要先過安全檢查，而這兩天最硬的一仗， 就是把「安全檢查」本身修得夠誠實。

這叫「跑況健康守門」，前天我們聊過測試的「閘門誠實度」——跳過就明說跳過， 不准裝成綠燈。 今天它升級了：一次 OpenRouter 額度凍結，讓一個真正「跑死了」的流程露了餡。

Luna: 跑死了還能裝沒事？

這就是陰險的地方。 管線一開場會先建一個空行程殼，所以後面某步當場崩了，那個殼還在、 還帶著行程編號。

舊檢查一看「有行程編號欸」，就把死掉的流程判成「良性跳過」——跟真的「這條腿沒票、 正常沒成交」混在一起，就可能矇混過上線資格的閘門。

修法很硬：重新定義「健康」——終點得是真的「行程完成」， 或真的在問你問題、真的在等你重新確認價格；

除此之外，錯誤遮罩、缺終點、串流中斷，一律判成「這趟跑死了」， 直接標紅、去查，絕不放行。

Luna: 「一個死掉的流程不准假裝成跳過」，這句跟前天那句「跳過不等於通過」應該裱起來， 並排掛在測試機房。

這兩句其實是同一個信念的兩面：上線資格要靠真的綠燈掙來， 不能靠灰色地帶偷渡。 管線這兩天還做了兩件貼心事：把原本四十步的進度條收斂成大約十個看得懂、 還會翻譯成各國語言的階段；

也把「假日休館」那份資料補齊了一批。 給機器看的那一面也沒閒著——Travel Pack 公開頁面除了把行程用結構化資料標出來給 AI 爬蟲讀，

這次還讓行程直接寫進網頁原始碼，不用等瀏覽器跑完才看得到。

Luna: 這我懂，這是做給機器看的菜單。 二〇二六年的新常識：你的頁面不只要 Google 收錄， 還要讓各家 AI 助手引用得到——使用者現在是問 AI「幫我排東京五日遊」，

不是自己翻搜尋結果。 欸對了，我看會議記錄這兩天整理出好幾份，有沒有什麼要補進帳本的？

有三條值得記。 第一，AI 的 token 開銷太高，要開始省——對一個每天真金白銀跑管線的產品， 這是生存問題。

第二，「旅程共賞」的需求規格從 Notion 搬到了 Linear， 以後以 Linear 為準——規格搬家最怕開發者讀到舊版， 這條被特別標成風險。

第三，外部合作跟政府經費的資格要重新評估。 好，收尾照慣例，結算風險清單。 貨幣：顯示層收官、探針還在聽，長會特別要求「修了要驗證」， 所以我給它「收官待驗」。

iOS 可用性：從半條往上動了一格——來回機票的購物車顯示修好了， 還進來一份購買體驗重設計規格，可用性這條總算有新進度。

票券帳號被鎖：它沒解鎖，反而長大了——整包升級成「訂購供應商功能異常」大票， 票券、飯店、機票全在裡面。

Luna: 所以清單是：貨幣收官待驗、iOS 從半條往上一格、 訂購供應商一大條，外加新進貨五張票。

呃，這樣算下來，清單是變長了吧？

變長了，但我認為是好消息。 dogfooding 的意義本來就不是證明產品沒問題，是趕在使用者之前把問題挖出來。

第一天就挖出訂購三大件，總比 demo 當天在台上發現好。 何況這兩天 Web 端版號從一點零點四六一路跑到一點零點五五， 行程引擎還學會了自己開車——修復跟進化的引擎，都沒有停。

Luna: 也對，蟲抓出來才有得修，車學會開才有得上路。 那接下來的問題很明確了：dogfooding 繼續跑，訂購三大件能搶修回來幾件？

那顆自動駕駛的心臟，什麼時候敢把旗標打開？ 還有——demo 只剩四天了喔。

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

Luna: 掰掰！