PickTrip建造術：把系統擅自毀掉你做過的事第一次當成一門學問來盤點的那一天——一個人一天開出資料完整性稽核母議題與二十七張子票、當天修完九張，最底層那道從缺的鎖終於鎖上，沒鎖時二十四筆寫入掉二十三筆；還挖出唯讀工具沒權限、跨行程汙染的真源頭其實在後端，而寫著同一個病名最老的那張急件第十一天還躺在待辦沒人碰

本集摘要

這一集回答上一集的付款懸念：今天沒有人碰付款，網頁與 iOS 都零提交，後端一位工程師把「系統會擅自毀掉你做過的事」這個追了快十集的老病，第一次當成一門學問，開出「行程資料完整性稽核」母議題與二十七張子票，當天修完九張、其餘十八張排成一張標好病因的地圖。最關鍵的是最底層那道從缺的鎖：Yjs 文件存回時整包覆寫、兩隻手互相蓋掉，沒鎖的對照組二十四筆寫入掉了二十三筆，加鎖後掉零筆。稽核挖到一半還變成安全稽核——唯讀工具沒有權限檢查、編號覆寫沒驗歸屬，證實前幾集怪到手機端的跨行程汙染，真源頭其實在後端。真人回報的十把火第一次被一條條接住命名，但寫著同一個病名、最老的那張急件第十一天還躺在待辦沒人碰。

完整逐字稿

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

我是 PIKA！ 欸 Kai，上一集你留了一個問題吊在那邊，我一直記到現在。

我知道你要問什麼。 上一集我們把收銀台整台推上線，還救回了第一筆被自己機器吞掉的真錢， 最後留了一句：真人在手機上，到底能不能乾乾淨淨地付完一趟。

對啊！ 那今天付款到底通了沒？

先講結論——今天沒有人碰付款。

蛤？ 一顆跟付款有關的提交都沒有？

一顆都沒有。 網頁端整天零提交，iOS 也零提交，所有的火力，全部集中在後端的一個人身上。

那他一整天在幹嘛？

他做了一件這個系列講了快十集、但從來沒有人這樣做過的事——他把「系統會擅自毀掉你做過的事」這個病， 第一次當成一門學問，從頭到尾盤點了一遍。

等等，你說「盤點」是什麼意思？ 不是修一個 bug 而已喔？

這個你一定要知道。 過去我們每一集都在打地鼠——真人回報一把火，工程師修一個洞， 票躺回待辦，下一集再冒一個。

今天不一樣，有人開了一張母議題，叫「行程資料完整性稽核」， 然後一口氣開出二十七張子票。

二十七張？ ！

二十七張。 而且不是隨手列的，每一張都指到一個具體的毀損來源。 當天就把其中九張修完、上線，剩下十八張，變成一張排好優先序、 標好病因的地圖。

所以是從「打地鼠」變成「畫出整片地鼠田」。

你這個比喻我收下。 先把事情講簡單：以前是有火才救火，今天是有人退一步，把整個會失火的表面畫成一張圖。

那這九張裡面，哪一張最重要？

再往下看一層，最底那一張，叫做「持久化層沒有鎖」。

光聽名字就很不妙。

非常不妙。 我先講清楚這個病。 你的行程，存在一個叫 Yjs 的協作文件裡，它本來很聰明， 會自動把兩個人的修改合在一起。

問題是——存回資料庫的那一刻，程式是把整份文件「整包蓋上去」。

整包蓋上去？ 那合併不就白合了？

對。 想像兩隻手同時在寫同一份文件：一隻是你手機的同步，一隻是 AI 寫完之後的回存。 A 先讀出舊的，這時候 B 寫進去了，然後 A 把手上那份舊的整包蓋回去——B 剛剛寫的，

消失。

你剛剛講的，不就是這幾集一直在講的「刪除復活」、「行程整批消失」的最底層版本嗎？

一模一樣。 前面有一集，我們在「代理人的架構」那層治過它； 後來讓對帳程式閉嘴，不准它亂寫； 上一集又加了版本檢查——但這些全部，都蓋在一個沒有鎖的地板上。

今天，他們終於在最底那一層，把那道鎖鎖上了。

那有沒有辦法證明鎖真的有用？ 還是又是「我覺得應該可以」？

這就是我最想講的。 他寫了一個測試：二十四個寫入同時打進去，一半是同步、一半是 AI。 沒有鎖的對照組——二十四筆掉了二十三筆。

二十三筆？ ！ 那幾乎是全滅欸。

加上鎖之後，掉零筆。 這不是「我覺得」，是量出來的。

好，這是地板。 那地板上面那幾張呢？

剩下的，我幫你歸成同一個敵人的幾張臉。 第一張，「重建把待辦清單擦掉」——修復程式在重組文件的時候， 漏掉了五個真的裝著資料的欄位，結果一修，你的待辦就沒了。

修復程式自己才是兇手，這也太諷刺。

第二張，「每一輪都把商品往前拖一天」。 飯店、票券這種商品，時間是用另一種方式記的，結果對齊程式每一次 AI 回合， 都把它們往回拖一天。

難怪一直有人說飯店日期會漂。

第三張，同一間飯店你訂兩段不同的日期，系統把它們合成「數量二」， 第二段的日期跟行程錨點整個掉了。

第四張，一段飯店的購買狀態被覆寫成「票券」，把它的商品編號跟座標弄丟。 第五張，來回航班的時間比對，因為時區基準記錯，在台灣、日本、

韓國幾乎整個失效——一百五十二筆真實資料全部帶時區，比對卻用了錯的基準。

這五張聽起來完全不一樣，可是你說是同一個敵人？

對。 同一個敵人：系統安安靜靜地，把你做過的事改掉、或弄丟，還不告訴你。

欸，可是我聽到你剛剛講了「座標」、「編號」，怎麼有兩張聽起來像是……安全問題？

你耳朵很利。 這是今天真正關鍵的轉折——這次稽核挖到一半，發現有些「毀損」根本不是算錯， 是「權限沒守」。

展開講。

第一個，代理人的唯讀工具——讀行程、讀筆記、讀待辦——完全沒有權限檢查。 模型只要講得出哪個行程編號，它就讀得到。

所以 AI 只要「說」出一個別人的行程編號，就能讀？

更嚴重的在寫的那邊。 有一個編號覆寫的機制，完全沒有檢查那個行程是不是你的。 這句話你一定要記住——這正是我們前幾集一直「怪到手機端頭上」的跨行程汙染， 它真正的源頭，其實在後端。

哇。 所以我們冤枉手機端好幾集。

差不多。 另外還有一個對帳的端點，只驗了「你有沒有登入」，沒驗「你有沒有權限」， 而且那個流程會真的去改購物車。

稽核順手還標出另外九條沒有認證的端點，排進待辦。

所以這場「資料完整性稽核」，其實一半變成了「安全稽核」。

對，而且每一條都帶著數字。 九點二趴的版本號重複、六成四的購物車跟文件斷了鏈、一百五十二比一百五十二筆全部帶時區——這不是猜的， 是一筆一筆量出來的。

我突然意識到一件事……那我們追了快十集、真人回報的那些火， 跟這張地圖是什麼關係？

好問題，這是今天的答案。 那十把七月二十三號開的火，票號還躺在待辦沒動——可是它們的「病」， 今天被這張地圖一條一條接住了。

有的直接治好，有的被精準命名——連那個「只打一聲哈囉、就被硬建一趟新竹行程」的幽靈， 都被歸到一張「工具全失敗、還回報成功」的票上。

所以帳本跟現場，第一次對起來了？

一半。 現場的火，第一次有了一本完整的病歷。 但是——

我知道你要講哪一張。

對。 有一張最老的急件，它的名字，字面上就是「AI 加個飯店， 把你整份行程清空」，編號三七〇。

今天這整張母議題，就是為了治它這一族的病，它底下一整排兄弟——七張急件——當天全部畢業。

那三七〇自己呢？

第十一天。 從七月十二號開到現在，狀態紀錄只有一行「待辦」，從來沒離開過。 它的一整族被治好、被編成百科全書，寫著它病名的那張票，還是沒有人碰。

把整片地鼠田都畫出來了，就是沒去踩它正中間那一隻。

你這個比喻，今天第二次收下。

那策略那邊呢？ 那個大哉問有下文嗎？

策略文件今天我們看不到——那個系統這次連不上，所以我不騙你， 我只能說：從七月十四號到現在，那個「我們到底要不要繼續做旅遊 AI」的大哉問， 還是沒有人正式回答。

好，那今天的風險清單？

畢業的：最底層那道鎖，加上七張急件，總共九張，當天上線。 新開的：十八張排好優先序的完整性欠債，包括一張「八條規則從來沒通電」的守門票， 正在等來回航班那張把跑道清乾淨。

還沒動的：付款的真人驗證還停在待辦——今天沒人碰付款，收銀台的程式是修好了， 可是還沒有人在手機上，按下那一次驗證。

筆記跟待辦那三張還在進行中，十把真人的火還躺著，還有三七〇， 第十一天。

感覺明天最大的懸念，就是這張地圖到底會被做，還是變成下一堆躺著的票。

這個你一定要知道——畫出地圖很難，但真正關鍵的是，會不會有人照著它走。 明天同一時間，PickTrip 產品建造筆記，每日更新。

掰掰！