提示詞工程最佳實踐

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

一般原則

清晰直接

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-6",
    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.6。

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

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

輸出和格式化

通訊風格和冗長度

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`、代碼塊 (```...```) 和簡單標題 (###, and ###) 保留 markdown。避免使用 **bold** 和 *italics*。

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

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

您的目標是可讀、流暢的文本，自然地引導讀者通過想法，而不是將資訊分割成孤立的點。
</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 設置以減少整體思考和令牌使用。

當您決定如何解決問題時，選擇一種方法並致力於它。除非您遇到直接與您的推理相矛盾的新資訊，否則避免重新審視決定。如果您在權衡兩種方法，請選擇一種並看到它的完成。如果選擇的方法失敗，您總是可以稍後進行課程更正。

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

利用思考和交錯思考功能

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

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

為需要代理行為的工作負載使用自適應思考，例如多步驟工具使用、複雜編碼任務和長期代理循環。較舊的模型使用帶有 budget_tokens 的手動思考模式。

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

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

自適應思考的觸發行為是可提示的。如果您發現模型思考的頻率超過您的喜好（這可能發生在大型或複雜的系統提示詞中），請添加指導來引導它：

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

如果您從帶有 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": "..."}],
)

之後（自適應思考）：

client.messages.create(
    model="claude-opus-4-6",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # or max, 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 調用更快且足夠時，模型可能會為代碼探索生成子代理。

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

當任務可以並行運行、需要隔離背景或涉及不需要共享狀態的獨立工作流時，使用子代理。對於簡單任務、順序操作、單文件編輯或需要在步驟中保持背景的任務，直接工作而不是委派。

鏈接複雜提示

透過自適應思考和子代理編排，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 Opus 4.5 和 Claude Opus 4.6 與之前的 Claude 模型相比具有改進的視覺功能。它們在圖像處理和數據提取任務上表現更好，特別是當上下文中存在多個圖像時。這些改進也適用於計算機使用，其中模型可以更可靠地解釋屏幕截圖和 UI 元素。您也可以使用這些模型通過將視頻分解為幀來分析視頻。

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

前端設計

Claude Opus 4.5 和 Claude Opus 4.6 擅長構建複雜的、真實世界的 Web 應用程序，具有強大的前端設計。但是，沒有指導的情況下，模型可能會默認為通用模式，創建用戶所說的「AI 垃圾」美學。為了創建獨特、創意的前端，令人驚喜和愉悅：

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

<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 4.6 模型時：

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

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

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

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

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

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

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

從 Claude Sonnet 4.5 遷移到 Claude Sonnet 4.6

Claude Sonnet 4.6 默認努力級別為 high，而 Claude Sonnet 4.5 沒有努力參數。在從 Claude Sonnet 4.5 遷移到 Claude Sonnet 4.6 時，請考慮調整努力參數。如果未明確設置，您可能會在默認努力級別下體驗更高的延遲。

推薦的努力設置：

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

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

如果您未使用擴展思考

如果您在 Claude Sonnet 4.5 上未使用擴展思考，您可以在 Claude Sonnet 4.6 上繼續不使用它。您應該明確設置努力級別以適合您的用例。在禁用思考的 low 努力下，您可以期望相對於沒有擴展思考的 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 上仍然可用但已被棄用。遷移到自適應思考與努力參數。

遷移到自適應思考

自適應思考特別適合以下工作負載模式：

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

使用自適應思考時，評估您的任務上的 medium 和 high 努力。正確的級別取決於您的工作負載在質量、延遲和令牌使用之間的權衡。

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 努力開始：

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 努力開始：

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 的計算機使用功能等工具很有幫助。