Project (專案)

在 v1.3.0 的發布文中，我們確立了企業 AI 轉型的「物理化」架構與 L0-L4 的層次化賦能。但隨著理論的完善，一個更尖銳的實戰問題浮現：「如果我只有 5 個隊友，明天早上進辦公室，我們該如何用 AI 開始協作？」 這就是今天發布的 v1.4.0 核心任務：讓理論落地為「團隊實踐原型」。 1. 遞迴演化的邏輯：為什麼是「團隊」？ 企業轉型往往死於規模的巨大。我們在 v1.4.0 中提出了一個關鍵假設：「團隊是企業賦能的最小實踐原型」。 如果一個 5 人的 Nano-Squad 能夠達成高度的 AI 對合與智力自動化接力，那麼企業級的轉型只不過是這套原型的無數次複製與連結。因此，我們在全書的第一章之前，強行插入了「第 0 章」，直接定義這套「虛擬企業實踐原型」。 2. 第 0 章：虛擬企業的「物理骨架」與「數位管家」 在 v1.4.0 中，我們不僅是寫書，更是直接產出了可運作的資產： 協作格律 (Chapters 0.1-0.2)： 我們不再談空泛的溝通，而是直接發布了 「團隊手冊 (Handbook)」 與 「工具指引 (Tools Guide)」 範本。這是團隊的「數位憲法」，明確定義了資產存放位置與 AI 互動的格律。 管理 Repo 目錄設計 (Chapter 0.3)： 這是一套針對虛擬企業設計的 管理 OS 目錄架構。透過 /workmgr/（執行）、/meeting/（共識）、/assets/（資產）與 /members/（個人空間）的物理隔離，讓團隊的「單一事實來源 (SSOT)」成為現實。 數位幕僚長 SyncHub (Chapter 0.4)： 這是本次升級的最大亮點。我們將 SyncHub 定位為 「數位管家」 而非「數位憲兵」。它守在背景，透過 Git 事件驅動，默默地整理進度、產出小報，並在成員完成任務時自動為下一位接棒者準備好脈絡。 3. 個人沙盒如何接入團隊？ 很多團隊協作的失敗，在於犧牲了個人的「創造手感」來換取「集體同步」。 ...

當我們開始嘗試將 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城門）全部剁掉，只保留核心字根。 ...

在完成《個人賦能》書籍的集成後，我的注意力重新回到了這片土地。 過去一週，我們對《流域導讀》（現正式更名為《流域導航》）進行了一場堪稱「範式轉移」的升級。如果說 v1.0 是我帶著你「看」河流的故事，那麼今日釋出的 v2.0，則是交付給你一套能跟河流「對話」的數位技能組。 這不只是一本書的改版，這是一場關於「認知效率」的革命。 為什麼要有 v2.0？從「敘事」轉向「技能」 在實地探勘曾文溪與二仁溪的過程中，我發現一個巨大的痛點：即使我有再多的熱情，面對百年的地理變遷與海量的史料，單靠人力去對合座標與文獻，效率實在太慢。 於是，在 v2.0 中，我們確立了 「Skill-First Approach (技能優先)」 的核心方針。我們不再只是寫下河流的歷史，而是開發一套名為 hgis-atlas-architect 的 AI 技能，讓 AI 助理化身為歷史地理架構師。 核心突破一：HGIS Layer 0-1-2 三層架構 我們定義了土地知識的演進路徑： Layer 0 (原始資產)：1920 年代的 SHP 圖資與《臺灣通史》的 60 萬字原文。 Layer 1 (結構實體)：透過 AI 萃取的 3,000+ 個古地名、埤圳與先賢索引。 Layer 2 (知識中樞)：將土地的「變遷邏輯」建模。例如，我們不再只是標註「蘇厝」在哪裡，而是建模「曾文溪改道如何影響聚落遷移」的動力學模型。 這套方法論，已完整寫入書籍的 Chapter 2.4 (方法論) 與 Chapter 10 (AI 分析師) 中。 核心突破二：極速對合的「15 分鐘法則」 在 v2.0 的實踐案例中（曾文溪與二仁溪），我們驗證了一項驚人的數據：當我們將 HGIS 流程封裝成 AI Skill 後，針對一個完整流域的歷史對合（包含 500+ 個 POI 的史料厚化與座標校準），由原本需要數天的工程，縮短至 15 分鐘。 ...

在《台灣歷史知識地圖》Layer 2 架構釋出後，我們隨即投入了第一個實戰場域：曾文溪流域。 這次的目標非常明確：我們不再滿足於地圖上冷冰冰的座標點，而是要透過「時空對合」技術，讓曾文溪流域的 696 個 POI 全部具備歷史靈魂與文獻厚度。 任務目標：構建曾文溪「厚數據」圖層 傳統的地圖標註往往只有名稱與座標，但我們希望構建的是具備歷史深度 (Depth)、水利脈絡 (Context) 與 因果邏輯 (Logic) 的「厚數據 POI」。 這意味著，當你走到曾文溪畔的一個小村落時，AI 不僅能告訴你這裡是哪裡，還能告訴你： 這個地名在 1920 年代的行政歸屬。 它在《臺灣通史》或其他地方志中被如何記載。 它與曾文溪水系（如埤圳、改道）的深層互動關係。 製作歷程：數位考古的三部曲 這次的產製過程是一次典型的「AI 協作數位鍊金術」，分為三個階段： 1. 空間鎖定層 (Spatial Anchor) 利用中研院提供的 1920 年代行政邊界 SHP 檔，與曾文溪流域範圍進行空間交集。我們篩選出了 100 個「大字 (Oaza)」點位，並計算其精確的 WGS84 座標。這是將歷史文本對齊到現代地圖的「時空錨點」。 2. 文獻厚化層 (Textual Enrichment) 這是最精彩的部分。我們開發了專門的萃取腳本，針對這 100 個古名點位，自動檢索 taiwan_history.db。 跨庫鉤稽：除了 1920 年代的官方資料，我們更進一步引入了內政部古地名庫的 37,758 筆資料，篩選出流域內的 813 筆關鍵紀錄。 故事萃取：不僅抓取名稱，更重點提取「地名由來（Place Mean）」，例如某個村落是因為躲避曾文溪改道水患而搬遷的。 3. 邏輯建模與匯入 最後，我們將這些分散的片段，透過 Python 腳本整合為 WalkGIS 特徵檔案。總計 696 個厚數據 POI 被正式匯入系統。 成果展示：三個有靈魂的 POI 讓我們看看這套流程產出的成果： ...

在先前的系列中，我們完成了從原始文本（Layer 0）到結構實體（Layer 1）的跨越。透過 Python 腳本，我們讓幾十萬字的《臺灣通史》變成了資料庫中清晰的人名、地名與座標。 但在數位考古的最後一哩路，我們面臨了一個更終極的挑戰：AI 該如何「理解」歷史的動態邏輯，而不僅僅是搜尋關鍵字？ 這就是今天我們要分享的壓軸戰役——Layer 2：知識中樞 (Knowledge Atlas) 的建構，以及本專案正式對外開源的里程碑。 從「搜尋」進化到「理解」：何謂 Layer 2？ 如果 Layer 1 是史料中的「單點實體」，那麼 Layer 2 就是將這些點連成線、織成網的「邏輯圖譜」。 當我問 AI：「為什麼清代的新竹會發展出如此發達的水利系統？」傳統的 RAG 頂多能幫我找到幾段描述。但擁有 Layer 2 知識中樞的 AI，能直接調用我們今日建立的五大專題模型： 水利開發模型 (Eco_System)：結構化全台 226 處埤圳，整合開鑿者與水源脈絡。 產業貿易模型 (Economy)：分析「南糖北茶」的經濟地理骨架。 官職權力模型 (Gov_Structure)：釐清三代政權演變與行政邊界。 衝突因果模型 (Conflict_Logic)：建模民變、械鬥與海防轉向的底層邏輯。 地名演進矩陣 (Toponym_Ref)：建立「古社名 -> 舊地名 -> 現代區劃」的跨時空映射。 這意味著，現在的 AI 助理（如 Antigravity）已經不只是在陪我翻古書，它更像是一位**「數位歷史策展人」**。 數位鏈金術的成果：taiwan-history-atlas 正式釋出 為了讓這份努力產出的數位資產不只是鎖在我的硬碟裡，今天我們做了一個重要的決定：將今日建構的所有腳本、資料庫 Schema 與核心 Layer 2 知識資產，正式獨立封裝並在 GitHub 上開源。 🔗 Repo 連結： https://github.com/wuulong/taiwan-history-atlas 這個版本不僅僅是一個資料集。它包含了： taiwan_history.db：具備三層架構的核心資料庫。 全套 AI 建模腳本：讓你可以複製這套方法論去處理其他的歷史志書。 AI 導航指引：教導如何引導 GPT/Claude 等 Agentic AI 使用這座歷史大腦的方法論。 授權：公眾領域貢獻 (CC0) 我們決定採用 CC0 1.0 通用公眾領域貢獻宣告 釋出這個專案。 ...

在建立完這套由「時光羅盤 + 歷史文本 + 自動空間配對」組成的 歷史空間感知引擎 (HGIS) 後，一定有人會問：費這麼大功夫寫程式，究竟能帶來什麼改變？ 答案是：它將徹底顛覆我們閱讀歷史與感知旅行的方式。 讓我們用新竹開源始祖——王世傑 來做個火力展示。 傳統閱讀法的侷限 如果你翻開《臺灣通史．列傳三》，你會讀到王世傑是因為幫鄭克塽的軍隊「運餉有功」，所以獲准前去開拓「竹塹埔」。這是一個很典型的拓王傳記，但也僅止於此。 HGIS 的跨域聯動 (Knowledge Graph) 但現在，我們擁有的是一個具備空間關聯性的資料庫。我透過 SQL 引擎對全庫下達指令，去搜尋「王世傑」這三個字在整本地圖與史書中的關節點。 奇蹟發生了，資料庫以空間座標為支點，將原本散落在不同章節的片段，拼湊成了一張無比立體的「城鎮規劃藍圖」： 取得合法性與資本： 來源：《列傳三》 內容：靠著支援軍事後勤（運糧）獲得竹塹的獨家開墾特許權。這是一切政治資本的起點。 切開經濟命脈 (紅藍圖釘連線)： 來源：《農業志》 內容：當上大開發商（業戶）後，出資主導開鑿了我們前幾天才在地圖上完成配對的**「隆恩圳（四百甲圳）」**。這條水路一口氣灌溉了兩千甲良田，也是我們最初在地形圖上看到「黃金洞」的原因！ 穩定社會的定海神針 (紅色圖釘)： 來源：《宗教志》 內容：人在吃飽之後，需要心靈依託。王世傑在南門的「巡司埔」捐地，興建了新竹最古老的觀音亭——「竹蓮寺」。 透過這樣跨越篇章的串聯，王世傑的形象立體化了。他不是一個帶著鋤頭亂挖的農夫，他是用**「水利工程（養活肉體）」與「信仰中心（凝聚精神）」，聯手畫下了大新竹百年格局的城鎮綜合規劃師**。 下一步：會說古書的語音助理 現在，這些關聯的經緯度與史料脈絡，都已經封裝成 KML 與 JSON 格式。 未來，當我們開車經過新竹市區的「竹蓮寺」，或是馳騁在「隆恩圳」遺址旁時。我的 Smart Traveling Assistant (智慧行車助理) 的雷達一旦感測到這些 WGS84 座標，就會瞬間在背景調用這套 HGIS 引擎。 它會用語音告訴我： 「哈爸，你現在位在竹蓮寺。這不只是一間大廟，它跟我們剛剛經過的那條隆恩圳，都是三百年前那個為了軍隊運糧的男人——王世傑，一手擘劃百年帝國的拼圖…」 從地圖上的一個疑惑，到實體化一整套能運作的歷史感知大腦。這就是我們這場數位鏈金術的最終意義：讓歷史不再只存在紙上，而是真正走進了我們每一次漫遊的風景裡。 (全系列完) 本文為哈爸與 AI 助理協作產出，紀錄實體探勘與數位工程之歷程。

經過前三篇的努力，我們左手握有中研院的「1920年代空間圖資」，右手拿著從《臺灣通史》榨取出來的「600+ 個古地名與基建列表」。 這就像是一場歷史級別的相親大會——我們要讓書本裡的名字，在歷史地圖上找到歸宿，並將它們賦予現代的 WGS84 GPS 經緯度座標。這個過程，技術上叫做 Geo-Coding (地理編碼)。 同名異地的災難 原以為只要用程式名稱對齊 (Fuzzy Label Matching) 就好，但代誌不是憨人想的那麼簡單！ 台灣地名有驚人的重複率。古書裡寫了個「新莊」或「福興」，如果你不用大腦，程式很容易把北部的事蹟，釘到南部的地圖上，導致座標嚴重飄移。 第一波升級：內政部兵器庫支援 首先，1920 年代的「街庄/大字」顆粒度有時仍不夠細緻，很多《臺灣通史》提到的小聚落找不到。 我決定導入國家級的兵器庫支援：內政部 3 萬筆古地名資料庫 (moi_settlements)。我把這 37,758 筆資料匯入我的資料庫，形成了一個包含了「1920 歷史界線 + 現代文史調查點位」的「三層立體查詢網」。 第二波突破：上下文錨定法 (Hierarchical Anchor) 為了解決同名造成的標記錯誤，我幫自動配對腳本裝上了**「閱讀理解能力」**。 我實作了 guess_anchor 演算法。配對前，程式會先反查《臺灣通史》原文，看看這個地名的上下文寫了什麼。 如果上下文提到了「淡水 / 艋舺」，程式會自動將這個地名的搜尋範圍 錨定 (Anchor) 在「臺北州」。 如果上下文提到「打狗 / 阿猴」，程式就只准在地圖的「高雄州」範圍內尋找這個聚落。 這招「因文定地」，徹底解決了同名異地的痛點！ 史圖合一的瞬間 當我按下 geo_coding.py 的執行鍵，看著終端機不斷吐出 Log： ⚓ Anchored: 中港 -> 對應到苗栗竹南的中港 (24.6853, 120.8519) ⚓ Anchored: 六張犁 -> 成功定錨... ⚓ Anchored: 牛罵 -> 臺中市清水區牛罵頭... 憑藉著上下文疊圖與三層過濾網，我成功地讓近 200 個寫在文言文裡的歷史地名，從泛黃的紙張上躍起，精準降落在 Google My Maps 的紅色圖釘上。 ...

上一篇我們用 Python 打造了能解讀歷史座標的「時光羅盤」。但羅盤只會告訴你地名，無法告訴你歷史。真正的歷史，藏在文言文的汪洋大海中。 因為我本身對台灣史完全沒有概念，為了建立自己的知識體系，我首先向 AI 提問，得到了這份極具啟發性的「台灣方志演化樹」： 【根】 全域性/起源 (Early & Comprehensive) ║ ╚══ 1684《福建通志‧臺灣府》(清代最早的官方紀錄) ║ ╠══ 1694《臺灣府志》(確立台灣史志的基本架構) ║ ╠══ 1920《臺灣通史》(連橫著，民間史學集大成之作) ║ ╚══【幹】 區域行政中心 (以北台灣為例) ║ ╚══ 1871《淡水廳志》(新竹史料之源，具行政與大租分配紀載) ║ ╠══【枝】 縣級史志 (新竹設縣後) ║ ║ ║ ╠══ 1892《新竹縣志初稿》(新竹正式設縣後的首部地方志) ║ ║ ║ ╠══ 1895《新竹縣制度考》(日治初期清理清代制度之專作) ║ ║ ║ ╚══ 1907《新竹廳志》(結合日治調查與清代舊志) ║ ╚══【葉】 地方/微觀採訪 (Local & Micro-geographic) ║ ╠══ 1894《新竹縣採訪冊》(最細微的點位紀錄，如黃金洞、御史崎) ║ ╠══ 1898《樹杞林志》(專注於新竹東部山區與竹東拓墾) ║ ╚══ 1980+《新竹縣/市志》(現代修訂版本) 有了這張圖，我就知道該去哪裡尋寶了。於是，我花了一點時間想辦法把這些史書從網路上抓了下來（大部分都順利搞定了）。 ...

上一篇提到，為了驗證地形圖上的「黃金洞」與歷史水利的關聯，我決定打造一個「歷史空間感知引擎」。要建構這套系統，第一步就是要獲得一把能夠解開空間座標的鑰匙。 我將目光轉向了中央研究院的 GIS 寶庫。 寶藏開箱：1920 年代的台灣地理切片 幸運的是，台灣學界已經將日治時期（1920 年代）的行政區劃轉換為數值圖資。我順利取得了當時的「街庄（1920b_1.shp）」與更細緻的村落級別「大字（1920a_1.shp）」Shapefile 檔案。 這兩份檔案就像是兩張巨大的網子，完整罩住了百年前的台灣島。 不過，要將百年前的網子跟現代的手機 GPS 疊合，遭遇了第一個技術難關：座標系的跨時空翻譯。歷史圖資通常使用 TWD67（台灣二度分帶），而我們現在的手機或 Google Maps 則是使用 WGS84 經緯度系統。利用 Python 的 Geopandas 套件，我寫了一段優美的投影轉換代碼，成功讓百年前的地圖「滑」進了現代的經緯網格中。 魔法實做 1：GPS 腳下檢索 (Point in Polygon) 有了吻合的圖資後，我開發了第一個功能。這是一個純粹的數學運算，俗稱 Point in Polygon (點在多邊形內)。 現在，只要我輸入一組現代的 GPS 座標（或許是我走在竹北街頭，或是站在台南的田野），程式就會瞬間吃進這組座標，穿越時空，告訴我：「你腳下站的地方，在 1920 年屬於新竹州新竹郡新竹街！」 魔法實做 2：方圓百里的時光雷達 (Spatial Proximity) 光知道腳下叫什麼名字還不夠，我想要有「導遊」的感覺。 於是我加入了 Buffer（緩衝區）的概念，實作了「附近古地名查詢」功能。想像你站在定點，按下啟動鍵，程式會以你為中心，發射出半徑數公里的虛擬雷達波。雷達波不僅會掃過 1920 年代的各級行政區，更進一步結合了內政部釋出的 3 萬多筆「古地名/歷史聚落」空間圖資。這樣一疊加，所有被涵蓋在範圍內的聚落名稱（甚至是已經消失的微小地名）全部都會列印出來。 這套被我戲稱為「時光羅盤」的模組，讓我們具備了強大的 空間反查能力。 執行例子： python scripts/query_hgis_point.py 24.785150 120.967825 在 1920 年屬於： 🏛️ 州廳: 新竹州 🏰 郡市: 新竹郡 🏘️ 街庄: 香山庄 但問題是，地圖上的地名是冷的。這個古地名背後曾經發生過什麼驚心動魄的故事？有哪個先賢曾經在這裡開圳引水？ ...

一切的起點，源自於對家鄉地名的好奇。 老爸出生在潭後，但我一直不知道為什麼是這個名字。這裡沒有水潭，何來「潭後」之名？如果只是在 Google Maps 上滑動縮放，這個問題可能永遠得不到解答，因為現代的衛星空照圖，早就被密集的建築與柏油路給覆蓋。 於是我開始在網路上搜尋，想知道名稱的可能由來。透過查閱資料，我找到了「北庄13」這條線索，並追溯到了開墾先賢王世傑的紀錄。這才發現，原來在古書中指出，以前頭前溪在此處曾經有一個深潭。 更引人入勝的是，古書原文中還記載著附近有「黃金洞」，但我身為在地人卻從來沒有聽過這個詞！於是，我開始在各種古書中搜尋「黃金洞」，這便是為什麼後來會需要下載並整理好幾本地方志與史書的原因。 例如在《新竹縣採訪冊》記載著水圳「西南行二里至黃金洞，又三里至潭後莊」，另有紀錄點出「西南行一里許至黃金洞，鑿山三十餘丈引水出…經潭後」。這些古籍清晰地描繪了水路行經的節點，但對「黃金洞」本身僅有文字描述，大意就是「在潭後到九甲埔中間有個高起的小山，所以需要挖隧道引水」。既然只有文字描述，於是我心想：那或許可以從 DTM 數值地形去分析它大概的位置？ 我不甘於僅止於文字記載，決定戴上另一副眼鏡——打開具備高解析度的高程資料，俗稱 DTM (Digital Terrain Model) 數值地形圖，試圖在地表尋找先民的遺跡。 DTM 就像是將地表的樹木與建築物全部扒光，只留下最純粹的山地與溝壑起伏。當我將「潭後」附近的地形顯示在 QGIS 上，經由 GIS 處理與高程分析後，確實可以看到一條具備劇烈落差的線。 雖然看到這條線，但傳說中的「黃金洞」確切點位在哪，一開始還是不太知道。於是我將它與目前的現代地圖進行疊加，赫然發現那條異常落差的線上，剛好就有目前的「水源街取水口」！ 直覺告訴我：就是這裡了。而再經過後續的文獻交叉比對，那裡證實就是傳說中「黃金洞」的所在。 這不是外星人的遺跡，而是兩百多年前，我們的先民在缺乏現代大型機具的情況下，為了將水資源從頭前溪引進竹塹平原，硬生生地以人力穿山鑿石，刻下的大型水利基建（引水穿山的隧道）。有了這條隧道，龐大的水流才得以穿過高起的小山，灌溉出兩千甲的良田。 這個 Aha Moment 深深震撼了我。 我體悟到一件事：「地理，其實就是凝固的歷史。」 現代地表上看起來微不足道的一個小土丘、一條乾涸的溝渠、甚至只是一個站牌的名稱「潭後」，在數百年前，可能都是決定整座城市生死存亡的戰略設施。 但下一個問題來了：這條水路是誰修的？什麼時候修的？除了「黃金洞」，台灣的地底下是不是還有無數條這樣凝固在時間裡的生命線？ 為了解開這些謎團，過程中勢必會需要將古書記載與真實的古地圖進行疊加比對。因此，我想先探索一下中央研究院（中研院）到底有哪些相關的歷史圖資資源可以使用。 （未完待續：下一篇，我們將打開中研院的百寶箱，解析歷史圖資的魔法！） 本文為哈爸與 AI 助理協作產出，紀錄實體探勘與數位工程之歷程。