Claude Fable 5.1 完整指南：演進、Token 節省技巧與技能建構

進化、Token 節省、提示詞、Harness 與技能建構

2026 年 9 月 1 日，Anthropic 發布了「Claude Fable 5.1」。截至我撰寫本文的 2026 年 9 月 2 日，距離發布僅過了一天。因此，與其參考社群媒體上的主觀評論，我將根據 Anthropic 的官方文件、API 文件以及最新的 Claude Code 規格來整理這些資訊。

先說結論：Fable 5.1 不僅僅是一個「回答一般問題時稍微聰明一點的模型」。

它的本質在於能夠處理橫跨數小時或數天的任務，而不會偏離目標；能夠深入挖掘根本原因，而非停留在表面問題；並且能夠持續驗證自己的輸出，直到最後一刻。

然而，它的價格是 Opus 5 的兩倍，Sonnet 5 的五倍。此外，內部思考無法關閉。如果你把所有事情都丟給 Fable 5.1，你會在真正發揮其能力之前，就用完使用額度和預算。

掌握 Fable 5.1 的關鍵不僅在於寫出好的提示詞。

更重要的是 設計哪些特定任務要分配給 Fable、要載入哪些資訊，以及哪些流程要卸載給更便宜的模型或腳本。

第一部分：Claude Fable 5.1 完整解說

1. 什麼是 Claude Fable 5.1？

Claude Fable 5.1 被定位為 Anthropic 公開釋出的模型中能力最強的一款。

Fable 5.1 與僅限邀請的 Claude Mythos 5.1 本質上是同一個模型。差異主要在於安全措施。公開版本的 Fable 包含了強大的分類器，用於偵測網路安全、生命科學和化學等高風險領域。而 Mythos 則由經過審核的組織用於防禦性研究等目的。(Anthropic

主要規格如下：

對於個人 Claude 用戶，Pro、Max、Team 和 Enterprise 用戶均可使用。在 API 上，一般客戶無需特殊審核即可使用。(Claude Platform

100 萬 Token 的上下文，簡單計算可以一次處理幾本到十幾本書、大量的程式碼庫或長期的對話歷史。

然而，「可以容納 100 萬 Token」與「你應該放入 100 萬 Token」是兩回事。

你塞入越多不相關的檔案、舊對話和長日誌，重要資訊就越容易被埋沒。雖然 Fable 5.1 可以處理大量上下文，但它並不會自動為你中和不相關的上下文。

2. Fable 5.1 的進化是「工作更久」

Fable 5.1 最顯著的進化並非單次回答的準確度，而是其在 長時間 Agent 任務中維持一致性的能力。

一般的 AI Agent 在任務時間拉長時，容易產生以下問題：

• 忘記最初的目標。
• 只進行症狀修復，而不調查原因。
• 重複讀取相同的檔案或網頁。
• 中途任意縮小工作範圍。
• 宣告「接下來會測試」，然後就直接結束。
• 進行大量更改，但未能執行最終的操作檢查。

Fable 5.1 專注於改善這些在長時間工作中發生的崩潰情況。官方描述將編碼、瀏覽器操作、研究以及橫跨數小時到數天的文件/試算表/簡報製作列為主要使用案例。它被設計成能夠從失敗的步驟中恢復、重新排序優先級，並在維護自身工作日誌的同時繼續進行。(Anthropic

早期採用的公司回報了以下案例：

在 MongoDB，據報導它調查了服務程式碼和文件以建立新的設計，透過數小時的自動執行，在大約三天內完成了一個複雜的原型。在 Ramp，它針對一個機器學習問題連續運行了 38 小時，發現了過去結果中的標籤問題，並在修正後平行執行了六個實驗。(Anthropic

此外，在 Millennium 的一個案例中，據報導，針對一個百萬次才會發生一次的崩潰，該模型拆解了外部函式庫，並與核心轉儲進行交叉比對，最終找到了多年未被發現的原因。雖然這些是官方頁面上的客戶案例，並非獨立機構重現的結果，但它們清楚地代表了 Fable 5.1 的發展方向。(Anthropic

簡而言之，Fable 5.1 與其說是「一個會寫大量程式碼的 AI」，不如說是：

一個負責任的負責人，能夠隔離困難問題、收集必要資訊、嘗試多種方法、驗證證據，最後彙整結果。

3. 基準測試有哪些改進？

根據 Anthropic 發布的主要分數，Fable 5.1 在長期 Agent、科學研究和商業自動化方面有顯著成長。

在衡量科學終端任務的 Terminal-Bench-Science 0.1 中，它從 Fable 5 的 24.7% 上升到 52.6%。在衡量一般 Agent 編碼的 Terminal-Bench 4.0 中，它得分 55.8%，而 Fable 5 為 42.0%。具有不同安全限制的 Mythos 5.1 得分為 60.9%。

在衡量商業自動化的 AutomationBench 中，它從 Fable 5 的 17.1% 上升到 31.4%。在 CursorBench 3.2 中，Fable 5.1 得分 73.4%，而 Fable 5 為 70.5%，Opus 5 為 70.0%。

此外，在衡量跨領域高階推理的 Humanity's Last Exam 中，它在不使用工具的情況下得分 60.9%，使用工具時得分 65.0%。(Anthropic

然而，閱讀這些數字時需要謹慎。

這些是 Anthropic 發布的評估結果。此外，Fable 啟用了生產安全分類器；在分類器介入的問題上，它可能得分為零，或者流程可能轉移到另一個模型。因此，Fable 和 Mythos 之間的差異可能包含安全設定的差異，而不僅僅是純粹的模型能力差異。(Anthropic

此外，在發布後隔天的階段，比在基準測試中排名第一更重要的是你實際工作中的「任務完成率」。

例如，在文章製作中，僅靠文字評估是不夠的：

• 它能否根據原始來源驗證事實？
• 它是否遵循了指定的字數？
• 它是否移除了冗餘和矛盾之處？
• 它是否區分了引用和摘要？
• 從標題到結論是否一致？

除非你準備好這樣的實際評估，否則使用昂貴的 Fable 可能只會讓它長時間思考，卻沒有更好的結果。

4. 自適應思考現在始終開啟

在 Fable 5.1 中，自適應思考始終開啟。

與先前的模型不同，思考無法完全關閉。在 API 中指定 thinking: {type: "disabled"} 將會導致錯誤。人類指定固定思考 Token 數量的方法也不再可用；模型本身會根據問題調整思考量。(Claude Platform

使用者可以調整的是「effort」。

有五個可用級別：

• low
• medium
• high
• xhigh
• max

預設值為 high。

官方建議從 high 開始，然後根據實際評估結果降低或提高。對於例行處理，使用 medium 或 low；僅在非常困難的設計、除錯、研究或長期 Agent 工作時使用 xhigh 或 max。

據說 Fable 5.1 即使在 medium 下也能產生接近舊版 Fable 5 的效能，而在 low 下，對於某些工作，其每項任務的成本效益比可能比以 high effort 執行較小模型更高。(Claude Platform

這裡的重點是，內部思考也會作為輸出 Token 計費，並消耗 max_tokens。

例如，即使最終顯示在螢幕上的稿件是 10,000 個 Token，如果它在思考時使用了相當於 10,000 個 Token 的量，那麼總共將有 20,000 個 Token 需要按輸出端計費。由於 Fable 的輸出單價是每 100 萬 Token $50 美元，不必要地使用 max 會迅速增加消耗。(Claude Platform

Fable 5.1 不是一個「effort 越高就一定越有利」的模型。

對文字格式化或摘要使用 max，可能只會增加模型先在內部起草一份草稿，然後在回應欄位中再次撰寫的情況。Anthropic 也建議，原則上對於長篇交付物使用 high，只有當你能衡量到品質提升時，才升級到 xhigh 或以上。(Claude Platform

5. 高價格，但極其便宜的快取

Fable 5.1 的標準費率是每 100 萬輸入 Token $10 美元，每 100 萬輸出 Token $50 美元。

由於 Opus 5 是 $5/$25，Sonnet 5 是 $2/$10，就單純的 Token 定價而言，Fable 是 Opus 的兩倍，Sonnet 的五倍。(Claude Platform Docs

另一方面，Fable 5.1 的一個重大變化是快取讀取價格。

在 Fable 5 中，它是每 100 萬 Token $1 美元，而在 Fable 5.1 中變成了 $0.25 美元。這是正常輸入價格的 2.5%。Anthropic 估計，在典型處理中，這將比舊版 Fable 節省約 25% 的成本，而對於重複讀取快取的 Agent 處理，最多可節省約 45%。(Anthropic

例如，如果你每次讀取一個固定的 100,000 Token 上下文，按正常輸入費率每次花費 $0.10 美元，但如果快取命中，則只需 $0.0025 美元。

換句話說，以穩定形式重複讀取相同專案描述、工具定義、程式碼庫前提和對話歷史的工作更有利。

相反地，每次重寫系統提示詞、重新排序工具列表或刪除並重建舊對話的使用方式將會破壞快取。

在 Fable 5.1 中，不破壞快取的提示詞結構比巧妙的提示詞更直接地與成本相關。

6. Fable 5.1 可能會破壞現有的 API Harness

當從 Fable 5 或 Opus 僅更改模型名稱時，有三點需要特別注意：

強制工具呼叫不可用

在 tool_choice 中強制使用 any 或特定工具名稱將會導致 400 錯誤。

原因是強制工具呼叫會導致模型跳過正常的思考過程，並開始在工具參數內部思考，這會降低參數品質。

相反地，請使用 tool_choice: auto，並在提示詞中明確說明「請使用 XX 工具來處理此流程」。如果你想保證 JSON 格式，請使用 strict: true 或 Structured Outputs。(Claude Platform

對話歷史不得中途改寫

Fable 5.1 中的思考區塊與產生該思考時的系統提示詞、工具和過往訊息綁定。

如果你刪除舊訊息、重新產生系統提示詞或中途改寫過去的工具定義，後續的思考區塊將會失效。對於新帳戶，已經應用了使此條件違規成為錯誤的機制。(Claude Platform

基本原則是不要編輯歷史，只附加到末尾。

臨時指示應作為回合範圍的系統訊息添加，長上下文應使用伺服器端壓縮或上下文編輯來組織。

降級到更便宜的模型時，內部思考無法攜帶

Fable 5.1 可以讀取由先前模型（如 Opus 5、Fable 5 或 Sonnet）建立的思考區塊。

然而，反過來則不行。如果你將 Fable 5.1 建立的思考區塊傳遞給 Opus 或 Sonnet，這些模型無法讀取它。(Claude Platform Docs

因此，如果你在同一對話中切換模型，以下順序通常是安全的：

用便宜的模型探索 → 升級到 Fable

如果你從 Fable 降級回較便宜的模型，你必須將決策、未解決的問題、必要的檔案和驗證結果作為明確的交接文件留下，而不能依賴思考區塊。

7. 安全限制與資料保留

在 Fable 5.1 中，某些關於網路安全或生命科學的請求會受到安全分類器的限制。

在標準的 Claude 應用程式中，相應的處理可能會自動路由到 Opus 4.8 或 Opus 5。在 API 中，你需要設定後備設定。切換到其他模型的處理將不會按 Fable 費率計費。(Anthropic

此外，Fable 5.1 通常需要 30 天的資料保留期。除非你已獲得 Anthropic 的明確許可，否則它無法在標準的零資料保留環境中使用。

在處理公司機密程式碼、客戶資訊或未發表的研究資料時，你應該在確認合約和保留條件後再導入，而不是僅僅因為「效能高」就使用它。(Claude Platform

8. 最終，誰需要 Fable 5.1？

Fable 5.1 是為那些將整個工作的完成率（而非單一模型回應）視為價值的人準備的。

• 大型程式碼庫的調查與修改。
• 難以重現的錯誤的根本原因分析。
• 橫跨數十份文件的研究。
• 從研究到建立試算表、文件和簡報的任務。
• 長時間的瀏覽器操作或待辦事項處理。
• 自主規劃並執行多個實驗的研究。

相反地，對於建立電子郵件、簡短摘要、簡單程式碼生成、例行文件整理或起草社群媒體貼文，幾乎沒有必要使用 Fable。

Anthropic 本身建議一般處理從 Opus 5 開始，只有在即使以 high effort 執行 Opus 時品質仍然不足的情況下，才升級到 Fable。(Claude Platform Docs

Fable 5.1 不是一個「讓所有人從一開始就使用的標準模型」，而是一個用於突破難點的高階模型。

第二部分：Token 節省、提示詞、Harness 與技能建構

1. Fable 5.1 的 Token 節省技巧

節省技巧 1：不要讓 Fable 從探索階段就做所有事

最有效的節省方法不是寫短句子。

而是減少你呼叫 Fable 本身的次數。

將取得檔案列表、過濾日誌、分類資料、簡單摘要和格式轉換留給 Sonnet、Haiku 或一般腳本。

在以下階段使用 Fable：

• 決定研究方針
• 從幾個假設中選擇最有希望的一個
• 整合矛盾資訊
• 識別根本原因
• 審核最終交付物
• 重新審視其他模型失敗的問題

官方文件也指導使用多個模型的配置，以便宜的模型作為執行者，高階模型作為顧問或監督者。(Claude Platform Docs

節省技巧 2：為每個步驟更改 effort

你不需要將整個會話都設定為 max。

我建議以下分配：

Fable 5.1 也提供在對話期間更改 effort 的機制。與其改寫頂層設定，不如在對話中途將 effort 更改作為系統訊息添加，這樣可以維護提示詞快取。(Claude Platform

正確的做法不是「始終使用最大能力」，而是 「只在困難的步驟使用最大能力」。

節省技巧 3：保持歷史僅附加以保護快取

在 Fable 5.1 中，保持以下內容固定：

• 系統提示詞
• 工具定義和順序
• 專案通用規則
• 過往訊息
• 思考區塊

將所有更改附加到末尾。

如果你在建構自己的 API，維護相同的逐位元組前綴比每次重新組合系統提示詞更安全。

在 Claude Code 中，快取處理基本上是自動化的，但你可以在 API 中使用 cache_control。對於多輪對話，使用自動快取；對於分離長固定資料，使用明確的快取邊界。(Claude

節省技巧 4：不要直接傳入工具輸出

將 10,000 行的日誌交給 Claude 並要求它「找出錯誤」是浪費的。

先用腳本或 hook 過濾它們。

Claude Code 的官方成本指南也建議使用 hook 預先處理長日誌，只將必要的幾百行傳遞給模型。它還說明，在可用時使用像 gh、aws 或 gcloud 這樣的 CLI，比連接大量 MCP 伺服器更容易抑制來自工具定義的上下文消耗。(Claude

在讓 AI 讀取之前，先用機器剪掉可以剪掉的東西。

節省技巧 5：分組獨立工具呼叫

當讀取五個檔案時，如果你將其拆分為五次輪次，每次一個檔案，那麼每次都會發送對話歷史。

在 Fable 5.1 中包含以下指示是有效的：

「在內部組織必要資訊，並在同一輪次內平行執行不依賴彼此結果的讀取、搜尋和驗證。」

Anthropic 也解釋說，透過鼓勵在單一回應中分組獨立工具呼叫，可以減少往返次數、Token 數量和等待時間。(Claude Platform

節省技巧 6：不要讓它為了小修正而重寫整個檔案

Fable 5.1 可能會為了小變更而重寫整個檔案。

在你的通用規則中包含這句話：

「如果最終結果不變，不要重寫整個檔案；僅以最小的差異編輯必要部分。」

這對於長篇 Markdown、JSON、設定檔、LP 和大型原始碼特別有效。透過防止完整重新生成，可以抑制輸出 Token 和差異驗證的負擔。(Claude Platform

節省技巧 7：不要在相同會話中繼續不相關的工作

在 Claude Code 中，當轉向不相關的工作時，使用 /clear。

在長對話中，即使添加一個簡短問題，也意味著要再次處理過去的對話、讀取的檔案和工具結果。即使快取有效，也不是免費的。

如果你不想用臨時問題污染歷史，請使用 /btw；如果你想只保留必要內容，請使用 /compact。將程式碼庫探索卸載給子 Agent，並僅將摘要返回主對話。(Claude

2. Fable 5.1 的實用提示詞

對於 Fable 5.1，與其指定數十個詳細的思考步驟，不如清楚地傳達目標、範圍、完成條件和驗證方法更有效。

以下是一個基本模板，可以適用於編碼、研究、文章製作和文件建立。

角色

你是負責將此請求執行完成的人。

你不僅負責回答，還負責必要的研究、工作、驗證和修正。

目標

[寫下要建立的最終產品或要解決的問題]

輸入

[寫下檔案、URL、資料和前提條件]

範圍

要實作的項目：

• [強制任務]
• [強制任務]

不實作的項目：

• [超出範圍]
• [不希望任意更改的內容]

完成條件

當滿足以下所有條件時，任務即告完成：

1. [功能/內容的條件]
2. [格式/字數/品質的條件]
3. [驗證方法]
4. [證明沒有錯誤的證據]

執行規則

• 首先，整理必要資訊和依賴關係。
• 平行執行不依賴彼此結果的搜尋、讀取和驗證。
• 在請求範圍內進行可逆的工作，無需中途請求許可。
• 在修正之前，先確認原因，而不僅僅是問題的症狀。
• 不要執行未請求的功能添加、最佳化或周邊修正；將它們作為建議放在最後。
• 盡可能使用最小差異編輯檔案。
• 工作完成後，根據初始完成條件進行驗證。
• 如果驗證失敗，調查原因、修正並再次驗證。
• 不要以寫下「接下來要做什麼」來結束；去執行那項工作。
• 僅對破壞性操作或重大規格變更才在執行前請求確認。

最終報告

最後，按以下順序簡短報告：

1. 完成了什麼
2. 所做的更改
3. 驗證結果和證據
4. 剩餘問題
5. 注意到但超出範圍的改進候選項目

Fable 5.1 可以長時間持續工作，但如果完成條件不明確，它會繼續進行不必要的探索。

因此，寫下完成和停止條件比說「深入思考」更重要。

3. 利用 Fable 5.1 的 Harness 設計

Harness 是圍繞模型的工作機制。

與其僅依賴模型的能力，你從外部決定要傳遞什麼資訊、使用什麼工具、按什麼順序進行、在哪裡驗證，以及在失敗時重試多少次。

我推薦以下 6 層結構：

第 1 層：通用規則

在 CLAUDE.md 中，僅放置每次都需要的事實性專案資訊。

專案

• 此儲存庫用於 XX 服務
• 生產環境是 XX
• 使用 pnpm 進行套件管理

必要檢查

• 更改後執行 pnpm lint
• 更改後執行 pnpm test
• API 更改時進行型別檢查

限制

• 不要破壞現有 API 的相容性
• 不要將機密資訊輸出到日誌
• 不要在請求範圍之外進行重構

由於 CLAUDE.md 在每次對話中都會被讀取，內容過長會持續消耗上下文空間。官方文件建議將單一檔案控制在 200 行以內，並將長流程移至技能中。（Claude）

第二層：路由器

收到請求時，先分類工作內容，而不是直接啟動 Fable。

• 簡單的提取/格式化 → Haiku 或腳本
• 一般的實作/研究 → Sonnet
• 複雜的設計/分析 → Opus
• 長期工作/困難問題 → Fable
• 僅針對失敗的困難點 → Fable xhigh

建立自動路由器時，應根據「判斷錯誤的損失」、「所需自主時間」以及「驗證難度」來判斷，而非價格。

第三層：探索主導

將程式碼探索、資料收集和競品研究拆分給子 Agent。

每個子 Agent 在獨立的上下文中運作，僅將結論和證據回傳給主 Agent。這可以防止數十個檔案的讀取結果膨脹主對話的歷史紀錄。（Claude）

第四層：Fable 監督者

Fable 使用探索主導回傳的結果進行判斷。

• 採用哪個假設
• 是否需要額外研究
• 要進行哪些變更
• 結果之間是否有矛盾
• 是否滿足完成條件

不要讓 Fable 負責從原始資料收集開始的所有事情，而是將整理好的證據傳遞給它，讓它專注於判斷。

第五層：確定性驗證

不要只依賴提示詞來進行驗證。

• 對於程式碼：測試、Lint、型別檢查。
• 對於文章：字數、重複用詞、網址、引用。
• 對於試算表：公式錯誤、遺漏值、總計。
• 對於著陸頁：連結、版面破損、截圖比對。

使用鉤子，你可以在工具執行前後執行檢查。與其指望 LLM 記得要驗證，不如在固定條件下自動執行。（Claude Platform Docs）

第六層：修復迴圈

僅在驗證失敗時才回到 Fable。

建立 -> 機械驗證 -> 成功（完成）/ 失敗 -> 原因分析 -> 最小修復 -> 重新驗證

重要的是不要無限循環。

例如，設定「同一種失敗最多 2 次」或「總共失敗 3 次後附上證據停止」。對於能夠長時間工作的模型，如果沒有停止條件，成本和工作範圍將會無限膨脹。

對於使用數十到數百個子 Agent 的流程，請改用動態工作流程，而不是讓 Claude 依序管理它們。在工作流程中，你可以將中間結果保存在腳本變數中，並僅將最終結果回傳給主上下文，這使其非常適合大規模研究或處理大量檔案。（Claude）

4. 技能不是「長提示詞儲存庫」

技能是一種將重複使用的工作流程儲存為 SKILL.md 的機制。

與 CLAUDE.md 的區別在於，技能的本體僅在需要時才會被讀取。

• 專案資訊和始終遵循的簡短規則：CLAUDE.md。
• 文章製作、部署、研究、審查等流程：技能。
• 大量的範例或規格：技能的參考檔案。

這種分離直接關聯到 Token 的節省。（Claude Platform Docs）

我推薦以下結構：

1.claude/
2├── CLAUDE.md
3├── skills/
4│   └── deep-article/
5│       ├── SKILL.md
6│       ├── research-rules.md
7│       ├── writing-rules.md
8│       ├── examples.md
9│       └── scripts/
10│           ├── count_chars.py
11│           └── check_repetition.py
12├── agents/
13│   ├── researcher.md
14│   └── critic.md
15└── settings.json

在 SKILL.md 中，僅放置概述、執行條件、流程和完成條件。

將大量的解釋、API 規格和成功案例分離到不同的檔案中，讓 Claude 僅在必要時讀取它們。官方文件建議將 SKILL.md 保持在 500 行以內，並將詳細資料分離到輔助檔案中。（Claude Platform Docs）

5. 實用的 SKILL.md 範本

以下是一個用於建立研究文章的技能範例。

name: deep-article

description: 研究第一手資訊並建立附有證據的長篇文章。當需要對最新 AI、公司、系統或產品進行詳盡解釋時使用。

argument-hint: "[主題] [目標字數]"

effort: high

目標

建立一篇關於 $ARGUMENTS 的、經過事實查核的長篇文章。

基本規則

• 如果最新資訊相關，務必搜尋
• 優先使用第一手資訊
• 區分事實、公司公告、第三方評估和推測
• 為數字附上目標期間和定義
• 不要重複相同的結論或範例
• 首次提及時解釋專業術語
• 不要以低於指定字數 90% 的篇幅結束
• 最後，報告字數和未驗證項目

工作流程

1. 將主題劃分為 3-7 個研究點
2. 平行研究獨立的研究點
3. 收集第一手資訊
4. 調查反證或不利資訊
5. 建立事實列表
6. 決定結構
7. 建立初稿
8. 審查重複、跳躍、引用、日期和數字
9. 修正
10. 檢查字數

完成條件

• 結論在開頭清晰明確
• 讀者能決定下一步行動
• 重要事實附有來源
• 事實與推測沒有混淆
• 達到指定字數
• 沒有重複的段落

僅在必要時閱讀的材料

• 研究標準：research-rules.md
• 風格標準：writing-rules.md
• 良好完成範例：examples.md

最終檢查

執行以下指令：

• python ${CLAUDE_SKILL_DIR}/scripts/count_chars.py <output-file>
• python ${CLAUDE_SKILL_DIR}/scripts/check_repetition.py <output-file>

技能的描述不僅僅是解釋，它還扮演著路由器的角色。

與其寫「撰寫高品質文章」這種模糊的句子，不如寫「用於需要調查最新 AI、公司和系統第一手資訊的長文請求」，這樣更容易在必要時被呼叫。

由於 Claude Code 會將技能描述列表放入上下文中，撰寫過長的描述會增加持續成本。將重要的用途放在開頭，並保持簡潔。（Claude Platform Docs）

6. 技能的高階用法

不得自動執行的技能

部署、發送、刪除、發布和付款不得由 Claude 任意啟動。

設定 disable-model-invocation: true，僅在使用者明確輸入 /deploy 等指令時才執行。

不應污染對話的技能

對於執行大量研究或程式碼探索的技能，請設定 context: fork。

這會讓它們在獨立的子 Agent 上下文中執行。大量的檔案內容和搜尋歷史不會進入主對話；只有最終結果會回傳。（Claude Platform Docs）

自動注入當前狀態的技能

在技能內部，你可以預先插入指令的執行結果。

當前狀態

!git status --short

!git diff --stat

Claude 接收到的是執行結果，而不是指令字串。

然而，每次都注入完整的 git diff 或大量日誌是適得其反的。先只放入 --stat 或錯誤行，等到必要時再讓它讀取詳細資訊。（Claude Platform Docs）

為技能設定 effort

將簡單的技能設為 medium，設計審查和深度研究設為 high，極度困難的審計設為 xhigh。

如果每個技能都有自己的 effort 設定，使用者就不需要每次都切換。

7. 始終進行比較評估技能

僅僅建立一個技能並不能告訴你品質是否提升。

官方文件指導分別評估兩件事：

1. 技能是否在收到必要請求時正確啟動？
2. 啟動技能後，交付成果是否真的變得更好？

在「有技能」和「無技能」的新對話中執行相同的請求。

對於文章技能，比較字數、遺漏來源、重複、事實錯誤和修正次數。對於程式碼技能，比較測試成功率、變更檔案數、不必要的變更和返工次數。

在建立技能的對話中進行測試，會因為對話中的補充資訊而隱藏缺陷。務必在新的對話中進行評估。Claude Code 也提供了一個官方的技能建立外掛程式來支援這種比較。（Claude Platform Docs）

最終結論

Claude Fable 5.1 並非單純加速 Claude 系列的模型。

它的最大價值在於能夠長時間持續處理困難工作、從中途失敗中恢復、搜尋根本原因，並在驗證自身結果的同時將工作完成。

另一方面，其輸入和輸出單價是 Opus 5 的兩倍。內部思考無法關閉，與改寫舊對話的框架不相容，也無法使用強制工具呼叫。

因此，最強的使用方式如下：

**用 Sonnet 或腳本縮小資訊範圍。

用子 Agent 分離探索。

將困難的判斷和整合分配給 Fable。

用鉤子和測試進行機械驗證。

僅對失敗的困難點提高 effort。

將重複流程儲存為技能。

保持對話歷史為僅追加模式以保護快取。**

如果你將 Fable 5.1 當作「什麼都能回答的高階聊天機器人」來使用，只會得到高昂的價格。

唯有將 Fable 5.1 定位為整合廉價模型、技能、子 Agent、鉤子和驗證迴圈的監督者時，它與前幾代的真正差異才會顯現出來。