上一篇，我把 LINE Cafe Bot 原本的收藏功能，優化成一份可以查看、去重、安排時間和移除店家的「想去清單」。

這次我仍然和 Codex 一起完成實作。只是我們面對的已經不是「從零做一個新功能」，而是如何讓新功能進入既有 Bot，又不破壞原本的使用方式。

功能完成後，我很快又遇到下一個問題：

幾天後，使用者還記得要輸入「我的想去清單」嗎？

Rich Menu 並不是這次才做。

先前我已經替 Cafe Bot 做過四格 Rich Menu，放入找附近咖啡、查看偏好、設定偏好與使用說明。我也寫過 Rich Menu 圖片、點擊區域和部署方式，所以這篇不再重複從零建立選單的流程。

這次真正要處理的是：當 Bot 增加一個新功能，原本的介面要怎麼一起長大？

後來我發現，這其實不只是多放一個按鈕。整件事同時碰到三個層次：

功能層：想去清單能不能正常儲存與顯示？
入口層：使用者過幾天後，還找不找得到它？
上線層：後端功能和 LINE 選單能不能安全接在一起？

第一層在上一篇完成；這一篇要處理的是後面兩層。

完整程式碼與選單素材：
https://github.com/zonawang/line-cafe-wishlist

原本的四個入口都不能少

原本的選單是四宮格：

┌────────────┬────────────┐
│ 找附近咖啡 │  我的偏好   │
├────────────┼────────────┤
│ 設定偏好   │  使用說明   │
└────────────┴────────────┘

最省事的做法，是拿掉其中一格換成想去清單。

但這等於新增一個功能，同時讓另一個功能變得更難找。四個舊入口都有用途，我不想為了新功能犧牲原本的操作方式。

最後我保留上排兩個主要入口，把下排改成三等分：

┌────────────┬────────────┐
│ 找附近咖啡 │  我的偏好   │
├────────┬────────┬────────┤
│設定偏好│想去清單│使用說明│
└────────┴────────┴────────┘

「想去清單」放在下排中央。它不是第一次進入 Bot 時最先使用的功能，卻是使用者之後會反覆回來查看的地方，放在固定選單裡比藏在文字指令中合理得多。

我先想的不是按鈕，而是使用者怎麼回來

新增 wishlist handler 之後，功能在測試中確實可以運作。但測試時的我知道所有指令，一般使用者不會。

真正的使用情境更像這樣：

今天搜尋咖啡廳
      ↓
收藏其中一家
      ↓
離開聊天室幾天
      ↓
某天想找回那家店

問題往往出現在最後一步。

如果使用者必須記住「我的想去清單」六個字，這個功能其實仍然依賴記憶。Rich Menu 的價值不是讓畫面更豐富，而是替這段中斷幾天的旅程留下一個可以回來的入口。

完整路徑因此變成：

推薦卡收藏 → 離開聊天室 → Rich Menu 找回 → 查看清單 → 繼續安排

這也是我把想去清單放在中央的原因：它負責的不是第一次探索，而是之後的回訪。

這次沒有多做一套收藏流程

點擊想去清單後，Rich Menu 送出的內容很簡單：

我的想去清單

因為後端原本就有 wishlist text handler，可以處理同一句指令，所以不需要為 Rich Menu 再開一個特殊 API：

手動輸入「我的想去清單」 ─┐
                            ├→ wishlist handler → 顯示清單
點擊 Rich Menu ─────────────┘

這是我這次刻意保留的設計：入口可以有很多個，但真正執行功能的地方只需要一個。

使用者想打字，可以打字；不記得指令，也可以直接點選單。兩種操作最後走進同一條程式路徑，之後修改想去清單時，不必同時維護兩套邏輯。

真正要改的是第五個點擊區域

這次沿用原本 2500 × 1686 px 的 Rich Menu 尺寸。上排仍然左右各半，下排則要把 2500 px 分給三個入口。

2500 無法被 3 整除，因此下排寬度設為：

833 px + 834 px + 833 px = 2500 px

中間的想去清單多一個像素，讓三個點擊區域完整接在一起，不留下按了沒反應的縫隙。

這裡改的不只是圖片。Rich Menu 上看見的圖案是一份 SVG／PNG，LINE 實際判斷點擊位置則讀取 JSON。兩邊都必須從四格一起更新為五格，否則就可能發生「畫面上點想去清單，實際卻觸發旁邊功能」的問題。

更新既有選單，不直接破壞舊版本

雖然這次不是第一次做 Rich Menu，我仍然沒有直接在使用中的版本上冒險修改。

我的更新順序是：先準備五格 JSON 與圖片，檢查尺寸和檔案大小，再建立新版本、上傳圖片，最後才把它設成 default Rich Menu。

切換成功前，使用者仍然會看到可以正常操作的舊選單。舊版本也先保留下來；如果新圖片或點擊位置在手機上出現問題，還有快速切回去的空間。

這次想去清單的程式部署在 Cloud Run，Rich Menu 則更新在 LINE 平台。兩邊是不同的上線動作，因此順序也很重要：

先讓後端看得懂「我的想去清單」
                 ↓
再讓 Rich Menu 出現想去清單入口

這樣使用者看到新按鈕時，後端已經準備好回應，不會出現入口先上線、功能卻還不能用的空窗。

Codex 這次做的，不只是多加一個按鈕

如果只寫最後結果，很容易把這段過程簡化成「請 Codex 多加一格 Rich Menu」。但實際協作比這多了幾個來回。

一開始，Codex 先讀取原本的四格 Rich Menu 設定與這次新增的 wishlist handler，確認「我的想去清單」已經是後端能理解的指令。接著才把下排重新切成 833、834、833 px，讓第五個入口能沿用同一條處理流程。

接著，Codex 協助整理五格選單的圖片與 JSON，確認尺寸、檔案大小和五個點擊區域一致，再建立新版 Rich Menu、上傳圖片並切換 default。舊選單則先保留，避免新版本有問題時失去回復空間。

完成後，Codex 又從 LINE API 讀回目前的 default Rich Menu ID，確認正式使用的確實是剛建立的版本，而不是只看到 API 回覆成功就結束。

這段協作讓我很喜歡的一點是：我不需要先把需求拆成「請修改哪一段 JSON」或「請呼叫哪一支 LINE API」。我只要說明新功能需要一個固定入口，Codex 就能往下盤點既有功能、調整版面、修改點擊區域、部署並驗證結果。

想去清單應該放在哪裡、哪些原有入口不能被犧牲，仍然需要我從使用者角度做判斷；Codex 則負責把這個產品決定變成可以檢查、可以部署，也可以回復的修改。

這次的重點不是再做一次 Rich Menu，而是讓新功能被找得到

如果只看技術名稱，這次好像又做了一次 Rich Menu。

但對我來說，它其實是想去清單功能的最後一步。

先前完成 Rich Menu，是替當時已經存在的功能建立入口；這次則是在 Bot 長出新能力後，回頭更新既有介面，讓新功能正式成為產品的一部分。

這次沒有增加新的 AI，也沒有更換推薦模型。真正改善的是使用者不必記得指令，就能再次找到之前收藏的咖啡廳。

回頭看，這次一共補了三個容易被忽略的缺口：

• 功能和入口之間的缺口：想去清單完成後，同步更新原本的選單。
• 新舊版本之間的缺口：先讓後端上線，再切換 Rich Menu，避免入口和功能不同步。
• 圖片和點擊區域之間的缺口：五格版面與 JSON bounds 一起更新，避免畫面和實際操作錯位。

這些都不是新的 AI 能力，卻直接影響一個功能最後好不好用。

而 Codex 在這裡扮演的角色，也不只是產生程式碼。它把「增加入口」、「調整版面」這些看似零碎的要求，串成從盤點舊功能、修改素材、部署到驗證的一段完整流程。

功能被做出來是一件事；過幾天仍然找得到、用得下去，才是它真正留下來的時候。

本篇完整程式碼與 Rich Menu 素材

GitHub：
https://github.com/zonawang/line-cafe-wishlist

先前的 Rich Menu 實作文章：
https://medium.com/@zonawang/bot-%E5%8A%9F%E8%83%BD%E9%83%BD%E5%81%9A%E5%A5%BD%E4%BA%86-%E6%88%91%E5%8D%BB%E5%BF%98%E4%BA%86%E6%80%8E%E9%BA%BC%E7%94%A8-%E7%94%A8-codex-app-%E5%92%8C-sol-%E6%9B%BF-line-cafe-bot-%E8%A3%9C%E4%B8%8A-rich-menu-b330f837ca13

LINE Rich Menu 官方文件：
https://developers.line.biz/en/docs/messaging-api/using-rich-menus/