論述基礎與限制

本卡的論述源於 1 個觸發 case（git stash -u 筆記的 review、使用者指出尾端「重點」段沒有必要）、再以 1 次 content/ 全站掃描（309 個總結型段落、Go 模組 53 章樣本、見下方「blog 樣本掃描」段）驗證與擴充。具體限制：

  • 「重點段」是這次出現的形式、不是唯一形式：同類補丁還有「一句話總結」「TL;DR」「小結」「劃重點」。判準不在標題名稱、在「這段是否只是重述前文已講過的內容」。
  • 不是所有 summary 都是補丁：長篇 / 多章模組的導覽型 summary（串連各章、給路由）有獨立價值、不適用本卡。本卡針對的是「單篇短文尾端重述自己」這種發散善後。
  • 修補有效性未獨立驗證：刪掉總結段後讀起來更聚焦、但「有沒有總結段」跟「讀者實際記憶留存」之間沒做使用者測試。

讀者使用本卡時、先判斷該 summary 段是「重述前文」還是「跨段路由 / 導覽」—— 前者套用、後者保留。

核心原則

教材把概念講清楚的責任落在正文、不落在尾端的總結段。 若一篇文章要靠「重點」段重述才能讓讀者記住、那訊號不是「需要總結」、是正文發散 —— 概念沒在它該出現的位置一次講清、被攤散在各段、所以尾端要再收一次。正確的回應是重組正文、不是補一個總結段替發散善後。

判準很簡單：刪掉總結段、看正文站不站得住。

  • 站得住 → 總結段本就冗餘、刪掉是淨減負擔。
  • 站不住 → 問題在正文組織、該重拆段落、不是靠總結救。

兩種結果都指向「不該留總結段」。總結段唯一看似合理的存在理由（怕讀者沒記住），恰好是正文設計不佳的徵兆 —— 用補丁掩蓋了該修的結構。

處理總結段內容：先分「提醒 vs 概念」

刪總結段的第一步是辨識段內每一條的性質，決定併回正文還是直接刪：

內容性質具體例子處理
純提醒 / 喊話「開新功能要養成順手加 -u 的習慣」「記得回頭確認」刪 —— 提醒不傳遞新概念、讀者需要時自己回前文
有概念價值「為何 Git 預設不收 untracked：因為常是編譯產物、log」併回正文 —— 移到它本該所屬的概念段、一次講清
純重述把表格 / 流程再用文字講一遍刪 —— 跟前文重複、是發散的直接證據

關鍵動作是「併回」而非「丟棄」：總結段裡常混著真正屬於正文卻被擠到尾端的概念（例如某設計選擇的理由）。把它移回該概念出現的段落、既刪了補丁、又補強了正文的「核心原則先行」。

沒這樣做的麻煩

補丁掩蓋結構問題、發散持續累積

留著總結段、等於接受「正文可以發散、尾端再收」。下一篇繼續發散、繼續補總結、文章組織能力不會進步。總結段是止痛藥、不是治療 —— 它讓「正文沒講清」這個真問題不痛、於是沒人去修。

讀者付兩次成本讀同一概念

重述型總結讓讀者讀第二遍已經懂的內容。懂的人覺得冗、沒懂的人靠重述也補不上（重述不會比正文講得更清）。兩種讀者都沒得到淨價值、只多付了 token。

概念價值被埋在補丁裡、正文反而缺角

總結段常混著本該在正文的概念（設計理由、邊界條件）。塞在尾端、正文對應位置反而缺了這塊 —— 讀者讀到正文時概念不完整、要讀到最後才補上。這違反「核心原則先行」、把該前置的概念後置成總結。

跟其他抽象層原則的關係

  • #64 Feature 操作要跟 Source 同層合成：本卡是該原則在寫作層的同構。#64 講「filter / 操作要在 source 同層或更上游做、不在下游補」、本卡講「概念要在正文（source）講清、不在尾端總結（下游）補」。兩者共享「修在源頭、不在下游打補丁」的骨架 —— 總結段就是寫作版的 post-source patch。
  • #150 教材用中性陳述、不對讀者喊話：兩卡常在同一段命中、但軸不同。#150 是字句層 / stance（「養成習慣」是祈使喊話）、本卡是結構層（整個總結段是組織補丁）。一個總結段可能同時是 #150 的喊話載體跟本卡的結構補丁 —— 修法也不同：#150 改句子 register、本卡刪整段並重組正文。
  • #151 教材給技術理由、不替方案下品質評價：兩卡都在問「這段內容該不該留在教材」。#151 砍的是「自評誇飾」（不傳遞概念的品質 verdict）、本卡砍的是「重述總結」（不傳遞新概念的結構補丁）。共同判準：不貢獻新概念的內容、不論它讀起來多像收尾、都是負擔。
  • #153 Review 漏抓先分 design gap 與 execution gap：本卡的「刪總結 vs 重組正文」是 diagnose 先於修法的同類動作。看到總結段別直接刪了事 —— 先用「刪掉正文站不站得住」診斷：站得住是冗餘（execution-side、刪即可）、站不住是正文發散（design-side、要重組）。診斷錯就會「刪了總結、發散的正文還在」。

判讀徵兆

徵兆該做的行動
文章尾端有「重點 / 小結 / 一句話總結 / TL;DR」段先問「這段是重述前文、還是跨段路由」—— 重述就是補丁候選
總結段每一條都能在前文找到對應純重述、刪 —— 讀者需要時回前文即可
刪掉總結段後正文仍完整證明總結冗餘、刪是淨減負擔
刪掉總結段後正文「少了關鍵概念」不是總結要保、是那個概念該併回正文對應段落
總結段混著「養成習慣 / 記得 / 別忘了」純提醒、刪 —— 提醒不是教材的責任（連 #150）
自問「沒有這段、讀者會看不懂嗎」答不會補丁確認 —— 刪
總結段是「一段重述 + 一句下一章路由」混合型 —— 外科式切重述段、留路由句、別整段刪
同一模組每章都有結構雷同的小結系統性補丁 —— 在模組層級統一定義小結責任、別逐章判

適用範圍與邊界

  • 適用：單篇文章 / 卡片尾端「重述自己」的總結段 —— 重點、小結、一句話總結、劃重點、TL;DR。這些地方若只是把前文再講一遍、就是發散善後。
  • 不適用：跨章模組 / 長篇的導覽型 summary（串連各章、給下一步路由、列模組地圖）—— 它傳遞「結構關係」這個正文沒有的新資訊、不是重述。report/ 的 _index.md 路由段、教學模組的章節導覽都屬此類。
  • 邊界：判別線是「這段傳遞新資訊（含結構 / 路由關係）、還是重述已講過的內容」。前者保留、後者刪。長度不是判準 —— 短文也可能有合理的路由段、長文也可能塞冗餘總結。
  • 位置反轉的例外：前置摘要不是尾端重述：放在文首的摘要（frontmatter description、開頭一段 abstract）跟尾端重述性質相反 —— 它服務「讀者決定要不要讀、先建立全局框架」、在讀者還沒讀正文時提供導航價值。尾端重述則是在讀者讀完之後把已知內容再講一次、無導航功能。同樣一句「本文講 X 的三個取捨」、放文首是合理摘要、放文尾就是重述補丁。判別不只看「是否重述」、還看「相對正文的位置決定它服務的是導航還是回顧」。

blog 樣本掃描：三種變體與外科式修法

對 content/ 掃「小結 / 總結 / 結論」當標題的段落、309 個檔案命中。Go 教學模組是密度最高的樣本：53 章每章一個 ## 小結、但只有 10 個含「下一章」路由、其餘 43 個是純重述章節核心原則。這不是偶發、是模組層級的系統性習慣 —— 也讓「總結段=補丁」這個判讀有了規模證據。

樣本分成三種變體、各自修法不同：

變體真實樣本性質修法
純重述型channel.md「channel 的重點是資料流、同步點與所有權邊界」、interfaces.md「Go interface 的核心是用行為定義依賴」整段重述正文已建立的核心原則、無路由、無新資訊刪或重組正文（本卡典型對象）
重述 + 路由混合型control-flow.md：一段重述（控制流程刻意維持少量語法）+ 一句路由（下一章回到 package）一段補丁包著一句合理路由外科式：切重述段、留路由句
綜合關係型llm/application-protocols.md「Function calling 是模型能力、structured output 是 sampling 約束、MCP 是 server 協議 —— 三者層級不同、組合使用而非競爭」把正文分散講過的多個概念並置成一個關係 frame語意判定：正文若從未在一句並置這個關係、屬新結構資訊、保留

兩個從樣本提煉的補充、修正了「整段刪」的過度簡化：

  • 真實世界最常見的是混合型、不是純補丁：一段重述包著一句路由。對混合型套用本卡、修法是外科式（切重述、留路由 / 綜合關係）、不是整段刪。判別線下沉到「段內每一句」、不是「整段留或刪」。

  • 系統性出現時在模組層級統一決定、不逐章補丁：當整個模組每章都有小結（Go 53 章），逐章判斷會反覆做同一決定。該在模組層級先定義「小結的責任」（只放跨章路由 / 跨章綜合、不放單章重述）、再一次套到全模組 —— 否則就是本卡反對的「為發散補補丁」在模組尺度重演。

    升格條件（候選獨立卡）：「smell 系統性出現 → 在模組 / 政策層級統一修、不逐實例補丁」這條、語意上正交於「總結=發散」、且可泛化到 cadence 同骨化（#122）、emoji、任何系統性寫作 smell —— 是 #64「修在 source」往「修法尺度要匹配問題尺度」的泛化。目前只有 1 個 instance（Go 小結）、按 #42 兩次門檻暫不抽卡（避免過早抽象 / framework bloat）。當第二個系統性寫作 smell 出現同樣「逐實例 vs 模組政策」張力時、即有 2 instance、抽成獨立卡。

  • 綜合關係型是導覽型例外的近親、但要語意驗證：「三者層級不同」這種並置、若正文從未在同一處講過這個關係、就是新資訊（傳遞結構）、不是重述。判別問「這句陳述的關係、正文有沒有在某段一次講過」—— 沒有則保留、有則仍是重述。

Self-case：本卡的觸發來源

本卡觸發於 review git stash -u 筆記 時、由使用者指出尾端「重點」段沒有必要：

重點這一塊是沒有必要的、如果讀者需要他可以自己回頭確認、不用預設讀者需要重新提醒。如果我們的文章一定要寫重點才能讓讀者記住、表示我們的文章內容太過發散、這時候要考慮的是重新拆分組織文章內容、而不是為了自己文章的設計不佳又多補一個重點章節。

該「重點」段有三條：

  1. 「開新功能幾乎一定有 untracked 檔案、要養成順手加 -u 的習慣」 —— 純提醒（養成習慣）、且跟「問題情境」段已講的重複。刪。
  2. 「為何 Git 預設不收 untracked」 —— 有概念價值、解釋了 -u 為何要明確表態。併回「-u 是什麼」段、放在表格之後、讓設計意圖在概念位置一次講清。
  3. 「記憶法：-u = untracked、-a = …」 —— 跟表格重複的重述。刪、把 -a 的範圍差異併進前述設計意圖段。

刪掉「重點」段後、正文（問題情境 → -u 是什麼含設計意圖 → 正確流程 → 替代做法取捨）仍完整、且因為概念併回正文反而更聚焦 —— 證明總結段本就是補丁、不是必要結構。

對應本卡：總結段的存在價值（怕讀者沒記住）恰好是正文發散的徵兆 —— 修法不是保留總結、是重組正文、把該前置的概念前置、該刪的提醒刪掉。