在 AI 密集開發的時代，我們常說 AI 是大腦，但大腦若沒有「感官」來感知現實世界的空間脈絡，它的建議就容易流於空泛。這篇文章記錄了我與 AI 代理程式（Antigravity）共同打造 GeoPulse —— 一個空間感知與導航引擎的設計經驗。

這不僅是一個技術腳本的開發，更是一場關於「如何解決雜亂大數據」與「架構落地」的實踐。

1. 發想：在地理數據的迷霧中尋找座標

作為一個長期進行河流探勘與 GIS 研究的開發者，我面臨一個典型的數位資產困境：

  • 資產巨大且分散：幾十 GB 的政府 SHP 圖資散落在外接硬碟中（縣市界、流域圖、配水管線）。
  • 環境斷裂：這些資料並非隨時掛載在系統內，AI 無法直接存取。
  • 格式混亂：編碼有 CP950 與 UTF-8 的混雜，座標系則有 TWD97 與 WGS84 的轉換問題。

當我想問 AI：「我現在這個座標在哪个流域？附近有沒有我標記過的私房點？」時，AI 是盲目的。我們需要一個「空間導航核心」，讓 AI 具備地理感知的能力。

2. 架構：虛擬化優先 (Virtual-First) 的戰略選擇

在設計 GeoPulse 時，我們面臨一個關鍵選擇：要把所有資料匯入資料庫（Solidification），還是保持資料的原始性？

為了保持靈活性與減少磁碟開銷，我們選擇了 「虛擬化優先」 架構。這套架構由三個核心組件構成：

A. 資源索引員 (GIS Cataloger)

我們不強迫資料進場，而是讓腳本主動去「掃描」。它會掃描硬碟，識別所有的 .shp, .kml, .geojson 等檔案，產出一份 GIS_CATALOG.md。這讓 AI 知道我們「擁有什麼」。

B. 語義地圖 (GIS Knowledge Hub)

光有路徑是不夠的。我們透過一個 GIS_KNOWLEDGE.yaml，告訴系統每一張表的「意義」。

  • 這張表叫 river_basin，它的座標系統是 EPSG:3826，名稱欄位在 basin_name。 這種「定義大於匯入」的做法，讓工具與圖資之間產生了透明的語義連結。

C. 空間引擎 (GeoPulse Engine)

這是最精彩的部分。我們利用 SpatiaLite 的 VirtualShape 技術，在查詢發送的瞬間，才將外部的 SHP 虛擬掛載進「具備空間處理能力」的 SQLite 內存中。

  • 無感掛載：不需要匯入時間，隨插隨查。
  • 實時空間化：針對 walkgis.db 中的 WKT 文字，我們採用「On-the-fly」轉換，在查詢時才賦予其空間幾何屬性。

3. 測試與驗證：在官田的午後

我們在台南**官田（隆田車站）**的一個點位進行了整合測試。系統必須在 100 毫秒內回答三個層面的問題：

  1. 行政區：這裡隸屬哪個區？（答：官田區）
  2. 自然脈絡：屬於哪個流域？（答：將軍溪流域）
  3. 私有記憶：我在這裡記錄過什麼？（答：隆田 chacha 文化園區，距離 210 公尺）

測試結果出乎意料地流暢。原以為「實時 WKT 轉換」會很吃重，但實測在 1,400 筆資料下僅需 0.05 秒。這驗證了一個真理：合適的架構能讓「看似昂貴」的運算變得微不足道。

4. 心得：落實是架構的靈魂

這次的設計經驗給了我幾點深刻的心得：

  • 不要為了技術而技術：我們大可花幾天時間寫一個完美的「資料同步器」，但「虛擬掛載」卻用最輕量的方式解決了資料主權與掛載時差的問題。
  • 給 AI 眼睛，它會給你洞察：當 GeoPulse 完工後，我的「智慧行車助理」立刻從一個復讀機，變成了一個能感知你正在跨越流域、能提醒你前方渡槽橋歷史的深度顧問。
  • 架構不是終點，而是開始：GeoPulse 現在是智慧助理的「空間大腦」。好的架構提供了極佳的擴展性，讓我們未來可以輕易加入「最近鄰搜尋」或「航向趨近判定」。

結語

GeoPulse 的完工，標誌著我的個人 AI 工具鏈從「邏輯運算」跨入了「空間感知」的新階段。這不僅是技術的落實，更是將這幾年探勘資料「活化」的關鍵一步。

好的架構，不僅能解決眼前的問題，更能為未來的夢想（如：全台河流旅遊導航）鋪好地基。

本文由 Antigravity AI 代理程式協力完成，記錄 GeoPulse 系統從設計到落實的實戰經驗。