principle-minimize-reader-load | 降低追蹤層數與隱藏狀態
本頁以 pstack-claude 0.9.126 為基準。原文設定 user-invocable: false，通常由 poteto-mode 按需讀取。你可以要求「套用 principle-minimize-reader-load」，檢查讀者為理解一個結果必須追蹤多少資訊。
定位與適用情境
原文用兩個獨立軸線看維護成本。第一是要追蹤的間接層數。第二是必須記在腦中的隱藏或可變狀態。程式行數與複雜度分數只能作為替代指標，不能取代實際閱讀負擔。
本例的新同事要弄清楚月報的結算日期。輸入是報表入口、日期轉接器、服務類別與模組層級的可變時區設定。即使函式都很短，仍可能要跳過多層轉傳，並記住誰最後改過時區。
準備
- 提供從報表入口到日期格式化的完整呼叫路徑，以及時區設定的所有讀寫位置。
- 寫下可觀察行為，包括指定時區的跨日結果與連續產生不同報表的結果。
- 準備兩個閱讀問題。「結算日期從哪裡來」與「誰能改變它」。
操作步驟
- 記錄兩種負擔。 沿呼叫路徑列出每一層處理的決策，再列出需要跨函式記住的時區與日期狀態。不要只數檔案或函式長度。
- 檢查抽象是否改變。 若兩層只是原封不動轉傳同一組參數，評估合併。單一呼叫端的包裝也要問是否隱藏重要決策，而不是看到一個呼叫端就刪除。
- 縮小狀態範圍。 評估把可變模組時區改為本次報表的明確輸入，讓日期計算回傳結果而非修改共享欄位。在邊界說明一次不變條件（Invariant），避免每個消費者重複理解。
- 用行為與閱讀驗證。 先核對跨日與多報表結果不變，再請未參與修改的讀者回答兩個問題。原文以 30 秒內能回答作為檢查，無實際讀者測量就標為待驗證。
可直接使用的提示詞
套用 principle-minimize-reader-load。請追蹤月報結算日期，分別列出間接層數，以及讀者必須記住的可變時區狀態。
先唯讀提出精簡方案。只建議合併沒有隱藏實質決策的轉傳層，並說明哪些邊界應保留。評估把模組時區改成每次報表的輸入，不建立新架構層。
交付修改前後的追蹤路徑、跨日與多報表測試案例，以及讓新讀者回答「日期從哪裡來、誰能改變它」的方法。不要聲稱尚未測量的閱讀時間。預期結果與驗收
預期得到同時處理間接層與狀態的提案。
- 每個保留的層級都能說明隱藏了什麼決策，而不只是重新命名相同方法。
- 日期與時區的來源、擁有者、可修改位置都能直接指出。
- 跨日及不同報表連續執行的測試仍保護原有行為。
- 閱讀檢查有實際記錄，或明確標註待測，不以行數下降冒充理解更快。
限制與權限
常見誤用是把所有程式攤平成一個檔案，卻留下大量全域變數。層數減少不代表狀態負擔也減少。另一種誤用是合併安全、驗證或領域邊界，只因它目前只有一個實作。
30 秒是原文提供的檢查問題，不是任何讀者都能達成的保證。教學中的報表與時區是示例。真正修改前仍要確認業務契約與允許範圍，不為精簡而移除專案要求的有效文件及功能註解。