2026/10/12

【AI工作流】從隨興寫扣到可維護的開發:Vibe Coding 帶給我的規格思維

從隨興寫扣到可維護的開發:Vibe Coding 帶給我的規格思維
AI 工作流・開發實務

從隨興寫扣到可維護的開發:Vibe Coding 帶給我的規格思維

一堂實戰課,讓我重新思考 AI 開發的規格、維護與驗收。
課程心得OpenSpec/SDD查核:2026-10-12

參加 Vibe Coding 實戰課程前,我以為重點會是如何寫出更精巧的提示詞,讓 AI 更快產生程式,或學會幾個自動生成的技巧。

沒想到課程一開始,我就發現自己對 Vibe Coding 的想像終究還是太淺了。課堂介紹的 OpenSpec 規格驅動工作流,大大開了我的眼界。

今天上課真的收穫很多,忍不住想趕快留下這份紀錄。尤其是當 AI 寫程式愈來愈快,我們能不能說清楚它為什麼改、改到哪裡,以及憑什麼判定完成?

原型跑得動之後,誰來說明它為什麼這樣做?

用幾句自然語言請 AI 搭出原型,確實方便。但當成果需要長期維護,單靠對話與「看起來可以用」,就容易遇到三個問題:

  • 需求容易漂移。 多輪修改後,最初的限制可能被忽略;新增一項功能,也可能影響原本正常的行為。
  • 決策難以追溯。 即使程式有版本紀錄,仍未必看得出某段業務邏輯為何改變、由誰確認,以及依據哪項需求。
  • 驗收缺少共同標準。 沒有事先說清楚成功條件,開發者與使用者可能對「完成」各有解讀。

這些問題並非 AI 開發獨有,只是快速生成與修改,更容易讓它們被忽略。

規格先行,把對話變成可檢查的約定

規格驅動開發(Spec-Driven Development,SDD)的重點,是在實作前寫清楚問題、改動範圍與驗收條件。

OpenSpec 將這些約定放進專案文件,協助人與 AI 對齊需求;還沒想清楚時,也能先探索。OpenSpec 入門文件

以下整理五個協作環節;實作發現新資訊時,可以回頭修訂文件,並非只能向前的流水線。OpenSpec 工作流說明

使用前:先請 Codex 安裝 OpenSpec

這次課程使用的是 Codex 桌面版。開始前,可以直接在對話中請 Codex:「請幫我安裝 OpenSpec,並在目前專案初始化 Codex 的工作流。」安裝與初始化完成後,再依它列出的技能名稱操作;若過程需要權限,依介面提示確認。

以下以 Codex 的技能呼叫為主,同時保留 IDE 斜線指令,方便對照。

五個協作環節依序為提案對齊、依規格實作、校驗與驗收、規格同步及歷史歸檔;發現需求改變時回頭修訂規格。
圖 1|五個環節各有責任;實作發現新資訊時,仍可回頭修訂規格。

1. 提案與對齊:先說清楚「為什麼做」

  • Codex 桌面版: $openspec-propose
  • IDE 斜線指令: /opsx:propose

建立變更。在預設的 spec-driven schema 下,產出提案 proposal.md、規格 specs/<功能>/spec.md、設計 design.md 與任務清單 tasks.md。OpenSpec 指令參考

AI 協助起草,人確認業務目的、權限、資料限制與驗收條件;文件齊全不等於內容正確。

2. 依序實作:讓任務有依據,也留下結果

  • Codex 桌面版: $openspec-apply-change
  • IDE 斜線指令: /opsx:apply

依任務清單實作並更新完成狀態。OpenSpec 指令參考

把必要測試列進任務,保存執行結果,並檢查改動範圍,讓清單上的勾選有成果支撐。

3. 校驗與驗收:檢查「做了」是否等於「做對了」

  • Codex 桌面版: $openspec-verify-change
  • IDE 斜線指令: /opsx:verify

檢查需求是否有對應實作、程式是否符合規格,以及設計是否落實。這是可選的擴充工作流,需依設定啟用。OpenSpec 指令參考

AI 協助找落差,但仍需實際測試、程式審查與業務驗收。

4. 規格同步:把確認後的變更納入正式規格

  • Codex 桌面版: $openspec-sync-specs
  • IDE 斜線指令: /opsx:sync

將增量規格合併到 openspec/specs/,也可在歸檔時處理。OpenSpec 常見問題

同步不會從程式自動反推需求。實作若有調整,要先確認合理性、修訂文件,再同步。

5. 歷史歸檔:保留一次變更的脈絡

  • Codex 桌面版: $openspec-archive-change(課堂寫法:$openspec-archive)
  • IDE 斜線指令: /opsx:archive

封存變更文件,保留規劃與任務紀錄。未完成的任務可能只觸發警告,因此歸檔不代表通過驗收。OpenSpec 指令參考

完整追溯還需串起程式版本、測試、審查與核定紀錄。

指令使用提醒: Codex 使用技能呼叫;IDE 斜線指令的格式則依整合工具不同。本文保留課堂的 $openspec-archive 寫法,實際操作仍以安裝後顯示的名稱為準,五個環節也不必每次都逐一執行。OpenSpec 工具整合說明

只是寫個小工具,也需要完整流程嗎?

不一定。一次性、容易重做、出錯影響很小的腳本,通常不必套用完整 OpenSpec;反覆使用或交給同事的小工具,則值得留下基本規格。

用完就丟的資料整理,或在測試資料上摸索套件與 API,可以先快速試作。

但即使只跑一次,若會覆寫資料、刪除檔案或更動正式資料庫,仍要確認操作範圍,準備預覽、備份或還原方式。

小工具的維護負擔,常在追加功能或交接時出現。例如原本只把 SHP 轉成 GeoJSON,後來又加入面積計算與無效值過濾;若沒記錄座標系統、輸出條件與異常處理,就難以判斷修改有沒有影響既有結果。這是示意情境,但也提醒我:省下今天的紀錄,可能換來明天重新理解程式的時間。

人負責決策,AI 協助把決策落實

這堂課讓我重新看見工程經驗的價值:AI 可以協助實作,人仍要決定需求取捨、資料邊界與驗收標準。規格也可能漏寫,模型也可能誤解,因此文件與測試仍需有人檢查。

下一次使用 AI 開發,我想先問清楚:要解決什麼問題?哪些邊界不能越過?看到什麼證據,才算完成?

從「快點寫出來」走向「知道它做對了」,是今天最想留下的收穫。


技術流程依 OpenSpec 官方文件於 2026 年 10 月 12 日查核;實際指令與產物可能隨版本、整合工具及 schema 設定不同。文中的治理做法與心得為作者對課程的整理與延伸。

2026/10/11

【AI工作流】不必背提示詞,掌握四個大原則就夠用

不必背提示詞,掌握四個大原則就夠用
AI 工具・日常協作

不必背提示詞,掌握四個大原則就夠用

把偏好、背景與成果對象說清楚,讓 AI 更容易接住你的需求。
2026年10月10日@大崩AI工具
Hero 首圖:左側以文章標題與「把需求說清楚,讓 AI 更容易接住你的想法」為核心;右側以對話視窗搭配記住偏好、交代背景、口述發散、提問補缺四個圖示。底部提問:成果給誰用?要幫他完成什麼?

現在與 AI 合作,很多日常任務已經可以用平常說話的方式交代,不必先背一套固定格式、角色設定或長篇指令模板。

但不必背提示詞,不代表需求可以省略。比起追求漂亮的指令,先讓 AI 知道你的偏好、這次要完成什麼,以及成果最後給誰用,通常更有幫助。

以下整理四個我常用的方法。與其說是提示詞技巧,不如說是跟 AI 合作的好習慣。

四個合作原則:記住偏好、交代背景、口述發散與提問補缺。需求清楚時,交代對象與用途、提供資料與限制,直接產出初稿;還沒想清楚時,先口述想法、歸納重點,再提問補缺。四種方法可以搭配,不必每次全部使用。
圖|四個合作原則與兩種使用情境:需求清楚就直接產出,還沒想清楚則先口述、歸納,再提問補缺。

一、建立專屬記憶,讓 AI 理解你的偏好

ChatGPT、Claude 與 Gemini 都提供記憶或個人化相關功能,但名稱、可用範圍與啟用條件不同,仍要以自己的帳號設定為準。可以先讓它知道你的工作背景、慣用語氣、文章長度,以及不喜歡的用詞。相關設定可參考 ChatGPT 個人化說明、Claude 記憶說明與 Gemini 個人化說明。

如果使用的工具有專案或類似工作空間,也可以把個別工作的背景資料與規則集中放進去,讓後續討論沿用同一套脈絡,不必每次重新交代。

我之前用三篇文章整理過這類做法:從建立專屬工作空間、管理專案內容,到透過對話產生專案指令與 SOP。想進一步實作,可以依需要參考:

分層管理的原則很簡單:通用偏好放設定,工作細節放專案。 這樣能減少反覆交代;不過,這次任務的重要條件仍要明說,不要只靠 AI 自己記得。

二、用 5W1H 交代背景,最重要的是給誰看

說明需求時,可以用 5W1H(何人、何事、何時、何地、為何、如何)幫自己整理思路。它是一份檢查清單,不必每次都填滿六個欄位;也可以直接提供文件、圖表或照片,讓 AI 掌握具體脈絡。

其中我最重視的是:這份成果最後要給誰看、給誰用?

寫給主管的簡報、給民眾的說明、給同事參考的技術筆記,即使討論同一件事,用詞深淺、篇幅與重點也會不同。除了要做什麼,再補上對象、用途與必要限制,AI 才有方向可依循。

例如,比起只說「幫我整理這份資料」,可以說:「請把這份資料整理成給民眾看的說明,用白話解釋,讓沒有相關背景的人也能看懂。」

三、需求還模糊時,用說的就好

如果自己也還沒想清楚要什麼,不妨用語音輸入,先把想法說出來。想到什麼就講什麼,不必在意邏輯順序,也不用急著整理成條列。

講完後,再請 AI 歸納重點,整理成清楚的需求或初稿。這種先發散、再收斂的做法,省去了「還沒想清楚,就得先寫出完整提示詞」的壓力。

這篇文章的初稿,就是這樣口述出來的。口述讓想法先有出口,整理則讓它逐漸成形。

四、請 AI 先發問,補足關鍵資訊

當任務還有不清楚的地方,可以加上一句:

如果目前資訊不足,請先問我幾個最關鍵的問題,再開始撰寫。

AI 可以根據已有內容,針對用途、對象、篇幅或風格提出問題。你只需要回答,需求就能在一問一答之間逐漸成形。

這個方法特別適合「知道自己有需求,卻還說不完整」的時候。如果任務已經清楚,就讓 AI 先做出初稿,再針對成果調整,不必每次都先訪問一輪。

結語:四個原則,依需要搭配

長期偏好先設定;任務開始時,交代背景與成果對象;想法模糊時,先用口述發散;缺少關鍵資訊時,再請 AI 提問補足。

四種方法可以搭配,也不必每次全部使用。下次交代任務,可以先從一句話開始:「這份成果要給誰用,幫他完成什麼?」 把這件事說清楚,再逐步補上資料與限制,合作就更容易有方向。

2026/09/28

【邊坡穩定分析工具】不必先猜滑動面在哪裡,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搬進瀏覽器之後

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

SSA 邊坡穩定分析網頁版操作畫面
開啟時會先載入一個三層地盤加地下水位的範例並完成計算,使用者可以直接在圖上修改,再按一次計算。
  • 畫出剖面就能算。地表線、各土層界面、地下水位線都可以在圖上拖曳節點,或從 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 產品說明。

2026/09/26

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

觀點・個資與隱私

防盜門與牢房

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

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

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
本文為作者個人觀點。

2026/09/09

【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
來源保留查證、引用與追溯依據。
五步驟資訊圖,依序說明完成 AI 對話、用 Web Clipper 保存逐字稿、呼叫歸檔 Obsidian、產生 decision.md、insight.md、reference.md,最後放入主題資料夾。
半自動歸檔流程:原始對話先完整保存,再把決策、洞見與參考資料整理成可累積的知識。

先建立 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 對話逐字稿範本

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

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

Obsidian 資料夾架構圖,左側 Clippings 保存 AI 對話逐字稿,右側主題資料夾包含 decision.md、insight.md 與 reference.md。
逐字稿保留過程,三個核心檔案保存成果;所有結論都應能回到原始對話查證。
核心原則: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。

相關工具

2026/08/27

【防災思維】九天,還是幾分鐘?瑞士 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公尺以上的懸冰川,既不在列管的高風險冰湖名單,現場也沒有連續性的地表變形監測。

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

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

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

瑞士Blatten與尼泊爾邊境事件六項比較表
同樣的災害型態,一邊爭取到九天,一邊只剩幾分鐘。把這張表攤開,兩地拉開差距的落點,幾乎都集中在監測那一列。
・・・

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

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

臺灣既有坡地防災六大制度與資料基礎
這六塊制度目前多半各自維護、分屬不同流程。

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

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

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

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

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

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

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

不安定土砂調查與運用流程,以醫療影像檢查為比喻
每一階段的調查成果,就是下一輪風險評估的起點。從判釋新生崩塌、追蹤殘坡,到排定治理優先順序,正好對應這一節的三步。
・・・

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

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

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

多源監測技術與偵測確認研判通報流程
左右兩側是不同尺度的監測工具,中間的偵測、確認、研判、通報才是重點。設備是輸入,鏈才是產出。
・・・

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

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

⚠️ 把系統的邊界講清楚

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

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

雨量型警戒與事件型偵測雙軌並行架構
兩軌不是取代關係。左軌處理因雨量而來的災害,右軌處理非因雨量誘發的災害;下方流程是右軌被觸發後才啟動的部分。

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

・・・

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

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

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

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

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

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

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

冰湖潰決演練情境設定與分層改進架構圖
走位、兵推、情境導向實作不是三選一,而是三層。差別不在辦在哪裡,而在情境想定敢不敢貼近最壞的狀況。

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

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

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

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

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

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

2026/08/23

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

防災書架 ・ 讀後感

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

一本 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);延伸閱讀連結為作者部落格文章。文中民國年份均已換算為西元年。