PickTrip建造術：狗糧開飯前夜——一夜二十三版，風險清單消掉兩條半

Summary

dogfooding 開跑前夜，團隊再度通宵：Web 前端一夜連發二十三版（1.0.23→1.0.45）。風險清單盤點：貨幣顯示混亂三端收官——後端刪除舊制「元」欄位（破壞性變更，線路上只留最小單位整數＋顯示小數位），iOS 與 Web 訂單/機票頁同日對齊，並挖出 DIDA 搜價硬編碼美金、丟棄回傳幣別的潛在雷，先埋 echo-diff 探針驗證潛伏或已發作；「iOS 與 Web 行程對不上」判定為兩端連到不同後端環境，非同步 bug，清單端點補決定性排序、Web 一次載全。前端效能大票清晨六點十八分關閉，收尾是十三批 BFF 邊界 zod 驗證，替 dogfooding 期間的爛資料買保險。Mini App 平台落實 TREK 建議：開發者入駐＋高風險權限審查閘、官方小工具包真 R2 上傳、QR/連結安裝 UI 開工。行程引擎長出「減少不確定性」第一塊實體：假日休館與國家精準 grounding，另加 shown-but-not-booked 品質軟規則與 eSIM 節點（DAG 37、旗標關）。未消風險：iOS 可用性半條、票券帳號仍鎖。

Transcript

歡迎回到 PickTrip 產品建造筆記。 昨天結尾我們留了兩個問題：dogfooding 第一天跑得怎麼樣？

風險清單消掉幾條？ 今天先老實交代第一題：dogfooding 是今天白天才正式開跑， 所以答案要明天才有。

但第二題，今天有很多可以報告的——因為團隊昨晚又通宵了。

Luna: 又通宵？ 前天才一夜關五張票欸。 這次的戰果是什麼？

先給一個數字感受一下強度：Web 前端從昨天傍晚到今天清晨， 連續部署了二十三個版本，版號從 1.0.23 一路跳到 1.0.45。

平均下來大概每十幾分鐘就上線一版。

Luna: 二十三版？ 這是在衝什麼？

衝的就是那張風險清單。 我們一條一條盤。 第一條，貨幣顯示混亂——就是上上集講的，飯店價格日幣台幣打架、 小數點亂跳，甚至出現過 NT$15 跟幾千萬這種離譜數字。

這一條今天可以宣布：收官。

Luna: 怎麼收的？

三端一起動手術。 先把事情講簡單：問題的根源是系統裡有兩套價格表示法——一套用「元」當單位， 一套用「分」這種最小單位的整數。

兩套並存，誰讀錯一次就是一百倍的災難。 這次的修法是釜底抽薪：後端直接把舊的「元」欄位從傳輸格式裡刪掉， 這是破壞性變更，從此線路上只剩「最小單位整數加顯示小數位數」一種表示法；

iOS 把所有讀價格的地方對齊新契約； Web 的訂單頁跟機票報價頁也完成遷移。 三端同一天切換完。

Luna: 直接刪欄位，這很敢欸。 不過我喜歡，留著舊欄位就永遠有人會誤用。

對，這就是「讓錯誤變得不可能」的做法。 但真正關鍵的是，調查過程還順藤摸瓜挖出一顆雷：跟飯店供應商 DIDA 對接的搜價程式，

寫死了「對方一定用美金報價」，還把對方真正回傳的幣別欄位整個丟掉。

Luna: 等一下，如果 DIDA 哪天對台灣的飯店回台幣， 我們卻當美金算——那價格不就直接錯三十倍？

就是這個風險。 目前還不確定它是「潛伏」還是「已發作」，因為理論上我們請求時有指定美金， 對方可能真的照辦。

所以團隊放了一個探針進去：每次搜價都比對「我們要求的幣別」跟「對方實際回的幣別」， 一旦不一致就記下來。

等資料說話，再決定要不要動匯率重構。 這開成了一張獨立的票追蹤。

Luna: 我欣賞這個節制，沒有直接大改，先驗證假設。 好，風險清單第二條呢？

第二條有意思了，它本來不在清單上，是昨天新爆的：有使用者發現， 同一個帳號，手機 App 看到的「我的行程」跟電腦網頁版完全對不上， 手機上有一趟進行中的東京五日，電腦上根本沒有。

Luna: 這聽起來超嚴重，行程消失是旅行產品的大忌。 是同步壞掉了嗎？

排查的結論恰恰是：這不是同步 bug。 再往下看一層——兩端打的是同一個清單端點，同一個帳號在同一個後端上， 清單不可能不一樣。

既然不一樣，唯一的解釋就是兩端連的根本不是同一個後端。 系統目前有正式環境跟另一個環境，iOS 跟 Web 各連各的， 資料自然是平行宇宙。

Luna: 哇，所以使用者以為的「沒同步」，其實是「兩個世界」。

對。 順著這條線，清單本身也修掉兩個坑：清單端點的排序原本不保證穩定， 同一批資料兩次回來順序可能不同；

Web 端還只載第一頁。 現在排序改成決定性的，Web 也改成一次把所有行程載回來。 這張票當天開、當天關。

Luna: 那二十三個版本裡剩下的呢？ 總不會都是這兩件事。

剩下的主力是一個收尾：前端效能與最佳實踐的那張大票，今天清晨六點十八分正式關掉。 上一次衝刺我們報過戰果——首頁 JS 減四成二、訂單頁減七成八。

昨晚做的是最後一段，而且性質不太一樣：不是讓網站更快，是讓它更難被弄壞。

Luna: 「更難被弄壞」？

團隊把 Web 跟後端之間那層轉接層的每一個入口，分十三批全部裝上了資料驗證。 任何進來的請求，先過一道格式檢查：欄位缺了、型別錯了、多塞了奇怪的東西，

在邊界就被擋下來，回一個清楚的錯誤，而不是讓爛資料流進系統深處， 炸在看不懂的地方。

Luna: 為什麼挑今天做這個？ dogfooding 前夜欸。

正因為是前夜。 全團隊明天開始真人真用，一定會用出各種奇怪姿勢。 爛資料早死早超生——在邊界擋下來，錯誤訊息是「這個欄位格式不對」；

流進去才炸，錯誤訊息是天書。 這是替接下來六天的除錯效率買保險。

Luna: 合理。 那昨天偵察報告的後續呢？ 四條行動建議，有動靜了嗎？

有，而且快得驚人。 第三條建議說：mini-app 開放第三方之前，拿 TREK 的安全設計當檢查清單。

今天後端就上了兩塊：開發者入駐流程，以及「高風險權限審查閘」——第三方小工具如果要的權限碰到敏感範圍， 不會自動放行，要先過人工審查。

這就是 TREK 那套「擴權必須重新同意」的思路，開始長進我們自己的平台。

Luna: 可發現性那個教訓呢？ 「裝了卻找不到」的反面教材。

也在動。 市集目錄的小工具圖示今天修好了，官方小工具包上了真正的雲端儲存， 而且 QR code 跟連結安裝的介面已經開工——這個同時也是例會的決策， 讓使用者掃個碼就能裝。

另外團隊還開了一張票，把驗證期間發現的平台缺口都記下來， 比如有個待辦事項權限宣告了卻沒有對應的資料通道，官方待辦小工具只能降級運作。

缺口不怕有，怕的是沒人記。

Luna: 好，還有一塊我猜是行程引擎？ 後端好像一直有動作。

對，這塊要接回第五集講的方向轉折：PickTrip 的價值不在排得像， 在減少旅途的不確定性。 當時說這是 demo 之後的第二輪，但管線今天已經長出第一塊實體： 假日休館。

行程引擎現在會知道一個景點在特定日期不開門——比如國定假日、 季節性關閉——而且判斷開放時間時會先精確定位景點在哪個國家， 不會拿錯國家的假日去算。

Luna: 龜山島幾月開放登島，就是這類問題吧？ 例會裡用戶真的問過。

正是同一族。 另外還有幾個管線升級：品質閘門加了一條軟規則，專門盯「AI 給使用者看過、 但最後沒訂」的項目；

eSIM 的供應節點也插進了管線——三十七個節點的流程圖又長了一格， 不過目前旗標關著，還沒對使用者開。

行程引擎正在從「排景點」往「旅途中所有會出錯的事」擴張。

Luna: 那 iOS 呢？ 風險清單第三條可是「iOS 前端暫不可用」。

iOS 昨天有兩筆：一筆是把機票預訂的流程針對 dogfooding 加固， 一筆是價格契約對齊。

誠實說，這條風險只能算「部分修復中」——接線問題還在清單上。 然後第四條，票券帳號被鎖，今天的紀錄裡完全沒有動靜，它還掛著。

而且別忘了，之前會議說過下週送審前票券流程必須可用，這條的引線其實不長。

Luna: 幫大家結算一下：貨幣，消掉，還附送一個監聽器； 兩端行程不同步，消掉； iOS，半條；

票券帳號，原地未動。 四條消了兩條半。

以一個通宵來說，我覺得可以打個好分數。 而且地基類的工程——資料驗證、貨幣契約、環境釐清——都是在替接下來六天鋪路。

Luna: 好，那明天真的要回答那個問題了：全團隊今天白天開始拿 PickTrip 排自己的旅行， 第一口狗糧吃起來到底什麼味道？

會不會第一天就吃出一堆蟲？

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

Luna: 掰掰！