寫 code 工作流常混用本地 LLM 跟雲端 LLM、混用的好處是組合兩邊優勢、代價是 prompt 在不同信任邊界之間流動。本章把「哪些 prompt 該留本機、哪些可以送雲端、怎麼配置才不會誤送」整理成可操作的分流判讀。本章是 0.7 隱私資料流原理「資料流 thinking + 信任邊界」的具體落地、跟 1.3 VS Code + Continue.dev 整合 的 multi-provider 配置直接對應。信任邊界詞彙見 backend trust-boundary 卡、PII 跟資料分類見 backend pii / data-classification 卡、API key 管理見 backend secret-management 卡。本章 framing 是個人 dev 視角；production 場景的 log / PII 治理見 backend/07 LLM log 與 PII 治理。

讀完本章後、你應該能對自己的 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 場景的路由。