讓 AI 排行程，但不讓它編景點：Elsewhere 的資料庫模式

Elsewhere 是我做的 AI 行程規劃工具：在 3D 地球上轉到想去的地方，點選，AI 幫你排成一趟順路的旅程，涵蓋 171 個國家。做這個工具之前，我先用普通的聊天介面請 AI 排過幾次行程，也因此看見最大的問題。

最危險的錯誤，是看起來很合理的錯誤

模型排出來的行程通常流暢、有邏輯，甚至語氣很有說服力。但當你拿其中的餐廳名稱去地圖上搜尋，有時候就是查不到：那家店可能早就歇業，也可能根本從沒存在過。景點的開放時間、飯店的位置，也有類似的狀況。

這種錯誤的麻煩在於，它不像亂碼那樣一眼就能看出來。使用者要到了現場、站在不存在的店門口，才會發現被騙了。

兩種模式

我的解法是把「找資料」與「排行程」拆開，讓兩種工作各用適合的方式：

資料庫精準模式（日本、韓國、越南、泰國）：景點、飯店、餐廳都先存進 D1 資料庫，AI 只能從資料庫提供的候選清單中挑選與排序，不能自己新增項目。它負責的是動線、天數分配與組合，而不是憑空生出店名。清單不夠用時才允許補充，而且補充的項目會被標示成「AI 補的」，讓使用者知道哪些需要自己再確認。

AI 知識模式（其他國家）：沒有資料庫可以依靠，就用模型本身的知識。這個模式我會明確讓使用者知道它的可信度較低，需要自行查證。

為什麼不全部做成資料庫模式

因為資料庫的建置成本很高，每個國家都要整理、更新、維護。我先挑旅客最多的四個國家做深，其餘的用 AI 知識撐住覆蓋範圍。誠實標示兩種模式的差別，比假裝每個國家都一樣可靠更重要。

其他幾個細節

• 拖曳編輯：AI 排出來的行程只是草稿，使用者可以直接拖曳調整順序，因為最了解自己想要什麼的還是使用者。
• Google Maps 動線導航：排好的行程可以一鍵轉成地圖路線，實際走起來才知道順不順。
• 短網址分享：行程可以產生分享連結，結果會存進快取，同樣的查詢不用重複請 AI 生成。
• 每日生成上限：AI 呼叫是有成本的，所以我設了每日上限，並用快取降低重複花費。

把 AI 當成「排序者」而不是「資料來源」

這個專案讓我形成一個習慣：先問自己，這個任務裡哪一部分需要「事實」，哪一部分需要「判斷」。事實應該來自可以查證的資料，判斷才交給模型。分清楚之後，AI 的失誤範圍就會小很多，因為它最壞也只是排得不夠順，而不是推薦一家不存在的餐廳。

想看看實際效果，可以到 Elsewhere 轉一轉地球。