論述基礎與限制

9 篇 macOS 文章原本放在兜底資料夾（content/other/）。拆出 APFS 卷結構和 iOS Simulator 架構兩篇獨立機制文章後，加上既有的 Preboot、App Container、磁碟診斷等文章，主題群聚變得明顯——這些是一個有結構的 macOS 系統管理主題，不是「沒地方放的雜項」。建立 content/macos/ 分類是文章累積到臨界量後的自然動作。case 來自持續累積的內容體系，一次性交付的文件專案可能適合先規劃分類。

核心原則

分類是內容的組織結構，它的合理性取決於底下有沒有足夠的內容支撐。文章拆分到獨立機制的深度後（#211 複合問題先拆機制再談交互），主題群聚會自然浮現——同一個領域的概念各自有了獨立文章，它們之間有引用關係，放在一起比散落在兜底資料夾更容易被發現和導航。

這個順序是內容先於分類，不是分類先於內容。先建空分類再填文章有兩個風險：分類太早建立時底下只有一兩篇文章（稀疏分類，讀者看到空架子會懷疑內容完整性）、以及文章為了填進預設分類而扭曲主題（錯誤歸屬，文章的主線被分類名稱牽著走）。

這次的情境

macOS 文章在 content/other/ 裡的演變過程：

階段文章數狀態
磁碟診斷 + App 佔用2 篇放 other/ 合理，macOS 技巧跟 Android、Chrome 混在一起
加 Preboot、Simulator 刪除、Container 辨識5 篇開始覺得 macOS 佔比偏高，但各篇獨立、沒有共同結構
加 APFS 卷結構、Simulator 架構（獨立機制文章）7 篇主題群聚明顯——系統架構層的文章互相引用，形成教學體系
加 App Sandbox、iOS App on Mac9 篇浮現三層結構（系統架構 / 磁碟管理 / 環境設定），other/ 不再合適

觸發建立分類的訊號是第三階段：寫獨立機制文章（#211）時，文章之間的引用關係讓主題結構可見。APFS 文章被 Preboot 和 Simulator 引用、App Sandbox 被 Container 辨識和 iOS App on Mac 引用——這些引用關係構成的網就是分類的邊界。

如果在第一階段就建 content/macos/，底下只有兩篇磁碟相關文章，分類名稱（macOS）跟內容（磁碟排查）不匹配，而且後來加入的新機設定、多桌面快捷鍵這些文章跟磁碟無關，事先規劃的分類結構會失準。

理想做法

兜底資料夾是暫存區，不是垃圾桶。文章一開始放在兜底資料夾是正常的——新主題還沒累積到足夠深度，硬分類比不分類更糟。但兜底資料夾需要定期檢視：多篇同主題文章聚集時就是浮現訊號。

浮現訊號的判準：

  • 同一個兜底資料夾裡有 3 篇以上文章共享主題關鍵詞
  • 文章之間出現相互引用（引用關係是結構的客觀證據）
  • 新文章寫入時作者自然想到「這跟前幾篇是同一個主題」

建立分類的時機：浮現訊號出現 + 能寫出有意義的 _index.md（分類首頁能列出結構層次——概念層 / 操作層 / 環境層，而不只是按時間排列的文章清單）。

多輪審查中的提醒：reviewer 掃到兜底資料夾時，可以加一個 frame——「這個資料夾裡有沒有主題群聚？」。這個 frame 在文章數量增加後定期檢查，不需要每輪都跑。

跟其他原則的關係

  • #212 不屬於這篇的內容要找出路：找不到出路的內容可能指向一個不存在的分類。#212 是單篇層面的路由，#213 是多篇層面的組織。
  • #211 複合問題先拆機制再談交互：拆分文章到獨立機制的深度是分類浮現的前置條件。沒拆分時所有概念塞在少數幾篇裡，看不出群聚。
  • #139 新增頂層 content 資料夾要同步首頁入口：分類建立後的機械工序——首頁 _index.md 要同步加入口。#139 處理建完之後的同步，本卡處理何時該建。
  • AGENTS.md Content 資料夾分類流程段：本卡補充「何時從 other/ 畢業」的判準，AGENTS.md 的判斷流程處理「新文章放哪」。

判讀徵兆

content/other/（或任何兜底資料夾）裡出現 3 篇以上同主題文章、且文章之間有相互引用，就是分類浮現的訊號。另一個徵兆是 _index.md 的典型內容列表裡出現明顯的群組（本次案例：9 個 macOS 開頭的條目擠在 other/ 的列表裡，視覺上就知道它們該有自己的家）。