why

why skill 概述

why skill 是一個聚焦的 Five Whys 分析工具，能把症狀一路拆成根因鏈，再轉成你可以採取的修正動作。如果你需要 why skill 來做 UX Audit、產品問題、bug，或流程中斷分析，它能幫你把「發生了什麼」和「為什麼會發生」清楚分開。

why 適合用來做什麼

當第一個解釋很可能太表面時，就用 why：像是「使用者流失了」、「build 失敗了」，或「團隊沒趕上期限」。這個 skill 的設計目標，是持續推進分析，直到找到系統性原因，而不只是看得到的症狀。

why 最適合哪些讀者

這份 why 指南最適合營運人員、分析師、工程師，以及 UX 審查者；他們想要一條有結構的根因路徑，但不想從零自己搭一套框架。如果你手上已經有明確的問題描述，只需要一個有紀律的方法去追問，它就很合用。

why 為什麼實用

它的主要價值在於速度和聚焦：提供可重複的提問形式、預設深度，以及驗證步驟，讓你能檢查原因是否真的能解釋症狀。當一般腦力激盪總是繞回同一個顯而易見的答案時，這會讓 why 的安裝特別值得。

如何使用 why skill

安裝並觸發 why

先把 why skill 安裝到你的 skills workflow，接著用具體症狀來呼叫它，不要只丟一個模糊主題。好的起手式像是：/why checkout conversion fell 18% after the redesign 或 /why CI failures spike on main branch。

提供問題陳述，不要先丟理論

這個 skill 最適合在你提供單一可觀察問題、它出現的情境，以及任何已知限制時使用。好的輸入：Mobile users abandon the signup form on step 2 after the new validation rules shipped; analyze root causes in the current UX flow. 較弱的輸入：Why is UX bad?

先閱讀真正重要的來源檔案

先從 SKILL.md 開始，理解分析流程；接著視你的環境，檢查 README.md、AGENTS.md、metadata.json，以及任何存在的 rules/、resources/、references/ 或 scripts/ 資料夾。在這個 repository 裡，SKILL.md 是主要的事實來源，所以最快的方式，就是先讀分析步驟和範例，再去調整套用。

把分析當成一段工作中的 session 來跑

把 why 當成一條有引導的連鎖分析：先陳述症狀，用證據回答每一個「為什麼」，然後在原因已經夠根本、而且可驗證時停止。如果出現不只一個原因，就要分支處理，不要硬壓成單一路線；最後提出能消除根因的變更，而不是只掩蓋症狀。

why skill 常見問答

why 只適合技術除錯嗎？

不是。只要你能描述出真實症狀，why skill 就能用在 UX Audit、營運、產品、客服，以及團隊流程問題上。關鍵要求是：問題必須能沿著因果關係往下追。

每次都一定要跑五輪嗎？

不一定。五輪是預設深度，但更好的原則是「一旦解釋變得可執行且穩定，就停下來」。如果三步就已經到達真正的根因，再硬補兩步通常只會增加雜訊。

why 跟一般 prompt 有什麼不同？

一般 prompt 常是在要點子；why 要的是有紀律的因果推導。當你想做根因分析、要找修正動作，或需要一種能從原因反推到症狀的可驗證審查時，它會更好用。

什麼情況下不該用 why？

不要拿它來做開放式發想、廣泛策略討論，或處理沒有可觀察症狀的問題。如果你無法把問題定義得夠清楚，讓它能被拿來測試因果鏈，why skill 只會產生淺層猜測。

如何改進 why skill

從更銳利的症狀開始

why 輸出的品質，取決於第一句話寫得好不好。要包含壞掉的是什麼、誰感受到影響、何時開始改變，以及發生在哪個環境：After the new onboarding copy, first-time activation dropped on iOS only. 這會比 activation is down 好得多。

補充證據，不要先下結論

如果你有 log、使用者引述、漏斗步驟、截圖、時間戳記或 release 標記，就一起提供。證據能幫 why 分辨相關性和因果性，也能避免分析太快停在第一個看起來合理的解釋。

反向檢查整條因果鏈

一個好的 why 結果，應該能從根因一路往上解釋到症狀。如果最後一層原因無法清楚推出前面的步驟，就先修正這條鏈，或把它拆成分支，再開始採取行動。

把發現轉成一個可修的動作

最好的 why 結果，最後會落在一個你能發布、記錄，或衡量的變更上。後續處理要聚焦在你真正能控制的那個原因，然後在修正後再跑一次 skill，確認症狀是否如預期朝正確方向移動。