今天去國泰世華銀行的零錢機存了一大袋累積已久的零錢。因為機器限制一次只能投入 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元）會優先花掉的心理偏好。一場簡單的存零錢，竟然可以延伸成社會學與物理學的小討論。 ...

哈爸筆記： 這是一場「名為探訪，實則流浪」的旅程。一開始雖然帶著探查烏溪流域的企圖心，但礙於事前規劃不及，最終回歸到「直覺式探索」的流浪模式。但也因為如此，意外體會到了在平日、在優質景點上「悠閒」的福氣。 總結：流浪中的悠閒與意外驚喜 這次旅程最大的收穫是**「悠閒」**。因為是平日，各大景點導覽與服務人員都顯得格外親切，互動也多。雖然在 AI 導遊功能的穩定性上多花了一些 debug 時間，甚至因此減少了與 Gemini 語音聊天的機會，但在重要單點（如鳥嘴潭、霧峰林家）停留時間更長，體驗反而更好。 核心洞察： 框架的重要性：探訪若無事前框架，臨時上場還是會感到吃力。說是探訪烏溪，其實更像是「剛好在烏溪流域流浪」。 悠閒是種福氣：能在好的點上悠閒，與人深入互動，是平日旅遊最大的奢侈。 AI 協作的摩擦力：目前「AI 導遊」功能仍不穩定，開發與除錯過程佔據了部分體驗時間，這是後續需要最佳化的地方。 旅程紀實 Day 0 & Day 1：從公部門水源到人工湖的壯闊 (3/10 - 3/11) 旅程從南投水保署的一場演講展開。隨後進入了水利資源的深度探索： 水規所導覽：參訪展館並受贈《島都之河》、《尋湖》等珍貴資源。 鳥嘴潭人工湖：在熱心志工導覽下，理解了人工湖作為現代水資源開發的高效方案。 九九峰氦氣園區：雖然沒搭到熱氣球，但在高架網格上的一場午覺，以及在木頭上畫下的五色鳥，找回了手做的平靜。 草屯市場美食：大觀市場的巧味潤餅、新口味雞肉肉包（超多汁！）是今日的靈活亮點。 Day 2：山林間的水門與靈長類的凝視 (3/12) 今日進入更深的山林，觀察水的律動： 惠蓀林場：近距離觀察猴群，感受原始自然的生命力。 北圳驚喜：路經茄苳樹公時，意外發現了「水過橋」的北圳。看著圳水在山林與農作間自然流轉，隨時可切換的水門充滿了生活與土地交織的味道。 國姓流連：在南港溪與北港溪交會處駐足，雖然看不出太多門道，但在免費廣場車宿，享受了一整晚的寧靜。 Day 3：霧峰林家的生命揮霍 (3/13) 最後一天的行程集中在霧峰林家，這是一場文化的洗禮： 大花廳的午休：在壯觀的戲台前，我打開電腦，在此度過了整個午休。引用一句話：「生命就是該浪費在美好的事物上。」 頤圃與萊園：在熱心的台語導覽中，感受清朝頂級居所的品味。坐在總統級嘉賓的座椅上，時空彷彿在此交錯。 霧峰第一市場：用烤地瓜與肉羹麵線為這場文化之旅劃下滿足的句點。 數位後影：AIQA 與 知識轉化 回到家後，透過 AI 進行了資料的再處理： NotebookLM 摘要：將旅程照片與筆記丟入 NotebookLM 進行關鍵洞察提取。 Mermaid 家族圖譜：霧峰林家的祖譜資料，順手用 AI 轉化為 Mermaid 加密架構圖（雖然部分細節因照片解析度而稍顯模糊，但足以視為數位考古的嘗試）。 地圖資產 互動地圖：烏溪 Google My Map ISMap 註冊檔：存於 static/walkgis_prj/data/2026台灣河流探索/烏溪/烏溪.kml 結語 雖然「探訪烏溪」的標題有些牽強，但這場在流域間的流浪，讓我重新找回了旅遊的「體感」。不再是趕點，而是與地方的人、當地的水，進行了一次從容的對話。 ...

最近兩天，我跟我的 AI 夥伴 (Antigravity) 泡在 Travel-Advisor-HUD 這個專案裡。目標很單純：讓我的行車助理不再只是「唸出路名」，而是像個真正懂我的「私人導遊」。 在兩天的密集對話中，我們經歷了幾次關鍵的「卡關」與「破繭而出」，這幾個點我覺得是開發地理感知型 AI (Geographic AI) 最迷人的地方。 🚀 什麼是 Travel Advisor HUD？ 這是一個跨裝置的行車助理系統：由 Mac 負責背景運算與大腦邏輯，iPad 則作為沈浸式視覺看板 (HUD)。它能感知你的位置、速度與航向，並結合你過去在 WalkGIS 筆記中的內容，由 Gemini 生成具備人文厚度的即時導覽。 🧩 關鍵卡關與突破 1. 沉重的 Geopandas 與「資料主權」的執念 一開始，我們想用 Python 的 Geopandas 來處理鄉鎮邊界 (SHP) 的空間對位。但在路測邏輯中，Geopandas 顯得過於笨重，且我有一個堅持：「資料主權」。 我不想為了讓 AI 讀數據，就把我珍貴的 walkgis.db (私有筆記) 或內政部的圖資檔案搬來搬去、轉檔轉去。 突破點：我們轉向了 SpatiaLite (SQLite 的空間外掛)。 心得：透過 ATTACH DATABASE 直接掛載原始 DB，並用 VirtualShape 虛擬映射 SHP 檔案。資料「原地不動」，但查詢卻是極速的 SQL 指令。這讓「資料主權」與「運算效能」在這一層完美的對位了。 2. 從「歡迎」到「盤點」的內容層次 原先的導覽很死板：進入新縣市就唸一段 Wiki 簡介。但開車的人真正需要的是：「這裡有沒有我以前記過的東西？」 卡關：AI 雖然強筆強大，但如果你不給它具體的「本地上下文」，它只會說些漂亮但空泛的廢話。 突破點：「行政區點位盤點 (Township Inventory)」機制。 心得：在跨越邊界的瞬間，系統自動在背景先發動一次空間點名，把該鄉鎮內所有關於我的私有筆記 POI 抓出來，做成摘要餵給 Gemini。當 AI 說出：「歡迎來到橫山，這裡有您之前筆記過的內灣車站喔…」時，那種「它真的懂我」的導覽感才算真正建立。 3. Hammerspoon 的定時器與動態設定 Hammerspoon 雖然穩定，但預設的定時器是靜態的。如果我在開車中想調整檢查頻率（比如從 5 分鐘改成 1 分鐘），以往我得停下車，打開 Mac、改代碼、Reload Config。 ...

烏溪流域探索：行前計劃 (SOP 實測回補) 目的：本計畫為「烏溪流浪」後的「反向建模」，旨在利用修訂後的 river-exploration 技能，將零散的探訪點補完為具備敘事靈魂的數位資產。 1. 數據準備 (Bones) 流域範圍：大肚溪（烏溪）流域。 物理資產：產製 static/walkgis_prj/features/20260310_Wuxi/ 下共 14 個核心 POI。 混合圖資：整合在地「水利設施圖」與 Google Maps API 精確座標。 2. 敘事靈魂 (Soul) 核心簽名 (River Signature)：「治理、轉向與文化遺產的對換」。 主題設計： Day 1: 水權與民生：從水規所的治理視野到人工湖的實體產製。 Day 2: 山林與渠道：北圳引水工程的地景契合。 Day 3: 權力與美學：霧峰林家作為流域內的權力與文化頂點。 3. 導航序列 (Navigation Sequence) Day 1 (3/10): 水規所 -> 鳥嘴潭 -> 九九峰 -> 大觀市場 Day 2 (3/12): 惠蓀林場 -> 北圳 -> 糯米橋 Day 3 (3/13): 霧峰健體中心 -> 頤圃 -> 萊園 -> 大花廳 數位地圖特徵檔 (WalkGIS Features) 已產製於 static 目錄。

在兩週前，我們釋出了《流域導航》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 的釋出，象徵著這套系統已具備了「跨時空虛擬對合」的雛形。當你不再看見單純的風景，而是看見一組組具備生存邏輯、不斷進化的物件時，你才真正讀懂了流域。 ...

在實現 QGIS 專案「一鍵生成」的路上，我們不僅要讓圖層「開得出來」，更要讓它「具備研究價值」。 這篇文章記錄了我們從 POC2 (樣式與標籤整合) 進化到 POC3 (空間分析與 SDM 紀律) 的完整心路歷程。這兩個階段分別解決了製圖中的「美學溝通」與「科學建模」兩大核心問題。 🎨 POC2：視覺精煉與動態標籤 (Visualization & Labeling) 目的：讓地圖「會說話」，透過自動化配置解決手動製圖中最繁瑣的排版工作。 在 POC1 成功掛載圖層後，我們發現原始的點位與線條在混亂的歷史底圖（如台灣堡圖）上極難辨識。POC2 的核心目標即是透過腳本，賦予地圖專業的視覺外觀。 1. 幾何感知的自動標註 (Geometry-aware placement) 我們實現了腳本對圖層類型的自動識別與對應配置： 點位圖層 (遺址)：自動採用 Centroid 配置，讓標籤精確落在遺址中心。 線段圖層 (河流)：自動切換為 Around Line (平行排列)，並預設帶有 0.5mm 的偏移量。這讓河名能順著水流蜿蜒，展現專業製圖感。 2. 跨平台字型與視覺消隱 (The macOS Fix) 我們在 POC2 中遭遇了字型相容性的重擊。原本預設的字型在 Mac 上會毀掉專案解析。最終，我們強制切換為 PingFang TC (萍方-繁)，並自動啟用了 0.7mm 白色光暈 (Text Buffer)。這小小的光暈，是讓地圖文字從花綠底圖中「浮現」出來的關鍵。 🛡️ POC3：空間分析中樞與 SDM 紀律 (Advanced Analysis & SDM) 目的：從「資料顯示」進化為「規律開發」，在不污染原始數據的前提下，自動生成分析模型。 當地圖變漂亮後，下一步就是「看見模式」。POC3 挑戰的是自動產出具有研究深度的分析圖層（如海拔區間與熱點圖）。 1. 恪守 SDM 紀律：絕對不改動原始資料 (Data Hub Snapshot) 開發者常為了分析方便，在原始 SQLite 裡建 View。但對歷史數據來說，原始碼應該是神聖的 (Holy Source)。 我們實作了「局部資料中樞 (Local Data Hub)」：腳本在產出專案的一瞬間，自動建立一個 poc_data_hub.db 快照。所有的 JSON 萃取、高程分區計算都只存在於這份快照中。原始 HGIS 資料庫保持 100% 乾淨，專案檔則是「可打包、可重製、可拋棄」的。 ...

在進行 HGIS（歷史地理資訊系統）研究時，我發現最耗時的往往不是分析數據，而是「準備地圖」。每次要開啟一個新研究，總要重複掛載百年歷史底圖、設定 KML 座標、調整 SQLite 的 SQL 篩選器…。 為了打破這個瓶頸，我發起了一場實驗：能不能像寫程式一樣，用「寫」的出一份 QGIS 專案？ 這就是我最近在推動的 軟體定義地圖 (Software-Defined Maps, SDM) 概念。 🏗️ 為什麼要自動化？ 如果你手動配置過 QGIS，你一定遇過這些崩潰瞬間： URL 特殊字元破壞專案：WMTS 的 URL 裡一堆 &，手動貼上 XML 常報錯。 座標系統 (CRS) 位移：明明設定了 WGS84，圖層卻飄到非洲西岸海面（座標 0,0）。 重複定義的勞力：每個專案都要重新分組（底圖、水理、點位），這應該交給機器人。 透過 Python + Jinja2 模板，我們可以把地圖專案變成可程式化的零件。 🛠️ 基本作法：Jinja2 零件化 核心思路是將 .qgs 專案檔（實質是 XML）拆解為模板。 我們建立了一個 base_project.qgs.j2，裡面預留了動態注入的內容： 層級化圖層樹：自動生成的分組。 資料源設定：SQL 篩選指令與檔案路徑。 空間參考系統：自動注入對應的 AuthID、Proj4 與 SRID。 最關鍵的「零件庫」是 GIS_KNOWLEDGE.yaml。它充當了 GIS 資源的「DNS 伺服器」，記錄了所有中研院底圖、本機 KML 與資料庫的 Metadata。 🚀 第一階段 POC：曾文溪 HGIS 數位中樞 在這次的 POC 中，我們成功實現了 Zengwen_HGIS_Hub.qgs 的一鍵產出： ...

本文記錄了 2026 年 3 月 7 日，關於「WhatNext (WN)」發想轉化流程的實戰經驗與方法論優化。 你是否也有過這樣的經驗？在晨間運動或通勤時，腦中突然湧現出極佳的靈感與邏輯鏈。你想記錄，但手邊只有手機，不方便打字。當你結束行程回到電腦前，那股靈感的火花可能已經消逝大半。 這就是我啟動 WhatNext (WN) 系統 的初衷：利用晨間爬樓梯、快走時的高含氧思維，捕捉那些天馬行空的連結。但更重要的是：如何讓這些靈感「不再死於摘要」，而是真正轉化為可執行的數位資產？ 今天，我與 AI (Antigravity) 透過一次 37 分鐘的錄音轉化實驗，提煉出了一套極具穿透力的發想轉化方法論。 核心痛點：靈感的「摘要損耗」 以往我們習慣將語音丟給 AI 產生「基本摘要」。摘要固然能讓我們抓到「講了什麼」，但對於複雜的邏輯推演（如：史前社會演進、複雜系統設計），摘要往往會省略掉最精華的推論鏈 (Reasoning Chain)。 在今天的案例中，我們探討了「台灣史前時代從母系社會轉向父系社會」的底層驅動力。如果只看摘要，結論可能只是「農業發展導致性別權力移轉」；但透過逐字稿 (Transcript)，我們保留了精準的因果關係： 舊石器時代：採集不需要強力武器 -> 兩性體力差異在效率上不顯著 -> 女性為生育與養育中心 -> 母系社會。 新石器時代：農業競爭加劇 -> 需要強力磨製石器進行打獵與保衛 -> 男性上肢武力優勢凸顯 -> 掌控關鍵資源分配 -> 父系社會。 這份「逐字稿優先」的體認，成為了今天 WN 方法論的第一個重要升級：針對複雜發想，逐字稿才是 AI 深度轉化的最佳燃料。 轉化架構：從「錄音」到「KB / 策略」的三階跳 我們定義了一套「最低摩擦力」的對合流程： 1. 隨境捕捉 (Capture) 場景：晨間運動。 媒介：語音紀錄。 核心：不限格式，盡情展開思維。 2. 核心轉化 (Ingestion & Distillation) 工具：NotebookLM。 動作：將「完整逐字稿」餵入，產出高質量的結構化輸出。 成果：建立對應的任務報告 (Task Report, TR) 與知識庫 (Knowledge Base, KB)。 實戰產出：一場運動後的「點子大爆發」 今天這場 37 分鐘的發想，在 AI 的高效轉化下，最終產出了： ...

在完成平面位置 (X, Y) 的座標標註與河流距離分析後，我總覺得地圖還少了點什麼。直到我們引入了 Z 軸——也就是高程數據，整個曾文溪流域的歷史才真正「活」了起來。 這是我在 HGIS 建模中最精彩的一場實驗：運用 20m DTM (數位地形模型)，讓遺址開口說出三千年來海陸變遷的秘密。 🏔️ 海拔高度：決定「是海還是陸」的生死線 在台南平原，海拔 5 到 10 公尺是一個神奇的區間。 透過 scripts/enrich_sites_with_elevation.py，我們讓 133 處曾文溪流域遺址自動去匹配內政部的 DTM 資料。這是一個跨縣市的圖磚掃描工具，能精確取出每一筆數據的高度。 考古證詞：南科考古館的案例 以 南科考古館 為例，其海拔約 5-7 公尺。 三千年前：這裡的海拔正好處於古台江內海的沙丘邊緣。大坌坑遺址中發現的「貝塚」，證明了這裡曾是海景第一排。 一千年前：隨著曾文溪泥沙沖積，海拔 6 公尺處變成了濕地與三角洲。 今日：它縮到了離海岸 30 公里的平原中心。 海拔等高線，正是這場「海退人進」演義中的指揮線。 🤖 Layer 3：讓 AI 具備「大歷史語義」 當我們有了 XY 座標、河流距離與 Z 軸高度後，我問了 AI 助理一個問題：「能根據這些數據，幫我寫出一段吸引人的導覽文字嗎？」 這就是 Layer 3：大歷史語義層 (Semantic Context Layer)。 我開發了 scripts/batch_l3_enrichment.py 作業管線。它不只是跑跑程式，而是讓 Gemini 扮演一位考古學家，結合這三個維度的數據，自動生成「地理歷史脈絡」。 AI 生成範例： 「這處遺址位於海拔 540 公尺的穩定河階，離曾文溪主流恰好保持 2.2 公里的安全觀測距離。這顯示先民在金屬器時代已具備極強的避災智慧，選擇了這塊永遠免疫洪水改道的『定海神針』…」 🛠️ 釋出指南 (Release Guide) 這一系列針對考古與地貌的深度模型，我已全數彙整進 Taiwan History Atlas 儲存庫的 v260306.1 更新 中。 ...

當我們在地圖上標註了全台兩千五百多個考古遺址後，下一個問題是：「為什麼他們要住在這？」 在傳統的 HGIS 中，我們習慣去找「古地圖」。但面對三千年前的遺址，世界地圖還是一片空白。這時，我們必須切換思維，引入 Layer 4：空間拓樸分析 (Spatial Topology)。 📐 什麼是 Layer 4？跳脫物理地表的「相對關係」 如果說 L1 是點位，L2 是知識，那麼 Layer 4 就是「點與環境的交互作用」。 我不想只是知道遺址在哪裡，我想知道它與「生存資源」——特別是河流的幾何關係。在曾文溪流域，河道會擺盪、海岸線會進退，但人類對於「取水與避災」的空間邏輯往往是恆定的。 透過 scripts/poc_l4_tributary_clustering.py 這個對合引擎，我們讓 2,249 個遺址自動去尋找它們對應的主流與支流，計算出精確的「離水距離」。 📊 數據發現：離水 2.5 公里的生存密碼 透過分析，我們在曾文溪流域發現了一個驚人的統計規律： 濱海初始期：離水最近距離平均約 2,700 公尺。 長期定居點：離水最近距離平均約 2,200 公尺。 這是一個 「生存甜蜜點」。 在那個沒有堤防的年代，住得太近（如 1km 內）會面臨曾文溪猛烈氾濫的改道威脅；住得太遠又取水不便。 這 2.5 公里的緩衝帶，正是史前先民在沒有現代水利工程的情況下，利用地形與距離「換取安全」的生存智慧。 🛠️ 核心工具：空間特徵標記 (Feature Extractor) 為了實現這種規模的運算，我在儲存庫中提供了一個關鍵腳本： scripts/feature_extractor.py：它不只記錄座標，更會透過幾何運算為每個點位打上「空間標籤」。例如：是否位於「河流樞紐」、屬於哪個「次流域」、以及其「離水梯度」。 這樣的設計，讓 AI Agent 在解讀資料時，不再只是讀到一串數字，而是讀到一個 「人類與環境博弈的空間邏輯」。 🤖 AI Skill 的深度應用 這項分析成果已整合進我們的 HGIS Architect AI Skill。 目前的 AI 助理不再只是會翻翻方志摘要，當你開啟此 Skill 並指向一個座標時，它能調用 L4 的拓樸數據告訴你：「這個位置雖然現在離曾文溪很遠，但在三千年前，它正好位於主要支流的交會口，是一個戰略性的交通節點。」 ...