【知識管理】每週十幾篇論文、和 AI 討論出的結論，我把它們放進同一個知識庫

研究方法・知識管理

每週十幾篇論文、和 AI 討論出的結論
我把它們放進同一個知識庫

論文讀過會忘，和 AI 討論出的結論沉在聊天紀錄裡。這兩種知識原本各放各的抽屜，接在一起之後，它們開始互相對照。

知識管理的價值不在存下多少，而在下次需要時，找得回當初的判斷，也找得到它的根據。

01一篇論文，自己找到了過去的那場討論

這個月開始我嘗試想恢復研究生活。ChatGPT 與 Gemini 每週替我找來 5 到 10 篇山崩與土石流的新論文，我挑過之後匯入書目軟體Zotero，再交給 Claude Code 讀全文、寫筆記。

某一次入庫的論文，是一篇用遺傳演算法回推埋藏滑動面的預印本，研究區是小林村與台 7 線。Claude Code 交回的整理報告最後多了一句：這篇可以對照「警戒模式及發布機制」這個主題。

「警戒模式及發布機制」這個主題不是論文。那是我先前和 AI 反覆討論工作時，整理下來的決策與洞見。我沒有要求 AI(Claude Code)去比對，它是在依規則建立連結的過程中，自己發現兩邊談的是同一件事。

學術文獻和工作上的判斷，第一次在同一個地方碰面。這篇文章想分享的，就是讓它們碰得到面的這套做法。

・・・

02過去的兩個抽屜

論文這一側的問題很典型。每週的清單躺在信箱，PDF 散在下載資料夾，摘要讀過就忘。要寫文獻回顧時，參考文獻得一筆一筆排，請 AI 代勞又怕它編出不存在的文獻。

AI 對話這一側，我今年 9 月寫過一篇「 不再讓 AI 對話停在聊天室：我用 Obsidian 建立半自動知識歸檔 SOP」的Blog文章。做法是把定稿的對話拆成決策、洞見、參考資料三個檔案，存進 Obsidian，逐字稿另外保留原文。那套方法讓結論不再流失，每一則洞見都能回查原始討論。

但兩個抽屜之間沒有通道。討論裡提到的論文只是一行文字，查證狀態永遠停在「待查證」；論文裡能支持或推翻我判斷的證據，也連不回那場討論。缺的不是更多工具，而是一個能讓兩種知識互相指認的結構。

・・・

03一套架構，三個工具各守一層

這套做法的概念來自今年 4 月 Andrej Karpathy 公開的 LLM Wiki 構想：讓 AI 持續維護一個 Markdown 知識庫，替資料寫摘要、建立交互連結、定期檢查矛盾。我把它落實成三層分工。

Zotero 保管論文 PDF 與書目，外掛 Better BibTeX 給每篇論文一個固定代碼，稱為 citekey，例如 wang2024deep。Obsidian 是知識庫本體，所有筆記都是一般文字檔。Claude Code 則依照一份寫好的規則檔，負責讀論文、寫筆記、建連結。

中間那一排才是人要做的事，只有篩選、匯入與判斷三處。其餘交給排程與 agent。

📌 整套系統只靠三個原則撐住

原文不改寫。PDF 與對話逐字稿永遠保留原樣，摘要和筆記另外存放。

citekey 是唯一的引用依據。citekey 只由 Zotero 產生，AI 不得自己編，也不得依標題猜 DOI。

判斷留給人。AI 的推論一律標成「LLM 歸納，待確認」，我的看法寫在它不能修改的區塊。

・・・

04讓兩種知識接上線的，是「概念頁」

論文和討論要互相連得起來，靠的不是把它們放在同一個資料夾，而是中間多了一層概念頁。例如「降雨誘發預警」「模型驗證策略」「土石流溢淹範圍劃設」，每個概念一頁，由 Claude Code 維護。這一層要成立，靠三個條件。

其一，論文入庫時，Claude Code 讀全文寫筆記，重要發現附上頁碼，再把這篇掛到相關的概念頁，並標明它和其他論文的關係是支持、反駁、延伸，還是方法不同。

其二，和 AI 討論出結論時，歸檔技能會在每則洞見後面附上「相關概念」。連結時，這則洞見的原句會被引用到概念頁的「使用者判斷」區塊，一個字都不改。

其三，概念頁裡每一句話都標明出處，分成文獻主張、使用者判斷、LLM 歸納三種。打開一頁，就能分辨哪些是論文說的、哪些是我自己下過的判斷、哪些只是 AI 的推論。

左側同時列著工作討論的主題，例如大規模崩塌監測資源配置、尼泊爾洪災的災害鏈管理，也列著論文的概念頁。兩種知識第一次排在同一棵樹上。

Obsidian 的反向連結會把這些關係變成雙向。從論文筆記點得到概念頁，從我過去的工作洞見，也看得到哪幾篇新論文正在支持或挑戰它。

💡 寫文獻回顧時，AI 為什麼編不出假文獻

草稿裡 Claude Code 只能寫 [@citekey] 這種標記，而且只能用書目檔裡真的存在的代碼。參考文獻清單由 Pandoc 依 APA 格式自動產生，再用一支小程式比對每個代碼。AI 沒有機會自己寫出任何一筆書目。

・・・

05判斷留在人手上

第一批入庫的論文裡，有一篇用居民通報資料訓練預測模型，R² 高達 0.98。Claude Code 在筆記裡寫下一個疑點：同一筆通報可能被半徑內多處邊坡共用，隨機切分時會同時出現在訓練集和測試集。它把這段標成「LLM 歸納，待確認」，沒有替我下結論。

後來試寫文獻回顧，它停下來問我，要不要把這篇標為品質有疑慮。我選擇先不標，讓這個推論以「推論」的身分留在草稿裡，等我自己讀過原文再決定。

兩篇論文對 NDVI 的結論看似相反。它記下了矛盾，也註明兩篇的災害類型、尺度與統計方式都不同，未必真的衝突。

篩選論文也是同樣的道理。AI 每週送來的清單，我先看摘要再勾選入庫。篩的是相關性與品質，不是觀點和我一不一致。挑戰我既有看法的論文要留下來，寫文獻回顧時它們最有用。

這套系統最重要的設計不是自動化，而是把「這句話是誰說的」標清楚。

・・・

06跑完第一輪的實際情況

從安裝到寫出第一份文獻回顧草稿，前後大約三天。目前的規模還很小，但每個環節都實際跑過一次。

11第一輪入庫的論文（篇）

8自動建立的概念頁（頁）

6試寫文獻回顧引用的論文（篇）

1每週例行作業所需時間（小時）

試寫的文獻回顧分成 6 節，引用 6 篇論文，代碼檢查全數通過，轉成 Word 後參考文獻也自動排好。比較讓我放心的是它最後附上的待確認清單，把只讀過摘要的引用、只有單一來源的論點、LLM 歸納的段落分三類列出來，這正是定稿前要逐一處理的地方。

它會主動說出讀不到的地方。這篇 PDF 有三頁沒有文字層，它沒有自己猜，而是在筆記裡註明。

⚠️ 第一輪沒有想像中順利

指令參數順序寫錯、登入指令打錯、轉檔軟體明明裝了卻找不到，這些都實際發生過。付費期刊的 PDF 大約三到五成要手動補，Claude Code 的選單介面也只有英文。

更重要的是，11 篇論文寫出的草稿，多數論點只有單篇支撐。這套系統不是開關，而是累積。論文到二、三十篇，討論主題到幾十個，概念頁之間的關係才會真正長出來。

過程中遇到的每個問題，我都整理進一本 41 頁的操作手冊，從安裝、每週例行作業到常見問題，讓沒有接觸過這些工具的同事也能照著做。

📌 下載操作手冊與研究庫骨架

手冊從安裝講到每週例行作業，附實際操作截圖與 32 個常見問題。研究庫骨架解壓縮後，資料夾、Claude Code 規則檔與每週指令都已設定好。

⬇ AI 文獻研究庫操作手冊（PDF）41 頁・A4 ⬇ 研究庫骨架_v2.zipObsidian 研究庫範本與設定檔

・・・

07它做不到的事

把邊界講清楚，這套方法才用得久。

它不能取代閱讀。筆記寫得再完整，精讀與判斷仍然要自己來。AI 寫的文獻回顧只是起點，用詞、論述取捨與結論都必須是自己的，投稿前也要確認期刊對 AI 輔助寫作的揭露規定。

它不適合放機敏資料。知識庫的內容會送到雲端模型處理，未公開的內部報告、個資與審查中的資料，應該留在另一個不上雲的地方。

它挑論文的眼光有限。我曾想要求 AI 只收高影響係數的期刊，後來發現 AI 查不到正確的 IF 值，坡地災害領域的核心期刊 IF 也普遍不高。最後改成給它一份期刊分層清單，加上單篇品質條件，再由我做最後一關篩選。

中文文獻的書目格式目前還要手動調整。

兩個抽屜，合成一棵樹

從散落在信箱的論文清單，到每篇附頁碼的筆記；從沉在聊天紀錄裡的結論，到能被新論文支持或挑戰的洞見；從各自獨立的兩個抽屜，到同一張關係圖。

知識管理的價值不在存下多少，而在下次需要時，找得回當初的判斷，也找得到它的根據。

#知識管理 #Obsidian #Zotero #ClaudeCode #文獻回顧

相關文章：AI 對話知識庫整理 SOP（2026 年 9 月）。
系統建置與試運行時間為 2026 年 11 月，文中數字為第一輪試運行結果。LLM Wiki 構想出自 Andrej Karpathy 於 2026 年 4 月公開的說明文件。使用工具：Zotero、Better BibTeX、Obsidian、Claude Code、Pandoc。

【2026總統盃黑客松】警報發出了，還有誰沒被通知？ 從「警報已發送」，走向「通知已確認」

2026 總統盃黑客松・不漏一戶行動隊

警報發出了，還有誰沒被通知？
從「警報已發送」，走向「通知已確認」

馬太鞍溪堰塞湖溢流的 19 位罹難者，全都住在事前公告的疏散範圍內。警報發了，範圍也畫了，卡住的是最後那一步。我們想補上的，就是這一步。

防災的最後一哩，不只是一則訊息，而是有人敲開那扇門。

今年總統盃黑客松，我們「不漏一戶行動隊」走到了 11 月 11 日的決審，最後沒有進入五組卓越團隊。比賽結束了，但這份提案處理的問題還在。這篇文章把決審簡報與一分鐘的實地演練影片完整整理出來，希望能讓更多在第一線做防災的夥伴看見。

01警報已發送，然後呢

2025 年 9 月 23 日下午，花蓮馬太鞍溪上游的堰塞湖在樺加沙颱風期間溢流，洪水夾帶泥沙沖進光復鄉市區。這場災害最後造成 19 人死亡、5 人失蹤。

在整理資料時，有三個數字讓我們停了很久。19 位罹難者平均年齡 78 歲。其中 15 位住在一樓平房。而且全部都住在事前公告的疏散範圍內。

也就是說，這不是一場沒有預警的災害。風險區畫出來了，細胞廣播也發了。問題出在警報發出之後的那段距離。山區可能收訊不穩、長輩不一定有或會操作智慧型手機，就算收到了細胞廣播，也不代表能夠理解訊息想傳達的風險及後續的防災作為。更遺憾的是，地方基層人力不足，未必有人能特別針對這些防災弱勢戶去逐戶確認並協助疏散。

從警報發出到真正撤離，中間至少隔著三道關卡。現行系統能確認的只有第一道。

💡 這篇文章不討論的事

馬太鞍溪事件的責任歸屬仍在司法程序中，本文不做評論。我們關心的是一個制度層次的問題：警報從「已發送」到「已確認」之間，目前沒有一套工具可以告訴指揮者，還有哪一戶沒有被找到。

・・・

02體系不缺警戒，缺的是把資訊變成行動的人手

臺灣現行的防災機制分工其實很清楚。中央負責更新潛勢資料、監測並適時發布警戒。地方負責更新保全住戶清冊、執行疏散撤離與安置。

卡住的地方在基層。區公所、村里長和第一線防災人員業務繁重，人力本來就不足，承辦人流動率又高，經驗很難傳承。警戒一發布，最常見的作法仍是一份紙本清冊加上電話和 LINE 群組。依名冊順序一通一通撥，電話沒接就斷了線索，現場回報散落在群組裡被洗版，公所得自己人工重整、重新派人。

📌 我們的定位

不是取代既有的防災體系，而是補上它的執行缺口。防災成敗的關鍵，在於讓「資訊」落實為「行動」。

工作坊時評審曾問我們：「就算沒進決賽，你們也會繼續推嗎？」 其實，這題最大的難度就在「跨部會」。在現行體制下，若沒有總統盃黑客松「卓越團隊」的光環與政策推力，單一機關要推動這種高難度的跨部會整合，現實上非常艱難。即便如此，我們仍想全力一試，因為這份提案不是為了自己，而是為了替第一線辛苦的鄉鎮市區公所同仁分擔勞苦，讓疏散避難更有效率、減少傷亡。

之所以用土石流與大規模崩塌當案例，只是希望從真實的場域與資料出發，更貼近第一線的實際需求。同一套任務管理機制，也能延伸到淹水、地震等其他災害。

・・・

03把警戒，變成有人負責的逐戶任務

我們提出的「防災弱勢戶通報覆蓋確認與智慧派工平台」，核心只有一句話：未完成，不結案。平台把既有警戒、地方名冊與可用人力串起來，拆成四個步驟。

• 鎖定對象。把警戒範圍和地方名冊比對，再用 3D 建物樓層資料篩出影響範圍內「只有一樓」的弱勢戶，列為優先通知對象。這一步直接回應了馬太鞍溪罹難者多住在一樓平房的教訓。
• 智慧派工。依風險等級、道路通阻和志工距離，建議派工組合，再由地方窗口確認與調度。
• 通知確認。由防災專員與志工以電話或到府通知，確認住戶狀況並回報。志工只負責通知與確認，疏散撤離涉及公權力，仍由村里長、警消與區公所人員執行。
• 追蹤補位。聯繫未果或人力不足的案件不會消失，會被補派或調整任務，直到完成。

第四步拉回第一步的那條箭頭是整個設計的重點。沒有聯繫上的住戶會重新進入任務佇列，而不是停在某個人的待辦清單裡。

真正操作這套系統的是區公所和志工，弱勢長輩不需要學任何新的 App。我們也希望平時就建立固定志工與保全住戶的服務關係，災時優先由熟識的人上門，避免陌生人突然來敲門造成困擾。科技在這裡負責管理任務與補位，不取代人與人之間的信任。

弱勢戶資料涉及個資，所以平台採最小必要揭露。志工只看得到自己負責任務所需的資料，拿不到完整清冊。應變啟動才解鎖，任務結束即取消查閱，系統留存處理軌跡而不留個資。山區常斷訊，前端也支援離線快取。

對區公所來說，這一切最後收斂成一張地圖。哪些住戶還待確認、沒完成的原因是什麼、要派誰去補位，在同一個畫面上就能看見。每次回報都會留下紀錄，回饋到下一次任務。

以甲仙區西安里為例的應變總覽。指揮者看的不是「發了幾則訊息」，而是「還剩幾戶沒確認」。

💡 為什麼不直接用 LINE 加 Google 表單

這是準備決審時，我們自己最先想到的質疑。LINE 可以通知，表單可以回報，地圖可以標位置，但三者各自分散，最後還是要承辦人重新彙整，才知道哪幾戶還沒完成。平台不是取代 LINE，而是把住戶、人員、任務狀態和異常案件串在一起，減少工具之間的斷點。

即使拿掉 3D 建物和智慧派工這些進階功能，任務派送、現場回報、異常接續和未完成列管這幾項核心仍然成立。更複雜的 AI 派工，要先證明比簡單規則或人工判斷更好，才值得投入。

・・・

04甲仙，10 月 29 日

提案要能落地，就得放到真實的山區去試。我們選了高雄市甲仙區。這裡山區地形複雜、環境脆弱，是土石流災害的重點防災區域。

17 條土石流潛勢溪流

31 戶高風險弱勢住戶

16 位土石流防災專員

9 位演練動員志工

整個驗證分三次推進。10 月 14 日展示系統雛形，與中央、地方及民間夥伴一起討論作業流程與分工。10 月 16 日在甲仙區公所把實際操作情境走過一遍，驗證通知、回報與調度流程。10 月 29 日正式實地演練，模擬警戒啟動並派送志工任務。平台納入甲仙 31 戶高風險弱勢住戶的資料，實際到府測試則以大田里的指定住戶進行。

時間點的設計很關鍵。逐戶通知原則上安排在土石流黃色警戒階段，也就是風雨還沒來的時候。這時道路和通訊大多正常，志工也不必冒險出門。我們不希望志工在風雨中才去敲門。

演練從陸上颱風警報發布開始。公所承辦先確認當天有哪些志工和防災專員能投入支援。志工不用另外安裝新的 App，收到 LINE 就能回覆能不能出勤。人力確認後才啟動任務，任務和路線再送回每個人的 LINE。

先確認今天「真的」有誰能出動，再派任務。

用第一線早就在用的工具，降低災時的學習成本。

影片裡最關鍵的一幕發生在住戶家門口。防災專員告訴長輩，這裡已經發布土石流黃色警戒，要帶他去安全的地方。長輩回答腳在痛，沒辦法走。專員沒有在現場卡住，而是當場回報，請公所派人支援。在過去，這句話可能就留在專員的記憶裡，或沉在某個群組的訊息底下。這也是刻意設計的分工。第一線負責通知、確認和發現問題，後續的撤離協助與救護，由公所依權責調度。

甲仙 10/29 實地演練，一分鐘影片。結尾是區公所的應變總覽畫面，誰還沒確認、誰正在處理、誰需要幫忙，一目了然。

演練後，甲仙區公所給了很實在的回饋。他們認為地圖容易看懂，資訊集中在一處，有助於掌握現場。但也點出一個問題。派工之後如果志工遲遲沒有回報，公所很難判斷該繼續等，還是另外派人。我們因此規劃逾時提醒，志工接單後 20 分鐘沒有進度就主動提醒，仍無回應再由公所電話確認，而不是讓系統自動改派。沒有回報不代表沒有執行，也可能是現場正在處理。這項功能目前仍在規劃階段。

・・・

05現場永遠跟名冊不一樣

這次演練刻意放進三種突發情境。它們都不是想像出來的，而是第一線夥伴最常遇到的狀況。

• 原本答應幫忙的志工臨時有別的任務，無法前往。平台即時掌握，任務重派給其他人。
• 志工到了保全住戶家，發現家裡還有另一位弱勢者需要救護車載送。回報區公所後，啟動後續協助。
• 志工在路上發現道路中斷，無法通行。即時回報障礙，公所重新調度路線與人力。

三種情境的共通點是名冊上都看不出來，只有走到現場的人才會知道。

這是整場演練最大的收穫。現場狀況常常跟原本掌握的資訊不同。平台的價值不只在派工，而是讓這些變化即時被看見、留下紀錄，再由區公所接手處理，而不是停留在某一位志工或承辦人身上。

這裡也有一條必須分清楚的界線。通知完成，不等於撤離完成。如果長輩聽懂了警戒，卻堅持不走，通知這一步可以記為完成，撤離卻不能跟著結案。志工把拒絕撤離、行動不便或需要救護的狀況回報上來，由公所列管，再依權責處理。

讓科技幫助人，守住最後一戶。

・・・

06前後對照，以及這張表沒有說的事

我們把導入平台前後的差異整理成四個面向。優先順序從「依名冊順序撥打」變成「一樓平房弱勢戶優先派工」。覆蓋確認從「電話沒接就斷線」變成「31 戶狀態全部可視化，未完成不結案」。突發狀況從「散落在 LINE 群組」變成「三種預設情境都能即時接手處置」。業務交接從「仰賴資深里長和承辦的個人經驗」變成「防災專員、志工清冊和處理歷程結構化留存，新進人員也能接手」。

這張表呈現的是指定情境下的流程可行性。通知覆蓋率和人力效率是否真的提升，要靠下一階段的比較試辦來回答。

⚠️ 決審前，我們先問過自己的問題

準備決審時，我們替評審擬了 20 道可能的提問。其中幾題，到現在仍是這套平台最誠實的邊界。

• 「不漏一戶」做得到嗎。不能保證。完成率只代表已納管住戶的任務進度。名冊外的獨居長者或行動不便者，要靠志工在現場發現、回報，再由公所查證更新清冊。不漏一戶是努力的目標，不是已經達成的宣稱。
• 人力不夠，平台幫得上忙嗎。平台無法憑空生出志工。它能做的，是讓公所及早知道誰能出勤、哪些住戶最急、哪些任務還沒人負責，缺口才不會到最後一刻才被發現。
• 會不會變成究責工具。平台不改變中央與地方的權責。未完成紀錄是為了及早協助，而不是追究誰沒做到。如果大家只追求漂亮的完成率，真實的困難就不會被回報。
• 個資被截圖怎麼辦。關閉權限擋不住截圖外傳。正式推廣前，必須先建立個資管理、事故通報與權責分工。
• 系統斷了怎麼辦。防災不能只靠單一系統。平台故障時，電話、無線電和紙本仍是備援。擴大前也要先做壓力測試與故障演練。

平台也有它管不到的事。如果警戒發布的時機、撤離範圍的判斷本身出了問題，再好的派工系統都補不回來。它處理的是警報發出之後的那段路，前面那一段仍然要靠監測、研判與決策。

我們不是讓政府更早發布警戒，
而是讓警戒發布之後，還沒被通知、還需要協助的住戶，
能及早被發現，並且有人接手。

・・・

07沒有進入五強之後

今年總統盃黑客松由農業部承辦，主題是「智慧農業 安全永續」，我們的提案歸在「安心社會」構面。11 月 11 日決審選出的五組卓越團隊，分別是處理詐騙終端攔截與人頭帳戶的「神鬼交鋒」、守護穿山甲避免被路殺的「鯪鯉共好」、整合跨域資料預測脆弱兒少風險的「Swan Radar」、打造循環衣物體系的「循環衣流」，以及用無人機即時送出 AED 的「隨機應電」。

每一組都非常優秀，值得我們學習。仔細看會發現，好幾組其實在回答跟我們相同的問題。資料與科技能不能在對的時間，找到那一個最需要幫忙的人。這也讓我們更確定，「不漏一戶」想解決的問題是有價值的。

比賽只是一個過程。我們在提案時規劃了一條三階段的路。第一階段讓平台正式上線，從甲仙擴散到其他坡地高風險地區。第二階段納入地方災害應變中心的標準作業程序之一。第三階段透過與 EMIC 全國防救災系統介接，成為國家級的常態工具。核心機制以共通任務管理為基礎，可以從坡地災害延伸到淹水、地震等情境。平時也能用在弱勢關懷、健檢與物資派送，讓名冊在不是災害的日子裡持續更新。

這份提案未來的推動，無法單靠農業部來執行。通報與疏散撤離牽涉的權責很廣，需要跨內政部及許多單位，中央與地方一起協作，才有可能繼續往下走。

謝謝每一位夥伴

這份提案從一開始就不是一個單位能完成的。謝謝農村水保署、內政部消防署、內政部國土測繪中心、國家災害防救科技中心、國立高雄大學災防科技研究中心、甲仙區公所、紅十字會新高雄分會、慈濟，以及準線智慧科技的每一個夥伴們。從潛勢圖資、3D 建物與人口資料、平台開發，到第一線的到府關懷與通報，每一塊都少不了。

中央供應資料與平台，地方主責調度，民間人力補位。這張圖本身就是我們想推的治理模式。

也特別謝謝甲仙的土石流防災專員、慈濟與紅十字會的志工，以及願意打開家門配合演練的居民。這段時間跟大家一起腦力激盪、跨領域合作，我自己真的學到非常多，這是這次參賽最大的收穫。有大家一起打拼，真好。

📌 決審簡報與演練影片

完整的 8 分鐘決審簡報（PDF）和甲仙一分鐘演練影片都放在這裡，歡迎下載參考。若你的單位也在處理弱勢戶通報，很希望聽聽你的經驗。

下載決審簡報 PDF 觀看一分鐘演練影片

從「警報已發送」，走向「通知已確認」

從一份紙本清冊到一張即時更新的地圖，從電話沒接就斷線到未完成不結案，從老承辦腦中的經驗到新進人員也能接手的紀錄。比賽結束了，這件事還沒有。

防災的最後一哩，不只是一則訊息，而是有人敲開那扇門。

#不漏一戶 #防災弱勢 #總統盃黑客松 #土石流防災 #公私協力

資料來源：不漏一戶行動隊 2026 總統盃黑客松決審簡報（2026 年 11 月）、甲仙區 10/29 實地演練紀錄；總統盃黑客松官網；馬太鞍溪堰塞湖傷亡數字依決審簡報（19 人死亡、5 人失蹤）。
註：甲仙演練數據為單次演練結果，不代表實際災時成效。未來發展為提案規劃，實際推動仍依相關程序辦理。

【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° 低。

曲線上每一點都讓 Fs 等於 1。一條崩塌面只能決定一條曲線，c′ 與 φ′ 要固定其中一個，或用兩條以上的崩塌面交會。

⚠️ 反算值的前提

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

・・・

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

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

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

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

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

・・・

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

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

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

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

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

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

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

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

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

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

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

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

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

01現勘之後，那處邊坡交給誰？

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

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

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

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

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

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

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

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 日至 9 月 30 日的衛星影像依序播放。紅框內坡面裸露的範圍逐期擴大，坡頂開裂處的擾動也越來越明顯。（影像來源：農村水保署 BigGIS）開啟BigGIS 2026/10/5 空拍正射影像

8 月以前位移緩慢累積，9 月之後明顯加速。值得注意的是，9、10 月的降雨已大幅減少，滑移卻仍持續增加。

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

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

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

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

資料治理由專責單位統籌，各業務單位維護內容，資訊單位支援系統與資安。底層的資料整理做紮實，上層的分析與決策才站得穩。

📌 資料存得下來，只是開始

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

・・・

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

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

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

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

• 案件承接　每個追蹤個案都有明確的主責窗口與處置狀態，不依賴最初接獲通報的那個人。
• 專業分工　各科依業務共同提供評估、監測、資料與應變支援，而不是把責任集中在某一科。
• 持續檢討　案件定期更新，依風險變化調整追蹤層級與後續處置。

發現異常之後的五個環節，以及四個科如何在其中相互支援。分工是為了讓專業有人負責，不是單向移交。

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

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

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

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

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

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

・・・

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

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

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

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

從名冊維護到完成回報的五個步驟。目標是讓公所掌握還沒確認的個案，並逐步與自主防災社區銜接。

・・・

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

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

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

人力有限時，更要明確決定哪些事情最重要、哪些做法需要改變。

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

從提出問題、持續追問到檢視假設與反例，AI 是一起想事情的夥伴，討論結果仍由人查證、判斷與負責。

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

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

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

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

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

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

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

【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 星系調整公告。
註：文中脈衝間隔、回音時間、像素尺寸等數值為依公開規格估算的量級，實際值依各景影像參數檔而定。模擬圖採簡化模型，僅供觀念說明。

【AI工作流】從隨興寫扣到可維護的開發：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 設定不同。文中的治理做法與心得為作者對課程的整理與延伸。

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

AI 工具・日常協作

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

把偏好、背景與成果對象說清楚，讓 AI 更容易接住你的需求。

2026年10月10日@大崩AI工具

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

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

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

圖｜四個合作原則與兩種使用情境：需求清楚就直接產出，還沒想清楚則先口述、歸納，再提問補缺。

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

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

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

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

• 用 Gemini 筆記本建立專屬專案工作區
• ChatGPT 專案不是另一個資料夾
• 先用好 ChatGPT 專案，再談 Skill：用對話建立可靠的 AI 工作流

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結語：四個原則，依需要搭配

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

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