Automation

在實現 QGIS 專案「一鍵生成」的路上，我們不僅要讓圖層「開得出來」，更要讓它「具備研究價值」。 這篇文章記錄了我們從 POC2 (樣式與標籤整合) 進化到 POC3 (空間分析與 SDM 紀律) 的完整心路歷程。這兩個階段分別解決了製圖中的「美學溝通」與「科學建模」兩大核心問題。 🎨 POC2：視覺精煉與動態標籤 (Visualization & Labeling) 目的：讓地圖「會說話」，透過自動化配置解決手動製圖中最繁瑣的排版工作。 在 POC1 成功掛載圖層後，我們發現原始的點位與線條在混亂的歷史底圖（如台灣堡圖）上極難辨識。POC2 的核心目標即是透過腳本，賦予地圖專業的視覺外觀。 1. 幾何感知的自動標註 (Geometry-aware placement) 我們實現了腳本對圖層類型的自動識別與對應配置： 點位圖層 (遺址)：自動採用 Centroid 配置，讓標籤精確落在遺址中心。 線段圖層 (河流)：自動切換為 Around Line (平行排列)，並預設帶有 0.5mm 的偏移量。這讓河名能順著水流蜿蜒，展現專業製圖感。 2. 跨平台字型與視覺消隱 (The macOS Fix) 我們在 POC2 中遭遇了字型相容性的重擊。原本預設的字型在 Mac 上會毀掉專案解析。最終，我們強制切換為 PingFang TC (萍方-繁)，並自動啟用了 0.7mm 白色光暈 (Text Buffer)。這小小的光暈，是讓地圖文字從花綠底圖中「浮現」出來的關鍵。 🛡️ POC3：空間分析中樞與 SDM 紀律 (Advanced Analysis & SDM) 目的：從「資料顯示」進化為「規律開發」，在不污染原始數據的前提下，自動生成分析模型。 當地圖變漂亮後，下一步就是「看見模式」。POC3 挑戰的是自動產出具有研究深度的分析圖層（如海拔區間與熱點圖）。 1. 恪守 SDM 紀律：絕對不改動原始資料 (Data Hub Snapshot) 開發者常為了分析方便，在原始 SQLite 裡建 View。但對歷史數據來說，原始碼應該是神聖的 (Holy Source)。 我們實作了「局部資料中樞 (Local Data Hub)」：腳本在產出專案的一瞬間，自動建立一個 poc_data_hub.db 快照。所有的 JSON 萃取、高程分區計算都只存在於這份快照中。原始 HGIS 資料庫保持 100% 乾淨，專案檔則是「可打包、可重製、可拋棄」的。 ...

在進行 HGIS（歷史地理資訊系統）研究時，我發現最耗時的往往不是分析數據，而是「準備地圖」。每次要開啟一個新研究，總要重複掛載百年歷史底圖、設定 KML 座標、調整 SQLite 的 SQL 篩選器…。 為了打破這個瓶頸，我發起了一場實驗：能不能像寫程式一樣，用「寫」的出一份 QGIS 專案？ 這就是我最近在推動的 軟體定義地圖 (Software-Defined Maps, SDM) 概念。 🏗️ 為什麼要自動化？ 如果你手動配置過 QGIS，你一定遇過這些崩潰瞬間： URL 特殊字元破壞專案：WMTS 的 URL 裡一堆 &，手動貼上 XML 常報錯。 座標系統 (CRS) 位移：明明設定了 WGS84，圖層卻飄到非洲西岸海面（座標 0,0）。 重複定義的勞力：每個專案都要重新分組（底圖、水理、點位），這應該交給機器人。 透過 Python + Jinja2 模板，我們可以把地圖專案變成可程式化的零件。 🛠️ 基本作法：Jinja2 零件化 核心思路是將 .qgs 專案檔（實質是 XML）拆解為模板。 我們建立了一個 base_project.qgs.j2，裡面預留了動態注入的內容： 層級化圖層樹：自動生成的分組。 資料源設定：SQL 篩選指令與檔案路徑。 空間參考系統：自動注入對應的 AuthID、Proj4 與 SRID。 最關鍵的「零件庫」是 GIS_KNOWLEDGE.yaml。它充當了 GIS 資源的「DNS 伺服器」，記錄了所有中研院底圖、本機 KML 與資料庫的 Metadata。 🚀 第一階段 POC：曾文溪 HGIS 數位中樞 在這次的 POC 中，我們成功實現了 Zengwen_HGIS_Hub.qgs 的一鍵產出： ...

在數位在數位開發與日常生活中，有些工具是經過深思熟慮後產生的，而有些則是「意外的產物」。Idea Pool (點子池) 的誕生，就屬於後者。這篇文章想分享的不是技術細節，而是那個開發當下的「Aha! Moment」—— 我們如何從一個單純的記錄需求，一氣呵成地演化出整套自動化生命週期。 1. 原本的初衷：捕捉那些「放鬆時的閃念」 最初的需求源於一個生活化的痛點：在生活放鬆的過程中，腦中常會有些不錯的 idea 突然冒出來，可能是對某個工具的優化靈感，或者是對文章結構的新構想。這些想法若不立刻記下來，三分鐘後就消失在記憶邊緣。 我大概描述了自己的想法與痛點，想開啟與 AI (Antigravity) 的討論。我大概描述簡單的想法與痛點，想要開啟討論，當時我腦中的想像還很模糊，可能只是一個簡單的紀錄功能，能讓我把初始想法大致描述記錄下來即可。 2. 驚訝的轉折：從「收納」到「成長」的架構 令我驚訝的是，當我們開始討論「怎麼存」時，AI 並沒有止步於建立一個文本檔，而是直接拋出了一套完整的 「點子生命週期管理」 架構，可能源自於我有說明痛點。提醒到我，如果點子只是存起來，那最後只會變成一個「數位墳墓」；點子必須能夠「成長」與「轉化」。 在短短一次的心流協作中，我們直接跳過了單純的記錄功能，設計出了三段式的運作邏輯： 特別的是 AI 結合我正練習的 2+1 快手精神，將展開與轉化架構話變成工具 A. 捕捉 (Capture) - just in 這是最底層的本能。透過 just in "我的想法"，瞬間將文字打入每季一個的 Ideas.md 檔案中。不需要管路徑、不需要切換視窗，重點在於實現那個「極低摩擦」。 B. 展開 (Expansion) - just ix 當我有空回頭看這些點子時，我最討厭的就是「想不起來當初在想什麼」。我們設計了 just ix (Idea Expansion)，調用 AI 對單一條目進行「碰撞」與「推演」。它會幫我辨識脈絡、建議實作路徑，甚至幫我想好可能的專案鏈結。 C. 轉化 (Transformation) - just it 這是整套系統的「最後一哩路」。當一個點子在 ix 階段成熟後，我們可以透過 just it (Idea Transformation) 直接將它「投射」到現實中——可能是轉化為 TASKS.md 中的一個正式任務，或是寫入知識庫。 3. 實施驗證：這不是演習，是真實的效率提升 這套系統最讓我感到驚喜的地方在於，它解決了「想法落地」的斷層。 ...

「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 Agent 與自動化腳本，將大量且發散的研究資料，快速收斂為 WalkGIS 系統中的標準化地圖。 實作流程解析 我的工作流主要分為三個階段：Deep Research (發散) -> 結構化萃取 (收斂) -> 自動化生成 (Agent Task)。 階段一：Deep Research 與維度定義 首先，我並不是直接開始畫地圖，而是先進行研究。我定義了濁水溪流域的五個觀察維度： 自然 (Nature): 包含源頭的合歡山、地質敏感的金門峒斷崖、以及河口的濕地生態。 水利 (Water Infrastructure): 這是濁水溪的靈魂。從上游的霧社水庫、武界壩，中游的集集攔河堰，到下游滋養彰雲平原的八堡圳與濁幹線。 人文 (Culture/History): 包含原住民部落（曲冰、武界）、客家文化（詔安）、以及漢人聚落（西螺、北斗）。 交通 (Transport): 見證歷史的西螺大橋、集集車站，以及現代的國道橋樑。 災害 (Disaster/Env): 誠實面對環境課題，如車籠埔斷層保存園區、地層下陷區。 我利用 AI 工具（如 Gemini）針對這些維度進行深度搜尋，挖掘出最具代表性的關鍵字與地點。 階段二：萃取清單 (The List) 研究之後，我將這些發散的資訊收斂為一份結構化的景點清單 (List of Locations)。這份清單不需要包含座標或詳細敘述，只需要準確的「名稱」與「分類」。 例如： 水利：八堡一圳、林內分水工 交通：西螺大橋、溪州大橋 人文：林先生廟、麥寮拱範宮 這份清單，就是餵給 AI Agent 的「種子」。 階段三：Run Task - 自動化生成的魔法 這一步是效率爆發的關鍵。我定義了一個名為 create-walkgis-map-from-list 的 Agent Task，讓 AI 代理人幫我完成那些繁瑣的 GIS 建置工作。 ...

Antigravity 實戰：解放 Google Maps MCP 的力量，AI 導遊帶你去吃喝 身為一個依賴 AI 協作的開發者，我一直在思考如何讓我的 Agent (Antigravity) 擁有「真實世界的眼睛」。雖然它能寫程式、能搜尋網頁，但遇到「地理空間」的問題時——例如「這條路沿線有什麼好吃的？」——它往往只能給我模糊的網頁摘要，而不是精確的地點資訊。 這篇文章記錄了我如何從零開始，克服 API 權限、工具缺失、通訊協定不相容等困難，最終成功讓 Antigravity 使用 Google Maps Grounding Lite MCP (Model Context Protocol)，變身為超強 AI 導遊的過程。 1. 緣起：尋找 Agent 的「地圖外掛」 一開始，我希望能透過 Command Line Interface (CLI) 工具，讓 Agent 直接操作 Google Maps。但我發現： 沒有官方 CLI: Google 只有 gcloud (管機器的)，沒有 gmaps (查地圖的)。 Gemini CLI 的潛力: Google 推出了 gemini CLI，且支援 MCP (Model Context Protocol)，這是一個讓 LLM 能標準化呼叫外部工具的協定。 目標確立：把 Google Maps MCP Server 裝進 Gemini CLI，再讓 Antigravity 呼叫它。 ...

在 WalkGIS 2.0 的開發過程中，我發現早期的地圖資料存在嚴重的 GPS 誤差。本文記錄了如何利用 Google Maps API 進行批次自動化校正，並解決了「台灣中心點」歸零問題、路徑檔被誤改以及資料一致性維護的技術挑戰。

這不是一篇理論文，而是一次真實的踩坑紀錄。本文記錄了我如何使用 WalkGIS Template，配合 AI Agent 的自動化任務，從零打造一份包含 16 個景點、具備 GPS 定位與詳細介紹的「清大夜市美食地圖」。文中包含基礎設施架設、AI 內容協作到最終資料治理的完整流程。

如何將生硬的 GIS 數據變成生動的旅遊故事？本文分享我的 WalkGIS 自動化工作流：使用 Shell Script 從 SQLite 精準萃取地圖資料，餵給 Google NotebookLM，一鍵生成卡通風格導覽與投影片大綱。

繼 Discord Bot 之後，今天挑戰讓 AI 讀取我的「私人知識庫」。利用 n8n 的 Google Drive 節點下載文件，透過 Extract Text 解析，最後餵給 Gemini 進行問答。過程中踩了 Google OAuth ‘測試使用者’ 的坑。