PickTrip建造術：demo當天定義自己——TripDoc教條落地成骨架，加密貨幣收銀台上線，AI清空行程的護欄卻還開著上場

本集摘要

demo 當天（ep12）：團隊沒有先補昨天的洞，而是先在架構文件裡把 PickTrip 定義成「開放、多人、AI 原生的旅行文件 TripDoc」——AI 是操作層而非聊天頁，高影響修改需 diff／確認／audit，交易留在產品內、履約才委外。同一週的程式碼把教條變成骨架：ItineraryCommands 領域層把所有行程與商業寫入收斂成同一道門（PIC-386／388）；AI 工具從 69 個收斂、目標 28 個並上確定性 DAG 路由與 skill 注入（PIC-374／375／382／383）；成本首次成為一級目標——per-turn token／花費遙測（PIC-398）、拔掉 OpenRouter 直接接供應商、統一到旗艦 Sol 加便宜 mini 兩顆模型；先鋪 Braintrust 評測安全網與購物車評分器（PIC-379／362）才敢重構。付款抽象成 provider 介面加註冊表，加密貨幣（NOWPayments）與 Stripe 併排上線，含選幣／估價／webhook 對帳／加密退款、退款依訂單原金流路由。iOS 磨好 demo 面：互動地圖重做、飯店替換流程、可退款才可取消、行程帳本與投票小工具、新版 AI 卡片。最大未結風險 PIC-370（Urgent，仍 Backlog）——in-trip AI 加飯店卻清空整份七天行程，high_removal 護欄對 ai_agent 不硬擋加 autoApply 無二次確認；修法（三路共用 mutation-guard，PIC-389 Phase 4d）已設計但 demo 當天尚未合併。其餘新火：AI 回合不出聲（PIC-333／368）、語音 agent 人數前後不一致致飯店售罄（PIC-339）、held 航班落地時間未作 day1 排程下界（PIC-359）、autoApply 編輯不可復原（PIC-328）、iOS AI 規劃器逾時與語音辨識（PIC-270）。

完整逐字稿

歡迎回到 PickTrip 產品建造筆記。 昨天我們是在一個很不舒服的畫面收尾的——使用者人在東京， 開口跟 AI 說「幫我找今晚的飯店」，結果 AI 加是加了，

卻順手把整整七天的行程清空，只剩下第一天一間飯店。 我們昨天丟了三個問題：護欄為什麼沒擋住？ 這種一鍵覆蓋為什麼不用二次確認？

demo 前修得好嗎？ 今天正好是 demo 當天，我先講結論：三個問題，答案分別是「有個洞」、 「本來就該要、但還沒接上」，還有一個你可能沒想到的——團隊今天做的，

不是急著補這個洞，而是先把「PickTrip 到底是什麼」這件事寫下來。

等一下，行程都被清空了欸，demo 當天不先滅火，反而先去寫文件？ 這聽起來很像那種房子在燒、大家先開會決定要不要重新裝潢的畫面。

我懂你的吐槽，但這次真的不一樣，你聽我把它講簡單。 昨天那個狀況，根因已經完全查清楚了：破壞性寫入的護欄，只硬擋「整份被刪光」跟「動到已經訂好的項目」兩種，

唯獨「刪除比例過高」這一種，對 AI 來源只寫一行 log、 不阻擋； 再加上旅程中的 AI 走的是自動套用，中間完全沒有二次確認；

最後刪除工具本身也沒有數量上限。 三個洞剛好疊在一起，AI 就把七天刪到剩一天。

所以它不是笨，是「合法地」把行程刪光的。 護欄明明看到刪太多，卻放行。

對，而這正是關鍵。 如果你只是急著把那一行 log 改成硬擋，你補的是一個症狀。 今天團隊在文件上，把 PickTrip 重新定義成一個東西——不是旅遊聊天機器人，

而是一份「開放、多人、AI 原生的旅行文件」，他們叫它 TripDoc。 一趟旅行的成員、行程、訂單、票券、付款、位置、照片，全都活在同一個、

可以被人、也可以被 AI 操作的共享物件裡。

聽起來很大。 可是這跟昨天那個把行程刪光的洞，到底有什麼關係？

關係就是全部。 這份文件裡有一句話，幾乎是直接對著昨天那件事寫的：AI 是操作層， 不是聊天頁；

高影響的修改一定要有 diff、要有確認、要有紀錄； 不可逆的交易跟敏感操作，AI 不能憑一段模糊的對話自己完成。

你發現了嗎——昨天的事故，就是這條原則被違反的現場。 所以今天真正重要的，不是那一行 log，而是他們開始把這條原則， 變成程式碼裡真正的骨架。

好，那「變成骨架」具體是做了什麼？ 我要看到東西，不要只看到理念。

給你看四件事。 第一，他們建了一個叫 ItineraryCommands 的領域層， 把所有對行程的寫入，收斂成同一道門；

連購物、下單這種商業寫入，也開始改走這道門。 先把事情講簡單：以前護欄要在很多地方各擋各的，現在只要守住這一道門， 規則就能在一個地方一次執法。

昨天那種「刪太多還放行」，未來就是在這道門上補一次，就全域生效。

喔——所以不是到處貼 OK 繃，是把所有水管接到同一個閥門。 這個我喜歡。

第二件，他們把 AI 的工具，從六十九個一路收斂，目標砍到二十八個左右， 光是查商品的工具就從十一個併成五個、改行程地點的從五個併成三個， 再配上一個確定性的回合路由器。

再往下看一層，這件事的意義是——工具越少、路徑越固定，AI 就越不容易亂點， 你也越容易看懂它到底做了什麼。

第三件，成本第一次被當成一級目標：每一次模型呼叫、每一個回合的花費， 都埋了儀表； 他們還把整套 AI 從中間商那一層整個拔掉，改成直接接供應商，

統一收斂到兩顆模型——旗艦的那顆做重活、便宜的那顆做雜活。

這個對做旅行的很有感啦。 使用者問一句「幫我排今天」，背後可能燒掉一堆錢，你不裝錶根本不知道錢花去哪。

而且你有沒有發現，這三件事都是在大動 AI 的骨架。 他們敢這樣改，是因為動手之前先鋪了一張安全網——一套自動評測的題庫， 還有一個專門檢查購物車每一列對不對的評分器。

等於先把考卷準備好，才敢去換寫答案的人。 這樣重構要是把哪裡改壞了，題庫會先替你叫出來。

懂，先裝好煙霧偵測器，才敢在廚房開火。 那第四件呢？

第四件最像 demo 會用到的——付款。 他們把付款抽象成一個介面加註冊表，原本的信用卡金流變成其中一個轉接頭， 然後併排接上了一條加密貨幣的通道，可以選幣、可以估價、可以對帳，

還有加密貨幣的手動退款； 而且退款會自動認得這筆訂單原本走的是哪一條金流。 等於 PickTrip 的收銀台，從單軌變成多軌。

這也呼應了那份文件的另一個判斷：交易要留在產品裡，履約可以交給供應商， 但體驗不能整包丟出去。

所以今天這一票東西，其實是同一個故事的不同切面——把 AI 變成守規矩的操作層、 把寫入收到一道門、把成本點亮、把收銀台加一條軌。

那手機端呢，demo 是要拿手機出去見人的耶。

對，iOS 今天也磨了一輪：互動地圖重做、飯店替換的流程、 票券跟飯店的詳情頁可以點進去看真實方案、只有可退款的才給你按取消， 還有行程帳本跟投票的小工具，AI 卡片也換成新版。

這些都是為了讓 demo 那支手機，體驗是連得起來、見得了人的。

聽起來今天其實蠻豐收的。 那……昨天那個把行程清空的洞，到底補了沒？ 你到現在都還沒正面回答我。

我不騙你——到 demo 當天為止，那張票還躺在待辦清單裡。 根因寫得非常清楚、修法也設計好了，就是把那道護欄升級成三條寫入路徑共用、 對 AI 一樣硬擋的不變量；

但它排在那個收斂領域層的後段，今天還沒合併進去。 所以我們是帶著這個已知的缺口上場的。

哇。 所以理念寫得很漂亮，「AI 不能未經確認做不可逆的事」， 結果最會違反這條的那個洞，就這樣開著走進 demo。

這就是今天最誠實的地方。 我幫大家把大局收一下：今天不是一個「上線了什麼功能」的日子， 是一個「決定自己是什麼」的日子。

畢業的是——把行程寫入收斂成領域層、成本儀表上線、加密貨幣金流接通、 iOS 的 demo 面磨好，還有先鋪好的一整套 AI 重構安全網跟回合可見性守衛。

新開的票，也是今天的風險清單：最上面那張，就是還沒焊好的行程清空護欄； 接著是 AI 回合常常「不出聲」、語音助理把人數設得前後不一致害飯店整批賣光、

已經訂好的機票落地時間沒被當成當天排程的下界、自動套用的編輯還沒辦法復原， 還有旅程規劃器逾時跟語音辨識這些老票。

所以明天要追的，就是看那道門，什麼時候真的把洞焊起來。

沒錯。 今天他們把地基畫清楚了，明天就看骨架長多快。 明天同一時間，PickTrip 產品建造筆記，每日更新。

掰掰！