出門在外，肚子突然一陣絞痛，急需解放卻像無頭蒼蠅一樣找不到廁所。為了徹底解決這個攸關人類尊嚴的痛點，我決定自己動手，開發一款專屬的「廁所尋找小精靈」。

以下是這次專案的開發心得與踩坑紀錄，分享給對自動化工作流或 AI 應用有興趣的朋友！

🛠️ 系統架構與實作做法
整個系統的核心概念是「透過 LINE 傳送位置，AI 自動去政府資料庫幫你撈出最近的廁所」。

使用者介面： LINE Bot

核心自動化流程： n8n

資料庫： Supabase

資料來源： 環境部環境資料開放平台（全國公廁建檔資料）

大腦： AI Agent

運作邏輯：
在 LINE 上呼叫小精靈並提供所在地區 ➡️ n8n 觸發工作流 ➡️ AI Agent 讀取 Supabase 內建檔的全國公廁資料 ➡️ 篩選出距離最近的廁所並回傳給使用者。

🚧 開發血淚史：遇到的坑與解決過程
剛開始以為只要把資料串一串就好，結果實作過程中經歷了九九八十一難，花了好一段時間才把系統搞定。以下是幾個主要的踩坑點：

1.資料匯入的撞牆期：
一開始想把環境部的 CSV 龐大資料直接硬拉進 n8n 裡，但完全不知道怎麼處理。苦惱了很久後，終於發現了 Supabase 這個救星，可以把 CSV 轉成易於讀取的關聯式資料表，再拉進 n8n 處理。

2.資料庫連線障礙：
剛架好 Supabase 準備串接時，憑證驗證一直打不過，連線頻頻失敗，光是搞定授權就耗費了不少心力。

3.Token 爆量與抓不到資料：
前期串接 AI Agent 時，因為一次塞了太多公廁資料進去，導致 Token 量瞬間爆掉；有時候又會發生資料完全抓不到的窘境。

4.變數與型態衝突：
在 n8n 處理資料流時，遇到了各種 Data Type 不匹配的衝突，只能一步步除錯轉換型態。

5.「臺」與「台」的世紀難題：
遇到了台灣地址特有的同義字問題！使用者輸入「台北」，但資料庫裡是「臺北」，導致 AI 判定字串不符而找不到廁所，後來特別針對同義字偵測做了解決。

6.過度篩選 (Over-filtering)：
為了讓結果更精準，一開始的篩選條件設得太嚴苛，導致明明附近有廁所，系統卻一直回傳找不到，最後重新調整了 AI 檢索的寬容度才解決。

。