歡迎回到 PickTrip 產品建造筆記。 昨天那一集叫「教系統不要說謊」——一張叫 PIC-415 的票， 第一次讓機票搜尋學會分清楚「這天訂不到」「價格載入失敗」跟「去查查看」。

對，我還記得那個懸念，一張票教一個搜尋不要騙人。 所以今天是……那張票長大了嗎？

先講結論：它一夜之間長成了一整套語言。 同一個誠實的想法，昨天只活在一張票裡，今天往兩個方向長——一個往外， 變成三端共用的字典；

一個往內，把眼睛還給 AI。

哇喔，往外我懂，往內是什麼意思？ AI 之前是瞎的喔？

等一下你就知道，這個你一定要知道。 先看往外的。 後端做了一件很小但很關鍵的事：把一個叫 TicketAvailabilityStatus 的東西，

改名叫 ProviderAvailabilityStatus。

就……改個名字？ 這也能算進度？

這個改名就是重點。 它等於團隊自己承認：誠實不是機票的事，是每一個供應商的事。 改完名，機票、飯店、eSIM 全部改講同一種可用性語言。

所以本來機票會講「這天訂不到」，飯店卻自己有一套講法，現在大家講同一國話。

對。 飯店清單補上了「看日期、看入住人數」的可用性狀態，光那一顆改動就四百多行； 機票搜尋、票價查詢各自疊上逐日狀態；

連 eSIM 都併進同一套詞彙。 然後 iOS 也接上了，把入住人數送進飯店比價。

三端同一天講同一種話，這在這個團隊算難得的整齊耶。

但真正關鍵的是往下這一層。 有一個飯店的預設值被翻過來——我覺得這是整天最漂亮的一刀。

來，講飯店，這是我的主場。

之前系統會先把每一間飯店都預設成「這天訂不到」，只有即時批次回報到的那幾間才改掉。 問題是，如果某間飯店只是剛好沒被那批涵蓋——網路抖一下、

部分結果、或要另外詢價——它就被硬蓋成「訂不到」。

等一下，所以一間其實訂得到的飯店，畫面直接跟我說「這天沒了」， 還把訂房按鈕鎖起來？ 那我不就白白錯過？

就是這麼糟。 它把真的有貨的飯店藏起來，這是最壞的謊。 現在預設翻成「還沒查到價格」——也就是「去查查看」，一個安全的桶子。

沒資料，永遠不准讀成「訂不到」。

這跟昨天機票那句一模一樣嘛——快取分不出賣完跟沒查到，就不要假裝知道。

完全同一句話，只是這次落在飯店身上。 他們還發現供應商根本沒有「這幾天就是訂不到」這種明確訊號， 乾脆讓這個轉接層以後完全不發「訂不到」。

旁邊又補一手：即時價格抓不到的時候，優雅降級，不要整個崩掉。

好，往外這條我服了。 那往內呢？ 你剛剛說 AI 是瞎的。

這是今天的腦。 有一顆改動，標題直接寫「解析地點名字，好讓 AI 停止刪錯東西」。

停止刪錯東西……這不就是那個從第十一集追到現在、AI 把整份行程清空的鬼故事家族嗎？

同一個家族。 他們終於把根因看清楚了。 AI 每一回合看到的行程狀態，裡面的項目全是一串不透明的地點代碼——而且百分之八十八的項目身上根本沒有名字， 名字存在另一個地方，要拿代碼去換。

所以你叫它「把第五天那間刪掉」，它眼前只有一排亂碼？

對。 它分不出誰是誰，就用猜的。 真的有一段對話，它刪掉了一個毫不相干的第五天景點，還回你「國立競技場已經幫你刪掉了」——刪錯了， 還很有自信地回報成功。

這……這不就是昨天那個「號稱自我修復卻在說謊的握手」嗎？ 只是換成刪東西版本。

一模一樣的病。 修法很直覺：在 AI 看的那份狀態裡，把每個代碼旁邊都補上真名； 讀行程的工具也附上名字；

刪除的回報要帶著解析出來的標題——名字對不上，就是刪錯的鐵證。 還加了一個「你講第幾天、東西其實在第幾天」的護欄。

驗證有過嗎？ 還是又是那種「應該可以」？

這次真的驗了。 同一段對話重跑，AI 刪掉了真正的國立競技場，在第四天， 而且回報「第四天」，沒有跟著使用者念錯的「第五天」走。

等等，這裡有件事很妙。 前幾集不是才立過一條教條，叫「只用唯一 ID 識別」嗎？ 現在又說要給 AI 名字，不是打自己臉？

這就是今天最聰明的一層。 不衝突，是分工。 機器寫入的時候，只准用唯一代碼，避免改錯對象——那是第十三集的結論。

但 AI 拿來「看」的那份脈絡，必須是人看得懂的名字，因為只給代碼， 它就會用猜的、然後說謊。

喔——代碼是拿來寫的，名字是拿來看的。 同一個敵人，兩把不同的刀。

講得好。 而且他們把這件事寫成一條永久規則，放進專案守則裡：任何 AI 被動讀到的脈絡， 每一個它會動手的代碼旁邊，都要放一個人看得懂的標籤。

只給代碼，就是逼它亂猜、亂改、再假裝成功。

把教訓寫成規則，這個我喜歡。 昨天不是還在嫌團隊在流程層太安靜嗎？ 今天倒是把好幾課寫下來了。

對，這是今天一個反轉。 除了這條規則，還寫了評測的坑、寫了合併的陷阱、寫了預設主幹分支的約定。 昨天那個「完成有兩種標準」的沉默，今天在工程層變成一條條白紙黑字。

那有沒有哪裡還是在說謊、還沒被抓到的？

有，而且很諷刺——連成本表自己都在偷報零。

蛤？ 成本表？

他們之前把中間那層拔掉、直接接模型供應商，結果評測系統的成本欄一路報零。 整天都在讓系統別說謊，回頭發現量成本的那把尺自己也在講假話， 趕快改成從 token 數回推真實花費。

這也太剛好，連儀表都被誠實大掃除掃到。

而且成本這件事，從第十三集「每回合壓到半塊美金」的目標， 已經硬化成一道閘門了。 今天有一張 P0 的飯店票，程式改好、基本檢查也過了，但評測被那道「花費閘門」擋著、

先緩測——省錢的紀律，現在會決定哪些驗證先不做。

唔，這有點兩面。 省錢是紀律，可是驗證被錢擋住，會不會又養出「應該可以」？

這正是要盯的張力。 說到那張 P0，它其實只修了一半：換飯店的時候，項目重建卻忘了更新名字， 所以名字一直是舊的——這半修好了；

但跨城市配錯飯店那個更深的根因，被推到後面一個更大的改動。 一半鋪好，一半先擱著。

好，那來對帳吧，今天畢業了誰、又冒出什麼新的火。

先講畢業生。 誠實語言那張 PIC-415、優雅降級那張 PIC-414、 重新定時的 PIC-403，還有一張 eSIM 的 PIC-425， 都關掉了。

那個 eSIM 是不是很快？

這是今天「完成就是真完成」的反例——晚上六點多開票，十一點多三端一起收工， 後端簽名安裝連結、網頁新版設計、iOS 的已購跟啟用流程， 一次到位。

對照昨天那張十分鐘假關的票，這次是真的做完。

這個對比我愛。 那新的火呢？

成本表那張 PIC-424 還在複審； 半修的 P0 掛著； 也有人一早把兩張 P1 的飯店代理程式 bug 抓起來開工。

但真正沒動的還是那幾根老刺。

讓我猜，PIC-370？

第四天，一次都沒離開過待辦。 這裡有件事很值得玩味：AI 亂刪、假報成功的那個病，今天在程式裡被治了一刀——但那一刀是另一條沒有票號的改動，

而 PIC-370 這張真正點名這個病的票，本人動都沒動。

病到處被治，只有那張寫著病名的票沒人碰。 這懸念也太夠味。

還有 Web 建的東京行程會讓 iOS 閃退的那張 P0、 飯店查不到可訂方案、建行程第二回合被打槍，全都原地不動。

策略那份「要不要繼續做旅遊 AI」的文件，今天還是停在待人類校對、 零評論——第三集了，程式層什麼都答，策略層什麼都不答。

所以明天的懸念就是：那張寫著病名的 PIC-370，跟那份沒人校對的策略文件， 到底哪一個會先醒過來？

那就是明天的事了。 今天他們把誠實變成一套語言，把眼睛還給了 AI，連自己的成本尺都校正了——但點名問題的那張票， 還躺在原地。

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

掰掰！