Fable 5.1 上線，Fable 5 的八個提示要點哪些要重測

你把舊模型時代寫的 skill（可重用的任務指令）原樣搬到 Claude Fable 5，Anthropic 的 Fable 5 提示指南說，這類 skill 常常規定得太細，還可能拉低輸出品質。官方、Claude Code 團隊的 Thariq（X 帳號 @trq212）、Anthropic 的 Boris Cherny（X 帳號 @bcherny）和研究員 Alex Albert 的建議，下表排成八個要點。

「舊做法」欄是本站歸納各來源要取代的寫法，不代表你以前一定這樣寫；「新做法」欄的內容都出自表中的出處。Anthropic 技術團隊成員 Lance Martin 的實驗補在第六列。

快速回答 Fable 5 的提示重點是少寫做法，多寫目標、理由和驗收方式；刪舊指令前，先用同一組任務比較效果。長任務的驗證，另開不含原工作對話的驗證者（verifier）。Anthropic 建議 effort（控制思考量的參數）用 high 起步，最吃能力的任務用 xhigh，換到 2026 年 9 月 1 日上線的 Fable 5.1 後要重測各檔位；要求模型把內部推理寫進回答，仍可能觸發拒答。

這張卡把八個要點收成五條。下文依表的順序逐列展開，每一列先寫來源怎麼說，再寫落到系統上改的是哪裡，本站自己的建議另外標明。

寫指令的四條，各自改了什麼？

四條都往同一個方向改：少寫做法，多寫要做到什麼、為什麼要做、怎麼驗收。官方的「Prompting best practices」寫著「一般性指令優先於規定步驟」（原文 "Prefer general instructions over prescriptive steps"）；Alex Albert 在 2026 年 6 月 9 日的貼文裡給了同樣的方向。

步驟清單該換成什麼？

換成完成狀態加驗證方式。Alex Albert 在 Fable 5 上線當天（2026-06-09）給新用戶四個建議，最後一條是從給任務改成給目標：描述做完長什麼樣、怎麼驗證，再讓 Fable 找路徑，Claude Code 的 /loop 與 /goal 就是為此做的。官方的 Fable 5 指南在「Recommended scaffolding changes」第一條建議，挑一個比以前交給舊模型的更難的任務，讓 Fable 5 自己界定範圍、提問、做完。

工程上的意思：skill 裡「第一步…第二步…」的段落，要改成「完成條件」和「驗證指令」，例如寫明跑哪一組測試、看哪個輸出。步驟寫得越細，越容易在模型該轉向時把它綁在原路上，Thariq 在 7 月的文章裡也說了同樣的取捨，下面第四條會談到。

舊的 skill 和 CLAUDE.md 要先刪嗎？

要先檢查，預設表現比較好的就刪。官方指南說：

"Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality."

同一節接著建議，若預設表現更好，就考慮移除舊指令，並指出 Fable 5 在工作中也會根據學到的東西更新 skill。Alex Albert 的第三條建議說得更直接：為舊模型寫的指令會把 Fable 錨定在過時的做法上，先讓它用自己的判斷。

Boris Cherny 在 2026 年 6 月 9 日的貼文裡給了一個具體例子。他請 Fable 5 除錯，它先量測、加 log，確認真的修好才宣布完成。他寫道：

"There's nothing in claude code's prompting telling the model to do that, it's just part of its personality."

本站的建議：Boris 沒有說該刪哪一條。如果你的 skill 裡有「先重現問題再修」「改完要跑驗證」這類句子，多半是當年為了補舊模型的習慣而寫的，值得拿同一組任務跑兩版，看有沒有差。

禁令清單能縮成幾句？

多半能。官方指南的「Strong instruction following」說，指令遵循的能力已經好到可以用一小段話帶動多數行為，不必逐項點名。它舉的例子是簡潔度：不用列出「不要列一堆用不到的選項、不要長篇解釋根因、不要寫結構繁複的 PR 描述」，一段「先講結果」的指令效果相同。

官方給的原句是：

"Lead with the outcome. Your first sentence after finishing should answer 'what happened' or 'what did you find'."

後面接著說，要讓輸出變短，就挑選內容，丟掉不會改變讀者下一步的細節，同時保留完整句子，避免片段、縮寫、箭頭鏈或行話。檢查點也一樣，一句「只有在破壞性操作、真正的範圍變更、只有使用者能提供的輸入這三種情況才停下來問」就夠，不用把每種情況列出來。

上圖就是官方給的兩段短指令：一段管輸出的寫法，一段管什麼時候停下來問。兩段加起來，取代的是一長串逐項禁令。

為什麼要交代這件事是做給誰的？

因為模型拿到理由，才能把任務接到相關的資訊上，不用自己猜意圖。官方指南寫的是：Fable 5 在提示說明請求背後的目的時，表現往往更好，長時間、牽涉多條工作線的 agent 尤其明顯。它給的模板是「我在為 [誰] 做 [大任務]，他們需要 [輸出能讓他們做什麼]，在這個前提下：[請求]」。

Thariq 在 2026 年 7 月 3 日發表的長文〈A Field Guide to Fable: Finding Your Unknowns〉也指向同一件事。他說，指令太具體，Claude 會在該轉向時仍照做；太空泛，Claude 會用業界慣例去補，那未必適合你的任務。他建議的做法是告訴 Claude 你的起點：想到哪一步、對這個問題和程式碼庫有多熟，讓它當思考夥伴。

長任務的 effort 和驗證怎麼設？

官方指南建議 effort 從 high 起步；驗證交給不含原工作對話的 verifier，官方指南和 Lance Martin 都這樣建議。兩者在第五、第六列。

effort 該設在哪一級？

官方的建議是預設用 high，最吃能力的任務用 xhigh，例行工作用 medium 或 low。指南還說，Fable 5 的低檔位表現仍然不差，常常超過舊模型 xhigh 的成績。檔位高了也有代價：例行工作上，它可能收集和思考得比任務需要的更多，官方給了一段「不要加功能、不要順手重構、不要為不可能發生的情況加錯誤處理」的提示來壓住。

Alex Albert 的版本略有不同：預設用 xhigh 或 high，需要快速互動時用 medium。官方把 xhigh 留給最吃能力的工作，Alex 把它和 high 並列當預設，兩邊的說法沒有完全對齊。

三方對檔位的說法如下：

工程上的意思：effort 是 API 請求裡的參數，可以依 agent 的角色分開設，例如規劃用高、跑例行檢查用低。本站建議在自己的任務集上各跑一次，再決定預設值。

誰來驗證長任務的結果？

交給另一個不含原工作對話的驗證者。官方指南寫：獨立、全新 context 的 verifier subagent（由主 agent 派出的子 agent），表現往往勝過同一個模型自我批評。Anthropic 的 Lance Martin 在 2026 年 6 月 9 日的文章〈Designing loops with Fable 5〉裡給了一個實驗：他讓 Fable 5 在 Parameter Golf（一個開源的機器學習工程挑戰，在 10 分鐘內用 8 張 H100 訓練出能放進 16MB 的最佳模型）上最多跑 8 小時，附一份列有九條可檢查條件的評分表（rubric），由負責評分的子 agent（grader subagent）逐條確認，全部達成才准停。他寫的結果是，Fable 5 改進訓練流程的幅度約 6 倍於 Opus 4.7（原文 "~6x more"）。這是他自己的單一玩具實驗，沒有第三方驗證。

進度回報也要有證據。官方指南的原話是：

"Before reporting progress, audit each claim against a tool result from this session."

指南說，在 Anthropic 的測試中，這段提示幾乎消除了捏造的狀態回報，連專門設計來誘發這種行為的任務也一樣。記憶也列在這一節：官方建議一個教訓一個檔案，檔案開頭一行摘要。Lance Martin 另用 Continual Learning Bench 的一項任務（依序回答 SQL 資料庫的問題，每題是獨立的 agent 工作階段）測記憶：Fable 5 最強的幾次執行，把筆記驗證成事實的覆蓋率最高到 73%（30 題中的 22 題），Opus 4.7 是 7–33%。

工程上的意思：負責分派工作的主 agent（orchestrator）啟動驗證者時，只給它規格和這次的程式碼差異（diff），不給工作過程的對話，讓它獨立檢查結果。

開工前後，各要處理什麼？

開工前要找出自己沒說出口的需求，開工後要避開「叫它交出推理」的指令。這兩件事在第七、第八列。

開工前，怎麼找出自己沒說的事？

用 Thariq 的四種未知來分。他在文章裡把問題拆成四類：已知的已知是你寫進提示的；已知的未知是你知道還沒想清楚的；未知的已知是太理所當然而不會寫下，但看到就認得的；未知的未知是你根本沒想到的。他說 Fable 是第一個讓他覺得工作品質的瓶頸在於自己釐清未知能力的模型。

他的做法，都是在讓這些未知提早浮出來，依時間分三段。

開工前有五招：

• blindspot pass：直接請 Claude 找出你沒想到的問題。
• 原型與腦力激盪：處理「看到才知道要不要」的標準。
• 訪談：請它一次問一個問題，優先問答案會改變架構的。
• 參考：指著現成的原始碼當參考，連不同語言都可以。
• 實作計畫：把最可能被你改的決定放在最前面。

實作中，請它維護一份 implementation-notes 檔，記下偏離計畫的決定。實作後，他請 Claude 產出變更報告並附測驗，自己全部答對才合併。

本站的建議：這些都是 Thariq 個人的工作流程，官方指南沒有寫。在任務夠大、你對程式碼庫不熟的時候，先做一次 blindspot pass 的成本很低。

想看它的推理過程，該用什麼？

要看推理摘要，讀 adaptive thinking 的 thinking 區塊；要在長任務中途把訊息原樣交給使用者，另設 send_to_user 工具。官方指南寫：prompt、skill 或 harness（控制 agent 執行流程的程式）若要求模型重述、照抄或解釋內部推理，可能觸發 Fable 5 的 reasoning_extraction 拒答類別。send_to_user 要在系統提示裡寫明什麼時候呼叫，官方說只定義工具、沒有提示，Fable 5 很少會呼叫它。要求簡短的解釋或動作摘要仍然可以。

官方還有一句對工程影響很大。Fable 5 的安全分類器拒絕的請求，可以設定 fallback 自動轉給 Claude Opus 4.8；但伺服器端 fallback 設成 "default" 時，不會重試被 reasoning_extraction 拒絕的請求，那個拒答會直接回到你手上。

工程上的意思：升級前，搜尋你所有的 skill 和系統提示，找「把你的思考過程寫出來」「先反思再回答」這類句子。

五方說法一致在哪，不同在哪，還有什麼別的解釋？

五方共同的方向，是把提示重心從「怎麼做」移到「做到什麼、為什麼、怎麼驗收」；明確不同的是 effort 的預設建議，刪指令與驗證的說法則各補充了不同做法，另有一個來源立場的問題要先交代。

一致的部分：官方與 Alex Albert 都主張把步驟換成一般性指令與目標；官方與 Thariq 都建議交代背景；官方與 Lance Martin 都說獨立的驗證者勝過自評。

兩處不同，列成表：

第二列的兩種驗證對象不同，不互斥。刪指令這件事上，Boris Cherny 的除錯例子補充了官方的說法：他舉的習慣沒寫在提示裡，模型自己就會做，支持「舊指令可以先刪」的方向。

替代解釋有兩個。第一，五個聲音全部出自 Anthropic：官方文件之外，Thariq、Boris Cherny、Alex Albert、Lance Martin 的 X 個人檔案都掛在 Anthropic 底下，指南提到的測試也是 Anthropic 自己做的，我查到的來源裡沒有第三方的對照實驗。第二，「少寫步驟」可能只在任務夠難時成立：官方自己說，用比較簡單的工作負載測試，往往低估這個模型；簡單任務該不該也刪掉步驟，文件未說明。

Fable 5.1 之後，八個要點哪些要重測？

要重測的主要是 effort 檔位，另外要刪兩類舊指令，其餘多數維持不變。Anthropic 的 Fable 5.1 指南說，Fable 5 的現有 prompt 在 Fable 5.1 上應該不用改也能表現良好，只有幾處行為差異。Fable 5.1 在 2026 年 9 月 1 日上線（Anthropic 的模型文件在「Released」欄標注這個日期），晚於 Fable 5 的 6 月 9 日，也晚於 Thariq 的文章。下表是八個要點在 Fable 5.1 官方文件裡的狀態。

第二列要多刪的兩類句子，出自 5.1 指南：Fable 5.1 在長工具鏈中寫給使用者看的進度更新比 Fable 5 少，過去的「把所有發現留到最後一次回報」這類句子要先移除；它也比舊模型少用粗體、標題和清單，為舊模型寫的「不要用格式」規則可能壓掉內容需要的結構。

第五列要重測，原因是 5.1 指南明說：就算你已在 Fable 5 上逐檔測過，升級後仍要重測，因為相同的檔位名稱在不同模型上，對應的思考量不一樣。5.1 指南列出的檔位是 low、medium、high、xhigh、max，預設仍是 high；官方說 medium 的結果大致和 Fable 5 相當、成本較低。5.1 還新增中途切換 effort 的 beta 功能，可以在難的步驟調高、例行步驟調低。

What's new in Claude Fable 5.1 列了四項 breaking change（既有程式碼會出錯或行為改變的變更），都不在八個要點內。5.1 不支援強制工具呼叫，tool_choice 設成 any 或指定工具會回 400 錯誤。修改 thinking 區塊之前的任何內容（系統提示、工具、先前的訊息）會讓之後的區塊失效，這項檢查對 2026 年 8 月 31 日起建立的新帳號強制執行。第三，Fable 5.1 的 thinking 區塊只有 Fable 5.1 與 Mythos 5.1 讀得懂，對話中途換成其他模型，那些回合的推理會被丟掉。第四，使用 advisor tool（讓較強的模型當顧問的 beta 工具）時，advisor 必須至少和 executor（執行任務的模型）一樣強；用 Fable 5、Opus 5.5 等當 advisor、搭配 Fable 5.1 executor，會回 400 錯誤。價格方面，輸入每百萬 token 10 美元、輸出 50 美元，和 Fable 5 相同，只有快取讀取降到每百萬 token 0.25 美元，是 Fable 5 的四分之一；官方指出，長時間的 agent 工作會反覆讀取同一段快取，受益最明顯。

先量，再刪

我的做法是挑一個最常使用的 skill，留一份舊版，另一份刪到只剩目標、驗證和邊界，用同一組可重跑的任務各跑一次再比；沒有這組任務就先別刪。

指令先量過才刪而驗收條件不動。

常見問題

Fable 5 的 effort 預設該設多少？

Anthropic 官方指南建議預設用 high，最吃能力的工作用 xhigh，例行工作用 medium 或 low。Alex Albert 則把 xhigh 與 high 並列為預設，需要快速互動時用 medium。兩邊略有差異，實際值要用自己的任務集量。Fable 5.1 的指南提醒，相同檔位名稱在不同模型上對應的思考量不一樣；即使已在 Fable 5 上測過，升級後仍要逐檔重測。

從 Fable 5 換到 Fable 5.1，prompt 要重寫嗎？

Fable 5.1 指南說，現有的 Fable 5 prompt 應該不用改也能表現良好。要檢查的是幾處行為差異：長任務中的進度回報變少、標題與清單用得更少、effort 檔位要重測。程式端要檢查官方列的四項 breaking change：強制工具呼叫會回 400 錯誤；修改 thinking 區塊之前的系統提示、工具或訊息，會讓之後的區塊失效，這項檢查對 2026 年 8 月 31 日起建立的新帳號強制執行；Fable 5.1 的 thinking 區塊只有 Fable 5.1 與 Mythos 5.1 讀得懂，中途換模型會丟掉推理；advisor tool 的 advisor 必須至少和 executor 一樣強，否則回 400。

為什麼請求回傳 refusal，而且沒有自動改走 Opus 4.8？

如果請求因要求輸出內部推理而被歸為 reasoning_extraction 拒答，官方說，伺服器端的備援設定（fallback，自動改走其他模型）即使設成 "default"，也不會重試這類請求，拒答會直接回給你。可先檢查 skill 或系統提示是否要求把推理寫進回應。改成讀 thinking 摘要區塊，或只要求簡短解釋與動作摘要。

Fable 5.1 比 Fable 5 貴嗎？

輸入每百萬 token 10 美元、輸出 50 美元，兩者相同。差別在快取讀取：Fable 5.1 是每百萬 token 0.25 美元，是 Fable 5 的四分之一，長時間的 agent 工作反覆讀取同一段快取，受益最明顯。

延伸閱讀

• 為什麼 AI 越聊越笨、一直犯同樣的錯？Anthropic 揭密 Context Engineering 實戰（2026 懶人包）
• AGENTS.md 怎麼寫？規則寫越多，Agent 反而越貴？（2026 完整教學＋範例）
• Loop Engineering 是什麼？怎麼讓 AI 自己把事情做完再叫你？（2026 實戰教學）

參考資料

• Anthropic, Prompting Claude Fable 5, Claude Platform Docs。查證日 2026-10-23。 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5
• Anthropic, Prompting best practices, Claude Platform Docs。查證日 2026-10-23。 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• Anthropic, Prompting Claude Fable 5.1, Claude Platform Docs。查證日 2026-10-23。 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1
• Anthropic, What's new in Claude Fable 5.1, Claude Platform Docs。查證日 2026-10-23。 https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1
• Anthropic, Introducing Claude Fable 5.1 and Claude Mythos 5.1（頁面標示 2026 年 9 月）。 https://www.anthropic.com/claude-fable-and-mythos-5-1
• Anthropic, Claude Fable 5.1（模型概覽，Released：2026 年 9 月 1 日）, Claude Platform Docs。查證日 2026-10-23。 https://platform.claude.com/docs/en/models/fable-5-1/overview
• Anthropic, Claude Fable 5 and Claude Mythos 5，2026-06-09。 https://www.anthropic.com/news/claude-fable-5-mythos-5
• Boris Cherny（X 帳號 @bcherny，Anthropic）, Fable 5 貼文，2026-06-09（UTC）。 https://x.com/bcherny/status/2064431111154053187
• Alex Albert（X 帳號 @alexalbert__，個人檔案列為 Anthropic 研究員）, 給 Fable 新用戶的四個建議，2026-06-09（UTC）。 https://x.com/alexalbert__/status/2064467657483829441
• Thariq（X 帳號 @trq212，個人檔案列為 Anthropic Claude Code 團隊）, A Field Guide to Fable: Finding Your Unknowns，2026-07-03（UTC）。 https://x.com/trq212/status/2073100352921215386
• Lance Martin（X 帳號 @RLanceMartin，個人檔案列為 Anthropic 技術團隊成員）, Designing loops with Fable 5，2026-06-09（UTC）。 https://x.com/RLanceMartin/status/2064397389189071163