歡迎回到 PickTrip 產品建造筆記。 昨天這集收在一個很難看的地方——PIC-370：使用者請 AI 加今晚的飯店，

agent 回一句「已加到 Day7」，實際上把整份七天行程清空到只剩 Day1 一間。 修法當時已經設計好，叫三路共用 mutation-guard， 但 demo 當天沒合併。

那今天第一件事，就是給我一個交代吧。

先講結論：它合了。 七月十四號凌晨四點十三分，PIC-389 進主線——agent、 pipeline、真人編輯，這三條寫入路徑從此共用同一套不變量檢查器。

太好了，那顆雷拆掉了！

這個你一定要知道——還沒。 護欄裝上了，但預設跑在觀察模式。 後面補的 PIC-404 才是嚴格攔截的開關，而它現在預設只記錄、 不擋。

加上 autoApply 沒有二次確認的 PIC-328 還躺在 backlog， PIC-370 這張票本身，從七月十三號下午三點十二分之後， 一次都沒有被碰過。

欸？ 所以是裝了煞車，但煞車線還沒接上？

先把事情講簡單：執法機構蓋好了，但還在試營運。 這是誠實的做法，也是還沒完的事實。

好。 那昨天到今天，團隊到底在忙什麼？

八十九個 commit，三個 repo。 後端六十三個，幾乎整包壓在同一件事——Agent 架構重構， Phase 1 到 Phase 7，一天之內收掉二十四張主線票。

一天？ 昨天不是才剛 demo 完嗎？

對。 但真正關鍵的是——動手的順序，不是他們自己排的。

什麼意思？

七月十四號早上，團隊跟可樂旅遊的馬總開了八十六分鐘。 一位在旅遊業做了二十年的老將。 他問的是最基本的一句話：你的獲利模式是什麼。

喔喔，外部視角。 然後呢？

然後他一層一層拆。 旅遊元件——機票、票券——價格透明、利潤極薄，OTA 普遍是拿訂房的利潤去養機票服務。

Klook 能在票券上賺錢，是因為他們在各地設點自己議價， PickTrip 沒有那個量體。

那就……先衝量？

這就是他點出的雞生蛋。 早期你只能二選一：經營品牌，或做完整供給。 兩個都要，需要極雄厚的資金。

他還自陳，他自己做過類似的照片、行程分享功能，失敗了。

這誠實得有點痛。

再往下看一層，最重的一刀是競爭。 他說真正的對手不是旅遊業者，是 Google——Flights API、 Maps、飯店、Docs、相簿，一旦整合起來，做旅遊元件的會一個一個倒。

PickTrip 的生存空間，只在大型通用平台無法深入的特定族群痛點。

那 B 端呢？ 賣給旅行社總行吧？

也被降溫了。 旅行社最在意的不是交付分散，是異常處理責任——飯店沒收到訂單的時候， 誰負責。 他舉了一個殺傷力很強的反例：曾經有團隊做「領隊一鍵呼叫」App， 他直接回旅行社不可能用。

配對失敗就變成雙軌服務； 三十個人同時呼叫領隊，要選誰？ 功能只是增加負擔。

所以功能新不新根本不是重點。

對。 B 端要的是減少工時、減少客訴。 馬總也答應幫忙牽線前線業務訪談。

那團隊聽完的反應是？

二十七分鐘。 會議結束二十七分鐘後，第一份會後校準就寫出來了。 而且它不是推翻前一天的 TripDoc 架構，是把它具體化——核心不是把 PDF 數位化，

是打造一個能承載旅程前中後、多人協作的行程載體。 然後排出四級優先序。 第一：穩定性與可編輯性，手動或 AI 新增飯店、票券、景點時， 不得崩潰、資料消失或錯誤覆寫。

第一名居然是「不要壞掉」。

第二是效能與開放性，從笨重的文件形態重構成快、可擴充，支援 QR Code、 加入主畫面這種低摩擦入口。

第三才是旅途體驗，互動地圖、相簿。 第四，TravelPack 後置成行銷擴散。 B 端也重新定義：C 端行程不等於 B 端方案，旅行社的 PDF 跟 Email 本來就能交付，

把資料搬進 PickTrip 本身不是價值。

這排序滿狠的，等於把昨天的亮點全往後推。

而且故事沒完。 當天晚上還有第二份文件，叫「產品方向與策略重估」。 團隊在裡面公開質疑——還要不要繼續做旅遊 AI。

哇。 這是要跳船嗎？

理由是垂直 AI 該選有領域知識、資料或法規門檻的場景， 文件點名的研究方向是醫療、Home Service、營建。

旅行 AI 毛利偏低、自建 AI 每日成本高、體驗未達標， 缺乏護城河。 連編輯器跳動與同步不穩，都被寫進去說已經影響開發信心。

那到底決定了沒？

先把事情講簡單：這份文件到現在還標著「待人類校對」。 它自己也承認，結論來自單一外部建議跟品質不一的逐字稿，而且還沒定義「繼續、 收斂或轉向」的量化判準。

所以我如實說——這是未決狀態，不是決定。

那隔天那場會呢？

七月十五號，九十一分鐘，本週資訊密度最高的一場。 而它的結論，跟前一晚那份重估的方向是相左的。 核心命題只有一句：先證明 PickTrip 能可靠完成一趟真實旅行，

而不是再做更多功能。 三個閉環排序——核心使用、營收、成長。

所以還是留在旅遊，先把東西修好。

而且技術盤點講得非常直白。 手動加入飯店曾經弄壞整份行程。 Yjs 本地與遠端版本不一致，造成內容崩潰或消失。

AI 因為用日期、用索引去猜測目標，所以改錯對象。 修復方向兩句話：統一寫入介面，只用唯一 ID 識別。

等等，這聽起來……

對，這就是今天最漂亮的地方。 把那兩句話跟後端那六十三個 commit 對起來看——PIC-387、

388、411、413，把所有裸的 doc.transact 全部趕到 command 層， 這是統一寫入介面。

PIC-378，day_id handle 成為唯一的日期定址方式， 日期跟序數全部退役，這是只用唯一 ID 識別。

會議室裡講的話，當天晚上就變成程式碼了。

同一批人，白天把痛點講清楚，晚上回去把它執法化。

另外還有 Phase 1 的協議不變量，禁止沉默回合——harness 直接把 needs_clarification 合成 ask_user，

把協議遵從權從模型手上收回來，順手關掉了 PIC-333。 工具面 69 收斂到 28。 runV3 跟 v4Refs 整條舊生成路徑退役。

那成本呢？ 昨天不是說成本第一次變成一級目標？

今天更狠。 prompt cache 命中改成實際量測而不是假設； 模型分層——規劃完成之後整個 loop 降到 mini， 敘述步也降。

目標是單次完整生成加對話加修改壓到零點五美元以內，會議記錄說做完大約一半。 他們還訂了一條規矩很值得記下來：AI 後端完成，不等於功能完成， 必須接回 iOS 實測。

那商業化呢？

直接質疑固定加價百分之五——因為金流稅費本身就吃掉四點五到六。 替代方案是供應成本跟市場參考價取中間值，但註明百分之五十只是討論起點。

飯店是現階段最可能有有效毛利的類別。 還有兩條紅線：分潤必須從實際毛利算，不是訂單總額； 顯示「省下多少」必須保留來源、樣本、時間、幣別，不得用假原價製造折扣。

最後這條我喜歡。

這些後來變成 Linear 上的 PIC-420、421、 422——feature flag 的 Go／No-Go 門檻、 價格樣本表與毛利基線、第一版售價規則。

有沒有什麼好笑的？ 我需要一點好消息。

有一個很人性的。 會議上發現，共享相簿其實早就做完了，但 Linear 狀態沒更新， 結果整個團隊誤判它還沒好。

哈哈哈，做完了自己不知道！

同一場會還花了一整節訂 bug 回報規範，起因是問題老是被描述成「有時候會壞掉」， 然後沒人重現得出來。

「有時候」是工程師的天敵。

收一下大局。 今天很罕見：外部的一記重拳，跟內部一整晚的重構，同時發生。 架構重構 Phase 1 到 Phase 7、二十四張票收掉，

寫入路徑統一、定址收斂、舊路徑退役、成本進閘門——這是真的往前走了一大步。

那風險清單？

畢業生是真的畢業了幾個：PIC-389 三路共用不變量已合， PIC-333 沉默回合關閉，runV3 退役。

但新票不客氣。 PIC-416，Urgent，P0——Web 建立的「東京 2026／07」行程， 在 iOS 上直接閃退，而且可以穩定重現。

PIC-403，retime-item 在兩顆模型上都失敗， matched control 證明不是換供應商造成的， 是能力缺口。

PIC-407、408，邀請合作者接受了卻不生效。 加上 iOS 那批新火：日期過濾、交通時間首次不渲染、購物車跟行程刪除不同步。

那 PIC-370 呢？ 就是那個。

還開著。 Urgent，Backlog，兩天沒動。 護欄的地基蓋好了，但嚴格攔截還在觀察模式，二次確認還沒做。

所以昨天那個問題，今天的答案是：往前走了一步，但還沒關。

誠實。

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

掰掰！