這個詞出現在「告警太多，反而沒人看」這個問題裡——它是這條因果鏈的終點。

alert fatigue（告警疲勞）指誤報與告警太多，人對告警逐漸麻木，連真正重要的也一起忽略。

要注意它和「誤報」本身不是同一件事：alert fatigue 不是 false positive 的另一個叫法，而是 false positive 持續累積造成的人因後果。源頭常見於醫療（病房監視器整天響）與資安維運。

怎麼形成

false alarm 與 noise 累積 → 每個告警的可信度下降 → 人開始預設「大概又是誤報」→ 真事件來時也被當誤報略過。測試領域的對應是把 flaky 紅燈一律重跑、不再查。

解法方向

• 降噪：提高告警 precision，少報無關的。
• 分級：可行動的才叫醒人，其餘進儀表板。
• 可行動性：每個告警都附「該做什麼」，否則它只是 noise。

相關概念

• 累積成它的來源：false positive、false alarm、noise。
• 測試領域的類比：flaky 被一律重跑。

這個詞出現在「告警太多，反而沒人看」這個問題裡。

false alarm（偽警報）指監控、告警或入侵偵測（IDS）系統觸發了，但實際上沒事——是 monitoring / 資安領域的 false positive。

「alarm」這個字面比 false positive 更口語、更早，消防與保全領域早就在用「假警報」。放到偵測語境，它就是 false positive 的一種。

為何要在意

單一 false alarm 只是虛驚，但累積會出兩個問題：

• 量大形成 noise，真警報被埋沒。
• 人對告警麻木，演變成 alert fatigue——連真的也不再認真看。

所以告警系統的設計重點之一，就是壓低 false alarm 率（提高 precision），同時別漏掉真事件。

相關概念

• 上位概念：false positive。
• 量多後的狀態與後果：noise、alert fatigue。

這個詞出現在「你的自動判斷會犯兩種錯：誤報與漏接」這個問題裡——它是另一種錯。

false negative（假陰性）指偵測器漏掉了真實存在的東西——說「沒有」，真實卻是「有」。它是 false positive 的另一半：兩者同屬混淆矩陣四格裡的兩個錯誤格。

• false positive（誤報）：說有、實無。
• false negative（漏接）：說無、實有。

各領域怎麼稱呼

和 false positive 一樣，false negative 換領域有不同叫法：

• 統計：Type II error（沒拒絕為假的虛無假設，漏掉真實效果）。
• 訊號偵測理論：miss（漏失），對應雷達「該偵測到敵機卻沒報」。
• 醫學：偽陰性（有病卻驗成陰性）。

和 false positive 的取捨

FP 與 FN 通常此消彼長：把偵測門檻調鬆、少漏接（FN 降），就容易多誤報（FP 升）；調嚴反之。要犧牲哪一個，取決於哪種錯誤代價更高：

• 癌症篩檢怕漏接（FN 致命），寧可多一些 FP 再複檢。
• 自動封鎖、垃圾郵件怕誤殺（FP 擾民），寧可放過一些再人工補。

這個取捨在統計裡就是 α 與 Type II error 的拉扯（見 Type I error），量化的尺則是 precision 與 recall——false negative 拉低的是 recall。

這個詞出現在「你的自動判斷會犯兩種錯：誤報與漏接」這個問題裡——它就是其中一種錯。

false positive（假陽性）指偵測器報了一個並不存在的東西——說「有」，真實卻是「沒有」。

這個詞最常見的接觸點是醫學檢驗（驗出陽性、其實沒病），因此常被當成醫學詞。它的源頭更早、也更通用。

源頭：訊號偵測理論

這組詞來自訊號偵測理論（Signal Detection Theory），問題情境源於二戰雷達操作員的研究：雷達螢幕上一個光點，是真的敵機，還是雜訊？「判定為敵機 × 實際是雜訊」就是一次 false positive。（正式理論在 1950 年代由心理物理學者整理成形，根源可追到這段二戰雷達研究。）

醫學診斷只是這套框架最有名的應用場，不是發源地。任何「偵測器給出判斷 × 真實狀態為何」的情境都套得上，所以它能跨領域通用。

為何各領域都用：二乘二的四格

偵測器的判斷（陽性/陰性）對上真實狀態（有/無），剛好四格——這就是 confusion matrix：

只要一個領域有「自動判斷 + 可驗證的真實狀態」，就需要這四格的詞彙。統計、程式、醫學、資安都是如此，所以共用同一組詞，而非各自另造。

各領域怎麼稱呼

同一個 false positive，換了領域有不同的本土叫法：

• 統計：叫 Type I error（假設檢定裡拒絕了為真的虛無假設），對應的還有顯著水準 α。
• 程式：false positive 本身就是第一線詞，描述不同切面還有更精準的本土詞（見下方相關概念）。
• 醫學：診斷檢驗的 false positive（偽陽性），是大眾最熟悉的用法。

相關概念

• 從哪個問題進來：你的自動判斷會犯兩種錯。
• 對偶錯誤：false negative（漏接，說無實有）。兩者是上方混淆矩陣的兩個錯誤格。
• 統計裡的編號：Type I error（= false positive）。

想看這個詞在測試、告警、規則誤觸等各情境的衍生說法，從 TIL／跨領域術語 的議題入口進入。

繁體中文的對應

中文圈通常用三個詞，語感略有差別：

• 誤報：偏「報出了不存在的東西」，最貼近 false positive 的偵測語境。
• 誤判：偏「判斷錯誤」，涵蓋假陽性與假陰性兩者。
• 假陽性：直譯，最精確但較學術。

所以「false positive 是不是借自醫學」這個問題，答案是：它是訊號偵測理論的通用詞，醫學只是借用者之一，程式與統計也各自借用並長出本土同義詞。

這個詞出現在「守衛和規則為什麼會誤觸」這個問題裡——它是結果視角。

false trigger（誤觸）指守衛或偵測器被「形似但其實不是真意圖」的輸入觸發——是 hook / guard 場景的 false positive。

與 over-match 的角度差

• over-match 是機制視角：規則涵蓋太寬。
• false trigger 是結果視角：守衛因此被觸發了。

同一件事的因與果——規則 over-match，於是守衛 false trigger。

一個典型例子

關鍵字守衛用「跳過審查」這組字偵測使用者的意圖。結果一則只是引用或討論「跳過審查」字樣的訊息也觸發了——命中了字面、但沒有真正要跳過的意圖。

這種「命中字面、無真實意圖」的 false positive 有個精準說法：lexical false positive（字面層假陽性）。修法是讓守衛在「明確是引用或討論」時抑制，但方向要保守——寧可偶爾誤觸（false positive），也別漏放真正的意圖（那會變成更危險的 false negative）。這個取捨方向，和 precision / recall 的選擇是同一回事。

相關概念

• 上位概念：false positive。
• 機制成因：over-match。
• 取捨的另一端：false negative。

這個詞出現在「測試紅燈不一定是真的壞」這個問題裡。

flaky test（不穩定測試）指同一份程式碼、同一個測試，什麼都沒改，卻有時過有時不過。

它是測試領域的 false positive——測試報紅、但被測的程式碼其實沒問題——而 flaky 特指其中「間歇、非確定性」的那種。

常見成因

• 競態（race condition）、依賴執行順序。
• 時間依賴：sleep、timeout、時鐘、時區。
• 共用狀態沒清乾淨：測試之間互相污染。
• 外部依賴：網路、第三方服務的暫態抖動。

為何危險

flaky 會侵蝕對測試套件的信任：紅了第一反應是點重跑而不是查 bug，久了連真的失敗也被當 flaky 忽略——這是測試版的 alert fatigue。

與 spurious failure 的區別

flaky 強調「間歇重現」（重跑可能就過）；spurious failure 強調「這次失敗的原因不是被測對象」，不一定間歇。兩者都是測試的 false positive，角度不同。

相關概念

• 上位概念：false positive。
• 近鄰：spurious failure、後果 alert fatigue。

這個詞出現在「告警太多，反而沒人看」這個問題裡。

noise（噪音）指大量 false positive 累積，淹沒了真正重要的訊號。

這個詞借自訊號處理的訊噪比（signal-to-noise ratio）：誤報越多，真訊號越難被看見。一個 linter 報出幾百條多半無關緊要的警告、一個監控系統整天閃 false alarm，都會被說成「noise 太多」。

為何是問題

noise 本身的每一條可能無害，但總量會壓垮注意力：真正該處理的混在裡面被略過。降噪（提高規則精度、過濾、分級）是讓真訊號重新浮現的前提。

後果

noise 持續累積會導致 alert fatigue——人對告警麻木。所以「降噪」不只是美觀問題，是維持偵測系統可用性的關鍵。

相關概念

• 組成 noise 的單位：false positive、false alarm、spurious warning。
• 人因後果：alert fatigue。

這個詞出現在「守衛和規則為什麼會誤觸」這個問題裡——它是機制成因。

over-match（過寬匹配，又稱 over-broad match、spurious match）指規則或樣式寫得太寬，命中了不該命中的東西。

如果說 false positive 是「偵測器誤報」這個現象，over-match 就是它在規則比對層常見的機制成因：不是偵測器壞了，是規則的涵蓋範圍超出了意圖。

常見場景

• regex 少了邊界或錨點：cat 命中 category、scatter。
• glob 太寬：*.test.* 連不想要的也掃進來。
• 關鍵字比對沒看上下文：命中了字面、卻不管語境。

怎麼收斂

把規則收窄到「恰好涵蓋意圖」：加邊界（\b）、加錨點、加上下文條件。收窄要拿捏——太寬會 over-match（false positive），太窄會漏掉真的（false negative）。這個拉扯就是 precision 與 recall 的取捨。

相關概念

• 它造成的現象：false positive、spurious warning。
• 結果視角：當守衛因 over-match 被觸發，就是 false trigger。

這個詞出現在「怎麼量一個偵測器準不準」這個問題裡——它是其中一把尺。

precision（精確率）回答一個問題：偵測器說「有」的那些，有多少是真的？

公式是 precision = TP / (TP + FP)（TP = 真陽性、FP = 假陽性）：分母是「所有被判為陽性的」，分子是其中真的陽性。所以 false positive 越多，precision 越低——誤報直接稀釋了「報出來的可信度」。

與 recall 成對

precision 只看「報出來的準不準」，不管「漏了多少」。漏接由 recall 衡量。兩者構成評估分類器的兩端，且通常此消彼長：把門檻調嚴、只報最有把握的 → precision 升、recall 降。

調和兩者的單一指標是 F1 score（precision 與 recall 的調和平均）。

什麼時候優先看 precision

當 false positive 的代價高、要求「報出來就盡量別錯」時：自動封鎖、自動下架、垃圾郵件丟棄——寧可漏一些（犧牲 recall），也別誤殺。

相關概念

• 被它懲罰的錯誤：false positive。
• 統計裡的對應：Type I error（誤報多則 precision 低）。
• 成對指標：recall。

這個詞出現在「怎麼量一個偵測器準不準」這個問題裡——它是另一把尺。

recall（召回率，又稱敏感度 sensitivity）回答另一個問題：真實存在的那些，偵測器抓到了多少？

公式是 recall = TP / (TP + FN)（TP = 真陽性、FN = 假陰性）：分母是「所有真的陽性」，分子是其中被抓到的。所以 false negative 越多，recall 越低——漏接直接拉低「抓全的能力」。

與 precision 成對

recall 只看「漏了沒」，不管「報出來的準不準」（那是 precision）。兩者通常此消彼長：把門檻調鬆、寧可多報 → recall 升、precision 降。調和兩者的單一指標是 F1 score。

什麼時候優先看 recall

當 false negative 的代價高、不能漏時：疾病篩檢、詐欺偵測、安全掃描——寧可多一些誤報（犧牲 precision）再人工複查，也別放走真的。

相關概念

• 被它懲罰的錯誤：false negative。
• 統計裡的對應：Type II error（recall 高對應檢定力高，兩者是同概念的不同 framing）。
• 成對指標：precision。

這個詞出現在「測試紅燈不一定是真的壞」這個問題裡。

spurious failure（偽失敗）指測試或建置確實失敗了，但失敗的原因是環境、網路、暫態干擾、基礎設施問題——被測對象本身沒有問題。

它是測試的 false positive：報了失敗、但程式碼其實沒問題。

與 flaky 的區別

兩者都是測試的 false positive，重點不同：

• spurious failure 強調「這次失敗的原因不是真因」——例如 CI 機器磁碟滿了、套件源連不上。
• flaky 強調「間歇、不穩定」——重跑可能就過，成因常是競態或時序。

一次 spurious failure 不一定 flaky（環境修好就穩定失敗或穩定通過）；flaky 的每次紅則多半是 spurious——除非不穩定源自被測碼自身的非確定性（那時紅燈反映的是真缺陷，不是偽失敗）。

處理

確認是偽失敗後，修的是環境或基礎設施，不是被測程式碼。把它和真失敗區分開，避免污染對測試的信任（見 alert fatigue）。

相關概念

• 上位概念：false positive。
• 近鄰：flaky。

這個詞出現在「守衛和規則為什麼會誤觸」這個問題裡——它是 linter 切面。

spurious warning（偽警告）指靜態分析、linter 或編譯器報了一條警告，但其實沒有問題——是 linting / 編譯領域的 false positive。

常見成因

• 規則訂得過嚴，把合法寫法也圈進去。
• 分析器無法證明某段安全，於是保守地報警（寧可誤報也不漏報）。
• 規則的比對範圍太寬，見 over-match。

處理

確認是偽警告後，可用 inline 抑制（如 // nolint、# noqa）關掉那一處——但要保守：抑制範圍越窄越好，否則容易把真問題一起關掉。抑制過頭、警告太多沒人理，就變成 noise。

相關概念

• 上位概念：false positive。
• 機制成因：over-match。
• 量多後的狀態：noise。
• 測試領域的同類偽訊號：spurious failure。

子分類：

• 單字：學到的英文單字 — 字源拆解、由來故事、同字根家族
• 跨領域術語：同一個概念在不同領域的稱呼 — 一個領域 framing 一篇、互連成「概念↔領域語」地圖

還沒成氣候的知識點直接放本資料夾根層、同主題累積三篇以上再開子分類。

跟其他資料夾的邊界

寫作前先依序評估：

1. 是 blog 本身設定 / Hugo / Markdown 議題？ → posts/
2. 是工作中用某工具遇到的事件？ → work-log/
3. 是中性 frame 的工作方法論？ → record/
4. 是從 case 抽出的工程原則？ → report/
5. 是 OS / 工具小技巧？ → other/
6. 跟工程無關、純粹是學到的知識點 → 本資料夾

判斷軸是「跟工程工作的距離」：前五個資料夾都服務工程脈絡、本資料夾收工程之外的學習。一個知識點若同時有工程應用（例如某演算法的歷史），以工程價值為主就放對應教材區、以故事本身為主就放這。

底下自動列出本資料夾的所有文章、依日期排序。

這個詞出現在「你的自動判斷會犯兩種錯：誤報與漏接」這個問題裡——它是統計學給「誤報」的編號。

統計學的假設檢定，把 false positive 編號叫 Type I error、把 false negative 叫 Type II error。

兩個編號的意思

假設檢定先立一個虛無假設（H₀，預設「沒有效果 / 沒有差異」），再用資料決定要不要拒絕它：

• Type I error（型一錯誤）：H₀ 其實為真，卻拒絕了它——宣稱「有效果」，實際沒有。這就是 false positive。
• Type II error（型二錯誤）：H₀ 其實為假，卻沒拒絕——漏掉了真實存在的效果。這就是 false negative。

與顯著水準 α 的關係

設計檢定時會先訂一個 顯著水準 α（常見 0.05），它就是容許的 Type I error 機率上限。在樣本數固定的前提下，把 α 設得越小，越不容易誤報（Type I 降低），但相對更容易漏掉真實效果（Type II 升高）——兩者此消彼長，這是檢定設計的核心取捨。（加大樣本數則可同時壓低兩者。）

一個好記的順序

哪個是 Type I、哪個是 Type II 容易記混。一個記法：Type I 是「太急著宣稱有」（過度反應、誤報），Type II 是「太保守而漏掉」。可把編號順序記成「先有過度反應，才談漏接」——這純為助記，不是 Neyman-Pearson 當初編號的歷史定義。

相關概念

• 概念本身與源頭：false positive。
• 對偶錯誤：Type II error（= false negative）。
• 量化的尺：precision（誤報多則 precision 低）。
• 程式領域描述同一件事的本土詞：over-match、false trigger、spurious warning 等。

這個詞出現在「你的自動判斷會犯兩種錯：誤報與漏接」這個問題裡——它是統計學給「漏接」的編號。

Type II error（型二錯誤）是 false negative 在統計假設檢定裡的編號：虛無假設（H₀，預設「沒有效果 / 沒有差異」）其實為假，卻沒拒絕它——漏掉了真實存在的效果。

它和 Type I error（誤報、宣稱有實無）成對：

• Type I：H₀ 為真卻拒絕 → false positive（誤報）。
• Type II：H₀ 為假卻沒拒絕 → false negative（漏接）。

β 與檢定力

Type II error 的機率記為 β。與它互補的是檢定力（statistical power）= 1 − β，也就是「H₀ 確實為假時，正確抓到的機率」。提高檢定力（少漏接）通常靠加大樣本數或放大效果量。

把 β 對應到偵測語境，「少漏接」就是提高 recall——兩者衡量的是同一件事的不同領域 framing。

相關概念

• 對偶錯誤：false positive / Type I error。
• 同概念的偵測語境：false negative。
• 量化的尺：recall（被 false negative 拉低）。

因、果、與一個切面

• 機制（因）：規則涵蓋範圍超出意圖，叫 over-match（過寬匹配）。
• 結果（果）：守衛因此被形似但非真意圖的輸入觸發，叫 false trigger（誤觸）。
• linter 切面：靜態分析報的偽警告，叫 spurious warning。

怎麼想這件事

誤觸不是「偵測器壞了」，是規則的範圍沒收好。收窄規則時要拿捏：太寬會誤觸（誤報），太窄會漏掉真的（漏接）。這個拉扯就是怎麼量偵測器裡 precision 與 recall 的取捨。

從這裡往下讀

• over-match：規則過寬而誤命中。
• false trigger：守衛被誤觸。
• spurious warning：linter 的偽警告。

兩種錯

• 說「有」但其實沒有 → 誤報（false positive）。
• 說「沒有」但其實有 → 漏接（false negative）。

把判斷（有/無）對上真實（有/無），剛好四格——這張判斷×真實的對照表叫混淆矩陣，false positive 那篇有完整版。

為什麼值得分清楚

因為兩種錯的代價往往不對稱，而且通常此消彼長：壓低一種會抬高另一種。癌症篩檢寧可誤報也不能漏接；自動封鎖寧可漏放也別誤殺。先想清楚「哪種錯更貴」，才知道偵測器該往哪邊偏。

從這裡往下讀

• 想徹底搞懂這兩種錯：false positive、false negative。
• 統計課對這兩種錯的編號：Type I error（= 誤報）、Type II error（= 漏接）。
• 想用數字衡量這兩種錯有多少：見怎麼量一個偵測器準不準。

從一條誤報到沒人看

這是一條因果鏈：

• 一條監控的誤報叫 false alarm（偽警報）。
• 大量誤報累積、淹沒真訊號，這個狀態叫 noise（噪音）。
• 人因此對告警麻木、連真的也忽略，這個後果叫 alert fatigue（告警疲勞）。

為什麼是設計問題

因為每一條告警單看都「沒錯」，問題出在總量。所以解法是系統性降噪：提高告警的 precision、分級、讓每條告警都可行動。降噪不是美觀問題，是讓偵測系統還有人看的前提。

從這裡往下讀

• false alarm：監控的偽警報。
• noise：淹沒真訊號的誤報。
• alert fatigue：告警疲勞。

兩把尺

• precision（精確率）：報出來的之中，有多少是真的？被誤報拉低。
• recall（召回率）：真的之中，抓到了多少？被漏接拉低。

為什麼要兩把

因為只看一把會被騙。一個偵測器只要「什麼都不報」，就永遠不誤報、precision 看起來無敵——但 recall 是零，全漏了。反過來「全部都報」recall 滿分、precision 慘不忍睹。兩把一起看，才知道它是真準還是在作弊。

兩者通常此消彼長，調和成單一數字是 F1 score。要偏哪一把，回到誤報與漏接哪個更貴的判斷。

從這裡往下讀

• precision：報出來的有多少是真的。
• recall：真的之中抓到多少。

兩種「假紅燈」

• flaky：同一份程式碼、什麼都沒改，卻時過時不過。問題在測試的不穩定（競態、時序、共用狀態）。
• spurious failure：這次失敗的原因不是被測對象——是環境、網路、CI 機器的暫態。

為什麼要分清楚

因為修的地方不同：flaky 要修測試本身的不穩定，spurious failure 要修環境或基礎設施。更重要的是，把假紅燈和真失敗混在一起，會讓人養成「紅了先重跑」的反射，久了連真 bug 都被當假紅燈忽略——這就是測試版的告警疲勞。

從這裡往下讀

• flaky：時綠時紅的測試。
• spurious failure：偽失敗。

第一組詞圍繞「false positive（誤報）」展開。建議從你遇到的問題進入——下面每個議題頁會把你導向該讀的術語卡，而不是劈頭背定義：

從問題進入

• 你的自動判斷會犯兩種錯：誤報與漏接 —— false positive、false negative、Type I／II error
• 怎麼量一個偵測器準不準：—— precision、recall
• 測試紅燈不一定是真的壞：—— flaky、spurious failure
• 告警太多，反而沒人看：—— noise、false alarm、alert fatigue
• 守衛和規則為什麼會誤觸：—— over-match、false trigger、spurious warning

每張術語卡頂部都會標明它出自哪個問題，所以從搜尋直接落在單張卡也找得到回路。

底下自動列出本分類的所有篇章、依日期排序。

字根拆解

• cand-：發光、白色、閃耀（拉丁文 candēre「發白光、發亮」）
• -id-：形容詞性的連接成分
• -ate / -ātus：過去分詞語尾，表「具有⋯性質的人」

由來

古羅馬競選公職的人會穿著用白堊漂白的純白托加長袍（toga candida），象徵純潔與清白，以爭取選民信任。「穿白袍的人」因此引申為「（求職、競選的）候選人」。

同字根家族

cand-（白、發光）這個字根串起一整組單字：

• candid（坦白的、率真的）：源自「白、純淨」的意象
• candle（蠟燭）：發光之物
• candor / candour（坦誠）：candid 的名詞形
• incandescent（白熾的）：in-（加強）+ candēre，燒到發白光
• candela（燭光）：光度的 SI 單位、直接借自拉丁文「蠟燭」

記住 candēre = 發白光，這五個字加上 candidate 就全部串起來了。

典型內容：

• candidate 的字源：穿白袍的人

底下自動列出本分類的所有單字、依日期排序。

一般英文中的意思

snippet 原本是「片段」或「摘錄」。

• 可以是一小段文字
• 也可以是程式碼、對話、影像或聲音的片段
• 重點是它是從整體中切出來的一小部分

template 是「模板」或「範本」。

• 表示一個可以反覆套用的格式
• 通常會保留一些空位，等人填入內容
• 重點是「先有結構，再填資料」

skeleton 是「骨架」。

• 表示最基本、最少的框架
• 還沒有完整細節
• 重點是「先把架構立起來」

技術寫作中的意思

在技術文件、程式開發、教學內容裡，這三個詞常常各自負責不同層級的重用。

snippet

通常指短小、可直接插入的內容片段。

• 一小段程式碼
• 一小段設定
• 一小段說明文字
• 一小段固定格式的提醒

它的特徵是短、穩、可重複使用。

template

通常指帶欄位的完整格式。

• 有固定順序
• 有需要填寫的位置
• 適合反覆產生同類內容

它的特徵是完整、可套用、可替換變數。

skeleton

通常指最小可用的結構輪廓。

• 先定大標題與章節
• 細節之後再補
• 常用在草稿、設計、規劃階段

它的特徵是先搭架構，再補內容。

情境式範例

1. snippet 的例子

你在寫信時，常常會重複用到一句固定話術，例如：

請在方便時回覆。

這句話就是一個 snippet。它短、固定、可以直接貼上。

如果你每次都要通知對方資料格式，也可以保留一小段固定內容，例如：

姓名：___

日期：___

這種短段落也屬於 snippet 的概念。

2. template 的例子

如果你要寫一封活動通知，可以先準備一個模板：

1標題：{活動名稱}
2
3時間：{日期}
4地點：{地點}
5對象：{受邀者}
6說明：{補充內容}

這就是 template。

• 結構先固定
• 需要的資料留空
• 每次只要填入不同內容就能使用

3. skeleton 的例子

如果你要先寫一篇文章，但還沒想好內容，可以先畫出骨架：

1# 主題
2
3## 背景
4
5## 問題
6
7## 方法
8
9## 結論

這就是 skeleton。

• 只有章節
• 沒有細節
• 目的是先把文章的基本輪廓立起來

三者比較

直覺分辨法

如果要用最簡單的方式分辨：

• snippet 是「拿來貼的短段」
• template 是「拿來填的格式」
• skeleton 是「拿來搭的骨架」

也可以這樣記：

• snippet 解決「每次都要重寫同一句」
• template 解決「每次都要重建同一種格式」
• skeleton 解決「先把架構搭起來，再慢慢補細節」

什麼時候用哪一個

• 想重用短句或固定提醒時，用 snippet
• 想重複產生同類文件或表單時，用 template
• 想先把內容架構起來、還沒準備好細節時，用 skeleton

結論

這三個詞都可以翻成「片段」或「範本」的近義概念，但在技術寫作裡，它們的分工很清楚：

• snippet 偏短，重點是可直接重用
• template 偏完整，重點是可套用的格式
• skeleton 偏框架，重點是先有架構再補細節