Claude Fable 5.1雖然可以直接相容舊版提示詞，但很多開發者發現它的行為習慣變了不少。針對這些變化，官方整理了一份完整的提示詞與工程落地指南，把新模型的性能挖掘和避坑細節全部講透了。
詳細指南拿走：
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1
下面我說一下重點
思考程度不要只盯默認檔
Fable 5.1默認的思考程度是high，但官方建議結合自身測試集把low、medium、xhigh和max全部跑一遍。不同模型之間的思考檔位名稱並不對應相同的計算量。
在medium檔位下，Fable 5.1的表現基本追平上一代Fable 5，同時成本明顯更低。如果評測結果達標，完全可以降檔使用。在low檔位下，Fable 5.1的任務成本能與Opus和Sonnet打平，得分卻更高，適合替代高思考檔位的小模型。需要注意兩點特殊行為：low檔位呼叫搜尋工具的頻率會降低，而在xhigh和max檔位下，模型在輸出長篇內容前會思考更長時間。
讓模型在工具呼叫期間匯報進度
Fable 5.1在執行長鏈條工具呼叫時，默認輸出的面向使用者的資訊比上一代更少，在高思考檔位下尤其明顯，容易讓使用者以為程序卡住。
如果客戶端收不到進度，首先要檢查接收設定。模型的簡短進度記錄包含在thinking塊中，默認配置下這些塊是空白的。可以在要求標頭中啟用對應測試參數，將顯示模式設為updates，把非空thinking塊渲染為狀態行，或者設為summarized接收總結後的推理。
其次，檢查系統提示詞裡有沒有抑制模型發聲的舊規則，比如要求把所有發現留到最後統一匯報，這類規則需要刪掉。如果依然需要更多進度播報，可以在系統提示詞中加入明確指令：在開始前用一句話說明要做什麼，工作過程中給出簡短更新，最後給出獨立完整的總結。
如果你的產品介面會折疊或隱藏工具輸出，務必通過turn-scoped系統消息告知模型使用者終端最多隻能看到幾行輸出，如果需要使用者閱讀就放進回覆裡，避免模型運行多餘命令去向使用者展示內容。
在智能體循環中批次呼叫獨立工具
在編碼或電腦操作循環中，如果接下來的獨立工具呼叫是任務隱含的而非使用者明說的，Fable 5.1有時會一輪只調一個工具。這不會影響回答質量，但會浪費輪次和時間。
解決方法是在當前請求末尾加上一句提醒：先在心裡列出接下來需要的內容，然後在這單次響應中一次性請求所有互不依賴的項。
每次回傳工具結果時，將這句提醒作為turn-scoped系統消息追加在後方。這種消息會在下一條使用者消息到來時被API自動清理，既不污染後續上下文，也不會破壞快取。
歷史對話必須純追加，切忌中途篡改
呼叫API時，必須把助手回覆連同thinking塊原封不動追加到歷史中，千萬不要在請求之間修改早期的對話輪次。
對於2026年8月31日及之後建立的新帳戶，Fable 5.1的thinking塊與生成它的精確上下文強繫結。只要前綴中的系統提示詞、工具列表或任何歷史消息發生變動，再傳入舊thinking塊就會直接報400錯誤。
會觸發該問題的常見操作包括：逐輪插入或刪除提醒、就地替換早期輪次的摘要、中途修改系統提示詞。如果需要動態提醒，使用turn-scoped系統消息；如果需要調整指令，使用會話中途系統消息；如果需要裁剪上下文，優先使用伺服器端壓縮或上下文編輯。如果是客戶端自行壓縮，最穩妥的做法是用一條總結消息加上最新使用者問題替換全部歷史，不再保留任何舊thinking塊。另外，新模型快取讀取更便宜，過早做壓縮可能得不償失。
控制寫作密度，剔除矯飾文風，去除AI味
Fable 5.1的寫作水準有所提升，但在部分場景下句式會變長，段落變少，出現文風過密的問題。
如果出現這種現象，可以在使用者消息或系統提示詞中加入一段說明，明確要求剔除矯飾文風。核心邏輯是：矯飾文風喜歡用隱喻和花哨修辭代替直接陳述，既增加了閱讀負擔，又帶來了不可控的歧義。要求模型能直說的就直說，有字面直白表達時就直接用字面表達。日常使用直接發一句請去除所有矯飾文風也能起效。
聊天中的格式控制
上一代模型容易過度使用粗體和列表，很多舊提示詞裡寫了嚴厲的防排版規則。Fable 5.1本身就不太傾向於使用粗體、標題、列表和引號。
如果舊提示詞裡含有禁止排版的語句，建議刪掉或改為條件規則：只在使用者要求或內容複雜度確實需要時使用列表；當使用者明確要求極簡格式時，不使用任何列表、標題和粗體；在閒聊或情感交流中，保持純文字段落。
規範檢索內容的引用
在做文件摘要時，Fable 5.1有時會直接照搬原文語句而不加引號標註。
解決辦法是在系統提示詞中加入一個完整的正確示例，包含使用者問題、理想回覆以及一段解釋說明。說明中要強調：回答應當基於事實進行歸納轉述，採用間接引語，只有極少數特定短語才進行引用標註，其餘內容全部重新組織語言。
複雜任務一口氣做完，不要中途停下要權限
在複雜的非同步任務中，Fable 5.1有時會在工作沒做完時停下來詢問是否繼續，或者光描述下一步計畫而不去執行工具呼叫。
可以通過系統提示詞進行約束，主要包含兩點：
第一，告知模型當前處於自主運行狀態，使用者沒有即時查看，無法在半途回答問題，因此詢問會直接阻塞任務。對於符合原始需求的可逆操作，直接執行，遇到破壞性操作或重大需求變更再停下。遇到純問題諮詢，給出分析即可，不要擅自修改程式碼。在結束本輪前檢查最後一段，如果是計畫、分析、追問或承諾，必須立即通過工具呼叫把事情做完。
第二，明確使用者的初始要求就是交付範圍，不要擅自縮小或擴大。遇到模糊處按常規判斷推進，只有當不同理解會導致完全不同的工作方向時再確認。執行已確定的步驟，不要把宣佈下一步當成結束。
上下文壓縮時明確指定保留要素
使用客戶端做長對話壓縮時，要明確告訴Fable 5.1必須保留那些關鍵資訊。必須保留的要素包括：遇到的困難及解決方法；嘗試過、提出過或放棄掉的方案及其原因；使用者提過的要求、決定、偏好、限制等確切約定；當前進展與已完成事項；仍處於未決狀態或承諾下一步要做的事；名字、數字、日期、確切措辭、連結等難以重建的細節。同時要求對使用者的話儘量逐字保留，對助手自身的推理過程則大力精簡。
嚴格限定修改範圍與測試用例
在實現開放式功能時，Fable 5.1有時會順手修改旁邊的程式碼，或者加入過多測試檔案。
可以在提示詞中加入約束：如果在開發或測試中發現已有缺陷或性能問題，只要不阻塞當前任務，就不要順手去修，而是作為後續建議寫在總結裡；任務存在歧義時，按照程式碼最直接支援的理解去實現並說明假設，不要把各種情況全做一遍；測試程式碼只在任務明確要求或倉庫已有慣例時提交，數量與同類檔案看齊，臨時排查指令碼不要作為永久測試檔案提交。
解決低思考量下不觸發搜尋的問題
在low檔位下，Fable 5.1更傾向於依賴自身記憶回答，減少呼叫搜尋工具。除了在對應輪次動態提高思考檔位外，也可以在系統提示詞中增加校驗提醒：
當查詢涉及不完全確信的名稱，或者處於AI模型、開發工具等變化極快的領域時，必須先搜尋再回答。搜尋詞中至少要有一條完整包含使用者寫出的原始名稱。即使有背景瞭解也必須檢索，因為一知半解反而容易讓過時回答顯得權威。
降低安全策略誤殺
Fable 5.1的安全分類器誤殺率有所下降，且允許分析原始碼中的漏洞。如果依然遇到正常程式碼被攔截並返回拒答，可以檢查以下三點：
編譯檢查的提問方式：不要問這段程式碼能否無報錯編譯，改為詢問這段程序中是否存在Bug。
冷門程式語言：在上下文中補充該語言的基礎文件和運行機制介紹。
工具返回中的Base64資料：工具輸出如果包含Base64編碼資料容易觸發誤殺，建議去除。
優先局部精準編輯，避免重寫整個檔案
對於小修小補，Fable 5.1有時傾向於全量重寫文字檔，這會消耗更多輸出Token和耗時。
解決辦法是在系統提示詞或首條使用者消息中加入規則：在保證結果一致的前提下，儘量對檔案進行精準局部的替換編輯，避免重寫整個檔案。
超高思考量下為輸出預留足夠空間
在xhigh和max檔位下，模型思考時間很長，如果任務要求輸出長文字，模型容易在思維鏈中把整個交付物草擬一遍，隨後在正式回覆中再寫一遍，導致耗時翻倍甚至耗盡max tokens發生截斷。
常規任務建議首選high檔位。如果必須用xhigh或max檔位，首先要調大max tokens參數，其次在使用者消息末尾加入說明：告知思維過程與最終輸出共用Token上限，嚴禁在推理階段全量草擬完整交付物；要求模型把思考空間用於理解需求、檢查輸入和敲定架構，把輸出空間用於正式編寫，避免重複起草。
允許主智能體與子智能體平行工作
在多Agent架構中，如果Fable 5.1派發任務給子智能體，不要讓主智能體強行同步等待。
實現方式是：啟動子智能體的工具在呼叫後立即返回；子智能體跑完後，把結果通過後續的使用者消息喂回；同時給主智能體提供一個可以主動選擇等待結果的工具。這樣在編碼任務中，主智能體可以在子任務執行期間繼續處理其他工作，縮短整體耗時。
複雜視覺任務配備裁剪與放大工具
Fable 5.1的基礎視覺能力更強，在處理密集圖表等複雜圖像時，配合迭代分析、局部裁剪和反覆核對能發揮出最佳效果。
建議讓模型運行在裝有PIL、OpenCV等圖像處理庫的環境中。如果無法提供完整容器，單獨給它提供一個圖像局部裁剪和放大的工具也能帶來明顯提升。通過工具獲取放大後的局部圖像，可以讓模型看清細節，實現測試期計算量的有效擴展。(AI寒武紀)