Posts

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

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

我們很高興宣布 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) ); 這個改變帶來的紅利是巨大的： ...

這次來大阪旅遊，除了享受美食與美景，我還做了一個特別的實驗：練習使用生成式 AI (GenAI) 來輔助旅遊規劃與決策。這不僅僅是問 Gemini「大阪哪裡好玩」，而是更深入地利用 AI 的邏輯推演與資料整理能力，來解決旅遊中遇到的「資訊過載」與「複雜交通」問題。 以下分享我如何運用 NotebookLM 與 Agentic AI (Antigravity) 來理解大阪梅田站這座複雜的交通樞紐。 1. 出發前的深度規劃：Gemini 與 NotebookLM 的協奏曲 在規劃階段，我先利用 Gemini 進行初步的發散式探索，詢問關於一日行程、深度旅遊建議以及景點背後的歷史文化。 操作心法：我將 Gemini 生成的對話內容匯出成 Markdown 檔案個別匯入 NotebookLM 作為知識庫。 AI 產出： 視覺化理解：利用 NotebookLM 整理出的重點，可以產出更清楚、方便理解的旅遊重點圖表或指南。 這種「先用 Gemini 生成，再用 NotebookLM 固化知識」的方法，讓我對大阪的歷史脈絡與行程要點有了更紮實的認識，而不僅僅是走馬看花。 2. 行程當日的即時戰略：Agentic AI 的動態規劃 到了當天，行程往往需要彈性調整。例如第二天我想去「四個特定的地方」，但我只知道名字，不知道確切位置和順序。 我的指令：給 AI 四個地點（Samuhara 神社、@cosme、Motherhouse、Loft），請它確認地點、找官網、並建議順序。 AI 的價值： 地理邏輯判斷：AI 發現其中一家神社比較遠且早開，其他三家都在梅田商圈，因此建議「先去神社，再回梅田一網打盡」。 Google Maps 整合：它直接吐給我一個規劃好的 Google Maps 路線連結，點開就能導航。 3. 破解「梅田大迷宮」：結構化資訊的力量 大阪梅田車站被稱為「大迷宮」，地下地上錯綜複雜。一般的地圖看了一頭霧水，本來是一頭霧水，但跟 AI 詢問一些架構問題，能幫助自己理解交通網絡。 3.1 根據地圖詢問交通架構 我先給地圖照片問 AI：「大阪車站的交通架構是什麼？有哪些節點？」AI 幫我釐清了 JR 大阪站、阪急梅田、阪神梅田以及幾條地下鐵線路的相對關係，建立了我腦中的「骨架」。 ...

這是我日本行的第二天。今天主要前往奈良看鹿，晚上回到大阪享用美食。 以下是實際去過的地方與買吃的東西： 🦌 奈良公園 (Nara Park) 官方網站 來到奈良當然不能錯過著名的奈良公園。 餵鹿：這是今天的重頭戲，雖然鹿很可愛，但有時候也挺熱情的，手上的鹿仙貝要拿好喔！ 🍚 志津香釜飯 (Shizuka) Google Maps 午餐選擇了著名的志津香釜飯。排隊人潮通常不少，但堅持傳統風味的釜飯，米飯吸滿了高湯精華，非常值得一試。 ⛩️ 冰室神社 (Himuro Shrine) 官方網站 接著參訪了冰室神社，這裡是著名的「製冰業守護神」。除了祈求好運，欣賞神社的靜謐氛圍也是一種享受。 抽了張 第 20 號大吉的籤 🏯 東大寺 (Todaiji Temple) 官方網站 宏偉的東大寺，看到大佛的瞬間真的感到很震撼。 大佛布丁 (Daibutsu Pudding)：Google Maps 參拜完特別買了有名的大佛布丁，瓶蓋上有可愛的大佛圖案，口感綿密濃郁，是很好的伴手禮或甜點。 🥘 福太郎 - 梅田店 (Fukutarou) 官方網站 晚餐回到大阪梅田，選擇了福太郎大阪燒。這裡是品嚐正宗大阪燒（Okonomiyaki）與蔥燒（Negiyaki）的好地方，坐在鐵板板前看著師傅料理，香氣四溢，為第二天畫下完美的句點。 AI 協作宣告 (AI Collaboration Disclosure) 本文內容由 AI 協作生成： 素材來源：哈爸提供行程與筆記。 文章生成：Antigravity 協助整理與撰寫。 文章落地：Antigravity 協助排版與發布。

分享一套利用 AI 語音討論的方法論，將對話轉化為具備「無限開放性」與「邏輯紀錄」的思考深化工具。

探討 AI 代理人化後的管理挑戰，提出「AI 安全官」概念，從行為意圖、特徵值到本質進行多層次安全監控。

探討 Agentic AI 帶來的安全挑戰，提出監控、即時阻攔與長線溯源結合的「全戰線」防禦機制。

Google Search 找不到剛發布的文章？本篇介紹如何利用 n8n 直接讀取 GitHub Repo 原始碼，結合 Gemini 的長文本能力，實作真正的「即時」問答機器人。