論述基礎與限制

磁碟空間診斷系列的寫作過程揭露了一個結構選擇：「空間不足」由 APFS 空間池、Cryptex 改變 Preboot 大小、iOS Simulator 多版本累積、App Container UUID 命名四個概念交互導致，把四個概念各自拆成獨立文章後讀者反而更容易自己推導整體狀況。從 #209 拆出後獨立成卡。case 集中在同一領域（macOS 磁碟管理）的多概念交互，跨領域的複合問題（例如效能問題涉及網路 + 資料庫 + 應用層）可能需要不同的串接方式。

核心原則

實際問題常由多個概念交互導致，但每個概念有自己的運作機制、自己的責任邊界。教學的展開結構是先各自教 A、B、C 的機制，再把 A×B×C 的交互作用談一次。

這個順序的依據是讀者的認知負荷。直接從交互作用切入（「你的磁碟滿了是因為 Preboot 8G + Simulator 33G + 遊戲容器 18G」），讀者拿到一份清單但不理解各項目為什麼這麼大。先教機制（Preboot 為什麼從 1G 變 8G、Simulator runtime 為什麼每組 16G），讀者理解各元件後，交互作用是自然推導的——三個各自合理的東西加起來超出預算，不需要另外記一條規則。

這次的情境

磁碟空間不足這個問題涉及四個獨立概念：

概念機制獨立文章
APFS container 空間池所有卷共用空間、Preboot 佔多少 Data 就少多少磁碟空間診斷
Cryptex 改變 Preboot 大小Apple Silicon 的安全更新機制讓 Preboot 從 1G 跳到 8GPreboot 卷
iOS Simulator 多版本累積每組 runtime 約 16G，裝兩組就 32G移除多餘 Simulator
App Container UUID 命名iOS on Mac App 用 UUID 命名、無法辨識佔用來源辨識 App 容器

每個概念獨立成篇，各自教機制。讀者讀完任何一篇都能處理該概念的問題。四篇合起來覆蓋「磁碟空間不足」的複合問題，讀者理解四個機制後就能自己判斷哪些該清、清多少、風險是什麼。

如果把四個概念塞進一篇文章，要嘛每個概念講不深（變成概述），要嘛文章過長讀者記不住。拆開後每篇聚焦一個機制，文章之間用連結串接，交互作用在各篇的「跟其他概念的關係」段落裡自然出現。

理想做法

複合問題的文章結構有三個關鍵判斷點。

各概念獨立成篇：每個概念有自己的機制、自己的操作、自己的判斷依據。文章之間用連結而非重複來串接。適合概念各自有足夠深度、讀者可能只需要其中一個概念的情境。

交互作用在哪裡談：如果 A 和 B 的交互作用本身就是一個值得獨立討論的議題，另開一篇；如果交互作用簡單（「A + B 加起來超出預算」），放在各篇的相關段落裡就夠了。判準是：交互作用需要的篇幅是否超過一兩段。

引用而非重複：如果 A 的機制已經在獨立文章裡教過，B 的文章引用 A 而不重複解釋。重複解釋會產生 SSoT 違反（#44 Single Source of Truth），而且兩篇的解釋會隨維護逐漸 drift。

跟其他原則的關係

  • #209 知識目標決定文章結構：判斷力導向的文章在面對多概念時自然走拆分結構——每個機制獨立教，讀者各自建立判斷力。
  • #44 Single Source of Truth：拆分後各概念只在一個地方深度解釋，其他地方引用。
  • #132 貫穿式案例是服務教材的教學骨架：複合問題的各概念用同一個案例串接時，案例本身就是貫穿線。磁碟空間系列裡「這台機器只剩 2G」是貫穿案例，四篇文章從不同角度解釋同一台機器的狀況。
  • AGENTS.md 原則三「商業邏輯先於 CASE」：先教各概念的系統層機制，再用複合問題當案例展示交互。

判讀徵兆

文章裡出現「另外還有一個原因是…」「除此之外也要注意…」的堆疊式展開，通常表示多個概念被塞在一起。每個「另外」後面如果是一個有自己機制的獨立概念，考慮拆成獨立文章。

另一個徵兆是文章寫到一半發現需要大量背景知識鋪墊——如果鋪墊本身就值得一篇文章，它應該是一篇獨立文章，當前文章引用它。