提示詞工程最佳實踐

這是使用 Claude 最新模型進行提示詞工程的單一參考資源，包括 Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 4.6 和 Claude Haiku 4.5。它涵蓋基礎技術、輸出控制、工具使用、思考和代理系統。跳轉到與您的情況相符的部分。

提示 Claude Opus 4.7

Claude Opus 4.7 是我們功能最強大的通用可用模型，在長期代理工作、知識工作、視覺和記憶任務方面具有特殊優勢。它在現有 Claude Opus 4.6 提示詞上表現良好。下面的模式涵蓋最常需要調整的行為。

響應長度和冗長度

Claude Opus 4.7 根據其判斷任務的複雜程度來校準響應長度，而不是默認為固定的冗長度。這通常意味著簡單查詢的答案更短，開放式分析的答案更長。

如果您的產品依賴於特定的輸出風格或冗長度，您可能需要調整您的提示詞。例如，要減少冗長度，您可以添加：

提供簡潔、集中的響應。跳過非必要的上下文，並保持示例最少。

如果您看到特定類型的冗長度示例（即過度解釋），您可以在提示詞中添加額外的指示來防止它們。顯示 Claude 如何以適當的簡潔程度進行溝通的正面示例往往比負面示例或告訴模型不要做什麼的指示更有效。

校準努力和思考深度

努力參數允許您調整 Claude 的智能與令牌支出，在功能和更快速度及更低成本之間進行權衡。對於編碼和代理使用案例，從新的 xhigh 努力級別開始，對於大多數對智能敏感的使用案例，至少使用 high 努力。嘗試其他努力級別以進一步調整令牌使用和智能：

• max： 最大努力可以在某些使用案例中提供性能提升，但可能會因令牌使用增加而顯示收益遞減。此設置有時也可能容易過度思考。我們建議為對智能要求高的任務測試最大努力。
• xhigh（新）： 超高努力是大多數編碼和代理使用案例的最佳設置。
• high： 此設置在令牌使用和智能之間取得平衡。對於大多數對智能敏感的使用案例，我們建議至少使用 high 努力。
• medium： 適合需要減少令牌使用同時權衡智能的成本敏感使用案例。
• low： 保留用於短期、範圍明確的任務和對智能不敏感的延遲敏感工作負載。

與 Claude Opus 4.6 相比，Claude Opus 4.7 有意義地改變了，嚴格遵守努力級別，特別是在低端。在 low 和 medium 時，模型將其工作範圍限制在所要求的內容，而不是超越預期。這對延遲和成本有利，但在中等複雜任務上以 low 努力運行時，存在一些思考不足的風險。

如果您在複雜問題上觀察到淺層推理，請將努力提高到 high 或 xhigh，而不是圍繞它進行提示詞調整。如果您需要為了延遲而保持 low 努力，請添加有針對性的指導：

此任務涉及多步驟推理。在響應之前仔細思考該問題。

我們預期努力對此模型的重要性將比任何先前的 Opus 都更重要，並建議在升級時積極進行實驗。

自適應思考的觸發行為是可控的。如果您發現模型思考的頻率比您希望的要高——這可能發生在大型或複雜的系統提示詞中——添加指導來引導它。如往常一樣，測量任何提示詞更改對性能的影響。示例：

思考會增加延遲，只應在它將有意義地改進答案質量時使用——通常用於需要多步驟推理的問題。如有疑問，直接響應。

相反，如果您在 medium 運行硬工作負載並看到思考不足，第一個槓桿是提高努力。如果您需要更精細的控制，直接提示它。

工具使用觸發

Claude Opus 4.7 傾向於比 Claude Opus 4.6 使用工具的頻率更低，而使用推理更多。在大多數情況下，這會產生更好的結果。但是，增加努力設置是增加工具使用級別的有用槓桿，特別是在知識工作中。high 或 xhigh 努力設置在代理搜索和編碼中顯示出明顯更多的工具使用。對於您想要更多工具使用的場景，您也可以調整您的提示詞以明確指示模型何時以及如何正確使用其工具。例如，如果您發現模型沒有使用您的網絡搜索工具，請清楚地描述原因和方式。

面向用戶的進度更新

Claude Opus 4.7 在長代理跟蹤中為用戶提供更定期、更高質量的更新。如果您添加了腳手架來強制臨時狀態消息（「每 3 個工具調用後，總結進度」），請嘗試移除它。如果您發現 Claude Opus 4.7 的面向用戶的更新的長度或內容對您的使用案例校準不當，請在提示詞中明確描述這些更新應該是什麼樣子，並提供示例。

更字面的指示遵循

Claude Opus 4.7 比 Claude Opus 4.6 更字面和明確地解釋提示詞，特別是在較低的努力級別。它不會默默地將一項指示從一個項目推廣到另一個項目，也不會推斷您沒有提出的請求。這種字面性的優點是精確性和更少的混亂，它通常對具有仔細調整提示詞、結構化提取和您想要可預測行為的管道的 API 使用案例表現更好。如果您需要 Claude 廣泛應用指示，請明確說明範圍（例如，「將此格式應用於每個部分，而不僅僅是第一個」）。

語調和寫作風格

與任何新模型一樣，長篇寫作的散文風格可能會改變。Claude Opus 4.7 更直接和有主見，驗證前置短語更少，表情符號也比 Claude Opus 4.6 的更溫暖風格少。如果您的產品依賴於特定的聲音，請根據新的基線重新評估風格提示詞。

例如，如果您的產品聲音更溫暖或更對話式，請添加：

使用溫暖、協作的語調。在回答之前確認用戶的框架。

控制子代理生成

Claude Opus 4.7 傾向於默認生成較少的子代理。但是，這種行為可以通過提示詞進行控制；給 Claude Opus 4.7 明確的指導，說明何時需要子代理。編碼使用案例的一個玩具示例：

不要為您可以在單個響應中直接完成的工作生成子代理（例如，重構您已經可以看到的函數）。

在同一轉中為多個項目或讀取多個文件時生成多個子代理。

設計和前端默認值

Claude Opus 4.7 比 Claude Opus 4.6 具有更強的設計直覺，具有一致的默認房屋風格：溫暖的奶油色/米白色背景（約 #F4F1EA）、襯線顯示類型（Georgia、Fraunces、Playfair）、斜體單詞重音和陶土/琥珀色重音。這對編輯、酒店和投資組合簡介讀起來很好，但對於儀表板、開發工具、金融科技、醫療保健或企業應用來說會感覺不對——它也出現在幻燈片中以及網絡 UI 中。

此默認值是持久的。通用指示（「不要使用奶油色」、「使其乾淨簡約」）傾向於將模型轉移到不同的固定調色板，而不是產生多樣性。兩種方法可靠地工作：

1. 指定具體的替代方案。 模型精確遵循明確的規範：

為名為 AEFRM 的補充品牌設計桌面登陸頁面。

視覺方向應來自使用淡銀灰色調的冷單色氛圍，逐漸深化為藍灰色和近黑色，類似於霧化的金屬表面。

該頁面應感覺尖銳和受控，具有強烈的結構感和克制感。

在整個頁面中使用此色調系統，而不是引入明亮的重音顏色。

在英雄設計中以黑白方式使用上傳的圖像。

佈局應使用清晰的水平部分和居中的最大寬度容器構建。在卡片、按鈕、輸入和媒體框架中一致地使用 4px 角半徑。邊距應感覺慷慨，每個部分周圍有足夠的空白空間，以便頁面呼吸。

排版應使用方形、角度的無襯線字體，字母間距比平常更寬，特別是在標題和導航中，使文本感覺更工程化，壓縮感更少。標題文本可以很大且大寫，而支持副本保持簡短和稀疏。子文本應使用 Alumni Sans SC 以 4-6px 編寫，如角落底部中心的微小文本。

對於結構，從包含強有力的產品聲明、一個簡短的支持段落和一個乾淨的產品佔位符或包裝框架的英雄部分開始。在此下方，添加一個包含三個或四個塊的好處網格，然後是配方或成分部分，最後是號召性用語。

按鈕應平坦精確，具有微妙的懸停變化，使用 transition: all 160ms ease out，其中亮度和邊框對比略微移動，而不是使用戲劇性運動。

顏色調色板應保持在此範圍內：
#E9ECEC、#C9D2D4、#8C9A9E、#44545B、#11171B。

2. 讓模型在構建前提出選項。 這打破了默認值並給用戶控制權。如果您之前依賴 temperature 來實現設計多樣性，請使用此方法——它在運行中產生有意義的不同方向。示例提示詞：

在構建之前，提出 4 個針對此簡介量身定制的不同視覺方向（每個為：bg hex / accent hex / typeface——單行理由）。要求用戶選擇一個，然後僅實施該方向。

此外，Claude Opus 4.7 需要比以前的模型更少的前端設計提示詞，以避免用戶稱之為「AI 垃圾」美學的通用模式。對於早期模型，我們在我們的前端設計技能中推薦了更長的提示詞片段。但是，Claude Opus 4.7 以更少的提示詞指導生成獨特、創意的前端。此提示詞片段與上述提示詞建議配合使用效果很好，以實現多樣性：

<frontend_aesthetics>
永遠不要使用通用的 AI 生成美學，如過度使用的字體系列（Inter、Roboto、Arial、系統字體）、陳詞濫調的配色方案（特別是白色或深色背景上的紫色漸變）、可預測的佈局和組件模式，以及缺乏特定於上下文的特徵的千篇一律的設計。使用獨特的字體、有凝聚力的顏色和主題，以及用於效果和微交互的動畫。
</frontend_aesthetics>

互動編碼產品

Claude Opus 4.7 的令牌使用和行為可能在具有單個用戶轉的自主、非同步編碼代理和具有多個用戶轉的互動、同步編碼代理之間有所不同。具體來說，它在互動設置中傾向於使用更多令牌，主要是因為它在用戶轉後進行更多推理。這可以改進長期編碼會話中的長期一致性、指示遵循和編碼功能，但也伴隨著更多的令牌使用。為了在編碼產品中最大化性能和令牌效率，我們建議使用 xhigh 或 high 努力，添加自主功能（如自動模式），並減少用戶所需的人類交互次數。

當然，在限制所需的用戶交互次數時，重要的是在第一個人類轉中預先指定任務、意圖和相關約束。在前面提供良好指定、清晰和準確的任務描述可以幫助最大化自主性和智能，同時最小化用戶轉後的額外令牌使用。我們發現，因為 Claude Opus 4.7 比先前的模型更自主，這種使用模式有助於最大化性能。相比之下，在多個用戶轉中逐步傳達的模糊或未充分指定的提示詞往往相對降低令牌效率，有時也會降低性能。

代碼審查工具

Claude Opus 4.7 在查找錯誤方面比先前的模型有意義地更好，在我們的評估中具有更高的召回率和精確度——在我們基於真實 Anthropic PR 的最難的錯誤查找評估之一中，召回率提高了 11pp。但是，如果您的代碼審查工具是為早期模型調整的，您最初可能會看到更低的召回率。這可能是工具效應，而不是功能回歸。當審查提示詞說「僅報告高嚴重性問題」、「保守」或「不要吹毛求疵」時，Claude Opus 4.7 可能比早期模型更忠實地遵循該指示——它可能同樣徹底地調查代碼、識別錯誤，然後不報告它判斷低於您所述標準的發現。這可以表現為模型進行相同深度的調查但將較少的調查轉換為報告的發現，特別是在較低嚴重性的錯誤上。精確度通常會上升，但測量的召回率可能會下降，儘管模型的基礎錯誤查找能力已經改進。

一些推薦的提示詞語言：

報告您找到的每個問題，包括您不確定或認為低嚴重性的問題。不要在此階段過濾重要性或信心——單獨的驗證步驟將執行此操作。您的目標是覆蓋：最好是表面一個稍後被過濾掉的發現，而不是默默地丟棄真正的錯誤。對於每個發現，包括您的信心級別和估計的嚴重性，以便下游過濾器可以對其進行排名。

此提示詞可以在沒有實際第二步的情況下使用，但將信心過濾移出發現步驟通常會有幫助。如果您的工具有單獨的驗證、重複數據刪除或排名階段，明確告訴模型其在發現階段的工作是覆蓋而不是過濾。

如果您確實希望模型在單個通過中自行過濾，請具體說明標準在哪裡，而不是使用「重要」之類的定性術語——例如，「報告任何可能導致不正確行為、測試失敗或誤導結果的錯誤；僅省略純風格或命名偏好之類的小問題」。

我們建議根據您的評估或測試案例的子集迭代提示詞，以驗證召回率或 F1 分數收益。

計算機使用

計算機使用功能可在各種分辨率上工作，最高可達新的最大分辨率 2576px / 3.75MP。在我們的計算機使用測試中，我們發現以 1080p 發送圖像提供了性能和成本的良好平衡。

對於特別成本敏感的工作負載，我們建議 720p 或 1366×768 作為具有強大性能的較低成本選項。我們建議您進行自己的測試，以找到適合您使用案例的理想設置；嘗試努力設置也可以幫助調整模型的行為。

一般原則

清晰直接

Claude 對清晰、明確的指示反應良好。具體說明您所需的輸出可以幫助增強結果。如果您想要「超越預期」的行為，請明確請求它，而不是依賴模型從模糊的提示詞推斷這一點。

將 Claude 視為一位聰慧但新進的員工，他缺乏對您的規範和工作流程的背景。您解釋所需內容的精確程度越高，結果就越好。

黃金法則： 向對任務背景最少的同事展示您的提示詞，並要求他們遵循它。如果他們會感到困惑，Claude 也會。

• 具體說明所需的輸出格式和約束。
• 當步驟的順序或完整性重要時，使用編號列表或項目符號點以順序步驟的形式提供指示。

添加上下文以改進性能

提供指示背後的上下文或動機，例如向 Claude 解釋為什麼這種行為很重要，可以幫助 Claude 更好地理解您的目標並提供更有針對性的響應。

Claude 足夠聰慧，可以從解釋中推廣。

有效使用示例

示例是引導 Claude 輸出格式、語調和結構的最可靠方法之一。一些精心製作的示例（稱為少樣本或多樣本提示詞）可以顯著提高準確性和一致性。

添加示例時，請使其：

• 相關： 密切反映您的實際使用案例。
• 多樣化： 涵蓋邊界情況，並有足夠的變化，使 Claude 不會拾取無意的模式。
• 結構化： 將示例包裝在 <example> 標籤中（多個示例在 <examples> 標籤中），以便 Claude 可以將它們與指示區分開。

使用 XML 標籤結構化提示詞

XML 標籤幫助 Claude 明確地解析複雜的提示詞，特別是當您的提示詞混合指示、上下文、示例和變量輸入時。將每種類型的內容包裝在其自己的標籤中（例如 <instructions>、<context>、<input>）可以減少誤解。

最佳實踐：

• 在您的提示詞中使用一致、描述性的標籤名稱。
• 當內容具有自然層次結構時嵌套標籤（<documents> 內的文檔，每個在 <document index="n"> 內）。

給 Claude 一個角色

在系統提示詞中設置角色可以為您的使用案例集中 Claude 的行為和語調。即使是單個句子也會產生差異：

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-7",
    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+ 令牌）時，仔細結構化您的提示詞以獲得最佳結果：

• 將長篇數據放在頂部：將您的長文檔和輸入放在提示詞的頂部，在您的查詢、指示和示例上方。這可以顯著改進所有模型的性能。

  在測試中，查詢在末尾可以將響應質量提高多達 30%，特別是對於複雜的多文檔輸入。

• 使用 XML 標籤結構化文檔內容和元數據：使用多個文檔時，將每個文檔包裝在 <document> 標籤中，其中包含 <document_content> 和 <source>（以及其他元數據）子標籤以獲得清晰度。

  示例多文檔結構

模型自我認知

如果您希望 Claude 在您的應用程序中正確識別自己或使用特定的 API 字符串：

助手是由 Anthropic 創建的 Claude。當前模型是 Claude Opus 4.7。

對於需要指定模型字符串的 LLM 驅動應用程序：

當需要 LLM 時，除非用戶另有要求，否則請默認為 Claude Opus 4.7。Claude Opus 4.7 的確切模型字符串是 claude-opus-4-7。

輸出和格式化

溝通風格和冗長度

Claude 的最新模型與以前的模型相比具有更簡潔和自然的溝通風格：

• 更直接和基礎： 提供基於事實的進度報告，而不是自我慶祝的更新
• 更對話式： 稍微更流暢和口語化，不那麼像機器
• 不那麼冗長： 除非另有提示，否則可能會跳過詳細的摘要以提高效率

這意味著 Claude 可能會在工具調用後跳過口頭摘要，直接跳到下一個操作。如果您更喜歡更多地了解其推理：

完成涉及工具使用的任務後，提供您所做工作的快速摘要。

控制響應格式

有幾種特別有效的方法來引導輸出格式化：

1. 告訴 Claude 要做什麼，而不是不要做什麼

   • 而不是：「不要在您的響應中使用 markdown」
   • 嘗試：「您的響應應由平滑流動的散文段落組成。」

2. 使用 XML 格式指示符

   • 嘗試：「在 <smoothly_flowing_prose_paragraphs> 標籤中寫出您響應的散文部分。」

3. 將您的提示詞風格與所需的輸出相匹配

   您的提示詞中使用的格式化風格可能會影響 Claude 的響應風格。如果您仍然遇到輸出格式化的可控性問題，請嘗試將您的提示詞風格與所需的輸出風格盡可能緊密地匹配。例如，從提示詞中移除 markdown 可以減少輸出中 markdown 的數量。

4. 為特定格式化偏好使用詳細提示詞

   為了更好地控制 markdown 和格式化使用，請提供明確的指導：

<avoid_excessive_markdown_and_bullet_points>
在編寫報告、文檔、技術解釋、分析或任何長篇內容時，使用清晰、流動的散文編寫，使用完整的段落和句子。使用標準段落中斷進行組織，並主要為 `inline code`、代碼塊 (```...```) 和簡單標題 (###、###) 保留 markdown。避免使用 **bold** 和 *italics*。

不要使用有序列表 (1. ...) 或無序列表 (*)，除非：a) 您呈現的是列表格式是最佳選項的真正離散項目，或 b) 用戶明確要求列表或排名

而不是用項目符號或數字列出項目，請將它們自然地融入句子中。此指導特別適用於技術寫作。使用散文而不是過度格式化將改進用戶滿意度。永遠不要輸出一系列過度簡短的項目符號點。

您的目標是可讀、流動的文本，自然地引導讀者通過想法，而不是將信息分割成孤立的點。
</avoid_excessive_markdown_and_bullet_points>

LaTeX 輸出

Claude Opus 4.6 默認為數學表達式、方程式和技術解釋使用 LaTeX。如果您更喜歡純文本，請將以下指示添加到您的提示詞：

僅以純文本格式設置您的響應。不要使用 LaTeX、MathJax 或任何標記符號，如 \( \)、$ 或 \frac{}{}。使用標準文本字符編寫所有數學表達式（例如，「/」表示除法，「*」表示乘法，「^」表示指數）。

文檔創建

Claude 的最新模型在創建具有令人印象深刻的創意天賦和強大指示遵循的演示文稿、動畫和視覺文檔方面表現出色。在大多數情況下，模型在第一次嘗試時就會產生拋光、可用的輸出。

為了在文檔創建中獲得最佳結果：

在 [topic] 上創建專業演示文稿。包括深思熟慮的設計元素、視覺層次結構和適當的引人入勝的動畫。

從預填充響應遷移

從 Claude 4.6 模型和 Claude Mythos Preview 開始，最後一個助手轉上的預填充響應不再受支持。在 Mythos Preview 上，帶有預填充助手消息的請求返回 400 錯誤。模型智能和指示遵循已經進步，使得大多數預填充使用案例不再需要它。現有模型將繼續支持預填充，並在對話中的其他地方添加助手消息不受影響。

以下是常見的預填充場景以及如何從它們遷移：

工具使用

工具使用

Claude 的最新模型經過訓練可以精確遵循指示，並受益於明確的方向來使用特定工具。如果您說「您能建議一些更改嗎」，Claude 有時會提供建議而不是實施它們，即使進行更改可能是您的意圖。

為了讓 Claude 採取行動，請更明確：

為了使 Claude 默認對採取行動更主動，您可以將其添加到您的系統提示詞：

<default_to_action>
默認情況下，實施更改而不僅僅是建議它們。如果用戶的意圖不清楚，推斷最有用的可能行動並繼續，使用工具發現任何缺失的詳細信息，而不是猜測。嘗試推斷用戶關於是否打算進行工具調用（例如文件編輯或讀取）的意圖，並相應地採取行動。
</default_to_action>

另一方面，如果您希望模型默認更猶豫，不太容易直接跳入實現，並且只在請求時採取行動，您可以使用如下提示詞來引導此行為：

<do_not_act_before_instructions>
除非明確指示進行更改，否則不要跳入實現或更改文件。當用戶的意圖不明確時，默認提供信息、進行研究和提供建議，而不是採取行動。僅在用戶明確要求時才繼續進行編輯、修改或實現。
</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>
如果您打算呼叫多個工具且工具呼叫之間沒有依賴關係，請以平行方式進行所有獨立工具呼叫。優先考慮在可以平行執行操作時同時呼叫工具，而不是按順序呼叫。例如，在讀取 3 個檔案時，以平行方式執行 3 個工具呼叫，同時將所有 3 個檔案讀入上下文。在可能的情況下最大化平行工具呼叫的使用，以提高速度和效率。但是，如果某些工具呼叫依賴於先前的呼叫來通知依賴值（如參數），請勿平行呼叫這些工具，而應按順序呼叫。切勿在工具呼叫中使用佔位符或猜測缺失的參數。
</use_parallel_tool_calls>

按順序執行操作，每個步驟之間有短暫的暫停，以確保穩定性。

思考和推理

過度思考和過度徹底

Claude Opus 4.6 進行的前期探索明顯多於以前的模型，特別是在較高的 effort 設定下。這項初期工作通常有助於優化最終結果，但該模型可能會在沒有提示的情況下收集廣泛的上下文或追求多個研究線索。如果您的提示之前鼓勵該模型更加徹底，您應該為 Claude Opus 4.6 調整該指導：

• 用更有針對性的指示替換籠統的預設值。 不要說「預設使用 [tool]」，而是添加指導，例如「在 [tool] 會增強您對問題的理解時使用它」。
• 移除過度提示。 在以前的模型中觸發不足的工具現在可能會適當地觸發。「如有疑問，使用 [tool]」之類的指示將導致過度觸發。
• 使用 effort 作為備選方案。 如果 Claude 繼續過於激進，請為 effort 使用較低的設定。

在某些情況下，Claude Opus 4.6 可能會進行廣泛的思考，這可能會增加思考令牌並減慢回應速度。如果此行為不可取，您可以添加明確的指示來限制其推理，或者您可以降低 effort 設定以減少整體思考和令牌使用。

當您決定如何解決問題時，選擇一種方法並堅持它。除非您遇到直接與您的推理相矛盾的新信息，否則避免重新審視決定。如果您在權衡兩種方法，請選擇一種並堅持下去。如果所選方法失敗，您稍後總是可以改變方向。

如果您需要對思考成本設置硬上限，具有 budget_tokens 上限的擴展思考在 Opus 4.6 和 Sonnet 4.6 上仍然有效，但已被棄用。更傾向於降低 effort 設定或使用 max_tokens 作為硬限制與 adaptive thinking。

利用思考和交錯思考功能

Claude 的最新模型提供思考功能，特別有助於涉及工具使用後反思或複雜多步推理的任務。您可以指導其初始或交錯思考以獲得更好的結果。

Claude Opus 4.6 和 Claude Sonnet 4.6 使用 adaptive thinking（thinking: {type: "adaptive"}），其中 Claude 動態決定何時以及思考多少。Claude 根據兩個因素校準其思考：effort 參數和查詢複雜性。更高的 effort 會引發更多思考，更複雜的查詢也是如此。在不需要思考的更簡單查詢上，該模型直接回應。在內部評估中，adaptive thinking 可靠地驅動比擴展思考更好的效能。考慮轉向 adaptive thinking 以獲得最聰明的回應。

對於需要代理行為的工作負載（如多步工具使用、複雜編碼任務和長期代理迴圈），使用 adaptive thinking。較舊的模型使用帶有 budget_tokens 的手動思考模式。

您可以指導 Claude 的思考行為：

收到工具結果後，仔細反思其品質，並在繼續之前確定最佳後續步驟。使用您的思考來根據這些新信息進行規劃和迭代，然後採取最佳的下一步行動。

adaptive thinking 的觸發行為是可提示的。如果您發現該模型思考的頻率比您希望的要高，這可能發生在大型或複雜的系統提示中，請添加指導來引導它：

擴展思考會增加延遲，應僅在它將有意義地改善答案品質時使用 - 通常用於需要多步推理的問題。如有疑問，直接回應。

如果您正在從具有 budget_tokens 的 extended thinking 遷移，請替換您的思考配置並將預算控制移至 effort：

之前（擴展思考，較舊的模型）：

client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=64000,
    thinking={"type": "enabled", "budget_tokens": 32000},
    messages=[{"role": "user", "content": "..."}],
)

之後（adaptive thinking）：

client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # or "max", "xhigh", "medium", "low"
    messages=[{"role": "user", "content": "..."}],
)

如果您未使用擴展思考，則無需進行任何更改。當您省略 thinking 參數時，思考預設為關閉。

• 傾向於一般指示而不是規定步驟。 「仔細思考」之類的提示通常會產生比手寫逐步計劃更好的推理。Claude 的推理經常超過人類會規定的內容。
• 多次示例與思考一起工作。 在您的少次示例中使用 <thinking> 標籤來向 Claude 展示推理模式。它將把該風格推廣到其自己的擴展思考塊。
• 手動 CoT 作為備選方案。 當思考關閉時，您仍然可以通過要求 Claude 思考問題來鼓勵逐步推理。使用結構化標籤（如 <thinking> 和 <answer>）來清潔地分離推理與最終輸出。
• 要求 Claude 自我檢查。 附加類似「在您完成之前，根據 [test criteria] 驗證您的答案」的內容。這可靠地捕捉錯誤，特別是對於編碼和數學。

代理系統

長期推理和狀態追蹤

Claude 的最新模型在長期推理任務中表現出色，具有卓越的狀態追蹤功能。Claude 通過專注於增量進度來保持跨擴展會話的方向，一次在幾件事上取得穩定進展，而不是嘗試一次完成所有事情。此功能特別在多個上下文視窗或任務迭代中出現，其中 Claude 可以處理複雜任務、保存狀態並使用新的上下文視窗繼續。

上下文感知和多視窗工作流程

Claude 4.6 和 Claude 4.5 模型具有 context awareness，使該模型能夠在整個對話中追蹤其剩餘上下文視窗（即「令牌預算」）。這使 Claude 能夠通過理解它有多少空間來工作，更有效地執行任務和管理上下文。

管理上下文限制：

如果您在代理工具中使用 Claude，該工具會壓縮上下文或允許將上下文保存到外部檔案（如在 Claude Code 中），請考慮將此信息添加到您的提示中，以便 Claude 可以相應地表現。否則，Claude 可能有時會在接近上下文限制時自然嘗試結束工作。以下是一個範例提示：

您的上下文視窗將在接近其限制時自動壓縮，允許您從中斷的地方無限期地繼續工作。因此，不要因為令牌預算問題而提前停止任務。當您接近令牌預算限制時，在上下文視窗刷新之前將您當前的進度和狀態保存到記憶體。始終盡可能堅持和自主，並完全完成任務，即使您的預算即將結束。切勿因為剩餘上下文而人為地提前停止任何任務。

memory tool 與上下文感知自然配對，以實現無縫上下文轉換。

多上下文視窗工作流程

對於跨越多個上下文視窗的任務：

1. 為第一個上下文視窗使用不同的提示：使用第一個上下文視窗來設置框架（編寫測試、建立設置腳本），然後使用未來的上下文視窗在待辦事項清單上進行迭代。

2. 讓模型以結構化格式編寫測試：要求 Claude 在開始工作前建立測試，並以結構化格式（例如 tests.json）追蹤它們。這導致更好的長期迭代能力。提醒 Claude 測試的重要性：「移除或編輯測試是不可接受的，因為這可能導致缺失或有缺陷的功能。」

3. 設置生活品質工具：鼓勵 Claude 建立設置腳本（例如 init.sh）以優雅地啟動伺服器、執行測試套件和 linters。這可以防止在從新的上下文視窗繼續時重複工作。

4. 開始新的 vs 壓縮：當上下文視窗被清除時，考慮使用全新的上下文視窗而不是使用壓縮開始。Claude 的最新模型在從本地檔案系統發現狀態方面非常有效。在某些情況下，您可能想利用這一點而不是壓縮。對於它應該如何開始要有規定性：

   • 「呼叫 pwd；您只能在此目錄中讀取和寫入檔案。」
   • 「查看 progress.txt、tests.json 和 git 日誌。」
   • 「在繼續實施新功能之前，手動執行基本集成測試。」

這是一項非常長的任務，因此詳細規劃您的工作可能會很有益。建議花費您的整個輸出上下文來處理任務 - 只需確保您不會在有重大未提交工作的情況下用完上下文。系統地繼續工作，直到您完成此任務。

狀態管理最佳實踐

• 使用結構化格式的狀態數據：在追蹤結構化信息（如測試結果或任務狀態）時，使用 JSON 或其他結構化格式來幫助 Claude 理解架構要求
• 使用非結構化文本進行進度筆記：自由格式進度筆記適合追蹤一般進度和上下文
• 使用 git 進行狀態追蹤：Git 提供了已完成工作的日誌和可以恢復的檢查點。Claude 的最新模型在使用 git 跨多個會話追蹤狀態方面表現特別好。
• 強調增量進度：明確要求 Claude 追蹤其進度並專注於增量工作

平衡自主性和安全性

在沒有指導的情況下，Claude Opus 4.6 可能會採取難以逆轉或影響共享系統的操作，例如刪除檔案、強制推送或發佈到外部服務。如果您希望 Claude Opus 4.6 在採取潛在風險操作之前確認，請向您的提示添加指導：

考慮您的操作的可逆性和潛在影響。建議您採取本地、可逆的操作，如編輯檔案或執行測試，但對於難以逆轉、影響共享系統或可能具有破壞性的操作，請在繼續之前詢問用戶。

值得確認的操作示例：
- 破壞性操作：刪除檔案或分支、刪除數據庫表、rm -rf
- 難以逆轉的操作：git push --force、git reset --hard、修改已發佈的提交
- 對他人可見的操作：推送代碼、評論 PR/問題、發送消息、修改共享基礎設施

遇到障礙時，不要使用破壞性操作作為捷徑。例如，不要繞過安全檢查（例如 --no-verify）或丟棄可能正在進行中的不熟悉檔案。

研究和信息收集

Claude 的最新模型展示了卓越的代理搜尋功能，可以有效地從多個來源查找和綜合信息。為了獲得最佳研究結果：

1. 提供明確的成功標準：定義對您的研究問題的成功答案構成什麼

2. 鼓勵來源驗證：要求 Claude 跨多個來源驗證信息

3. 對於複雜的研究任務，使用結構化方法：

以結構化方式搜索此信息。當您收集數據時，開發幾個相互競爭的假設。在進度筆記中追蹤您的信心水平以改進校準。定期自我批評您的方法和計劃。更新假設樹或研究筆記檔案以保留信息並提供透明度。系統地分解此複雜研究任務。

這種結構化方法使 Claude 能夠查找和綜合幾乎任何信息，無論語料庫的大小如何，並迭代地批評其發現。

子代理編排

Claude 的最新模型展示了顯著改進的本地子代理編排功能。這些模型可以識別何時任務將受益於委派工作給專門的子代理，並在沒有明確指示的情況下主動執行此操作。

要利用此行為：

1. 確保定義明確的子代理工具：有子代理工具可用並在工具定義中描述
2. 讓 Claude 自然編排：Claude 將在沒有明確指示的情況下適當地委派
3. 注意過度使用：Claude Opus 4.6 對子代理有強烈的偏好，可能在更簡單、直接的方法就足夠的情況下生成它們。例如，該模型可能在直接 grep 呼叫更快且足夠時為代碼探索生成子代理。

如果您看到過度的子代理使用，請添加明確的指導，說明何時應該和不應該使用子代理：

在任務可以平行執行、需要隔離上下文或涉及不需要共享狀態的獨立工作流時使用子代理。對於簡單任務、順序操作、單檔案編輯或需要跨步驟維護上下文的任務，直接工作而不是委派。

鏈接複雜提示

使用 adaptive thinking 和子代理編排，Claude 在內部處理大多數多步推理。當您需要檢查中間輸出或強制執行特定管道結構時，顯式提示鏈接（將任務分解為順序 API 呼叫）仍然有用。

最常見的鏈接模式是自我修正：生成草稿 → 讓 Claude 根據標準審查它 → 讓 Claude 根據審查進行改進。每個步驟都是一個單獨的 API 呼叫，因此您可以在任何時刻記錄、評估或分支。

減少代理編碼中的檔案建立

Claude 的最新模型有時可能會為測試和迭代目的建立新檔案，特別是在處理代碼時。此方法允許 Claude 在保存最終輸出之前使用檔案（特別是 python 腳本）作為「臨時草稿紙」。使用臨時檔案可以改善結果，特別是對於代理編碼用例。

如果您更傾向於最小化淨新檔案建立，您可以指示 Claude 在完成後清理：

如果您建立任何臨時新檔案、腳本或幫助檔案用於迭代，請在任務結束時通過刪除它們來清理這些檔案。

過度熱情

Claude Opus 4.5 和 Claude Opus 4.6 傾向於通過建立額外檔案、添加不必要的抽象或構建未請求的靈活性來過度設計。如果您看到此不需要的行為，請添加特定指導以保持解決方案最小。

例如：

避免過度設計。僅進行直接請求或明顯必要的更改。保持解決方案簡單和專注：

- 範圍：不要添加功能、重構代碼或進行超出要求的「改進」。錯誤修復不需要周圍代碼清理。簡單功能不需要額外的可配置性。

- 文檔：不要向您未更改的代碼添加文檔字符串、評論或類型註釋。僅在邏輯不明顯的地方添加評論。

- 防禦性編碼：不要為無法發生的情況添加錯誤處理、備選方案或驗證。信任內部代碼和框架保證。僅在系統邊界（用戶輸入、外部 API）驗證。

- 抽象：不要為一次性操作建立幫助程序、實用程序或抽象。不要為假設的未來要求設計。正確的複雜性量是當前任務所需的最小值。

避免專注於通過測試和硬編碼

Claude 有時可能會過度專注於通過測試，而犧牲更通用的解決方案，或可能使用幫助腳本等解決方法進行複雜重構，而不是直接使用標準工具。為了防止此行為並確保健壯、可推廣的解決方案：

請使用可用的標準工具編寫高品質、通用的解決方案。不要建立幫助腳本或解決方法來更有效地完成任務。實施適用於所有有效輸入的解決方案，而不僅僅是測試用例。不要硬編碼值或建立僅適用於特定測試輸入的解決方案。相反，實施實際解決問題的邏輯。

專注於理解問題要求並實施正確的算法。測試用於驗證正確性，而不是定義解決方案。提供遵循最佳實踐和軟體設計原則的有原則的實施。

如果任務不合理或不可行，或者任何測試不正確，請告訴我，而不是解決它們。解決方案應該是健壯的、可維護的和可擴展的。

最小化代理編碼中的幻覺

Claude 的最新模型不太容易出現幻覺，並根據代碼提供更準確、更有根據、更聰明的答案。為了進一步鼓勵此行為並最小化幻覺：

<investigate_before_answering>
切勿推測您未打開的代碼。如果用戶引用特定檔案，您必須在回答前讀取該檔案。確保在回答有關代碼庫的問題之前進行調查和讀取相關檔案。除非您確定正確答案，否則不要在調查前對代碼進行任何聲明 - 提供有根據和無幻覺的答案。
</investigate_before_answering>

功能特定提示

改進的視覺功能

Claude Opus 4.5 和 Claude Opus 4.6 與以前的 Claude 模型相比具有改進的視覺功能。它們在圖像處理和數據提取任務上表現更好，特別是當上下文中存在多個圖像時。這些改進延伸到電腦使用，其中模型可以更可靠地解釋屏幕截圖和 UI 元素。您也可以通過將視頻分解為幀來使用這些模型分析視頻。

已證明有效進一步提升效能的一種技術是為 Claude 提供裁剪工具或 skill。測試表明，當 Claude 能夠「放大」圖像的相關區域時，圖像評估會有一致的提升。Anthropic 為裁剪工具建立了 cookbook。

前端設計

Claude Opus 4.5 和 Claude Opus 4.6 在構建複雜、真實世界的 Web 應用程式和強大的前端設計方面表現出色。但是，在沒有指導的情況下，模型可能會默認為通用模式，創建用戶稱之為「AI slop」美學的內容。為了創建獨特、創意的前端，令人驚喜和愉悅：

以下是您可以使用的系統提示片段，以鼓勵更好的前端設計：

<frontend_aesthetics>
您傾向於收斂到通用的「分佈上」輸出。在前端設計中，這會創建用戶稱之為「AI slop」美學的內容。避免這種情況：製作創意、獨特的前端，令人驚喜和愉悅。

專注於：
- 排版：選擇美麗、獨特和有趣的字體。避免使用 Arial 和 Inter 等通用字體；改為選擇提升前端美學的獨特選擇。
- 顏色和主題：致力於一致的美學。使用 CSS 變數以保持一致性。主色調配以銳利口音優於膽怯、均勻分佈的調色板。從 IDE 主題和文化美學中汲取靈感。
- 動作：使用動畫進行效果和微交互。優先考慮 HTML 的純 CSS 解決方案。在可用時為 React 使用 Motion 庫。專注於高影響時刻：一個精心編排的頁面加載，帶有交錯顯示（animation-delay）會比分散的微交互創造更多喜悅。
- 背景：創建氛圍和深度，而不是默認為純色。分層 CSS 漸變、使用幾何圖案或添加與整體美學相匹配的上下文效果。

避免通用 AI 生成的美學：
- 過度使用的字體系列（Inter、Roboto、Arial、系統字體）
- 陳詞濫調的配色方案（特別是白色背景上的紫色漸變）
- 可預測的佈局和組件模式
- 缺乏上下文特定特性的千篇一律設計

創意解釋並做出對上下文感覺真正設計的意外選擇。在淺色和深色主題、不同字體、不同美學之間變化。您仍然傾向於跨代收斂到常見選擇（例如 Space Grotesk）。避免這種情況：批判性思考超出框框是至關重要的！
</frontend_aesthetics>

您也可以參考 完整技能定義。

遷移考慮

從早期代代遷移到 Claude 4.6 模型時：

1. 對所需行為要具體：考慮描述您希望在輸出中看到的確切內容。

2. 用修飾符框架化您的指示：添加鼓勵 Claude 提高輸出品質和詳細程度的修飾符可以幫助更好地塑造 Claude 的效能。例如，不要說「建立分析儀表板」，而是使用「建立分析儀表板。包括盡可能多的相關功能和交互。超越基礎知識以建立功能完整的實施。」

3. 明確請求特定功能：當需要時，應明確請求動畫和互動元素。

4. 更新思考配置：Claude 4.6 模型使用 adaptive thinking（thinking: {type: "adaptive"}）而不是帶有 budget_tokens 的手動思考。使用 effort 參數 來控制思考深度。

5. 從預填充回應遷移：從 Claude 4.6 模型開始，最後一個助手轉向的預填充回應已被棄用。有關替代方案的詳細指導，請參閱 從預填充回應遷移。

6. 調整反懶惰提示：如果您的提示之前鼓勵該模型更加徹底或更積極地使用工具，請減少該指導。Claude 4.6 模型明顯更主動，可能會在以前模型所需的指示上過度觸發。

有關詳細的遷移步驟，請參閱 遷移指南。

從 Claude Sonnet 4.5 遷移到 Claude Sonnet 4.6

Claude Sonnet 4.6 預設為 high 的 effort 級別，與沒有 effort 參數的 Claude Sonnet 4.5 相反。在從 Claude Sonnet 4.5 遷移到 Claude Sonnet 4.6 時，考慮調整 effort 參數。如果未明確設置，您可能會在預設 effort 級別遇到更高的延遲。

建議的 effort 設定：

• Medium 用於大多數應用程式
• Low 用於高容量或延遲敏感的工作負載
• 在中等或高 effort 下設置大型最大輸出令牌預算（建議 64k 令牌）以給模型思考和行動的空間

何時改用 Opus 4.7： 對於最難、最長期的問題（大規模代碼遷移、深度研究、擴展自主工作），Opus 4.7 仍然是正確的選擇。Sonnet 4.6 針對快速周轉和成本效率最重要的工作負載進行了優化。

如果您未使用擴展思考

如果您在 Claude Sonnet 4.5 上未使用擴展思考，您可以在 Claude Sonnet 4.6 上繼續不使用它。您應該明確設置 effort 為適合您的使用情況的級別。在禁用思考的 low effort 下，您可以期望相對於沒有擴展思考的 Claude Sonnet 4.5 有相似或更好的效能。

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8192,
    thinking={"type": "disabled"},
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "..."}],
)

如果您使用擴展思考

如果您在 Claude Sonnet 4.5 上使用帶有 budget_tokens 的擴展思考，它在 Claude Sonnet 4.6 上仍然有效，但已被棄用。遷移到 adaptive thinking 與 effort 參數。

遷移到 adaptive thinking

Adaptive thinking 特別適合以下工作負載模式：

• 自主多步代理： 將要求轉化為工作軟體的編碼代理、數據分析管道和錯誤查找，其中模型在許多步驟中獨立運行。Adaptive thinking 讓模型為每個步驟校準其推理，在更長的軌跡上保持路線。對於這些工作負載，從 high effort 開始。如果延遲或令牌使用是一個問題，縮減到 medium。
• 電腦使用代理： Claude Sonnet 4.6 在使用 adaptive 模式的電腦使用評估中達到了同類最佳的準確性。
• 雙模式工作負載： 簡單和困難任務的混合，其中 adaptive 在簡單查詢上跳過思考，在複雜查詢上深度推理。

使用 adaptive thinking 時，在您的任務上評估 medium 和 high effort。正確的級別取決於您的工作負載在品質、延遲和令牌使用之間的權衡。

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

在遷移期間保留 budget_tokens

如果您在遷移時需要暫時保留 budget_tokens，大約 16k 令牌的預算為更難的問題提供了空間，而不會出現失控令牌使用的風險。此配置已被棄用，將在未來的模型版本中移除。

對於編碼用例（代理編碼、工具繁重的工作流程、代碼生成），從 medium effort 開始：

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=16384,
    thinking={"type": "enabled", "budget_tokens": 16384},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "..."}],
)

對於聊天和非編碼用例（聊天、內容生成、搜尋、分類），從 low effort 開始：

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8192,
    thinking={"type": "enabled", "budget_tokens": 16384},
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "..."}],
)

提供驗證工具：隨著自主任務長度的增加，Claude 需要在沒有持續人工反饋的情況下驗證正確性。Playwright MCP 伺服器或用於測試 UI 的電腦使用功能等工具很有幫助。