# 影片筆記：Give Me 10 Mins and I'll Save You Millions of Claude Tokens

## 一句話總結
講者透過解析 Claude 的 Prompt Caching（提示詞快取）機制，說明如何透過理解快取層級、TTL 規則及善用專案管理，在單日節省數千萬 Tokens，並強調根據自身需求篩選資訊的重要性。

## 核心重點
1.  **Prompt Caching 的成本優勢**：快取內的 Tokens 僅收取正常輸入成本的 10%，Anthropic 高度重視快取命中率。
2.  **TTL（生存時間）差異**：
    *   Claude 訂閱方案：預設 TTL 為 1 小時。
    *   API 與 Subagents：預設 TTL 為 5 分鐘（可調整但成本較高）。
    *   超過時間未操作或更改系統提示詞，快取會失效（Uncached），需重新全量處理（Recache），成本高昂。
3.  **快取結構層級**：
    *   **系統層（System Layer）**：系統指令、工具定義、輸出風格（全域快取）。
    *   **專案層（Project Layer）**：Claude.md、Memory、規則（專案級別快取）。
    *   **對話層（Conversation Layer）**：回覆與訊息（隨對話增長，需重新處理）。
4.  **快取創建與讀取**：
    *   **Cache Create**：首次寫入快取的一次性成本。
    *   **Cache Read**：重複使用快取內容（如 Claude.md、系統指令），成本較低。
5.  **影響快取的因素**：
    *   切換模型（如從 Opus 切換到 Sonnet）會改變前綴（Prefix），導致快取失效。
    *   Opus Plan 模式：規劃階段使用 Opus，執行階段使用 Sonnet，中途切換模型會重置快取。
    *   建議將大型文件放入 Projects 而非直接貼入 Chat，以獲得更優化的快取。
6.  **實用工具與習慣**：
    *   使用 **Token Dashboard** 追蹤每日輸入、輸出及快取創建/讀取的 Tokens。
    *   使用 **Session Handoff Skill** 透過複製摘要、清除會話並貼上，模擬「會話移交」，避免長時間暫停導致快取失效。
    *   **三個關鍵習慣**：不要暫停太久（超過 1 小時請開啟新會話）、切換任務時重新開始、使用專案管理大型文件。
7.  **個人學習策略**：
    *   雖然其他文章在深度與細節上做得很好，但講者基於自身未重度使用 API 的情況，決定不學習過多內容。
    *   核心在於釐清自己真正需要掌握的重點，而非盲目追求資訊更新。

## 詳細大綱

### 一、Prompt Caching 效益與成本結構
*   **實際節省案例**：講者分享利用 Claude 的 Prompt Caching 機制，在單日節省 9100 萬 Tokens，過去一周節省超過 3 億 Tokens。
*   **成本計算**：快取內的 Tokens 僅收取正常輸入成本的 10%。
*   **Anthropic 的監控**：Anthropic 對快取命中率（Hit Rate）進行監控與重視。

### 二、快取機制與 TTL 規則
*   **TTL 差異**：
    *   **Claude 訂閱方案**：預設 TTL 為 1 小時。
    *   **API 與 Subagents**：預設 TTL 為 5 分鐘。
*   **快取失效後果**：
    *   若超過時間未操作，快取會失效（Uncached）。
    *   更改系統提示詞也會導致快取失效。
    *   失效後後續請求需重新全量處理（Recache），成本高昂。

### 三、快取結構層級解析
*   **系統層（System Layer）**：包含系統指令、工具定義、輸出風格。屬於全域快取。
*   **專案層（Project Layer）**：包含 Claude.md、Memory、規則。屬於專案級別快取。
*   **對話層（Conversation Layer）**：包含回覆與訊息。隨每次對話增長，需重新處理。

### 四、快取創建（Create）與讀取（Read）
*   **Cache Create**：首次寫入快取的一次性成本。
*   **Cache Read**：重複使用快取內容（如 Claude.md、系統指令），成本較低。
*   講者提到因 "cash read"（疑為 Cache Read）節省了 9100 萬 Tokens。

### 五、影響快取的因素與誤區
*   **切換模型**：會導致前綴（Prefix）改變，使快取失效並重新快取。
*   **Opus Plan 模式**：規劃階段使用 Opus，執行階段使用 Sonnet，中途切換模型會重置快取。
*   **Cloud Chat 與 Projects 差異**：建議將大型文件放入 Projects 而非直接貼入 Chat，以獲得更優化的快取。
*   **建立 HTML 專案**：講者提到建立 HTML 專案時消耗了 205,000 Tokens。

### 六、實用工具與習慣
*   **Token Dashboard**：講者提供的追蹤工具，用於追蹤每日輸入、輸出及快取創建/讀取的 Tokens。
*   **Session Handoff Skill**：講者提供的 Skill，透過複製摘要、清除會話並貼上，模擬「會話移交」，避免長時間暫停導致快取失效。
*   **三個關鍵習慣**：
    1.  不要暫停太久（超過 1 小時請開啟新會話）。
    2.  切換任務時重新開始。
    3.  使用專案管理大型文件。
*   **指令操作**：
    *   `/slash compact`
    *   `/slash clear`
    *   `/slash model`
    *   `/slash copy`

### 七、結尾：資訊篩選與個人需求
*   **資訊篩選**：講者表示雖然其他文章在深度與細節（nuance）上做得很好，但由於講者目前並未重度使用 API，因此不需要掌握那些過於深入的內容。
*   **學習態度**：保持資訊更新與追蹤趨勢固然重要，但核心在於釐清自己真正需要掌握的重點。
*   **互動請求**：感謝觀眾觀看至影片結尾，並請求觀眾按讚（like）以支持頻道。

## 工具 / 模型 / 名詞整理
*   **Claude Code**
*   **Claude**
*   **Anthropic**
*   **Claude.md**
*   **Opus**
*   **Sonnet**
*   **Opus Plan** (模型設定模式)
*   **Token Dashboard** (講者提供的追蹤工具)
*   **SessionHandoffSkill** (講者提供的 Skill)
*   **GithubRepo**
*   **FreeschoolCommunity**
*   **Cloud Chat** (或寫作 Clouded.ai / CloudedCode，依逐字稿原文)
*   **Slash Compact** (指令)
*   **Slash Clear** (指令)
*   **Slash Model** (指令)
*   **Slash Copy** (指令)
*   **API**
*   **Cache Create**
*   **Cache Read**
*   **TTL (Time To Live)**
*   **Hit Rate**
*   **Prefix**
*   **Recache**
*   **Uncached**
*   **System Layer**
*   **Project Layer**
*   **Conversation Layer**
*   **SEVs** (講者提到 "declare SEVs"，疑為 "Service Events" 或特定內部術語縮寫)

## 操作流程整理
1.  **監控與追蹤**：
    *   使用 **Token Dashboard** 追蹤每日輸入、輸出及快取創建/讀取的 Tokens。
2.  **專案管理優化**：
    *   將大型文件放入 **Projects** 而非直接貼入 Chat。
    *   利用 **Claude.md**、**Memory** 和規則建立專案層級快取。
3.  **會話維護與移交**：
    *   避免長時間暫停（超過 1 小時）。
    *   若需暫停，使用 **Session Handoff Skill**：
        1.  複製當前摘要。
        2.  清除會話。
        3.  貼上摘要以模擬「會話移交」。
4.  **指令操作**：
    *   使用 `/slash compact`、`/slash clear`、`/slash model`、`/slash copy` 等指令進行操作。
5.  **模型切換注意事項**：
    *   在 **Opus Plan** 模式下，規劃階段使用 Opus，執行階段使用 Sonnet。
    *   避免中途切換模型，以免重置快取。
6.  **資訊篩選**：
    *   評估自身是否重度使用 API。
    *   若不重度使用，則篩選資訊，不學習過於深入的内容，專注於核心需求。

## 值得注意的限制或風險
1.  **TTL 失效風險**：
    *   API 與 Subagents 的預設 TTL 僅為 5 分鐘，若操作間隔過長，快取會失效，導致成本大幅增加。
    *   Claude 訂閱方案雖有 1 小時 TTL，但仍需避免過長暫停。
2.  **模型切換成本**：
    *   切換模型（如從 Opus 到 Sonnet）會改變前綴，導致快取失效並需重新快取，產生高昂成本。
3.  **系統提示詞變更**：
    *   更改系統提示詞會導致快取失效，需重新全量處理。
4.  **快取創建成本**：
    *   首次寫入快取（Cache Create）是一次性成本，需評估是否值得。
5.  **大型文件處理**：
    *   直接將大型文件貼入 Chat 可能無法獲得優化的快取，建議使用 Projects。
6.  **Opus Plan 模式限制**：
    *   規劃與執行階段使用不同模型，中途切換會重置快取。

## 逐字稿辨識疑點
*   **cash read**：逐字稿中出現 "saved 91 million tokens because of cash read"，疑為 "Claude" 或 "cache read" 之聽寫錯誤。
*   **Cloud subscription / Cloud Code**：逐字稿中多次出現 "Cloud"，疑為 "Claude" 之聽寫錯誤（如 "working with Cloud Code", "Cloud subscription"）。
*   **Thorik / Thorax graphics**：逐字稿引用 Anthropic 人員時寫作 "Thorik" 及 "Thorax graphics"，疑為特定人名或圖表名稱，需查證。
*   **ClawedCode / Clawed.ai**：逐字稿中出現 "ClawedCode" 及 "Clawed.ai"，疑為 "Claude Code" 或 "Claude.ai" 之聽寫錯誤。
*   **SEVs**：逐字稿提到 "declare SEVs"，疑為 "Service Events" 或特定內部術語縮寫。
*   **205,000TOKENS**：講者提到建立 HTML 專案時消耗此數量的 tokens，語境中數字可能為聽寫誤差或特定專案數據。
*   **這個組織的組織的組織...**：逐字稿後半段出現大量重複且語意不明的「組織」一詞（如 "这个组织的组织的组织", "如果你转过去的电话"），疑為語音辨識嚴重錯誤或模型生成亂碼，無法確定實際指涉內容。
*   **Opus plan**：逐字稿寫作 "model opus plan"，指涉 Opus 模型的 Plan 模式設定。

## 可延伸追問
1.  如何具體設定 API 與 Subagents 的 TTL 以平衡成本與便利性？
2.  "SEVs" 在 Anthropic 內部或特定情境下的具體定義為何？
3.  "Session Handoff Skill" 的具體操作步驟與最佳實踐為何？
4.  對於重度使用 API 的用戶，有哪些進階的快取優化策略？
5.  如何準確識別並避免 "Opus Plan" 模式下的模型切換風險？
6.  "Token Dashboard" 的具體功能與使用介面為何？
7.  如何評估將大型文件放入 Projects 的具體效益與成本？
8.  對於非重度 API 用戶，如何有效篩選資訊以避免資訊過載？