PickTrip建造術：Demo 倒數七天，一夜關五張票的衝刺實錄

Summary

本集起節目轉為每日更新。深夜例會釘死七月節奏：7/7 功能修到可用、7/8–13 全團 dogfooding、7/14 demo、八月自 Web 上線；真實用戶與可樂旅遊的測試訊號浮現，價值主張從「排得像」轉向「減少旅途不確定性」，browser agent 代辦排入第二輪。工程端一夜關五張票：P0 住宿消失與交通時間錯亂修復（住宿占位卡＋程式決定性重算）、Deepgram 中文誤判成韓文根治（辨識參數改由後端擁有）、共享相簿 API 完成並解鎖 iOS 旅程相機接力、Web 效能工程收官（首頁 JS -42%、訂單頁 -78%）、Mini App deep link/QR 四小時交付。Demo 前風險清單：貨幣顯示混亂、iOS 前端暫不可用、票券帳號被鎖。

Transcript

大家好，我是 Kai。 開始之前先跟大家報告一個節目本身的變化：從這一集起，PickTrip 產品建造筆記改成每日更新。

我們每天會把過去二十四小時裡這個產品真實發生的事——程式碼、 決策、會議、踩坑——整理成一集給你。

Luna: 每日更新耶，這對節目是很大的承諾。 不過我覺得時間點選得很妙，因為上一集我們才聊完「第一批使用者到底去哪裡找」， 結果我翻了一下這一天的紀錄，欸，使用者好像真的開始出現了？

對，這就是今天的第一條線。 先講大局：昨天深夜團隊開了一場例會，一路開到今天凌晨。 這場會把整個七月的節奏釘死了：七月七號，也就是今天，所有功能要修到可用；

七月八號到十三號，全團隊帶著產品去 dogfooding； 七月十四號 demo； 目標八月從 Web 正式上線。

Luna: 等一下，dogfooding 就是團隊自己當使用者， 真的拿產品去排自己的旅行？

對，自己吃自己的狗糧。 而且會議裡已經有真實用戶回饋進來了：有人用 AI 重排了一趟基隆到宜蘭的行程， 結果跟他自己排的相當接近，體驗不錯。

另外商務端也出現訊號——可樂旅遊的特助表示可以幫忙找用戶來測試。 Luna: 這不就是上一集講的兩條路嗎？

C 端找真實旅行者，B 端找旅行社。 策略才講完，第一批訊號就到了。

沒錯。 但這場例會最值得講的，其實是一個方向性的轉折，而且起點正是那句稱讚。 用戶說「AI 排的跟我自己排的差不多」——這聽起來是好消息，

但你多想一層，就會發現一個問題：既然差不多，我為什麼需要你？ Luna: 對欸，「排得像」是稱讚，也是警告。

這代表排行程本身可能不是護城河。

團隊前幾天其實已經在會議裡算過帳：單純轉售行程的利潤可能不到百分之五， 連 AI 的成本都很難蓋掉。

所以這次例會把價值主張重新講了一次：PickTrip 的價值不在「排得像不像」， 而在減少旅途中的不確定性。

比如你要爬山，找得到登山嚮導嗎？ 龜山島現在開放登島嗎？ 這種問題才是旅行者真正卡住的地方。 技術上，他們打算用 browser agent 讓 AI 真的去查、

去代辦，這條線排在 demo 之後的第二輪。 Luna: 好，大局講完了。 那第二條線呢？ 我看你筆記上寫著「一夜關五張票」，這是什麼衝刺夜？

這是工程端的故事。 從昨天深夜到今天清晨，團隊在 Linear 上一口氣關掉五張票， 三個程式庫加起來超過四十個 commits。

我挑三個有故事的講。 第一個是一隻 P0 等級的 bug：有使用者的行程裡，某一晚的飯店直接消失， 然後交通時間出現十六小時五十七分這種離譜數字。

Luna: 十六個小時的交通，這是要從台北通勤到外太空嗎？ 根因是什麼？

兩個根因。 飯店消失，是因為系統解析飯店資料失敗時，把那間飯店整個丟進警告堆， 那一晚的住宿就空了；

時間錯亂，則是因為生成行程的 agent 直接相信 AI 給的時間。 修法很有代表性：現在每一晚如果沒有飯店，就補一張可刪除的「住宿待安排」占位卡， 至少誠實告訴你這裡還沒搞定；

時間則改用程式做決定性重算，保證行程不重疊、交通不超過四小時。 Luna: 我抓到重點了——「不相信 AI 給的時間， 改用程式重算」。

這跟例會裡講的那個原則是同一件事吧？

完全同一件事。 這次例會把重構哲學講明了：確定性的計算交給程式，AI 只負責做決策。 時間、價格、座標這種算得出來的東西，不要讓 AI 用猜的。

這一晚的好幾個修復，都是這個原則的落地。 Luna: 第二個故事呢？

語音。 之前有個懸案：使用者明明講中文，系統卻誤判成韓文。 這一晚查到根因了——他們用的語音辨識服務 Deepgram 有一個「多語言模式」，

聽起來很萬能，但翻開官方文件，那個模式支援的語言清單裡， 根本沒有中文和韓文。 Luna: 蛤？

所以等於一直用一個根本不支援中文的模式在聽中文？

對。 修法是一次小型的架構重構：以前語音辨識要用什麼模型、什麼語言， 是 app 自己決定的； 現在改成後端統一擁有這些參數，每一種語言釘死對應的單語模型，

app 只負責把後端給的設定原封不動用上。 從開票、後端實作、到 iOS 接上，二十四小時內收斂。

有趣的是 Web 端查證之後發現根本沒有語音辨識這條路徑， 直接把票關掉不做。 Luna: 我喜歡「查證之後決定不做」，這也是一種產出。

第三個故事？

第三個是一場接力賽：旅程相機、旅程相簿和即時動態。 上一集我們聊產品閉環的時候說過，旅行結束後的「回憶」是閉環很重要的一段。

昨天這條線的產品需求書剛定稿——旅行中拍的照片自動回到行程脈絡、 相簿有列表和地圖雙視圖、地圖上點團員的頭像，可以看 Stories 式的即時照片。

結果 PRD 定稿當晚，後端的共享相簿 API 就完成了： 全團員可見、支援地圖模式，而且照片的 GPS 座標在伺服器端刻意降精度到一百公尺左右。

Luna: 等一下，降精度是什麼意思？ 故意讓定位變模糊？

對。 你看得出照片大概在哪個街區拍的，但拿不到精確到門牌的座標， 這是隱私保護的設計。 這支 API 一合併，iOS 端的開發馬上解鎖，六個階段的規格和分工當晚談定，

今天凌晨已經宣布開工。 PRD、後端、iOS，三棒在二十四小時內交接完，這就是我說的接力賽。 Luna: 那 Web 端這一天在幹嘛？

兩件事。 第一件是體質改造收官：一個跑了好幾天的效能工程正式關票。 數字很漂亮——首頁的初始 JavaScript 減了百分之四十二，

訂單頁減了百分之七十八，刪掉一萬一千行沒人用的死碼，一百零九支 API 路由逐一盤點該留該砍， 過程中還順手修掉一個權限漏洞。

Luna: 這種工作使用者完全看不到，但七月十四號 demo 的時候， 「開起來快不快」就是第一印象。

正是為了那一天。 第二件是看得到的：行程裡的交通面板接上真實的通勤路線了， 滑鼠移到某條路線上，地圖會即時畫出那條路怎麼走。

另外 Mini App 做好了 deep link 和 QR code 安裝——這正好是例會裡點名要的功能， 從開票到完成只花四小時，還順便上架了四款官方基礎小工具：

記帳、地圖、待辦、票券。 Luna: 好，講了這麼多順利的，按照我們的習慣，該講不順的了。 demo 倒數七天，風險清單上有什麼？

三個，而且都不小。 第一，貨幣顯示：飯店價格出現日幣台幣混用、小數點錯亂。 這在 demo 是尷尬，但如果使用者真的按下付款，就是事故， 所以被列為最高風險。

第二，iOS 前端這幾天暫時動不了，加上航班搜尋和購物車還有一串 bug 排隊等修。 第三，票券系統的帳號因為長期沒有交易被鎖住了，下週送審之前必須救回來。

Luna: 所以接下來這一週，重點就是看這張風險清單消得掉消不掉。

對。 用一句話總結這一天：策略上，PickTrip 想清楚了自己賣的不是「排行程」， 而是「確定性」；

工程上，一個晚上關五張票，把住宿、語音、相簿、效能的地基補齊； 然後所有人抬頭看著同一個日期——七月十四號。

Luna: 而且從今天起，這個倒數我們每天陪大家看。 dogfooding 第一天會發生什麼事？

明天就知道。 你正在打造產品，或只是喜歡看一個產品怎麼一天一天長出來， 都歡迎每天回來。

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