why | 用歷史證據查設計理由
本頁以 pstack-claude 0.9.126 為基準。why 調查哪些限制、事件與取捨促成目前的程式形狀，不能只從程式碼猜作者的動機。
定位與適用情境
你發現搜尋請求有一個重試上限，想提高它。先查當時是否發生服務過載、逾時或重複請求事故，才能知道哪些保護不能隨便移除。
若問題只是重試迴圈如何執行，使用 how。若問「為何選這個數字」，則需要歷史、事故或資料證據，而不是一段合理但無來源的故事。
準備
提供目標檔案、符號、目前版本與你的問題。若已知工單或合併請求（Pull request，PR），附上連結或可公開的內容。
先確認授權與工具。模型上下文協定（Model Context Protocol，MCP）可接入不同來源，但本機有 git 不代表已登入 GitHub 或能搜尋團隊聊天。Claude Code 可用 /pstack:why，Codex 插件可從 $ 技能選單插入 $pstack:why。
操作步驟
- 建立程式碼錨點，記錄檔案與行範圍、符號、相關提交及 PR。追蹤歷史與重新命名，不只看最近一次修改。
- 列出可查的七類來源。包含版本控制、工單、長篇文件、團隊聊天、基礎設施可觀測性、錯誤追蹤與產品分析資料倉儲。逐一標明工具、授權與缺口。
- 對可用來源安排獨立調查，再統整結果。原文預設平行查核；重試等防禦性程式還要查事故脈絡。沒有結果也保留查詢紀錄，不等於當年沒有發生事故。
- 分開閱讀找到的事實、合理推論、競爭解釋與未知。保留引文及信心措辭，不把「可能」改成「確定」。
- 若準備改程式，把歷史限制整理為應保留、可改變、應避免與風險四類，先作為規劃輸入，不直接實作。
可直接使用的提示詞
用 pstack:why 查目前搜尋請求重試上限的設計理由，先不要改程式。
先找實際符號與相關提交，追蹤引入及後續調整的 PR 或工單。
列出七類證據來源的工具與授權狀態，只查我已授權的來源。
重試屬於防禦邏輯，請特別找逾時、過載或重複請求事故紀錄。
每個缺失或零結果都要列入 Sources Consulted，不要寫成事件不存在。
分開事實、推論、替代解釋與未知，再提出變更前的保留項與風險。預期結果與驗收
你應能沿引用找到支撐結論的提交、討論或原文。來源表每類都應有結果、空結果或明確跳過理由。缺少聊天工具時，結論應是「未能搜尋聊天紀錄」，不是「團隊從未討論」。
檢查每個設計動機是否有證據，以及是否區分實作時的決定與後來累積的限制。原文只允許在極少數已確認所有可用搜尋都重複的簡單案例直接回答，不能因為看似小改就省略覆蓋檢查。
限制與權限
原文以可保留 MCP 存取的代理模式派工，但仍明說調查者不應寫入。工具模式不是修改、發送訊息、部署或取得新資料權限的授權。依目前平台支援調整，不盲目套用 Claude 的工具旗標。
來源不足就降低結論強度。舊 PR 的理由不保證今天仍成立，現今監控數字也不能倒推當時動機。本頁不宣稱已連線任何外部服務或查出特定事故。