VibeCoding 實作：自動篩選Email傳到 LINE群組

計畫

想解決的問題

當顧客透過我們的系統完成預約後，系統會發送 email 通知給商家(我們的客戶)有新的顧客預約了。商家希望可以直接在 LINE群組中收到通知，更方便分派工作，也節省查看 email 的時間。

由於這項需求不在開發團隊的優先項目之中，加上這個場景還需要研究 LINE Messaging API的機制，短期內無法實現。

為了提供替代解法，同時在沒有工程師的情況下提供服務，本次的目標是透過Vibe Coding+部署在免費功能上，作為加值服務提供給我們的客戶。

目標流程

1. 當收到特定寄件者與主旨的email 時，觸發 Gmail API 與後續流程
2. 透過Google Google Cloud，解析與處理email 內容
3. 再透過串接LINE Messaging API，將整理後的訂單內容發送到 LINE OA帳號所在的特定群組

費用與限制

1. Gmail API 與 GCP 使用量不會超過免費額度
   -> 根據 Claude 計算，GCP Cloud Function 每天超過 66,666 封或是 每小時超過 2,777 封 email 才會超過免費額度。
2. LINE Messaging API 不會超過免費額度
   -> 應該是最先會碰到的限制，不過現在可以先用免費的輕用量方案。

實際執行

預計分成2個步驟：

1. 設定GCP，串接 Gmail 並解析 Email內容
2. 串接 LINE Messaging API 發送訊息

1. GCP設定 -> 失敗。改成用 Apps Script

這是我提供給 Claude 的第一個 Prompt：

我想打造一個功能，流程如下： 
1. 當收到特定寄件者與主旨的email 時，觸發 Gmail API 與後續流程 
2. 透過在 GCP 部署的功能，解析與處理email 內容 
3. 透過LINE Messaging API，將整理後的訂單內容發送到 LINE OA帳號所在的特定群組 
 
我已建立好全新的GCP專案與LINE功能。 
 
你的第一個任務是引導我完成 GCP專案上的建置與產生程式碼。 
在這個階段不需要和LINE串接，目標是在我的信箱收到特定 email 後，判斷並解析email 的內容。 
我會透過產生實際訂單email進行測試，此階段的目標結果是讓我可以透過 Log 或其他方便驗證方式讓我確認email 有被正確判斷且能解析出我要的資訊，為下一個階段發送訊息做準備。 
 
我的email 是 xxxxx@xxxxx.com.tw 
 
我要搜尋的訂單email 寄件者固定為「no-reply@xxxxx.com.tw」，主旨固定為「您的預約已建立」。 
信件內容範例： 
「您有新的預約 
代號：51912店名：Alfred 正式店 姓名：123電話：123123123信箱：日期：2025/08/15 星期五時段：13:00人數：2 人預約狀態：確認預約 
備註未填寫」、 
「您有新的預約 
代號：51704店名：Alfred Test Staging分店姓名：123電話：123123123信箱：日期：2025/04/10 星期四時段：10:00人數：1 人預約狀態：確認預約 
備註未填寫」、 
「您有新的預約 
代號： 41707 店名： Alfred 測試店 阿福1號分店 姓名： 111 小姐 電話： 111111111 信箱： 日期： 2025/03/25 星期二 時段： 00:00 人數： 1 人 預約狀態： 確認預約 備註 未填寫」 
 
我希望產生的功能可以讓我更彈性的在程式碼中去設定收件的email、寄件email、或主旨等作為參數。 
同時我希望經過程式處理的email 會被貼上email 標籤，例如「已同步至LINE Bot」。如果原本gmail 中不存在這個標籤，就先建立標籤。 
 
因為目標是產生即時的處理，所以不會處理歷史的信件。假如在非常短時間內收到兩封以上訂單email，則都會個別處理。 
 
因為我是GCP新手，請導覽我在GCP英文介面中完成所有設定。 
 
在執行以前，請先和我確認你是否還需要更多資訊或決策，或是針對整體流程提出建議。

實際開始執行後，Claude 確實開始引導我如何在 GCP 進行設定，但這時碰到幾個問題：

1. 我設定的憑證無法通過 -> 這是放棄這個方案的關鍵點，花了很多時間我無法搞定，我也沒有能力處理。
2. Claude 給的指定和 GCP 介面有出入，可能用到不是最新的功能，例如 已經沒有Cloud Function 、得改用新版的 Cloud Run。 -> 這花了我不少時間摸索，也可能是在個環節出錯。
3. 需要在本地端終端機進行一些設定，這超過我目前的能力，我連了解問題是什麼都沒辦法。

為了解決困境，我選擇使用之前用過的 Apps Script 進行部署，詢問過 Claude 後也評估是可行的方案，考慮點：

• Apps Script 的極限是每分鐘排程抓取一次資料，和一開始預想的即時通知不同。 -> 判斷可以接受一分鐘到幾分鐘的通知延遲。
• 部署更簡單，和Gmail 生態也有很好的整合。
• 在我的使用量內一樣是免費服務。

轉戰 Apps Script 後就順利很多，在這個階段我給 Claude 的階段目標是能成功爬取目標的 email ，並解析內容。

解析 email 沒問題後，接著進入下一個階段。

2. 建立 LINE OA 和 LINE Developer 帳號

要發送 LINE 通知給別人，一定得有個 LINE OA / LINE Bot 才行。

根據 2025/8/14 的截圖畫面，建立 LINE Bot 要使用 Messaging API，一定要先建立一個 LINE OA 帳號來開通。

由於我之前已經有建立好免費的 (灰盾) LINE OA帳號了，啟用 Messaging API後，可以找到我的 LINE Developer 帳號完成連結，並取得 Channel ID 跟 Channel Secret，會自動存到 LINE Developer 的 Channels 設定當中。

完成設定後，接著跟著 Claude 逐步完成 LINE Messaging API 的設定，包含前面提到的用安全的方式儲存 Channel ID 和 Channel Secret，以及設定 Webhook 。

就算完全沒設定過，因為步驟很少，只要找得到對應的名詞，以及逐一檢查重點的幾個設定要開還是關，反而沒碰到什麼困難。

其中有個步驟是要先將 LINE OA 帳號加入到某個對話群組當中，發送任何一組訊息後，再透過 Apps Script 中發動寫好的 functions 與 Webhook 捕捉 channel ID，這個 ID 我想成類似收件人地址，也就是儲存後讓程式知道未來我的訊息要發到哪裡。

這些一次性的設定在操作時我只想到要先讓他能成功連接，在完成後才回過頭來請 Claude 整理成操作步驟的說明，目的是未來要拓展我的服務，例如接到多組不同 LINE OA或群組時，這些就是人工要處理的部分，最好能標準化的執行。

回顧與後續

整個服務成功打通後，除了個人成就感之外，這次在和團隊分享時也獲得幾點正面的反應：

1. 對於「需求」和「解法」的關注度和理解程度提升：以往這些需求可能只存在口語表達，就算再怎麼仔細的表達，在當下或過一陣子討論時，還是會發現對於實際想怎麼做、解決什麼問題會有出入。有更明確的Prototype，甚至直接把服務做出來，看得懂才會有興趣，而且還能更專注在想像這能如何優化、甚至忍不住動手幫忙。
2. 士氣跟可能性：雖然是土炮式的開發了一個功能，但最後還是一個可以運作的功能。對於工程師來說應該有更高的要求，但對於麻瓜PM來說這代表有更多實現事情的可能性。先求有再求好的致命傷往往是無法交付夠快，無法收到回饋，收到回饋也沒有資源優化，最後弄成四不像。在資源有限的情況下，許多事情克服靜態摩擦力後，「滾動式修正」才能真的滾動起來。滾起來，才不會每次看到大餅都只能眼神死。
3. 經驗累積 & 生產力的提升：一旦成功過一兩次，其實更容易去想像 AI或任何工具能為自己辦到什麼。這次的經驗源自於我先打造了一隻 Apps Script 來幫我將 email 中收到的表單回饋填寫到 Google Sheet 上。這個經驗讓我這次在操作 Apps Script 時順暢很多，也更知道如何與 Claude 合作，而下次我想我會嘗試更多 LINE API 的可能性。團隊看到這些實際案例後，也會更能思考那自己能夠多做些什麼，改變是會傳染的。

以我個人來說，過程中有得到幾個不錯的 Practice：

1. 讓 Claude 負責產生程式碼，貼給 Gemini 做 Code Review 與安全性的評估，再把 Gemini的建議貼回去給 Claude 修改。來回之下我的程式碼變得更乾淨，應該也更有效率和堅固。
2. Google 相關的問題，問 Gemini 能得到更新、更完整的資訊。
3. 思考儲存重要參數的方式，例如 Gemini 建議用 PropertiesService 加密重要的 API Secret 等資料。可以透過一次性的 Function 把重要資料加密後，不讓這些資料以全裸的方式存在我的程式碼當中。
4. 考慮未來正式部署和複製的情境，除了快速驗證想法之外，也要為了成功驗證後的下一步做打算。
5. 心態上的強化，要相信自己真的能把東西做出來。而且就算碰到障礙，還會有替代解法可以突破。重點是維持前進下去的動力，持續嘗試。