Antigravity

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

最近在研究 LASS 社群維護的 「流域情報開放地圖」 QGIS 專案，這是一個集結了政府開放資料與民間調適計畫成果的龐大資料庫。 資料雖豐富，但若只想專注於特定流域（例如：濁水溪），要從全台的圖資中「萃取」並「整理」出有結構的資料，手動操作相當繁瑣。這次我嘗試透過 AI 助理 Antigravity 來協助處理，發現這是一個非常高效的工作流，特別是針對舊式 Shapefile 資料結構的梳理。 以下分享這次的實作筆記，以及一個關鍵的發現：河川代碼 CSV 的重要性。 1. 任務目標 從全台的 GIS 圖資中，提取出 濁水溪流域 的完整資料，並轉換成 Google Earth 可用的 KMZ 格式。需求包含： 流域範圍：濁水溪集水區的面資料 (Polygon)。 河道水系：包含主流與所有支流的線資料 (Line)。 層級結構：需區分主流、一級支流（如陳有蘭溪）、二級支流（如和社溪），並以不同顏色與資料夾呈現。 2. 關鍵資料解析 在專案目錄中，主要的幾何資料位於 1-流域水文地理環境 下的 RIVERL.shp（全台中央管河川）。原本以為只要用 SQL 篩選 BASIN_NAME = '濁水溪' 即可，但 AI 分析後發現了一個隱藏的寶藏檔案： 📂 檔案位置： 河川整理資料 - 河川代碼主從 這份 CSV 檔案是解析河川「拓撲關係（Topology）」的關鍵，沒有它，GIS 圖資就只是一堆沒有從屬關係的線條。所以也很容易做出下圖 為什麼這份 CSV 很重要？ Shapefile 本身雖然有 RV_NO (河川代碼)，但要從代碼反推「誰是誰的上游」需要複雜的解碼邏輯。而這份 CSV 直接建立了樹狀結構： 欄位 說明 範例 (陳有蘭溪) river_id 河川唯一碼 151010 river_name 中文名稱 陳有蘭溪 in_id 注入的河川 ID (Parent) 151000 (注入濁水溪) river_link 全路徑字串 0@151000@151010 AI 應用的邏輯技巧 透過 Antigravity，我們利用 river_link 欄位快速算出了河川的「層級 (Stream Order)」，邏輯出奇簡單： ...

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 —— 全台散步地圖」專案的過程中，我與 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 大阪站、阪急梅田、阪神梅田以及幾條地下鐵線路的相對關係，建立了我腦中的「骨架」。 ...

雲端服務最讓人卻步的往往不是技術本身，而是那複雜到像迷宮的控制台介面，以及永遠搞不懂的計費陷阱。這篇文章分享我如何使用 AI Agent (Antigravity)，把原本痛苦的 GCP 系統管理工作，變成了一場輕鬆的對話。不用再查文件、不用背指令，只要「出一隻嘴」，機器就開好了，錢也省下來了。

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

哈爸筆記：從「抗重力」到「奪回主權」——三位一體治理套件的誕生實錄 1. 緣起：當「賦能」變回「重力」 在撰寫《個人 AI 賦能》第十章時，我突然感到一種強烈的「重力」。 隨著對話進度飛快，我與 Antigravity 產出的腳本、研究報告、圖資和草稿像雨後春筍般出現在各個目錄。本來是為了賦能，結果最後我得花一半的大腦頻寬去記：「那個檔案存哪了？」、「這個任務勾選了嗎？」、「我的日誌跟羅盤對位了嗎？」。 當數位資產累積到臨界點，如果不治理， AI 就會從「推動力」變成「認知的重力」。 2. 建構：三位一體與「總指揮」的誕生 為了對抗這股熵增，我決定與 Agent 聯手進行一場「系統大掃除」。 我們確立了**「三層執行與勾稽架構 (Three-Tier Architecture)」**： 頂層 (Compass)：你的北極星。 中層 (Tasks)：你的轉化器。 底層 (Logs)：你的推進器。 但只有架構是不夠的，我需要一個「執法者」。於是，我們封裝了 work-governor (總指揮) 這個 Skill。他不負責具體的搬運勞動，他只負責「勾稽 (Audit)」。他會冷靜地盯著這三層檔案，告訴你：「哈爸，你的計畫與行動斷軌了。」 3. 釋出：將「數位武裝」標準化 最後，我們決定將這套自用的治理系統，封裝成**「三位一體治理套件 (The Trinity Suite)」**，作為書本第十章的隨附資產。這套套件由一個總指揮與三個分管員（羅盤、任務、日誌）組成。 我們甚至微調了第十章的最後幾個練習，讓讀者能直接調用這套武裝，執行 *init-workspace 建立主權專區，執行 *audit 體驗巡航稽核。 書本 GitHub 連結：PersonalAI-Empowerment 4. 感觸：紀錄即遺忘，治理即自由 這場實驗最大的獲得，是那種**「終於把管理權交還給系統」**的解脫感。 數位領主的養成，並非來自於對細節的控制，而是來自於對格律的統御。 AI 協作聲明：本文由哈爸（人）提供核心領悟與實戰歷程，Antigravity（AI）協助結構化與文字修飾。這是一次典型的「人機協同治理」產出。