2026/11/02

【SSA 邊坡穩定分析-升級版】邊坡已經在動,接下來怎麼算? SSA 從傾斜管一路算到計算書

SSA 邊坡穩定分析・改版紀錄

邊坡已經在動,接下來怎麼算
SSA 從傾斜管一路算到計算書

9 月介紹 SSA 時,它主要做一件事,自動找出安全係數最小的滑動面。兩個月後,它能把傾斜管、崩崖與觀測水位放進分析,反算土壤參數,設計補強與擋土牆,最後輸出送審用的計算書。

搜尋找到的是最危險的滑動面,現地資料指出的是正在動的那一條。

01搜尋找到的,不一定是正在動的那一條

上一篇〈不必先猜滑動面在哪裡〉介紹的是 SSA 的核心。它用動態規劃逐段搜尋,不必先假設圓弧,就能找出安全係數最小的臨界滑動面。

實務上常遇到另一種情況。颱風過後,坡頂裂了一道縫,坡趾開始隆起,邊坡已經在動。這時手上通常有更多資料,包括地表的裂縫與隆起、傾斜管讀數、崩塌後的測量和鑽孔水位。

自動搜尋找到的,是在你假設的參數下最危險的那一條。現場正在滑的那一條,可能更深,位置也不同。這次改版的重點,就是讓分析跟著現地資料走。

1.318自由搜尋的 Fs
1.672通過傾斜管剪動位置的 Fs
26.12°反算的崩積層 φ′
146驗證檢核全部通過
📌 本文的例子

文中數字都來自使用手冊的教學案例。這是一處坡高約 12.5 m 的道路上邊坡,表層是 4 到 6 m 的崩積層,下方為風化岩與岩盤,坡頂有道路。參數為假設值,僅供說明操作。

・・・

02地表跡象與傾斜管,把滑動面釘住

坡頂的裂縫是崩崖,坡趾的隆起是滑動體被擠出的地方,這兩處標出了滑動面的兩端。在「剖面」頁的滑動面控制點限制坡趾出口與坡頂入口的範圍,重新計算後,滑動面兩端都落在範圍內,Fs 為 1.319。

兩端固定了,中間仍可淺可深,深度要靠地下資料決定。假設坡腰的傾斜管 BH-1 在地表下 8 m 量到明顯剪動,把它設成控制點,輸入位置 28 m、深度 8 m、容許誤差 0.3 m,搜尋就只接受通過這個位置的滑動面。

通過傾斜管剪動位置的臨界滑動面
滑動面通過傾斜管的剪動位置(綠色菱形),兩端也落在崩崖與隆起範圍內。地表與地下的證據指向同一條滑動面。

奇怪的是,這條滑動面的 Fs 是 1.672,比自由搜尋的 1.318 高出許多,邊坡卻明明在動。這表示現地強度比假設的低,或水位比假設的高。答案要靠反算。

・・・

03反算,崩塌當下 Fs 約等於 1

邊坡如果已經崩塌,反而多了一個很有價值的條件。崩塌那一刻的 Fs 約等於 1。

先把崩塌面放進「指定滑動面」,再把地下水位改成崩塌當時的高水位,本例比剖面水位高 2 m。試算得到 Fs 1.069,仍大於 1,代表假設的強度偏高。在「設定」頁的反算分析選擇摩擦角,目標 Fs 設為 1,程式以二分法求得崩積層的 φ′ 為 26.12°,比原本假設的 28° 低。

反算結果與 c′–φ′ 組合曲線
曲線上每一點都讓 Fs 等於 1。一條崩塌面只能決定一條曲線,c′ 與 φ′ 要固定其中一個,或用兩條以上的崩塌面交會。
⚠️ 反算值的前提

反算結果高度依賴假設的水位、單位重與計算方法。設計時要沿用反算時的方法與水位條件,否則反算就失去大半意義。

・・・

04分層水壓,同一個剖面有兩種水位

不同地層的水頭常常不一樣。崩積層裡是一般的地下水,下方的風化岩卻可能是受壓含水層。本例假設鑽孔 BH-2 在風化岩量到的水頭接近地表,到了坡趾甚至高於地表。

現在可以在剖面上新增水壓線,再到「土層」頁指定風化岩改用這條線,崩積層仍用地下水位,各層各用各的水頭。重新計算後,滑動面切進風化岩,最大深度由 5.9 m 變成 8.6 m,Fs 降到 1.259。

風化岩受壓水頭使臨界滑動面變深
綠色點線是風化岩的受壓水頭。只看地下水位,就會漏掉這條更深的滑動面。

沒有水位資料,或規範以孔隙水壓比表示填方與棄土場的水壓時,也可以改用 ru。

・・・

05補強、擋土牆與特殊條件

找到滑動面之後,下一步是設計。補強構件從原本的土釘、地錨,擴充到抑止樁、微型樁與地工合成材。教學案例中,8 支 6 m 土釘只把 Fs 從 1.318 提高到 1.361,因為多數土釘伸出滑動面的長度太短,拉拔力有限。改成 9 m 後,Fs 提高到 1.599。

規範還要求暴雨與地震情境。「檢核」頁預設常時、暴雨、地震三種情境,要求安全係數依水土保持技術規範第 73 條分別為 1.5、1.2、1.1,一次算完。本例三種情境為 1.599、1.323、1.129,全部符合。

擋土牆有獨立的頁面,可以檢核重力式、懸臂式與扶壁式擋土牆的滑動、傾倒、偏心與承載力。坡趾那座重力式擋土牆在地震時的滑動安全係數只有 1.12,牆前道路下有 1 m 根入,計入被動土壓後提高到 1.35。整體穩定方面,擋土牆的壓腳效果讓常時 Fs 再升到 1.705。

土釘與坡趾擋土牆的整體穩定
土釘與擋土牆一起納入整體穩定。擋土牆視為不可穿越的結構物,滑動面只能從牆下或牆後通過。

滑動面太深、土釘夠不到的地滑,可以改用抑止樁。程式依日本《地すべり防止技術指針》求出把 Fs 提高到 1.5 所需的必要抑止力,本例為每公尺 173.9 kN,再逐項檢核彎曲應力、剪應力、根入長度與地盤降伏。

河道旁的邊坡,只要把水位線畫到地表以上,就會自動視為坡外積水。坡頂若有張力裂縫,可依 Rankine 公式計算深度,並設定裂縫是否充水。坡趾積水 3 m、坡內水位上升,再加上充水的裂縫,本例的 Fs 由 1.318 降到 1.117。

坡外積水與張力裂縫
淺藍色是坡外積水。水退得快、坡內的水來不及排出時,情況反而不利,要另外評估。
・・・

06算出來的數字,能不能信

上一篇提到 SSA 只有簡易 Janbu 法,嚴密法要用其他軟體驗證。這次加入了 Spencer 法與 Morgenstern–Price 法,兩者同時滿足力與力矩平衡。選用嚴密法時,程式先以簡易 Janbu 法找出臨界滑動面,再移動滑動面的節點與兩端,讓所選方法的 Fs 最小。本例 Spencer 法為 1.429,M–P 法為 1.421,都高於簡易 Janbu 法的 1.318,未修正的簡易 Janbu 法確實偏保守。

手上有舊報告時,可以輸入圓心與半徑,重算同一個圓弧。兩邊的數字若有差異,多半出在計算方法、孔隙水壓的算法或切片數這三處。

「說明」頁的驗證報告,會以當版的計算核心在瀏覽器裡重算全部驗證考題,包含閉合解、Fredlund and Krahn (1977)、ACADS 標準考題、補強構件、鋼管樁計算例與擋土牆外部穩定。目前 146 項全部通過,約需 3 分鐘,報告可下載 Word 或列印為 PDF,作為送審時的程式驗證文件。

驗證報告結果
每次改版都重跑一次,確認新功能沒有改壞原本的計算。

分析完成後,「檢核」頁可以直接輸出 Word 或 PDF 計算書,內容包含輸入參數、擋土牆外部穩定、臨界滑動面與切片明細,以及各情境的檢核總表。

教學案例產出的計算書
教學案例產出的計算書。Word 檔可以直接套用公司版型再編修。
・・・

07手冊、影片,以及還做不到的事

為了讓第一次使用的人也能上手,這次一併完成了使用手冊與教學影片。手冊有中文、英文、日文三種版本,第一篇以同一個道路邊坡為例,從輸入地形一路做到計算書,第二篇依使用情況介紹控制點、反算、分層水壓等進階功能。各章的範例檔都能直接匯入。

💡 從這裡開始

SSA 網頁版 cychen59.github.io/ssa-slope-stability

使用手冊 中文/English/日本語(皆可下載 PDF)

教學影片 前導/第一集 入門教學/第二集 現地資料/第三集 特殊條件與可信度

建議先看第一集,再照著手冊第 1 到 8 章操作一次。

⚠️ 使用前要先知道的限制

SSA 是二維極限平衡分析,不做滲流分析,孔隙水壓由水位線或 ru 計算。坡外積水以靜水壓處理,不含水位驟降產生的超額孔隙水壓。擋土牆只檢核外部穩定,牆身與底版的結構強度要另外設計。

計算結果僅供參考,工程判斷與設計仍應由專業技師依現地調查與相關規範負責。

和上一篇一樣,這兩個月的改版也是和 Claude Opus 5.5 一起完成的。從加入嚴密法、擋土牆,到逐章截圖的使用手冊與三集影片的字幕,都是一邊試算、一邊比對文獻、一邊修正出來的。

從找到滑動面,到交出計算書

從只有簡易 Janbu 法,到三種方法並列比對;從自由搜尋,到讓滑動面通過傾斜管的剪動位置;從單一地下水位,到各層各用各的水頭;從一個 Fs,到能送審的計算書與 146 項驗證。

搜尋找到的是最危險的滑動面,現地資料指出的是正在動的那一條。這次改版,就是讓這兩者在同一個畫面裡對得起來。

#邊坡穩定分析 #臨界滑動面 #反算分析 #擋土牆 #ClaudeAI

文中數值為 SSA v2.10.2(2026-11-01)使用手冊教學案例的計算結果,參數為假設值,僅供說明操作。
相關文章〈不必先猜滑動面在哪裡,SSA 邊坡穩定分析免費網頁版一鍵解決〉(2026-09-28)。
問題與建議歡迎來信 cychen59@gmail.com。

2026/10/25

【防災工作手記】現勘結束,才是追蹤的開始。從一次邊坡現勘,重新思考動態風險管理

減災監測組・防災工作手記

現勘結束,才是追蹤的開始
從一次邊坡現勘,重新思考動態風險管理

台灣花了二十多年,把土石流潛勢溪流與大規模崩塌潛勢區一一畫上地圖。可是每一場颱風過後,山都在變。那些還沒被畫進地圖、卻已經出現異常的地方,需要有人接著看下去。

過去二十多年,我們努力回答哪些地方可能發生災害。接下來,還要能回答新發現的風險由誰追蹤、如何處理、何時調整。

01現勘之後,那處邊坡交給誰?

南投縣仁愛鄉發祥村慈峰產業道路旁,一處坡地出現地滑跡象。消息傳進組裡,負責大規模崩塌業務的同仁第一時間安排現勘,調查團隊很快進場。

這是我們熟悉的節奏,我很感謝同仁的即時反應。但這一次,我想和大家再往前想一步。

現勘完成、紀錄寫好之後,如果這處邊坡還不確定會不會被納入大規模崩塌潛勢區,接下來由誰繼續看著它。

潛勢區的認定需要調查、評估與行政程序,這段時間可能不短。坡面卻不會等程序走完,才決定要不要繼續滑動。

📌 是否納入潛勢區,與是否需要持續追蹤,是兩個問題

一處已經出現異常的邊坡,不應因為身分還沒確定,就在現勘之後失去追蹤。我們先把這類個案納入不安定土砂的追蹤評估,正式分類與後續措施,再依調查結果與相關程序辦理。

本文提到慈峰的案例,並不預先判定它的規模、危險程度或最後的分類結果。它讓我們看見的,是制度與制度之間那段容易被忽略的空白。

2026 年 10 月 5 日慈峰產業道路旁滑動坡地的空拍環景
2026 年 10 月 5 日空拍。滑動範圍上緣緊鄰茶園與建物,下方則延伸進整片林地。開啟 360 度空拍環景
・・・

02明霸克露橋教會我們的事

2021 年盧碧颱風期間,高雄市桃源區玉穗溪的崩塌與土砂運移,造成明霸克露橋災損。

災後我們重新檢視歷年衛星影像,發現玉穗溪上游早在 2009 年莫拉克颱風之前,就已出現坡頂張力裂隙。莫拉克風災後,坡面變動更加明顯,逐漸形成大範圍的不安定殘坡。2015 年蘇迪勒颱風後,坡頂裂隙與下方尚未崩落的區域,已形成較明確的不安定土砂區塊。之後歷經多次颱風豪雨,最終在盧碧颱風及 0806 豪雨期間發生大規模崩塌。

玉穗溪上游斯拉巴庫山邊坡崩塌變遷過程
玉穗溪上游斯拉巴庫山邊坡崩塌變遷過程。崩塌面積從 2007 年的 3.1 公頃,逐期擴大到 2021 年 8 月的 79 公頃。大規模崩塌發生前十多年,每一期影像都已留下變化的線索。(資料來源:農村水保署電子報第 98 期)

玉穗溪下游沒有保全住戶,歷年來未劃入土石流潛勢溪流。當時也並未針對這類尚未納入既有防災體系的上游不安定土砂,建立常態性的追蹤與風險評估機制。

這件事讓我們重新檢視自己的工作方式。台灣的坡地防災從土石流潛勢溪流開始,逐步擴展到大規模崩塌。這些工作都建立在地質、地形與歷史調查之上,先找出哪裡有潛勢且有明確可能受到衝擊的保全住戶,針對這些地方安排調查、監測、警戒與應變。

這套方法這些年保護了許多人,但它有一個前提,就是風險已經被看見。然而,每一次颱風、豪雨或地震之後,現地條件都可能改變,坡面或河道裡可能多出新的不安定土砂,並成為下一場土砂災害的致災料源。這些變化及可能帶來的風險,未必能立即反映在既有的潛勢資料與作業機制裡。

二十多年前我剛進這個單位時,讀的是林照真的《戰慄土石流》,那本書讓我明白這份工作為什麼存在。這些年制度一路長出來,我越來越相信一件事。地圖畫得再細,也要承認山會變。

💡 既有潛勢區是基礎,不是邊界

現行二次災害高風險區的評估,已涵蓋既有土石流集水區、不在既有集水區內的野溪,以及鄰近保全住戶的易致災坡面。我們要做的,是讓掌握風險的範圍,持續跟著山的變化更新。

更早發現風險的理念進化與工作流程
從土石流潛勢溪流、大規模崩塌,走到事件後的動態風險管理。技術工具的用途,是讓線索更早浮現,並接得上後續的追蹤與評估。
・・・

03從發現異常到分級追蹤

要更早發現風險,我們手上有幾種工具。地動訊號是地震儀記錄到的崩塌震動,衛星雷達(SAR)不受雲雨遮蔽,可以觀測地表變化,再加上光學衛星影像、無人機(UAV)空拍與現地調查。

2026 年 6 月 21 日發現萬里溪新形成的堰塞湖後,我們與陽明交大防災中心團隊分析地動訊號,事後回推崩塌發生在前一天下午 3 時 43 分。時間範圍縮小之後,影像、地形與現勘資料的判讀都更有效率,研判與溝通也有了可靠的起點。這是事件後的回推分析,並不代表當時已能即時自動偵測與通報。(資料來源:萬里溪堰塞湖地動訊號分析)

⚠️ 異常偵測只是線索

每種工具都有適用條件與精度限制。SAR 在台灣陡峭山區會受雷達陰影、疊掩與地表覆蓋變化影響,部分崩塌可能偵測不到。兩期 UAV 三維模型的差異,也可能來自定位誤差或植生遮蔽,不一定代表坡體真的在動。線索要經過多時期資料比對、必要的現地查證與專業研判,才能決定是否進一步處理。

不是每一處異常,都要無限期列管

遙測與影像判釋的能力越來越好,每年發現的疑似異常也會越來越多。如果每一處都列入長期監測,最後拖垮的會是整個團隊。我們正嘗試依證據與可能影響,把追蹤分成三種層級。

資料留存與定期檢視異常證據有限、近期變化不明顯,或暫無明確影響對象。保留基準資料,利用既有影像或事件後資料再檢視。
重點追蹤有持續變動跡象、較大量的不安定土砂或潛在影響對象。安排專案評估、影像比對或必要的補充調查。
優先處置與跨機關協調有明顯加速變動或可能造成重大衝擊的證據。優先研判,必要時協調權責機關採取監測、防護或應變措施。

層級可以往上,也要能往下。追蹤一段時間後,若異常沒有持續發展,就降低檢視頻率。確認不需要專案追蹤時,也應該允許結案並保存紀錄。新的豪雨、新的崩塌或其他異常訊號出現,再重新提高關注。一套只進不出的制度,長期一定撐不下去。

讓每一個被發現的異常,都有下一步

我們希望建立的,是一個簡單、可以持續運作的方式。發現異常之後,先建立基本資料,確認目前有哪些證據、可能影響哪些對象,再依變動程度與風險高低,決定是否需要進一步調查、定期追蹤或優先處理。

每個需要追蹤的個案,都應該有明確的承接窗口、下一次檢視的時機,以及提高或降低追蹤層級的依據。涉及其他機關權責的事項,也要有清楚的通報與協調方式。

我們想補上的,不是另一張越畫越大的風險地圖,
而是一套讓新發現的風險有人承接、
依證據持續調整,也能適時結案的工作方式。

・・・

04讓每個地點都有自己的風險歷程

回到慈峰的例子。同仁進場現勘的同時,也同步安排無人機空拍,建立正射影像與三維地表模型,再整合既有影像與調查資料,這次現勘就留下了一個可比對的起點。下一次再飛、再看,才能回答坡面變形是否擴大、裂隙或崩塌範圍如何改變。

慈峰這處坡地就是這樣被看出變化的。我們比對多期影像上的地表特徵點,截至 2026 年 10 月 20 日,量測出累計滑移量約 63 公尺。

2026 年 6 月 2 日衛星影像 2026 年 7 月 6 日衛星影像 2026 年 8 月 2 日衛星影像 2026 年 9 月 14 日衛星影像 2026 年 9 月 30 日衛星影像
2026 年 6 月 2 日至 9 月 30 日的衛星影像依序播放。紅框內坡面裸露的範圍逐期擴大,坡頂開裂處的擾動也越來越明顯。(影像來源:農村水保署 BigGIS)開啟BigGIS 2026/10/5 空拍正射影像
2026 年月降雨量與累計位移量
8 月以前位移緩慢累積,9 月之後明顯加速。值得注意的是,9、10 月的降雨已大幅減少,滑移卻仍持續增加。

這張圖說明了單次現勘看不到的事。一處坡地在某個時間點看起來的樣子,無法告訴我們它正在加速還是趨緩。只有連續的觀測,才能讓判斷跟上坡面的變化,這也是「是否追蹤」不能等到「是否劃設」確定之後才決定的原因。

空拍後產出的 3D 模型,除了方便檢視地表全貌及建立精準的地形資料,亦可整合現地構造調查與長期監測資料,分析地滑在不同時期的運動與變化。模型提供的是數據,要不要進一步調查或監測,仍由專業人員綜合研判。

慈峰產業道路旁坡地的空拍三維模型
由空拍影像建立的三維模型,可以直接量測距離、面積與坡度,下一期模型也能以它作為比對基準。開啟空拍 3D 模型

這些資料還要接得起來。現勘紀錄、空拍影像、三維模型與後續追蹤成果,不應各自躺在不同的案件資料夾裡。我們希望逐步用共同的地點識別與時間紀錄把它們串起來,讓之後接手的人知道,這裡第一次何時被發現、當時怎麼判斷、後來有哪些變化,以及為什麼調整了處理方式。

資料治理的分工與價值鏈
資料治理由專責單位統籌,各業務單位維護內容,資訊單位支援系統與資安。底層的資料整理做紮實,上層的分析與決策才站得穩。
📌 資料存得下來,只是開始

資料治理的成果,是下一次的調查與決策,可以站在前一次的成果上繼續往前走。少了這段歷程,前面講的分級、降級與結案,都只能靠個人記憶支撐。

・・・

05跨科合作,讓風險有人承接

減災監測組有四個科,各有專責。分工的目的是讓專業有人負責,但分工也有副作用。一個案件如果落在科與科之間,很容易每一科都做完了自己那一段,卻沒有人負責下一步。

慈峰的情況就是一例。知道組裡有無人機與調查資源,處理異常邊坡的同仁就能在第一時間想到同步整合。知道有人正在處理一處異常邊坡,負責不安定土砂調查的同仁就能思考是否承接後續追蹤。

我們正在建立的工作方式,包含三個要素:

  • 案件承接 每個追蹤個案都有明確的主責窗口與處置狀態,不依賴最初接獲通報的那個人。
  • 專業分工 各科依業務共同提供評估、監測、資料與應變支援,而不是把責任集中在某一科。
  • 持續檢討 案件定期更新,依風險變化調整追蹤層級與後續處置。
把新發現的風險接回防災機制的工作鏈
發現異常之後的五個環節,以及四個科如何在其中相互支援。分工是為了讓專業有人負責,不是單向移交。

新發現的風險,如何回到既有機制

新的風險資訊,會先進入動態評估與追蹤流程,再依性質與可能影響,走向不同的路徑。

  • 回饋既有潛勢機制 檢討原有潛勢資料、影響範圍與監測需求。
  • 納入災後動態管理 評估新增的二次災害風險,提醒後續追蹤。
  • 移請權責機關處理 涉及道路、橋梁、河川、國有林地或私人土地時,通報相關機關協調處置。

慈峰這處坡地主要位於林班地,相關空拍成果也已提供林業及自然保育署南投分署參考。資料分享出去,讓不同機關在同一份基礎上各自判斷,也是承接的一種方式。

💡 追蹤不等於劃設,也不等於包辦治理

不安定土砂追蹤與土石流潛勢溪流劃設是兩套不同的制度。發現新的崩塌,不代表就要新增潛勢溪流;結束災後的額外追蹤,也不代表解除既有潛勢區的管理。我們負責的是持續掌握與評估,後續治理仍依各機關權責辦理。

・・・

06從風險資訊到地方防災行動

我們也記得 2025 年的馬太鞍溪堰塞湖。一場颱風後新生成的崩塌與堰塞湖,形成後已有監測與警戒作業,最後仍在溢流時造成花蓮光復地區 19 人死亡、5 人失聯。

這件事提醒我們,發現風險、持續監測、研判預警與地方落實避難,是不同但必須環環相扣的工作。前面任何一段做得再好,資訊沒有化為每一戶的行動,風險掌握就還不完整。

這也是我們把「從警報已發送到通知已確認」帶到總統盃黑客松提案的原因。我們想協助地方政府建立一套可運作的補位機制,在通知確認之後,接著掌握協助需求、安排人力派工、追蹤未完成的案件。要驗證的是整套流程,而不只是一個資訊平台能不能操作。

以黑客松補足已知防災缺口
從名冊維護到完成回報的五個步驟。目標是讓公所掌握還沒確認的個案,並逐步與自主防災社區銜接。
・・・

07少做重複的事,才能持續做重要的事

公部門人力逐年緊縮,我們必須以人力減少、增補機會不高作為規劃前提。前面談的分級追蹤、跨科承接與資料串接,本身也是為了這件事,讓有限的人力用在最需要的地方。

新增一項重點工作時,我們要求自己同步決定,哪些既有工作可以整併、降頻、延後或停止。工作只加不減,最後拖垮的會是最核心的任務。

因應人力減少,聚焦核心任務
人力有限時,更要明確決定哪些事情最重要、哪些做法需要改變。

我們也鼓勵同仁把 AI 當成一起想事情的夥伴。擬定新方法或評估原則時,帶著背景資料與初步構想反覆討論,問到依據、假設、反例與地方可行性都能說清楚為止,而不是問到 AI 同意自己。哪些判斷仍需由人負責,也要說清楚。

善用 AI 提升專業與工作品質
從提出問題、持續追問到檢視假設與反例,AI 是一起想事情的夥伴,討論結果仍由人查證、判斷與負責。

我們想留下的,不只是案件

從土石流潛勢溪流到大規模崩塌,再到每一次事件之後的新變化;讓一次現勘接上空拍與模型,讓一次調查接上分級追蹤,讓一則警報接上每一戶的確認。

這些想法,是同仁在一次次現勘、會議與災後檢討中慢慢累積出來的。我們給自己的願景是這樣寫的:

精進科技應用,強化公私協力,提升基層自主防災能量與永續韌性;融合技術、資訊及數據,落實歷年研究成果,並能隨時隨地取用。

過去二十多年,我們努力回答哪些地方可能發生災害。接下來,還要能回答新發現的風險由誰追蹤、如何處理、何時調整。

#坡地防災 #不安定土砂 #大規模崩塌 #動態風險管理 #公務員的日常

註一:本文所述慈峰產業道路個案,不預先判定其規模、危險程度及潛勢區認定結果,後續依調查結果與相關程序辦理。
註二:文中三種追蹤層級為本組嘗試中的管理構想,不代表現行已正式採行的分級制度。
註三:玉穗溪上游坡地變動歷程,參考農村水保署電子報第 98 期。
註四:馬太鞍溪堰塞湖傷亡數字,依立法院資料,統計至 2025 年 10 月 20 日。
註五:萬里溪崩塌發生時間之地動訊號分析,詳見本部落格 2026 年 6 月專文。
文中民國年份均已換算為西元年。

2026/10/13

【AI 時代的學習筆記】看得懂結論,說不出原理?請 AI 製作互動教材,破解 InSAR 這道抽象難題

AI 時代的學習筆記

看得懂結論,說不出原理?
請 AI 製作互動教材,破解 InSAR 這道抽象難題

工作上用 InSAR 監測大規模崩塌好一段時間,原理卻一直是一片空白。這次沒有翻開教科書,而是一題接一題問,看不懂就請 AI 畫成動畫。三天下來,問出了二十個問題和一個互動網頁。這中間發生了什麼事?

看不懂的地方,就請 AI 畫出來,畫到我懂為止。

01一頁簡報,問出一連串問題

事情從一頁簡報的結論開始。「面對衛星的坡面,回波訊號強,卻是坡向滑動較不敏感的地方。」手邊另有一份 Gemini 針對這句話的盲點分析,指出迎視坡會有前縮、疊置等幾何失真,原句容易讓人誤解。

兩邊各有道理,我想確認誰對,於是請 Claude 把它做成可以拖動參數的互動頁。結果有點意外。原句的結論其實站得住,順坡滑動同時往下,往下的分量會抵銷朝向衛星的分量。以入射角 39°、坡度 30° 計算,投影到視線上只剩約 16%。反倒是盲點分析裡「滑動朝向衛星時最敏感」的說法,只看了水平分量。

真正讓我停下來的是另一件事。我看得懂這個結論,卻說不出背後的道理。前縮是怎麼發生的?坡面上的點怎麼變成影像裡的像素?這些問題,我其實從來沒有真正弄懂過。

・・・

02做了這麼久,原理卻是空白

農村水保署大量使用 InSAR 做大規模崩塌的廣域監測。我看過很多委辦計畫的成果,也看過無數張彩虹干涉圖,卻一直沒有把原理從頭弄清楚。

不是沒有努力過。我讀過書、上網查過資料,也請教過委辦團隊與同仁。只是時間總是不夠,書上的文字描述很難讓人抓到精髓,附圖也不見得看得懂該怎麼解讀,再加上自己基礎知識的不足。想要有人一步一步帶著學,現實上很難,別人未必有那個時間和耐心。過去也試過用 AI 問,但都是問一兩句就停,從沒有從頭到尾好好讀過、持續追問。

💡 書上的圖為什麼難懂

靜態的圖只畫出一個情境。坡度變陡會怎樣、換成降軌會怎樣,讀者只能在腦中想像。很多觀念卡住,不是因為圖畫錯,而是沒辦法動手改一個參數,看看什麼跟著改變。

・・・

03從第一個問題開始追問

這次剛好遇上國慶日三天連假,我決定換個方式。不急著讀完一本書,而是把每一個看不懂的地方都問到底,每個答案再引出下一個問題。回頭看這三天的提問,幾乎是一條完整的學習路線。

📌 連假期間實際問過的問題(節錄)

「兩條等斜距線」是什麼意思?

雷達衛星到底怎麼拍照,跟光學衛星有什麼不一樣?

Sentinel-1 一次脈衝照亮多大的範圍,經過台灣時是東西向還是南北向的長條?

每一格像素就是一次脈衝嗎?要等回音回來才發下一個嗎?

衛星離地面到底是 700 公里還是 850 公里?

常聽到的「解析度 10 公尺」又是怎麼回事?

彩虹圈要怎麼看?地震後的干涉圖為什麼不是圓的?

其中有幾題,換作當面請教別人,我大概問不出口。一個已經做了很久的人,再問「每一格像素是不是一次脈衝」,多少會有顧慮。對 AI 就沒有這層包袱,同一個觀念可以問第三次、第四次,直到真的懂為止。

・・・

04看不懂,就請它畫出來

文字解釋看了還是不懂時,我就請它畫成動畫或互動頁,讓我自己操作。這是這次最關鍵的轉變。

第一個開竅的時刻,是光學與雷達的對照。光學衛星像照相機,靠「方向」決定地物落在影像的哪裡。雷達衛星沒有鏡頭可以分辨方向,它發出脈衝,再依回音抵達的先後把地物排進格子,所以影像的橫軸其實是「離衛星多遠」。

光學衛星與雷達衛星成像方式的比較動畫
山腳 B 與山頂 C 離衛星幾乎一樣遠,回音同時抵達,只能擠進同一格。前縮與疊置的源頭就在這裡。

第二個是脈衝的時間。我原本以為衛星要等回音回來,才會發下一個脈衝。動畫算給我看,脈衝來回約需 5.7 毫秒,每 0.6 毫秒就發射一次,所以空中同時有九、十個脈衝在飛。第 1 次脈衝的回音,落在第 10 與第 11 次發射之間的空檔。

脈衝發射與回音接收的時間動畫
上半部是空間,下半部是時間。一批回音只持續約 0.3 毫秒,剛好塞進兩次發射之間,所以不會混淆。

第三個是迎視坡怎麼變成影像。把坡面上等間距的點,依離衛星的遠近丟進一格一格的像素,前縮、疊置、陰影就直接看得見。坡度一調過入射角,山頂的點跑到山腳前面,和平地的點混在同一格。

坡面點落入像素格的互動圖
紅色格子裡同時有綠點與橘點,代表不同地方的回音混在一起,這一格的相位已經無法單獨解讀。
・・・

05我也抓到它畫錯的地方

這個過程並非一路順利。我陸續發現好幾處不對。衛星圖示的天線方向畫反了,說明寫「長邊順著飛行方向」,圖卻是橫擺。彩虹圈的剖面圖,明明是下陷的案例,畫出來卻像隆起。第一版的雷達動畫只畫了脈衝出去,沒畫回音回來,偏偏「回音抵達時間」才是成像的關鍵。前後文也出現過 700 公里與 850 公里兩種說法,追問之後才弄清楚,一個是軌道高度,一個是斜距。

這些錯誤有個共同點,都是在可以操作的圖上被我看出來的。文字裡的小錯容易滑過去,畫在圖上就藏不住。能指出哪裡畫錯,某種程度也說明我真的懂了。

⚠️ 使用這個網頁前要知道的事

頁面中的數值多是依 ESA 公開規格估算的量級,模擬也採用簡化模型,目的是說明觀念。實際分析請以影像參數檔、正式文獻與專業團隊的判斷為準。AI 會出錯,這份教材也經過我一路挑錯修正,難免還有疏漏,歡迎指正。

・・・

06十個單元,二十個問題

最後,我把這三天弄懂的重點整理成一個互動網頁,放在 GitHub 上。前三個單元講雷達怎麼成像,接著是前縮、疊置、陰影與視線敏感度,再來是干涉圖的判讀、振幅影像在崩塌與淹水上的應用,最後一個單元是地震後的干涉圖。每個單元都可以拖動參數或播放動畫。第 11 個單元把我實際問過的二十個問題整理成常見問題。

10個互動單元
20個實際問過的問題
2.8 cm彩虹圈一圈代表的位移
約 9 個同時在空中飛的脈衝
彩虹圈判讀的互動模擬
拖動位移量,圈數跟著增減。下方剖面把彩虹圈還原成地表的下陷形狀,一圈對應 2.8 公分。
水平錯動斷層的模擬干涉圖
斷層兩側一側靠近、一側遠離衛星,條紋沿斷層拉長,兩側色序相反。把走向轉成南北向,條紋會明顯變少,這是台灣許多斷層的觀測限制。

網址在這裡:https://cychen59.github.io/insar-intro/。對我自己而言,這是一次從無到有掌握知識的經驗。我踩過的坑、曾經不理解的地方,相信對剛接觸 InSAR 的人也會有幫助。

・・・

07學習方法正在改變

這次經驗讓我體會到,AI 時代的學習方式需要調整。不一定每次都要讀完一本完整的教科書。遇到問題,透過提問一步一步拆解,反而更快掌握核心。

更重要的是,AI 不只會回答,還能把複雜的概念做成工具。脈衝怎麼在空中交錯、相位怎麼變成顏色、斷層錯動為什麼畫出蝴蝶狀的條紋,這些用文字很難說清楚的東西,做成可以操作的畫面後,理解的速度完全不同。

不過這有幾個前提。要願意持續追問,不懂就說不懂。要動手操作,而不是看完就算。要對答案保持懷疑,看到怪的地方就指出來。還有,問題本身來自工作中累積的困惑,多年看報告、審成果的經驗,讓我知道該問什麼。AI 補上的是解釋與視覺化,判斷仍然要靠自己。

從看得懂結論,到說得出原理

從一頁簡報,到二十個問題。從翻不完的書頁,到可以拖動的滑桿。從不好意思再問一次,到一路問到真正弄懂。這三天最大的收穫,或許不是那個網頁,而是換了一種學習的方法。

看不懂的地方,就請 AI 畫出來,畫到我懂為止。

#InSAR #合成孔徑雷達 #大規模崩塌 #AI學習 #Sentinel1

互動網頁:InSAR 入門圖解(2026 年 10 月製作,以 Claude 協助設計與撰寫程式)。
參考資料:ESA Sentinel-1 使用者指南(IW 觀測模式、GRD 產品規格)、Copernicus Sentinel-1 星系調整公告。
註:文中脈衝間隔、回音時間、像素尺寸等數值為依公開規格估算的量級,實際值依各景影像參數檔而定。模擬圖採簡化模型,僅供觀念說明。

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 邊坡穩定分析免費網頁版一鍵解決

2026 年 11 月更新
SSA 已加入 Spencer 法與 Morgenstern–Price 法、控制點與反算、分層水壓、坡外積水與張力裂縫、抑止樁、擋土牆外部穩定、多情境檢核與 Word/PDF 計算書,並有中、英、日文使用手冊與教學影片。本文第 05 節的部分限制已不再適用,新功能請見〈邊坡已經在動,接下來怎麼算〉。

工具介紹・邊坡穩定分析

不必先猜滑動面在哪裡
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 上,歡迎回報問題或提出改進建議。

📌 功能更新

已加入土釘、地錨與擋土牆,補強後的臨界滑動面一樣由動態規劃自動搜尋,畫面上還會列出有無補強的安全係數對照。 另外可以設定坡頂或坡趾的均布、梯形與線載重,含薄弱夾層的邊坡也能沿弱面準確找出破壞面。

📌 引用本程式

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

陳振宇、藤田正治、堤大三(2014),「基岩位置及土層特性對降雨逕流與大規模崩塌之影響」,中華水土保持學報,45(4),pp.243-256。

Chen, C. Y., Fujita, M., and Tsutsumi, D. (2014). "The Influence of Bedrock Location and Soil Characteristics on Rainfall-Runoff and Large-Scale Landslides." Journal of Chinese Soil and Water Conservation, 45(4), 243-256. (in Chinese)

・・・

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