hunt

hunt 技能概覽

hunt 是用來做什麼的

hunt 是一個以除錯為優先的技能，會先逼你從根因思考，再動手修正。它最適合處理錯誤、當機、回歸、測試失敗、快取過期問題、截圖異常，以及那種「以前明明可以」的失敗情境；這類問題需要的是可驗證的假設，而不是隨手打一個補丁。

誰應該安裝它

如果你經常在應用程式程式碼、測試、建置產物或執行期行為之間來回排查，而且希望有一套可重複的 hunt 指引，幫你快速縮小問題範圍，那就很適合安裝。當症狀很雜、同樣的修法一直失敗，或錯誤同時牽涉 log、UI 狀態與產生出的輸出時，尤其有用。

hunt 的不同之處

它的核心價值在於紀律：先鎖定具體的檔案、函式、行號或條件，再持續蒐集證據，直到根因足以站得住腳。配套參考內容涵蓋 logging、失敗模式、IME/Unicode 邊界情況與渲染錯誤，所以這個技能不只是叫你「更努力除錯」；它會把你推向正確的診斷類型。

如何使用 hunt 技能

安裝與情境設定

先依照你的環境走一般的技能安裝流程，然後依序開啟這些技能檔案：SKILL.md、references/failure-patterns.md、references/logging-techniques.md、references/ime-unicode.md、references/rendering-debug.md。先從最貼近症狀的參考文件開始；除非問題跨越多個領域，不然不用全部都讀。

如何用提示詞呼叫 hunt

想要 hunt 發揮最好效果，請先要求診斷再要求修復，並提供你手上最小可重現的症狀。好的輸入會像這樣：hunt this regression: clicking Save no longer persists after refresh; latest change touched src/hooks/user.ts; logs show cache hit. 不好的輸入會像這樣：save is broken, please fix.

這個技能預期的工作流程

hunt 指南預期你先用一句話提出假設，再用證據驗證，只有在原因已經能被測試時才動手修補。實際上可以這樣做：重現問題、縮小路徑、蒐集一個能區分假設的 log 或檢查項、確認傳播路徑，然後寫出最小修正，並在可行時補上回歸測試。

實用的閱讀路徑

如果問題看起來像快取、佇列、guard 或建置邊界造成的，就看 references/failure-patterns.md。如果你需要有工具輔助的證據，就看 references/logging-techniques.md。如果是 CJK 輸入或組字問題，請看 references/ime-unicode.md。如果是 PDF、列印、字型或版面失敗，請看 references/rendering-debug.md。

hunt 技能 FAQ

hunt 只適合程式碼錯誤嗎？

不是。hunt 適用於任何具體的失敗模式：執行期錯誤、測試失敗、產生出的成品壞掉、UI 回歸，以及輸出不符合預期。它不適合純程式碼審查或功能設計。

我需要先知道確切根因嗎？

不需要，但你需要一個可以被推翻的假設。這個技能就是為了幫你從「有東西不對」推進到「我認為根因是 X，因為 Y」。

hunt 比一般提示詞更好嗎？

當失敗原因不明確或反覆出現時，通常是的。一般提示詞可能直接產出一個 patch；hunt 會先減少猜測，降低修完這條路、卻把另一條路弄壞的機率。

什麼情況下不該用 hunt？

如果你是在新增功能、在沒有 bug 的情況下重構，或你已經有確認過的最小修正、只需要實作協助，那就先不要用。它也不是高層級架構腦力激盪的最佳選擇。

如何改進 hunt 技能

一開始就提供更有力的證據

把症狀、最新變更、確切環境，以及一兩個具體觀察一起給出來。例如：fails only on cold start、passes after cache clear、breaks on macOS with CJK input，或 PDF renders locally but not in CI。這能幫助 hunt 立刻選到正確的失敗模式。

避免常見失誤

最大的錯誤，是在原因還沒縮小前就急著要修復。另一個常見失誤，是可觀測性太模糊：log 只看得到錯誤訊息，卻沒有哪個分支、哪個步驟序列，或哪個狀態轉換能區分不同假設。要補的是能區分假設的證據，不是更多噪音。

在第一輪之後持續迭代

如果第一次診斷不完整，請回覆新的觀察結果，不要整個 prompt 重來。hunt 最適合用在一個逐步收斂的迴圈：假設、檢查、反例、更強的假設。這就是從安裝 hunt 技能，走到穩定可用的 Debugging workflow 的方式。