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 上,歡迎回報問題或提出改進建議。

📌 功能更新

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

📌 引用本程式

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

陳振宇、藤田正治、堤大三(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
本文為作者個人觀點。

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。

相關工具