一篇文章的範圍是兩個限定的交集：標題寫出的對象，以及它所在分類已經限定的條件。作者在分類裡寫標題時，分類的條件對他是給定的，所以標題常常不寫它——當時放在 Python 重構模組裡的〈從修改競爭判斷拆檔〉（後來搬到軟體設計原則模組），作者不需要在標題寫「Python」或「程式碼」。標題因此比文章實際的範圍寬。題目範圍檢查只拿段標去比標題時，一節講得比分類更泛的段落會落在標題的範圍內而通過。

失效的形態

從修改紀錄畫模組邊界（當時題為〈從修改競爭判斷拆檔〉）當時放在 python/07-refactoring，那個模組的 description 寫的是程式碼品質改善指南。文章末尾有一節〈文字文件的拆分〉，把同一套方法套到規則文件、操作手冊與範本上。那一節的每一句都成立，而且直接延伸前文的論點。

拿段標對標題逐一判定時，這一節判在範圍內：標題講的是「拆檔」，文字文件也是檔案。拿它對分類判定，它落在範圍外：Python 分類收的是 Python 程式碼，文字文件的拆分與語言無關。讀者指出的正是這一點，而且指出它違反的是這篇文章自己在教的單一職責——放在這裡的一節，修改的理由是文件寫作的做法改了，不是 Python 的做法改了。

同一個模組裡還有第二種形態：〈非程式碼的重構〉整篇講規則文件的精簡。這一篇的標題本身就寫出了它在分類範圍外，標題與分類兩個限定在標題那一層已經對不上，比對分類時整篇落在範圍外。

範圍的兩個來源

標題限定的是這一篇承諾交付什麼。分類限定的是讀者從分類列表、麵包屑或網址進來時已經帶著的條件：這個分類收哪一種語言、哪一個抽象層、哪一類對象。分類的條件寫在它的目錄頁 description 與簡介裡，也寫在站點的分類規則裡（例如 backend 寫語言無關的服務能力、語言模組只寫實作）。

兩個來源各自能讓一節落在範圍外，所以檢查要兩個都比，判定也分開記：

在標題範圍內在分類範圍內處置
是是留在原處
是否移到承接它的分類，原處留一句連結
否否照標題範圍檢查的既有處置（移出獨立成篇，或刪掉推導連接詞）
標題本身落在分類外—整篇移到承接它的分類，舊網址用 aliases 保留

移出去的目的地要承接那個主題，移動的形式是路由不是刪除：原處留一句寫出目的地交付什麼的連結。

為什麼既有的檢查沒擋住

題目範圍檢查（#299）的比對對象只有標題。寫標題的人手上有分類這個前提，審查者拿到的稿件路徑也帶著分類，所以兩者讀「拆檔」時都自動補上「Python 的」，補完之後那一節看起來就在範圍外——而規則照字面只比標題，比完它在範圍內。

另一道會擋住它的檢查是單一職責的變動理由測試：那一節與其餘各節的修改理由不同。這道測試以「一篇文章越寫越長」為觸發條件，而這篇文章不長，觸發條件沒有啟動。觸發條件的問題另見 #377。

檢查與修法

題目範圍檢查的逐段標表加一欄「在不在所屬分類的範圍內」。判定時打開所屬分類的目錄頁讀它的 description 與簡介；目錄頁沒有寫出限定條件時，以站點的分類規則為準。這一欄與標題那一欄分開判，因為兩者會給出不同的結果，合併成一欄時審查者只會比他手上比較具體的那一個。

移動的目的地照站點的分類流程選，並確認目的地確實承接這個主題（#240）；原處留下的那一句要寫出目的地交付什麼，讀者遮住連結之後仍說得出那一篇會給什麼。

寫作的當下同一個問題可以先問一次：要加的這一節，換到同一站的另一個分類底下會不會更合適。

判定上的補充（2-C 分類欄第一次實際使用時的回饋）：

  • 換掉限定詞句子不用改，不等於落在分類外。 同一篇裡分類內的實作節依賴這一節的論證時（Python 拆檔教材裡語言無關的修改競爭原則，撐起後面拆 Python 模組的做法），這一節判在範圍內；把它搬走，留下的實作節就沒有論證。
  • 目錄頁的描述可能混著出處條件（「基於某段版本的重構經驗」）。判定只取主題條件（「程式碼品質改善」），出處條件不限定內容範圍。

論述基礎與限制

證據是一篇文章的一節、同一個模組裡的另一篇，以及一位讀者的指認。分類條件從目錄頁 description 讀出來的做法在一次三篇的審查裡用過，那一次分類欄判出了標題欄判不出的一處（程式碼分類裡的 CHANGELOG 與索引例子），也確認了上面的補充；description 只寫主題、沒寫限定條件的分類，判定會落回站點規則，那一步的一致性沒有量過。

跟其他抽象層原則的關係

判讀徵兆

  • 讀者說「這一節不屬於這裡」，而那一節在標題的範圍內。
  • 一節內容換掉分類就完全成立，例如把「Python」換成任何語言、或把「程式碼」換成「文件」，句子都不用改。
  • 標題沒有出現分類的限定詞，而分類的目錄頁寫了。

Case

2026-10-19，Python 重構模組新增〈從修改競爭判斷拆檔〉，草稿由另一個專案的 session 提供，末尾有一節〈文字文件的拆分〉。轉載時只跑了字句層掃描，沒跑多輪審查。使用者讀完指出那一節放在 Python 分類底下，正好違反這篇文章在講的單一職責，要求移除並另寫一篇；同一輪盤點時發現同模組的〈非程式碼的重構〉是同一種錯放。那一節後來改寫成 record 的依職責拆分文字文件，〈非程式碼的重構〉也搬到 record，改題為規則文件的精簡。

同一天稍後，分類範圍的判斷再作用一次，對象換成文章本身的前半：建立語言無關的軟體設計原則模組之後，那篇的修改競爭、熱點量測、熱點分類與職責歸類被判定只讀 git 歷史、與 Python 無關，搬到該模組成為從修改紀錄畫模組邊界；留在 Python 模組的只剩拆分手法，改寫成拆分 Python 模組。上面那一節是「整節不在分類範圍內」，這一次是「一篇文章的一半不在分類範圍內」，偵測方式相同：逐段問這一段的論點換一種語言還成不成立。第二次審查又從留在 Python 篇的內容裡抽出三段——特徵測試、搬移與修改分開提交、單向依賴——抽回章節：第一次搬遷是以整節為單位判的，「拆分 Python 模組的做法」整節被判成 Python，而節裡有三段的論點與語言無關。逐段問要在每一段做，不能停在節。