Mermaid

戰略羅盤自動化：解決「進展太快、記錄太細、方向模糊」的個人數位革命 🌪️ 困擾許久的「迷霧」 在高速推進的 AI 賦能時代，我遇到一個很深刻的困擾：事情進展實在太快了。 每一天都有新的對話、新的腳本、新的筆記，這些「點」被鉅細靡遺地记录在哈爸筆記文中。然而，當有人問起「最近進展如何？」或是我想調整下個月的大方向規劃時，我卻常感到一片模糊。 碎瑣的紀錄就像樹木，讓我看不清整座森林。 現實中，我常常只有一個直覺的方向，卻缺乏一張清晰的「地圖」來定錨位置與演化歷程。 🧭 解決方案：策略羅盤管理員 (Strategic Roadmap Manager) 這次，我們針對這個痛點打造了一個專屬 Skill。核心目標很簡單：把「點」連成「線」，把「線」織成「面」。 1. 用視覺化定錨直覺 (Visual Anchoring) 我們不寫長篇大論的週報。我們使用 Mermaid 語法產出三張圖： 心智圖 (Mindmap)：釐清戰略版圖，一眼看出能量正消耗在哪個支線。 流程圖 (Flowchart)：揭示因果鏈條。為什麼現在要做 A？因為 A 會支撐未來的 B。 演化時序 (Timeline)：清楚區分 Planning (規劃中) 與 Status (已完成)，讓進步「看得見」。 2. 層級式管理 (Annual vs. Monthly) 我們同時同步更新**「年度羅盤」與「月度羅盤」**。 月度看細節，記錄本月的關鍵轉向 (Pivot)。 年度看大趨勢，確保我們沒有因為某個月的忙碌而偏離核心願景。 3. 補完隱性脈絡 (The Missing Context) 這是最漂亮的一步：USER_STRATEGIC_CONTEXT.md。 筆記文記錄的是「發生了什麼」，但這個隱性脈絡檔記錄的是**「我為什麼想這麼做」、「我的直覺是什麼」**。AI 在分析我的公開日誌時，會先讀取這個隱藏的「大腦直覺」，這讓產出的地圖不再只是機械式的彙整，而是真正具備我的靈魂與野心。 ⚡ 實戰成果：三個月戰略軌跡的一秒呈現 透過這個 Skill，我們在幾分鐘內回溯完成了： 2025/12：WalkGIS 的創世紀與自動化基建啟動。 2026/01：河流探勘產能化與「地圖即 Prompt」的願景轉向。 2026/02：Skill-First 協作範式的確立與全台行政區框架化。 這種「戰略透明度」，讓我即便在事情高速變化的當下，也能隨時退一步，看清自己正在這台數位演化的越野車上，開往哪個座標。 📈 總結：從紀錄者進化為架構師 有了這個 Skill，我最大的體悟是：記錄是為了遺忘，而地圖是為了導航。 ...

驗證 WalkGIS 系統的擴充性：透過標準化流程，快速部署「大甲溪水利溯源」與「智慧水圳」兩條全新路線，並整合 Google Maps 導航與 AI 內容生成。

我們很高興宣布 WalkGIS Project V0.1 正式釋出！ 🎉 這是一個實驗性的專案，旨在探索如何讓「地圖資料」不僅是冷冰冰的座標，而是能被人類與 AI 共同閱讀、協作的「散步故事」。 🚀 什麼是 WalkGIS？ WalkGIS 是一個輕量級的 GIS (地理資訊系統) 資料庫。不同於傳統地圖，它使用 WKT 文字格式 儲存座標，並用 Mermaid 流程圖 來描述路線。這意味著： 你可以直接讀懂它：打開資料庫，你看到的不是亂碼，而是 POINT(...) 和清晰的文字描述。 AI 可以幫你導覽：未來的 AI 助理可以直接讀取這些資料，為你規劃行程。 🗺️ V0.1 首發路線：后豐鐵馬道 & 東豐綠廊精華遊 作為 V0.1 的展示，我們建構了台中最經典的 「后豐鐵馬道 & 東豐自行車綠廊」 大環線地圖。 這張地圖收錄了 24 個精選景點，從后里馬場出發，穿越百年的九號隧道與花樑鋼橋，一路延伸至東勢客家文化園區。 原圖 數位化的路線拓樸 看看我們如何用程式碼畫出這條路線的邏輯： graph LR; %% 子圖：后豐鐵馬道 subgraph Houfeng ["后豐鐵馬道 (4.5km)"] direction TB H1(1. 后里馬場) --> HA(樟樹平台); HA --> H2(2. 夫妻樹); H2 --> H3(3. 九號隧道); H3 --> H4(4. 花樑鋼橋); H4 --> HB(鐵道之鄉酒莊); HB -.-> HC(榮町雜貨店); end %% 子圖：東豐綠廊 (前段) subgraph Dongfeng_Start ["東豐綠廊-起點段"] D7(7. 豐原大道) --> Junction{綠廊交接處}; HB --> Junction; Junction --> D5(5. 朴口車站); D5 --> HE(200days冰店); HE --> D6(6. 豐榮水利碑); end %% 子圖：石岡精華段 subgraph Shigang ["石岡精華段"] D6 --> D9(9. 石岡水壩); D9 -.-> D10(10. 石岡斷層月台); D9 --> D11(11. 0蛋月台); D11 --> D12(12. 九房3D彩繪村); D12 --> D13(13. 石岡旅服中心); D13 --> D14(14. 情人木橋); D14 -.-> D15(15. 土牛客家館); end %% 子圖：東勢段 subgraph Dongshi ["東勢終點段"] D14 --> D16(16. 梅子車站); D16 --> D17(17. 梅子百年芒果樹); D17 --> D18(18. 梅子鐵橋); D18 --> D19(19. 東勢客家園區); end %% 周邊景點 D8(8. 公老坪) -.-> D7; %% 樣式設定 classDef spot fill:#fff,stroke:#333,stroke-width:2px; classDef highlight fill:#fcf,stroke:#f00,stroke-width:2px; class H1,H3,H4,D9,D11,D19 highlight; class Junction fill:#ff9,stroke:#333,stroke-width:2px,shape:rhombus; mermaid.live 顯示 📂 如何取得與使用？ WalkGIS V0.1 目前已整合於本部落格的專案庫中： events/notes/wuulong-notes-blog/walkgis_prj/ ...

在構建「WalkGIS —— 全台散步地圖」專案的過程中，我與 AI Agent (Antigravity) 進行了一場深度的架構辯論。核心問題在於：當我們希望 AI 能像人類一樣理解地圖時，傳統的 GIS 資料庫還是最好的選擇嗎？ 這篇文章記錄了我們如何從傳統的 SpatiaLite 方案，轉向一個更輕量、更適合 LLM 的 “Text-based GIS” 架構。 1. 痛點：AI 讀不懂二進位碼 (Binary Blob) 起初，我們理所當然地選擇了 SpatiaLite 作為 SQLite 的空間擴充。它是業界標準，功能強大。但是，當我嘗試讓 Agent 讀取資料庫時，問題出現了： Agent: “我讀取到了 geometry 欄位，但它是 binary blob，我無法直接解析它的座標。” SpatiaLite 為了效能，將幾何資料存為二進位格式。這對 QGIS 很好，但對 LLM 來說，就像是一本無字天書。如果要讓 Agent 理解「后里馬場在哪裡？」，我們必須寫額外的 Python 程式碼去解碼它，這增加了依賴度與複雜性。 2. 決策：擁抱 WKT (AI-First Approach) 既然我們的目標是 “Agentic GIS”，為什麼不直接存成文字呢？ 於是，我們做了一個大膽的決定：棄用 SpatiaLite，擁抱 WKT (Well-Known Text)。 我們將 DB Schema 修改如下： CREATE TABLE walking_map_features ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, -- geometry BLOB, <-- 傳統做法 (X) geometry_wkt TEXT NOT NULL -- 新做法 (O) : POINT(120.735 24.298) ); 這個改變帶來的紅利是巨大的： ...