Claude 分流實戰:訂閱 / API / Foundry / 本地怎麼選 + 省 Token

很多人把「用 AI 怎麼划算」想成「省 token」,其實真正的重點在更上層:哪種工作該走哪個通道(訂閱 / API / Azure Foundry / 本地),以及怎麼分階段切換。把通道分對、把資料分流對,比你在單一通道裡省那幾個 token 重要太多。這篇先講分流與分階段(大局),再講進了通道之後怎麼省 token、保持聰明(底層功夫)。所有定價與快取數字都以官方資料核對過。

Part 1|分流:哪種工作走哪個通道

第一件要釐清的事:「訂閱 vs API」不是「機密與否」的軸。訂閱和 API 都是把資料送到 Anthropic 雲端,兩者差別是計費方式與資料條款,不是「資料會不會外洩」。真正的機密分流要靠第三、第四個選項:留在你既有雲邊界的 Azure Foundry,以及完全不出公司的本地 LLM。先把三條軸分開:

• 機密軸:本地 ↔ 雲端。決定資料能不能離開公司。
• 信任邊界軸:Anthropic 自己的雲 ↔ 你既有的雲(Azure/AWS/GCP)。Foundry 讓資料留在公司已核准的 Azure 邊界。
• 計費 + 模式軸:訂閱(互動、固定費)↔ API(程式化、按量、商用條款)。

哪些資料可以做哪些:三層分流

資料類型	走哪	為什麼
公開 / 不重要	訂閱	便宜;公開資料不怕被拿去訓練
內部但不機密(已在 Azure)	Azure Foundry(或商用 API)	留 Azure 邊界、預設不訓練、可開 ZDR
機敏 / 涉密 / 不確定	本地 / 地端 LLM	絕不上雲;default-deny,不確定就當機敏

為什麼公司資料走 Foundry 是最佳解?因為信任邊界早就跨過了。如果你的 code 已經在 Azure DevOps、公司也接受 Azure Foundry,那走 Foundry 的 Claude 是留在同一個 Azure 邊界裡推論,不是再送到 Anthropic 自己的雲——邊際的資料暴露趨近於零。它複用你早就過關的 Azure 合約與資料條款,比直連 Anthropic API 更乾淨。(注意:Foundry 是功能子集,不支援 Anthropic 的 Managed Agents 與 server 端工具,純 code 生成 / 對話 / 一般 tool use 沒問題。)

你的工作 → 用哪個

工作	性質	用哪個
ESG 討論 / 問問題	公開、通用	訂閱
ESG 文案(通用骨架)	公開	訂閱
ESG 文案(含公司真實數據)	內部	Foundry 或假資料混合
專案討論(通用、不涉密)	一般	訂閱
專案討論(涉公司設計 / 架構)	公司資產	Foundry
開發 / BUG(公司 code)	公司資產	Foundry

切換規則:只要問 2 個問題

預設是訂閱(互動 + 公開),只有「踩到公司資料」或「要自動化」才翻到 Foundry / API。重點:這是按任務類型路由,不是每句話狂切——你開一個工作時就決定走哪條,不會中途換。兩個帳戶(訂閱 + Foundry/API)各管各的場景,既省又乾淨:訂閱吃高頻互動 + 公開的大量量(已預付、邊際成本趨近 0),Foundry/API 只碰公司資料 + 自動化(貴通道只餵小東西)。

公司用的「訂閱」是商用方案,不是員工個人帳號

上面講「公司資料用訂閱也行」時,有個關鍵前提要釘清楚:處理公司的東西,要用「公司開的商用訂閱」(Team / Enterprise),不是員工個人的消費級 Pro / Max。這跟資料機不機密是兩道分開的閘——就算沒有機敏問題,帳戶條款與治理仍是另一關。

帳戶	處理公司(非機敏)事	為什麼
員工個人 Pro / Max(消費級)	⚠️ 不建議	消費級條款,資料預設可能被拿去訓練(除非手動關);無 DPA;公司無管控/稽核;工作綁個人帳號,人離職就失去
公司開的 Team / Enterprise	✅ 可以	商用條款、不訓練、有 DPA、admin 管控、帳號歸公司
公司 API / Azure Foundry	✅ 可以	商用條款、可自動化;Foundry 還能留 Azure 邊界

一句話:非機敏不代表可以走消費級條款。公司的東西用公司商用帳戶,別躺在某個員工的個人訂閱裡,否則訓練、稽核、離職交接、IP 歸屬全是漏洞。(消費級的確切訓練/保留條款 Anthropic 改過幾次,對外講死前建議查當下版本;但商用 vs 消費級的分野是穩的。)

從零開發:原型用訂閱,串真資料才切 Foundry

把上面的原理套到「從零開發一個東西」的生命週期,就是這篇最實用的一招。原型階段沒有任何公司資料,用訂閱快速迭代;等要串接真實公司資料,才切到 Foundry。但切換點不是「原型做完了」這種階段標籤,而是一個具體的資料事件:

第一次「真公司資料 / 真 schema / 真憑證 / 真專有邏輯」要進 prompt 的那一刻——在這之前,全部留訂閱。

換句話說,只要你餵進去的還是假資料 / mock / 通用結構,就算你在寫「串接用」的 code,也還能留在訂閱:

階段	餵進去的是什麼	用哪個
原型 / scaffolding	通用架構、mock 資料、假 schema	訂閱(快、便宜、高頻迭代)
串接(打 fake schema / mock)	仍是假的,只是形狀對	還是訂閱
串接(碰真 schema / 真資料)	真公司東西	Foundry(留 Azure 邊界)

有一個判斷會決定你「切多早」:機密的是「值」還是「結構」?

• 只有資料值機密、schema 是通用的 → 用假資料混合法,幾乎全程留訂閱,真值在自己這端換回去,Foundry 幾乎用不到。
• schema / 業務邏輯本身就機密(欄位名洩漏商業設計)→ 一碰真結構就切 Foundry,切得比較早。

三個實務提醒:(1) 原型從第一天就用合成 / mock 資料,別圖方便把真實樣本烤進原型——一旦烤進去,訂閱階段就不乾淨了。(2) 切換是一個真步驟:換後端 / 換 key / 換設定,切完跑個 smoke test 確認行為一致(不同後端 model 版本可能微差)。(3) 快取不跨帳戶,切過去第一次是冷的,正常。

假資料混合法:真機敏值永遠不出公司

當產出真的要碰機敏值,用「假資料 → 產出 → 換回真資料」三步,讓你既能用最強的雲端模型產出,真機敏值又完全不離開公司:

1. 在自己這端,把機敏欄位換成假資料 / 佔位符(masked)。
2. 把「假資料版」丟給雲端 LLM,產出結構、內容、排版、分析框架。
3. 在自己這端把真資料 find-replace 換回佔位符。

讓這招順的關鍵是佔位符要一致、可一鍵全域取代——用穩定命名如 [公司名]、{{2025_範疇一排放量}},不要散落同義變體;需要假數字時標明是佔位值,別混入像真的數字。程式碼也適用:含活憑證(API key、DB 密碼、內部 endpoint)的檔案一律先抽掉再送,那是另一種洩漏面,跟在不在 Azure 無關。

Part 1 一句話:資料先過機密分類,再決定通道;原型用訂閱、串真資料才切 Foundry、機敏走假資料混合或本地。把通道分對,比省 token 重要得多。

Part 2|底層功夫:進了通道之後怎麼省 token、保持聰明

通道分對之後,才輪到「在通道裡怎麼用得省又聰明」。這部分是底層功夫——對訂閱省的是「使用額度」,對 API/Foundry 省的是「真金白銀」,而且省 token 不只省錢,還能讓模型保持在最聰明的狀態。

Context 是乘數:為什麼長對話又貴又笨

Context(對話視窗)不是只算一次,而是每一輪都重算一次。我讀進一個 2000 行的檔,那 2000 行接下來每一輪對話都重新帶著計費。所以「在對話早期讀一個大檔」會污染後面整段對話的成本。

更關鍵的是:長 context 不只貴,還會讓模型變笨。Chroma 對 18 個前沿模型(含 Claude Opus 4、GPT-4.1、Gemini 2.5)的實測顯示,每一個都隨輸入變長而退化——即使「需要的資訊 100% 在 context 裡」,準確率仍隨長度掉 13.9% 到 85%。這叫 context rot。所以省 token 同時是讓模型保持聰明。另外兩個失效模式:Lost in the middle(關鍵埋中段準確率掉 30%+,重要指令放開頭、當前問題放最後)、context poisoning(混進一個幻覺會被當前提複製,該截斷到污染點之前重啟)。

三個動作:繼續、compact、clear 怎麼選

動作	對之前對話做了什麼	能否接著聊同一件事
繼續聊	全部逐字帶著	能,但越疊越大、越慢、越貴、越笨
/compact 壓縮	換成一份摘要(有損,細節掉、重點留)	能,thread 不斷
/clear 清除	全部丟掉(只剩 CLAUDE.md、auto memory 重載)	不能,這次記憶歸零

原則:同一件事還要繼續且馬上繼續,用 compact;要停一陣、換事、或 context 已經很肥,先寫筆記再 clear。

5 層記憶模型:Note 與 Brain 是兩條垂直的軸

層	存什麼	活多久 / 何時載入
Context 對話視窗	這次對話的一切	clear 就沒;每輪都在、每輪算錢
Note 接手筆記	做到哪、下一步	任務做完即丟;叫它讀才讀
MEMORY.md	你是誰、偏好、專案狀態	跨所有對話;每次開對話自動載
Brain	踩過的坑 + 領域知識	永久跨專案;宣告 Domain Brain 才載
Skill	正確做法的模板	永久;用到才呼叫

最容易混淆的是 Note 跟 Brain,它們是兩條互相垂直的軸:Note 答「這次做到哪」(短期、綁任務、會過期);Brain 答「這類事怎麼做才不踩坑」(永久、跨專案)。clear 時 Note 把工作進度帶過去、Brain 把教訓帶過去——不是二選一,兩個都寫但寫不同東西,一個搬狀態、一個搬智慧。

Context × Loop:乘數效應在迴圈裡會放大

用 /loop 或排程反覆跑時,單輪成本是「context 大小 × 1」,帶著肥大 context 的迴圈是「context 大小 × 迭代次數」。所以每一輪開始前把 context 收乾淨,比一路累積更省也更準:每次迭代讀回精簡狀態檔(Note)→ 做這一輪 → 寫回狀態檔 → 收掉工作 context。狀態活在檔案裡,活躍 context 保持小而新鮮,這就是 long-running agent 能跑幾十輪不退化的關鍵。

ccbot 是 UI 工具,不是 context 容器

ccbot 這種「review → triage → 逐條修」一次幾十條 finding 的流程,最容易把上面所有原理一次踩雷。它應該被當成一個「UI 工具」——讓你逐條決策的介面——而不是用來長壓 context 的容器。心法:一個 finding(或一個 cycle)就是一個任務邊界,分批做、批次之間 clear,絕不一個對話硬幹幾十條。到約 100K token 時 context rot 發作,後面越判越糊;分批 clear 反而讓每條都用最乾淨的腦判,還更省 token。每條判完把「決定→存檔、教訓→Brain、進度→Note」三件事歸位,再開乾淨 context 做下一條。

API / Foundry 端怎麼算成本(含程式範例)

走 API / Foundry 時 token 直接是帳單,值得認真算。先講怎麼量——不要用 tiktoken(那是 OpenAI 的 tokenizer,對 Claude 會低估 15–20%)。用官方 count_tokens:

from anthropic import Anthropic

client = Anthropic()
resp = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": open("CLAUDE.md").read()}],
)
print(resp.input_tokens)

成本公式:(input ÷ 1,000,000 × input 單價) + (output ÷ 1,000,000 × output 單價)。以 Opus 4.8($5 / $25)、50,000 input + 2,000 output 為例:input $0.25 + output $0.05 ≈ $0.30/次。加上 prompt caching(同一大前綴重複用):讀取只要基礎 input 價約 0.1 倍,寫入 1.25 倍(5 分鐘)或 2 倍(1 小時)。同樣 50K 前綴重複 10 次:不快取 $2.50,有快取 ≈ $0.54,省約 78%。

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    system=[{
        "type": "text",
        "text": LARGE_STABLE_CONTEXT,        # 穩定的大前綴
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": user_question}],  # 變動內容放後面
)
print(response.usage.cache_read_input_tokens)   # 驗證命中;一直是 0 = 前綴被污染

快取是前綴完全比對,差一個字元就全 miss——常見元兇:datetime.now()、UUID、沒排序的 json.dumps()、或工具清單變動(工具一改整個快取全滅)。非即時的批量工作可走 Batches API,直接半價。

各模型定價與快取門檻(官方數字)

模型	Input $/1M	Output $/1M	Context	適合的活
Fable 5	$10	$50	1M	最難的長程推理 / agentic
Opus 4.8	$5	$25	1M	架構決策、複雜推理、跨檔案邏輯
Sonnet 4.6	$3	$15	1M	CRUD、API 對接、測試、文件
Haiku 4.5	$1	$5	200K	檔案掃描、目錄盤點、簡單搜尋

「最低可快取前綴」門檻各模型不同,而且不按貴賤排——這點最反直覺:

模型	最低可快取前綴
Opus 4.8 / Haiku 4.5	4,096 tokens
Sonnet 4.6 / Fable 5	2,048 tokens

具體後果——同樣一段 3,000 token 的前綴,在 Sonnet 4.6 與 Fable 5(門檻 2,048)快取得起來,在 Opus 4.8 與 Haiku 4.5(門檻 4,096)卻會靜默不快取,你不會收到錯誤,只會發現帳單沒省到。所以用 Haiku 做大量小請求時,若前綴不到 4,096,拿不到任何 cache 折扣。門檻不按貴賤排,別憑感覺假設;不同模型 tokenizer 也不同,跨模型估成本一定要用該模型自己的 count_tokens 重算。

省過頭反而害事:三個要避免的過度優化

1. 壓縮砍太狠:摘要寧可先求高 recall(多留)再慢慢收。一開始壓很乾,會砍掉日後才變關鍵的細節,逼出更多來回反而更貴。
2. 為省而硬拆多輪:研究顯示同一 prompt 拆成多輪累積,品質掉 39%(context clash)。該一次講清的別硬切。
3. 濫用子代理:多代理約用 15 倍 token。廣度研究、檔案掃描很划算;緊耦合、要共享上下文的事用子代理反而又貴又糊。判準:任務價值 > token 成本才划算。

一句話心法