自動化

長期以來，AI 代理程式雖然能思考、能寫碼，但在作業系統與應用程式之間，總像隔著一層玻璃。透過 Obsidian 1.12.x 全新釋出的 CLI 工具，AI 終於擁有了能直接操作 UI 的「手腳」。

影像豐富化之路：從雜訊清洗到 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 化 為了讓這套邏輯不再只是「一次性腳本」，我們完成了以下優化： ...

寫在升級後： 剛整理完濁水溪的探索方法論 (SOP)，正準備發佈時，發現我的 AI 助手 Antigravity 也有了新功能——支援 Skill (技能) 系統。 於是，我順手請 AI 將原本單純的文字版 Task，升級為更具結構化的 Skill。這不僅是一次工具的迭代，更是 AI 協作模式的進化。 什麼是 Antigravity Skill？ 過去我們習慣用 Task (任務) 來告訴 AI 做什麼，通常是一份 Markdown 文件，寫滿了步驟與指令。 而新的 Skill (技能) 則更像是一個 「可執行的軟體包」。它不僅有說明文件 (SKILL.md)，還可以包含專屬的腳本 (scripts/)、模板 (templates/) 與範例。 簡言之，Task 是給 AI 看的「說明書」，Skill 則是給 AI 用的「工具箱」。 實戰：建立 River Exploration Skill 我請 AI 將剛剛總結的「河流探索工作流」封裝成一個 Skill。 AI 迅速在 .agent/skills/river-exploration/ 建立了以下結構： SKILL.md：核心 SOP，包含了我強調的「黃金時間 (The Golden Hour)」當日結算流程。 scripts/gen_map_urls.py：把之前散落在專案裡的 Google Maps 連結生成程式，收納為此技能專用的工具。 templates/blog_post_template.md：標準化的遊記 Markdown 模板，確保每次產出的格式一致。 Task vs. Skill：優缺點比一比 在實際體驗後，我對這兩種模式做了簡單的比較： ...