本地 LLM 用得順不順、九成取決於「期待對齊現實」。把本地當成「免費、永遠在線的初階 pair programmer」、它的表現會超出預期、變成日常雜事的得力幫手；把它當成 Claude Sonnet / GPT-5 替代品、跨檔案重構失敗、規劃 multi-step 任務（把模糊目標拆成多個可執行步驟依序執行）崩潰、深度 debug 給平庸答案的場景就會接連出現、第一週體感很差。本地 vs 雲端的能力分工背景見 0.0 本地 vs 雲端 LLM。

本章把期待校準到現實。讀完後你會清楚知道：哪些任務交本地、哪些交雲端、本地 LLM 一週後該怎麼判斷去留、什麼時候硬體升級才有意義。

本章目標

讀完本章後，你應該能：

1. 區分本地擅長領域、雲端擅長領域、模糊地帶三類任務。
2. 建立「本地 vs 雲端」的切換反射、減少每次糾結。
3. 用一週實測決定本地 LLM 是否留在工作流。
4. 識別本地 LLM 對你個人是「日常主力」「偶爾備援」還是「整體無用」。

本地擅長領域：明確強項

本地 LLM 在這些任務上的表現「足夠好、足夠快、值得每天用」：

本地擅長的共通結構：模式單純度高 + context 短 + 結果可驗證。遇到新任務時用這三條判讀：模式有沒有大量訓練資料覆蓋（補 type / 寫 docstring 屬高、設計新架構屬低）、需要的 context 是不是單檔內（單檔內屬短、跨檔屬長）、回應對不對自己看得出來（測試跑得過 / 註解讀得通 = 可驗證、深度 debug 的結論對錯難以即時驗證 = 不可驗證）。三條都打勾、本地通常勝任；任一缺項、考慮切雲端。

這份清單覆蓋了一般工程師每天 60 ~ 80% 的 LLM 使用情境。對主要靠雲端 API 訂閱（Claude Code、ChatGPT Plus、API tokens）的使用者、把這些餵給本地能讓雲端費用 / 配額用在真正困難的任務上。

雲端擅長領域：本地較弱、改用雲端更划算

下列任務在雲端旗艦上的表現明顯領先本地、預設交給雲端可以省下「先試本地、發現品質不夠、再切雲端」的時間成本：

雲端擅長的共通結構：context window 大 + reasoning depth 深 + 訓練資料密度高。雲端旗艦的 context 動輒 200K+ tokens、reasoning effort 模式能跑深推理 chain、訓練資料量級遠超開源模型。新任務若涉及「跨多檔閱讀 + 多步驟規劃 + 領域知識深度」、預設交雲端比較划算。

這份清單覆蓋了「LLM 真正取代人類思考的部分」、雲端旗艦的能力斷崖式領先。

模糊地帶：先試本地、視結果切換

下列任務本地能否做好視具體 case 而定。預設策略是「先試本地、看到觸發訊號再切雲端」：

觸發訊號的設計目標是「不依賴主觀判斷」、用具體跡象避免「總覺得本地不夠好就一律切雲端」的偏誤。建立自己的觸發訊號清單後、切換變成反射動作、不再每次糾結。模糊地帶切到雲端是正常工作流、是「先用便宜的工具、不夠再升級」的合理做法、跟本地「失敗」是兩件事。

切換的具體流程

Continue.dev 的 chat panel 下方（輸入框上方的下拉選單）有 model selector、可以直接切。建議的反射動作：

1. 預設用本地：開啟 Continue panel 時、先選本地 model。
2. 碰到雲端擅長任務直接切：上面雲端擅長表格的任務、第一次提問就選雲端。
3. 模糊地帶試一次本地：本地的回答堪用就用、看到觸發訊號就切雲端重提。
4. 記錄本地 hit rate：用一週、記錄哪些任務本地通過。第二週開始就有自己的判斷依據。

把本地當工具、把切換當常態。本地的價值在於「該用時隨手可用」、不是「裝了就要硬用」。

用一週實測：去留決策

裝完本地 LLM 後、建議用一週實測決定是否留下來。實測時做四件事：

1. 每次用 LLM 都先試本地、讓本地有機會證明自己。
2. 記錄 hit rate：簡單試算表、欄位放任務描述、本地通過、雲端通過。
3. 記錄體感速度：本地的等待感是「順暢」「可接受」「心煩」哪一級。
4. 記錄記憶體與發熱：Mac 是否變慢、風扇是否狂轉影響其他工作。

一週後做決策（hit rate 閾值是經驗值、可依任務分佈微調）：

這個實測比看 benchmark 重要得多、因為你的工作流跟 benchmark 設定的任務分佈未必一致。

本地 LLM 的角色定位

把本地 LLM 定位成「免費的初階 pair programmer」、期待會自然對齊現實：

1. 初階 pair programmer 是有用的：能寫測試、能解釋程式碼、能補 type、能改 callback。這些事一個 junior 同事每天做得很好。
2. 初階 pair programmer 有適用範圍：設計新架構、跨檔案重構、評估技術選型適合交給 senior（雲端旗艦）、跟交給 junior 同事的判斷一致。
3. 初階 pair programmer 隨時在線、不用付薪水：這是本地 LLM 比 junior 同事還好的地方。
4. 初階 pair programmer 跟 senior 互補：本地處理量、雲端處理難度、兩者組合讓 senior 把時間花在真正困難的部分。

陷阱是把本地當「便宜的 senior」。它的能力等級是 junior；明確這個定位後、你會自然把日常雜事丟給本地、把難題留給雲端。

跟雲端旗艦的協作姿勢

「混用」是有結構的協作姿勢、不是隨機切換。下表是寫 code 場景的典型分工：

這個結構讓「雲端旗艦的高品質」用在最值錢的地方（規劃 + 審稿）、「本地的免費 + 速度」用在批量產出。雲端 API 費用會大幅下降、思考品質仍然維持高水準。

硬體升級的判斷時機

裝完本地、用一週後、可能會想「升級 Mac 是否值得」。判斷依據（記憶體預算的完整推導見 0.5 Apple Silicon 記憶體預算）：

1. 記憶體預算：跑 14B 模型體感卡 → 升 24GB；跑 31B 卡 → 升 32GB；跑 70B 卡 → 升 64GB。
2. 生字速度：用最強量化與較小模型仍 < 10 tok/s 表示要換更輕的模型、不是升級硬體。
3. Hit rate 太低：問題在本地模型能力上限、不在硬體、升級沒幫助。
4. 長 context 場景：升級到 48GB+ 才能順暢處理 16K+ context。

陷阱是把「想換新 Mac」混在「正當理由」裡。先用一個月再決定；多數情況下省下的 API 費用攤平不了升級成本。

識別「本地對你個人沒用」的訊號

下列訊號表示本地 LLM 在你工作流上幫助有限、可以乾脆卸載：

1. 一週後雲端 API 費用沒降、因為切換習慣始終沒養成。
2. 本地回答太慢、實際使用頻率低、Ollama 卻在背景吃記憶體。
3. Mac 規格本來就吃緊、跑本地讓其他工作變慢。
4. 你的工作主要是規劃、設計、複雜推理、本地擅長領域跟你的主場交集小。

卸載屬於合理結論、不算失敗。本地 LLM 適合特定工作流；你的工作流跟它的擅長領域交集小、改用雲端是更划算的選擇。

完整卸載 Ollama 跟 Continue.dev 的指令：

1brew services stop ollama
2brew uninstall ollama
3rm -rf ~/.ollama
4
5# 卸載 Continue.dev 擴充套件
6# 在 VS Code Extensions panel 找到 Continue 點 Uninstall
7rm -rf ~/.continue

卸載後可以雲端 API 全用 Claude Code、Cursor 或其他雲端 IDE plugin、體驗一樣完整。

何時不適用本章建議

本章假設你的工作流可以「混用本地 + 雲端」。以下情境的混用前提不成立、本章建議要調整：

下一章

下一章：1.6 延伸方向、講日常路徑跑穩後可以玩的延伸（Open WebUI、aider、產圖）。