🎯 什麼情境該想到我
當你盯著一個難題「不知從何下手、腦袋空白」時。與其等靈感，不如套策略。
⚙️ 怎麼用（卡住時逐個試）
- 先徹底理解問題：輸入輸出是什麼？有哪些限制？舉幾個具體例子。
- 減少/放寬約束：先解一個「簡化版/特例」，再逐步加回限制。
- 拆成子問題：把大問題切成能各自解決的小塊。
- 從已知會做的部分開始：先寫你確定會的，邊做邊逼近未知。
- 逆向推理：從想要的結果倒推需要什麼。
- 用類比：把它連到你解過的相似問題（見 工具-用類比解決新問題）。
★ 書中完整的八條（第 1 章）
原卡列的是實務上最常用的幾條；《像程式設計師一樣思考》第 1 章的完整清單是：
| # | 原則 | 書中的重點 |
|---|---|---|
| 1 | 永遠要有計畫（Always Have a Plan） | 書說這「也許是最重要的規則」。計畫可以改，但沒計畫就是亂試 |
| 2 | 重述問題（Restate the Problem） | 用自己的話重寫，常會發現題目其實比想像簡單，或發現隱藏的限制；可以把「正式重述問題」當成計畫的第一步 |
| 3 | 拆解問題（Divide the Problem） | 拆成可各自解決的小塊 |
| 4 | 從你已經會的開始（Start with What You Know） | 先寫確定會的部分，建立信心與進度 |
| 5 | 縮小問題（Reduce the Problem） | 拆不開時，拿掉或放寬一個限制，解一個較小的版本；書的說法是像從側面繞過去 |
| 6 | 找類比（Look for Analogies） | 見 工具-用類比解決新問題 |
| 7 | 實驗（Experiment） | 見下 |
| 8 | 不要挫折（Don’t Get Frustrated） | 見下 |
原卡的「逆向推理」不在這份清單中，但它是解題的常見技巧（從目標狀態倒推需要什麼），可以歸在第 2 條「重述問題」的一種變形。
★ 「實驗」不是「亂猜」
書對兩者的分界很清楚：
- 猜：打一段程式碼，希望它能動，心裡沒有明確的預期。
- 實驗：先假設執行某段程式碼會發生什麼，再跑，看假設對不對——每次都得到資訊。
書中的兩種實驗：
- 探索不熟悉的 API：不確定某個容器刪除元素時會怎樣？寫一個獨立的小程式專門試這件事，不要邊解主問題邊猜。在 Go 裡就是寫一個
_test.go或go run一個小檔案；這個小程式之後還可以當參考。 - 刻意改變行為來定位問題：輸出剛好是反的？故意把迴圈方向反過來，看輸出有沒有跟著變——有變或沒變都告訴你問題在哪一層。
★ 「不要挫折」為什麼是一條方法
書的論點：挫折時思考不清楚、效率變差、一切變更久；而且挫折會自我增強。書認為，挫折不是外部刺激造成的反射，而是你允許它發生——所以避免挫折是一個你可以做的決定。具體做法：
- 回到第 1 條：如果你有計畫並且照著走，你就在前進——寫出最終解法只是計畫的其中一步。
- 換一個子問題：卡住的那塊先放著，去做計畫裡的另一塊。
- 休息：書在除錯章節也提到，離開一段時間能打破你對程式碼的錯誤印象。
★ 一份可以直接用的「卡住了」檢查表
- 我能用一句話重述問題嗎？輸入是什麼、輸出是什麼、限制是什麼？
- 我手上有沒有 3 個具體的輸入→輸出例子（含一個邊界案例）？
- 我能解一個更小的版本嗎？（n=1、只有一種類型、不考慮併發）
- 這題的哪一部分我以前處理過？
- 我現在是在實驗（有預期）還是在猜？
- 我已經卡同一個點超過 30 分鐘了嗎？→ 換一個子問題，或找人（或玩具熊）講一遍。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 別急著寫 code；在「理解 + 計畫」上多花時間，通常省下更多亂試的時間。
🔗 相關工具
- 工具-用類比解決新問題 —— 策略之一，從解過的相似問題借結構
- 工具-設計訣竅 —— 更程序化的版本，把解題流程固定成一份可檢核的清單
- 工具-反過來想 —— 正面想不通時的換向招式，改問「怎樣一定會失敗」