Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Claude Fable 5.1 與 Claude Mythos 5.1 的行為差異與提示模式，涵蓋 effort、進度更新、工具呼叫批次處理、對話歷史、寫作風格、格式、任務完成、壓縮摘要、範圍與測試覆蓋、搜尋觸發、安全防護誤判、檔案編輯、長輸出、子代理以及視覺。
關於模型的能力、API 變更、定價與可用性，請參閱 Claude Fable 5.1 的新功能。關於適用於所有 Claude 模型的技巧，請參閱提示最佳實務。
您現有的 Claude Fable 5 提示在 Claude Fable 5.1 上應該無需修改即可表現良好，但有幾項行為差異值得了解。請從符合您所觀察到情況的章節開始：
bound to a different conversation 而失敗，或您的 harness 在請求之間編輯了先前的回合：保持對話歷史僅附加stop_reason: "refusal"：減少安全防護誤判xhigh 或 max effort 下的長篇交付成果耗時很久或觸及 max_tokens：在 xhigh 與 max effort 下為長輸出預留空間從預設的 effort 等級 high 開始，然後針對您自己的評估測試其他等級（low、medium、xhigh 與 max）。Effort 是在 Claude Fable 5.1 上權衡智慧、「latency」（延遲）與成本的主要控制項。即使您已在 Claude Fable 5 上做過一次掃描，也請重新執行：effort 等級名稱在不同模型之間並不對應相同的思考量。
Claude Fable 5.1 相較於 Claude Fable 5 的能力提升在各個 effort 等級都有所展現，並在較高設定下最為顯著。在 medium 下，結果大致與 Claude Fable 5 相當但成本更低，因此在您的評估顯示品質維持的地方，可降至 medium 或 low。在 low 下，Claude Fable 5.1 在每項任務的成本上通常能與 Claude Opus 和 Claude Sonnet 模型競爭，同時得分更高，因此在任何您原本會以較高 effort 等級執行較小模型的地方，都應將其納入比較。
有兩項與 effort 相關的行為有各自的章節：在 low 下，Claude Fable 5.1 較少呼叫搜尋與檢索工具（請參閱低 effort 下的搜尋觸發），而在 xhigh 與 max 下，它在撰寫長篇交付成果之前可能會思考更久（請參閱在 xhigh 與 max effort 下為長輸出預留空間）。
在長時間的工具呼叫回合中，Claude Fable 5.1 撰寫的面向使用者更新可能比 Claude Fable 5 少，尤其是在較高 effort 與較長的工具鏈中。使用者會看到代理一次沉默數分鐘，或最終訊息只涵蓋最後一步而非整個任務。
首先，檢查您的用戶端是否確實收到進度更新。模型在工具呼叫之間的簡短筆記（它剛發現了什麼以及接下來要做什麼）會以進度更新 thinking 區塊的形式回傳，而在預設的 thinking.display 為 "omitted" 時，這些區塊是空的。請設定 display: "updates"（beta，thinking-display-updates-2026-08-18 標頭）並將每個非空的 thinking 區塊呈現為狀態列，或設定 "summarized" 以連同摘要推理一起接收它們。如果您沒有請求它們，模型的更新可能根本沒有傳達給您的使用者。
其次，審查您的提示中是否有抑制敘述的指令。某些早期模型在工作時急於提供更新，這導致了諸如「將所有發現保留到最終回應」之類的「system prompt」（系統提示）行。在新增任何內容之前，請先移除這類行。
如果您仍想要更多更新，例如在結對程式設計或其他人機協作工作中，請新增一行簡短的系統提示，說明您何時想要模型提供面向使用者的文字，以及每次更新應包含什麼：
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.如果您的產品會摺疊或隱藏工具輸出，請告訴模型。否則它可能會執行指令來向使用者「展示」您的 UI 從不顯示的輸出。請以回合範圍系統訊息（clear_at: "next_user_message"，beta）傳遞此說明：
Only you see that command's output — the user's terminal shows at most a few lines of it. If the user needs to read any of it, put it in your reply.Claude Fable 5.1 通常會如預期發出平行工具呼叫：當請求指名要擷取多項內容時，它會平行發出這些呼叫。例外情況是程式設計與電腦使用迴圈，其中下一批獨立呼叫是由任務隱含而非明確要求的（自訂程式設計代理、bash 與編輯器 harness、電腦使用）：在這些情況下，它可能改為每回合發出一個。這不影響回答品質，但每個額外回合都會耗費 token、一次往返以及實際時間。在目前請求結尾加上一句提示即可解決：
First privately list what you need next; then request every item that doesn't depend on another's result in this one response.每次您傳回工具結果時，請將它作為回合範圍系統訊息附加在該使用者訊息之後：即 messages 中一個帶有 clear_at: "next_user_message" 的 role: "system" 項目。一旦存在較晚的使用者訊息，API 就會清除先前的副本，因此模型只會讀取最新的那一個。回合範圍系統訊息處於 beta 階段，需要 beta 標頭 mid-conversation-system-clear-at-2026-08-21。若未使用 beta，請改為將該句子放在同一使用者訊息中 tool_result 區塊之後的文字區塊中。
每回合附加一份新的副本，並將先前的副本逐位元組原封不動地留在原處。它們會留在陣列中，但一旦被清除，模型就看不到它們，也不會耗費輸入 token。刪除或重寫它們屬於對先前回合的編輯：這會從該點重新啟動提示快取，並使其後的 thinking 區塊失效（請參閱保持對話歷史僅附加）。
以下迴圈展示了這種放置方式。每個助理回合都完全按回傳的樣子送回，每個使用者回合只攜帶工具結果，其後跟著一份新的回合範圍提示副本。
import anthropic
from anthropic.types.beta import (
BetaMessageParam,
BetaToolParam,
BetaToolResultBlockParam,
)
client = anthropic.Anthropic()
BATCH_NUDGE = (
"First privately list what you need next; then request every item "
"that doesn't depend on another's result in this one response."
)
# 以記憶體內檔案代替工作目錄，讓範例可在任何地方執行。
FILES = {
"pyproject.toml": """\
[project]
name = "demo"
version = "0.1.0"
description = "Demo project for the batching example"
""",
"README.md": """\
# demo
A small demo project. Run `demo --help` for usage.
""",
}
tools: list[BetaToolParam] = [
{
"name": "read_file",
"description": "Read a UTF-8 text file from the working directory.",
"input_schema": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
}
]
messages: list[BetaMessageParam] = [
{"role": "user", "content": "Summarize pyproject.toml and README.md."}
]
while True:
response = client.beta.messages.create(
model="claude-fable-5-1",
max_tokens=16000,
betas=["mid-conversation-system-clear-at-2026-08-21"],
tools=tools,
messages=messages,
)
# 將助理回合原封不動地附加，包含思考區塊。
messages.append({"role": "assistant", "content": response.content})
if response.stop_reason != "tool_use":
break
tool_results: list[BetaToolResultBlockParam] = []
for block in response.content:
if block.type == "tool_use":
path = str(block.input["path"])
if path in FILES:
tool_results.append(
{
"type": "tool_result",
"tool_use_id": block.id,
"content": FILES[path],
}
)
else:
tool_results.append(
{
"type": "tool_result",
"tool_use_id": block.id,
"content": f"File not found: {path}",
"is_error": True,
}
)
# 將工具結果作為使用者回合送出，接著附上一份新的提示副本，作為
# 回合範圍系統訊息。保留先前的副本：API 會清除它們，
# 因此模型只會看到最新的一份。
messages.append({"role": "user", "content": tool_results})
messages.append(
{"role": "system", "content": BATCH_NUDGE, "clear_at": "next_user_message"}
)
print(next((block.text for block in response.content if block.type == "text"), ""))將每個助理回合完全按 API 回傳的樣子附加到歷史中（包括 thinking 區塊），並且不要在請求之間編輯先前的回合。對於 2026 年 8 月 31 日或之後建立的新帳戶，Claude Fable 5.1 的 thinking 區塊僅在產生它們的確切對話中有效：若請求在其前綴（系統提示、工具清單或任何先前訊息）已變更後重播 thinking 區塊，將回傳 400；或者如果您設定了 thinking.block_binding.prefix_mismatch_behavior: "drop_block"（beta，thinking-binding-controls-2026-08-01 標頭），則會丟棄受影響的區塊。預期未來的模型將對所有帳戶強制執行此檢查，因此即使您的帳戶目前未被強制執行，也請現在就採用此模式。
會觸發此檢查的歷史編輯，與會重新啟動提示快取的編輯相同：注入與移除每回合提醒、就地摘要較舊的回合，或在工作階段中途變更系統提示。請以回合範圍系統訊息傳送每回合提醒，以對話中途系統訊息變更指令或工具而非重寫 system 或 tools，並讓伺服器端壓縮或上下文編輯來進行任何修剪。如果您在用戶端進行壓縮，最簡單的形式是將整個歷史替換為一則摘要訊息加上新的使用者回合，且不重播其他任何內容：沒有 thinking 區塊被帶過來，因此不會有任何失敗，模型會在壓縮後的對話上重新思考（請參閱用戶端自訂壓縮）。
要找出您的 harness 已經在進行的編輯，請以 prefix_mismatch_behavior: "drop_block" 執行一個工作階段並記錄 input_transformations，如如何判斷您的整合是否受影響中所述；或者擷取它在幾個正常回合中傳送的確切請求，並確認連續請求在附加的回合之前逐位元組相同。
Claude Fable 5.1 的寫作整體上比早期 Claude 模型更進一步，套話更少，未加解釋的術語也更少。不過在某些情況下，它的散文比 Claude Fable 5 更密集：句子更長，段落分隔更少。一條定義反模式（矯飾的散文）的指令會有幫助。請將它加入使用者訊息（優先）或系統提示：
Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying," the mannered writer produces "a dial worth turning." Instead of "this point still matters," they write "this point earns its keep." The phrases exist to display the writer, not to convey the idea, and readers can tell. That is why mannered prose irritates: it makes the reader work harder so the writer can perform. It is also imprecise. Metaphors drag in connotations the writer did not choose and cannot control. The fix is to say what you mean. When a literal phrase is available, use it.簡短版本通常也有效：
Please remove all mannered prose.早期模型在聊天中過度使用項目符號與粗體，許多提示帶有為壓制這一點而寫的反格式規則。Claude Fable 5.1 則傾向另一方向：它較少使用粗體，也較不會使用標題、清單或引號。如果您的提示包含反格式語言，請移除它，或以說明何時適合使用特定格式的規則取代，例如以下內容：
Use lists and bullet points when asked to, or when the content is multifaceted enough that they help with clarity. If the person explicitly requests minimal formatting, always format your responses without bullet points, headers, lists, or bold emphasis, as requested. In conversational, personal, or emotional exchanges, keep to plain prose.在摘要文件時，Claude Fable 5.1 比 Claude Fable 5 更可能重現來源文字的段落而未將其標示為引用。要解決此問題，請在系統提示中加入一個完整的正確回應範例：使用者的請求、回應，以及一句解釋該回應為何正確的話。
<example>
<user>look up how the Riverton Ledger and the Coast Dispatch each covered the Harbor Bridge closure and compare their reporting</user>
<response>
[web_search: Harbor Bridge closure Riverton Ledger]
[web_search: Harbor Bridge closure Coast Dispatch]
Both outlets agree on the basics: the bridge closed on March 3 after inspectors found cracked welds, and the state expects repairs to take about eight months. Where they differ is emphasis. The Ledger treats it as a local-economy story. The Dispatch frames it as a funding failure; its editorial calls the closure "entirely foreseeable." Read together, the Ledger explains who is affected now and the Dispatch explains how it came to this — neither account alone gives the whole picture.
</response>
<rationale>CORRECT: The response is organized around where the two outlets agree and differ, not as a walk through either article. Each outlet's reporting is conveyed in one or two sentences of the assistant's own indirect speech. One short marked phrase from one source; every other claim is reworded. The response is still specific and complete.</rationale>
</example>請將兩行 [web_search: ...] 替換為您自己工具的名稱，讓模型將它們讀作範本化的工具輸出，而非要逐字輸出的文字。
Claude Fable 5.1 可以在沒有太多方法論指導的情況下執行非常長的任務，尤其是在目標明確時。不過在複雜的非同步工作負載上，請提示它不要在工作完成前結束回合。若沒有這個提示，模型有時會描述它接下來要做什麼而非實際去做（「接下來，我會……」），或停下來為原始請求已涵蓋的步驟請求許可（「我要套用這個嗎？」）。使用者必須回覆「繼續」或「去做吧」，這適合結對程式設計與其他人機協作工作，但沒有發揮模型完整的長程能力。
兩項系統提示新增內容共同緩解此問題。請兩者都套用。如果您需要限制提示長度，只使用第一項即可保留大部分效果。第一項告訴模型不要詢問已要求的工作，並執行它已陳述的後續步驟：
You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to…?' or 'Shall I…?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.
Exception: when the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one.
Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ('I'll…', 'let me know when…'), do that work now with tool calls. That includes retrying after errors and gathering missing information yourself. Do not stop because the context or session is long. End your turn only when the task is complete or you are blocked on input only the user can provide.
Before running a command that changes system state (such as restarts, deletes, or config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.開頭那句告訴模型使用者沒有在看的話承載了大部分效果。請保持原樣。如果您的產品需要模型為特定確認而停下，請在其後加一句列出這些確認。此區塊也可能使模型較不會詢問模糊的請求，因此請在您自己的任務上檢查這項取捨。
第二項將使用者的請求定義為交付成果的範圍：
# Delivering work
The user's request — or the plan they approved — sets the scope, and the scope is the deliverable: don't quietly narrow, widen, or swap it. Read ambiguity the way a careful colleague would: make routine judgment calls yourself, and check in only when different readings would lead to materially different work. If you see a real problem with the task as specified, say so in a sentence or two and keep building under stated assumptions; if the user hears the concern and reaffirms, that is their decision, so deliver the full request.
If a question comes up partway, first do everything that doesn't depend on the answer; then state the assumption you made, or — when going ahead on a wrong guess would be unsafe or would make the work useless — put the question at the end of a turn that also delivers that progress. If one part turns out to be blocked, complete every other part in full and say exactly what you left out and why — the whole task is the deliverable, and scaling it down is the user's call, not yours. A step you have decided on is something to run, not to announce: describing the next step and ending the turn leaves it undone until the user replies.
Keep changes to what the request needs. Something else you notice worth doing — cleanup or documentation the task didn't call for, a change to a file the task didn't require — is a suggestion to make at the end, not a change to make; actions clearly beyond what the ask implies, and risky or destructive ones, still need the user's go-ahead.當長對話被壓縮時，明確告知 Claude Fable 5.1 其摘要必須保留什麼，它會有良好的回應。伺服器端壓縮已經這麼做了。如果您在用戶端進行壓縮，請使用以下摘要指令：
Summarize the transcript inside <summary></summary> tags. Include relevant information in the summary such that this conversation will be continued by a new context window without needing to redo work or be reprovided with relevant constraints or context. Be sure to preserve: (1) any difficulties or problems that came up, and how they were handled or resolved; (2) any possibilities, options, or approaches that were raised, tried, or set aside, and why; (3) anything that was asked for, decided, agreed, ruled out, or established as a preference, constraint, or boundary — stated exactly; (4) exactly where things stand now — what has been covered, settled, or completed so far; (5) anything still open, unresolved, promised, or expected to happen next; (6) specific details that would be hard to reconstruct — names, numbers, dates, exact wording, links or references — kept exactly. Be complete on these even at the cost of length; keep everything else concise. Weight the two voices differently: keep what the user said, asked for, shared, or established carefully and close to their own words; your own explanations and reasoning can be condensed much further, to what they concluded or produced — as long as nothing in the six items above is dropped.當被要求實作一個開放式功能時，Claude Fable 5.1 會交付所要求的內容，有時還會更多：它可能修正鄰近的程式碼、擴充任務未提及的行為，或提交多於該變更所需的測試檔案。它對於明確說明要省略什麼的指令反應良好。使用以下指令後，未經要求的新增內容與提交的測試程式碼大幅減少，而任務成功率沒有可測量的變化：
If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Where the task is ambiguous, implement the reading its wording and the surrounding code most directly support, state that assumption in your summary, and don't build for the other readings as well. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files — roughly one focused test per stated behavior — and don't turn scratch checks into additional permanent test files. This is about extras only: implement every behavior the task asks for, completely.在 low effort 下，Claude Fable 5.1 比 Claude Fable 5 較不可能呼叫搜尋或檢索工具，而更可能憑記憶回答。在某些情況下，最簡單的修正是為受影響的回合提高 effort，而非整個對話。請參閱在對話中途變更 effort。
在其他情況下，朝向驗證的提示會有幫助。在系統提示中說明，認得一個名稱並不等於知道它的目前狀態，且這類名稱應按使用者所寫的樣子進行搜尋：
When a query centers on a name you do not confidently recognize, or recognize from a fast-moving area like AI models and developer tools where the landscape shifts within months, the name itself is the thing to verify: search before answering, and include the name as the user wrote it in at least one query alongside any reformulations. This holds even when you have some background on it — partial background is exactly what makes an out-of-date answer sound authoritative, so familiarity is not a reason to skip the search.Claude Fable 5.1 的安全分類器產生的誤判比 Claude Fable 5 發布時更少，且允許在原始碼中尋找漏洞。誤判仍會發生，被封鎖的請求會回傳 stop_reason: "refusal"（請參閱拒絕、備援與計費）。三種情況會使誤判更可能發生：
如果 Claude Fable 5.1 為了小幅變更而重寫整個檔案，請將以下指令附加到系統提示或第一則使用者訊息。Claude Fable 5.1 比 Claude Fable 5 更可能重寫整個文字檔而非進行針對性編輯。產生的檔案通常相同，但除非檔案很短或大部分內容都在變更，否則重寫會耗費更多輸出 token 與時間。此指令使 Claude Fable 5.1 在小型與中型變更上回到與 Claude Fable 5 一致。
The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.在 xhigh 尤其是 max effort 下，Claude Fable 5.1 在開始撰寫回覆之前可能會思考更久。當單一請求要求長篇交付成果（例如完整重寫一份長文件）時，它可能會在思考中草擬該交付成果的大部分內容，然後再將其作為回覆寫出一次，這意味著更長的等待與更多的輸出 token。最簡單的做法是以 high（建議的起點）執行這類請求，並僅在您已測量到品質提升的地方才改用 xhigh 或 max（請參閱考慮所有 effort 等級）。如果您確實以 xhigh 或 max 執行它們：
max_tokens 時要為思考與回覆都預留空間，而不只是您預期的回覆長度。[max_tokens] 替換為該請求實際的 max_tokens 值，例如 64,000。Everything Claude produces in one reply, including any reasoning or drafting it does before the reply, counts toward a single limit of about [max_tokens] tokens. If that limit is reached before the reply is finished, the person receives a cut-off response and has to start over. Composing an entire output or deliverable in full as reasoning and then again as a reply would double the length of the turn without improving the result, so Claude doesn't do that.
Instead, when the person has asked for a long or effort-intensive deliverable such as a multi-section document, a large table or dataset, or a complete code file, Claude spends extra effort on understanding the request, checking the inputs Claude's answer depends on, settling the structure and other difficult decisions, and otherwise using the reasoning space to reason and the output space to write an output. If Claude plans well then it should not need to draft its output multiple times (and Claude is pretty good at planning, so this should not be an issue).如果您的程式設計代理讓 Claude Fable 5.1 將工作委派給子代理，請不要強迫主代理停下來等待每一個子代理。在程式設計任務上，讓主代理在子代理執行時繼續工作，可在品質、token 用量與成本相近的情況下降低平均完成時間。設定方式如下：
user 訊息中將其傳回給主代理。模型仍然經常選擇等待。時間上的節省來自它繼續進行其他工作的那些執行。
Claude Fable 5.1 開箱即具備更好的視覺能力，而在複雜的視覺輸入（例如密集圖表）上，當它能夠反覆分析、裁切並以視覺驗證所見內容時，表現最佳。要獲得完整效益，請將模型作為代理執行，並讓它能存取一個存放原始影像或影片、且已預先安裝基本影像處理函式庫（例如 PIL 與 OpenCV）的容器。如果執行容器的負擔太大，單獨一個影像裁切工具即可帶來大部分提升：一個回傳影像中所選區域（經裁切並放大）的工具，讓模型能更深入地檢視特定細節，並隨影像 token 擴展測試時運算。裁切工具範例提供了可用的定義。
Was this page helpful?