Workflow

「Skill 優先」的 AI 協作新實踐：從需求定義到知識點萃取的自動化進化 🚀 序言：一個新的協作節奏 在過去的 AI 協作中，我通常是先遇到問題，發出指令，解決之後再考慮是否要將它整理成工具。但這一次，我試著調換順序：先說出一個「Skill」的構想，定義它的通用流程與腳本格式，然後直接用它來演練並修正。 這次的目標是：如何高效地將長達一個多小時的「哈爸實驗室雙周會」錄影，拆解成一個個有價值的「知識點 (Knowledge Points)」。 🏗️ 第一步：Skill 的定義與構建 (Defining the Skill) 與其說「幫我切影片」，我對 AI 下達的指令是：「我們來做一個 knowledge-point-distiller Skill」。這個 Skill 必須具備以下完整閉環： 影音處理自動化：能根據時間清單自動切割影片，並同步產出適合 NotebookLM (容量 < 20MB) 的優化 MP3。 資源歸檔結構化：每一個知識點 (KP) 都有自己的資料夾，包含 MP4 片段、MP3 音訊與 metadata.md。 SOP 化：將整套流程寫入 .agent/skills/ 目錄下的 SKILL.md，讓 AI 與我都能隨時查閱操作標準。 這種「先建工具，後打仗」的做法，讓我在還沒開始處理影片前，就已經擁有了整套「生產線」。 🧪 第二步：實戰演練與即時修正 (Practice & Refinement) 有了工具後，我們直接拿「2/6 哈爸實驗室雙周會」進行測試。這個階段的「修正」是重點： 全場音訊的需求：在切割子片段的過程中，我發現除了個別知識點，我也需要一份「全場完整錄音」上傳到 NotebookLM 進行全局綜整。於是，我們立刻將這個功能補進 Skill 的 SOP 中。 與 Git 的整合：歸檔不是終點，提交才是。我們在 Skill 流程中補上了 GitHub 的 Commit 與 Push 指引。 跨 Skill 調度：在這個過程中，新的 Skill 自動調用了先前的 media-processor Skill 來處理高品質音訊壓縮，展現了技術模組之間的協同能力。 💡 關鍵體驗：為什麼「先說出 Skill」很有用？ 這是我第一次嘗試「先定義、再運作、後修正」的模式，心得如下： ...

寫在轉化後： 我們與 AI 的對話往往像是一場漫長的淘金。在過去幾週的「河流探索」專案中，我與 AI 助手累積了數百次關於 GIS 處理、水利考掘與行程規劃的對話。這些對話中隱含著極高的「專業 SOP」，但若不加以整理，它們終將沉沒在歷史紀錄中。本文記錄了我如何讓 AI 「自我解構」，將對話轉化為持續賦能的 Agent Skills。 1. 發現遺產：在廢墟中尋找規律 隨著曾文溪、濁水溪探索的展開，我發現每次規劃時，AI 都要重新理解一次我的需求： 「我要生成 Google Maps 連結」 「我要將點位寫入 walkgis.db」 「我要撰寫帶有水利深度的 Blog Post」 這些重複性的動作，就是 「技能化」 的最佳候選者。我讓 AI 回頭檢視我們的對話紀錄，問它：「在這些對話中，有哪些動作是你反覆在幫我做的？請把它們解構出來。」 2. 技能封裝 (Skill Encapsulation)：定義專業邊界 這是我覺得最驚艷的部分。AI 並不只是給我一份總結，而是協同我建立了具體的「技能包 (Skills)」目錄： gis-data-manager：封裝了標記 POI、WKT 轉換與資料庫同步的腳本。 river-exploration：封裝了從 Phase 0 (資料準備) 到 Phase 3 (深度解析) 的完整河流探索指引。 hugo-content-wizard：專門處理「筆記轉部落格」的繁瑣格式。 我們定義了具體的 SKILL.md，這就像是賦予了 Agent 一本「標準作業手冊」。 3. 無痛轉入手感：從「手工業」到「自動化導航」 當這些技能被定義後，我再次發起任務（如這次的「蘭陽溪考掘」）時，感覺完全不同了： 溝通簡化：我不再需要解釋怎麼存資料庫，只需要說「執行 gis-data-manager 的同步邏輯」。 品質躍升：因為 SOP 已被明確化，AI 會自動執行「豐富化對話」、「異常偵測」等高階動作，產出的內容從原本的「行程表」躍升為「水路歷史考掘計畫」。 這種感覺就像是，你不用再教廚師怎麼切菜，你只需要給食材並說出你想吃的菜系，廚師已經具備了全套精湛的刀工與調味邏輯。 結語：讓 AI 成為你的肌肉記憶 這次的實驗讓我理解到，AI 的強大不在於它「懂得多」，而在於它能透過我們的引導，將「偶然的成功」沉澱為「必然的技能」。當對話不再是消耗，而是累積成一套不斷成長的 Agent Skills 時，數位賦能才真正發生。 ...

前言： 在完成了四天三夜的濁水溪溯源之旅後，許多朋友好奇：如何在有限時間內，規劃出如此深度且具備彈性的行程？ 其實，這不僅是一場旅行，更是一次 AI 協作 (AI-Augmented) 的實驗。我將這次的經驗提煉成一套標準工作流（SOP），分享給所有熱愛探索與科技的朋友。 現代探險家的數位工具箱 過去的探險家靠的是羅盤與手繪地圖；現代探險家則擁有強大的數位孿生工具： GIS 系統 (WalkGIS)：提供地理空間的骨架。 生成式 AI (LLM)：充當知識淵博的嚮導與秘書。 數位筆記 (Hugo Blog)：結構化記錄與歸檔。 這套方法論分為四個階段，形成一個從虛擬到實體，再回到虛擬的閉環。 階段一：數據鋪墊 - 建立地理認知 (Data Preparation) 在出發前，我們必須先「看見」這條河流。 數位孿生基礎：利用 GIS 技術提取流域範圍、河道、堤防與水利設施。這讓我們知道哪裡是「可以走的路」，哪裡是「值得看的點」。 興趣點豐富化 (Enrichment)： AI 可以在這裡發揮大用。我使用腳本串接 Google Places API，沿著河岸搜尋「補給點」（車宿洗澡點、美食）與「文化點」（古蹟、廟宇）。 這個步驟將冰冷的經緯度，轉化為有溫度的旅行節點。 階段二：行程規劃 - AI 協作草案 (Planning) 有了數據，接著是規劃。這不是寫死板的時刻表，而是建立一個「有邏輯的劇本」。 主題分段：我們將濁水溪切分為「海口信仰」、「橋梁水利」、「生態電力」、「山湖騎行」四個主題。 撰寫計畫文 (The Plan)： 我會要求 AI 根據上述數據，草擬一份 Blog Post (行前計畫)。 AI 的角色：它負責串聯景點邏輯（如：先吃肉圓再去冰店順路嗎？）、計算時間，並生成 Google Maps 的多點導航連結。 這時候的筆記標題通常標註 (行前計劃)，內容包含「預定行程」與「AI 協作聲明」。 階段三：實地探索 - 彈性與感知 (Execution) 帶著計畫上路，但要把心打開。 彈性執行：地圖是死的，路是活的。西螺大橋封路怎麼辦？鳥嘴潭來不及去怎麼辦？AI 的計畫提供了骨架，但現場的應變才是靈魂。 多感官記錄： 數位軌跡：開啟 ATAK 或運動記錄 APP，留下真實的 GPX。 當下紀錄：利用錄音或快速筆記，記錄當下的感受（例如：電輔車的隱形推力、九蛙疊像的實際水位）。這些細節是回家後寫不出來的。 黃金時間：當日結算與發佈 (The Golden Hour) 這是我認為長期旅程能持續下去的關鍵：絕不拖延。 ...

寫在升級後： 剛整理完濁水溪的探索方法論 (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：優缺點比一比 在實際體驗後，我對這兩種模式做了簡單的比較： ...

最近在整理舊檔案時，翻出了一個好幾年前製作的 ATAK 地圖擴充包 (ATAK-Maps-LASS.zip)。這個懶人包當年整合了 Google、Bing、以及最重要的台灣通用電子地圖與魯地圖，為了讓團隊能快速在 ATAK 建立共同的圖資環境。 沒想到興沖沖地匯入新版 ATAK 後，卻發現無法讀取，甚至連最關鍵的魯地圖都無法顯示。 於是我請了 AI 助手協助除錯，沒想到短短幾分鐘內就找出了結構性問題與連結失效的原因，並協助重新打包修復。這篇文章簡單紀錄一下這次的協作修復過程，並分享這個「復活版」的地圖包給大家。 修復過程：AI 如何解決問題？ 1. 修正 ZIP 結構問題 一開始匯入失敗的原因，是資料夾結構多了一層。 原本結構：ATAK-Maps-LASS.zip -> ATAK-Maps-Map/ -> Taiwan_map/ … 正確結構：ATAK 要求資料包的內容（XML 設定檔）必須直接位於壓縮檔的根目錄。 解決：AI 自動協助將目錄攤平並重新打包。 2. 魯地圖 (Rudy Map) 網址失效 這是最棘手的部分。原本的設定檔使用的是 http://rudy.tile.basecamp.tw，但發現： HTTPS 限制：現代 Android 系統與新版 ATAK 預設阻擋明文 HTTP 連線。 DNS 解析失敗：該網址目前似乎無法穩定連線。 解決：經過 AI 搜尋與測試，找到了由 Happyman 維護的穩定鏡像站，並支援 HTTPS 加密連線。我們將設定檔更新為： <url>https://tile.happyman.idv.tw/map/moi_osm/{$z}/{$x}/{$y}.png</url> 地圖包內容與特色 這個修復後的 Data Package 包含了多種實用的線上圖資來源，適合登山、搜救或戶外活動使用： 🇹🇼 台灣在地圖資 (Taiwan_map) 這是此包的精華，針對台灣使用者最佳化： TW_RUDY (魯地圖)：登山界必備神圖，包含詳盡的等高線、地形渲染與登山路徑（已更新為 Happyman Mirror）。 TW_EMAP (臺灣通用電子地圖)：內政部國土測繪中心官方圖資，準確度最高，林道與地標資訊豐富。 TW_PHOTO (正射影像)：高解析度的台灣航照圖。 TW_B5000 (1/5000 基本地形圖)：適合需要精密地形判讀的場景。 🌍 全球主流圖資 Google Maps： Hybrid / Satellite：衛星影像與混合圖（含路名）。 Terrain：帶有陰影的地形圖。 Roadmap：標準街道圖。 Bing Maps：微軟的衛星與街道圖，有時在山區的雲層遮蔽狀況比 Google 好。 ESRI： World Topo：ArcGIS 的地形圖，風格精美。 Nat Geo：國家地理雜誌風格地圖。 OSM (OpenStreetMap)： Standard：標準開源地圖。 CycleOSM：強調自行車路徑的版本。 OpenTopoMap：基於 OSM 的等高線地形圖。 下載 下載 ATAK-Maps-LASS_Fixed.zip 註：本資料包僅包含 XML 連線設定檔，需在有網路的環境下瀏覽（ATAK 會自動快取瀏覽過的圖磚供離線使用）。 ...

很多精彩的想法都消失在會議室的空氣中？本文分享我的一套 GenAI 工作流：從手機錄音開始，透過 Google NotebookLM 生成摘要與圖表，再經由 Agentic AI (Antigravity) 改寫，最後自動部署到個人的 Hugo 網誌。這是一條讓「隨機討論」快速變成「結構化知識」的高速公路。

本實驗記錄了如何透過 Python Fabric 構建中間層來驅動 Google Gemini CLI，解決直接操作命令列時遇到的轉義字元問題、日誌雜訊干擾，並實現模型參數的靈活配置。