讀完本模組後，你應該能在自己的 Mac 上裝好一個本地 LLM 工作流，並知道它的能力邊界、什麼時候該切回雲端。

章節列表

推論伺服器選型總表

模組零已建立的三層架構視角告訴你 Ollama、LM Studio、llama.cpp 都屬於伺服器層。本模組要回答的是這三者的具體差異：

讀完本表後的決策建議是：先裝 Ollama，跑穩後再評估其他。LM Studio 可以同時裝來探索模型，但日常主力建議 Ollama；llama.cpp 暫時不需要直接接觸（Ollama 內部已經用 llama.cpp）。

為什麼這個順序

本模組章節順序的設計脈絡：

1. 先 1.0 Ollama：學習曲線最低、生態最成熟、Gemma 4 MTP 一鍵支援。多數讀者裝完這個就能開始用。
2. 再 1.1 LM Studio：給「想要可視化探索」的讀者另一條路；也可以跟 Ollama 並存。
3. 接 1.2 llama.cpp：澄清網路上「llama.cpp 才是真本地」的迷思，給進階讀者完整背景。
4. 再 1.3 VS Code + Continue.dev：把伺服器接到日常工作環境，這才是寫 code 的真正起點。
5. 然後 1.4 模型選型：伺服器跑起來後該裝哪個模型，給優先順序。
6. 再 1.5 期望管理：用一週後該怎麼判斷「值不值得繼續用」「什麼時候切雲端」。
7. 最後 1.6 延伸方向：日常路徑穩了再玩 Web UI、coding agent、產圖。

每一章可以單獨讀，但若你是第一次接觸本地 LLM，照順序讀最不容易迷路。

一個小時的最短路徑

如果你沒時間讀完整本模組、只想用一小時搞定本地 LLM 寫 code 的最基本工作流，下面是最短路徑：

 1# 1. 裝 Ollama（5 分鐘）
 2brew install ollama
 3ollama serve &
 4
 5# 2. 拉模型（首次下載約 20 ~ 30 分鐘，看網速）
 6ollama run gemma4:31b-coding-mtp-bf16
 7
 8# 3. 在 VS Code 裝 Continue 擴充套件（2 分鐘）
 9# 4. 設定 ~/.continue/config.json（5 分鐘）
10# 5. 試用 Cmd+L（對話）、Cmd+I（行內編輯）（剩下時間）

需要 32GB+ Mac 才能流暢跑這個 model；16GB / 24GB 請改用 1.4 模型選型 的對照表選對應大小的模型。完整步驟在 1.0 Ollama 跟 1.3 VS Code + Continue.dev。

跑穩之後該做什麼

裝完不是終點。本地 LLM 跟雲端的差別在於「需要持續調教」。跑穩後建議的後續工作：

1. 用一週實測：把日常工作流真實餵進去、記錄通過率與痛點、用真實任務當判讀依據而非示範任務。
2. 建立切換習慣：明確哪些任務交給本地、哪些切雲端。詳見 1.5 期望管理。
3. 觀察記憶體與發熱：開 Activity Monitor 看記憶體 swap 狀態、機殼溫度是否過高。
4. 追新模型：本地模型發布速度很快、每 2 ~ 3 個月會有新候選、值得追蹤。
5. 判斷是否升級硬體：用一個月後若限制都來自記憶體、再評估升級 Mac；先確認痛點再投資硬體。

不在本模組內的主題

本模組不討論：

1. 訓練、fine-tuning、LoRA 微調 — 跟「跑現成模型」是不同的工程問題。
2. 部署到雲端 GPU、Linux server — 本指南範圍只在 Apple Silicon Mac。
3. Cursor、Windsurf、Cline 等其他 IDE 整合 — Continue.dev 是與本地 LLM 整合最成熟的選擇，其他工具的整合度視版本而定。
4. 詳細的 benchmark 跑分方法 — 本指南只引用官方數據，自己跑分屬於另一個工程主題。

需要這些主題時請另尋專門資源；硬塞進來只會讓「Mac 本地寫 code」這條最短路徑被淹沒。

Continue.dev 是 2026 年 5 月時與本地 LLM 整合最成熟的 VS Code 擴充套件。對應到雲端世界、它的定位類似 Cursor、差別是 Continue.dev 預設綁本地、可以同時連雲端；Cursor 預設綁雲端、本地是次要 surface、設定深度較高。

本章假設你已經裝好 Ollama 並至少跑過一次 ollama run。沒裝過請先回 1.0 Ollama。

本章目標

讀完本章後，你應該能：

1. 安裝 Continue.dev 擴充套件。
2. 在 ~/.continue/config.json 設定本地 Ollama 模型。
3. 用 Cmd+L 開對話、Cmd+I 做行內編輯。
4. 同時設定本地與雲端模型，按任務切換。
5. 排除 Continue 連不上 Ollama 的常見問題。

安裝擴充套件

Continue 擴充套件是 VS Code 內接到本地 LLM 的介面層入口、裝完才有 chat panel 與 inline edit 快捷鍵。在 VS Code 內按 Cmd+Shift+X 開啟 extensions panel、搜尋 Continue。第一個結果作者是 Continue Dev, Inc.（藍色 verified 標記）、點 Install。

裝完後左側 sidebar 多一個 Continue icon（一個小方塊）。第一次點開會跳出 onboarding、可以略過。

擴充套件本身是 open source、Continue Dev 帳號（公司提供的雲端服務 tier、跟 VS Code 的 Microsoft 帳號是兩件事）可選。「本地 LLM」場景使用 open source 部分就足夠、不必登入。

找到 config.json

Continue 的設定檔在 ~/.continue/config.json（macOS 是 /Users/<你的帳號>/.continue/config.json）。第一次開 Continue 後檔案會自動產生。

開檔案：

1code ~/.continue/config.json

或在 VS Code Continue panel 點右上角齒輪 icon，會直接開 config.json。

預設內容包含一些雲端範例 model（OpenAI、Anthropic、Mistral），我們要加自己的本地 model。

設定本地 Ollama 模型

把 models 陣列改成這樣：

 1{
 2  "models": [
 3    {
 4      "title": "Local: Gemma 4 31B MTP",
 5      "provider": "ollama",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434"
 8    }
 9  ],
10  "tabAutocompleteModel": {
11    "title": "Local autocomplete",
12    "provider": "ollama",
13    "model": "gemma4:e4b",
14    "apiBase": "http://localhost:11434"
15  },
16  "embeddingsProvider": {
17    "provider": "ollama",
18    "model": "nomic-embed-text",
19    "apiBase": "http://localhost:11434"
20  }
21}

每個欄位的意義：

Embedding model 的角色跟 chat / autocomplete model 不同：chat model 負責「跟你對話」、embedding model 負責「把文字壓成向量、用來做語意相似比對」、是 @codebase 功能的後端引擎。一般 chat model 沒法當 embedding model、要分開設定。

provider: ollama 是 Continue 內建的 Ollama 整合、比 provider: openai 多支援 model auto-pull 等功能。apiBase 不需要加 /v1、Continue 內部會處理。

存檔後 Continue 會自動 reload。

用 Cmd+L 開對話

Cmd+L 是把當前 buffer 餵進 chat 的快捷路徑、context 由選取範圍決定。回到 VS Code、按 Cmd+L（macOS）開啟 Continue chat panel。預設快捷鍵：

按 Cmd+L 後 panel 開啟，下方輸入區可以打 prompt。如果先選了一段 code，那段 code 會自動加進 context，你可以直接問「解釋這段 code」「改成 async」「加 type annotation」。

第一次提問時 Ollama 會載入 model（30 ~ 60 秒）、看到 Continue panel 有 spinner 是預期的。之後同一個 model 會留在記憶體（ollama keep_alive）、對話速度會快得多。

用 Cmd+I 做 inline edit

把游標放在你要修改的 code 上（或選取一段），按 Cmd+I 開 inline prompt。打字描述要做什麼，例如：

1加 type annotation

或：

1把這個 callback 改成 async/await

Enter 後 Continue 會把選取的 code + 你的指令送給本地模型，回傳的 diff 直接 inline 顯示。按 Cmd+; 接受、Cmd+' 拒絕。

陷阱是「選取範圍太大」。本地模型的 context window 雖然多半 8K 以上、但塞太多 code 會讓 TTFT 暴增。把選取範圍縮在一個 function 或一個 block 內、體感最好。

同時設定本地與雲端模型（按任務切換）

寫 code 場景的常見配置是「本地當預設、雲端當大難題備援」。修改 config.json：

 1{
 2  "models": [
 3    {
 4      "title": "Local: Gemma 4 31B MTP",
 5      "provider": "ollama",
 6      "model": "gemma4:31b-coding-mtp-bf16",
 7      "apiBase": "http://localhost:11434"
 8    },
 9    {
10      "title": "Cloud: Claude Sonnet 4.6",
11      "provider": "anthropic",
12      "model": "claude-sonnet-4-6",
13      "apiKey": "sk-ant-xxx"
14    },
15    {
16      "title": "Cloud: GPT-5",
17      "provider": "openai",
18      "model": "gpt-5",
19      "apiKey": "sk-xxx"
20    }
21  ]
22}

Continue chat panel 下方有 model selector，可以下拉切換。建議的切換時機：

詳細的判斷邏輯見 1.5 期望管理。安全 / 資料邊界面向：同個 IDE 同時接本地跟雲端 provider、prompt routing 設錯就會把該走本地的 NDA / 客戶 code 送到雲端、見 6.4 跨雲端 / 本地的資料邊界；codebase / 外部文件 / 剪貼簿成為 prompt injection 攻擊面的判讀見 6.3 IDE 場景的 prompt injection。

Codebase 索引與 @ 命令

@ 命令是把外部 context（整個專案 / 終端機輸出 / docs）注入到 chat prompt 的擴充機制、讓 LLM 在回應時能參考超出選取範圍的資料。Continue 支援把整個 codebase 索引成向量資料庫、讓你用 @codebase 參考整個專案。要啟用：

1. ~/.continue/config.json 設定 embeddingsProvider（前面已給範例）。
2. 開新 chat 後在 prompt 內打 @codebase，Continue 會自動把相關片段加進 context。
3. 第一次索引要 5 ~ 30 分鐘（看 repo 大小），之後增量更新。

@codebase 對中型專案（< 1000 檔案）效果不錯、本地模型有機會找到合適片段；對大型專案（10000+ 檔案）效果受限於 embedding model 品質。大型專案的退路：拆 workspace 縮小索引範圍、改用 @file 明確指定相關檔案、或換較強的 embedding model（例如雲端 OpenAI text-embedding-3-large）。

其他 @ 命令：

處理 Continue 連不上 Ollama

常見錯誤訊息與處理：

排錯時先用 curl 驗證 Ollama 本身正常：

1curl http://localhost:11434/api/tags

如果這個都回不出來、問題在 Ollama；如果這個正常但 Continue 連不上、問題在 Continue 設定。

排錯時的機制判讀：

• Failed to fetch：通常是 Ollama 沒跑、或 listen address 配置不一致（Continue config 跟 OLLAMA_HOST 對不上）。
• address already in use：另一個 Ollama instance 佔了 port、或 LM Studio 啟動時也搶 11434。先用 lsof -i :11434 找佔用方。
• 長時間 spinner：第一次載入大模型（30 ~ 60 秒）正常；如果每次新 chat 都這樣、可能 keep_alive 太短、模型每次被 unload。
• 對話內容亂碼 / 一直重複：小模型 capacity 不足以維持長 context 連貫性、或 repeat_penalty 預設值對該模型不合適。先換較大模型驗證是不是 model 本身的問題、再回頭調 temperature / repeat_penalty。
• Tab autocomplete 沒觸發：autocomplete 模型沒 pull 成功、或 model 名稱拼錯。ollama list 確認 model 真的在。

何時 Continue.dev 不適合

Continue.dev 是 VS Code 環境內最成熟的本地 LLM 介面層、但在以下情境會撞到設計邊界、需要找替代路徑：

Continue 的甜蜜點是「VS Code 內、單檔到中型專案、人在駕駛位的 chat + inline edit」。離這個甜蜜點越遠、收益越低、改用 Cline / aider / Cursor 等工具更直接。

Continue.dev 跟 Cursor 的取捨

如果你正考慮 Continue.dev vs Cursor，下表是寫 code 場景的取捨：

對「本地 LLM 為主」的使用者，Continue.dev 是更直接的選擇。Cursor 是「雲端 LLM 為主、偶爾本地」的選擇。

下一章

下一章：1.4 寫 code 場景的模型選型優先順序，回答「Ollama 跑起來該裝哪個 model」。

讀完本章後、你應該能對自己的 IDE 工作流回答：每個 LLM provider 收到什麼 prompt、雲端服務的資料政策大致長怎樣、哪些任務該分到本地、哪些可以送雲端、配置誤送的常見路徑跟對應防護。

本章目標

1. 認識「prompt 邊界」在多 provider 工作流的位置。
2. 區分本地 LLM 跟雲端 LLM 在資料流上的差異。
3. 認識主流雲端 LLM 服務的資料政策大致分類。
4. 用「敏感度 × 任務類型」軸把工作流分流到本地或雲端。
5. 認識多 provider 設定下、prompt 誤送的常見路徑跟對應防護。

prompt 邊界在哪

在多 provider 工作流下、prompt 邊界長這樣：

 1                ┌───────────────────────────┐
 2                │  使用者 + 本機 codebase   │ ← trust zone A：完全本地
 3                └───────────────────────────┘
 4                            ↓ prompt
 5        ┌─────────────────────────────────────────┐
 6        │  IDE LLM client（Continue.dev）         │
 7        │   ↓ route by config                     │
 8        │   ├── 本地 model（Ollama / llama-server）│ ← trust zone B：仍在本機
 9        │   ├── 商業雲端（Anthropic / OpenAI）     │ ← trust zone C：雲端 vendor
10        │   └── 第三方 LLM 聚合（OpenRouter etc.） │ ← trust zone D：聚合層 + 上游 vendor
11        └─────────────────────────────────────────┘

每跨一條邊界、prompt 都會被另一個主體看到。trust zone B 是本機 process（包括其他可能 dump 流量的工具）、C 是商業 LLM vendor、D 是聚合層加上游 vendor、複雜度跟洩漏面隨層數增加。

本地 LLM vs 雲端 LLM 在資料流上的差異

混用的好處：

1. 敏感任務留本地：機密 codebase、PII、合約等不送雲端。
2. 能力受限任務送雲端：跨檔案重構、複雜推理用旗艦雲端模型。
3. 離線可用：本地當 fallback、雲端不可用時仍能基本運作。

混用的風險：配置稍微錯一步、原本想留本地的 prompt 被誤送到雲端。

主流雲端 LLM 服務的資料政策（大致分類）

各家雲端 LLM 服務的資料政策依方案跟版本變化、大致可以分成幾類：

事實查核註：上面是 2026 年 5 月主流商業 LLM 服務的常見政策分類、具體條款依 vendor、地區、方案、版本快速變化、且各家詞彙不一致（如「training」「improve our services」「abuse review」可能指不同範圍）。引用前以對應 vendor 的當前官方資料政策頁面、OpenAI Data Policy 等為準。

判讀重點不是「哪家最嚴」、是「我送進去的內容、貼合我的預期嗎」。

按敏感度 × 任務類型分流

把工作流分流到本地或雲端的兩軸：

1敏感度軸：
2  公開 / 一般 / 機密 / 高機密（PII、合約、未公開 codebase）
3
4任務類型軸：
5  補完 / 解釋 / 重構 / 設計討論 / 端到端 agent

對應的分流建議：

實務上的常見模式：

1. 預設本地、特定任務開雲端：日常工作走本地、需要旗艦能力時手動切。
2. 預設雲端、敏感任務切本地：日常走雲端旗艦、開機密 repo 時切本地。
3. 依 repo 切：用 Continue.dev / IDE 工具的「per-workspace config」、每個 repo 自己決定。

選哪種模式取決於工作流的敏感度分布。多數寫 code 個人 dev 屬於「一般 / 機密混合」、值得用模式 1 或模式 3。「哪個任務適合本地、哪個適合雲端」的任務面判讀見 1.5 期望管理、本章補上「分流之後的資料邊界」面。

Continue.dev 多 provider 配置範例

Continue.dev 基礎安裝跟單一 provider config 見 1.3 VS Code + Continue.dev 整合、本節聚焦多 provider 共存下的安全性設計。下面是一個合理的 Continue.dev 配置範例、把本地 + 雲端混用、清楚標出每個 model 的走向：

 1{
 2  "models": [
 3    {
 4      "title": "Local 30B MoE (default)",
 5      "provider": "ollama",
 6      "model": "qwen3-30b-a3b",
 7      "apiBase": "http://localhost:11434"
 8    },
 9    {
10      "title": "Local 14B (fast)",
11      "provider": "ollama",
12      "model": "qwen3-14b",
13      "apiBase": "http://localhost:11434"
14    },
15    {
16      "title": "Cloud Claude (premium only)",
17      "provider": "anthropic",
18      "model": "claude-sonnet-4-6",
19      "apiKey": "${env:ANTHROPIC_API_KEY}"
20    }
21  ],
22  "tabAutocompleteModel": {
23    "title": "Local autocomplete",
24    "provider": "ollama",
25    "model": "qwen3-14b"
26  }
27}

關鍵設計：

1. 預設模型是本地：list 第一個是 local、tabAutocomplete 也是 local。
2. 雲端模型 title 明確標記：「Cloud Claude」開頭、避免選錯。
3. autocomplete 永遠本地：補完的 prompt 流量大、autocomplete 屬於高頻、留本地。
4. API key 從環境變數：不寫死在 config 裡、避免 commit 進 git。

事實查核註：Continue.dev 的 config 格式跟 provider 支援度依版本變化、本範例為示意、實際引用以當前 Continue.dev 官方文件為準。

prompt 誤送的常見路徑

個人 dev 場景下常見的 prompt 誤送路徑：

1. 預設 model 設成雲端、按了 hotkey 沒看到當前 model：把寫到一半的機密 prompt 送到雲端。對應防護：預設改本地、雲端 model 用名稱前綴明確。
2. autocomplete 設成雲端：補完每幾秒就觸發、prompt 包含當前游標附近 code、流量大且持續。對應防護：autocomplete 必定本地。
3. codebase RAG 索引到 .env / secrets：RAG 把 secret 加進 prompt、再送雲端。對應防護：IDE search exclude 加上 .env、*.key、secrets/、.aws/。RAG 把外部內容引入 prompt 的整體機制與失敗模式見 4.1 RAG 原理。
4. 多 client 同時跑、key 共用：Cursor / Continue.dev / Claude Code 等多 client 共用 API key、難追是哪個 client 的流量。對應防護：給每個 client 各自的 API key、有問題能追溯。
5. 聚合服務不知道實際送到哪：用 OpenRouter / together.ai 等聚合層、prompt 經過聚合層後送到上游 vendor、上游可能是不同 region 不同政策。對應防護：個人 dev 場景傾向不用聚合、直接接 vendor。
6. forgot prompt history 含 sensitive content：某次貼了機密內容後、後續同 conversation 都帶著、不知不覺重複送。對應防護：機密 prompt 用獨立 conversation、用完清空。

個人 dev 場景的最低防護建議

1. 預設模型設成本地：避免誤觸發雲端。
2. autocomplete 必定本地：流量大、持續、適合本機處理。
3. API key 從環境變數讀、不寫死 config：dotfile commit 不會洩漏。
4. codebase search exclude .env / secrets 路徑：避免 RAG 索引到 secret。
5. 看完 prompt 內容再送雲端：對重要任務、value 不大但風險高時 prefer 本地。
6. 不同 client 用不同 API key：流量追溯。
7. 機密 prompt 用獨立 conversation：用完清空、不污染後續。

雲端 vendor 的 enterprise plan 選擇

當個人 dev 工作流穩定後、若要把雲端 LLM 用得更深、可以評估 enterprise plan：

選擇判讀：個人 dev 主要看「API key 預設政策」、若不夠用、再評估升級。

給讀者的跨邊界判讀流程

每次設新工作流 / 換 LLM client / 加新 model 時的判讀流程：

1. 盤點 model 列表：每個 model 是本地還是雲端、走哪家 vendor。
2. 看 vendor 的當前政策：別憑印象、看當前官方文件。
3. 設定 default model + autocomplete model：default 跟 autocomplete 是高頻路徑、優先本地。
4. 加 codebase RAG exclude：把 secret / sensitive path 排除。
5. 跑簡單測試：開個假機密 prompt（如「我的 SSH key 是 fake-key-test」）、觀察 client log 跟 vendor dashboard、確認流量去向符合預期。

下一章

靜態網站 / 沒 backend 場景的 prompt 邊界（API key 暴露、CORS、SaaS 信任、client-side abuse）見 4.16 靜態 / serverless RAG deployment 的資安段。

下一章：6.5 跨進 production 的 routing 中樞、整合本模組到 backend/07 production 場景的路由。