提示最佳實踐
針對 Claude 最新模型的提示工程技術完整指南,涵蓋清晰度、範例、XML 結構化、思考以及代理系統。
本頁是針對目前 Claude 模型進行「prompt engineering」(提示工程)的參考文件,涵蓋的模型包括 Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 5、Claude Sonnet 4.6 以及 Claude Haiku 4.5。本頁分為三個部分:
- 首先是**特定模型指引**:說明單一模型在哪些地方行為不同,以及您應在提示中做哪些調整。
- 接著是適用於所有目前模型的技術:一般原則、輸出與格式、工具使用、思考,以及代理系統。
- 最後是遷移注意事項,適用於從較早世代模型遷移過來的提示。
特定模型指引
以下每個模型都有各自的提示頁面。請先閱讀您所使用模型的頁面,再閱讀後續的技術說明。
| 模型 | 指南 | 差異之處 |
|---|---|---|
| Claude Fable 5.1 與 Claude Mythos 5.1 | 提示 Claude Fable 5.1 | 與 Claude Fable 5 的差異:努力程度、完成長時間任務、面向使用者的進度更新、原封不動地傳回思考區塊、代理迴圈中的工具呼叫批次處理、低努力程度下的搜尋觸發、格式,以及寫作密度。 |
| Claude Fable 5 與 Claude Mythos 5 | 提示 Claude Fable 5 | 與 Claude Opus 4.8 的差異:努力程度、指令遵循、長時間執行的進度宣稱、記憶系統,以及 reasoning_extraction 拒絕類別。 |
| Claude Sonnet 5 | 提示 Claude Sonnet 5 | 與 Claude Sonnet 4.6 的差異:回應長度、努力程度與思考深度校準、工具使用觸發、字面指令遵循,以及設計與前端預設值。 |
| Claude Opus 5 | 提示 Claude Opus 5 | 與先前 Opus 模型的差異:回應長度與冗長程度、面向使用者的進度更新、書面交付成果的長度、任務範圍與過度驗證、子代理控制,以及自我修正。 |
| Claude Opus 4.8 | 提示 Claude Opus 4.8 | 回應長度、努力程度與思考深度校準、工具使用觸發、字面指令遵循、子代理控制,以及設計與前端預設值。 |
一般原則
本節及後續各節中的技術適用於目前的 Claude 模型,包括 Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5 與 Claude Mythos 5。若某項技術指名特定模型,請將其視為在該模型上測得的結果,並在套用至其他模型之前,先以您自己的評估重新驗證。
清晰且直接
Claude 對清晰、明確的指令反應良好。具體說明您期望的輸出有助於提升結果。如果您想要「超乎預期」的行為,請明確提出要求,而不是依賴模型從模糊的提示中推斷。
請將 Claude 想像成一位聰明但剛入職的新員工,對您的規範與工作流程缺乏背景了解。您越精確地說明您想要什麼,結果就越好。
**黃金法則:**將您的提示拿給一位對該任務幾乎沒有背景了解的同事看,請他們照著做。如果他們會感到困惑,Claude 也會。
- 具體說明期望的輸出格式與限制條件。
- 當步驟的順序或完整性很重要時,請使用編號清單或項目符號,以循序步驟的方式提供指令。
效果較差:
Create an analytics dashboard效果較佳:
Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation.加入上下文以提升表現
提供指令背後的上下文或動機,例如向 Claude 解釋為何某種行為很重要,有助於 Claude 更好地理解您的目標,並提供更具針對性的回應。
效果較差:
NEVER use ellipses效果較佳:
Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them.Claude 足夠聰明,能夠從解釋中進行類推。
有效運用範例
範例是引導 Claude 輸出格式、語氣與結構最可靠的方法之一。幾個精心設計的範例(稱為「few-shot」或「multishot prompting」,即少樣本或多樣本提示)能提升準確性與一致性。
加入範例時,請確保它們:
- **相關:**緊密貼合您的實際使用情境。
- **多樣:**涵蓋邊界情況,並具備足夠的變化,讓 Claude 不會學到非預期的模式。
- **結構化:**將範例包在
<example>標籤中(多個範例則包在<examples>標籤中),讓 Claude 能將它們與指令區分開來。
使用 XML 標籤結構化提示
XML 標籤有助於 Claude 毫無歧義地解析複雜的提示,尤其是當您的提示混合了指令、上下文、範例與變數輸入時。將每種類型的內容包在各自的標籤中(例如 <instructions>、<context>、<input>)可減少誤解。
最佳實踐:
- 在您的各個提示中使用一致且具描述性的標籤名稱。
- 當內容具有自然的層級結構時,請使用巢狀標籤(文件放在
<documents>內,每份文件放在<document index="n">內)。
賦予 Claude 角色
在「system prompt」(系統提示)中設定角色,可讓 Claude 的行為與語氣聚焦於您的使用情境。即使只有一句話也會產生差異:
client = anthropic.Anthropic()
message = client.messages.create(
model="claude-opus-5",
max_tokens=1024,
system="You are a helpful coding assistant specializing in Python.",
messages=[
{"role": "user", "content": "How do I sort a list of dictionaries by key?"}
],
)
print(message.content)長上下文提示
處理大型文件或資料密集的輸入(20k+ tokens)時,請仔細結構化您的提示以獲得最佳結果:
-
**將長篇資料放在頂部:**將您的長文件與輸入放在提示的頂部附近,位於您的查詢、指令與範例之上。這能提升所有模型的表現。
-
**使用 XML 標籤結構化文件內容與中繼資料:**使用多份文件時,請將每份文件包在
<document>標籤中,並使用<document_content>與<source>(以及其他中繼資料)子標籤以求清晰。<documents> <document index="1"> <source>annual_report_2023.pdf</source> <document_content> {{ANNUAL_REPORT}} </document_content> </document> <document index="2"> <source>competitor_analysis_q2.xlsx</source> <document_content> {{COMPETITOR_ANALYSIS}} </document_content> </document> </documents> Analyze the annual report and competitor analysis. Identify strategic advantages and recommend Q3 focus areas. -
**以引文作為回應依據:**對於長文件任務,請要求 Claude 在執行任務之前先引用文件中的相關部分。這有助於 Claude 聚焦於相關內容,並忽略文件的其餘部分。
You are an AI physician's assistant. Your task is to help doctors diagnose possible patient illnesses. <documents> <document index="1"> <source>patient_symptoms.txt</source> <document_content> {{PATIENT_SYMPTOMS}} </document_content> </document> <document index="2"> <source>patient_records.txt</source> <document_content> {{PATIENT_RECORDS}} </document_content> </document> <document index="3"> <source>patient01_appt_history.txt</source> <document_content> {{PATIENT01_APPOINTMENT_HISTORY}} </document_content> </document> </documents> Find quotes from the patient records and appointment history that are relevant to diagnosing the patient's reported symptoms. Place these in <quotes> tags. Then, based on these quotes, list all information that would help the doctor diagnose the patient's symptoms. Place your diagnostic information in <info> tags.
模型自我認知
如果您希望 Claude 在您的應用程式中正確識別自己,或使用特定的 API 字串:
The assistant is Claude, created by Anthropic. The current model is Claude Opus 5.對於需要指定模型字串的 LLM 驅動應用程式:
When an LLM is needed, please default to Claude Opus 5 unless the user requests
otherwise. The exact model string for Claude Opus 5 is claude-opus-5.輸出與格式
溝通風格與冗長程度
與先前的模型相比,Claude 的最新模型具有更簡潔、更自然的溝通風格:
- **更直接且有依據:**提供基於事實的進度報告,而非自我吹捧式的更新
- **更具對話感:**稍微更流暢、更口語化,較不像機器
- **較不冗長:**除非另有提示,否則可能為了效率而略過詳細摘要
這表示 Claude 可能會在工具呼叫後略過口頭摘要,直接跳到下一個動作。如果您希望更清楚地看到它的推理過程:
After completing a task that involves tool use, provide a quick summary of the work you've done.Claude Opus 5 在冗長程度上是個例外:它預設的面向使用者回應比先前模型更長,而且提高或降低 effort(努力程度)並不能可靠地改變可見回應的長度。請改為明確提示要求簡潔。範例指令請參閱提示 Claude Opus 5。Claude Fable 5.1 在代理工作期間則有相反的傾向:它在工具呼叫之間撰寫的面向使用者更新較少。請明確要求進度文字,並移除任何要求它保持該文字簡短的指令。請參閱要求面向使用者的進度更新。
控制回應格式
有幾種特別有效的方法可以引導輸出格式:
-
告訴 Claude 該做什麼,而不是不該做什麼
- 不要說:「不要在回應中使用 markdown」
- 試試:「您的回應應由流暢連貫的散文段落組成。」
-
使用 XML 格式指示符
- 試試:「將回應中的散文部分寫在 <smoothly_flowing_prose_paragraphs> 標籤中。」
-
讓您的提示風格與期望的輸出相符
您在提示中使用的格式風格可能會影響 Claude 的回應風格。如果您在輸出格式的可引導性上仍遇到問題,請嘗試讓您的提示風格盡可能貼近您期望的輸出風格。例如,從提示中移除 markdown 可以減少輸出中 markdown 的數量。
-
針對特定格式偏好使用詳細的提示
如需對 markdown 與格式的使用有更多控制,請提供明確的指引:
<avoid_excessive_markdown_and_bullet_points>
When writing reports, documents, technical explanations, analyses, or any long-form
content, write in clear, flowing prose using complete paragraphs and sentences. Use
standard paragraph breaks for organization and reserve markdown primarily for `inline
code`, code blocks (```...```), and simple headings (## and ###). Avoid using **bold**
and *italics*.
DO NOT use ordered lists (1. ...) or unordered lists (*) unless: a) you're presenting
truly discrete items where a list format is the best option, or b) the user explicitly
requests a list or ranking
Instead of listing items with bullets or numbers, incorporate them naturally into
sentences. This guidance applies especially to technical writing. Using prose instead of
excessive formatting will improve user satisfaction. NEVER output a series of overly
short bullet points.
Your goal is readable, flowing text that guides the reader naturally through ideas
rather than fragmenting information into isolated points.
</avoid_excessive_markdown_and_bullet_points>Claude Fable 5.1 的格式化程度已經比早期模型少,因此在該模型上,像這樣的區塊可能會壓抑內容所需的結構。請將其移除,或以聊天中的格式中較短的規則取代。
LaTeX 輸出
Claude 的最新模型預設使用 LaTeX 來呈現數學運算式、方程式與技術說明。如果您偏好純文字,請在提示中加入以下指令:
Format your response in plain text only. Do not use LaTeX, MathJax, or any markup
notation such as \( \), $, or \frac{}{}. Write all math expressions using standard text
characters (e.g., "/" for division, "*" for multiplication, and "^" for exponents).文件建立
Claude 的最新模型能以強大的指令遵循能力建立簡報、動畫與視覺文件,而且通常第一次嘗試就能產出可用的輸出。
如需在文件建立上獲得最佳結果:
Create a professional presentation on [topic]. Include thoughtful design elements,
visual hierarchy, and engaging animations where appropriate.從預填回應遷移
從 Claude 4.6 模型與 Claude Mythos Preview 開始,不再支援在最後一個 assistant 輪次使用預填回應(提供部分 assistant 訊息讓 Claude 接續)。對這些模型發送帶有預填 assistant 訊息的請求會傳回 400 錯誤。模型智慧與指令遵循能力已有所進步,使得大多數預填的使用情境不再需要它。較早的模型仍繼續支援預填,而在對話其他位置加入 assistant 訊息則不受影響。
以下是常見的預填情境以及如何從中遷移:
預填曾被用來強制特定的輸出格式,例如 JSON/YAML、分類,以及類似的模式,其中預填會將 Claude 限制在特定結構中。
遷移方式:結構化輸出功能專為限制 Claude 的回應遵循指定的 schema 而設計。請先嘗試要求模型符合您的輸出結構,因為較新的模型在被告知時能可靠地符合複雜的 schema,尤其是在搭配重試機制實作時。對於分類任務,請使用帶有包含有效標籤之 enum 欄位的工具,或使用結構化輸出。
像 Here is the requested summary:\n 這樣的預填曾被用來略過開場文字。
**遷移方式:**在系統提示中使用直接的指令:「直接回應,不要有前言。不要以『Here is...』、『Based on...』等語句開頭。」或者,指示模型在 XML 標籤內輸出、使用結構化輸出,或使用工具呼叫。如果偶爾仍有前言出現,請在後處理中將其去除。
預填曾被用來繞過不必要的拒絕。
**遷移方式:**Claude 現在在適當拒絕方面表現得好很多。在 user 訊息中使用清晰的提示而不使用預填應已足夠。
預填曾被用來接續部分完成的內容、恢復被中斷的回應,或從先前生成停止的地方繼續。
**遷移方式:**將接續移至 user 訊息,並包含被中斷回應的最後文字:「您先前的回應被中斷,並以 `[previous_response]` 結尾。請從您停下的地方繼續。」如果這是錯誤處理或不完整回應處理的一部分,且沒有使用者體驗上的代價,請重試該請求。
預填曾被用來定期確保上下文被更新或注入。
**遷移方式:**對於非常長的對話,請將先前以預填 assistant 方式提供的提醒注入到 user 輪次中。如果上下文補充是更複雜代理系統的一部分,請考慮透過工具進行補充(根據輪次數等啟發式方法,公開或鼓勵使用包含上下文的工具),或在上下文壓縮期間進行。
工具使用
工具用法
Claude 的最新模型經過訓練以精確遵循指令,並能從明確指示使用特定工具中獲益。如果您說「你能建議一些修改嗎」,Claude 有時會提供建議而非實作它們,即使進行修改可能才是您的本意。如需了解如何定義工具以及排解工具觸發問題,請參閱使用 Claude 進行工具使用。
若要讓 Claude 採取行動,請更加明確:
效果較差(Claude 只會建議):
Can you suggest some changes to improve this function?效果較佳(Claude 會進行修改):
Change this function to improve its performance.或:
Make these edits to the authentication flow.若要讓 Claude 預設更主動地採取行動,您可以將以下內容加入系統提示:
<default_to_action>
By default, implement changes rather than only suggesting them. If the user's intent is
unclear, infer the most useful likely action and proceed, using tools to discover any
missing details instead of guessing. Try to infer the user's intent about whether a tool
call (e.g., file edit or read) is intended or not, and act accordingly.
</default_to_action>另一方面,如果您希望模型預設更加謹慎、較不傾向直接跳入實作,且只在被要求時才採取行動,您可以使用如下的提示來引導此行為:
<do_not_act_before_instructions>
Do not jump into implementation or change files unless clearly instructed to make
changes. When the user's intent is ambiguous, default to providing information, doing
research, and providing recommendations rather than taking action. Only proceed with
edits, modifications, or implementations when the user explicitly requests them.
</do_not_act_before_instructions>Claude Opus 4.5 與 Claude Opus 4.6 對系統提示的反應也比先前的模型更靈敏。如果您的提示原本是為了減少工具或技能觸發不足而設計的,這些模型現在可能會過度觸發。解決方法是收斂任何強烈的措辭。原本您可能會說「CRITICAL: You MUST use this tool when...」,現在可以使用較一般的提示,例如「Use this tool when...」。
最佳化平行工具呼叫
Claude 的最新模型會平行執行獨立的工具呼叫。這些模型會:
- 在研究期間執行多個推測性搜尋
- 一次讀取多個檔案以更快建立上下文
- 平行執行 bash 指令(這甚至可能成為系統效能的瓶頸)
此行為是可引導的。雖然模型在沒有提示的情況下平行工具呼叫的成功率已很高,但您可以將其提升至約 100%,或調整其積極程度:
<use_parallel_tool_calls>
If you intend to call multiple tools and there are no dependencies between the tool
calls, make all of the independent tool calls in parallel. Prioritize calling tools
simultaneously whenever the actions can be done in parallel rather than sequentially.
For example, when reading 3 files, run 3 tool calls in parallel to read all 3 files into
context at the same time. Maximize use of parallel tool calls where possible to increase
speed and efficiency. However, if some tool calls depend on previous calls to inform
dependent values like the parameters, do NOT call these tools in parallel and instead
call them sequentially. Never use placeholders or guess missing parameters in tool
calls.
</use_parallel_tool_calls>Execute operations sequentially with brief pauses between each step to ensure stability.在 Claude Fable 5.1 的長代理迴圈中,請在每一輪工具結果之後,以輪次範圍的系統訊息發送平行呼叫指令。請參閱在代理迴圈中批次處理獨立的工具呼叫。
思考與推理
過度思考與過度周全
Claude Opus 4.6 比先前的模型進行更多前期探索,尤其是在較高的 effort 設定下。這些初始工作通常有助於最佳化最終結果,但模型可能會在未經提示的情況下收集大量上下文或追蹤多條研究線索。如果您的提示先前鼓勵模型更加周全,您應針對 Claude Opus 4.6 調整該指引:
- **以更具針對性的指令取代一概而論的預設值。**不要說「預設使用 [tool]」,而是加入像「當 [tool] 能增進您對問題的理解時使用它」這樣的指引。
- **移除過度提示。**在先前模型中觸發不足的工具,現在很可能會適當觸發。像「如有疑問,請使用 [tool]」這樣的指令會導致過度觸發。
- **將 effort 作為備援手段。**如果 Claude 仍然過於積極,請使用較低的
effort設定。
在某些情況下,Claude Opus 4.6 可能會進行大量思考,這可能會使思考 tokens 膨脹並拖慢回應速度。如果不希望出現此行為,您可以加入明確的指令來限制其推理,或降低 effort 設定以減少整體思考與 token 用量。
When you're deciding how to approach a problem, choose an approach and commit to it.
Avoid revisiting decisions unless you encounter new information that directly
contradicts your reasoning. If you're weighing two approaches, pick one and see it
through. You can always course-correct later if the chosen approach fails.如果您需要對思考成本設定硬性上限,帶有 budget_tokens 上限的「extended thinking」(擴展思考)在 Opus 4.6 與 Sonnet 4.6 上仍可運作,但已被棄用。在 Claude 4.7 及更新的模型上,設定 budget_tokens 會傳回 400 錯誤。建議改為降低 effort 設定,或搭配自適應思考使用 max_tokens 作為硬性限制。
善用思考與交錯思考能力
Claude 的最新模型提供思考能力,對於涉及工具使用後反思或複雜多步驟推理的任務特別有幫助。您可以引導其初始或交錯思考以獲得更好的結果。
Claude 4.6 及更新的模型與 Claude Mythos Preview 使用自適應思考(thinking: {type: "adaptive"}),由 Claude 動態決定何時思考以及思考多少。在 Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5 與 Claude Mythos 5 上,思考始終開啟,且自適應思考是唯一的模式。Claude 根據兩個因素校準其思考:effort 參數與查詢複雜度。較高的 effort 會引發更多思考,較複雜的查詢亦然。對於不需要思考的較簡單查詢,模型會直接回應。在內部評估中,自適應思考可靠地帶來比擴展思考更好的表現。請考慮改用自適應思考。
對於需要代理行為的工作負載,例如多步驟工具使用、複雜的程式設計任務以及長時程代理迴圈,請使用自適應思考。較舊的模型使用帶有 budget_tokens 的手動擴展思考;請參閱各模型設定表以了解每個模型接受哪種設定。
您可以引導 Claude 的思考行為:
After receiving tool results, carefully reflect on their quality and determine optimal
next steps before proceeding. Use your thinking to plan and iterate based on this new
information, and then take the best next action.自適應思考的觸發行為是可透過提示調整的。如果您發現模型思考的頻率比您希望的更高(這在大型或複雜的系統提示下可能發生),請加入指引來引導它:
Thinking adds latency and should only be used when it will meaningfully improve
answer quality - typically for problems that require multistep reasoning. When in
doubt, respond directly.如果您正從帶有 budget_tokens 的擴展思考遷移,請替換您的思考設定,並將預算控制移至 effort。以下範例顯示遷移前後的相同請求(可用的等級與各模型的可用性請參閱 effort):
# 之前:使用手動預算的擴展思考(較舊的模型)
client.messages.create(
model="claude-sonnet-4-5-20250929",
max_tokens=16000,
thinking={"type": "enabled", "budget_tokens": 10000},
messages=[{"role": "user", "content": "..."}],
)
# 之後:搭配 effort 的自適應思考
client.messages.create(
model="claude-opus-4-8",
max_tokens=16000,
thinking={"type": "adaptive"},
output_config={"effort": "high"},
messages=[{"role": "user", "content": "..."}],
)如果您沒有使用擴展思考,則不需要任何變更。在 Claude Opus 4.6 至 Claude Opus 4.8 以及 Claude Sonnet 4.6 上,當您省略 thinking 參數時,思考是關閉的。在 Claude Opus 5 與 Claude Sonnet 5 上,當您省略 thinking 參數時,思考預設為開啟。在 Claude Opus 5 上,您只能在 effort 為 high 或更低時停用它。在 Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5 與 Claude Mythos 5 上,無論您是否設定 thinking 參數,思考始終開啟。
- **優先使用一般性指令而非規定性步驟。**像「徹底思考」這樣的提示通常比手寫的逐步計畫產生更好的推理。Claude 的推理經常超越人類所能規定的範圍。
- **多樣本範例可與思考搭配使用。**在您的少樣本範例中使用
<thinking>標籤,向 Claude 展示推理模式。它會將該風格類推到自己的擴展思考區塊中。 - **以手動「chain-of-thought」(思維鏈),即 CoT 提示作為備援。**當思考關閉時,您仍可透過要求 Claude 逐步思考問題來鼓勵逐步推理。使用像
<thinking>與<answer>這樣的結構化標籤,將推理與最終輸出清楚分開。在 Claude Opus 5 上,建議改為以較低的 effort 等級保持思考開啟:在思考停用的情況下,模型偶爾會將內部 XML 標籤輸出到可見輸出中,因此在該模型上套用此模式之前,請先參閱在思考停用下執行。 - **要求 Claude 自我檢查。**附加類似「在完成之前,請根據 [測試標準] 驗證您的答案」的內容。這能可靠地捕捉錯誤,尤其是在程式設計與數學方面。Claude Opus 5 是例外:它在沒有明確指令的情況下就能很好地驗證自己的工作,而從針對早期模型調校的提示中沿用的驗證指令可能導致過度驗證,增加 tokens 與延遲。遷移至 Claude Opus 5 時,請移除這些指令而非改寫它們。請參閱任務範圍與過度驗證。
代理系統
長時程推理與狀態追蹤
Claude 的最新模型能以強大的狀態追蹤能力處理長時程推理任務。Claude 透過專注於漸進式進展來在長時間的工作階段中保持方向感,一次穩定推進少數幾件事,而非試圖一次完成所有事情。此能力在跨越多個「context window」(上下文視窗)或任務迭代時尤其明顯,Claude 可以處理複雜任務、儲存狀態,然後以全新的上下文視窗繼續。
上下文感知與多視窗工作流程
Claude Sonnet 5、Claude Sonnet 4.6、Claude Sonnet 4.5 與 Claude Haiku 4.5 具備上下文感知功能,讓模型能在整個對話過程中追蹤其剩餘的上下文視窗(也就是它的「token 預算」)。這讓 Claude 能透過了解自己還有多少空間可用,更有效地執行任務與管理上下文。
管理上下文限制:
如果您在會壓縮上下文或允許將上下文儲存至外部檔案的代理框架中使用 Claude(例如在 Claude Code 中),請考慮將此資訊加入您的提示,讓 Claude 能據此行動。否則,Claude 有時可能會在接近上下文限制時自然地嘗試收尾工作。以下是範例提示:
Your context window will be automatically compacted as it approaches its limit, allowing
you to continue working indefinitely from where you left off. Therefore, do not stop
tasks early due to token budget concerns. As you approach your token budget limit, save
your current progress and state to memory before the context window refreshes. Always be
as persistent and autonomous as possible and complete tasks fully, even if the end of
your budget is approaching. Never artificially stop any task early regardless of the
context remaining.記憶工具與上下文感知搭配良好,可用於管理上下文轉換。
跨多個上下文視窗的工作流程
對於跨越多個上下文視窗的任務:
-
**為第一個上下文視窗使用不同的提示:**使用第一個上下文視窗建立框架(撰寫測試、建立設定腳本),然後使用後續的上下文視窗在待辦清單上迭代。
-
**讓模型以結構化格式撰寫測試:**要求 Claude 在開始工作前建立測試,並以結構化格式(例如
tests.json)追蹤它們。這能帶來更好的長期迭代能力。提醒 Claude 測試的重要性:「移除或編輯測試是不可接受的,因為這可能導致功能缺失或有錯誤。」 -
**建立便利工具:**鼓勵 Claude 建立設定腳本(例如
init.sh)以順利啟動伺服器、執行測試套件與 linter。這能避免從全新上下文視窗繼續時的重複工作。 -
**重新開始與壓縮的取捨:**當上下文視窗被清除時,請考慮以全新的上下文視窗開始,而非使用壓縮。Claude 的最新模型在從本機檔案系統探索狀態方面極為有效。在某些情況下,您可能會想利用這一點而非壓縮。請明確規定它應如何開始:
- 「呼叫 pwd;您只能在此目錄中讀寫檔案。」
- 「檢視 progress.txt、tests.json 與 git 記錄。」
- 「在繼續實作新功能之前,先手動執行一次基本的整合測試。」
-
**提供驗證工具:**隨著自主任務的長度增加,Claude 需要在沒有持續人類回饋的情況下驗證正確性。能讓 Claude 驗證 UI 工作的工具很有幫助,例如電腦使用工具、瀏覽器使用工具,或瀏覽器自動化 MCP 伺服器。
-
**鼓勵完整使用上下文:**提示 Claude 在繼續之前有效率地完成各個元件:
This is a very long task, so it may be beneficial to plan out your work clearly. It's
encouraged to spend your entire output context working on the task - just make sure you
don't run out of context with significant uncommitted work. Continue working
systematically until you have completed this task.狀態管理最佳實踐
- **對狀態資料使用結構化格式:**追蹤結構化資訊(例如測試結果或任務狀態)時,請使用 JSON 或其他結構化格式,以幫助 Claude 理解 schema 要求。
- **對進度筆記使用非結構化文字:**自由格式的進度筆記很適合用於追蹤一般進度與上下文。
- **使用 git 進行狀態追蹤:**Git 提供已完成工作的記錄以及可還原的檢查點。Claude 的最新模型在使用 git 跨多個工作階段追蹤狀態方面表現尤其出色。
- **強調漸進式進展:**明確要求 Claude 追蹤其進度並專注於漸進式工作。
{
"tests": [
{ "id": 1, "name": "authentication_flow", "status": "passing" },
{ "id": 2, "name": "user_management", "status": "failing" },
{ "id": 3, "name": "api_endpoints", "status": "not_started" }
],
"total": 200,
"passing": 150,
"failing": 25,
"not_started": 25
}// Progress notes (progress.txt)
Session 3 progress:
- Fixed authentication token validation
- Updated user model to handle edge cases
- Next: investigate user_management test failures (test #2)
- Note: Do not remove tests as this could lead to missing functionality平衡自主性與安全性
在沒有指引的情況下,Claude Opus 4.6 可能會採取難以復原或影響共用系統的動作,例如刪除檔案、強制推送,或發布至外部服務。如果您希望 Claude Opus 4.6 在採取潛在風險動作之前先確認,請在提示中加入指引:
Consider the reversibility and potential impact of your actions. You are encouraged to
take local, reversible actions like editing files or running tests, but for actions that
are hard to reverse, affect shared systems, or could be destructive, ask the user before
proceeding.
Examples of actions that warrant confirmation:
- Destructive operations: deleting files or branches, dropping database tables, rm -rf
- Hard to reverse operations: git push --force, git reset --hard, amending published commits
- Operations visible to others: pushing code, commenting on PRs/issues, sending
messages, modifying shared infrastructure
When encountering obstacles, do not use destructive actions as a shortcut. For example,
don't bypass safety checks (e.g. --no-verify) or discard unfamiliar files that may be
in-progress work.研究與資訊收集
Claude 的最新模型能有效地從多個來源尋找並綜合資訊。如需獲得最佳研究結果:
-
**提供清晰的成功標準:**定義什麼構成對您研究問題的成功回答。
-
**鼓勵來源驗證:**要求 Claude 跨多個來源驗證資訊。
-
對於複雜的研究任務,使用結構化方法:
Search for this information in a structured way. As you gather data, develop several
competing hypotheses. Track your confidence levels in your progress notes to improve
calibration. Regularly self-critique your approach and plan. Update a hypothesis tree or
research notes file to persist information and provide transparency. Break down this
complex research task systematically.這種結構化方法有助於 Claude 有條理地處理大型語料庫,並反覆批判其發現。
子代理編排
Claude 的最新模型能原生編排子代理。這些模型能辨識任務何時會因將工作委派給專門的子代理而受益,並在不需要明確指令的情況下主動這麼做。
若要善用此行為:
- **確保子代理工具定義完善:**備妥子代理工具並在工具定義中加以描述。
- **讓 Claude 自然地編排:**Claude 會在沒有明確指令的情況下適當地委派。
- **留意過度使用:**Claude Opus 4.6 對子代理有強烈偏好,可能會在較簡單、直接的方法就足夠的情況下產生子代理。例如,當直接呼叫 grep 更快且足夠時,模型可能會為程式碼探索產生子代理。Claude Opus 5 也比先前的模型更容易委派給子代理;相關指引與範例抑制提示請參閱控制子代理產生。
如果您看到過度使用子代理的情況,請加入關於何時需要與不需要子代理的明確指引:
Use subagents when tasks can run in parallel, require isolated context, or involve
independent workstreams that don't need to share state. For simple tasks, sequential
operations, single-file edits, or tasks where you need to maintain context across steps,
work directly rather than delegating.串接複雜提示
有了自適應思考與子代理編排,Claude 能在內部處理大多數多步驟推理。當您需要檢視中間輸出或強制執行特定的管線結構時,明確的提示串接(將任務拆分為循序的 API 呼叫)仍然有用。
最常見的串接模式是**自我修正:**產生草稿 → 讓 Claude 根據標準審查 → 讓 Claude 根據審查結果進行改進。每個步驟都是獨立的 API 呼叫,因此您可以在任何時間點記錄、評估或分支。
減少代理程式設計中的檔案建立
Claude 的最新模型有時可能會為了測試與迭代目的建立新檔案,尤其是在處理程式碼時。這種方法讓 Claude 能在儲存最終輸出之前,將檔案(尤其是 Python 腳本)當作「臨時草稿區」使用。使用臨時檔案可以改善結果,尤其是在代理程式設計的使用情境中。
如果您希望盡量減少淨新增的檔案建立,可以指示 Claude 自行清理:
If you create any temporary new files, scripts, or helper files for iteration, clean up
these files by removing them at the end of the task.過度積極
Claude Opus 4.5 與 Claude Opus 4.6 有過度工程化的傾向,會建立額外的檔案、加入不必要的抽象層,或內建未被要求的彈性。如果您看到這種不希望出現的行為,請加入具體指引以保持解決方案精簡。
例如:
Avoid over-engineering. Only make changes that are directly requested or clearly
necessary. Keep solutions simple and focused:
- Scope: Don't add features, refactor code, or make "improvements" beyond what was
asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need
extra configurability.
- Documentation: Don't add docstrings, comments, or type annotations to code you didn't
change. Only add comments where the logic isn't self-evident.
- Defensive coding: Don't add error handling, fallbacks, or validation for scenarios
that can't happen. Trust internal code and framework guarantees. Only validate at system
boundaries (user input, external APIs).
- Abstractions: Don't create helpers, utilities, or abstractions for one-time
operations. Don't design for hypothetical future requirements. The right amount of
complexity is the minimum needed for the current task.避免專注於通過測試與硬編碼
Claude 有時可能會過度專注於讓測試通過,而犧牲更通用的解決方案,或可能使用像輔助腳本這樣的變通方法來進行複雜的重構,而非直接使用標準工具。若要防止此行為並獲得可通用的解決方案:
Please write a high-quality, general-purpose solution using the standard tools
available. Do not create helper scripts or workarounds to accomplish the task more
efficiently. Implement a solution that works correctly for all valid inputs, not just
the test cases. Do not hard-code values or create solutions that only work for specific
test inputs. Instead, implement the actual logic that solves the problem generally.
Focus on understanding the problem requirements and implementing the correct algorithm.
Tests are there to verify correctness, not to define the solution. Provide a principled
implementation that follows best practices and software design principles.
If the task is unreasonable or infeasible, or if any of the tests are incorrect, please
inform me rather than working around them. The solution should be robust, maintainable,
and extendable.在代理程式設計中盡量減少幻覺
Claude 的最新模型較不容易產生幻覺,並能根據程式碼給出更準確、有依據且聰明的答案。若要進一步鼓勵此行為並盡量減少幻覺:
<investigate_before_answering>
Never speculate about code you have not opened. If the user references a specific file,
you MUST read the file before answering. Make sure to investigate and read relevant
files BEFORE answering questions about the codebase. Never make any claims about code
before investigating unless you are certain of the correct answer - give grounded and
hallucination-free answers.
</investigate_before_answering>特定能力提示
改進的視覺能力
與先前的 Claude 模型相比,Claude Opus 4.5 與 Claude Opus 4.6 具有改進的視覺能力。它們在影像處理與資料擷取任務上表現更好,尤其是當上下文中存在多張影像時。這些改進也延伸至電腦使用,模型能更可靠地解讀螢幕截圖與 UI 元素。您也可以透過將影片拆分為影格,使用這些模型來分析影片。
一項已證實能進一步提升表現的有效技術,是給 Claude 一個裁切工具或代理技能。測試顯示,當 Claude 能夠「放大」影像的相關區域時,影像評估的表現有一致的提升。Anthropic 已建立了一份裁切工具的範例。
前端設計
Claude Opus 4.5 和 Claude Opus 4.6 能夠建構具備出色前端設計的複雜、真實世界的網頁應用程式。然而,在缺乏指引的情況下,模型可能會預設採用通用模式,產生使用者所稱的「AI slop」(AI 粗製品)美學。若要打造獨特、富有創意、令人驚喜與愉悅的前端:
對於 API 之外的前端設計工作,Claude Design 提供了畫布與設計工具,讓 Claude 能以互動方式生成並反覆迭代設計。
以下是一段您可以用來鼓勵更佳前端設計的系統提示片段:
<frontend_aesthetics>
You tend to converge toward generic, "on distribution" outputs. In frontend design, this
creates what users call the "AI slop" aesthetic. Avoid this: make creative, distinctive
frontends that surprise and delight.
Focus on:
- Typography: Choose fonts that are beautiful, unique, and interesting. Avoid generic
fonts like Arial and Inter; opt instead for distinctive choices that elevate the
frontend's aesthetics.
- Color & Theme: Commit to a cohesive aesthetic. Use CSS variables for consistency.
Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Draw
from IDE themes and cultural aesthetics for inspiration.
- Motion: Use animations for effects and micro-interactions. Prioritize CSS-only
solutions for HTML. Use Motion library for React when available. Focus on high-impact
moments: one well-orchestrated page load with staggered reveals (animation-delay)
creates more delight than scattered micro-interactions.
- Backgrounds: Create atmosphere and depth rather than defaulting to solid colors. Layer
CSS gradients, use geometric patterns, or add contextual effects that match the overall
aesthetic.
Avoid generic AI-generated aesthetics:
- Overused font families (Inter, Roboto, Arial, system fonts)
- Clichéd color schemes (particularly purple gradients on white backgrounds)
- Predictable layouts and component patterns
- Cookie-cutter design that lacks context-specific character
Interpret creatively and make unexpected choices that feel genuinely designed for the
context. Vary between light and dark themes, different fonts, different aesthetics. You
still tend to converge on common choices (Space Grotesk, for example) across
generations. Avoid this: it is critical that you think outside the box!
</frontend_aesthetics>您也可以參考完整的技能定義。
遷移注意事項
從較早世代遷移至目前的 Claude 模型時:
-
明確說明期望的行為: 請考慮精確描述您希望在輸出中看到的內容。
-
以修飾語來組織您的指令: 加入鼓勵 Claude 提升輸出品質與細節的修飾語,有助於更好地塑造 Claude 的表現。例如,與其使用「建立一個分析儀表板」,不如使用「建立一個分析儀表板。盡可能納入相關的功能與互動。超越基本需求,打造功能完整的實作。」
-
明確要求特定功能: 若需要動畫與互動元素,應明確提出要求。
-
更新思考設定: Claude 4.6 模型使用 adaptive thinking(自適應思考)(
thinking: {type: "adaptive"}),而非搭配budget_tokens的手動思考。請使用 effort 參數來控制思考深度。 -
停止使用預填回應: 自 Claude 4.6 模型與 Claude Mythos Preview 起,不再支援在最後一個 assistant 回合中使用預填回應。請參閱停止使用預填回應以取得替代方案的詳細指引。
-
調整反惰性提示: 如果您先前的提示鼓勵模型更加徹底或更積極地使用工具,請減少這類指引。Claude 4.6 模型更為主動,對於先前模型所需的指令可能會過度觸發。
-
原封不動地傳回思考區塊,並保持歷史記錄僅追加: 請完全依照 API 回傳的內容追加每個 assistant 回合,包含思考區塊。在 Claude Fable 5.1 上,修改思考區塊之前的對話會導致錯誤,或者若您選擇啟用該選項,則該區塊會被捨棄:在請求之間編輯較早的訊息、重建
system或tools,或就地摘要較舊的回合,都會使之後的每個思考區塊失效,因此請將這些變更移至對話中途的系統訊息與伺服器端的上下文管理。請參閱保持對話歷史記錄僅追加。
如需詳細的遷移步驟,請參閱遷移指南。
從 Claude Sonnet 4.5 或更早版本遷移至 Claude Sonnet 5
請參閱遷移指南中的從 Claude Sonnet 4.5 或更早版本遷移至 Claude Sonnet 5,其中涵蓋了 effort 預設值的變更,以及手動擴展思考(budget_tokens)的移除。
後續步驟
Claude Fable 5.1 的行為差異與提示模式,涵蓋 effort、任務完成、進度更新、思考區塊、工具呼叫批次處理以及寫作風格。
Claude Fable 5 與 Claude Mythos 5 的行為差異與提示模式,涵蓋 effort、指令遵循、長時間執行、記憶以及鷹架變更。
Claude Sonnet 5 的行為差異與提示模式,涵蓋 effort、自適應思考預設值、工具使用,以及從 Claude Sonnet 4.6 遷移。
Claude Opus 5 的行為差異與提示模式,涵蓋回應冗長度、代理式敘述、任務範圍界定、子代理委派以及自我修正。
何時使用提示工程,以及在調整提示之前如何規劃您的方法。
Was this page helpful?