🎯 什麼情境該想到我
當你遇到一個「沒解過、想不到解法」的新問題時。
⚙️ 怎麼用
「不會解 X？先解一個你會解、且和 X 相似的問題。」
- 問：這題讓我想到什麼解過的問題？ 找出結構相似之處（資料形狀、操作、目標）。
- 借用那個問題的解法骨架，再針對差異調整。
- 善用既有模式：設計模式、演算法策略、資料結構——把新問題對應到已知模式（見 工具-演算法設計策略、設計模式）。
- 若找不到直接類比，先解一個更簡單的相似版本，再往上加。
★ 書中的定義：類比有「整題」和「局部」兩種
《像程式設計師一樣思考》對類比的定義是：目前問題與已經解過的問題之間的相似之處，可以被利用來幫助解決目前的問題。相似有不同程度：
| 程度 | 例子 | 怎麼用 |
|---|---|---|
| 整題相同 | 書中的「狐狸、鵝、玉米」過河謎題和一個密碼鎖問題，本質上是同一題 | 直接套解法 |
| 只有一部分相同 | 兩個完全不同的數字處理問題，唯一共通點是都需要超過內建浮點數的精度 | 只把「處理精度」那一塊的解法搬過來 |
多數類比是第二種。所以找類比的問法不是「這整題像什麼」，而是「這題的哪一個部分我以前處理過？」
★ 為什麼它最難練：你需要一個「解法庫」
書說辨識類比是最能提升解題速度的方法，也是最難培養的——因為你得先有足夠多自己解過的題目，才有東西可以類比。
書特別警告一條捷徑：找一段相似的程式碼來改。問題在於：
- 你沒有自己完成解法，就沒有真正理解它；很難正確修改一段你不完全理解的程式。
- 每個你自己寫成功的程式，都會成為未來的類比來源；現在越依賴別人的程式碼，未來就越依賴。
這個警告在 AI 生成程式碼的時代更貼切：直接接受 AI 給的解法而不理解，等於放棄累積自己的解法庫。
★ 程式設計中最常用的類比來源
| 你遇到的問題 | 可以類比到的已知問題 |
|---|---|
| 「找出兩個版本的設定差在哪」 | 最長公共子序列（diff 演算法） |
| 「任務之間有先後依賴，排出執行順序」 | 拓撲排序（見 拓撲排序） |
| 「限制每個使用者每秒的請求數」 | 權杖桶（見 工具-限流器設計） |
| 「多個服務要對某件事達成一致」 | 共識問題（見 工具-線性一致性與共識） |
| 「很多來源的資料要合併且去重」 | 合併排序的 merge 步驟 + 雜湊集合 |
| 「在一大堆可能中找最佳組合」 | 背包問題 → 動態規劃（見 動態規劃） |
★ 驗證類比：找出「不一樣的地方」
借來解法之後，要明確列出兩題的差異，逐一檢查每個差異會不會讓解法失效：
- 限流器類比權杖桶 → 差異：分散式，多台機器要共享桶 → 單機版解法不夠，需要共享儲存。
- 任務排程類比拓撲排序 → 差異：依賴可能有環 → 拓撲排序要能偵測環並回報。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 類比是起點不是終點；相似不等於相同，要驗證借來的解法對這題真的成立。
🔗 相關工具
- 工具-程式問題解決策略 —— 上位工具箱，類比是其中一招，卡住時可換別招
- 工具-多元思維模型 —— 類比的素材庫，跨學科模型越多，能借用的相似結構越多