AI協作

立霧溪水化：從 20m DTM 萃取「絕對連通」潛勢溪流的技術長征 最近在進行 2026 台灣河流探索：立霧溪 的計畫中，遇到了一個困難問題：「官方的河道路網在深山峽谷裡不夠用。」 為了在 Google My Maps 上能有精確的導航，我決定啟動一場「數位成河」的挑戰——從 203 張 DTM 網格中，重新模擬出立霧溪的水脈靈魂。 這是一場關於環境韌性、演算法優化與「繞過限制」的戰鬥。 1. 數據獵取：在 40 萬顆網格間尋寶 這場比賽的第一關是數據獲取。內政部地政司提供了高品質的 20m DTM (數值地形模型)。但下載下來後，是數百個碎片化的 .grd 檔案。 技術筆記：千萬別試圖用 Python 逐一讀取。直接調用 gdal_merge.py 進行物理合併，並強制使用 EPSG:3826 (TWD97/TM2) 座標定錨，這是台灣所有官方地形資產的生命線。 2. 演算法的七次轉生：從「碎虛線」到「大河模型」 剛開始模擬時，我們遇到了經典的碎裂問題。D8 演算法在極端陡峭的太魯閣峽谷中，會因為數位噪聲產生無數的「鬍渣」支流，這在手機地圖上簡直是一場視覺災難。 經歷了七個版本的迭代，我們總結出的 「大河模擬黃金標準 (V7)」 是： [V1-V3] 拓樸追蹤：將離散點串成線，確立了河流的連通性基礎。 [V5-V6] 40m 重採樣：在寬廣河谷（如天祥河床），20m 的解析度反而太精細，小石頭會擋住流路。將解析度降階到 40m，反而能「看透」大河深槽的路徑。 [V7] Priority-Flood Routing：這是最關鍵的突破。我們在填補地表窪地的同時，就「強行鎖定」每一格往海洋的唯一洩水路徑。這解決了平原河床「0 坡度」導致的斷流悲劇。 3. 爆破 2000 個物件的「透明牆」 當我們興奮地把幾千條河道支流匯入 Google My Maps 時，遇到了著名的 「2000 項目限制牆」。Google 說：「你的地圖太豐富了，我裝不下。」 這時，我們應用了 「物件原子化 (The Atomizer Pattern)」： 我們將 5,306 段官方河道網格，透過 KML 的 MultiGeometry 標籤，全部釘死在 同一個物件元件 裡。對 Google 來說，它只是一個「稍微大一點的物件」，而非幾千個物件。 ...

哈爸筆記： 在前一篇文章中，我提到烏溪之行是場「直覺式探索」的流浪。然而，流浪結束後，真正的挑戰才開始：如何將這些感性的體會，轉化為標準化、可傳承的數位資產？這幾天，我與 AI 助手 Antigravity 針對烏溪進行了一次深度的「事後補產製 (Post-processing)」，過程中不僅補完了圖資，更撞擊出一套全新的河流探索方法論。 數位考古：從「碎片段」中挖掘出的烏溪魂 這次補產製的過程，簡直像是一場「數位考古」。我發現原本以為「沒有資料」的地方，其實只是因為沒有用對方法。 2. 靈魂厚化：SQL 結構化採樣的威力 我質疑 AI：為什麼不分析《臺灣通史》全文？後來發現，用 grep 掃描 1GB 的純文字是最低效的。 我們改採 L0-SQL Pattern，直接從 taiwan_history.db 的 Layer 0 進行全文檢索。透過 JOIN 卷名欄位，我們驚喜地勾勒出霧峰林家「水權政治」的脈絡——從吳洛築圳到家族兵權的轉化。這種帶有「證據 ID」的分析，讓歷史不再只是故事，而是可以被索引的資產。 技術突破：主流、子溪與次溪的層級對位 在產製 烏溪.kml 時，我們落實了專業的水文層級管理： 主流：代碼 143000，深藍粗線，象徵流域的動脈。 子溪流：匯入主流的一級支流（如北港溪、大里溪），標準藍色。 次溪流：更細碎的微循環系統。 透過 dissolve (幾何合併) 技術，我們將原本破碎的線段結合成完整的生命線。在 Google My Maps 打開的一瞬間，烏溪流域的層級感躍然紙上。 成果預覽：烏溪 Google My Map 數位資產的「三位一體」 這次作業確立了未來每一條河流探索的標準產出： 空間骨架 (Skeleton)：存放於 data/ 的整合性 KML。 人文證據 (Soul)：與 KML 同目錄的 Historical_Evidence_Report.md。 導覽引擎 (Map)：註冊於 walkgis.db 的 ISMap 與 Features。 結語：為下一條河做準備 這次「事後補產製」最大的收穫，是我們將所有經驗寫回了河流探索的技能規範中。現在我們有了一般化的自動化產製腳本，未來只要輸入流域名稱，AI 就能在幾秒內產出標準化的資產包。 ...

哈爸筆記： 這是一場「名為探訪，實則流浪」的旅程。一開始雖然帶著探查烏溪流域的企圖心，但礙於事前規劃不及，最終回歸到「直覺式探索」的流浪模式。但也因為如此，意外體會到了在平日、在優質景點上「悠閒」的福氣。 總結：流浪中的悠閒與意外驚喜 這次旅程最大的收穫是**「悠閒」**。因為是平日，各大景點導覽與服務人員都顯得格外親切，互動也多。雖然在 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 寫專屬程式」的心路歷程，也驗證了人機協作中「人類提供結構，AI 提供執行」的高效模式。 1. 背景：細節與強度的拉扯 在田野中發現了一張細節極其豐富的珍貴舊地圖。這類地圖有個特性：如果你想一張照片拍完，細節（尤其是文字）會因為解析度不足而變得模糊不清。 為了保留所有細節，我採取了「局部特寫」法：分別拍下地圖的四個角落。照片是清晰了，但挑戰也來了：如何把這四張帶有手拿變形、光影與透視差異的照片，拼回原樣？ 2. 挫折：專業軟體的高牆 一開始我很有志氣地問了 AI，它推薦我使用全景攝影界的開源神器 Hugin。 雖然 Hugin 功能極強，但它的介面充滿了攝影測量學的專有名詞：焦距 (Focal Length)、失真係數 (Lens Projection)、控制點 (Control Points)…等。即便對著 AI 給的指南操作，我依然在無數次的對齊失敗與複雜的參數設定中感到挫敗。對我來說，我只是想拼一張圖，並不想成為攝影量測專家。 3. 轉機：AI 代理程式的「灰盒」實驗 我決定把「死馬當活馬醫」，直接請我的 AI 代理程式 (Antigravity) 寫程式處理。過程中我也學到了一課： 全自動的失敗 (Black Box)：一開始 AI 給了一支使用 OpenCV 內建 Stitcher 的程式。這類「黑盒」工具在處理旅遊風景照很強，但面對手拿翻拍、重複特徵不明顯的地圖時，演算法直接放棄（回報失敗碼 1）。 關鍵的人類介入 (Human-in-the-loop)：我發現機器缺的是「空間感」。我主動告訴 AI 每張圖檔對應的位置： 左上：IMG_4953 右上：IMG_4955 左下：IMG_4954 右下：IMG_4956 精準執行：有了這份資訊，AI 放棄了不穩定的全自動模式，改寫一支基於 SIFT 特徵匹配與透視變換的客製化腳本。 4. 技術大腦：這支程式的工作邏輯 這支 Python 程式不再是瞎猜，而是執行了以下步驟： 特徵提取 (SIFT)：在照片中尋找數千個數位特徵（如地圖上的線條交會點、古文字的筆畫）。 空間受限匹配：利用我提供的佈局，限定程式只比對「鄰接」的邊界，這大大降低了機器「認錯特徵」的機率。 透視投影變換 (Homography)：這是最重要的一步。手拍照片一定有歪斜，程式透過數學計算，將照片進行如同 3D 空間般的「拉伸對齊」，確保地圖上的道路能無縫銜接。 三階段融合：先拼左半部、再拼右半部，最後合體。 5. 心得：AI 時代的「灰盒」策略 這次經驗讓我體會到，我們不一定要去硬啃專業軟體的說明書。最有效率的方式是 「灰盒策略」： ...

哈爸筆記： 曾文溪不僅是一條河，它是嘉南平原的動脈，也是台灣近代史的縮影。經過五天、橫跨山海的實地踏查，我們從原本的「三日計畫」演變為「五日深度流浪」。這篇文章將這五天的地理拼圖、水利邏輯與人文感悟進行最終收束。 1. 曾文溪五日全路徑：山海逆轉攻略 不同於最初規畫的「由海向山」，我們最終選擇了**「山→中→海」**的逆向操作。這讓我們在旅程初期體力最充沛時，能直攻曾文溪最核心的蓄水心臟。 Day 1：移動與蓄水 (山) 從高速公路直奔楠西，探訪曾文水庫。看見全台最大水庫如何攔截阿里山脈的水源，並在龜丹溫泉洗去塵囂。 Day 2：記憶與溯源 (中上游) 在玉井、南化、左鎮穿梭。從噍吧哖的抗日歷史到左鎮化石園區的史前追尋，我們在惡地景觀中找尋台灣的起源。 Day 3：生命線的跨越 (中游) 主題是「淨水與輸水」。從山上水道博物館的百年紅磚，到跨越曾文大溪、滋養平原的大圳渡槽橋三連戰。 Day 4：數位與海口規律 (中下游) 在隆田 chacha 透過數位互動解構大圳，並在烏山頭水庫向八田與一致敬，隨後順流而下抵達安平。 Day 5：消失的內海傳說 (海口) 深入曾文溪泥沙堆疊出的台江浮覆地。在四草、鹿耳門與青鯤鯓扇形鹽田之間，完成對這條河流如何「創造土地」的最後見證。 2. 探索的三大關鍵元素 這次探訪讓我們抽離出探索流域的核心維度： A. 水利工程的「隱形地誌」 曾文溪不只是河道，它是一套精密的控制系統。從曾文、南化、烏山頭與虎頭埤四座水庫的座標串聯，到空中跨河的渡槽橋，這套系統支撐了嘉南平原百年的農業生產力。 B. 常民生活的「市場規律」 我們發現「傳統市場」是理解地方感最精準的座標。從玉井的碗粿到土城的𩵚魠魚羹，流域的人民如何依水而居、依地而食，在清晨的市場氣息中最為鮮明。 C. 歷史與生態的交織 從五千年的考古地層（南科考古館）到百年的抗日遺址（噍吧哖），再到現代的人工濕地（官田水雉園區）。流域是時間的載體，每一層地平線下都埋藏著不同的故事。我們強烈體會到，高品質的文化景點與專業博物館（如化石館、考古館、水道博物館、隆田chacha）應該被大量地納入台灣的旅遊規劃中，它們提供的深度是傳統走馬看花無法比擬的。 3. 規劃 vs 實際：計畫趕不上變化的「灰盒」實驗 透過對比 Git 紀錄中的「原始規劃」與「實際遊記」，我們能精確觀察到「機器邏輯」與「人類體感」之間的動態調適： 維度 事前規劃 (AI 靜態) 實際執行 (人機動態) 行程變異動能 (Insights) 策略方向 海向山 (由低至高) 山向海 (逆向攻略) 能量管理：體力最好時直攻核心大壩。 內容重心 工程與名詞導向 人文與故事導向 好奇心驅動：故事(噍吧哖)比水泥更有吸引力。 執行節奏 緊湊的點對點移動 容納非計畫的休息 恢復力機制：湖畔午睡、特定洗澡點的加入。 日常儀式 特定名店巡禮 穩定的「市場規律」 地方感建立：從傳統市場開始每一天的節奏。 分析洞察： ...

哈爸筆記： 流域探訪不只是地理位置的移動，更是一場關於「節奏管理」與「身心負載」的實驗。從早晨的市場氣息到早晨的工作窗口，我們在曾文溪的身影中，學習如何讓計畫在流浪中呼吸，並找出 AI 與人類智慧最理想的協作邊界。 這是一次以框架計劃提供流浪模式運行的曾文溪探訪。當我們修正了原本「由海向山」的路徑，改為「由山向海」的逆轉攻略時，許多關於探訪實務的洞察也隨之浮現。 1. 探訪的日常節奏：市場與時鐘 探訪流域慢慢歸納出穩定的操作模式。一天早餐的開始從傳統市場開始。由於深度的探訪以及車宿的特性，容易停留在小鎮過夜。 市場早晨規律：每天的行程從在地市場開始。原因很簡單：市場是最能直接體驗當地生活氣息的地方，且周邊匯聚了多元的在地早餐。這比找特定的名店更有彈性，也更具地方感。 需要注意時間分配： 人文景點（09:00 - 17:00）：博物館或古蹟有嚴格的開放時間。這要求探訪者必須根據開館時間精準安排優先級。 自然空窗期（06:00 - 09:00）：自然景觀不受時間限制，也可以拿來早點去探索，這 3 小時是極大化每日利用率的關鍵。 2. 「流浪型」探訪的優勢：以車為家 本次行程原定 3 天卻延展至 5 天，這種隨機應變的能力與流浪探索的特性來自於「無住宿限制」。 「以車為家」的流浪模式，讓改動行程的門檻降到最低。當我們不再受限於預訂的飯店，就能根據當下的體感與進度即時修正路線。這也反映出 AI 在規劃上的局限：它會機械式執行「3 天」的指令（因此在規劃時，可以多加入一步驟：天數的客觀選擇與評估），卻無法主動思考行程的合理性或在地文化的深度厚度。真正的優化，導源於人類隨時調整的靈活性，不過改變計劃的效能很高，可以很容易產出今天實際的探訪結果，也很快地能夠轉換出明天的探訪計劃。 3. 核心主題：水庫巡禮 這是一場遲來的「水庫之旅」。前兩次探訪走到上游時多已精疲力竭，往往因時間壓力而略過。本次從上游出發，在心理壓力較小的情況下，我們一口氣走訪了曾文溪流域的四座水庫，補全了這條河流最重要的資源調度拼圖。 4. 當探索遇上工作：高度艱難的平衡 關於如何「一邊探訪、一邊產出工作」的嘗試，結論是：極度艱難。 精神負荷：探索需要不斷導航、處理變數、確認下一個座標，這會消耗大量能量。 創造力的空缺：晚上用於總結行程，體力已達極限；早晨雖有 2-3 小時的工作窗口（06:00-09:00），但也僅適合處理後勤行政工作。真正具爆發力或創意的產出，難以在高度變動的路徑中實現。 5. 地圖、好奇心與在地文化 在數位時代，雖然導航方便，但我體會到傳統地圖不可或缺的價值。 傳統地圖的方向感：我們現在很容易略過地圖直接導航前往目的地，但傳統地圖更能幫助建立整體的空間方向感。 流域地圖的缺失：探索流域若能有專屬的「流域地圖」是最好的導引，但現實中這類資訊往往支離破碎。 好奇心驅動的準備：台南的歷史文化景點做得非常出色，有豐富的內容可以深入拓展。雖然這類功課可以事前做，但往往難點在於「沒看過就沒有好奇心」，因此不容易事先準備。許多驚喜是在現場被觸發後，才開啟了後續的連結。 精美地圖的取得：沿途收集了很多精美的手繪地景地圖（如水果地圖、農場地圖），這些具有強烈地方特色的資料，如果能在線上就事先取得，將會大大強化探訪前的願景建立。 6. 流浪型探索的關鍵技巧：鄉鎮導向與 AI 語音對話 在實際移動中，我發現「鄉鎮」是最自然的探索單位，路標指引也多以鄉鎮名稱為導向。重要的附近景點其實都會有路標，所以路標有顯示的其實是重要的景點，以探索的角度來說，每一個都去就可以了，這正是隨興探索最有趣的地方。 以鄉鎮為單位的深度經營：每進入一個新鄉鎮，我會先與 AI 對話，請它介紹該區域的基本資料、歷史與特色。這種「即時補課」的方式，能快速增加探訪的深度。 開車時的語音互動：在路途中，特別是獨自開車的漫長時間，利用「語音模式」與 AI 聊天了解即將探訪的區域，是一個極佳的技巧。這讓駕駛時間變成「資訊預習時間」，讓流浪型的探索不再是盲目遊蕩，而是帶著背景知識的深度巡禮。不過，目前互動中仍有一點遺憾：AI 並不知道你目前在哪裡，所以你得一直告訴他。若未來有工具能讓 AI 即時感知位置，變成像專業導遊一樣，一進入某個鄉鎮就自動介紹周邊特色，那體驗將會更加完整而無縫。 7. 實務優化：裝備與數位工具 交通與物流與後勤： 西濱與國道：觀察到西濱快速道路（台61線）的高架設計功能趨近高速公路，但休息站功能與國道完全不同。國道休息站不僅可以充電，甚至還能洗澡，這對車宿者是極大的助益。 洗澡點的預查：事前如果能收集一些可以洗澡的點（如運動中心、熱點洗澡處），或是汽車旅館的位置，對行程的穩定性會更強。 隨身管理：側背包優於腰包，需整合兩支手機與自拍棒。關於「蓋章」，建議使用單張紙蓋章並加註標籤，回頭整理的效益遠高於逐次使用筆記本。 數位地圖與 AI：Google Maps 的點位管理仍有優化空間。而 AI 的角色應是「脈絡累積器」，每日結束後將當日回饋餵養給 AI，能解決行動端與電腦端資訊不對稱的問題。 總結：持續累積的流域脈絡 台南在古蹟保存與文化故事的呈現上，確實有其獨到之處。透過與早餐店阿婆的對話，或是化石館的視覺震撼，我們在曾文溪流域看見了台灣土地的層疊感。雖然自然觀察仍受限於物種識別的知識庫，但透過系統性的後續整理與 AI 輔助，這些經驗正逐漸轉化為深刻的土地洞察。 ...

前言： 在完成了四天三夜的濁水溪溯源之旅後，許多朋友好奇：如何在有限時間內，規劃出如此深度且具備彈性的行程？ 其實，這不僅是一場旅行，更是一次 AI 協作 (AI-Augmented) 的實驗。我將這次的經驗提煉成一套標準工作流（SOP），分享給所有熱愛探索與科技的朋友。 現代探險家的數位工具箱 過去的探險家靠的是羅盤與手繪地圖；現代探險家則擁有強大的數位孿生工具： GIS 系統 (WalkGIS)：提供地理空間的骨架。 生成式 AI (LLM)：充當知識淵博的嚮導與秘書。 數位筆記 (Hugo Blog)：結構化記錄與歸檔。 這套方法論分為四個階段，形成一個從虛擬到實體，再回到虛擬的閉環。 階段一：數據鋪墊 - 建立地理認知 (Data Preparation) 在出發前，我們必須先「看見」這條河流。 數位孿生基礎：利用 GIS 技術提取流域範圍、河道、堤防與水利設施。這讓我們知道哪裡是「可以走的路」，哪裡是「值得看的點」。 興趣點豐富化 (Enrichment)： AI 可以在這裡發揮大用。我使用腳本串接 Google Places API，沿著河岸搜尋「補給點」（車宿洗澡點、美食）與「文化點」（古蹟、廟宇）。 這個步驟將冰冷的經緯度，轉化為有溫度的旅行節點。 階段二：行程規劃 - AI 協作草案 (Planning) 有了數據，接著是規劃。這不是寫死板的時刻表，而是建立一個「有邏輯的劇本」。 主題分段：我們將濁水溪切分為「海口信仰」、「橋梁水利」、「生態電力」、「山湖騎行」四個主題。 撰寫計畫文 (The Plan)： 我會要求 AI 根據上述數據，草擬一份 Blog Post (行前計畫)。 AI 的角色：它負責串聯景點邏輯（如：先吃肉圓再去冰店順路嗎？）、計算時間，並生成 Google Maps 的多點導航連結。 這時候的筆記標題通常標註 (行前計劃)，內容包含「預定行程」與「AI 協作聲明」。 階段三：實地探索 - 彈性與感知 (Execution) 帶著計畫上路，但要把心打開。 彈性執行：地圖是死的，路是活的。西螺大橋封路怎麼辦？鳥嘴潭來不及去怎麼辦？AI 的計畫提供了骨架，但現場的應變才是靈魂。 多感官記錄： 數位軌跡：開啟 ATAK 或運動記錄 APP，留下真實的 GPX。 當下紀錄：利用錄音或快速筆記，記錄當下的感受（例如：電輔車的隱形推力、九蛙疊像的實際水位）。這些細節是回家後寫不出來的。 黃金時間：當日結算與發佈 (The Golden Hour) 這是我認為長期旅程能持續下去的關鍵：絕不拖延。 ...

寫在升級後： 剛整理完濁水溪的探索方法論 (SOP)，正準備發佈時，發現我的 AI 助手 Antigravity 也有了新功能——支援 Skill (技能) 系統。 於是，我順手請 AI 將原本單純的文字版 Task，升級為更具結構化的 Skill。這不僅是一次工具的迭代，更是 AI 協作模式的進化。 什麼是 Antigravity Skill？ 過去我們習慣用 Task (任務) 來告訴 AI 做什麼，通常是一份 Markdown 文件，寫滿了步驟與指令。 而新的 Skill (技能) 則更像是一個 「可執行的軟體包」。它不僅有說明文件 (SKILL.md)，還可以包含專屬的腳本 (scripts/)、模板 (templates/) 與範例。 簡言之，Task 是給 AI 看的「說明書」，Skill 則是給 AI 用的「工具箱」。 實戰：建立 River Exploration Skill 我請 AI 將剛剛總結的「河流探索工作流」封裝成一個 Skill。 AI 迅速在 .agent/skills/river-exploration/ 建立了以下結構： SKILL.md：核心 SOP，包含了我強調的「黃金時間 (The Golden Hour)」當日結算流程。 scripts/gen_map_urls.py：把之前散落在專案裡的 Google Maps 連結生成程式，收納為此技能專用的工具。 templates/blog_post_template.md：標準化的遊記 Markdown 模板，確保每次產出的格式一致。 Task vs. Skill：優缺點比一比 在實際體驗後，我對這兩種模式做了簡單的比較： ...

當靈感遇上 AI：一個上午的加速實踐 這篇文章不是遊記，而是關於這個網站與這個計畫是如何誕生的紀錄。 過去，當我們萌生一個「想去探索台灣河流」的念頭時，往往會卡在繁瑣的規劃、資料蒐集，甚至是架設網站的技術門檻上。但這次，我嘗試了一種全新的工作模式——與 Agentic AI (Antigravity) 協作規劃。 以下是我們在短短時間內，從「一個想法」到「網站上線」的歷程筆記。 第一階段：從模糊到具象 (The Brainstorming) 1. 結構化龐雜資訊 一開始，我只有「想探索河流」這個模糊的概念。我請 AI 扮演研究分析師，快速梳理了台灣北部、中部、南部、東部的主要河川。 關鍵產出：AI 幫我列出了一份包含 11 條主要河川的清單，並針對每一條河列出了「景觀」、「生態」與「人文」的探索重點。這份清單成為了後續所有行程的骨架。 2. 定義探索方法論 我們不只是去玩，而是希望帶入**「流域治理」與「開放資料」**的視角。AI 協助我將這些硬核的知識轉化為一篇名為〈數位河流學〉的方法論文章，確立了這個部落格「知性與感性兼具」的基調。 第二階段：技術苦工的自動化 (The Infrastructure) 有了內容，需要載體。我選擇了 Hugo 這個靜態網站產生器，但技術細節往往是最磨人的。 GenAI 解決了什麼？ 環境建置：從 hugo.yml 的基礎設定，到 PaperMod 主題的調整。 功能客製化： Google Maps 嵌入：解決了 Hugo 預設擋掉 iframe 的安全性設定。 自動目錄 (TOC)：協助開啟全站的文章導覽，解決了不同頁面顯示不一致的問題。 系列分類 (Series Taxonomy)：建立特殊的「Series」頁面，讓針對同一條河流（如大甲溪）的不同文章能自動聚合，並擁有專屬的介紹首頁。 除錯 (Debugging)：最經典的是 “Future Date” 問題。當我看不到新文章時，AI 迅速指出是因为我的文章日期設在「明天」，並教我設定 buildFuture: true 來解決。 第三階段：內容深度的擴充 (The Content) 在撰寫《大甲溪車宿攻略》與《后里環保公園指南》時，AI 扮演了編輯與資料庫的角色。 它記住了我要去「后里」，並能提醒我那邊是合法的車泊點，甚至補充了「洗澡要去附近游泳池」這種在地細節。 當我需要針對「歷史文化」做補充時，它能迅速生成一段關於大甲溪流域開發史的背景介紹，讓我能專注於個人體驗的書寫，而非重複查閱維基百科。 第四階段：連結真實社群 (The Connection) 最後，為了讓這個計畫落地，我們建立了一個 “Planning” (旅程規劃) 頁面。 ...