上一篇，我讓 Cafe Bot 學會在正確時間主動提醒。

使用者可以收藏咖啡廳、安排時間，然後說一句「週六下午兩點去第二間，提前一小時提醒我」。時間到了，Bot 會自己傳 LINE 訊息。那一版解決的是「別忘了去」這件事。

但提醒功能上線後，我發現另一個更日常的問題：Bot 已經記得我什麼時候要去，卻還不知道我想去什麼樣的地方。每次傳送位置，它都像第一次見到我一樣重新推薦。

有人想找安靜、可以工作的地方；有人在意甜點；也有人只是下班後想找一間走路就到、能坐晚一點的店。如果每次都重新說一遍，推薦功能再準，也很難讓人想一直用。

所以這次我替 LINE Cafe Companion 加上的功能很單純：記住使用者自己明確設定的咖啡偏好，並在下一次分享位置時套用。

換句話說，上一篇讓 Bot 能可靠地記住未來答應過的事；這一篇，則是讓它開始記住眼前這個人的選擇。這篇只記錄這次新增的偏好記憶功能，以及我第一次用 Codex Terra 完成它的過程。

如果你還沒看過上一篇，可以先從這裡開始：我收藏了咖啡廳，還是會忘記去：我和 Codex 讓 LINE Bot 在正確時間主動提醒我。

使用者實際會怎麼用？

操作不需要填表單，直接在 LINE 裡說話就行：

設定我的偏好：安靜、有插座、適合工作

Bot 會先把它理解成結構化的偏好，再回覆確認按鈕。按下確認後，使用者下次傳送位置，推薦結果就會優先考慮這些條件，並清楚顯示：

已套用你的偏好：安靜、有插座、適合工作

偏好也可以自己管理：

查看我的偏好
移除有插座偏好
清除我的偏好

我刻意讓「設定、移除、清除」都多一道確認。偏好雖然不是什麼高風險資料，但一個聊天 Bot 最好不要因為一句模糊的話，就默默改掉使用者的資料。

第一版沒有做「猜你的喜好」

一開始我有想過：能不能從聊天紀錄、收藏或行程自動推測使用者喜歡什麼？

這種做法聽起來很聰明，實際上卻容易讓人不舒服。使用者收藏一間店，不一定代表他喜歡它；也可能只是先記下來。更重要的是，如果 Bot 自己改了偏好，使用者很難知道推薦為什麼變了。

因此第一版只接受使用者明確說出口的偏好。可選項目包含：

• 安靜、適合工作
• 有插座、有 Wi-Fi
• 有甜點、寵物友善、深夜營業
• 平價、步行優先

這樣的好處是資料小、行為可預期，也容易讓使用者隨時查看與刪除。

技術上，偏好不是一段自由文字

雖然使用者看到的是「安靜、有插座」，程式裡不直接儲存這段句子，而是轉成固定的 key，例如：

type CafePreference =
  | 'quiet'
  | 'work_friendly'
  | 'outlets'
  | 'wifi'
  | 'desserts'
  | 'pet_friendly'
  | 'late_night'
  | 'budget'
  | 'walkable';

這個小決定很重要。固定 key 可以避免同一件事被存成「安靜」、「安靜一點」、「不要太吵」三種不同資料；也讓之後的刪除、顯示和測試都比較可靠。

當使用者傳來文字時，Gemini Function Calling 只負責判斷意圖和挑出合法的偏好 key。真正寫入 Firestore 的動作，仍由後端在使用者按下確認後執行。

資料放在以 LINE userId 為主鍵的 Firestore 文件中。因此即使 Bot 在群組裡被使用，A 設定的偏好不會跑到 B 身上；群組中的推薦會使用「傳送位置那個人」自己的設定。

偏好怎麼影響推薦，又怎麼避免亂講？

位置推薦仍然使用 Google Maps Grounding。這次新增的是：在發出推薦請求時，把已保存的偏好一起帶進提示，讓模型優先尋找符合條件的店。

不過「優先找」不等於「替店家補資料」。像插座、Wi-Fi、安靜程度這些資訊，不是每一間店的 Google Maps 資料都會明確寫出來。

所以我在提示裡加了一條規則：只有 Google Maps Grounding 有支持時，才可以把某個偏好說成店家的事實；資料不足時，必須坦白說無法確認。

這比列出一長串看似貼心、實際上不可靠的推薦理由更重要。對使用者來說，能知道「這件事目前查不到」往往比收到一個猜測更有用。

整個流程可以簡化成這樣：

LINE 自然語言
    ↓
Gemini Function Calling 判斷偏好操作
    ↓
LINE 確認按鈕
    ↓
Firestore 保存個人偏好
    ↓
下一次傳送位置
    ↓
Google Maps Grounding 依偏好優先推薦

這次為什麼改用 Codex Terra？

上一篇做提醒功能時，我使用的是 Codex Sol。這次則刻意改用 Codex Terra。

原因不是要把 Terra 當成 Sol 的替代品，而是這個需求的性質很適合它：範圍清楚、可以拆成幾個獨立步驟，而且每一步都能驗證。

我把工作切成幾段：先定義偏好 key 和顯示文字，再補 Firestore 的讀寫，接著擴充 Function Calling、LINE 訊息與地圖推薦，最後加上單元測試、部署 Cloud Run、切換 webhook 並在手機上測。

依照 OpenAI 官方文件，Sol 是面向複雜程式、電腦操作、研究與安全工作的旗艦模型；Terra 則定位為日常工作中能力與成本的平衡選項。

我的實際感受是：對這種有明確邊界的功能，Terra 很適合拿來完成「讀既有程式、跨檔案修改、補測試、部署與檢查」這整段工作。它不是少思考，而是把思考放在資料模型、確認流程和驗證上，而不是把功能做得過度複雜。

如果今天要處理的是大型架構重整、難以定位的資安問題，或需要更深的研究與推理，我仍會傾向選 Sol。但像這次的偏好記憶，Terra 是很務實的選擇。

最後：記憶不是越多越好

上一篇讓 Bot 從「記住一家店」走到「記住未來答應過的事」；這次沒有再急著替它增加更多魔法，而是先讓它記得一份使用者看得見、改得掉、刪得掉的偏好設定。

對產品來說，這也許少了一點魔法感；但對一個會長期陪使用者找咖啡廳的 Bot 來說，清楚比神祕更重要。

下一步如果要做自動學習，我會把它做成建議，而不是自動寫入。例如 Bot 可以問：「你似乎常選適合工作的店，要不要把『適合工作』加入偏好？」讓決定權始終留在使用者手上。

專案開源與完整程式碼

👉 GitHub：https://github.com/zonawang/line-cafe-companion
👉 更多 LINE Bot 與 AI 實作紀錄： https://github.com/zonawang/zona-ai-learning-lab