歡迎回到 PickTrip 產品建造筆記，我是 Kai。

大家好！ 昨天我們才說團隊「準備開門做生意」欸——地基鎖上、機票多接一家、 稽核百科排乾一半。

對，昨天是「準備開門」。 今天有個轉折——開門做生意的那隻手，又縮回來了。

蛤？ 為什麼？ 出事了嗎？

先講結論。 今天最重要的一件事，是他們發現收銀台還在說謊——把「還訂得到」的東西， 謊報成「這個方案已經過期」。

只有一個地方會這樣嗎？

不只。 三個供應商一起中：票券、飯店、eSIM，全部都會。 人一發現，就把上線日往後推。 誠實，排在上線前面。

等一下，我用旅行的角度翻譯一下。 我在 app 上挑好一張大阪的票，手指按下去，它跳「這個方案已經過期」——

我一定以為賣完了、或下架了，轉頭就走。 可是其實那張票好好的？

好好的。 真正發生的，只是後台的網路打了一個嗝。 這個你一定要知道，三個供應商，是一模一樣的病。

先看飯店。 DIDA 那家的報價轉接層，只要遇到任何錯誤——代理卡住、 伺服器 5xx、逾時——一律回「不可用」。

然後結賬那端就當真了？

對，結賬根本不看是哪一種錯誤，直接蓋成「永久過期」。 一個暫時的網路嗝，就把一間訂得到的飯店，變成「已過期」。

那 eSIM 呢？ 也是這樣？

eSIM 更微妙。 它真的賣完時，其實會正常回一個成功的狀態，不會丟錯誤。 只有真正的網路故障，才會掉進那個接錯誤的區塊。

所以反過來說，只要網路抖一下，一張能買的 eSIM，就被標成「過期」。 修法是：退回上一份快照，當作還能買，同時守住價格為零的防呆。

票券那邊聽說最複雜？

再往下看一層。 票券是 Klook，兩個問題疊在一起。 第一，那筆優惠存錯了時段——把真正下午兩點的場次，存成了半夜。

光這個就夠嗆了。

還有第二。 下單前那道「再查一次還能不能訂」的檢查，本身是壞的：送錯了請求內容、 從錯的欄位讀錯誤碼、還藏了一個空指標。

真正的失敗全被吞掉，通通吐成「過期」。

所以三張票，其實是同一句謊話，只是用三種方式在講。

講得好。 而且這條線，我們追很久了。 你記得嗎——教系統不要說謊那一集、把 DIDA 的安全預設從「沒有」翻成「去查查看」那一集、 還有拆穿假的「目前沒有方案」那一集。

今天是同一個敵人的最後一站：收銀台前的「過期」。 之前它學會了假裝沒有，今天，終於不准它假裝過期。

三張票，同一天開、同一天修、同一天結案。

我突然覺得「假過期」比「假沒有」更壞欸。 假沒有你還會再找找，假過期會讓人覺得「啊我來晚了」，直接放棄。

完全正確，這就是為什麼它擋在上線前面。 而今天真正罕見的是——人跟程式碼，第一次講了同一句話。

怎麼說？

昨天有一場「產品發布與客服系統集成」的會議，白紙黑字寫了同一個 bug： 「結賬把有效的票，誤判成過期」。

然後，他們做了一個很大的決定。

什麼決定？

把上線，往後延。 先別加任何新功能，先修三個擋路的東西：票券的日期篩選會跳「沒有票」——有個日式舞蹈的行程就中招了；

結賬誤判過期； 還有一些分支沒有乾淨地合進主線。

測試版上還看得到這些 bug？

對，看得到，那就是還不能上。

所以昨天才說要開門做生意，今天門又關回去了？

對，但這扇門關得有道理。 先把事情講簡單：上一集是「準備開門」，這一集是「等一下， 收銀員還在騙客人，先別開」。

這不就是可樂旅遊馬總當初講的？ B2B 在乎的不是有多少新功能，是異常處理的責任。

一模一樣。 他們現在是把誠實，排在上線前面。 而且今天還有另一件很有意思的事——他們同一天在蓋客服後台。

客服後台長什麼樣？

網頁那邊做了一整套 SOP 知識庫——DIDA 的服務等級、 Stripe 的爭議處理，全部寫成一張一張的 SOP 卡。

iOS 那邊，加了真人客服的入口，從行程的三個點、還有個人頁進去。

等等，一個全部用 AI 做出來的產品，客服卻特地找真人來坐？

對，會議紀錄裡特別註明了——是真人客服，不是 AI 客服。 這是一個很誠實的自我認知。

AI 可以幫你排行程、幫你下單，但當一筆真錢卡住、一間飯店真的訂不到， 接手的，得是人。 收銀台後面，第一次坐進了一個真人。

這個對比好強喔。 前面在拆 AI 說的謊，後面在請真人來善後。

再往下看一層，今天還有兩個案子，我叫它「昨天的解藥，今天變成毒」， 而且都是當天拆、當天補。

又來？

第一個是安全。 前幾天我們鎖了一道——AI 改行程時，寫入的行程編號必須等於當下這一趟的編號， 用來擋跨行程的污染。

結果它把「建立一趟全新行程」整個擋死了。 因為建新行程的瞬間，系統才剛生出一個新編號，舊的還是空的， 一比對，就說「你越權」——每一趟新行程都建不出來。

今天緊急修掉。

第二個是昨天那道會餓死人的寫入鎖對不對？

對，就是昨天那道。 太嚴，會餓死，手動存待辦存不進去、區塊還無限複製。 昨天還在做，今天做完了：鎖的吞吐量重寫，客戶端加了退避， 終於存得進去了。

我發現一個規律欸——他們把地基一道一道往下鎖，每鎖一道， 就夾到自己一次。

你觀察得很準。 但成熟的地方在於：現在都是當天發現、當天補起來。

那昨天留的問號呢？ 那本「行程完整性稽核」的百科，是被排乾，還是又凍在待辦？

今天的答案是——在排。 版本號補上了防重複的機制、載入失敗跟「文件根本不存在」被分清楚， 不再拿空白去覆蓋、購物車跟協作文件的斷鏈，在每個寫入點補起來。

連那個「AI 全部失敗、卻還回報成功」的機制——就是之前新竹幽靈那一隻——今天也開始動它了。

那昨天新接的那家機票供應商呢？ 有上嗎？

上了。 第二家機票商正式併進去了，連航班號前面多帶的航空代碼都順手修掉。 現在機票，後面有兩家供應商在撐。

聽起來今天到處都在治病。 那……那張票呢？ 我猜你要講它了。

你猜對了。 有一張票，還是沒動。 第十三天。

又是它。

就是它。 那張最老的急件，七月十二號建的，狀態史就一格「待辦」，從沒離開過。 它的名字是「AI 一加飯店，就清空整份行程」——正是這整本稽核百科， 命名的那個病。

病，在收銀台被治、在地基被治、在每一個供應商被治。 可寫著病名的那張票，還躺在原地，第十三天。

還有那筆付款呢？ 收銀台的鐵門昨天不是抬起來了？

收銀台的機器，在程式碼裡是修好了。 但那筆「在真手機上，真的刷一筆來確認」的 QA，到今天還躺在待辦， 沒有一個人真的刷過。

反正——上線也延了。

好，那今天的畢業生跟新票，幫我點一下名。

畢業生：三張「假過期」的票，票券、飯店、eSIM 全部結案； 那個擋死新行程的安全回歸修好了； 會餓死人的寫入鎖，兩張都做完了；

載入失敗的空白覆蓋補好了； 待辦資料的收斂也完成了。

還在檯面上的：稽核百科還有一半在排、客服後台的後端那一半， 還凍在待辦； SOP 知識庫的第二階段剛開張；

付款的真機驗證沒動； 還有第十三天的那張老急件。

至於策略那份大哉問，還是停在七月十四號，沒人動它。 但這次我不叫它沉默——因為團隊是自己把上線往後推，先把誠實補齊， 才敢開門。

所以明天的問題是——延了的上線，那三個擋路的 bug 修完了沒？ 收銀台的付款，會不會終於有人在真機上，刷下第一筆？

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

掰掰！