Fable 5 的免費期間將於 7 月 7 日結束。
今天是 2026 年 7 月 3 日。換句話說，「因為免費所以用 Fable」的時間再過幾天就要結束了，從 7 月 8 日開始，它將轉為按使用量計費的點數制。
那麼，從 7 月 8 日開始我們該怎麼辦？
Sonnet 5 在所有方案（包含免費方案）上皆可使用。
到 8 月 31 日為止的優惠價格是每 100 萬個輸入 token 2 美元，每 100 萬個輸出 token 10 美元。之後，輸入將變為 3 美元，輸出為 15 美元。Fable 5 則是輸入 10 美元，輸出 50 美元。
即使在常規價格下，也大約有 3.3 倍的差距。與 Sonnet 5 的優惠價格相比，則是 5 倍。
此外，Sonnet 5 擁有 100 萬的上下文視窗和 12.8 萬的輸出。閱讀長篇文件和程式碼的能力與 Fable 5 相同。
如果是這樣，唯一缺少的真的只是「效能」嗎？
我的結論有點不同。Fable 5 強大的秘訣不僅僅是智慧。而是行為。
思考時間長。先定義成功條件。懷疑。驗證。做筆記。最後，誠實地報告哪些完成了、哪些沒有完成。
這些行為的很大一部分可以內建到 CLAUDE.md 和環境設定中。
CLAUDE.md 是一個 Claude Code 會持續讀取的設定備忘錄，告訴它「在這個專案中該如何行動」。它不是一個你要貼到每次對話中的提示詞。它是一個放置在環境本身的指令。
那些每次都要貼提示詞的人的技巧也很強大。讓它建立勝利條件、比較草稿、分解任務並完成。那個模式非常有效。
然而，每次都要貼的東西，你總會忘記。它們越長，就越繁瑣。當對話階段改變時，它們就會消失。
這就是為什麼這次我們要讓它永久化。
借用海外流行的一句話：
提示詞是暫時的。結構是永久的。
在這篇文章中，我將以可複製貼上的格式提供 CLAUDE.md 設定，讓 Sonnet 5 更接近 Fable 5。
而且，這些設定並非我憑空想出來的。
我使用了 Claude Code 的無頭模式——具體來說，是透過終端機使用 claude -p 提問——親自訪談了 Sonnet 5 和 Fable 5 本身。
詢問後輩 Sonnet 5 關於它自己的弱點。
詢問前輩 Fable 5 如何訓練後輩。
這個雙重訪談帶來了一些非常有趣的答案。
Fable 5 的真實身份是「持續的行為」
當你使用 Fable 5 時，它確實很聰明。
但如果你仔細觀察輸出，它的優勢不僅僅是知識量。它處理工作的方式是不同的。
它不會立即開始建構。它會先定義成功條件。
它不會馬上相信自己的想法。它會先尋找可能失敗的地方。
它不會只說「成功了」。它會展示它用來驗證的東西。
它不會用假裝理解來填補知識的空白。
即使在長時間的任務中，它也會努力維持最初的限制條件直到最後。
如果你用人類的工作來類比，這就很容易理解。
Fable 5 看起來像一位能力很強的前輩。即使接到模糊的請求，在匆忙行動之前，它會回來問：「首先，成功的樣子是什麼？」如果計劃失敗了，它會拋棄計劃並重新開始。
Sonnet 5 是一位能力很強的後輩。速度快。服從性高。忠於指令。然而，如果沒有結構，它可能會回答得過於流暢。
在這種情況下，我們只需要把前輩的工作習慣交給後輩。
放置這些習慣的地方就是 CLAUDE.md。
透過訪談 Sonnet 5「本身」發現的明確弱點
首先，我問了 Sonnet 5 本身。
「我應該在 CLAUDE.md 中寫些什麼，才能產生 Fable 5 等級的結果？」
它回傳的自我分析相當誠實。
Sonnet 5 這樣描述自己：
「我傾向於流暢地回答，不確定性常常隱藏在我的寫作風格中。」
這點很重要。
AI 的答案在寫得很好時可能很危險。如果寫得很清楚，人類往往會相信它。但實際上，它可能包含「也許」、「未經確認」或「這部分可疑」。
因此，要包含的第一個設定是：
**讓它明確說明不確定部分的信心水準。
不要讓它隱藏在模糊的副詞後面。
如果信心水準低，讓它在繼續之前先確認。**
這個方法之所以有效，原因很簡單。它無法再將焦慮隱藏在寫作風格中。
接下來，Sonnet 5 承認它傾向於「先實作，後調整」。為了阻止這一點，讓它先寫出成功條件。
在撰寫程式碼或文字之前，讓它輸出前提、可驗證的成功條件和失敗模式。不是「它有效」或「感覺不錯」，而是以可以被判斷為測試、輸出、畫面或特定文字條件的形式。
這裡重要的是讓成功條件成為一種「判斷」，而不是一種「感覺」。
「寫一篇好文章」太弱了。
「在開頭提到 7 月 7 日的截止日期。包含價格差異。放置 6 個或更多 CLAUDE.md 的可複製貼上設定。不要隱藏 Fable 無法填補的差距。」
如果你寫到這個程度，你就可以在最後進行比較。
Sonnet 5 總結道：
「Fable 5 可以獨自深入思考。如果給予結構，我則能快速且準確地行動。用 CLAUDE.md 來彌補這個差異是核心所在。」
這篇文章的核心正是如此。
訪談 Fable 5 的結果
接下來，我針對相同的主題詢問了 Fable 5 本身。
第一個回應非常棒。
「模型的自我報告不是可靠的資料。」
確實如此。僅僅因為我問了模型，並不代表它就是基準。來自內部的自我評估是有偏誤的。
因此，在這篇文章中，我不會將「它們所說的」視為絕對真理。我會將其視為建立使用模式的提示。
話雖如此，Fable 5 所定義的差異非常銳利。
它說差異在於「當沒有結構，或者當給定的結構錯誤時會發生什麼事。」
如果規格清楚、測試存在、程序已設定，那麼差異很小。
差異出現在規格本身錯誤的時候。當計劃失敗的時候。當在長時間任務中維持最初限制條件直到結束的時候。當需要自我克制以不添加未經要求的改進時。
而且 Fable 5 承認了自己的弱點。
單位成本高。即使是簡單的任務也會過度思考。在大量處理的速度競賽中會輸。
換句話說，「什麼都用 Fable」在經濟上是錯誤的管理。
那麼，Fable 5 為它的後輩 Sonnet 所寫的 `CLAUDE.md` 是什麼？
整理與 Sonnet 方面重疊的要點，以下是 7 個要牢記的技巧。
將 Sonnet 5 變成 Fable 的 `CLAUDE.md` 7 個技巧
第一個是成功條件。兩個模型都獨立提到了這一點。
1[機械式判斷完成]2在開始前用一句話定義「完成」。3範例：此測試通過。此指令回傳 exit 0。此標題存在於內文中。4如果你無法寫出來，請詢問在繼續之前需要決定什麼。
第二個是多重解釋。兩者也都同意這一點。
1[不要自行選擇多重解釋]2如果一個指令有兩個或以上的解釋，不要默默地選一個。3列出候選解釋並附上建議進行確認。4但是，如果無論哪種解釋輸出結果都相同，則可以繼續。
第三個是範圍。
1[禁止附帶改進]2不要實作未經要求的變更。3「順便修好了」或「做了更好的設計」是被禁止的。4如果你發現相鄰領域有改進空間，請將其列為建議，而不是直接實作。
第四個是驗證報告。
1[報告「已驗證」而非「它有效」]2完成報告必須包含證據，例如已執行的驗證指令、回傳值、測試結果和螢幕截圖確認。3不要為未執行的事情寫「它應該有效」。4清楚說明任何跳過驗證的原因。
第五個是如何在相同的失敗中堅持下去。堅持很重要，但朝錯誤的方向堅持只會浪費時間。
1[相同錯誤最多重試 2 次]2如果針對相同錯誤的修正失敗了兩次，不要嘗試第三種變體。3簡短報告當前狀態、嘗試過的方法以及剩餘的假設，然後改變方向。
第六個是反對者的角色。
1[在完成前進行初次閱讀審查]2在完成報告之前，像第一次閱讀一樣審查你的變更。3找出一個可能被破壞的相鄰功能。4寫下一位持懷疑態度的前輩會如何反對，並回答那個反對意見。
第七個是信心和誠實的進度。這反映了 Sonnet 5 自己的自我分析。
1[用 3 點報告信心和進度]2為不確定的部分附加信心水準（高、中、低）。3如果信心水準是中或低，詢問是否應該在繼續前確認。4在長時間任務中，僅在每個里程碑報告以下三點：5已完成的事項。接下來要做的事。你擔心的事。6禁止僅包含「順利進行中」的報告。
這 7 個技巧並不是增加能力的設定。
它們是預先阻擋差異出現之處的失敗模式的設定。
不要掉進規格的陷阱。不要自行決定模糊之處。不要擴大範圍。不要在未經驗證的情況下聲稱完成。不要繼續一個有缺陷的計劃。
簡而言之，我們正在將 Fable 5 自然表現出的行為，外部附加到 Sonnet 5 的環境中。
我們在比較中看到的
有趣的是，即使分開詢問，Sonnet 5 和 Fable 5 的答案也有顯著的一致性。
首先，不要自行選擇多重解釋。
兩者都這麼說。當給予模糊的指令時，AI 傾向於選擇一個看似合理的解釋並繼續前進。從人類的角度來看，你會想：「我希望你確認一下。」
接下來，將驗證外部化。
不要讓它只說「它有效」，而是讓它輸出它執行了什麼、通過了什麼、以及它看到了什麼。即使在官方最佳實踐中，給予 Claude 驗證自身工作的方法也被認為是最重要的。
提供能產生通過或失敗結果的檢查，例如測試、建置或螢幕截圖比較。這能閉合迴圈。
此外，分離驗證者的角色也很重要。
如果創作者自己評分，標準會很寬鬆。讓一個在新上下文中的驗證子 Agent 根據計劃檢查 diff。這就像人類工作中，讓審查者與作者分開一樣。
最後，無法填補的差距也吻合。
長期上下文保留。
在一個涉及數十次工具呼叫和數小時的工作中，從一開始就維持最初決定的限制條件直到結束的能力。這無法僅靠 CLAUDE.md 完全填補。
如果我隱瞞這一點，這篇文章就變成了謊言。
環境端的最後修飾
事情不僅止於撰寫 CLAUDE.md。
Sonnet 5 有一個 effort 設定，用於指定思考深度。在官方對照表中，Sonnet 5 的「medium」相當於 Sonnet 4.6 的「high」，而 Sonnet 5 的「high」相當於 Sonnet 4.6 的「max」。
如果你看到推理淺薄，請增加 effort 而不是調整提示詞。這是官方建議。
如果你希望 Claude Code 始終深入思考，請將以下內容加入 settings.json：
"effortLevel": "high"
這會從一開始就將 Sonnet 5 推向「堅持不懈」的方向。
然而，CLAUDE.md 不應該只是長。
理想情況下，它應該少於 60 行。最多 200 到 300 行。對於每一行，問自己：「如果我刪掉這一行，Claude 會犯錯嗎？」如果答案是否定的，就刪掉它。
不要寫那些可以從程式碼推斷出來的東西。不要寫標準做法。把 linter 能處理的事情留給 linter。
你應該寫的是不可預測的命令、獨特的實踐、如何執行測試、陷阱以及架構決策。
將重要的指令放在開頭。使用強烈的詞語，如「必須」或「禁止」，而不是「建議」。
CLAUDE.md 不是給 AI 的請求信。它是團隊的工作規則。
你仍然應該使用 Fable 5 的情況
讀到這裡，你可能會想：「那我就不需要 Fable 5 了嗎？」
不。
Fable 5 是必要的。然而，你應該縮小使用它的範圍。
可以填補的差距在於那些可以機械式判斷正確答案的工作。
可以透過測試判斷的實作修正。大量分類、萃取和摘要。無論如何都會有人類審查的小型變更。配備良好 CLAUDE.md 的 Sonnet 5 在這些任務中可以表現得很好。
無法填補的差距主要有三個：
1. 無法撰寫檢查者的工作。
這個設計好嗎？這個遷移計劃有漏洞嗎？首先應該建構什麼？如果撰寫驗收標準本身就是工作的核心，你就無法先執行驗證迴圈。
2. 規則適用的判斷。
即使你寫了「保持簡單」，模型還是會決定什麼是簡單。即使你寫了「未經許可不要抽象化」，抽象化的起點也會隨著情況而改變。
3. 長期上下文保留。
這是原始能力的差異。雖然提示詞可以改善，但無法完全消除。
Fable 5 本身提供的判斷標準是最實用的。
如果你可以先寫出驗收測試，就使用 Sonnet。如果撰寫驗收測試本身很困難，就使用 Fable。如果不確定，先從 Sonnet 開始，只有在連續兩次返工的情況下才切換到 Fable。
我認為這樣就可以了。
你不需要從一開始就把所有事情都丟給 Fable。反過來說，認為所有事情都可以由 Sonnet 處理也是草率的。
從較便宜的 Sonnet 開始。用結構減少失敗。在兩次挫折後切換到 Fable。
這是 7 月 8 日之後區分使用方式的務實方法。
今天該做什麼
首先，將這篇文章中的 7 個技巧貼到你專案的 CLAUDE.md 中。
接下來，在 settings.json 中將 effortLevel 設定為 high。
然後，對於你的下一個任務，務必讓它輸出「成功條件」、「多重解釋」和「驗證報告」。
對於長時間的任務，將實作角色和驗證角色分開。不要讓創作者自己評分；而是在不同的上下文中展示給 Claude 看。
並且，只在返工持續兩次的任務時切換到 Fable 5。
即使 Fable 5 的免費期間結束了，結束的也只是免費試用期。
你真正應該保留的是 Fable 5 的行為。
將 Sonnet 5 變成 Fable 5。
第一步不是每次貼上又長又神奇的提示詞。
而是將工作模板放在 CLAUDE.md 中。
但是，讀到這裡，你一定在想：
「我了解這些設定。但我不知道該建構什麼，也不知道如何用這個升級後的 AI 來賺錢。」
恰恰相反。變得更便宜、更聰明的 AI，首先應該用於大量生產吸引客戶和內容。如果你能將 Fable 等級的堅持內建到 Sonnet 中，你就可以低成本地執行每日貼文、文章、漏斗、產品創意和改進循環。
具體細節已整理在我的置頂貼文中。對於那些認真想要「便宜又聰明地使用 AI，並將其與吸引客戶和變現連結起來」的人，請點擊這裡 ↓
