當我們開始嘗試將 AI 與歷史地理資訊系統 (HGIS) 結合時，最初是在探勘總體性的《臺灣通史》。但歷史的魔鬼往往藏在地方的細節裡。

為了驗證我們的架構是否具備「橫向擴展」到區域史料的能力，我將目光轉向了北台灣早期的政經中心——竹塹 (新竹)。這次，我決定一次挑戰五本重量級的地方方志：《新竹縣採訪冊》、《淡水廳志》、《樹杞林志》、《新竹縣志初稿》、《新竹縣制度考》。

這五本書，總計 34 卷、9,000 多條史料片段。如果單靠純文本搜尋，那就像是在汪洋中撈針。

今天，我正式在 Taiwan History Atlas 專案中，釋出了這套針對新竹史料開發的「多書跨卷整合與空間對合框架」，並同步上線了 竹塹五書歷史知識地圖。

🏗️ L0-L1-L2：史料的階梯式煉金術

要讓 AI 不會在這 9,000 多條文獻中「幻覺」，我們採用了嚴謹的「分散式溯源，集中式建模」三層架構：

1. L0 文獻底座 (Text ETL)

有別於單一文本，地方方志的卷次編排極度不一致。透過 hsinchu_multi_loader.py，我們實作了多種 Regex 解析器，一次性將五本史書的目錄、卷次、條目全部打散又重組，完美塞入 hsinchu_history.db 的標準 Documents -> Volumes -> Contents 結構中。

2. L1 實體萃取與降維對合 (Entities & Linkage)

光有文字不夠，我們需要提取「有意義」的節點。 透過 AI 輔助腳本，我們一口氣從五書中抓出了三類實體：

  • Infrastructure (基礎建設)：1,410 筆（橋樑、隘口、古道、城門等）。
  • Location (聚落空間)：4,343 筆（堡、里、庄、社、窠、坑等）。
  • Irrigation (水利開發)：834 筆（陂圳、埤塘、水門等）。

但困難來了：古地名在地圖上是找不到座標的！ 例如史書寫「隆恩圳」或「林先坤陂」，現代 Google Map 根本不知道在哪。

這時我們啟動了 「地理特徵降維打擊」 的演算法。我們寫了清洗函數（如 clean_infra_name, clean_water_name），把地名的尾巴（像是 xxx庄、xxx圳、xxx城門）全部剁掉，只保留核心字根。

接著，啟動**「雙軌空間對合引擎」**：

  • 先拿乾淨的字根去碰撞 1920年代的台灣堡圖大字 (Oaza) 中心點。
  • 沒撞上的，再去聯集 內政部 3 萬多筆的古地名資料庫 (moi_settlements)。

不可思議的是，這個簡單粗暴的降維法，竟幫我們抓回了 821 個 帶有 WGS84 原生坐標的歷史實體！

3. L2 知識圖譜中樞 (Atlas Ingestion)

最後，我們將這 821 個打好經緯度彈孔的數據，連同它們在五書中出現的「原文引述 (Mentions)」，封裝成 JSON 模型，推入了總部的 history_atlas.db。包含三大網：竹塹歷史聚落分佈 (624點)、水利開發網 (100點)、交通防禦網 (97點)。

🌐 知識外顯：從資料庫到「開放快照」

雖然 SQLite 資料庫是我們 AI 助理最好的「大腦」，但為了讓更多人能直接感受到這份資料的價值，我也在專案中部署了 「Layer 2 知識匯出引擎」 (export_atlas_to_open.py)。

現在，這 800 多個竹塹歷史 POI 與跨全台的史料建模，已經被轉化為：

  • 🗺️ 空間導覽 (GeoJSON)：可以直接丟進 Google My Maps 或 QGIS，視覺化竹塹地區的開墾脈絡。
  • 📝 知識快照卡 (Markdown)：將原本隱藏在 JSON 字段中的「地理由來」與「史料彙整」直接攤開，優化 GitHub 的閱讀體驗。

這是我在專案首頁新增的 Open Data 展示區 的核心精神：不讓知識堆在硬碟裡，而是讓它在外顯的格式中「被看見」。

🗺️ 走入歷史：竹塹五書知識地圖

你現在可以點擊打開這張 竹塹五書歷史知識地圖。

在地圖上，我們不再受限於單一書籍。當你在新竹的某處點開一個標記（例如「石壁潭」或「鳳山崎」）時，跳出來的，會是《淡水廳志》與《新竹縣採訪冊》在 19 世紀對它落下的歷史見證。

走到哪，清代的史書便跟著唸到哪。

這個套件與 AI Skill，我已經全數開源在 taiwan-history-atlas 庫中的 scripts/hsinchu/ 與 skill/ 模組庫裡。有了這套自動化煉金爐，從文本到空間知識，全台 390 個行政區的 HGIS 考證，都有了一條可複製的高速公路。