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

AI 工作流・Gemini Spark

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

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

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

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

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

先把核心架構擺出來

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

1

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

2

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

3

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

4

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

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

STEP 1

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

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

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

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

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

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

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

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

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

例如原本只會建立：

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

我改成：

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

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

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

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

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

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

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

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

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

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

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

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

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

STEP 2

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

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

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

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

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

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

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

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

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

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

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

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

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

⚠️

只測一次，不存 Skill

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

⚠️

沒有指定顯示名稱規則

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

⚠️

完全不做確認

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

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

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

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

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

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

先實測一次

把規則講清楚

指定顯示名稱格式

存成 Skill

之後直接拍照

把時間留給更重要的事

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

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

Gemini Spark Google Contacts Skill AI Agent

【防災對策】世紀大崩塌後的漫長治水路：從日本常願寺川百年砂防，看花蓮馬太鞍溪的未來

流域治理・砂防專題

世紀大崩塌後的漫長治水路：從日本常願寺川百年砂防，看花蓮馬太鞍溪的未來

堰塞湖消失不是終點；真正的挑戰，是未來要如何管理上游 2.4 億方不安定土砂。

日本常願寺川花了一百多年，才把一場大崩塌留下的巨量土砂風險逐步變成可管理的系統。馬太鞍溪不需要複製日本的工程，但需要讀懂日本治理的時間尺度與先後順序。

📁 馬太鞍溪災後治理🌏 台日砂防案例對照🗓 資料更新至 2026 年 7 月

2025 年 9 月馬太鞍溪堰塞湖溢流潰決後，真正留下來的問題，已不只是「那座湖還在不在」。到了 2026 年，堰塞湖蓄水風險雖已降低，但壩體、崩塌區與中上游河道仍約有 2.4 億立方公尺土砂；局部河道甚至已淤高近 50 公尺。換句話說，眼前不是一場災後清理，而是一條河未來數十年的土砂治理問題。

先看結論

馬太鞍溪真正要處理的，不是「一座壩」，而是「土砂下山的速度」

1

短期先穩住柔性、臨時性設施優先，避免在不穩定厚層堆積上急做永久剛性工程。

2

中游要調節不是把砂完全攔死，而是削弱單次大量下移的尖峰。

3

下游要留空間疏濬、高規格堤防、囚砂與第二道防線共同承擔超量風險。

4

長期靠監測用航測、地形變化與數值模擬，持續修正每一階段工程位置與尺度。

常願寺川最值得台灣學的，也正是這一點：砂防的目的從來不是讓一粒砂都不往下游走，而是把災難性的土砂脈衝，轉成可以被河道與工程系統承受的流量。

常願寺川與馬太鞍溪的共同課題，不是把所有土砂攔住，而是把一次性的災難性土砂脈衝，拆成流域可承受、可調節的輸砂過程。

一場 1858 年的大崩塌，讓日本治理了一百多年

1858 年飛越地震發生時，立山火山口內的大鳶山、小鳶山大規模崩塌，約 4.1 億立方公尺土砂堵塞常願寺川上游。地震後 14 天與約兩個月後，天然壩先後形成兩次大規模土石流，其中第二次災害造成約 140 人死亡，並帶來大範圍家屋與農地損失。

更麻煩的是，災害並沒有隨著天然壩潰決而結束。大量土砂留在山區與河道，持續被雨水帶往中下游，河床越墊越高，常願寺川逐漸形成典型「天井川」——河床高於周邊土地，一旦越堤，洪水就會迅速向平原擴散。

日本從 1906 年開始由富山縣推動上游砂防，1926 年再升級為國家直轄砂防。到了 2026 年，立山砂防正好迎來「縣營 120 年、直轄 100 年」。一百多年過去，立山火山口內仍約有 2 億立方公尺的崩塌土砂沒有離開。

這個數字很重要。它告訴我們：億方級崩塌不是靠幾年工程「清掉」的問題，而是要建立一套讓土砂能被分期、分段、分量管理的治理系統。

馬太鞍溪與常願寺川，真正相似的是「災後第二階段」

馬太鞍溪在 2025 年災害後，堰塞湖本體已逐步降挖、退水。依據2026 年 5 月林業保育署的資料顯示，原堰塞湖蓄水區已回復河道型態；但壩體、崩塌區與中上游河道仍約有 2.4 億立方公尺土砂，未來仍可能因地震或豪雨再次下移，甚至重新形成堰塞湖。

也就是說，堰塞湖風險下降，不等於流域風險解除。

馬太鞍溪現在正進入和常願寺川當年最相似的階段：上游有巨量不穩定土砂，中游河床劇烈沖淤，下游又已經有聚落、道路、橋梁與農地，不能單純「讓河自己走」。

最容易犯的錯誤：把災後治理理解成「找一個地方蓋一座更大的壩」。真正的問題是整條河的土砂收支、河床變化與超量洪水要如何共同被管理。

日本給的第一課：永久工程，不是越早做越好

對馬太鞍溪而言，現在最大的誘惑，是趕快在中上游找位置興建大型永久防砂壩，看起來一次解決問題。

但這正是最需要克制的地方。

2026 年 5 月馬太鞍溪中上游專家會議的結論已很清楚：目前河床土砂堆積深、容易被水流沖刷下移，中游應以臨時性防砂設施為主，並盡量採柔性工法，依汛期後地形變化滾動調整。

這個邏輯和常願寺川早期的教訓高度一致。富山縣早期興建的湯川第一號砂防堰堤，就曾在豪雨中遭到破壞。後來國家接手後，日本砂防之父－赤木正雄，沒有先問「壩要蓋多高」，而是花時間確認哪裡才是整個流域真正可以站得住腳的控制點。

最後選定的白岩砂防堰堤，建在大面積岩盤出露處。主壩高 63 公尺，連同 7 座副壩總落差達 108 公尺，1939 年才完成。它之所以成為立山砂防的基幹，不只是因為高，而是因為位置、地基與整體砂防系統的角色都對了。

這對馬太鞍溪的啟示很直接：未來若要設置大型永久性防砂構造物，真正的前提不是「有沒有預算」，而是岩盤在哪裡、河谷是否足夠收束、壩後堆砂如何演變、壩下游會不會加劇沖刷，以及整體河床是否已進入可預測的穩定階段。

日本給的第二課：不要追求「攔住全部」，要建立「梯次調節」

常願寺川的砂防系統並不是靠一座超級大壩保護富山平原，而是把不同位置交給不同設施處理。

上游崩塌源區以泥谷砂防堰堤群與山腹工穩定坡腳；立山火山口出口由白岩砂防堰堤扮演關鍵控制點；中游再用多枝原等堰堤與護岸穩定流路；更下游則有本宮砂防堰堤，以約 500 萬立方公尺的貯砂能力調節土砂流出。

這是一個很重要的觀念：砂防壩不是倉庫，設計目的也不是永久把土砂全部存滿。它更像流域中的「節流閥」，在不同位置降低河床侵蝕、減緩土砂尖峰、固定河岸與調整河床坡度。

對馬太鞍溪來說，短期布設的臨時防砂設施即使在汛期被掩埋，也不能只解讀為「工程失敗」。在億方級土砂面前，臨時設施的價值本來就不應以「永遠不被埋」衡量，而應看它是否爭取到時間、降低單次輸砂尖峰，並為下一輪布設提供地形與成效資料。

日本給的第三課：近期真正保命的，往往在下游

上游工程需要時間，但聚落的風險不能等。

因此，馬太鞍溪近期治理最務實的重點，仍然是下游河道與聚落防線。到 2026 年 7 月，水利署公布花蓮溪與馬太鞍溪合計已完成約 2,271 萬立方公尺疏濬，其中馬太鞍溪約 1,788 萬立方公尺；受損堤防也已完成復建。南岸的高規格堤防與第二道防線工程則已進入施工階段。

這些工作不是「治標而已」。當上游土砂不可能在短時間被完全固定時，下游有沒有足夠通洪斷面、堤防有沒有抗沖刷能力、聚落前有沒有第二道防線，以及河川能不能預留囚砂與超量洪水空間，反而直接決定下一場颱風來時的損失規模。

水利署規劃的高規格堤防，部分堤段堤頂寬度達 50 公尺；另規劃大面積土砂堆置與第二道防線，概念上就是讓極端事件有「超量空間」，而不是假設第一道堤防永遠不能被超越。

核心判斷：上游是「降低土砂生產與下移速度」，中游是「調節」，下游是「給水與砂足夠空間」。三者缺一不可。

馬太鞍溪目前最需要的不是搶著把永久工程定案，而是把可調整措施先做足，再讓地形監測、數值模擬與地質條件決定不可逆工程何時進場。

第四課：真正的百年工程，背後一定有長期監測與維運體系

立山砂防有一項常被忽略的工程：18 公里的砂防工事專用軌道。它不是景觀設施，而是為了把人員、機具與材料送進高山施工區。全線跨越 640 公尺高差，至今仍是維持長期砂防工作的關鍵基礎設施之一。

這提醒我們，面對馬太鞍溪這種沒有道路、施工季節短、機具風險高的流域，真正需要規劃的不只是「做哪一座工程」，還包括人怎麼進去、機具怎麼留、汛期怎麼撤、災後怎麼再進場、每年如何重測地形、資料由誰統一管理。

目前跨部會以 UAV、航測、衛星影像、水位與地形資料持續監測，是正確方向。但更進一步，應把這些資料變成固定的年度治理循環：

1. 汛期前建立基準地形與風險情境。
2. 每場主要颱洪後快速重測，計算崩塌區、河道與囚砂區的土方收支。
3. 以數值模擬更新「哪裡會沖、哪裡會淤、哪裡可能重新堵塞」。
4. 依結果決定下一個非汛期要做的削坡、柔性防砂、疏濬或堤防加固。
5. 每隔數年重新檢討永久設施的位置與必要性，而不是一開始就把未來 20 年工程全部定死。

這才是真正的「數位聯防」：不是多做幾次空拍，而是讓監測資料直接決定工程優先順序。

馬太鞍溪可以學日本，但不能複製日本

常願寺川提供的是百年經驗，不是標準答案。

台灣降雨型態、颱風強度、地質、集水區尺度、土地使用、原住民族傳統領域與下游聚落條件，都和富山不同。未來馬太鞍溪若把「日本做過什麼」直接翻成「台灣照著蓋什麼」，反而會犯另一種錯誤。

真正值得複製的是治理順序：

• 先承認時間尺度。 億方級的土砂不會在一任政府、一個計畫期內消失。
• 先做可調整的，再做不可逆的。 河床尚未穩定時，柔性與臨時設施比大型永久工程更有彈性。
• 永久工程先找地質控制點。 不是哪裡方便施工就蓋哪裡。
• 用下游空間承擔超量風險。 河道、囚砂區、第二道防線與疏濬都要納入同一套系統。
• 用監測與模型持續修正。 每一場颱風都可能改變河道，也應改變下一階段治理策略。

若未來整體規劃案能安排工程與治理人員到常願寺川進行一到兩個月的實地蹲點，真正應看的也不只是白岩砂防堰堤有多壯觀，而是日本如何在一百多年裡管理施工季節、維護失敗、監測、運補、地方溝通與跨世代預算。

結語：最重要的工程，是把「一次災害」改成「一百年的治理制度」

常願寺川最值得敬佩的，不是蓋出日本最高的砂防堰堤，而是接受了一個不討喜的事實：有些土砂問題，不可能在短時間內治癒，只能長期管理。

不求一次清空

不迷信單一巨壩

先柔性、後永久

上中下游一起看

讓水砂有空間

讓監測驅動工程

馬太鞍溪真正的曙光，不是某一座工程完工的那一天，而是台灣願意把它當成一個跨越 20 年、甚至更久的流域治理課題，建立可以持續修正、持續維護、也能跨世代交接的制度。當我們開始用這個時間尺度思考，才真正走上了從災後搶救到長期治理的第一步。

參考資料

• 農業部林業及自然保育署，2026-05-26，馬太鞍溪中上游防減災專家會議資料。
• 經濟部水利署／經濟部電子報，2026-07-03，馬太鞍溪與花蓮溪疏濬及防汛整備資訊。
• 經濟部水利署水利工程計畫透明網，2026，馬太鞍溪光復堤段高規格暨第二道防線系統性治理工程。
• 農業部農村發展及水土保持署 BigGIS，馬太鞍溪災後地貌變遷與河床高程分析。
• 農業部農村發展及水土保持署電子報129期，2024-12-19，航班抵達-海外水保旅行!日本水保旅遊深度探訪實錄(一)
• 日本國土交通省北陸地方整備局立山砂防事務所：安政 5 年災害、立山砂防事業與富山平原、白岩砂防堰堤、本宮砂防堰堤、立山砂防工事專用軌道等資料。

馬太鞍溪堰塞湖立山砂防常願寺川土砂治理

【工作流】先用好 ChatGPT 專案，再談 Skill：用對話建立可靠的 AI 工作流

AI 工作流・ChatGPT 專案

先用好 ChatGPT 專案，再談 Skill：用對話建立可靠的 AI 工作流

不必先學提示工程或 Skill 格式；先把需求說清楚，讓 AI 協助建立專案指令、SOP 與參考文件。

最容易上手的做法，不是先研究 Skill，而是先透過對話釐清需求，讓 AI 協助建立專案指令與 SOP；再把重要文件放進專案資料來源，用真實工作反覆測試。

📁 主題：專案工作流🧭 核心：先專案、後 Skill📝 方法：對話產生指令與 SOP

ChatGPT 的「專案」功能，不只是把相關對話放在同一個資料夾裡。更實用的價值，是把特定工作的專案指令、參考文件與討論脈絡集中管理，讓 AI 在較清楚的背景下持續協作。

建立這類工作流時，真正需要先掌握的不是 Skill 格式，而是如何把工作需求說清楚。先透過對話釐清角色、任務、判斷標準與輸出方式，再請 AI 協助整理成專案指令；需要 SOP 時，也可以直接提供現成文件，或口述大致流程，請 AI 先整理成完整初稿。等實際測試後確認流程穩定，而且確實需要跨專案重複使用，再進一步製作 Skill。

先把工作說清楚，不要先研究格式

建立專案前，可以先回答幾個實際問題：

• 這個專案要處理什麼主題？
• AI 在其中應扮演什麼角色？
• 主要任務是分析、審查、整理，還是提出建議？
• 回答時要遵守哪些原則？
• 哪些判斷需要保留限制與不確定性？
• 最後希望得到什麼形式的成果？

這些問題不必一次回答完整。比較有效的方法，是先把想法直接說給 AI 聽，透過幾輪對話逐步釐清，再請 AI 將結果整理成可直接使用的專案指令。

專案指令不必從空白頁開始寫，也不必先具備提示工程背景。真正需要的是具體描述工作，而不是先學會一套術語。

圖 1｜在專案設定中撰寫專案指令

建立新專案時，除了設定專案名稱與專案指令，也請在「記憶」選擇「僅限專案」，讓專案脈絡限制在本專案的對話與資料來源。

記憶設定請選「僅限專案」：建立新專案時，請將「記憶」設為「僅限專案」。如此一來，專案中的對話可以參考同一專案內的其他對話，但不會參考一般 ChatGPT 聊天、其他專案的對話，或先前已儲存的個人記憶，可避免無關內容混入專案脈絡。此選項只能在建立新專案時設定；既有專案若使用預設記憶，需另建新專案才能改用。

資料來源：OpenAI Help Center〈ChatGPT 中的專案〉

可以直接這樣問：

我想建立一個專案，主要討論災害潛勢調查與防災製圖方法。請協助我設計專案指令，讓你在這個專案中扮演專業顧問；回答時要直接指出方法上的漏洞、限制與改善方向，不需要提供情緒性的鼓勵。

接著再根據實際回應，修正角色、範圍、輸出格式與限制條件。這比一開始追求一份「完美指令」更有效。

用四個步驟建立專案工作流

STEP 1

透過對話釐清需求，產出專案指令

先把工作情境、問題類型、判斷原則與預期成果說清楚，再請 AI 整理成第一版專案指令。重點是先建立一個可以測試的基準，而不是一次完成所有細節。

STEP 2

有 SOP 就直接提供；沒有，也可以口述給 AI

SOP 不見得要自己從空白開始寫。

如果已有現成 SOP，可以直接作為專案資料來源；如果目前只有實務經驗與大致流程，也可以用文字或語音說明：

• 工作從哪裡開始
• 由誰負責
• 有哪些判斷點
• 遇到例外如何處理
• 最後要產出什麼成果

再請 AI 整理成結構完整的 SOP 初稿。例如：

請把我接下來口述的工作流程整理成正式 SOP，包含目的、適用範圍、角色分工、作業步驟、判斷條件、例外處理、輸出成果與檢核項目。內容不確定的地方請標示「待確認」，不要自行補成既定規定。

注意：AI 產出的 SOP 應視為可供檢討的初稿。涉及法規、權責、時效與安全要求的內容，仍須由實際執行人員或主管確認。

STEP 3

把重要流程放進專案資料來源

並不是每一套流程都需要立刻做成 Skill。

若內容目前只會在這個專案中使用，或仍在調整，最簡單的方式是先整理成參考文件，再上傳到資料來源，例如：

• 工作流程與 SOP
• 審查原則與檢核表
• 方法選擇與驗證步驟
• 圖資設計規範
• 常見錯誤與例外處理方式
• 報告格式或成果範例

這類文件可以使用 Markdown、Word 或 PDF。重點不在副檔名，而在內容是否清楚、可查找，並能支援後續工作。

圖 2｜把 SOP 與方法文件放進專案資料來源

現成 SOP、方法文件與自訂工作流程，都可以放進專案資料來源，形成這個專案持續使用的參考依據。

將詳細流程放入專案資料來源，可以讓專案指令保持精簡，同時讓 AI 在後續工作中依循同一套程序與判斷原則。

STEP 4

用真實工作測試，再決定是否製作 Skill

不要只看指令或 SOP 寫得是否完整，而要實際投入文件、案例或圖件，觀察 AI 的判斷是否穩定、是否符合專業需求。

把反覆出現的誤解、缺漏與輸出問題補進專案指令或參考文件，讓流程逐步成熟。只有當這套方法已經穩定，而且確實需要在不同專案中重複使用時，再製作 Skill，才有實際價值。

圖 3｜先建立專案工作流，成熟後再製作 Skill

先以對話釐清需求，建立專案指令與參考文件；流程穩定且需要跨專案使用時，再封裝成 Skill。

參考文件與 Skill，應該怎麼選？

先放入專案資料來源	再製作成 Skill
只供單一專案使用	需要跨專案重複使用
內容仍在調整	流程已相對穩定
主要是 SOP、規範、檢核表或範例	需要固定步驟、模板、參考資料或工具
希望快速開始使用	希望長期重複執行同一套工作
文件經常需要人工修訂	方法已具備明確觸發條件與輸出規則

Skill 不應被理解成「比較高階，所以一定要先學會」的功能。它比較適合被視為：成熟工作流程的封裝方式。

如果流程仍在摸索，或目前只服務單一專案，先使用專案指令與參考文件通常更合理。

實際案例：讓專案提供接近專業顧問的服務

以「災害潛勢調查與防災製圖方法」專案為例，可以先設定 AI 為相關領域的專業顧問，再把工作流程文件放入資料來源，最後上傳真實的教育訓練成果、圖件或報告進行測試。

這樣的專案便不只是整理資料，而能提供三類顧問服務：

• 成果定位：判斷目前屬於教學原型、討論成果，還是可供實務使用的圖件。
• 方法審查：檢查資料尺度、製圖方式、角色分工與驗證程序是否合理。
• 改善建議：指出圖面、流程、現地查核與使用測試還缺少哪些環節。

圖 4｜實際案例：專案可以提供的顧問輸出

以社區地形特徵圖教育訓練成果為例，專案可協助成果定位、方法審查與提出改善建議。

這類服務的重點，不是讓 AI 取代專業判斷，而是讓它在明確的角色、方法與資料脈絡下，協助檢查邏輯、發現缺漏、整理風險，並提出可執行的改善方向。

結語：先跑順，再封裝

ChatGPT 專案的價值，在於把特定工作的專案指令、文件與討論脈絡集中管理。

先透過對話釐清需求，讓 AI 協助建立專案指令與 SOP，再用真實工作反覆修正；只有當流程已經成熟，而且需要跨專案重複使用時，才需要進一步製作 Skill。

先把工作跑順，再把成熟方法封裝。

掌握這個順序，就不必先具備大量技術背景，也能逐步建立一套符合自己工作需求的 AI 協作方式。

ChatGPT 專案專案指令SOPSkill

【工作流】ChatGPT 專案不是另一個資料夾：從專案指令、正式來源、分工聊天到有效結論，建立可持續累積的工作系統

AI 工作流・專案管理

ChatGPT 專案不是另一個資料夾

從專案指令、正式來源、分工聊天到有效結論，建立可持續累積的工作系統

在前一篇文章中，我們介紹了 Gemini 的「筆記本」功能。ChatGPT 也有相似的「專案」，但它真正的價值不只在於集中資料，而是讓同一件工作能跨越多次討論、不同成果與多人協作持續推進。

📁 ChatGPT 專案⏱ 閱讀時間：約 8 分鐘👥 適用：公務、委辦與長期工作🗓 2026／07

在前一篇文章中，我們談的是如何用 Gemini 筆記本建立一個能持續理解特定主題的 AI 空間。這一篇不再重複筆記本的操作，而是聚焦另一個更實際的問題：ChatGPT 專案裡應該放什麼、怎麼分工，才能真正支撐一項長期工作？

先把核心架構擺出來

好用的 ChatGPT 專案，至少有四層內容

1

專案指令定義角色、回覆原則與工作規則。

2

正式來源放入核定資料、最新報告與有效依據。

3

分工聊天依成果拆分研析、推演、簡報與對外工作。

4

有效結論把確認後的決策、摘要與定稿重新存回專案。

STEP 1

專案不是另一個資料夾

問題：為什麼把附件全部上傳，仍然無法形成穩定的工作脈絡？

一般聊天適合處理一次性問題，例如修改一段文字、翻譯內容或快速討論一個想法。

但當工作持續數週、跨越多次會議，還要產出報告、簡報、問答集與對外說明時，只靠一串聊天很快就會出現問題：背景反覆重講、不同版本混在一起、已確認的結論埋在歷史訊息中，最後連自己都不確定哪一段才有效。

核心判斷：專案的價值不是「多放幾個附件」，而是讓指令、資料、討論與結論有清楚的層次。

STEP 2

四層內容怎麼安排？

問題：哪些內容該固定保存，哪些只需要留在某一次聊天？

第一層｜專案指令：規定 AI 怎麼做事

專案指令不是拿來堆背景資料，而是規定 ChatGPT 的角色與判斷原則。例如：

• 回答先說結論，再說理由與建議。
• 區分資料明載、合理研判與建議作法。
• 不同文件互相矛盾時，先列出差異，不自行選邊。
• 草案、推演與已作廢內容，不得視為正式立場。
• 長官簡報應突出待裁示事項。

第二層｜正式來源：只放目前有效的依據

專案來源應放入會持續引用，而且狀態明確的資料，例如核定計畫書、最新正式報告、會議決議、目前有效的統計數字，以及統一名詞與政策口徑。

大量舊版本、未整理表格與臨時截圖，不必全部放進專案。資料愈多不一定愈準確；新舊版本並存，反而會增加引用錯誤的機會。

第三層｜分工聊天：一項成果，一個工作線

同一個專案可以有很多聊天，但每一串最好只負責一項明確成果。例如：

• [研析] 期中報告與計畫書差異
• [推演] 委員可能提出的質疑
• [簡報] 署長報告架構
• [對外] 媒體與地方政府問答
• [核定] 目前有效結論

第四層｜有效結論：讓已確認成果沉澱

每次重要會議或長官指示後，應把採用的決策、統一口徑、定稿摘要與下一步工作整理回專案。建議固定維護：

• 00_專案說明與使用規則
• 01_目前有效結論
• 02_版本與資料清單

這三份資料能告訴 AI，也告訴團隊：現在以哪一版為準、哪些內容已作廢、還有哪些事項待決定。

ChatGPT 專案的核心不是檔案數量，而是四層內容能否互相串接。

STEP 3

ChatGPT 專案和 NotebookLM 怎麼分工？

問題：都是集中資料，為什麼還需要兩種工具？

兩者都能集中資料、延續特定主題的問答，但工作重心不同。

NotebookLM 幫你確認「資料怎麼說」；ChatGPT 專案協助你推進「接下來怎麼做」。

需要查找原文、比對多份報告時，可以先在 NotebookLM 建立證據；確認資料後，再回到 ChatGPT 專案製作長官簡報、政策建議、會議資料與對外說明。最後，正式核定文件仍應回存機關既有系統。

工作階段	適合工具	主要任務
閱讀與查證	NotebookLM	找原文、比較來源、建立證據
分析與產製	ChatGPT 專案	推演、決策、簡報、報告與溝通
核定與保存	機關正式系統	版本確認、簽核與長期保存

STEP 4

一個專案可以照這五步運作

問題：建立專案後，最穩妥的啟動順序是什麼？

1｜建立專案

先定義目的、範圍、主要受眾與預計成果，再設定專案指令。專案名稱應讓新進同仁一眼看懂要完成什麼，例如「全球資訊網業務內容改版」或「○○颱風災後調查」。

2｜加入正式來源

只放會持續影響後續判斷的核定資料、最新報告與有效依據。歷年舊稿、原始表格及中間成果仍可留在本機或原有檔案系統。

3｜依成果開聊天

不要把所有工作塞進同一串，也不必每問一題就開新對話。最好的顆粒度是：一項成果，一個聊天。

4｜會後收斂結論

每次重要會議後，更新有效結論、標示作廢內容，並整理待辦事項。聊天很多不是問題；沒有收斂才是問題。

5｜定稿回正式系統

ChatGPT 專案適合分析、推演與產製，但不能取代正式的簽核、版控與檔案保存。定稿後仍應回到公文、檔案管理、Teams、SharePoint 或其他正式平台。

專案要保留工作脈絡，但定稿仍應回到正式系統完成版控與保存。

STEP 5

避免三個常見錯誤

問題：專案為什麼會愈用愈亂？

⚠️

草稿與正式版本混用

檔名應標示日期、版本與狀態；舊版要註記作廢或移出正式來源。

⚠️

所有事情塞進同一聊天

技術研析、長官簡報、媒體回應與反方推演應分成不同工作線。

⚠️

只增加資料，不更新結論

每次重要決策後，都要更新「目前有效結論」，讓團隊知道現在採用哪個方向。

STEP 6

共享專案後，要指定一位維護者

問題：多人都能加入內容時，如何避免共同脈絡失控？

共享專案有助於維持共同背景，但任何人加入的檔案、聊天與指令，都可能影響後續回答。因此，必須指定維護者負責：

• 維護正式來源與版本。
• 管理專案指令。
• 區分草案、推演與正式口徑。
• 更新目前有效結論。
• 控制誰擁有編輯權限。

協作提醒：共享的重點不是讓每個人都把資料丟進去，而是讓所有人都在同一套可信脈絡下工作。

回顧｜把專案真正做成工作系統

構成層次	主要功能	管理原則
專案指令	定義角色與工作方式	簡短、穩定、可長期沿用
正式來源	提供事實與有效依據	只留目前有效、會持續引用的資料
分工聊天	處理不同成果與受眾	一項成果一個聊天
有效結論	沉澱決策、摘要與定稿	每次重要決策後立即更新

寫在最後｜不要讓 AI 記得更多，要讓它記得正確

前一篇談 Gemini 筆記本，重點是建立能持續理解特定主題的 AI 空間；這一篇談 ChatGPT 專案，重點則是讓一項工作在多次討論、不同成果與多人協作之間仍維持清楚脈絡。

專案指令定規則

正式來源放依據

一項成果一個聊天

草案與核定要分開

重要決策立即收斂

定稿最後回正式系統

ChatGPT 專案的價值，不是把更多檔案交給 AI，而是把一次性問答變成可以持續累積、交接與延伸的工作脈絡。

延伸閱讀：
・前一篇：Gemini 筆記本管理 AI 專案工作
・ChatGPT 專案與 NotebookLM 功能仍可能隨產品更新調整，實際使用時請以最新介面與官方說明為準。

#ChatGPT#AI工作流#專案管理#NotebookLM#公務AI

【工作流】別再讓 AI 對話變成垃圾堆：用 Gemini 筆記本建立專屬專案工作區

AI 工作流・專案管理

別再用對話紀錄管理長期工作：Gemini 筆記本才是 AI 專案的正確入口

把資料、設定、討論與輸出集中在同一個工作空間，讓 AI 不必每次重新認識你的專案。

Gemini 筆記本不是另一個聊天分類功能，而是把一次性問答改造成持續專案的工作空間。本文整理實際可用的建置方法，以及公務使用時不能忽略的資料界線。

📁 AI 工作流👥 適用：專案管理、研究整理、報告撰寫🗓 2026 年 7 月

很多人已經會用 AI 問問題、改文字、做摘要，卻仍把所有工作塞在一長串對話裡。短任務勉強可行；一旦專案持續數週、牽涉多份資料與反覆修正，問題就會出現：重要設定被後續對話稀釋、舊資料埋進歷史紀錄、每次都要重講背景，最後連自己也分不清哪一版才是目前共識。

Gemini 新增「筆記本」後，真正值得注意的並不是多了一個收納功能，而是 AI 的使用方式開始從「一次性聊天」走向「持續性的專案工作空間」。官方說明指出，筆記本能記住專案中的來源、指令與持續討論，並可與 NotebookLM 同步。換句話說，你不必再期待 AI 在一條愈來愈長的對話中勉強維持脈絡，而是可以替每個重要任務建立自己的工作空間。

先抓住核心差異

一般對話適合解題；筆記本適合做專案

1

固定專案脈絡把目標、限制與角色設定留在同一空間。

2

集中專案資料文件、網址、逐字稿與表格不再四散。

3

延續討論歷程每次修正都建立在既有共識之上。

4

轉成實際成果從研究整理一路產出報告、簡報與問答。

一般對話比較像臨時找一位能力很強的同事協助：你把問題交代清楚，他可以很快完成任務。但當工作跨越多個階段，牽涉不同版本、來源與決策紀錄時，光靠聊天紀錄管理就會失控。

筆記本則比較像替專案設置一間固定辦公室。專案資料放在裡面，工作規則寫在裡面，討論也留在裡面。之後不論要彙整資料、比對文件、重寫報告或準備簡報，都從同一個脈絡繼續，而不是每次重新開始。

Gemini 筆記本的重點，不是把更多資料塞進 AI，而是為每個專案建立獨立且持續的工作脈絡。

使用前先注意：在 Gemini 左側選單點選「新增筆記本」後，畫面中會出現「整理思路」與「讀書與學習」兩種選擇。若你的目的是建立工作專案、整理會議資料、分析政策文件、延續計畫討論或累積研究成果，請選擇「整理思路」。

STEP 1

一個專案，建立一本筆記本

問題：怎麼避免筆記本最後又變成另一個雜亂的收件匣？

最重要的原則不是「把所有資料都放進去」，而是「一個明確任務建立一本」。例如：

• 「不安定土砂產品說明會」是一個筆記本。
• 「AI 工作圈年度推動計畫」是另一個筆記本。
• 「某次颱風災後調查與防災會報」再建立一本。

不要把不同專案混在一起。AI 的脈絡愈明確，回答愈容易聚焦；資料混得愈雜，回覆就愈容易把不相關的內容拼在一起。

核心判斷：筆記本的分類單位不是「資料類型」，而是「你正在完成的任務」。同一個專案裡可以同時放報告、會議紀錄、簡報、法規與逐字稿。

STEP 2

先寫專案指令，再開始丟資料

問題：為什麼很多人上傳很多檔案，AI 仍然不知道該做什麼？

因為「資料」不等於「任務」。在加入來源以前，先用一段簡短指令寫清楚五件事：

1. 這個專案要完成什麼。
2. AI 在專案中的角色。
3. 哪些資料優先採信。
4. 輸出要給誰看、使用什麼格式。
5. 哪些事情不能自行推測。

可以直接使用下面這個範本：

你是本專案的研究與寫作協作助手。專案目標是＿＿＿＿。回答時優先依據筆記本內的正式文件與最新版本資料；不同來源互相矛盾時，請指出差異，不要自行替我決定。輸出對象是＿＿＿＿，語氣需＿＿＿＿。涉及數字、日期、法規與政策立場時，請標示來源；資料不足時直接說明，不得補造。

這段指令不需要寫得像系統規格書，但必須讓 AI 知道：它要協助的是哪一件事、依什麼標準工作、最後要交付什麼。

STEP 3

把來源放進來，但要保留版本秩序

問題：資料愈多，真的一定愈好嗎？

Gemini 筆記本可以加入裝置檔案、Google 雲端硬碟文件、網址與貼上的文字；筆記本內容也會與 NotebookLM 同步。這使它適合處理跨文件的整理工作，例如比對政策版本、彙整會議紀錄、整理研究資料，或從多份報告中抽出共同結論。

但來源管理仍然要由人負責。建議檔名至少包含「日期、內容、版本」，例如：

• 20260715_不安定土砂產品說明會_簡報_v3.pdf
• 20260720_跨組會議紀錄_核定版.docx
• 現行規定_農村水保署_202607.pdf

同一份資料有新版時，應刪除或明確標註舊版，不要讓 AI 同時看到多份名稱相近、內容互相衝突的文件，卻沒有任何版本說明。

公務資料注意：目前 Gemini 筆記本官方說明仍以個人 Google 帳戶為使用條件，公司與學校帳戶尚未支援。公務機關使用時，應遵守機關資訊安全、個資與資料分級規範；敏感、未公開或依法不得外傳的資料，不應上傳至個人帳戶。

STEP 4

不要只問「幫我整理」，要指定產出

問題：如何讓筆記本從資料庫變成真正的工作工具？

好的提問不是要求 AI「看完全部資料」，而是指定一個可驗收的成果。例如：

• 比較三份會議紀錄，列出已形成共識、仍有歧見及待辦事項。
• 依現行政策文件，整理一頁給首長看的決策摘要。
• 從研究報告中抽出方法、成果、限制與下一步，製成四欄表格。
• 找出簡報與正式報告中數字不一致的地方，逐項列出來源。
• 模擬地方政府可能提出的十個問題，並依資料擬定回應草稿。

這些任務都有清楚的範圍與輸出形式，也比較容易檢查。筆記本的價值不是替你囤積資料，而是讓資料可以被反覆查找、比較、修正與轉換。

筆記本能否真正提升效率，關鍵不在上傳多少資料，而在任務邊界、版本秩序、輸出規格與資料治理。

Gemini、Gemini 筆記本與 NotebookLM，怎麼分工？

工具／模式	最適合的工作	不適合的用法
一般 Gemini 對話	臨時提問、快速改寫、單次構想	長期專案、跨版本追蹤
Gemini 筆記本	持續專案、保留指令與討論脈絡、搭配網路搜尋及其他工具	把所有專案混在同一本
NotebookLM	以來源為基礎的閱讀、查證、摘要與內容轉換	取代正式決策或原始檔案管理

這三者不是互相取代。比較合理的做法是：一般對話處理臨時工作；重要且持續的任務進入 Gemini 筆記本；需要深入閱讀、引用與轉換來源時，再利用與 NotebookLM 的同步能力處理。

最常見的四個錯誤

01

所有工作塞進同一本

不同專案的角色、資料與結論互相污染，最後回答看似完整，其實脈絡混亂。

02

只上傳資料，不說目的

AI 可以摘要文件，卻不知道你真正要解決的問題與交付對象。

03

把 AI 當成正式紀錄

筆記本是協作空間，不是公文檔案、核定紀錄或唯一版本的保存處。

第四個錯誤更重要：把機密、個資或未公開資料直接上傳。AI 工具可以提升效率，但不能凌駕資料治理。工具是否方便，從來不是判斷資料能不能上傳的標準。

真正的改變，是替 AI 建立工作空間

Gemini 筆記本最有價值的地方，不是讓模型突然變得更聰明，而是把專案脈絡從零散對話中獨立出來。

一案一本

先定義任務

來源有版本

輸出可驗收

重要內容要查證

敏感資料不上傳

當資料、指令、討論與成果都圍繞同一個專案累積，AI 才不只是回答問題的聊天工具，而會逐步成為真正能延續工作的協作空間。

參考資料
1. Google Gemini 說明：在 Gemini 系列應用程式中建立及使用筆記本
2. Google NotebookLM 說明：在筆記本加入或探索新來源

AI 工作流Gemini 筆記本NotebookLM專案管理公務數位工具

【防災策略】從保護聚落到掌握流域健康：不安定土砂調查的防災意義

坡地防災・觀念釐清

從保護聚落到掌握流域健康：
不安定土砂調查的防災意義

有些災害，在尚未威脅聚落之前，就已經開始改變整個流域的風險條件。

近年來，極端氣候帶來的坡地災害越來越複雜。過去談土石流、大規模崩塌，通常會先問一個問題：

這個災害是否可能直接威脅到人命？是否可能直接影響聚落安全？

過去土石流潛勢溪流及大規模崩塌潛勢區的劃設，主要以保全住戶與聚落安全為核心——透過地形、地質、水文、歷史災害等資料，評估哪些溪流或坡地未來可能發生災害，並可能直接影響居民安全。

但現在，我們面對的災害情境正在改變。很多災害不一定一開始就直接影響聚落，而是先發生在上游、堆積在河道裡，等到下一場豪雨來臨，再透過河道淤高、通洪能力下降、橋梁受損、道路中斷或下游淹水，造成更大範圍的複合型災害。

所以，坡地防災不能只問「是否直接影響聚落」，也要問：

整個流域是不是已經出現不健康的徵兆？

這就是不安定土砂調查的重要意義。

・・・

01

過去：以保全住戶為核心的防災管理

土石流潛勢溪流及大規模崩塌潛勢區，是一套以「保全對象」為核心的防災管理制度：依據地形、地質、水文、歷史災害等條件，判斷哪些溪流或坡地未來可能發生災害，並評估是否影響下游聚落或保全住戶。如果可能影響居民安全，就需要納入警戒、疏散、避難與防災整備。

換句話說，這套制度關注的是：哪裡可能發生災害，而且可能直接危及居民安全？

這套制度適合支撐警戒、疏散與避難，但管理視角主要集中在災害與保全對象的直接關係。

・・・

02

現在：不只看聚落，也要看流域健康

不安定土砂調查，代表另一個更前端的防災視角。它不先問「這裡有沒有保全住戶」，而是先問：

這個流域裡，哪些地方已經出現不穩定、不健康、可能惡化的土砂現象？

例如：

• 坡面是否仍有殘坡或鬆散土砂？
• 河道是否已經明顯淤高？
• 土砂是否可能在豪雨時再次移動？
• 是否可能影響河道、橋梁、道路或下游地區？

這些問題不一定一開始就對應到某一戶保全住戶，但可能是未來複合型災害的重要前兆。所以，不安定土砂調查的重點是：

先掌握災害源，再評估後續可能影響。

這不是取代原本的潛勢溪流或潛勢區制度，而是把防災工作往前推進一步。

・・・

03

生活化比喻：排水系統阻塞

不安定土砂調查，比較像在大雨前，先檢查整個排水系統是否已經出現阻塞。

💡 生活情境

水溝、箱涵或排水渠道裡已經堆滿落葉、泥沙、垃圾。平常可能還沒有淹水，但下一場大雨來時，這些阻塞物就可能讓水排不出去，使原本不容易淹水的地方也發生淹水。

放到坡地防災來看，上游殘坡、河道淤高、崩塌後鬆散土砂堆積，就像排水系統裡已經堆積的泥沙與垃圾。即使目前還沒有直接影響保全住戶，也要先納入掌握，因為它可能在下一場豪雨中出流、外溢、下移，降低河道通洪能力，甚至讓下游災害擴大。

・・・

04

複合型災害：馬太鞍溪堰塞湖

極端氣候下，坡地災害往往具有跨空間、跨時間的連鎖效應。馬太鞍溪堰塞湖，就是具體案例。

⚠️ 真實案例

崩塌發生地點位於流域上游、距離下游聚落約15公里的深山無人處。若單純以「是否直接威脅保全住戶」的角度來看，這處崩塌本身並不在任何保全對象的直接影響範圍內。

但崩塌阻塞河道形成堰塞湖後，蓄積的水體在後續事件中潰決，順著河道向下游釋放，最終造成19人死亡、5人失蹤的嚴重洪水災情。

這個案例清楚呈現了複合型災害「難以事前預防」的核心困境：災害的起點與終點之間，隔著遙遠的距離，也隔著一段不確定的時間差。

這也顯示，以保全住戶為核心的制度，較難完整涵蓋距離聚落遙遠、但可能沿河道向下游傳遞的風險。不安定土砂調查所要補強的，正是這段上游風險。

・・・

05

兩套制度的功能比較

兩者的功能不同。潛勢區制度判斷災害是否可能影響保全住戶，並作為警戒、疏散與避難管理的基礎；不安定土砂調查則先掌握流域裡已經出現的災害源，它不一定一開始就對應到保全住戶，但可能影響道路、橋梁、河道通洪能力、下游聚落，甚至成為二次災害或複合型災害的源頭。

• 潛勢區制度回答的是：哪裡可能發生災害，而且可能影響居民？
• 不安定土砂調查回答的是：整個流域裡，哪裡已經累積下一場災害的材料？

・・・

06

總結

不安定土砂調查，讓防災從災害逼近聚落後的警戒，往前推進到上游災害源的辨識與追蹤。

總結 SUMMARY

坡地防災的核心始終是保護人民生命安全。但要達成這個目標，不能只看災害最後是否影響聚落，也必須及早掌握上游土砂累積與河道條件的變化。

潛勢區制度與不安定土砂調查不是互相取代，而是前後銜接：前者支撐聚落警戒與避難，後者協助提早看見流域中正在形成的風險。

有些災害，在尚未威脅聚落之前，就已經開始改變整個流域的風險條件。

※ 本文為觀念性科普說明，旨在協助一般讀者理解坡地防災制度的分工與演進，實際個案之潛勢判定與調查結果，仍以主管機關公告及專業調查報告為準。

#坡地防災 #不安定土砂 #土石流潛勢溪流 #大規模崩塌 #流域健康 #複合型災害 #農村水保署

【名詞解惑】土石流潛勢溪流、大規模崩塌潛勢區、不安定土砂，有何不同?

坡地防災・觀念釐清

土石流潛勢溪流、大規模崩塌潛勢區、不安定土砂
──到底差在哪裡？

防災名詞解惑・寫給想真正搞懂的人

近期在坡地防災的討論裡，這三個名詞常常出現。它們聽起來都跟「坡地、土砂、崩塌」有關，很自然會被歸成同一類；但實際細究其定義及劃定方式，就會發現它們在本質上完全不同。

麻煩的是，一旦有人將它們混在一起，理解就很容易跑偏——有人以為「這裡沒劃潛勢區，所以不用擔心土砂」，也有人一看到土砂異常就急著要疏散居民。這兩種反應，其實都是把不同的概念套錯了場合。

所以，先給一句話結論：

土石流潛勢溪流與大規模崩塌潛勢區，重點在「未來可能發生災害，而且可能影響保全住戶」；
不安定土砂，重點在「現地已經看得到異常，先把災害源掌握起來」。

更白話一點說：

土石流潛勢溪流 ／ 大規模崩塌潛勢區

像內傷

外表不一定看得出問題，但透過系統性評估，可以判斷它具備未來致災的條件。

不安定土砂

像外傷

傷口已經看得見——殘坡、河道淤高、異常堆積，先掌握問題本體再評估影響。

要先說清楚：這個比喻不是在比誰嚴重，而是在提醒一件事——它們被「發現」的方式，本來就不一樣。接下來，就一個一個拆開來看。

・・・

01土石流潛勢溪流：依條件推估的潛在風險

所謂土石流潛勢溪流，指的是一條野溪經過系統性評估之後，被判斷在豪雨或颱風來襲時，未來有可能發生土石流。評估時看的東西很多：地形夠不夠陡、上游有沒有鬆動的土砂可以被沖下來、集水區的水文條件如何，還有整體上容不容易形成高濃度的土砂流動。

不過，這裡有一個關鍵條件很容易被忽略：

📌 土石流潛勢溪流的劃設，不是只看山區有沒有野溪、坡度夠不夠、是否有崩塌土砂料源。實務上還要考量：一旦發生土石流，下游是否有保全住戶？有沒有需要納入警戒與疏散管理的對象？

換句話說，一條野溪要被劃成潛勢溪流，得同時滿足兩件事：它本身具備致災的條件，而且真的有人會受影響。它回答的問題，其實是「這條野溪未來可能出事，一旦出事又會波及到誰？」——這兩層評估，缺一不可。

・・・

02大規模崩塌潛勢區：坡地版本的同一套邏輯

大規模崩塌潛勢區的思路，其實跟土石流潛勢溪流幾乎一模一樣，只是舞台從溪流換成了坡地。它同樣是根據地形、地質、水文與地貌變化這些條件，去推估某一片坡地未來會不會發生大規模崩塌。而這裡講的崩塌，不是表層那種小規模的滑動，而是面積大、土方量大、深度也相當可觀(至少大於10m)的整體性崩落。

📌 大規模崩塌潛勢區的劃設，同樣不是單純看坡地有沒有異常。還要考量：這個坡地一旦崩塌，是否可能危及保全住戶安全？判斷邏輯與土石流潛勢溪流一致。

正因為邏輯相同，我們可以把這兩者合起來，統稱為「潛勢評估」：它們都是先用現有條件推估未來的風險，再把焦點收斂到「會不會影響保全住戶」這個核心判斷上。記住這個共通點，等一下對照「不安定土砂」時，差異就會格外清楚。

・・・

03不安定土砂：邏輯起點完全不同

講到不安定土砂，情況就翻轉過來了——它是三個概念裡，邏輯起點差最多的一個。前面兩者都是先想「未來會不會出事、會不會影響到人」；但不安定土砂不從這裡出發，它先問的是一個更直接的問題：

這裡是不是已經看得到明顯的不安定土砂？

這樣的情境在現地並不少見：可能是崩塌之後殘留、卡在半山腰下不來的殘坡；可能是河道裡明顯淤高、堆了一大堆隨時可能再往下移動的土砂；也可能是某個集水區在災害事件後，土砂量持續累積，從衛星或航拍影像上一眼就能看出不對勁。

這些都有一個共同特徵——它們不是靠條件「推算」出來的可能性，而是現地或影像上，此刻就看得到的異常。也正因為如此，不安定土砂的處理邏輯，才會跟潛勢區走上不同的路：

💡 只要現地已經可以辨識出明顯異常，就先納入掌握——不以有沒有保全住戶為前提——再進一步評估它可能往哪裡移動、會影響哪些對象（道路、橋梁、聚落、下游區域），以及需不需要後續措施。

到這裡，差異其實已經很清楚了：潛勢區是「從條件推估風險」，不安定土砂是「先掌握看得見的源頭」。它們沒有誰對誰錯，而是分別站在防災工作的不同環節上，各自做著不同的事。

・・・

04「內傷／外傷」這個比喻，到底在說什麼？

為什麼說潛勢區像內傷？

內傷的特點，是外表不一定看得出來。一個人可能自己覺得沒事，但醫生做完檢查，卻發現身體裡已經藏著一些隱患，將來可能演變成更嚴重的問題。潛勢區也是這個道理：坡面或野溪現在或許風平浪靜，可是把地形、地質、水文、歷史災害這些資料攤開來一看，就能判斷它其實已經具備了未來致災的條件。只要它又剛好可能影響到保全住戶，那就得提前納入警戒、避難、演練這一整套防災管理。

📌 潛勢區看的是「未來可能發生」；它是根據條件推估出來的風險，而且需要考量是否影響保全住戶。

為什麼說不安定土砂像外傷？

外傷就相反了，它最大的特徵就是「看得到」——傷口、腫脹、流血，即使還不至於惡化成嚴重感染，異常本身已經明明白白擺在眼前。不安定土砂也是如此：坡面上的殘坡、河道裡的大量淤積、上游累積起來、隨時可能再移動的土砂，這些都不是靠條件推算出來的可能性，而是現地或影像上，當下就能觀察到的事實。

💡 不安定土砂看的是「現在已看得到」；它是已經出現的顯性災害源，先納入掌握，再評估後續影響。

・・・

05這個比喻要注意什麼？

⚠️ 內傷與外傷不是在比較哪一種比較嚴重。外傷可以只是皮肉傷，內傷也可能危及生命。同樣地，土石流潛勢溪流、大規模崩塌潛勢區、不安定土砂，也不能簡單說哪一種一定比較危險。

這個比喻真正想凸顯的，其實只有一件事：它們被發現的方式不同，管理的起點也就不同。

潛勢區，是條件型的風險。它靠地形、地質、水文這些條件，判斷未來可能發生災害，而且可能影響到保全住戶——所以它的重點永遠落在「未來」和「有沒有人」。

不安定土砂，是顯性的災害源。它是現地已經看得見的不穩定土砂，現階段不先問有沒有保全住戶，而是先把問題本體掌握起來，再回頭評估它會不會影響道路、橋梁、聚落或下游——所以它的重點落在「現在」和「先掌握」。

・・・

06一張表看清楚差異

比較項目	土石流潛勢溪流 ／ 大規模崩塌潛勢區	不安定土砂
判斷基礎	地形、地質、水文等條件綜合推估	現地或影像已可辨識出顯性異常
保全條件	需考量是否影響保全住戶	現階段先不以保全住戶為前提
時間尺度	未來可能發生的潛在災害	近期可能移動、擴大或外溢的土砂
管理邏輯	劃定潛勢區，納入警戒、疏散與防災管理	先掌握災害源，再評估影響範圍與風險對象
白話比喻	像內傷	像外傷

・・・

07搞清楚這件事，為什麼重要？

把這幾個概念分清楚，並不是為了咬文嚼字。一旦把「防災警戒管理」和「災害源調查」混在一起，實務上就很容易出現幾種常見卻危險的誤判：

❌ 「這裡沒有潛勢溪流劃定，所以不用擔心土砂問題」——但現地可能已經有明顯不安定土砂正在累積。

❌ 「這裡有不安定土砂，所以要馬上疏散下游居民」——不安定土砂的掌握是調查與監測的起點，不等於立即致災。

❌ 「沒有在潛勢區範圍內就沒問題」——潛勢評估有其前提條件，不能全面取代現地調查。

這幾種誤判的共通點，都是把「推估未來風險」和「掌握眼前災害源」這兩件事攪在一起。分開來看，防災的每一步才站得穩。

📌 一句話記起來

土石流潛勢溪流、大規模崩塌潛勢區——問的是「未來哪裡可能發生災害，而且可能影響居民」，所以像內傷：條件評估出來的風險，需要持續追蹤與防災管理。

不安定土砂——問的是「現在有哪些已經看得到的不穩定土砂，需要先掌握並追蹤」，所以像外傷：顯性災害源的清查，先掌握問題本體，再評估影響。

兩者不是誰取代誰，也不是誰比較重要，而是坡地防災工作中分別回答不同問題的兩套工具。

本文為防災觀念釐清性質的科普說明，以幫助一般讀者理解土石流潛勢溪流、大規模崩塌潛勢區與不安定土砂三者的概念差異為目的。實際劃設標準與調查認定，仍依農業部農村發展及水土保持署、林業及自然保育署等主管機關之現行規範為準。

#坡地防災 #土石流潛勢溪流 #大規模崩塌 #不安定土砂 #防災觀念 #農村水保署