diagnose

# diagnose — 先架測謊機，再准審問 You are a disciplined debugger. 你最大的敵人不是 bug，是**自己的過早結論**：讀兩眼 code 就宣稱「找到原因了」，修下去症狀還在、信用先沒了。本 skill 的核心只有一件事——**Step 1 的 feedback loop 才是全部，其餘都是機械動作**。 ## Step 0: 適用判定 | 情境 | 套不套 | |---|---| | 行為異常（錯輸出 / crash / 時好時壞 / 效能劣化）且原因未明 | ✅ 套 | | 已有一條會 fail 的指令（失敗測試 / 可重現的 curl） | ✅ 套，既有指令當**候選 loop**——過一遍 Step 1 五條判準（常已滿足）再進 Step 3，必要時回 Step 2 最小化 | | 純概念問題、讀 code 導覽、新功能需求 | ❌ 不套 | | 原因已確立、只是要修 | ❌ 不套，直接修 | ## Step 1: 建 red-capable feedback loop（本 skill 的全部） **CRITICAL — 停止句：這條指令存在之前，禁止讀 code 建理論、禁止提任何 root cause。** 發現自己在沒有重現指令的狀態下開始「應該是因為…」——停，回來先建 loop。 ### 完成判準（五條全過才算有 loop） - [ ] 一條**實際跑過至少一次**的指令（把指令和輸出貼出來，不是「應該可以這樣測」） - [ ] **Red-capable**：它斷言的是 user 講的那個症狀（錯值、crash、缺資料），**不是「沒噴錯」** - [ ] 確定性：重跑結果一致（非決定性 bug → 目標改成**拉高重現率**——50% 可以 debug、1% 不行） - [ ] 秒級完成（分鐘級的 loop 會讓你懶得跑、開始用猜的） - [ ] 可無人執行（不需要 user 幫忙點畫面） ### Loop 手法選擇 | 情境 | 手法 | |---|---| | 有測試框架 | 寫一個 failing test | | HTTP 服務 | curl + 斷言輸出（grep / jq） | | CLI / script | 固定 fixture 輸入重跑 | | 只在特定資料上壞 | 把那筆資料抽成最小 fixture | | 版本回歸 | `git bisect` + 上面任一手法當判準 | | 效能問題 | **不用 log**，先量基準數字，再二分定位 | | 真的建不出來 | 最後手段：明講建不出、列出試過什麼、向 user 要環境 / log dump / 錄影——**不准在沒有 loop 的情況下開始猜** | ## Step 2: 最小化重現 逐項砍（環境變數、輸入欄位、config、資料量），**每砍一項重跑 loop**，直到剩下的每一項都缺它不可（砍掉任何一項就重現不了）。最小化省下的時間���在 Step 4 十倍還你。 ## Step 3: 假說——先列 3 到 5 個，再測第一個 **MANDATORY**: 測任何假說之前，先產出一張排序過的假說清單，每條附**可否證預測**： ``` H1（最可能）：<假說>。若為真：跑 <X> 會看到 <Y>。 H2：... H3：... ``` - 排好的清單**先給 user 過目再開測**——user 常有能瞬間重排順序的領域知識。 - User 不在場（背景 / 無人值守）→ 照自己...