📌 30 秒摘要（Layer 3）
會語法不代表會「解問題」——本書專治「看著題目卻不知從何下手」。核心是把問題解決當成一套可練習的方法：面對難題時，用固定的策略拆解它（減少約束、拆子問題、用類比、從已知出發、逆推），而不是盯著空白畫面等靈感。是 程式設計方法 的心法版、演算法圖解 的思維前置。
🗺 心智圖（Canvas）
像程式設計師一樣思考
Link to original 像程式設計師一樣思考
🧭 有計畫地解題
🎯 什麼情境該想到我
當你盯著一個難題「不知從何下手、腦袋空白」時。與其等靈感，不如套策略。
⚙️ 怎麼用（卡住時逐個試）
- 先徹底理解問題：輸入輸出是什麼？有哪些限制？舉幾個具體例子。
- 減少/放寬約束：先解一個「簡化版/特例」，再逐步加回限制。
- 拆成子問題：把大問題切成能各自解決的小塊。
- 從已知會做的部分開始：先寫你確定會的，邊做邊逼近未知。
- 逆向推理：從想要的結果倒推需要什麼。
- 用類比：把它連到你解過的相似問題（見 工具-用類比解決新問題）。
★ 書中完整的八條（第 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；在「理解 + 計畫」上多花時間，通常省下更多亂試的時間。
🔗 相關工具
- 工具-用類比解決新問題 —— 策略之一，從解過的相似問題借結構
- 工具-設計訣竅 —— 更程序化的版本，把解題流程固定成一份可檢核的清單
- 工具-反過來想 —— 正面想不通時的換向招式，改問「怎樣一定會失敗」
Polya 四步 理解問題 → 擬定計畫 → 執行 → 回顧
🧩 五大解題策略
減少／放寬約束 先解一個簡化版的問題，再把約束加回來
拆成子問題 把大問題切成能各自解掉的小塊
🎯 什麼情境該想到我
當你遇到一個「沒解過、想不到解法」的新問題時。
⚙️ 怎麼用
「不會解 X？先解一個你會解、且和 X 相似的問題。」
- 問：這題讓我想到什麼解過的問題？ 找出結構相似之處（資料形狀、操作、目標）。
- 借用那個問題的解法骨架，再針對差異調整。
- 善用既有模式：設計模式、演算法策略、資料結構——把新問題對應到已知模式（見 工具-演算法設計策略、設計模式）。
- 若找不到直接類比，先解一個更簡單的相似版本，再往上加。
★ 書中的定義：類比有「整題」和「局部」兩種
《像程式設計師一樣思考》對類比的定義是：目前問題與已經解過的問題之間的相似之處，可以被利用來幫助解決目前的問題。相似有不同程度：
程度 例子 怎麼用 整題相同 書中的「狐狸、鵝、玉米」過河謎題和一個密碼鎖問題，本質上是同一題 直接套解法 只有一部分相同 兩個完全不同的數字處理問題，唯一共通點是都需要超過內建浮點數的精度 只把「處理精度」那一塊的解法搬過來 多數類比是第二種。所以找類比的問法不是「這整題像什麼」，而是「這題的哪一個部分我以前處理過？」
★ 為什麼它最難練：你需要一個「解法庫」
書說辨識類比是最能提升解題速度的方法，也是最難培養的——因為你得先有足夠多自己解過的題目，才有東西可以類比。
書特別警告一條捷徑：找一段相似的程式碼來改。問題在於：
- 你沒有自己完成解法，就沒有真正理解它；很難正確修改一段你不完全理解的程式。
- 每個你自己寫成功的程式，都會成為未來的類比來源；現在越依賴別人的程式碼，未來就越依賴。
這個警告在 AI 生成程式碼的時代更貼切：直接接受 AI 給的解法而不理解，等於放棄累積自己的解法庫。
★ 程式設計中最常用的類比來源
你遇到的問題 可以類比到的已知問題 「找出兩個版本的設定差在哪」 最長公共子序列（diff 演算法） 「任務之間有先後依賴，排出執行順序」 拓撲排序（見 拓撲排序） 「限制每個使用者每秒的請求數」 權杖桶（見 工具-限流器設計） 「多個服務要對某件事達成一致」 共識問題（見 工具-線性一致性與共識） 「很多來源的資料要合併且去重」 合併排序的 merge 步驟 + 雜湊集合 「在一大堆可能中找最佳組合」 背包問題 → 動態規劃（見 動態規劃） ★ 驗證類比：找出「不一樣的地方」
借來解法之後，要明確列出兩題的差異，逐一檢查每個差異會不會讓解法失效：
- 限流器類比權杖桶 → 差異：分散式，多台機器要共享桶 → 單機版解法不夠，需要共享儲存。
- 任務排程類比拓撲排序 → 差異：依賴可能有環 → 拓撲排序要能偵測環並回報。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 類比是起點不是終點；相似不等於相同，要驗證借來的解法對這題真的成立。
🔗 相關工具
- 工具-程式問題解決策略 —— 上位工具箱，類比是其中一招，卡住時可換別招
- 工具-多元思維模型 —— 類比的素材庫，跨學科模型越多，能借用的相似結構越多
從已知會做的部分開始 先寫出你確定會寫的那一段，逐步逼近
逆向推理 從想要的結果往回推導需要的步驟
🛠 執行原則
先讓它能動，再讓它好 先求可運作的解，再談優化
建立可重用的心智工具箱 把解過的問題模式內化，下次直接調用
🧰 這本書給我的工具
- 工具-程式問題解決策略 — 看著題目卡住、不知怎麼下手時
- 工具-用類比解決新問題 — 遇到沒解過的問題時
✨ 關鍵重點（Layer 1–2）
- 有計畫地解題：理解問題 → 擬定計畫 → 執行 → 回顧（Polya 式）。
- 常用策略：減少/放寬約束（先解簡化版）、拆成子問題、用類比（把新問題連到解過的）、從你已知會做的部分開始、逆向推理。
- 先讓它能動，再讓它好：先求可運作的解，再優化。
- 建立可重用的心智工具箱：把解過的問題模式內化，下次直接調用。
💬 金句原文（Layer 0）
- 「當你不知道怎麼解一個問題時，先解一個你會解的相似問題。」