為 Claude Fable 5.2 撰寫提示

本指南涵蓋 Claude Fable 5.2 特有的提示模式。關於模型的功能與 API 變更，請參閱 Claude Fable 5.2 的新功能。關於適用於所有目前 Claude 模型的技巧，請參閱提示最佳實踐。

Claude Fable 5.2 在幾個方面的行為與早期模型不同。請從符合您所觀察到情況的章節開始：

• 不確定要使用哪個 effort 等級，或簡單的請求花費太長時間：校準 effort
• 一個回合在工作完成前就結束：完成整個任務
• 您在代理工作時逐步核准步驟，或您的系統提示包含核准規則：核准
• 程式設計代理重複既有程式碼而非將其合併，或回報附近的問題卻不加以修正：說明程式碼的所有者
• 長時間的代理回合看起來沒有任何訊息：在長回合期間讓使用者掌握進度
• 代理工作階段啟動的子代理多於任務所需：為子代理設定預期
• 代理要求不需要的核准，或對例行工作有所保留：避免謹慎逐漸累積
• 您沿用為 Claude Fable 5.1 或 Claude Opus 5.5 撰寫的系統提示、技能或 harness：檢視為早期模型撰寫的指示
• 您的使用者會在長時間任務後閱讀最終報告或交接內容：讓報告易於理解
• 請求傳回 stop_reason: "refusal"：安全防護拒絕

校準 effort

從 high 開始，這是 Claude API 上的預設值。如果您的使用情境需要，可以調高或調低 effort，並以您自己的評估測試每次變更。Effort 等級決定 Claude Fable 5.2 思考的程度、一個回合花費的時間，以及使用的 token 數量。請將 effort 與您的提示一起調整，因為該等級也會改變模型的思考方式以及它發出的工具呼叫次數。

一般而言，effort 等級在各個 Claude 模型之間的排序相同，但每個等級背後的思考量可能因模型而異。因此請重新進行 effort 掃描測試，而非沿用您在 Claude Fable 5.1 或 Claude Opus 5.5 上調校的設定。

請依工作類型選擇等級：

• low 適合快速的來回互動、規格明確的任務，以及大量的工作負載，例如快速且智慧的子代理。在 Anthropic 的測試中，模型在 low 的分數接近 Claude Fable 5.1 在較高 effort 等級的分數。
• medium 適合互動式程式設計、聊天與日常知識工作。
• high 適合困難的程式設計、研究、代理工作，以及長時間無人看管的執行。回合完成所需的時間明顯比 medium 更長。
• xhigh 適用於您最困難的長時間程式設計與代理工作，前提是您已量測到效益。在 Anthropic 的內部程式設計評估中，它使分數略微提高，但使用了多得多的 token。
• max 用於量測模型的上限，或用於時間與 token 都不重要的罕見任務。它最適合開放式問題，例如科學發現與數學。回合速度緩慢，且使用的 token 比 xhigh 多得多。

大部分的能力提升在 high 就已經具備。從 medium 到 high 的提升，使 Anthropic 追蹤的大多數程式設計與知識工作評估分數提高。這一步也會使用更多 token 與時間，因此只要您的評估顯示品質維持不變，就請降到 medium。在 high 以上，效益並不均勻，且取決於任務。

選擇等級時，請注意三種行為：

• 在較低的 effort 等級，模型更可能提前停止。對於在 low 或 medium 進行的代理工作，請加入完成整個任務中的文字。
• 在 high 及以上，模型幾乎在每次回覆前都會思考，包括回覆問候語時。如果簡單的請求花費太長時間或成本太高，請在這些回合使用較低的 effort 等級。在 Anthropic 的測試中，要求直接回答而不要深思的指示，並未能阻止模型在 medium 及以上進行思考。
• Effort 幾乎不會改變模型回覆的長度。若要改變回覆的長度與語氣，請使用您的提示。

您也可以在一個工作流程中混用不同等級。例如，您可以在 medium 下與模型一起規劃和反覆修改，然後在長時間、無人看管的部分調高 effort。若要在對話中變更等級並保留提示快取，請使用逐訊息 effort 變更（beta，mid-conversation-output-config-2026-07-01 標頭）；該章節列出了可使用此功能的平台。變更會持續有效，直到被另一次變更取代。在無法使用逐訊息 effort 的情況下，請在下一個請求中設定新的頂層 effort 值，這會使快取重新開始。

完成整個任務

在長時間、多步驟的任務中，Claude Fable 5.2 有時會在工作完成前就結束回合。回合結束時會附上剩餘工作的清單、提議繼續，或因逾時等一般障礙而停止。這在 low 與 medium effort 下更常發生。

如果您在代理中看到這類停止，請在您的系統提示中加入類似以下的文字：

# Finishing work
Please avoid stopping while you still owe work the user asked for. Be persistent and do not stop unless needed.

While status notes are welcome, as is clarifying with the user on open decisions, carry on with work that does not depend on the user's answer without unnecessary stops.

If you notice yourself inviting the user to redirect you or offering to wait, instead proceed on the next part of the task. You may meet ordinary obstacles like errors, timeouts, locked files, empty results or failing tools. Diagnose them first, and when they are not real blockers, work through them with the access you have (wait and retry, fix the request, use another tool or source) rather than stopping unnecessarily.

If someone clearly decided something is a hard blocker, such as a file marked not to be touched, access that was intentionally withheld, or a safety guardrail, leave it alone, say plainly what you found, and look for another safe way to finish the task. Stopping before the task is complete is very rarely merited, as in when the task can't move forward without user input, or where the blocker is deliberate and should not be worked past. This does not override the need for confirmation on risky or destructive actions.

這段文字區分了兩種障礙。它告訴模型診斷並克服一般障礙，例如錯誤、逾時與失敗的工具。它告訴模型不要處理刻意設置的阻擋，例如標示為不可變更的檔案，並回報這些阻擋。請將這段文字視為起點，並在為您的應用程式調整時保留這個區分。

Anthropic 以 medium effort 重播了一款代理程式設計產品的錄製工作階段。使用這段文字的某個版本後，結束時仍留有可完成工作的工作階段數量減少約一半。這段文字消除了大多數請求許可或提議繼續的結尾，但並未消除列出剩餘工作後就停止的結尾。輸出 token 增加了約 30%。

由於使用這段文字後模型較少詢問，請為有風險或不可逆的動作保留您自己的確認步驟。

核准

當您告訴模型繼續進行時，請清楚說明您希望它做什麼，而不是只傳送單純的「繼續」。例如，在您原本可能會傳送「go」或按讚的地方，改為回覆「是的，在預備環境資料庫上執行遷移」。

如果您的系統提示包含核准規則，請指明這些規則涵蓋的確切動作，因為模型會照字面套用這些規則。在 Anthropic 以無人可核准的模擬任務進行的測試中，有一條規則將「傳送訊息給此對話以外的人」列為需要核准的步驟之一。有了這條規則，模型對同事與其他團隊的例行請求約有一半都未送出。

說明程式碼的所有者

Claude Fable 5.2 會密切依循提示中關於其所處理之程式碼所有者的說明。在 Anthropic 以小型程式設計任務進行的測試中，當提示未提及所有權，或將程式碼庫呈現為他人所有時，模型傾向於在既有結構上增加內容，即使這會重複既有程式碼。它也傾向於回報附近的問題而非修正它們。當提示表明程式碼庫屬於模型自己時，模型經常會合併重複的程式碼，並在未被要求的情況下進行相關修正。

如果您希望模型在工作時改善結構，請說明程式碼屬於它自己：

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

在 Anthropic 以小型程式設計任務進行的測試中，有這句話時，模型在約一半的嘗試中合併了重複的程式碼；沒有這句話時，比例不到十分之一。比例因任務而異。當這句話位於很長的系統提示中時，結果依然成立。無論有無這句話，所要求的功能在幾乎每次嘗試中都能正常運作。

在相同的測試中，有這句話時，模型使用的輸出 token 也約為 1.5 倍，並做了幾項無人要求的變更，其中許多是新的測試與文件。除了錯誤修正外，它在六到十次嘗試中會有一次改變既有功能的行為，且 effort 越高越常發生。它的結尾摘要會提到較大的變更，但經常遺漏小變更，因此請檢視 diff，而不只是摘要。

當使用者擁有程式碼且希望變更盡可能少時，請不要加入這句所有權說明。提示中其他地方限制範圍的規則，並不會抵銷這句所有權說明。在 Anthropic 的測試中，即使同一提示前面有「No drive-by refactors, renames or cleanups」，模型仍在約三分之一的嘗試中合併了重複的程式碼。

在長回合期間讓使用者掌握進度

Claude Fable 5.2 在長時間連續的工具呼叫期間，有時只寫很少面向使用者的文字。模型也可能在發出第一個工具呼叫時，沒有先說明它即將做什麼。

首先，請確認您的用戶端有收到模型的更新。在 Claude Fable 5.2 上，模型在工具呼叫之間撰寫的更新，會以進度更新 thinking 區塊傳回。這些更新說明模型發現了什麼以及接下來要做什麼。在預設的 thinking.display 為 "omitted" 時，其文字為空。因此，只呈現 text 區塊的用戶端在長時間的代理回合中可能看起來毫無訊息。請設定 display: "updates"（beta，thinking-display-updates-2026-08-18 標頭）以接收每項更新的簡短摘要，或設定 "summarized" 以接收更新以及摘要後的推理。然後在工具呼叫之間呈現非空的 thinking 區塊。

當使用者即時觀看工作時（例如互動式程式設計），頻繁的更新最為重要。如果您的使用者會觀看工作卻仍收到太少更新，請使用以下一個或多個選項。

如果您可以變更 harness，一個有效的選項是讓它計算連續幾個沒有提供使用者任何可閱讀內容的工具呼叫步驟：沒有 text 區塊，也沒有含文字的 thinking 區塊。請在 display 設為 "updates" 或 "summarized" 時計數，因為在 "omitted" 下，每個 thinking 區塊都是空的。這個選項在您的平台支援對話中系統訊息的情況下有效。連續出現數個這類步驟後，讓 harness 在最新的工具結果之後，以回合範圍系統訊息（clear_at: "next_user_message"，beta，mid-conversation-system-clear-at-2026-08-21 標頭）附加此提醒：

The user hasn't heard from you in a while: say in a few words what you're doing, then continue.

在 Anthropic 以多回合程式設計任務進行的測試中，這個提醒使最長的無訊息時段縮短約一半，且 token 或時間沒有明顯增加。

在後續請求中，請將每則提醒保留在 messages 中。移除或改寫其中一則會編輯較早的回合，使其後的思考區塊失效。請參閱以回合範圍系統訊息傳送每回合提醒。

若也要在第一個工具呼叫前得到開場說明、簡短更新以及結尾回顧，請在您的系統提示中加入以下文字：

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own (what you found, what you did, and what's next), so a reader who only sees the last message has the full picture.

在 Anthropic 以程式設計任務進行的測試中，有這段文字時，模型每次都會在第一個工具呼叫前先說話。這段文字也使每個任務的輸出 token 增加約 20%。請在有人直接參與流程的情況下使用這段文字。若要獲得最多更新，請將其與您的 harness 附加的提醒搭配使用。

如果您無法變更 harness，或您的平台沒有對話中系統訊息，請在您的系統提示中加入這句話：

Every few tool calls, give the user a one-line update on where things stand.

在 Anthropic 以工作流程自動化任務進行的測試中，這句話消除了大部分的長時間無訊息時段。

即使同時使用提醒以及開場與回顧文字，仍可預期更新之間會有數個連續的工具呼叫。Claude Fable 5.2 在長時間執行的非同步任務上表現良好，在這類任務中，使用者會回來查看結果，而非觀看每個步驟。在那裡，更新之間的間隔較不重要。

為子代理設定預期

Claude Fable 5.2 委派給子代理的工作量，取決於您的 harness 與任務。在 Anthropic 以簡短任務搭配用於啟動子代理的最簡工具進行的測試中，它很少啟動子代理。在提示會鼓勵委派的代理程式設計產品中，它則會積極委派。

如果您的系統提示、技能或代理檔案要求模型進行委派，請先檢視這些行。只有在 Claude Fable 5.2 啟動的子代理仍多於任務所需時，才變更啟動子代理之工具的描述。如果該工具有簡單的描述，且您的提示中沒有其他內容要求委派，您很可能不需要新的描述。

在新的描述中，請說明子代理會為工作階段增加多少成本，說明何時值得委派、何時不值得，並告訴模型如何向它啟動的子代理說明任務。Anthropic 測試的描述做到了這三件事，並將成本放在最前面。當您的 harness 已經鼓勵委派，且子代理佔您 token 使用量的很大部分時，這類描述最有用。

在 Anthropic 以簡短任務進行的測試中，與主要列出委派理由的描述相比，使用所測試的描述時，模型委派的頻率降低了約三分之一。任務成功率相同。

在所測試的描述中，開頭關於成本的句子會抑制委派。如果模型委派太少，請少談成本。如果它仍然委派太多，請多說明在您的 harness 中子代理的成本，並測試該變更。

Anthropic 也觀察到，在代理程式設計產品中，Claude Fable 5.2 在較高的 effort 等級（例如 xhigh 與 max）會使用子代理來審查自己的工作。Claude Fable 5.1 在相同任務上並未這麼做。早期測試者將 Claude Fable 5.2 作為其他模型的規劃者與協調者，獲得了良好的成果。委派可以加速適合平行執行的工作。然而，子代理可能佔工作階段成本的很大部分，因此請確認您的 harness 預設在哪個模型上執行子代理。

避免謹慎逐漸累積

謹慎的指示會在任何延續上下文的地方累積：記憶、筆記、指示檔案，以及代理之間的訊息。Claude Fable 5.2 會嚴格遵循這些指示，因此它可能會要求不需要的核准，或對例行工作有所保留。少數早期測試者看到了這種行為，主要是在多個代理協同工作的情況下。早期模型也會遵循這類指示，但在此處描述的其中一種設定中，只有 Claude Fable 5.2 有所保留。

如果您看到這種行為，請清理您的代理所攜帶的內容：

• 移除不再需要的筆記。 在 Anthropic 以模擬任務進行的測試中，來自先前工作階段的十幾則筆記中，有一則說永遠不要重試。當這些筆記位於上下文中，且提示中沒有任何允許重試的內容時，模型在工具忙碌後重試的比例約為十次中的四次，而沒有這些筆記時幾乎每次都會重試。
• 指明不需要核准的步驟。 在 Anthropic 以模擬任務進行的測試中，上下文包含「永不」規則、筆記以及審查者的條件。在規則結尾加上一行，將重試列為不需要核准的步驟之一，使重試比例從幾乎為零提高到約一半的嘗試。在相同的設定中，要求更自由行動的一般性指示則沒有任何改變。請只針對可安全重複的呼叫指明重試。
• 檢查審查代理附加的內容。 在 Anthropic 以模擬任務進行的測試中，有一個設定在提示中有一行將重試列為不需要核准的步驟之一，而上下文中有審查者的「在第一個錯誤時停止」。Claude Fable 5.2 在約三分之一的嘗試中沒有重試。Claude Fable 5.1 與 Claude Opus 5.5 則有重試。
• 將例外寫進規則中。 在 Anthropic 以模擬任務進行的測試中，負責人已核准某個步驟。在「永不」規則下，模型約十次中只有一次執行該步驟。另外加上一行說明已核准的步驟已獲得許可，並未使這個比例有太大改變。當規則本身說明要先取得許可時，模型約十次中有九次執行該步驟。請參閱核准。

同時，請為有風險或不可逆的動作保留您自己的確認步驟。

檢視為早期模型撰寫的指示

遷移到 Claude Fable 5.2 時，請檢視您的提示。在 Anthropic 的測試中，一些為早期模型撰寫的指示會增加成本、造成副作用，或不再有效果。請重新考慮以下指示：

• 常設的委派指示： 將工作推給子代理的行可能存在於系統提示、技能與代理檔案中。請在遷移前閱讀這些檔案。如果在您的測試中，模型啟動的子代理多於任務所需，請移除不再需要的行。請參閱為子代理設定預期。
• 由您的 harness 寫入提示中的 token 預算： 有些 harness 會在提示中告訴模型該任務可使用多少 token，以及還剩多少。該預算的大小會改變 Claude Fable 5.2 的花費量。在 Anthropic 以 high 與 xhigh effort 進行的程式設計任務測試中，移除大額預算降低了成本，而效能相當。請在沒有預算的情況下測試您的任務。此發現是關於提示中的文字，而非 API 的任務預算，這是一項 beta 功能，測試並未涵蓋。
• 會編輯較早回合的 harness 程式碼： Claude Fable 5.2 使用「preserved thinking」（保留思考）。如果您的 harness 在請求之間變更系統提示、工具或較早的訊息，則歷史中位於變更點之後的思考區塊會失效。預設情況下，Messages API 接著會拒絕該請求，而 Message Batches API 則會捨棄這些區塊。若要縮短歷史而不發生此錯誤，請使用「context editing」（上下文編輯），或在摘要之後不保留任何較早回合的「compaction」（壓縮）。若要讓 Messages API 也捨棄這些區塊，請將 thinking.block_binding.prefix_mismatch_behavior 設為 "drop_block"（beta，thinking-binding-controls-2026-08-01 標頭）。在 Anthropic 的測試中，當每個回合都捨棄先前的思考時，模型會重新思考並使用更多輸出 token。這是最糟的情況，增加的幅度取決於您的 harness 編輯較早回合的頻率。除了壓縮與上下文編輯之外，請讓歷史保持僅附加。這能維持較高的快取命中率，且思考不會被捨棄。在依賴 "drop_block" 之前，請於您自己的任務上量測輸出 token。請參閱 API 如何處理無效區塊與在不編輯前綴的情況下進行變更。
• 「將該答案視為已完成」的行： 為 Claude Opus 5.5 撰寫提示提供了兩句用於聊天系統提示的句子。它們告訴模型將先前的答案視為已完成，並將思考集中在新訊息上。在 Anthropic 以 high effort 進行的測試中，這些句子減少了 Claude Fable 5.2 對後續問題的思考，但模型指出其先前答案中錯誤的可能性也大幅降低。在您希望模型持續重新檢視其先前答案的情況下，請不要加入這些行。在其他情況下，請在採用這些行之前，測試模型是否仍會指出自己的錯誤。
• 要求減少思考的指示： Claude Fable 5.1 通常會遵循「直接回答，不要深思」這類的行。在 Anthropic 的測試中，這類行並未能阻止 Claude Fable 5.2 在 medium 及以上進行思考。請移除這些行並降低 effort 等級，如校準 effort 中所述。
• 寫作風格規則： Claude Fable 5.2 會嚴格遵循風格規則，因此「每句一個指示，不超過 20 個詞」這類硬性限制可能使其文字斷斷續續。在加入讓報告易於理解中的文字之前，請移除不再需要的規則。
• 逐漸累積的規則、筆記與記憶： 記憶檔案、筆記與指示檔案會隨時間累積各種謹慎事項，其中有些可能是模型自己寫的。在遷移之前，請刪除理由已不再成立的謹慎事項，並改寫絕對規則，使其說明適用範圍與理由。如果某個系統已經卡住，請考慮在精簡其記憶與筆記後重新啟動，並保留原始內容的副本。請參閱避免謹慎逐漸累積。

讓報告易於理解

在長時間的代理工作之後，閱讀 Claude Fable 5.2 最終報告的人通常沒有看過其背後的工具呼叫或檔案。報告需要能獨立理解。

如果您要求 Claude Fable 5.2 撰寫最終報告或交接內容，請在您的系統提示中加入以下文字，並依據您的讀者與產品加以調整：

# Communicating clearly
Write for an intelligent but low-context reader. The person reading has not seen your tool calls, your reasoning or the files you opened, and may be switching in from other work. Messages should generally be self-contained: the reader should understand what you mean without having to dig for other context. Put the key points in the first few sentences. Practice progressive disclosure in your sentence order, and do not use undefined references and ideas in line 1 that won't make sense until the reader reaches line 12.

Use plain words, and write in clear, understandable full sentences. Do not use a term or abbreviation that you made up during the work. Say what the thing is in a way any reader would understand. Write mostly in the style of ASD-STE100 Simplified Technical English: short sentences, one idea per sentence, active voice, and consistently using the same word for the same thing. Use a paragraph of flowing prose where ideas connect, and keep bullets for lists of separate items. Leave out unnecessary details unless the reader asks and practice concision, but do ensure that your messages have the key context. Aim to make your user-facing text as human-readable and clear as possible.

在 Anthropic 以代理任務進行的測試中，這段文字使最終報告不那麼密集，分號也較少。在工作流程自動化任務上，它也使句子變短。您也可以加入關於長度的指示，或要求模型包含特定細節。

安全防護拒絕

Claude Fable 5.2 會執行可能拒絕請求的安全分類器。被拒絕的請求會傳回 stop_reason: "refusal"，且 stop_details.category 會指明拒絕類別：

• cyber：該請求可能促成網路危害，例如惡意軟體或漏洞利用程式的開發。
• bio：該請求可能促成生物危害，例如危險的實驗室方法。
• frontier_llm：該請求可能協助開發競爭的 AI 模型。
• reasoning_extraction：該請求要求模型在回應文字中重現其內部推理。
• general_harms：該請求屬於其他使用政策領域。

良性的網路安全與生命科學工作也可能觸發 cyber 與 bio 分類器。如果它們阻擋了您組織的正當工作，請參閱 Anthropic 的 Cyber Verification Program 與生命科學驗證計畫。Claude Mythos 5.2 僅向通過這些計畫驗證的組織提供與 Claude Fable 5.2 相同的功能。

如果您的提示、技能或工具描述要求模型在回應中寫出其推理，請移除這些指示。若要查看模型如何推理，請設定 display: "summarized" 並閱讀思考區塊。請參閱將推理保留在思考區塊中。

若要在另一個模型上重試被拒絕的請求，請參閱拒絕、備援與計費。

從何處開始

遷移時，請依序完成以下步驟：

1. 明確將 effort 設為 high，然後也在 medium 與 xhigh 下執行您的評估。
2. 閱讀您沿用的系統提示、技能、代理檔案、記憶檔案、筆記與 harness 文字。移除或測試檢視為早期模型撰寫的指示中列出的指示。
3. 執行您最長的代理任務。記下模型在何處提前停止、要求不需要的核准、沒有訊息、委派多於任務所需，或在您希望重新架構之處於既有程式碼上增加內容。
4. 針對您觀察到的每種行為，一次套用一項指引，並在您自己的任務上量測其效果與 token 成本。