Project (專案)

最近兩天，我跟我的 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 的一鍵產出： ...

在完成平面位置 (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 的拓樸數據告訴你：「這個位置雖然現在離曾文溪很遠，但在三千年前，它正好位於主要支流的交會口，是一個戰略性的交通節點。」 ...

在之前的 HGIS 系列中，我們主要處理的是「紙上的歷史」——透過方志與古籍還原清代的社會空間。然而，要真正觸摸到「台灣主體性」最深層的脈絡，我們必須將目光投向更長的時間尺度：考古遺址。 如果說《臺灣通史》記載的是數百年的族群演進，那麼埋藏在台南平原地底下的「文化層」，則是長達數千年的地景變遷證詞。 今天，我正式在 Taiwan History Atlas 專案中發布了 v260306.1 更新，核心重點就在於建構一套具備「血緣追蹤」能力的 考古遺址 Master Registry (主註冊表)。 🏛️ 為什麼我們需要 Master Registry？ 在處理全台遺址資料時，最頭痛的不是「沒資料」，而是「資料太多且碎片化」。文資局有「法定遺址」、中研院有「普查遺址」、地方政府還有「疑似遺址」。 要在 AI 輔助下進行科學分析，我們不能只是貼貼補補，必須建立一個 Master Registry： 資料對齊：解決同一個遺址在不同單位有不同名字 or 座標微差的問題。 層級化建模：將原始資料 (L0) 轉化為帶有語義標籤的實體 (L1)，再整合進知識中樞 (L2)。 血緣追蹤 (Source Origin)：每一筆數據都能回溯到是哪個單位的原始點位，確保「證據力」。 目前這套系統已成功整合了 2,563 處 遺址，成為我們 HGIS 引擎中最堅實的核心數據庫。 🛠️ 核心腳本與工作流 (Scripts Toolkit) 在 taiwan-history-atlas 儲存庫中，我們透過以下工具實現了這一流程： 1. Layer 1：實體萃取與特徵標記 利用 scripts/extract_entities.py，AI 會自動掃描原始 Open Data 文本，提取出： 文化年代：從大坌坑、蔦松到金屬器時代。 遺址等級：Rank 1（國定）到 Rank 4（疑似）。 特徵標籤：貝塚、石器、多層疊壓等。 2. Layer 2：跨庫遷移與合成 使用 scripts/atlas_migrator.py，將分散在各區域的實體統一遷移至 data/history_atlas.db。這個過程不只是搬家，更是在進行「去重 (De-duplication)」與「血緣標註」。 ...

本文記錄了《企業生成式 AI 轉型》方法論中，關於『個人為主，團隊為原型』的首次實體化實驗。 回顧這些日子以來，我與 AI (Antigravity) 的協作已經達到了一種近乎肌肉記憶的流暢感。從建立 [TMUX 自動化工作空間]、使用 Hammerspoon 打造「2+1 快手」，到用 TASKS_LEDGER 與 Mermaid 畫出戰略版圖，這是一套高度個人化的超級沙盒 (PA Sandbox)。 但問題來了：如果我是一個超級個體，當我們要把這種力量擴展給一個 3 到 5 人的「超小型團隊 (Nano-Squad)」時，該怎麼辦？ 總不能要大家都學會寫 Python 腳本，或是用我特製的 Hammerspoon 快速鍵吧？ 這就是這次 團隊 AI 協作中樞實驗計畫 (SyncHub Prototype) 誕生的背景。 理論基石：碎形邏輯與單一真相來源 (SSOT) 在《演化路徑：企業賦能的碎形邏輯：個人為基，團隊為原型》第 0 章中，我們定義了企業轉型的最小實踐單位：超小型團隊 (Nano-Squad)。 如果企業是由個體組成的碎形，那麼團隊管理與個人管理的架構就應該長得一樣。 這次的實驗，我們徹底拋棄了 LINE 或 Discord 這種容易造成「資訊孤島」與「語意發散」的即時通訊軟體作為真相來源。我們將 GitHub (Git 檔案系統) 確立為團隊的唯一真相來源 (Single Source of Truth, SSOT)。 所有的共識、決策、任務進度，都必須落地為 Markdown 或 YAML 檔案。 創新機制：非同步的「脈絡拋接 (Inbox / Outbox)」 為了消弭「團隊強制同步」帶來的摩擦力，並且保護個人的「AI Sandbox」實驗空間，我們設計了一套極其優雅的對合機制： 個人主權區 (members/{name}/workmgr/)：每一個團隊成員都有自己的安全區。你在這裡用你習慣的法子、自己的 ChatGPT/Claude 來打草稿、做研究，沒人會管你。 對合與裁決 (sync/outbox/)：當你覺得任務完成了，或者卡關需要團隊幫忙時，你（人類）必須下達「裁決」。把你的精華整理出一個 Payload，丟進你的 Outbox。 戰略大腦 (workmgr/inbox/)：團隊級別的 AI (SyncHub)，就像一個數位幕僚長。它會定時去各個成員的信箱收信，檢查有沒有語意衝突？有沒有偏離 Roadmap 戰略？然後自動將這些進度整合成團隊今天的小報，並刷新總任務帳本 (TASKS Ledger)。 這套機制的精妙之處在於：它將微軟或 Google 提倡的 Multi-Agent System (MAS) 本地化到了檔案系統上。 LLM (大型語言模型) 原生就非常擅長讀取這種純文字的檔案結構！ ...

面對數百首從 CD 轉錄、檔名雜亂、標籤缺失的鳥鳴音訊檔，你會選擇手動一首首修改，還是開發一套具備「生物學智商」的自動化系統？ 我起初的想法很單純：在野外走動時，如果聽到鳥聲，我希望能有機會辨識出那是哪隻鳥。於是，企鵝給了我一大包鳥鳴音檔。我只是想找個容易的方式，能隨時翻出想聽的聲音來學習，結果為了這個簡單的願望，就乾脆擼出了這套工具。 這篇文章記錄了 birdsong-processing-kit 的誕生過程：我們如何利用 Gemini AI 與 iNaturalist 生物資料庫，將 816 首混亂的 MP3，轉化為具備「綱、目、科、屬」專業階層、內嵌高清封面與詳細標籤的數位資產。 🎯 核心目標：建立聲音的「數位孿生」 我們擁有的原始資料非常雜碎：有的檔名是「3-55」，有的標籤是日文，有的則是空白。這次自動化改裝的核心目標有三： 結構化分類：按生物學階層（綱/目/科/屬）重新組織目錄。 資訊厚化：自動注入 iNaturalist 的標準中文名、學名、以及物種封面圖片。 溯源管理：在 ID3 標籤中保留原始路徑，確保搬移後依然能追蹤來源。 🛠️ 實作方法：身分校對三部曲 (Identity Cascade) 在開發過程中，我們建立了一套名為「識別決策瀑布」的邏輯，以達到準確度與成本的平衡： 1. 文字優先 (Text-First Discovery) 過度依賴 AI 聽音辨位既昂貴又緩慢。系統會先遍歷原始 ID3 標籤與檔名，清洗掉序號與雜訊，產生候選清單，並優先查詢 iNaturalist API。只要文字比對能獲得精確分類，就不啟動 AI。 2. AI 聽聲辨位 (Gemini 2.5-flash) 針對完全沒有名稱資訊的音軌，系統會自動上傳音訊至 Gemini 2.5-flash。透過 Flash 模型強大的多模態理解力，讓 AI「聽完」後回傳 JSON 格式的識別報告，作為識別的最強墊底方案。 3. 分類中文化校正 iNaturalist 的高階分類（如目、科）往往只有英文或拉丁文。我們另外調用了 Gemini 2.5-flash 針對識別出的學名清單進行批次翻譯，確保目錄結構呈現如「鴞形目/鴟鴞科」這樣的純中文專業觀感。 🚧 遇到的挑戰與克服之道 挑戰 A：AI 成本與處理速度的矛盾 困境：全量 800 多筆若全部上傳辨識，不僅 Token 消耗大，且速度緩慢。 克服：實施「文字預檢」機制。透過 mutagen 深度挖掘 ID3 標籤中的「隱藏資訊」，將 80% 的檔案在文字階段就完成對合，剩餘的 20% 才交由 AI 處理。 ...