哈爸筆記

今天，我們終於走到了 11 個流域探索計畫的最後一站：頭前溪。 作為這系列數位探索的「大終章」，頭前溪對我的意義非比尋常。這是我生活的主場，也是我每日通勤、呼吸的水源地。但也正因為這份熟悉，當我用之前產製的「AI 深度研究計畫 (Research 3)」去對合時，我感到了前所未有的 「違和感」。 這篇筆記，將記錄我們如何在這最後一站，完成 HGIS 方法論的 「權力對合革命」。 1. 質疑與修正：當 AI 遺漏了靈魂 之前的 AI 報告（Research 3）過於迷戀「科學園區供水」與「豆腐岩」的現代地景。但如果你翻開《新竹五書》，你會發現頭前溪的靈魂其實被隱藏在 「竹東、東興、隆恩、汀甫」 這四條名圳裡。 竹東圳 (21km)：它不是普通的溝渠，它是 1920 年代跨流域引水的工程奇蹟，更是後來科學園區水路技術的「史前雛形」。 東興圳：它在竹北高鐵區的斜向流動，是客家士紳對抗現代格子城市格線的最後痕跡。 筆記心得：如果探索不包含這些大圳，我們只是在看「河床」，而不是在讀「社會脈動」。 2. 從「地理圖釘」進化為「角色繫結 (Entity-Binding)」 這是我在這一站做的最大修正。以往我們只標記「這裡是隆恩堰」，但現在，我們強行執行了 POI Actor Attribution： 節點 = 問禮堂 -> 角色繫結 = 六家林家。 節點 = 指標性圳路 -> 角色繫結 = 王世傑 (新竹規劃師)。 這就是我們在 系列五：知識圖譜 中提到的邏輯。當地圖上的圖釘不再是死物，而是連結著《新竹五書》中鮮活的家族利益與水權博弈時，你的導航助理才會告訴你：「這不只是水，這是王世傑當年為了軍隊運糧所佈下的百年棋局。」 3. 數位資產的極致對合 (Triple-Sync) 在頭前溪計畫中，我們實踐了目前最複雜的數據對稱： KML 層級化：嚴格依照 RV_NO 分出主流、支流與次溪流，並注入 Associated_Entity 屬性。 SQLite 高階化：首次在 walkgis.db 中全面使用 WKT (Well-Known Text) 語法定錨空間標註。 ISMap 模組化：將計畫拆解為四大權力弧線（邊界、規劃、士紳、門戶），支援隨時「進場/離場」的模組化走查。 4. 11 流域工程的終局感悟 從第一站到第十一站，這場數位鍊金術讓我明白：「地圖是實體世界的代碼，而 HGIS 是對這段代碼的逆向工程。」 ...

「水權即政權，權力即空間。」 作為 11 個流域探索的最終站，同時也是哈爸的居住地，頭前溪計畫不再只是河道走查。受到 HGIS 系列五：知識圖譜 的啟發，我們將這份 8 日模組化計畫升級為 「Entity-Bound（角色繫結）」 的時空導航。 為什麼這麼做？ (Why This Path?) 傳統的河流研究（如 AIBook 3）過於偏重工業供水與美學工程（如豆腐岩）。但在《新竹五書》與歷史地圖的層層堆疊下，頭前溪其實是一張由 士紳家族 與 四大名圳 編織而成的權力網。我們將探索焦點從「設施」轉向「角色（Agents）」。 四大權力弧線 (The Four Arcs) 本計畫拆解為四大弧線，使用者可依據興趣與時間隨時調用對應的「模組」。 1. 邊界與隘墾之弧 (Arc of the Frontier) 探索點位：五峰源頭、北埔姜家 (金廣福)、竹東圳取水口。 繫結角色：泰雅族主權者、莊進連、姜氏家族。 核心命題：山區水源如何被「轉化」為支撐全球貿易（茶、煤）的原始資本？ 2. 規劃師的藍圖之弧 (Arc of the Planner) 探索點位：隆恩堰、隆恩圳/汀甫圳分水分離點、竹蓮寺。 繫結角色：王世傑 (Wang Shijie)。 核心命題：清初規劃師如何運用灌溉工程養活肉體，再用信仰中心（竹蓮寺）定錨精神？ 3. 士紳地景之弧 (Arc of the Gentry) 探索點位：東興圳 (竹北)、六家問禮堂、汀甫圳 (高地段)。 繫結角色：六家林家 (新竹五書)、北門鄭家。 核心命題：水權如何分層？為何斜向流動的東興圳，能在高鐵特區的格子街道中存活下來？ 4. 門戶與微血管之弧 (Arc of the Gateway) 探索點位：槺榔驛 (輕便車)、舊港島、南寮。 繫結角色：新竹軌道株式會社、島港豐巢團隊。 核心命題：資源產出的最後一公里路，以及 1898 戊戌大水後的城市韌性。 數位探索資產 (Digital Assets) 本計畫提供具備「角色屬性」的互動資產，在 Google My Maps 上點擊圖釘即可看到繫結的人物故事。 ...

今天去國泰世華銀行的零錢機存了一大袋累積已久的零錢。因為機器限制一次只能投入 100 枚硬幣，我分了三次才存完。回到家後，我看著這三張明細單，心血來潮想跟 Gemini 來一場關於「零錢隨機性」的小實驗。 這次的過程與心得，讓我對 AI 在生活自動化與知識輔助上的成熟度感到驚艷。 零錢機存款數據萃取 我直接拍了三張存款明細單，丟給 Gemini 處理。 數據彙整 (2026/03/14) 交易時間 50元 10元 5元 1元 總金額 10:42 10 63 14 13 $1,213 10:45 12 53 20 15 $1,245 10:53 10 66 13 11 $1,236 合計 32 182 47 39 $3,694 我的心得與觀察 1. Gemini 的影像辨識極其準確 我丟出的照片只是隨手拍的收據，字體雖然清晰但仍有陰影與背景干擾。Gemini 能夠完美萃取出每一種幣值的數量、日期與金額，而且完全正確。這證明了「影像轉結構化數據」的技術已經非常成熟。 2. 邏輯計算能力強，沒有幻覺 在進行三組數據的彙整、四種幣值的加總時，Gemini 直接進行了精確的邏輯運算。完全不需要依賴額外的 Python 程式碼，加法與乘法（計算總金額）都做得非常正確，完全沒有所謂的「AI 幻覺」或計算錯誤，這在使用體感上非常安心。 3. 在實驗中複習統計學 除了數據匯總，我更感興趣的是「隨機性」。我把硬幣混在大袋子裡，每次「一把抓」投入。我問 AI：這三次抓取的比例是否合理？ 藉由跟 AI 的討論，我學到了： P 值 (P-value)：這次實驗的 P 值約為 0.65，代表這三次的差異純粹是機率湊巧，我的抓取動作非常隨機。 巴西堅果效應：討論中發現，為什麼 5 元和 1 元有時會成群出現？原來是因體積小而掉入縫隙的物理特性。 4. 與 AI 深度討論帶來的細節觀察 最有趣的是與 AI 討論「為什麼 10 元這麼多？」。 我們一起發想，這反映了台灣的消費習慣（找零主力）、定價邏輯（多為 5 或 0 結尾），以及我們對高面額硬幣（50元）會優先花掉的心理偏好。一場簡單的存零錢，竟然可以延伸成社會學與物理學的小討論。 ...

在兩週前，我們釋出了《流域導航》v2.0，確立了「HGIS Layer 0-1-2」的三層知識架構，並透過 hgis-atlas-architect 技能大幅提升了地名與史料的對合效率。 然而，隨著我們深入曾文溪流域的「青瞑蛇」改道史，我們撞上了一個數位探索的核心挑戰：當文字史料斷裂時，該如何導航？ 今日，我們正式釋出 《流域導航》v2.1 (Relic & Deep-Time Modeling)。這是一個從「行政地名變遷」跨越到「萬年尺度生存演義」的重要版本。 為什麼要有 v2.1？看見「超越文獻」的硬證據 文字會撒謊，行政邊界會消失，但土地上的「硬證據」——考古遺蹟 (Relics)——是誠實的。 在 v2.1 中，我們引入了 Layer 3 (屬性推論與演繹) 與 Layer 4 (空間拓樸) 的完整定義。我們不再滿足於「標註一個點」，而是要「還原一套生存邏輯」。 核心突破一：OO-History (物件導向歷史) 建模 為了處理全台 2,500 處以上的考古遺址而不迷失，我們導入了軟體工程中的物件導向思維。我們建立了 Root-Spec-Entity 三層繼承架構： 90% 繼承 (Era Spec)：直接繼承特定時代（如：大坌坑文化）的「共性樣態」。 10% 覆寫 (Relic Entity)：僅針對特定遺址的「異常證據」（如：南科遺址中超前出現的稻米）進行考證與標籤覆寫。 這套方法顯著降低了歷史數據厚化的成本，讓我們能以「集團軍」的方式，快速為數千個歷史物件立起具備深度的「生活樣態框架」。相關規格已對齊 MASTER_HISTORY_SCHEMA.json 字典。 核心突破二：生存第一原理與「能源平衡模型」 在 Layer 3 的演義中，我們引入了系統工程的視角。我們將史前家庭視為尋求「能源平衡 (Energy Balance)」的運算單元： 輸入：河口、潟湖與森林格網的資源產量。 能耗：維持生命與遷徙的物理成本。 遷徙演算法 (Migration Algorithm)：當資源密度不足以支撐能耗，族群如何根據「空間記憶」進行決策。 這讓我們產生了一份極具震撼力的 「南科案例」：模擬五千多年前，當曾文溪主流北移、潟湖淡水化時，南科先民如何展現「跟著河口跑」的追蹤式遷徙樣態。 核心突破三：「預測 -> 驗證 -> 修正」的建模迴圈 v2.1 的操作心法從「讀圖」變成了「對抗」： 原理發想 (Prediction)：根據生存原理，在腦中先立起「建築基本樣態」。 證據對合 (Verification)：將發想與 taiwan-history-atlas 的實測考古數據（如：離河距離 HRD 聚類、高程位能指標）進行對撞。 假說重構 (Correction)：透過「差異值」發現歷史真相——如果發想與數據不符，通常代表我們發現了「技術突變」或「族群例外的生存策略」。 結語：導航在一場永無止盡的演義中 《流域導航》v2.1 的釋出，象徵著這套系統已具備了「跨時空虛擬對合」的雛形。當你不再看見單純的風景，而是看見一組組具備生存邏輯、不斷進化的物件時，你才真正讀懂了流域。 ...

在完成《個人賦能》書籍的集成後，我的注意力重新回到了這片土地。 過去一週，我們對《流域導讀》（現正式更名為《流域導航》）進行了一場堪稱「範式轉移」的升級。如果說 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+《新竹縣/市志》(現代修訂版本) 有了這張圖，我就知道該去哪裡尋寶了。於是，我花了一點時間想辦法把這些史書從網路上抓了下來（大部分都順利搞定了）。 ...