【邊坡穩定分析工具】不必先猜滑動面在哪裡，SSA 邊坡穩定分析免費網頁版一鍵解決

工具介紹・邊坡穩定分析

不必先猜滑動面在哪裡
SSA 邊坡穩定分析免費網頁版一鍵解決

同一個邊坡，試遍三十一萬個可能的圓弧滑動面，找到的最小安全係數是 1.28。改用 SSA 的動態規劃法，不用事先假設滑動面的形狀，程式直接找出 Fs = 1.11 的滑動面。差距來自搜尋方法，這支免安裝的網頁工具就是為這件事做的。

邊坡分析最難的，常常不是算安全係數，而是知道該算哪一條滑動面。

01三十一萬個圓弧，還是差一截

先看一個簡單的例子。高 12 公尺的砂土邊坡，坡度約 1:1.7，砂土 c′ = 10 kPa、φ′ = 35°。坡趾下方 1 公尺處夾著一層 1 公尺厚的軟弱黏土，c′ 只有 2 kPa、φ′ 只有 12°，再往下是岩盤。

傳統的做法是假設滑動面是圓弧。我讓程式把圓心以 0.5 公尺為間距、半徑以 0.25 公尺為間距全部試過一遍，有效的圓弧共 315,989 個，最小安全係數是 1.28。

同一個剖面交給 SSA，用同樣的簡易 Janbu 公式計算，不到一秒就得到 1.11。它找到的滑動面在坡趾附近切進黏土夾層，貼著夾層底部平滑一段，再轉向坡頂。這個形狀不是圓弧，所以圓弧再怎麼密集地試也碰不到。

圓弧最多只能在夾層底部擦過一個點，動態規劃的滑動面則沿著夾層走了十幾公尺，軟弱層的影響因此完整反映在安全係數上。

1.28 和 1.11 差了一成多。如果設計要求是 1.2，前者看起來過關，後者則不過關。

・・・

02先猜再算的老問題

臨界滑動面分析，是在給定的地形、地層與土壤條件下，找出安全係數最小的那一條滑動面。多數程式的做法是先產生一批候選滑動面，逐一計算，再從中挑出最小值。

台灣實務上常用的 STABL（包括 STEDwin 介面）就是這個思路。它可以隨機產生圓弧、塊體或不規則折線，功能完整，也支援 Bishop、Spencer 等多種分析法。不過它找到的是「試過的裡面最小的」，結果會受試算數量和使用者設定的搜尋範圍影響。範圍設偏了，真正的臨界面就可能不在候選名單裡，所以常要換幾組設定反覆確認。

地層越複雜，這個問題越明顯。軟弱夾層、順向坡層面、風化岩與新鮮岩盤的界面，都會讓臨界滑動面偏離圓弧，而這些正是山區邊坡最常見的情況。

・・・

03把找滑動面變成找最短路徑

SSA 用的是動態規劃（dynamic programming，逐段求最佳解的數學方法）。沿水平方向畫出一條條垂直分割線，每條線上排列候選節點，滑動面就是從左到右、每條線各選一個節點連成的折線。

這很像在棋盤上找一條最省力的路。每走一段就累加這段滑動面的貢獻，每個節點只保留累積值最小的那條來路，走到最後一條線再回頭追溯，就得到整個網格裡的最佳路徑。搜尋範圍延伸到地表以上，地表以上的線段貢獻為零，所以滑動面從哪裡出露、從哪裡切入，都由計算自己決定。

安全係數是抵抗力總和除以滑動力總和，不能直接逐段相加。Baker（1980）證明可以改用 G = Σ(抵抗 − F × 滑動) 這個輔助函數，在滑動力為正的條件下，讓 G 最小就等同讓安全係數最小。程式先假設一個 F 做動態規劃，再沿找到的滑動面算出它自己的安全係數，當作下一輪的 F，通常幾輪就收斂。

💡 這個方法從哪裡來

計算核心參考日本建設省土木研究所地すべり研究室 1987 年的「動的計画法を用いた臨界すべり面解析法」（中村・久保田，土木研究所資料第 2425 號）。2013 年我依此寫成 C++ 程式 SSA，當時以有限元素法解 Richards 方程計算降雨入滲後的孔隙水壓，用來研究大規模崩塌的發生機制。

這次的網頁版把孔隙水壓改成由使用者畫的地下水位線直接換算，操作簡單許多，搜尋與安全係數的核心演算法則維持不變。

・・・

04搬進瀏覽器之後

網頁版的目標是讓任何人打開就能用，不必安裝、不必註冊，也不必準備輸入檔。

開啟時會先載入一個三層地盤加地下水位的範例並完成計算，使用者可以直接在圖上修改，再按一次計算。

• 畫出剖面就能算。地表線、各土層界面、地下水位線都可以在圖上拖曳節點，或從 Excel 貼上座標，也能直接匯入 CSV。
• 土層數目自己決定。按「新增土層」就能往下加一層，再畫出它的頂面界面線，崩積層、風化岩、軟弱夾層、岩盤都可以分開設定。不需要的土層也能直接刪除。
• 參數照習慣輸入。單位重可選 kN/m³ 或 tf/m³，凝聚力可選 kPa 或 tf/m²，切換時數值自動換算。某一層可設為岩盤，滑動面不會穿越。
• 地下水直接換算。孔隙水壓由水位線到滑動面的鉛直距離計算，水位以上用 γ、以下用 γsat 計重，另可選擇水位線傾斜修正。地震力以水平與垂直震度的擬靜態方式加入。
• 網格有建議值。頁面會依模型長度和土層厚度計算分割線間距與節點間距，太粗時提醒，並提供一鍵套用的建議值。
• 結果可以驗算。除了安全係數、滑動體面積與出入口座標，每一片切片的重量、水壓、抵抗力與滑動力都列成表格，可以複製到 Excel 自行核對。
• 模型可以存檔。整個模型存成一個 JSON 檔，下次匯入就能接著分析。所有計算都在自己的瀏覽器裡完成，資料不會上傳。

0.23 秒範例模型完成搜尋
（60 條分割線 × 80 個節點）

5 輪範例模型迭代收斂

自由增減土層數目依地層需要
自行增加

網頁下方另有完整的方法原理，列出簡易 Janbu 法、Baker 輔助泛函與動態規劃遞迴式的推導，式號與 1987 年的原報告一致，方便對照。

・・・

05使用前要先知道的限制

找得到臨界滑動面，不代表什麼都能算。下面這些限制，使用時請放在心上。

⚠️ 使用限制

• 只有簡易 Janbu 法。它忽略切片間的剪力，未修正的安全係數通常偏保守。頁面另外列出乘上修正係數 f0 的結果，但 f0 是經驗式，只能當參考。需要 Bishop、Spencer 等方法時，請以其他軟體複核。
• 二維極限平衡分析。不考慮三維效應，也不計算變形量。
• 不含補強與外加載重。地錨、土釘、地工格網、擋土結構、坡頂超載目前都無法輸入。
• 地下水只是一條水位線。採靜水壓，不處理滲流場、超額孔隙水壓與基質吸力。水位高於地表時的積水重量與側向水壓也沒有納入。
• 結果受網格影響。找到的是「網格精度內」的最小值，凹形限制在計算中也是近似處理。重要案例請加密網格，確認安全係數不再明顯變化。
• 設定會改變答案。最小滑動深度、是否限制凹形、是否允許穿越模型邊界，都會影響找到的滑動面。c′ = 0 的土層尤其容易收斂到很淺的表層滑動。
• 參數決定一切。強度參數與地下水位的不確定性，通常比計算方法的差異大得多。

這是一個分析輔助工具。計算結果僅供參考，正式的工程判斷與設計，仍應由專業技師依現地調查與相關規範負責。

📌 建議的用法

先用 SSA 找出臨界滑動面大概的位置、深度與規模，特別是地層複雜、懷疑有軟弱面的邊坡。再把這個結果拿去和 STABL 等商用軟體的搜尋結果比對，或作為設定搜尋範圍的依據。兩個方法找到的位置接近，結果就更可靠；差很多，就代表值得再看一次地層與參數。

・・・

06怎麼開始用

打開 cychen59.github.io/ssa-slope-stability 就能使用，手機也可以開，但編輯剖面建議用電腦。CSV 範例檔與範例模型都放在 GitHub 上，歡迎回報問題或提出改進建議。

📌 引用本程式

使用本工具的分析結果發表報告或論文時，請引用：

Chen, C. Y., Ikkanda, S., Fujita, M., and Tsutsumi, D. (2013): A study on mechanism of large-scale landslides and the prediction, Proceeding of 12th International Symposium on River Sedimentation, pp.109-118.

・・・

07這次改版，其實是 AI 完成的

從 C++ 到網頁版，這次改版其實全靠 Claude Opus 5.5 強大的能力。我做的只有兩件事，提供原始碼，再跟它描述這支程式的作用。

接下來，它先讀懂程式，整理出原本的演算法與幾個可以改進的地方，再依照我的需求，一步步變成網頁版。計算核心、剖面繪圖、土層編輯、CSV 匯入、單位切換、方法原理頁，都是在一次次對話中完成的。它也用無限邊坡的解析解和國際基準案例驗算過計算結果，確認數字站得住。

以我過去的程式能力，沒有辦法想像能做成這種程度。不管是畫面、UI 還是 UX 的設計，都遠超過我自己的能力。

生在這個 AI 爆發的年代，做研究真是幸福啊！

從一份 1987 年的研究報告，到一個網址

從近40年前日本土木研究所的研究報告，到 2013 年用來研究大規模崩塌的 C 語言 版本，再到現在打開瀏覽器就能用的免費工具。三十多年來，這個方法最有特色的，是它不要求使用者先猜滑動面的形狀。

邊坡穩定分析最難的，常常不是算安全係數，而是知道該算哪一個滑動面。

#邊坡穩定 #大地工程 #動態規劃 #Janbu #ClaudeAI

說明：第 01 節的比較案例為本文自行設定的示意邊坡，兩種搜尋都採簡易 Janbu 法、未乘修正係數 f0。圓弧搜尋的圓心範圍為 x = 10～50 m、z = 5～60 m，間距 0.5 m；滑動面最低點由岩盤頂面至高程 11 m，間距 0.25 m。動態規劃採 80 條分割線、每線 100 個節點、最小滑動深度 1 m。
參考資料：中村浩之、久保田哲也（1987）動的計画法を用いた臨界すべり面解析法，土木研究所資料第 2425 号；Baker, R. (1980) Determination of the critical slip surface in slope stability computations, International Journal for Numerical and Analytical Methods in Geomechanics, 4, 333-359；Purdue University STABL 與 STEDwin 產品說明。

【個資與隱私】同一扇門，鑰匙在誰手上，決定了它是防盜門還是牢房。

觀點・個資與隱私

防盜門與牢房

一支手機搞定食衣住行，確實方便。但方便的另一面，是鑰匙交到了誰手上。

同一扇門，鑰匙在誰手上，決定了它是防盜門還是牢房。

01沒做壞事，就不用怕？

身邊去過高度數位化社會旅行的人，回來常說同一件事。搭車、吃飯、住宿都靠一支手機，一個禮拜沒打開錢包，方便得讓人羨慕。聊到隱私，很多人會聳聳肩說，自己又沒做壞事，被看光也沒差。

這句話我聽過很多次，每次都覺得少了一個前提。有沒有做壞事，要看由誰來判斷。在權力受到制衡的地方，判斷的是法律和法院。在權力沒有制衡的地方，判斷的人不是你。

我常拿電子門鎖來想這件事。裝一扇堅固的防盜門擋小偷，大家都覺得合理，也住得安心。但如果門的鑰匙不在你手上，管理的人隨時能從外面把門反鎖，讓你出不去也回不了家，那它就不再是防盜門了。同一扇門，鑰匙在誰手上，決定了它是防盜門還是牢房。

・・・

02退路與單點故障

住在台灣，我們很少意識到自己有多少退路。信用卡被盜刷還有現金，某個帳號被停用，生活照樣過。對公家機關的處分不服，可以訴願，可以打行政訴訟。一個地方出問題，其他地方還撐得住。

全面綁定單一身分的系統剛好相反。交通、消費、住宿、通訊都掛在同一個身分和同一套資料庫底下，工程上叫單點故障。這個點一旦被關掉，所有東西會一起停擺。

💡 什麼是單點故障

系統裡只要一個環節失效，整體就跟著停擺。工程設計上會刻意避免這種結構，重要系統都要有備援。

2022 年河南幾家村鎮銀行爆發提款危機，有儲戶準備到鄭州陳情，健康碼突然轉紅，人在車站就被攔下。他們沒有犯法，只是想領回自己的存款。後來官方調查也證實，是地方官員擅自替這些人賦碼。一套為了防疫而設計的系統，轉個手就能拿來限制一個人的行動。

・・・

03一筆每天都在兌現的交易

公平地說，這樣的事對多數人來說很遙遠。不少生活在那裡的人是真心滿意的。深夜走在路上不用擔心，手機掉了很快能找回來，辦事效率高得讓外地人驚訝。對他們來說，交出一些隱私換來安全和便利，是一筆划算的交易，而且每天都在兌現。

這種感受是真實的，不該被輕易看成是被洗腦。我自己如果生活在那裡，大概多數日子也會這樣想。

問題不在於這筆交易平常划不划算，而在於條件由誰來改。今天你是守法的市民，系統對你很友善。哪天你的存款被凍結、房子蓋到一半停工，或者只是說了一句不合時宜的話，你就從受保護的人變成被管理的對象。這個轉換不需要你同意，也不會事先通知。

河南那些儲戶，在健康碼變紅的前一天，
應該也覺得這套系統很方便。

・・・

04那我們交給 Google 的資料呢

講到這裡，一定有人會反問。我們每天把信件、照片、行事曆交給 Google、Apple 和微軟，手機裡的定位紀錄恐怕比政府掌握的還多，這樣不也是把鑰匙交給別人？

這個問題問得好，我自己也想過很久。資料交出去的量，兩邊或許差不多，差別在於拿到資料的一方能對你做什麼。

可以走

Gmail 用得不順，可以換別家信箱，照片可以匯出到別的雲端。換起來麻煩，但做得到。一個國家的身分系統，你沒辦法說不用就不用。

公司不能抓人

Google 可以停你的帳號，這很困擾，但它不能讓你搭不上車、住不進旅館，更不能把你帶走。能動用警察和法院的，只有國家。

公司也被管著

這些企業在台灣要受個資法規範，在歐洲要面對 GDPR。2023 年 Meta 因為違規傳輸歐洲用戶資料，被開罰 12 億歐元。企業出了事，有主管機關可以查，有法院可以告，有媒體會追。

⚠️ 這不代表交給科技公司就高枕無憂

帳號被系統誤判停權、申訴無門的案例在國外時有所聞，美國政府也能依法向企業調閱資料。所以才更需要法律持續把關，也值得每個人把重要資料多留一份備份。

說到底，我們願意把一部分隱私交給這些公司，不是因為它們比較可靠，而是因為它們頭上還有更大的規則，而我們手上還留著離開的選擇。

・・・

05回頭看看自己

講完對岸和科技公司，也得回頭看看自己。台灣的健保資料庫是全世界研究者羨慕的寶庫，幾乎每個人的就醫紀錄都在裡面，政府也曾把這些資料提供給學界和其他單位利用。

2012 年，幾位民眾和人權團體提出質疑，認為自己的病歷被拿去使用，事前沒人問過，事後也沒辦法說不。這場爭議一路打了十年，2022 年憲法法庭判決，政府提供健保資料給外部利用，卻缺乏讓當事人退出的機制，部分違憲，要求限期修法。

📌 煞車不會自己踩

這件事常被當成台灣民主的成績單，我覺得它更像一個提醒。煞車確實存在，但它不會自己踩。那十年裡，是幾個不肯放棄的人一路堅持，才把它踩了下去。

煞車還在的地方

我不反對數位化，也很享受它帶來的效率。只是系統越強大，越需要可靠的煞車。民主社會的數位治理之所以能被接受，靠的是法律限制資料用途，有獨立法院可以審查，還有媒體和公民在旁邊盯著，而不是期待政府特別善良。

把煞車拆掉的地方，坐在車上的人只能祈禱開車的人心情一直很好。煞車還在的地方，我們要做的是記得它在哪裡，必要時伸腳去踩。

鑰匙交出去之前，多問一句它會被怎麼用，門才會一直是防盜門，不會在某一天悄悄變成牢房。

#個資與隱私 #數位治理 #數位人權 #觀點

參考資料
河南村鎮銀行紅碼事件：中央社〈河南村鎮銀行儲戶健康碼變紅〉https://www.cna.com.tw/news/acn/202206140055.aspx；天下雜誌轉載 BBC 中文報導（含鄭州市紀委監委通報）https://www.cw.com.tw/article/5121929
Meta 遭歐盟罰款：公視新聞 https://news.pts.org.tw/article/638051；iThome https://www.ithome.com.tw/news/157007
健保資料庫案：憲法法庭 111 年憲判字第 13 號判決全文 https://laws.gov.taipei/law/Judge/ConstitutionalJudgeContent/CJ00000872；理律法律事務所判決整理 https://www.leeandli.com/TW/Newsletters/6947.htm
本文為作者個人觀點。

【AI工作流】不再讓 AI 對話停在聊天室：我用 Obsidian 建立半自動知識歸檔 SOP

AI 工作流・Obsidian 知識管理

不再讓 AI 對話停在聊天室：我用 Obsidian 建立半自動知識歸檔 SOP

受到 AI Monday 分享啟發，我保留熟悉的 ChatGPT 使用方式，把自動化集中在對話完成後的知識歸檔

我沒有為了全自動化而改變主要工作介面，而是讓 ChatGPT 繼續負責討論、Obsidian 負責長期保存，再以一套半自動 SOP 串起兩者。

📁 Obsidian🤖 ChatGPT⚙️ 半自動 SOP

我經常使用 ChatGPT 進行政策研議、技術問題分析、簡報檢討與工作構想。這些對話當下很有價值，但只留在聊天紀錄裡，過一段時間便很難再次找到；即使找到了，也必須重新閱讀整段討論，才能知道當時形成了什麼結論。

因此，我設計了一套不需要 API、也不必另外開發系統的半自動流程：先用 Obsidian Web Clipper 保存完整對話，再請 ChatGPT 透過「歸檔 Obsidian」技能，把對話中真正值得留下的內容拆成決策、洞見與參考資料三個 Markdown 檔案。

這套方法的重點不是把所有 AI 回答都收藏起來，而是同時保留兩種不同層次的資料：逐字稿保存思考過程，主題檔案保存可再利用的知識成果。

這個做法從哪裡來？

這個構想受到影片〈20260907 AI Monday｜公共治理與行政服務｜公民科技與開源協作〉中一段分享的啟發。影片介紹的做法，是以結構化資料夾搭配 AI 助理與治理規範，將資料分成三類：conversations/ 保存對話逐字原文、references/ 保存外部資料與來源、insights.md 保存蒸餾後的關鍵洞見。如此一來，AI 不只是回答當下的問題，也能透過既有檔案恢復脈絡，成為一個會記憶的思考夥伴。

我認同這個架構，但沒有完全照搬。原因很實際：我大多數時候仍習慣直接在 ChatGPT 網頁版或桌面版整理資料、來回討論。原生介面的操作最熟悉，檔案上傳、長篇討論及不同工具的整合也比較方便。如果為了全自動歸檔，反而要求自己改用另一套對話介面，使用阻力很可能大於歸檔帶來的效益。

因此，我把影片的核心概念留下來，但調整了實作方式：

• 對話仍在我最熟悉的 ChatGPT 網頁版或桌面版完成；
• 對話告一段落後，才用 Web Clipper 保存完整逐字稿；
• 再由「歸檔 Obsidian」技能蒸餾決策、洞見與參考資料；
• Obsidian 作為長期知識載體，但不取代 ChatGPT 的討論介面；
• 保留最後的人工下載、檢查與分類，不追求無人介入的全自動化。

我的改造原則：工具應該配合既有工作習慣，而不是為了追求自動化，反過來增加每天使用的阻力。

1

逐字稿保留完整討論脈絡與推演過程。

2

決策記錄最後採取的方案與理由。

3

洞見留下可跨情境重複使用的判斷。

4

來源保留查證、引用與追溯依據。

半自動歸檔流程：原始對話先完整保存，再把決策、洞見與參考資料整理成可累積的知識。

先建立 Obsidian 的目錄架構

我先在 Obsidian Vault 中建立以下目錄：

AI對話知識庫/
├─ Clippings/
│  └─ Web Clipper 保存的 AI 對話逐字稿
├─ 20-Topics/
│  ├─ 主題 A/
│  │  ├─ decision.md
│  │  ├─ insight.md
│  │  └─ reference.md
│  └─ 主題 B/
│     ├─ decision.md
│     ├─ insight.md
│     └─ reference.md
└─ 90-Templates/
   └─ AI 對話逐字稿範本

原則上，一個持續發展的討論主題建立一個資料夾。例如「大規模崩塌監測資源配置方式探討」、「警戒模式及發布機制」或「災害潛勢調查與防災地圖」，各自形成獨立的知識單元。

同一主題日後若有新的對話，並不是重新建立另一套三個同名檔案，而是把新的決策、洞見與來源追加進原有檔案，並標示日期及對應的逐字稿。這樣才能逐步形成主題脈絡，而不是製造大量零散筆記。

逐字稿保留過程，三個核心檔案保存成果；所有結論都應能回到原始對話查證。

核心原則：Clippings 保存「當時怎麼討論」；Topics 保存「討論後留下什麼」。兩者不能互相取代。

STEP 1｜完成對話，確認已經定稿

不是每一輪問答都需要歸檔。我會在一個議題已經充分討論、文字完成定稿，或形成最終決策後，才啟動歸檔流程。

如果討論仍在變動，此時產生的 decision.md 很可能只是暫時意見，反而會污染知識庫。因此，啟動條件應該是下列其中之一：

• 已完成文件或簡報的最終版本。
• 已在不同方案之間作出選擇。
• 已形成值得日後沿用的判斷原則。
• 已完成一個技術問題或政策議題的階段性分析。

STEP 2｜用 Web Clipper 保存完整逐字稿

在 ChatGPT 對話頁面按下 Obsidian Web Clipper，套用預先建立的「AI 對話逐字稿」範本，將整個討論頁面存進 Obsidian 的 Clippings 目錄。

Web Clipper 範本至少應包含：

• 對話標題；
• 儲存日期；
• ChatGPT 對話網址；
• 平台名稱；
• 完整頁面內容；
• 狀態與主題標籤。

檔名可以採用：

YYYYMMDD－討論主題－ChatGPT.md

例如：

20260909－大規模崩塌監測資源配置方式探討－ChatGPT.md

擷取前要檢查：長對話可能採動態載入。使用 Web Clipper 前，應先確認頁面開頭、中段與結尾均已載入；存入 Obsidian 後，也要抽查逐字稿是否完整。

STEP 3｜在原對話呼叫「歸檔 Obsidian」技能

完成逐字稿保存後，我在同一個 ChatGPT 對話最後輸入：

歸檔 Obsidian

這個技能會讀取本次對話，將內容蒸餾成三種不同用途的檔案：

1. decision.md｜形成的決策

保存本次正式形成的選擇，包括：

• 決策內容；
• 決策理由；
• 放棄的替代方案；
• 主要風險；
• 需要重新檢討的條件。

如果對話只是分析而未形成決策，技能應明確註明「本次未形成正式決策」，不能把建議誤寫成已定案事項。

2. insight.md｜重要的洞見

洞見不是對話摘要，而是經過討論後，可在其他工作中重複使用的判斷。例如揭示一個因果關係、指出原有假設的漏洞，或形成新的政策與技術判斷原則。

每一項洞見最好同時記錄：

• 洞見內容；
• 為什麼重要；
• 適用範圍；
• 限制或反例；
• 對應的原始逐字稿。

3. reference.md｜使用的參考資料

整理對話中實際使用過的論文、報告、網站、公文或其他來源，至少保留：

• 資料名稱；
• 作者或發布機關；
• 網址或檔案名稱；
• 發布日期與取用日期；
• 本次討論如何使用這項資料。

沒有在對話中實際出現的來源，不應由 AI 自行補造。無法確認的書目，也應標示「待查證」。

STEP 4｜下載三個 Markdown 檔案

技能完成後，ChatGPT 會提供三個可下載的 Markdown 檔：

decision.md
insight.md
reference.md

下載後，先快速檢查四件事：

1. 決策是否真的是最後定案，而不是討論過程中的暫時方案。
2. 洞見是否有資訊增量，而不是一般性摘要。
3. 參考資料是否真的出現在本次對話。
4. 是否有機敏資訊、個人資料或不應進入個人知識庫的內容。

AI 可以協助整理，但不能取代最後一次人工確認。尤其是政策決策與參考來源，錯一次，後續就可能沿用錯誤。

STEP 5｜放入相對應的 Topic 資料夾

最後，將下載的三個檔案手動拉到 20-Topics 下相對應的主題資料夾。如果該主題已經存在同名檔案，就把新內容依日期追加到原檔，而不是直接覆寫。

每一筆內容都應反向連結到 Clippings 中的原始逐字稿，例如：

## 2026-09-09｜保留三級架構，採可逆的動態管理

### 決策內容
維持現有三級架構，允許依新資料升級、降級或調整監測配置。

### 原始對話
[[20260909－大規模崩塌監測資源配置方式探討－ChatGPT]]

如此一來，看到結論時可以立刻回查當時的完整討論，不必只相信被蒸餾後的一小段文字。

這套流程不需要 API

這個版本不需要 OpenAI API，也不必撰寫自動化程式。ChatGPT 負責理解與蒸餾，Obsidian Web Clipper 負責保存完整頁面，使用者只需下載三個 Markdown 檔案並放入正確位置。

它並不是百分之百自動化，但這個保留人工確認的環節反而很重要。因為「是否已經形成決策」、「哪一項內容值得成為長期洞見」、「參考來源是否可靠」，都不適合完全交給程式自行判斷。

最容易犯的四個錯誤

⚠️

還沒定稿就歸檔

暫時方案可能被誤認為正式決策。

⚠️

用摘要取代逐字稿

失去原始脈絡後，結論難以查證。

⚠️

每次都覆寫同名檔

舊決策與觀點會被新內容消除。

⚠️

什麼對話都保存

知識庫最後只會變成另一個聊天垃圾場。

從聊天紀錄，走向可累積的個人知識庫

這套方法真正解決的，不是「怎麼把 ChatGPT 網頁存下來」，而是如何把一次性的對話轉換成可以持續累積、查證與再利用的知識。

完整逐字稿保留推理與討論脈絡；decision.md 記錄最後做了什麼選擇；insight.md 保存未來仍可使用的判斷；reference.md 則讓結論具有可追溯的依據。四者結合後，AI 對話才不再只是聊天紀錄，而會逐漸形成自己的第二大腦。

最後留下四個原則

逐字稿完整保留，不由 AI 改寫。

重要議題定稿後才啟動歸檔。

一個主題建立一個知識資料夾。

決策、洞見與來源分開管理。

所有蒸餾成果都連回原始對話。

最後仍由人確認，不把判斷外包給 AI。

附錄一｜Obsidian Web Clipper「AI 對話逐字稿」範本

以下內容可放入 Web Clipper 範本的 Note content。官方變數 {{title}}、{{url}}、{{domain}}、{{date}} 與 {{content}} 會在擷取時自動替換；其中 {{content}} 會優先使用目前選取的內容，沒有選取時才嘗試擷取頁面主要內容。

---
type: ai-conversation
title: "{{title}}"
platform: "{{domain}}"
source_url: "{{url}}"
captured: "{{date}}"
status: archived
topic:
tags:
  - AI對話
  - 逐字稿
---

# {{title}}

## 基本資料

- 平台：{{domain}}
- 擷取日期：{{date}}
- 原始網址：{{url}}
- 對應主題：待填寫

## 對話逐字稿

{{content}}

## 對應知識檔案

- Decision：待建立
- Insight：待建立
- Reference：待建立

## 備註

- 本檔保留原始對話，不以摘要取代。
- 如網頁內容採動態載入，歸檔後須抽查開頭、中段與結尾。

建議的 Web Clipper 設定如下：

• Template name：AI 對話逐字稿
• Template trigger：https://chatgpt.com/
• Behavior：Create a new note
• Note name：{{title}}
• Note location：Clippings

若對話頁面無法被 {{content}} 完整辨識，可以先選取對話內容，再執行 Web Clipper；或者將正文變數改成 {{selection}}。不要直接改用 AI Interpreter 摘要，因為這一階段的目的就是保留原文。

附錄二｜「歸檔 Obsidian」提示詞範本

若尚未建立專用技能，也可以在重要對話完成後，直接貼上以下提示詞。建立技能後，則可把這份內容放入技能指令，平常只需輸入「歸檔 Obsidian」。

請將本次完整對話整理成可存入 Obsidian 的知識歸檔檔案。

工作原則：
1. 只依據目前對話中實際出現的內容，不補造事實、來源或結論。
2. 區分「討論過的選項」、「建議」與「最後形成的決策」。
3. 洞見不是一般摘要，只保留可跨情境重複使用、能改變判斷，
   或揭示重要因果、限制、風險與假設的內容。
4. 參考資料只收錄本次對話實際使用的論文、報告、網站、影片、
   公文或檔案；資料不完整時標示「待查證」，不得自行補齊。
5. 不重製完整逐字稿；逐字稿已另外由 Web Clipper 保存。
6. 使用繁體中文，內容具體、可追溯，避免空泛結論。

請產生以下三個獨立的 Markdown 檔案，並提供下載：

一、decision.md｜形成的決策
- 本次決策狀態：已定案／階段性決定／尚未形成決策
- 決策內容
- 決策理由
- 討論過但未採用的選項及原因
- 主要風險與限制
- 決策成立所依賴的假設
- 需要重新檢討的條件或時間
- 後續行動

如果本次沒有形成決策，請明確寫「本次未形成正式決策」，
不要把 AI 建議寫成使用者已經決定的事項。

二、insight.md｜重要的洞見
每項洞見須包含：
- 洞見標題
- 洞見內容
- 為什麼重要
- 適用範圍
- 限制、反例或不確定性
- 對後續工作的可能影響
- 形成日期

刪除一般性摘要、重複觀點、過程性文字與沒有資訊增量的內容。

三、reference.md｜使用的參考資料
每筆資料須包含：
- 標題
- 作者或發布機關
- 資料類型
- 發布日期；未知則註明未知
- 網址或原始檔名
- 本次對話中的使用目的
- 可支持的主張
- 查證狀態：已確認／待查證

如果本次沒有使用外部參考資料，請明確寫「本次未使用外部參考資料」。

三個檔案的共同要求：
- 檔案開頭加入本次對話主題與日期。
- 在「原始對話」欄位預留 Obsidian 雙向連結：
  [[請填入 Web Clipper 逐字稿檔名]]
- 若目前環境無法建立可下載檔案，請改用三個分開的 Markdown
  程式碼區塊輸出，讓我能分別另存為上述檔名。
- 完成後簡短列出你判定的主題資料夾名稱，但不要自行改動我的 Obsidian。

相關工具

• Obsidian Web Clipper 官方說明
• Obsidian Web Clipper 變數說明
• 構想來源：20260907 AI Monday｜公共治理與行政服務｜公民科技與開源協作

【防災思維】九天，還是幾分鐘？瑞士 Blatten 與尼泊爾冰岩崩塌的兩種結局

複合型土砂災害・防災思維

九天，還是幾分鐘
瑞士 Blatten 與尼泊爾冰岩崩塌的兩種結局

2026年的尼泊爾，2025年的瑞士，兩場幾乎同類的冰川崩塌，結局天差地遠。差別不在有沒有前兆，而在監測與應變，能不能爭取到那段反應時間。

面對這類災害，我們真正能爭取的，不是阻止它發生，而是縮短「災害發生」到「我們知道」之間的時間。

01一場比預警更快的災害

2026年8月26日上午，尼泊爾與西藏交界的高山河谷，發生一場大規模災害。從陸續取得的衛星影像與初步分析來看，它不是一般豪雨造成的河川暴漲。更可能的過程，是高海拔冰川的一段在約5,200公尺高處崩落，墜落約1,200公尺撞上谷底，一路裹挾岩塊與泥砂，形成冰岩崩塌，衝入倫德河（Lhende Khola），短暫堵塞河道並蓄水，接著潰決，再以高含砂洪流奔向下游。下游水位一度在30分鐘內暴漲約9公尺。

這場災害造成重大傷亡。罹難與失蹤人數在事件後持續增加，各方統計仍在更新，其中包含大量外籍旅客。

約5,200 m冰川崩落起始海拔

約1,200 m崩落墜落落差

約9 m下游水位30分鐘內漲幅

M5.2崩塌導致的地震訊號規模

真正值得防災領域深思的，不只是「這到底是不是土石流」「是不是冰河湖潰決」，而是這場事件凸顯了天然災害具有的三個致命特性。一是高度不確定，二是高度不可控制，三是反應時間極短。

這張圖把尼泊爾事件拆成五個接連發生的階段。真正的難處不在任何單一階段，而在階段之間切換的速度，快到人為幾乎沒有介入的空檔。

・・・

02知道哪裡有風險，不等於知道何時開始

山區防災可以靠地形、地質、歷史災害、降雨與監測資料，辨識出風險較高的區域。臺灣在這方面並非從零開始，已建立土石流潛勢溪流、大規模崩塌潛勢區、影響範圍與保全住戶等制度。大規模崩塌的影響範圍評估，本來就會依可能的致災型態，區分為重力堆積型、土石流型或堰塞湖型。對於「哪裡可能出問題」，我們累積了不少知識。

困難的是另一件事。知道哪裡有風險，不等於知道災害會在什麼時間、以什麼方式開始。尼泊爾這次的第一個關鍵瞬間，很可能就發生在高海拔、偏遠、幾乎沒有地面監測的上游。事件初期，外界一度懷疑與地震有關；美國地質調查所後來研判，那個「地震訊號」其實是崩塌本身產生的，規模相當於一場5.2的地震。連最初的訊號都被讀錯，正好說明觸發機制往往要在災害發生之後，才能逐步釐清。防災不能建立在「一定能事先預測」的假設上。

・・・

03災害鏈一旦啟動，能控制的空間很有限

一般熟悉的山區災害，多半是降雨增加、邊坡逐漸不穩，然後崩塌或土石流發生。這種情境至少還有時間順序，也可能從雨量、坡體變形、水位等訊號累積判斷。

尼泊爾這類事件不同。冰岩崩塌、大量土砂與冰雪進入河谷、河道堵塞、暫時蓄水、潰決、高含砂洪流，可能在極短時間內連續發生。當大量水、土砂、巨石與冰塊灌進陡峻狹窄的高山河谷，所釋放的能量，已經超出工程設施在災害當下能控制的尺度。

📌 重點

到了這個階段，防災真正的問題，已經從「能不能把洪流擋下來」，變成「能不能在它抵達下游以前，就知道事情已經開始」。這是兩種完全不同的防災思維。

・・・

04真正能爭取的，是時間

面對這類災害，我們未必能精準預測崩塌何時發生，也未必能在災害鏈啟動後阻止它發展。但有一件事仍然可以努力，就是縮短「災害已經發生」到「我們知道災害發生」之間的時間。

對快速演變的複合型災害來說，可供應變的時間，可能不是幾個小時，而只是幾分鐘。所以防災的目標，不該只放在預測災害何時發生，而要同時建立一條完整的反應鏈，從異常偵測、快速確認、災害鏈研判、下游警戒，一路接到疏散行動。

・・・

05有監測，不一定就能預警

把尼泊爾這次事件，和2025年5月瑞士的Blatten災害放在一起看，問題會更清楚。

兩起事件的災害型態幾乎是同一類。Blatten是岩崩加上冰川崩塌、堵塞河道，尼泊爾是冰岩崩塌、河道堵塞、潰決再到高含砂洪流。真正的差別在結局。Blatten在崩塌前約九天就完成撤離，約三百位居民與牲畜陸續撤出，最後只有一位本已撤離，後來又返回尋找牲畜的牧羊人罹難。尼泊爾這次，初步統計死亡與失蹤已知超過千人。

事實上，這兩地其實都有進行長期的研究與監測，差別在監測的目的與強度。瑞士阿爾卑斯山區對特定危險坡體，設有以防災為目的、持續而高頻的現地監測與專業團隊，能追蹤落石、冰川與坡體變形的異常，並直接支援撤離決策。喜馬拉雅山區雖然長期有國際與區域研究，卻多以廣域科研與冰河湖普查為主，主要依賴中低解析度衛星追蹤冰川退縮趨勢與高危冰湖清冊。這次的崩塌源頭在海拔5,200公尺以上的懸冰川，既不在列管的高風險冰湖名單，現場也沒有連續性的地表變形監測。

再加上兩個結構性限制。一是跨境高海拔的盲區，源頭位於西藏側的高寒無人區，缺乏雙邊即時連線的邊界冰川預警，下游的尼泊爾端無從及時掌握上游異常。二是下游最後一道防線被瞬間沖毀，原本設在下游的自動水位站，在崩塌誘發的高含砂洪流衝擊下第一時間就損毀，訊號來不及傳到更下游的聚落。

監測不是「有」或「沒有」的是非題。同樣叫監測，為科研普查而設，和為防災預警而設，密度與時效完全不同。前者能累積長期趨勢，卻未必能在崩塌前幾天、甚至幾分鐘給出實時警報。決定能不能預警的，往往是監測的目的與強度。

不過也要承認，有些地方受地形與環境所限，就算有資源也很難布設監測。像去年臺灣的馬太鞍溪堰塞湖，位置太偏遠，重機械上不去，要在現地架設連續監測都極為困難。這不是願不願意做，而是條件上做不到。面對這種先天就難以監測的環境，真正該問的不是如何把監測鋪得更滿，而是當異常一旦發生，能不能快速偵測、快速研判，並在極短時間內對下游做出正確的決策與反應。

同樣的災害型態，一邊爭取到九天，一邊只剩幾分鐘。把這張表攤開，兩地拉開差距的落點，幾乎都集中在監測那一列。

・・・

06臺灣的下一步，是把既有能力串起來

臺灣已有土石流潛勢溪流、大規模崩塌潛勢區、保全住戶、風險分級與影響範圍等制度。土石流潛勢溪流的劃設本來就以防災管理為目的，並透過現地勘查、風險評估、審查、公開與應變機制持續更新；大規模崩塌調查也已包含危害度、脆弱度與保全對象評估。要精進的，不是再創造一個新災種，而是把原本分散的資料與技術，串成一條完整的災害管理鏈。

這六塊制度目前多半各自維護、分屬不同流程。

第一步，先知道「哪裡新崩了」

重大颱風、豪雨或地震過後，最基本的問題是這次新增了多少崩塌、位置在哪、規模多大，亦即新生崩塌判釋，實為後續災害鏈管理的起點。目前新生崩塌判釋考量實務操作的可行性，會分成三個階段：災後7天先做緊急判釋，快速掌握主要新生崩塌；災後1個月補充較完整的影像成果；災後半年完成較完整的崩塌目錄。重點不是第一時間就百分之百精確，而是先求快，再逐步補上完整與精度。

第二步，災害結束不代表風險消失

崩塌留在坡面與河道的大量土砂，不會因為雨停就自動穩定。這些「不安定土砂」，指的是坡面或河道上處於暫態平衡或不穩定狀態的土砂，在降雨、地震等條件下可能再次運移，波及中下游。它可能來自新生崩塌、崩塌後的殘坡、河道累積的鬆散土砂，或過去尚未穩定的堆積體。換句話說，第一次災害的結果，可能就是下一次災害的來源。

殘坡管理因此正朝年度更新、事件後更新、版本管理與分類追蹤發展，要回答的不只是崩塌畫在哪，而是哪些殘坡仍不穩定、量體有多少、哪些可能再進入河道、下游會受到什麼影響。這比單純問「這裡是不是土石流潛勢溪流」，又往前了一步。

第三步，防災資源不能平均分配

全臺有大量崩塌、殘坡與不安定土砂，不可能每一處都投入相同的監測與治理，因此需要風險排序。唯一聯外道路、重要鐵公路、橋梁、下游聚落與重要公共設施，若同時受到大量不安定土砂威脅，就應優先調查、模擬、監測與整備。這是從「災害調查」真正走向「風險治理」的關鍵一步。

每一階段的調查成果，就是下一輪風險評估的起點。從判釋新生崩塌、追蹤殘坡，到排定治理優先順序，正好對應這一節的三步。

・・・

07沒有單一監測技術能解決所有問題

面對高度不確定的山區災害，常見的迷思是只要裝更多儀器就能預測災害。事情沒有那麼單純。不同監測技術，看到的是不同尺度、不同時間特性的訊號，比較合理的方向不是依賴單一設備，而是建立多源監測。

微地動訊號可用來快速辨識可能已發生的大型崩塌，SAR雷達衛星可做廣域地表變異偵測、降低雲層遮蔽的影響，InSAR適合觀察較長時間的地表變形，光學衛星用來確認崩塌與地貌變化，UAV與光達提供高解析度地形判釋，PIV等影像分析可追蹤局部位移，投入式水位計則能持續掌握河道堵塞與異常水位。

左右兩側是不同尺度的監測工具，中間的偵測、確認、研判、通報才是重點。設備是輸入，鏈才是產出。

・・・

08從「雨量型預警」到「事件型偵測」

臺灣以雨量為基礎的土石流警戒仍然非常重要。對多數颱風、豪雨型的土石流與大規模崩塌來說，降雨預測、雨量累積、警戒發布、疏散整備，仍是最成熟有效的方式。尼泊爾事件提醒我們的是，有些災害不是從雨量開始，而是從地震、大型崩塌、微地動異常、河道突然阻塞，或堰塞湖快速形成開始。

⚠️ 把系統的邊界講清楚

既有的雨量型預警，涵蓋不了不是從雨量開始的災害。這不是預警失效，而是它的設計前提本來就不含這種觸發方式。

因此可以逐步研議雙軌並行。第一軌是既有的雨量型預警，處理常態的颱風豪雨型災害。第二軌是事件型偵測，當偵測到大型崩塌、河道阻塞或堰塞湖等異常，立即進入快速查證與下游影響研判，流程大致是異常偵測、快速查證、災害鏈研判、下游影響評估、警戒與疏散。第二軌不是要取代雨量警戒，而是補上一件事，當災害不照傳統氣象方式發生時，政府仍有一套可以啟動的機制。

兩軌不是取代關係。左軌處理因雨量而來的災害，右軌處理非因雨量誘發的災害；下方流程是右軌被觸發後才啟動的部分。

第一波災害結束，防災工作也還沒結束。大型崩塌與洪流過後，上游可能仍有未穩定的殘坡、河道阻塞、新生堰塞湖，加上持續降雨，隨時可能二次崩塌或再次潰決。現行土砂災害調查程序，本來就要求現地研判災害原因、二次災害可能性與後續處置。未來更該把災後調查，定位成下一階段風險管理的即時情報，而不是事件過後就結案。

・・・

09演練的想定，要對得上真實的災害

預警與應變的最後一哩，是平時的演練。就在這次災害發生前約三週，西藏吉隆口岸一帶才辦過一場冰湖潰決疏散演練。等到災害真的來了，那段演練影片在網路上被大量轉傳，也引來不少討論（影片連結）。

走位式的演練並不是沒有價值。它能讓人員熟悉自己的任務、通報流程與協調分工，這是基礎訓練該有的功能。真正的問題不在演練辦得認不認真，而在它的情境想定有沒有對上真實的物理與時間尺度。如果想定預設了偏溫和的條件，充裕的廣播、整隊與依序撤離時間，加上設施完好、道路暢通、通訊正常，那麼流程即使跑得很順，也很難碰到極端災害下真正的關卡。

遺憾的是，這次事件發生的情境是如此嚴苛。反應時間以分鐘計、甚至沒有預警，避難點可能直接被沖毀，橋梁道路瞬間消失，電力與通訊全斷。要讓演練貼近這種情況，可以檢視三件事。情境想像有沒有納入極端預警、複合災因與上游突發的二次災害。情境設定有沒有把道路中斷、通訊失效、避難點失效、現場資訊不足這些真實限制放進去。運作方式是不是在接近真實的場域，用真實的決策、通報、派遣與協調來進行。

這不代表要否定走位式演練，比較合理的方向是分層。基礎的走位保留下來，作為熟悉任務與編組分工的訓練。再往上一層，讓高階指揮與決策者在應變室裡，面對「監測站斷訊」「預定避難點被淹沒」「聯外橋梁斷裂」這類注入式狀況的壓力測試。最後把演練帶到接近真實的工作場域，用貼近實況的情境操作通報、調度、避難與決策。

這樣一來，未來演練的檢討，就不只是看流程順不順、口條好不好，而是再往前一步。真正可能的資訊斷點會出現在哪裡，手上的裝備與設備夠不夠用，指揮體系與幕僚的能力，是不是足以在資訊不足的當下，撐起一個站得住的決策。

更重要的，也許是檢討的氛圍。它的目的不是責罵，也不是究責，而是大家一起把問題找出來、看清楚，再一步步改好。願意承認自己還有不足，才有辦法一次比一次更周全。

走位、兵推、情境導向實作不是三選一，而是三層。差別不在辦在哪裡，而在情境想定敢不敢貼近最壞的狀況。

能控制的，也許不是災害，而是反應的時間

面對這類複雜的山區災害，我們得承認一件事。科技不可能讓所有災害都變得可以預測，也不可能讓所有災害都變得可以控制。這不是防災失敗。成熟的災害管理，本來就是在不確定的條件下做決策。

臺灣下一階段要推的，不一定是一套全新的制度，而是先把既有能力串起來。整合土石流、大規模崩塌、堰塞湖與不安定土砂資料，讓微地動、SAR／InSAR、UAV光達、水位監測與BigGIS等多源監測常態化，強化跨機關資料介接與事件型快速通報，再分階段驗證、滾動檢討。這套機制不可能靠紙上設計一次到位，比較務實的作法，是用真實事件驗證成效，逐步修正監測、通報與協作模式。

我們真正能爭取的，從來不是阻止災害發生，而是縮短「災害發生」到「我們知道」之間的那段時間。

#複合型土砂災害 #冰岩崩塌 #堰塞湖 #坡地防災 #災害鏈 #早期預警

資料來源：尼泊爾國家災害風險減災管理局、路透社、半島電視台等媒體，及 Planet Labs 衛星影像之初步判釋（事件統計至2026年8月27日，罹難與失蹤人數仍在更新）。臺灣相關制度說明，綜整自土石流潛勢溪流、大規模崩塌與不安定土砂之現行作業規範。
註：事件之觸發機制與各項數值屬災後初步研判，後續可能隨調查修正。

【防災書架/讀後感】土石流碰撞的不只是山區聚落，還有一座座社會價值觀與慣性

防災書架 ・ 讀後感

土石流碰撞的不只是山區聚落
還有一座座社會價值觀與慣性

一本 2002 年出版的調查報導，寫的是賀伯與桃芝那幾場改變台灣的風災。從事坡地防災多年的我，每隔幾年就會重讀一次。儘管這二十多年來，我們已走了很長的路，但它想提醒的那件事，到今天依然值得一讀再讀。

《戰慄土石流》的序言裡，有四個字：「寸土寸心」。你對這塊土地用了幾分心，決定了雨季來時它會不會反過來吞掉你。

《戰慄土石流──災難、政治與風險管理》，林照真著。書名四個字被土石壓成傾斜的樣子，本身就是全書的隱喻。（圖片來源：時報出版）

01一本 2002 年的書，成了我防災路上的啟蒙者

2002，這本書出版的那年，我剛踏進防災工作不久。當時的我，對於土石流幾乎是一張白紙，它成了我進入這個領域的啟蒙書。後來我自己規劃、設計的許多防災策略方向與做法，追根究底，都能在這本書裡找到最初的那顆種子。

二十多年來，我每隔幾年就會把它拿出來重讀一次，對照過去與現在：這二十多年，我們到底改變了什麼，又有哪些是怎麼也改不動的。每一次讀，答案都不太一樣。

第一次翻開它時，我以為會讀到一份災情整理。那時我還是個防災新手，神木村愛玉子溪滾下的巨石、大興村一夕變成「墳場」的空拍，對我來說都還只是新聞裡的畫面。但作者林照真是跑社會運動與調查報導出身的資深記者，她沒有停在「死了多少人、埋了多少戶」，而是把鏟子往下再挖一層。她拋出一個讓我坐直身子的命題：如果土石流不只是天災，而是一面鏡子——照出政治的要脅、公權力的軟弱，還有社會力的不振呢？

這句話對一個技術人來說是刺耳的。我們習慣用雨量、地形、地質去解釋一場崩塌，卻很少願意承認：有些災難的真正變數，根本不在山上，而在會議室裡。

・・・

02翻轉：土石流原本是「大地的恩賜」

書裡有一段話，把我這種技術背景的人給重新校準了。它說，土石流其實是生成萬物的基礎。回推上百萬年，台灣西部那片養活我們所有人的肥沃平原，正是千千萬萬次土石崩落、一層一層堆疊出來的。

換句話說，崩塌是大地造物的本能，它沒有惡意，它只是照著自己的節奏在搬運這片土地。真正把「恩賜」變成「敵人」的，是人。當我們把馬路、房子、生計，硬塞進土石流的必經之路，衝突才由此開始。

「土石流是生成萬物的基礎。」

這個視角的價值，不是替災難卸責，而是把責任的位置擺正。災難的起點，往往在於我們忘了這片土地最初的生長邏輯，把一條它走了幾百萬年的路，當成可以隨手佔用的空地。

・・・

03最難的一題：生計與環境，怎麼取得平衡

書裡最讓我共鳴、也最不好談的，是山區土地利用的價值拉扯。一邊，是生活不易、倚賴土地維生的農民；另一邊，是屬於全體國民、需要休養生息的環境。兩邊都站得住，兩邊都有各自的道理。

在本書寫作的那個年代，林照真點出一個容易被忽略的現象——部分山坡地的「超限利用」：在不適合的坡度上耕作或興建，讓土地承受了超過它能負荷的壓力。這是 2002 年前後的觀察。

不過，這裡我需要為這段補上二十多年後的註腳－在中央、地方與許多在地農民的共同努力下，這樣的情況其實已經改善許多。而我自己這些年更深的體會是－山坡地並不是完全不能利用，關鍵在於有沒有做好完善的水土保持規劃與農地水土保持。做得到位，開發與保育是可以並存的。

這幾年在不少災害現場，我甚至看到一個很值得深思的現象：許多規模龐大的崩塌，發生在人跡罕至的原始林；而民眾實際從事農作的範圍，反倒相對穩定。這當然不是在鼓勵大家上山開墾——而是說明一件事：任何開發，都必須付出合理的保護與補償措施，這塊大地才可能取得平衡。

💡 老問題在收斂，新的隱憂卻在別處長出來

近年另一個逐漸浮現的課題，是早期開闢的部分山區農路與產業道路，若年久失修、水土保持與維護設施沒有跟上，或是道路搶修時為求快速、把崩塌的土石就近往下游溪谷傾倒。這些堆積的鬆散土砂，未來都可能成為新的土石流料源。這本書提醒我們看見風險的來源，而風險的來源，本身也一直在改變。

・・・

04更深一層：一本書留下的政策思考

如果只談土地利用，這本書也就只是一篇評論。它更深的地方，是把問題帶到制度層面。在當年，土地開發的利益多半歸於個人，而災後整治與復建的成本，往往由社會共同承擔。書中由此追問，開發的權利與相應的責任，該如何對等？公共資源投入高風險地區時，又該搭配什麼樣的規範，才不至於失去永續？

這些都是 2002 年前後的思辨。而值得欣慰的是，這二十多年來，隨著潛勢圖資、警戒基準、預警科技一項項到位，公共資源已經愈來愈能依科學風險來配置。書中當年提出的種種提問，很多正是後來一連串制度改革的起點。今天重讀它，不是為了翻舊帳，而是為了記得我們從哪裡出發、又為什麼要繼續往前走。

・・・

05當「土石流」變成社會的代名詞

書裡有個區分，我覺得也很值得省思－「土石流」與「土石流現象」是兩回事。前者是自然的物理作用，是石頭跟水往低處走；後者，是政治糾葛、社會力不振、公權力不彰所引發的連鎖反應。

地質的崩落只是結果。真正震碎家園的，往往是背後那個「現象」。書中引述前副總統呂秀蓮的說法，台灣社會其實正經歷五種土石流——政治、經濟、社會、自然與道德。當非理性的政治介入治山防災，當權利與義務的關係被扭曲，我們面對的就不再是單純的土石流動，而是一整套社會價值的崩塌。

・・・

06傲慢的代價：那座在地震帶上蓋地鐵的城市

林照真看完電影《火山爆發》後，被片中一句台詞觸動：這城市竟在地震帶上蓋地鐵，終將為自己的傲慢付出代價。她把鏡頭轉回台灣——我們何嘗不是在土石流的路徑上，硬闢出一條馬路？

大興村的龍君廟被厚重土石吞沒、上安村的居民與河道爭地而居，都是同一種傲慢的寫照。我們以為工程技術能征服自然，卻忘了潘朵拉的盒子一旦被九二一這樣的天災震開，那份傲慢終究會迎來沉重的回擊。

⚠️ 一個從業者願意誠實承認的邊界

科學能把土石量化到很細，卻無法替我們決定要如何對待這塊土地。二十多年來，制度確實一直在進步，許多過去做不到的預警，今天做得到了。但這本書提醒我：任何一套系統都有它的邊界——它算得出雨量會不會超標，卻算不出人願不願意用心善待每一寸土地。工具再好，也彌補不了土地倫理的缺席。

・・・

07那麼，我們到底能做什麼：土石流防減災的三個面向

讀完這本書，最容易碰到的一種心態是：既然土石流是大地的本能，那是不是什麼都別做了？當然不是。以我這些年的實務來看，工程措施並非不可行，關鍵在於是否搭配了足夠的空間與合理的配置。我們不可能再像過去那樣，為了多利用一點土地，就把野溪河道限縮在很小的範圍；相反地，得適時把空間留還給土石流去流動，甚至預留沉砂的位置。這些年靠著更多科學研究與技術發展，各種新型防砂設施例如透過性壩、可調式防砂壩，搭配新的工法，確實能在一定程度上保護聚落、減緩衝擊。但也必須誠實地說，任何工程設施都有設計的極限，在合理的預算下，我們能減緩的，終究只是某個規模以下的土石流。

「留空間」是什麼意思，這張圖說得比文字清楚：上游先用非透過性與透過性防砂壩（A、B）分段攔阻、消化能量，中段以大型沉砂池（C）與導流堤（D）容納並引導土石，最後由格柵壩（E）與導流渠道（F）讓水流安全繞過村莊。工程的重點不是把溪溝縮小，而是替土石流的規模預先留好去處。（豐丘溪治理工程空拍，攝於 2001 年 8 月 23 日；圖片來源：水土保持局歷史影像平台）

這就帶出第二件事。隨著氣候變遷，未來災害的規模愈來愈難預期，硬體擋不住的那一部分，得靠軟體來補：事前發布警戒、及早疏散避難，都比從前更關鍵。而民眾的自主防災意識與自主防災能力，同樣是發展重點——這也是我認為這近二十年進步最多的地方。

至於最難的一塊，始終是國土利用的規劃與管制。我想再強調一次：不是所有土地都不能使用，而是無論使用強度或使用規範，都必須替大自然留下足夠的空間，人與自然之間才可能取得平衡。

防減災的三個面向，正對應著「地、人、物」：物——硬體減災，靠治理工程減緩衝擊；人——軟體避災，靠警戒與避難降低傷亡；地——管理離災，靠總量管制與永續利用，從源頭把風險降下來。三者環環相扣，缺一不可。

📌 三個面向，環環相扣

說到底，土石流的防減災離不開三個面向：硬體的減災工程、軟體的防災疏散避難（包含社區的防災韌性），以及國土利用的永續規劃。三者環環相扣、缺一不可——任何一環鬆了，整套防災都會留下缺口。

・・・

08為什麼每進來一位新同事，我都請他先讀這本書

我待的單位換過名字。從早年的水土保持局土石流防災中心，到現在的農村水保署減災監測組。但有件事一直沒變：每當有新夥伴報到，我都會大力推薦他，一定要先把這本書讀完，再談其他。

不是為了考試，也不是懷舊。技術可以邊做邊學，SOP 可以照著跑，唯獨「我們到底為什麼而做」這件事，得先想清楚。這本書會告訴他：我們守的不只是幾條溪流的雨量門檻，而是山裡人的身家性命，還有一整套關於土地的權利與義務。讀懂了這個，才算真正接得住這份工作的使命，也才知道我們想完成的，究竟是一份什麼樣的志業。

・・・

土石掃過之後，我們還能為土地做什麼

從把土石流當成純粹的天災，到看懂它也映照著背後的整個社會；從只看見眼前的生計或環境，到明白兩者要靠完善的水土保持一起顧；從被動的災後整治，到讓科學的風險管理走在災害前面——這本書真正想改變的，從來不是山，是人看山的方式。

當下一個雨季來臨，如果我們願意把土地倫理放回每一次選擇的中心，也許土石掃過之後，還能替這塊土地找回真正的平安。而這一切，其實都收在本書序言那四個字裡——寸土寸心。

📌 延伸閱讀

這本書談的是「問題」；那麼二十多年後，我們到底把問題解到什麼程度？我把台灣土石流防災走過的這 25 年，整理成另一篇長文：〈從 214 條人命到零傷亡　台灣土石流防災走過 25 年〉。建議和這本書對照著讀，會更有感覺。

💡 這本書，現在可以免費讀

《戰慄土石流》目前已由余紀忠文教基金會開放全書 PDF 公開閱覽，逐章都能下載：https://www.yucc.org.tw/book/4881。一本影響了我整個防災生涯的書能被這樣公開分享，要特別感謝基金會的慷慨大方。誠心推薦每一位關心這塊土地的朋友，都親自讀一讀。

#戰慄土石流 #林照真 #土石流 #坡地防災 #超限利用 #環境正義 #讀後感 #防災科普

本文為《戰慄土石流》（林照真著，時報出版，2002 年 8 月）讀後感，書中觀點與引述均出自該書；「五種土石流」為書中引述前副總統呂秀蓮之說法；「寸土寸心」語出本書序言。
全書 PDF 由余紀忠文教基金會開放公開閱覽（https://www.yucc.org.tw/book/4881）；延伸閱讀連結為作者部落格文章。文中民國年份均已換算為西元年。

土石流防災二十五年

從214條人命到零傷亡
台灣土石流防災走過25年

2001年桃芝颱風一夜奪走214條人命。25年後的今天，地方政府可以在土石流發生前，提早疏散數十戶即將被土石掩埋的民眾。這中間發生了什麼事？

災害的規模由自然決定，傷亡的規模由人決定。這是台灣用25年、公私協力換來的深刻體認。

01一場沒有成為災難的豪雨

2025年7月28日下午3點半，高雄市六龜區。編號「高市DF114」的土石流潛勢溪流達到黃色警戒，村里隨即啟動預警疏散。三小時後，下午6點半，警戒升為紅色——當地在2小時內完成172人的預防性疏散。

然後，什麼事都沒發生。

7月29日沒事，30日沒事，31日也沒事。直到8月2日上午，土石流才真的來，衝進10戶民宅，土石在屋內堆積高達2.2公尺。8月5日中午12點半警戒解除，居民回家整理家園。

從疏散到災害發生，中間隔了整整五天。這五天，是172個人不在家裡的五天，也是地方政府必須頂住「到底還要撤多久」壓力的五天。最後的結果欄位上寫著：0人傷亡。

📌 這才是防災真正的樣子

成功的防災不會登上頭版，因為它的成果是「沒有發生的事」。六龜這一場，帳面上只有10戶民宅受損；但如果時間退回25年前，同樣的雨、同樣的溪流，帳面上會是另一種數字。

・・・

02那一夜，土石流來的時候沒有人知道

時間倒回2001年7月30日凌晨。中度颱風桃芝從花蓮登陸，受中央山脈阻擋，滯留在中部與東部山區超過10小時。最大累積雨量758mm，以今天的標準看並不算驚人，但921地震震鬆的山，撐不住了。

花蓮縣光復鄉大興村，全村184戶中約150戶被土石掩埋，27人死亡、16人失蹤。整場颱風全台111人死亡、103人失蹤，農林漁牧損失逾77億元。一場中度颱風，兩百多條人命。

災害的源頭：桃芝颱風後大興村上游集水區的空拍接圖。山脊到溪谷之間佈滿新生崩塌，鬆散土石一路沿著主流堆積下來——土石流不是從村子旁邊冒出來的，是整個集水區一起垮下來的結果。（歷史影像平台，水土保持局提供）

大興村災後。原本的房屋被掩埋在厚達數公尺的土石之下，圖中央下方裸露的那一截，是被挖開後才重見天日的建物殘骸。地面高程整個被墊高，等於村子被埋進地底。（農村水保署歷史影像平台，Christine Chou提供）

最難以承受的不是雨太大，而是沒有人知道，土石流即將到來。當時全台劃設的土石流潛勢溪流只有722條，警戒基準值尚未建立，山區居民手上沒有任何工具，可以在土石流抵達前告訴他們「儘快疏散避難」。

・・・

03把看不見的風險，畫在地圖上

第一步：知道危險在哪裡

1996年賀伯颱風後首次公布485條潛勢溪流，921地震後把集水區面積門檻從5公頃下修到3公頃、擴大為722條，此後逐年檢討增修。截至2026年1月，全台土石流潛勢溪流已達1,753條，另有94處大規模崩塌潛勢區，分布於17縣市、159個鄉鎮市區、692個村里。

1,753土石流潛勢溪流（條）

94大規模崩塌潛勢區（處）

52,783保全住戶清冊人數

1,141現役土石流防災專員

第二步：知道什麼時候該走

2005年起建立目前使用的土石流警戒基準值，以有效累積雨量為指標、50mm為級距，依各溪流地質條件訂在200至650mm之間；雨量預報逼近門檻發布黃色警戒，達到門檻發布紅色警戒，地方政府據以勸告或強制撤離。

這兩件事看似只是畫線與訂數字，卻是台灣第一次把「土石流」從災後的名詞，變成災前可以操作的指標。

土石流及大規模崩塌防災資訊網首頁。構成一個「隨時可查」的公開防災底圖——25年前，這些數字一個都不存在。

💡 為什麼溪流條數會一直增加？

不是山變壞了，是「看得更清楚了」。每一次重大地震或颱風之後，都會重新檢討劃設標準與範圍；同時地震也確實會製造新的崩塌與鬆散土砂。條數增加代表的是調查涵蓋率提升，也是我們對災害潛勢地區掌握度的提高。

・・・

04從24小時到48小時，多爭取的那一天

制度畫出了範圍，科技則負責把時間往前推。這25年間，台灣在坡地防災的觀測、監測與資料處理技術上已與國際同步發展，其中最直接改變地方政府決策節奏的一項成果，是土石流預警時程從24小時延長至48小時。

這一天之差，建立在兩個條件上：

其一，中央氣象署已能提供未來48小時的預測降雨。
其二，農村水保署把這份預測雨量完整整合進土石流預警機制，搭配每10分鐘更新一次的雨量記錄，自動換算全台每一處潛勢溪流是否達到警戒發布或預警門檻。

自動化算出的只是數字，最後仍由農村水保署專業分析研判，適時發布黃色警戒與紅色警戒。多出來的24小時，讓地方政府得以在雨真正落下前完成部署；近年推動的預防性疏散，也因此有了執行空間——不必等雨量逼近門檻才動員，而是在天氣還算平靜、道路仍然暢通時，就先安排優先疏散，把需要優先照顧的弱勢族群請下山。

2026年公開更新的潛勢資料與整備工作。右上角「未來48小時土石流紅黃警戒推估」是關鍵：警戒不再只是「現在達標了」，而是「後天可能達標」，讓地方政府提早啟動預防性疏散。

訊息傳遞也同步進化。土石流預報每天固定六個時段發布；其中已達黃色或紅色警戒的地區，會再透過細胞廣播直接推播到警戒範圍內的每一支手機，且同一則警戒不重複發送。警語文字更被逐字打磨：黃色警戒改為「請作好避難準備」，紅色警戒改為「請依指示避難」；細胞廣播原本只有中英文版本，近期並新增越南文與印尼文——山區的新住民與移工，同樣需要看懂那則警報。

・・・

05真正救人的，是那位拿著雨量筒的阿嬌姨

但科技從來不是這個故事的主角。

2004年5月24日，農村水保署把一批「簡易雨量筒」發送到台中和平松鶴部落的居民手上。那是很陽春的東西——一支透明量筒，刻度上標著100、200、300公釐，沒有電、沒有訊號、不會自己叫。

一個半月後，2004年7月2日起的七二水災來了。松鶴部落居民彭玉嬌——鄰居叫她「阿嬌姨」——就靠著那支剛發下來的量筒逐時記錄雨量，發現數字不對勁，自行啟動疏散避難機制，協助村民離開。那場水災，松鶴土石淹沒60戶，僅1人死亡。

右圖為松鶴部落災後空拍，土石淹沒60戶。

💡 7:2:1

日本阪神大地震的生還者調查顯示，成功脫困的比例中，自助佔7成、鄰里互助佔2成，公部門救援只佔1成。這個比例解釋了為什麼防災不能只做系統：真正把人帶出來的，多半是自己和隔壁鄰居。

「如果每個社區都有一位阿嬌姨。」

這句話直接催生了土石流防災專員制度。農村水保署自2005年起投入培訓，專員由在地居民擔任、任期三年，負責量雨、回報災情、傳達警戒、協助撤離、組織社區。累計培訓已達3,819位，現役1,141人，有潛勢溪流且有人居住的村里覆蓋率100%。2009年莫拉克颱風期間，防災專員協助約9,100名居民撤離，推估減少1,046人傷亡。

颱風來時，大家都在家躲雨，只有他們往外跑。防災專員手上的簡易雨量筒，二十多年來一直是這套系統最前端、也最可靠的一個節點。

這股力量後來擴大為自主防災社區2.0，全台累計628個村里投入，並依成熟度分為金質15處、銀質112處、銅質320處。每個社區依自身地理與人文條件量身打造防災模式：誰負責敲哪一戶的門、往哪條路撤、避難所鑰匙在誰身上——這些寫不進中央系統的細節，決定了撤離能否在兩小時內完成。

📌 演練不是形式

光是近一年，全台就辦理兵棋推演176場、實作演練60場、設施強化61處，並在鄉公所預置重機械待命175處，隨時進駐疏通水路。六龜那場「2小時內疏散172人」，靠的不是臨場反應，是演練過很多次。

・・・

06把25年攤成一張圖

防災最怕兩件事：該發警戒沒發，以及發了太多次讓人不再相信。

防災工作推動成效。綠線是土石流傷亡人數，藍線是該場事件的颱風災害總傷亡人數，紅線是兩者的比值；橫軸下方括號內是各場事件的累積雨量。紅色箭頭的起點，就是2002年啟動土石流防災應變機制的那道分界線。

先看紅線。1996年賀伯颱風，土石流傷亡佔颱風總傷亡的12%；2001年桃芝，這個數字衝到45%——那一年每兩位死傷者，就有將近一位是被土石流帶走的。

但這張圖最誠實的地方，是它沒有讓紅線在2002年那道虛線之後立刻歸零。2008年的卡玫基與辛樂克，比值仍然各是29%；2009年莫拉克，全台颱風災害總傷亡2,258人，土石流佔4%。機制不是開關，是累積。真正把紅線壓到貼著橫軸，是後面十幾年逐年增修潛勢溪流、調降警戒基準值、培訓防災專員、演練再演練的結果。

📌 圖上最該看的兩個括號

2009年莫拉克的累積雨量是2,855公釐，圖上用紅字標了出來，因為當年那是難以想像的數字。

然後看最右邊：2025年7月28日豪雨，累積雨量3,076公釐，比莫拉克還多兩百多公釐。土石流傷亡人數：0。

雨並沒有變小，是接住雨的方式變了。

2001年之後土石流傷亡人數逐年下降，近十餘年的颱風豪雨中，土石流保全對象已多次達成零傷亡。曾經一場颱風奪走兩百多條性命的災害類型，如今在警報響起與土石抵達之間，多出了那決定性的幾小時，甚至幾天。

・・・

07山的考題還沒有寫完

2025年9月樺加沙颱風在花蓮馬太鞍溪形成堰塞湖，溢流後重創光復鄉。截至災後統計，19人死亡、5人失蹤。那是與土石流不同的災害機制——蓄水量9100萬噸、世界級巨大堰塞湖溢流後的洪水規模、速度與影響範圍，都超出既有各類災害警戒系統的設計前提。

馬太鞍溪堰塞湖災害失聯與死亡統計圖（國立東華大學強韌防災團隊製作，底圖為國土測繪中心9月25日災後航拍影像）。紅點為死亡位置、藍點為失聯位置。溢流的洪水與土砂把河道拓寬到原本的數倍，直接把大平村、大同村納入影響範圍——既有的潛勢溪流圖層，畫不出這種規模的災害。

台灣花了25年學會應付一種災害，山又出了一道新題目。極端降雨讓單場雨量屢創新高，地震持續改變坡地穩定性，警戒基準值必須跟著動：2024年調降5縣市130條溪流，2025年再因地震調降3縣市55條，同時為42處二次災害高風險區設定分級降雨注意值。「潛勢溪流」這個框架本身，也正朝更精準、更多元的管理型態調整。

25年，換來的一句話

從722條溪流到1,753條，從沒有警報到細胞廣播四種語言，從數十戶被土石掩埋到全村平安疏散避難——台灣最有價值的防災基礎建設，或許不是任何一套系統，而是山裡那位願意在雨還沒落下時就出門敲門的人。

災害的規模由自然決定，傷亡的規模由人決定。這25年至少證明了這件事。

#土石流防災 #自主防災社區 #土石流防災專員 #預防性疏散 #桃芝颱風 #防災科技 #農村水保署 #韌性台灣 #零傷亡

資料來源：農業部農村發展及水土保持署「土石流及大規模崩塌防災資訊網」潛勢統計與警戒發布說明、2026年公開更新潛勢資料、防災工作推動成效歷年統計、《自主防災20年成果紀念誌》，以及2001年桃芝颱風災情紀錄。

【AI工作流】把 Google Gemini Spark 變成名片掃描王：設定一次 Skill，以後拍照就能整理聯絡人

AI 工作流・Gemini Spark

把 Google Gemini Spark 變成名片掃描王：設定一次 Skill，以後拍照就能整理聯絡人

從實際案例到可重複使用的 Skill，真正省下來的不是打字時間，而是整段名片整理流程。

這篇文章不是在教你怎麼做一次名片匯入，而是教你怎麼把一次成功的做法，變成之後可以反覆使用的 Skill。

📁 主題：Gemini Spark 名片工作流👥 適用情境：會議、論壇、拜訪後整理名片🧩 重點：把 Prompt 變成 Skill

很多人把 Gemini Spark 當成另一個聊天機器人，但我最近最有感的一個用法，其實是把它直接變成「名片掃描王」。這件事真正的價值，不只是辨識名片，而是把一次成功的操作流程存成 Skill，以後只要拍照上傳，就能自動啟動相同規則，持續幫你整理 Google 聯絡人。

先把核心架構擺出來

這篇文章的重點不是掃描，而是工作流

1

先實測一次先確認 Spark 真的能讀懂名片並寫入聯絡人。

2

把規則講清楚特別是顯示名稱如何放入公司與職稱。

3

存成 Skill把一次性的 Prompt，變成可重複使用的工作方式。

4

以後直接拍照未來只要上傳名片照片，就能自動套用。

如果只是把名片文字辨識出來，傳統 OCR 早就做得到。Gemini Spark 真正有意思的地方，是它可以把「辨識 → 整理 → 套規則 → 寫入 Google 聯絡人」這幾件事串成一段完整流程。而一旦這段流程被存成 Skill，它就不再只是一次成功的操作，而是可以持續重複使用的工作方法。

STEP 1

先做一次：拍照後請 Spark 匯入 Google 聯絡人

問題：這一步要確認什麼？

第一次使用時，我的做法很直接：把名片照片上傳給 Spark，請它將資訊寫入 Google 聯絡人，並指定「顯示名稱」要採用 姓名（公司及職稱） 的格式。

請幫我將名片上的資訊寫入 Google 聯絡人，其中「顯示名稱」上面寫為「姓名(公司及職稱)」。

為什麼我刻意把顯示名稱改成「姓名（公司 職稱）」？

這裡其實有一個很重要的技術限制，也是我最後採用這個命名方式的最主要原因。

Google 官方目前對 Contacts 連結功能的說明，明確舉例 Spark 可以查找、新增、修改或刪除姓名、Email、電話、生日、地址等聯絡資訊。不過在我實際使用 Spark 寫入 Google 聯絡人時，公司、職稱以及備註等欄位，並沒有像姓名、電話、Email 這些主要聯絡資訊一樣，可以直接指定寫入。

這就產生了一個很現實的問題：一張名片上真正有助於辨識對方身分的資訊，往往不只有姓名、電話與 Email，公司與職稱反而是最重要的背景資訊之一。如果 Spark 最後只能把姓名、電話、Email 寫進聯絡人，那麼名片上非常有價值的「他在哪裡工作、擔任什麼職務」就會在自動匯入的過程中遺失。

所以「姓名（公司 職稱）」其實是一個變通方式：既然目前無法把公司與職稱穩定寫進對應的專用欄位，我就把這兩項最重要、又最需要保留下來的資訊，一起放進 Spark 可以控制的「顯示名稱」裡。

例如原本只會建立：

• 王大明
• 李小華
• 陳志宏

我改成：

• 王大明（○○科技 總經理）
• 李小華（○○顧問公司 專案經理）
• 陳志宏（○○大學 教授）

這樣做不是因為「顯示名稱」本來就應該拿來存公司與職稱，也不是最標準的資料庫設計；它純粹是因應 Spark 目前欄位寫入限制所採用的實務折衷。如果未來 Spark 可以直接把公司、職稱、備註等資訊寫進 Google 聯絡人的對應欄位，我會優先採用結構化欄位，而不是把所有資訊都塞進顯示名稱。

但這個變通方式，剛好又帶來一個額外好處

即使先不談欄位限制，我實際管理聯絡人時也發現，「姓名」往往不足以讓我立刻知道對方是誰。尤其參加研討會、跨機關會議或業務交流後，短時間內可能一次新增十幾位甚至更多聯絡人；過一段時間再看到「王大明」這個名字，我未必還記得他是哪個單位、當時是以什麼身分認識的。

公司與職稱其實就是很有效的「情境標籤」。當畫面直接顯示 王大明（○○科技 總經理），我不需要再點進聯絡人詳細資料，就能立刻知道他的組織與角色。

這個差異在幾個日常場景特別明顯：

• 搜尋聯絡人時：同名或名字相近的人，可以直接用公司與職稱區分。
• 電話打進來時：螢幕上直接看到「姓名＋公司＋職稱」，更容易立刻判斷對方身分。
• 在 Gmail 選收件人時：不用先打開聯絡人詳細資料，就能降低寄錯人的機率。
• 很久以後重新聯絡時：公司與職稱能幫助我快速喚回「當初在哪個情境認識這個人」。

換句話說：第一層理由是「Spark 目前的欄位寫入限制，所以必須找替代方案」；第二層理由才是「這個替代方案剛好讓日後辨識與搜尋聯絡人更方便」。

當然，這個方法也有代價：如果對方換公司或升職，顯示名稱就必須跟著更新。所以它是一個現階段很好用的 workaround，而不是我認為永遠最理想的聯絡人資料結構。

圖 1｜實際操作案例：Spark 已辨識名片資訊，並進入建立 Google 聯絡人的確認步驟。

核心判斷：第一次操作的目標，不是追求最省時間，而是先確認 Spark 能否正確辨識、正確提議新增聯絡人，並且照你的格式建立顯示名稱。

從這張實際操作截圖可以看到，Spark 會先整理出要新增的聯絡人資料，接著詢問你是否允許建立聯絡人。這一步很重要，因為它代表流程不是單純文字回覆，而是真的往 Google 聯絡人的建立動作前進。

另外，手機拍照時候，可以將5~6張名片排好後一次拍攝，Spark 自己可以清楚地辨識每一張名片的資訊，毋需逐張拍照。

STEP 2

真正的重點：把剛才的做法存成 Skill

問題：為什麼這一步才是整篇文章最重要的部分？

如果每次拿到新名片，都還要重新打一大段指令，那這個流程只做了一半。真正讓 Spark 變成「名片掃描王」的關鍵，在於你把剛剛成功的做法，直接請它寫成一個 Skill。

好的，把我們剛剛拍名片照片上傳後，自動匯入到 Google 聯絡人的做法，寫成一個 skill。以後就照這樣的模式進行：只要我拍照上傳的內容都是名片的話，請自動啟動這個 skill，然後直接幫我寫入我的 Google 聯絡人。

這句話的價值在於：你不是在告訴它「這次怎麼做」，而是在告訴它「以後遇到同樣情境，都照這樣做」。這就是 Prompt 與 Skill 的差別。

圖 2｜實際操作案例：Spark 已將這套名片匯入流程寫成可重複使用的 Skill。

從第二張實際畫面可以看到，Spark 已成功建立並啟用 business-card-to-contacts 這個 Skill，並明確說明：未來只要上傳名片照片並要求儲存或匯入，它就會自動啟動這個 Skill，辨識名片資訊，並依「姓名（公司及職稱）」的格式直接寫入 Google 聯絡人。

注意：這裡真正值得學的，不是 Skill 的名稱叫什麼，而是把你常用的規則說清楚：何時啟動、要擷取哪些欄位、遇到不確定資訊怎麼處理、顯示名稱要怎麼組成。

Prompt 與 Skill 的差別，到底差在哪裡？

比較面向	Prompt	Skill
用途	解決這一次的任務	定義之後都照這樣做
重複性	每次都要重新下指令	建立一次後可反覆使用
一致性	容易每次寫法不同	可固定命名規則與處理方式
適合情境	偶發性問題	重複性的固定工作流

所以如果你只是想偶爾試一次，Prompt 就夠了；但如果你參加會議、論壇或交流活動後，總是會拿到一批名片，那就沒有理由停在 Prompt。這種工作本來就應該被做成 Skill。

我建議至少固定下來的 4 個規則

• 啟動條件：只要我上傳的是名片照片，就自動使用這個 Skill。
• 擷取內容：姓名、公司、職稱、電話、手機、Email。
• 命名規則：顯示名稱統一為「姓名（公司及職稱）」。
• 容錯原則：若文字不清楚或欄位不確定，不要自行猜測，先顯示給我確認。

⚠️

只測一次，不存 Skill

這樣你下次還是得從頭重新說一次，根本沒有形成工作流。

⚠️

沒有指定顯示名稱規則

匯入後只剩姓名，之後在聯絡人裡很難快速辨識身分。

⚠️

完全不做確認

名片照片若有反光或裁切不清，電話與 Email 仍可能出錯。

這個方法真正替你省下的是什麼？

省下來的不是「打幾個字」而已，而是每次活動結束後那一整段低價值、但又不得不做的整理工作。以前你要自己看名片、自己輸入、自己命名；現在則是第一次把規則教好，之後把例行操作交給 Spark。

這也是我認為 AI Agent 真正值得重視的地方：不是幫你多回答幾個問題，而是開始幫你接手一段可重複的工作流程。

結論：先做對一次，再存成 Skill

這篇文章真正要講的只有一句話：名片掃描不是重點，存成 Skill 才是重點。 當你已經證明 Spark 可以完成「拍照 → 辨識 → 寫入聯絡人」之後，下一步就不是再重做一次，而是把這套流程固定下來。

先實測一次

把規則講清楚

指定顯示名稱格式

存成 Skill

之後直接拍照

把時間留給更重要的事

如果你桌上也常常累積一堆懶得整理的名片，這大概就是最值得先做成 Skill 的工作之一。

參考來源：Google Gemini 說明文件（Gemini Spark、Skills、Google Contacts Connected App）。

Gemini Spark Google Contacts Skill AI Agent