影像豐富化之路：從雜訊清洗到 AI 自動化的 POI 補補完實錄

📸 前言：一張圖勝過千言萬語

在開發 WalkGIS 的過程中，我們發現一個「有溫度的點位」必須包含視覺元素。然而，當點位數量來到數百甚至上千個時，手動去一張張找圖、貼連結是不可能的任務。更具規戰性的是，原始資料中的點位名稱往往帶有大量管理雜訊（如「住-」、「推薦-」、「集章處－」），這些「髒資料」會讓搜尋引擎徹底失焦。

本文記錄了我們如何利用 AI 協作，從 0 到 1 打造出一套自動化的「POI 影像豐富化」流程，並將之封裝為一套可重複使用的技術 Skill。

🛠 演進工序：解決問題的三大步

1. 構建「階梯式」搜尋隊列 (Tiered Retrieval)

單一來源往往無法滿足多樣的地景需求。我們設計了一套「階梯式」策略：

• 第一層：Wikipedia PageImage API —— 針對權威性景點（如「台江國家公園」），直接抓取維基百科條目圖片，準確度最高。
• 第二層：Wikimedia Commons API —— 利用共享資源庫，透過多重名稱變體（如 File:{Name}, {Name} Taiwan）進行廣泛搜尋。
• 第三層：Google Places API (最強後援) —— 當開源資源都失效時，調用 Google Places Photo。這確保了即便是在山區的小型「工作站」或「民宿」，也能有高質量的實景照片。

2. 語意理解：LLM 驅動的名稱清洗 (Name Sanitization)

這是最核心的突破。面對 住-護照優惠-特富野民宿 這種名稱，傳統的正則表達式很難清乾淨。

• LLM 預處理：我們讓 AI 批量讀取點位名稱，並產出「搜尋關鍵字陣列 (Array of Search Seeds)」。
• 映射機制：例如將 山海驛站-官田工作站 自動對應到 ["官田工作站", "農田水利署官田工作站"]。
• 規一化匹配：為了避免 mapping 時因為全半形符號（如 ｜ vs |）或多餘空白導致失敗，我們在腳本中實現了名稱規一化演算法。

3. 工程化與 Skill 化

為了讓這套邏輯不再只是「一次性腳本」，我們完成了以下優化：

• 斷點續跑 (Resuming)：支援 -s 參數，從指定的點位繼續執行，避免大型地圖處理中斷。
• 智能覆蓋 (Overwriting)：支援 --all 參數，當 Mapping 修正後，程式會自動精確替換 Markdown 內的 cover_image 與圖片標籤，避免內容過於混亂。
• Skill 封裝：將整套流程封裝為 poi-image-manager Skill，未來任何新地圖只要下指令，兩分鐘內就能完成影像豐富化。

💡 關鍵洞察：AI 協作的新範式

在這次開發中，我（USER）與 AI（Antigravity）的角色分配如下：

1. 策略定義：USER 辨識出「雜訊」是痛點，並提出「階梯式搜尋」的想法。
2. 邏輯實現：AI 快速產出多階層搜尋代碼，並處理複雜的 API Rate Limiting。
3. 優化循環：當搜尋出錯（如搜到奇怪的 PDF）時，USER 指出問題，AI 進一步強化「關鍵字變體」與「覆蓋機制」。

🏁 最終成果

以「山海圳國家綠道」地圖為例：

• 總點位 109 個。
• 成功率：透過這套流程，原本 70% 找不到圖或圖不對的點位，現在都換上了精確的實景封面。
• 地景呈現：從海邊的「台江遊客中心」到深山的「排雲山莊」，點位開展之後不再只有文字，而是豐富的視覺轉置。

影像豐富化不只是為了好看，更是為了提供旅人最直覺的場域認知。現在，這套工作流已經成為我們「河流探索」基礎設施的一部分。

協作紀錄：

• 策劃: USER
• 執行: Antigravity (AI Coding Assistant)
• 技術棧: Python, Wikimedia API, Google Places API, YAML, SQLite
• 完成日期: 2026-02-03