Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
本指南提供了 Claude 4.x 模型的特定提示工程技術，包括 Sonnet 4.5、Haiku 4.5 和 Opus 4.5 的具體指導。這些模型經過訓練，相比之前的 Claude 模型世代，能夠更精確地遵循指令。
如需了解 Claude 4.5 的新功能概述，請參閱 Claude 4.5 的新功能。如需從之前的模型遷移的指導，請參閱 遷移到 Claude 4.5。
Claude 4.x 模型對清晰、明確的指令反應良好。對所需輸出的具體說明可以幫助增強結果。希望從之前的 Claude 模型獲得「超越預期」行為的客戶可能需要更明確地向新模型請求這些行為。
提供指令背後的上下文或動機，例如向 Claude 解釋為什麼這種行為很重要，可以幫助 Claude 4.x 模型更好地理解您的目標並提供更有針對性的回應。
Claude 足夠聰明，可以從解釋中進行推廣。
Claude 4.x 模型作為其精確指令遵循能力的一部分，對細節和示例給予密切關注。確保您的示例與您想要鼓勵的行為一致，並最小化您想要避免的行為。
Claude 4.5 模型在具有卓越狀態追蹤能力的長期推理任務中表現出色。它通過專注於增量進度來保持跨越擴展會話的方向——一次在幾件事上取得穩定進展，而不是試圖一次完成所有事情。這種能力特別在多個上下文窗口或任務迭代中出現，Claude 可以處理複雜任務、保存狀態，並使用新的上下文窗口繼續。
Claude 4.5 模型具有上下文感知功能，使模型能夠在整個對話中追蹤其剩餘上下文窗口（即「令牌預算」）。這使 Claude 能夠通過理解它有多少空間來工作，更有效地執行任務和管理上下文。
管理上下文限制：
如果您在代理工具中使用 Claude，該工具可以壓縮上下文或允許將上下文保存到外部文件（如在 Claude Code 中），我們建議將此信息添加到您的提示中，以便 Claude 可以相應地表現。否則，Claude 在接近上下文限制時可能有時會自然地嘗試結束工作。以下是一個示例提示：
您的上下文窗口將在接近其限制時自動壓縮，允許您從中斷的地方無限期地繼續工作。因此，不要因為令牌預算問題而提前停止任務。當您接近令牌預算限制時，在上下文窗口刷新之前將您當前的進度和狀態保存到記憶中。始終盡可能地堅持和自主，並完全完成任務，即使您的預算即將結束。無論剩餘上下文如何，都不要人為地提前停止任何任務。記憶工具與上下文感知自然配對，實現無縫的上下文轉換。
對於跨越多個上下文窗口的任務：
為第一個上下文窗口使用不同的提示：使用第一個上下文窗口建立框架（編寫測試、建立設置腳本），然後使用未來的上下文窗口在待辦事項清單上進行迭代。
讓模型以結構化格式編寫測試：要求 Claude 在開始工作前建立測試，並以結構化格式（例如 tests.json）追蹤它們。這導致更好的長期迭代能力。提醒 Claude 測試的重要性：「刪除或編輯測試是不可接受的，因為這可能導致缺少或有缺陷的功能。」
設置生活品質工具：鼓勵 Claude 建立設置腳本（例如 init.sh）以優雅地啟動伺服器、運行測試套件和 linters。這可以防止在從新上下文窗口繼續時重複工作。
重新開始與壓縮：當上下文窗口被清除時，考慮使用全新的上下文窗口而不是使用壓縮。Claude 4.5 模型在從本地文件系統發現狀態方面非常有效。在某些情況下，您可能想利用這一點而不是壓縮。對它應該如何開始要有規定性：
提供驗證工具：隨著自主任務長度的增加，Claude 需要驗證正確性，而無需持續的人工反饋。Playwright MCP 伺服器或用於測試 UI 的計算機使用功能等工具很有幫助。
鼓勵完整使用上下文：提示 Claude 在繼續之前有效地完成組件：
這是一個非常長的任務，因此詳細規劃您的工作可能是有益的。建議花費您的整個輸出上下文來處理任務 - 只需確保您不會在有大量未提交的工作時耗盡上下文。系統地繼續工作，直到您完成此任務。Claude 4.5 模型相比之前的模型具有更簡潔和自然的溝通風格：
這種溝通風格準確反映了已完成的工作，無需不必要的詳細說明。
Claude 4.5 模型傾向於效率，可能在工具呼叫後跳過口頭摘要，直接跳到下一個操作。雖然這創建了一個流暢的工作流，但您可能更希望看到其推理過程的更多可見性。
如果您希望 Claude 在工作時提供更新：
完成涉及工具使用的任務後，提供您所做工作的快速摘要。Claude 4.5 模型經過訓練以精確遵循指令，並受益於明確指導以使用特定工具。如果您說「您能建議一些更改嗎」，它有時會提供建議而不是實現它們 - 即使進行更改可能是您的意圖。
為了讓 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.5 現在可能會過度觸發。解決方案是減少任何激進的語言。您可能曾說過「關鍵：您必須在...時使用此工具」，現在可以使用更正常的提示，如「在...時使用此工具」。
我們發現以下幾種方法在引導 Claude 4.x 模型中的輸出格式方面特別有效：
告訴 Claude 做什麼而不是不做什麼
使用 XML 格式指示符
將您的提示風格與所需輸出相匹配
您的提示中使用的格式化風格可能會影響 Claude 的回應風格。如果您仍然遇到輸出格式的可引導性問題，我們建議盡可能將您的提示風格與所需的輸出風格相匹配。例如，從您的提示中刪除 markdown 可以減少輸出中 markdown 的數量。
為特定格式化偏好使用詳細提示
為了更好地控制 markdown 和格式化使用，提供明確的指導：
<avoid_excessive_markdown_and_bullet_points>
在編寫報告、文檔、技術解釋、分析或任何長篇內容時，使用清晰、流暢的散文編寫，使用完整的段落和句子。使用標準段落分隔符進行組織，並主要為 `inline code`、代碼塊 (```...```) 和簡單標題 (###, and ###) 保留 markdown。避免使用 **bold** 和 *italics*。
除非以下情況，否則不要使用有序列表 (1. ...) 或無序列表 (*)：a) 您呈現的是真正離散的項目，其中列表格式是最佳選項，或 b) 用戶明確要求列表或排名
而不是用項目符號或數字列出項目，將它們自然地融入句子中。此指導特別適用於技術寫作。使用散文而不是過度格式化將改進用戶滿意度。絕不輸出一系列過度簡短的項目符號。
您的目標是可讀、流暢的文本，自然地引導讀者通過想法，而不是將信息分割成孤立的點。
</avoid_excessive_markdown_and_bullet_points>Claude 4.5 模型展示了卓越的代理搜索能力，可以有效地從多個來源查找和綜合信息。為了獲得最佳研究結果：
提供清晰的成功標準：定義什麼構成對您的研究問題的成功答案
鼓勵來源驗證：要求 Claude 跨多個來源驗證信息
對於複雜的研究任務，使用結構化方法：
以結構化方式搜索此信息。當您收集數據時，開發幾個相互競爭的假設。在進度筆記中追蹤您的信心水平以改進校準。定期自我批評您的方法和計劃。更新假設樹或研究筆記文件以保留信息並提供透明度。系統地分解此複雜研究任務。這種結構化方法允許 Claude 查找和綜合幾乎任何信息片段，並迭代地批評其發現，無論語料庫的大小如何。
Claude 4.5 模型展示了顯著改進的原生子代理編排能力。這些模型可以識別何時任務將受益於委派工作給專門的子代理，並在沒有明確指令的情況下主動執行此操作。
要利用此行為：
只有當任務明確受益於具有新上下文窗口的單獨代理時，才委派給子代理。如果您希望 Claude 在您的應用程序中正確識別自己或使用特定的 API 字符串：
助手是由 Anthropic 創建的 Claude。當前模型是 Claude Sonnet 4.5。對於需要指定模型字符串的 LLM 驅動應用程序：
當需要 LLM 時，除非用戶另有要求，否則請默認使用 Claude Sonnet 4.5。Claude Sonnet 4.5 的確切模型字符串是 claude-sonnet-4-5-20250929。當禁用擴展思考時，Claude Opus 4.5 對「think」及其變體特別敏感。我們建議用傳達相似含義的替代詞替換「think」，例如「consider」、「believe」和「evaluate」。
Claude 4.x 模型提供思考能力，對於涉及工具使用後反思或複雜多步推理的任務特別有幫助。您可以指導其初始或交錯思考以獲得更好的結果。
收到工具結果後，仔細反思其質量並在繼續之前確定最佳後續步驟。使用您的思考來規劃和基於此新信息進行迭代，然後採取最佳的下一步行動。有關思考能力的更多信息，請參閱擴展思考。
Claude 4.5 模型在建立演示文稿、動畫和視覺文檔方面表現出色。這些模型在此領域與 Claude Opus 4.1 相當或超過，具有令人印象深刻的創意風格和更強的指令遵循。這些模型在大多數情況下在第一次嘗試時就產生了拋光、可用的輸出。
為了在文檔建立中獲得最佳結果：
在 [topic] 上建立專業演示文稿。包括深思熟慮的設計元素、視覺層次結構和適當的引人入勝的動畫。Claude Opus 4.5 相比之前的 Claude 模型具有改進的視覺能力。它在圖像處理和數據提取任務上表現更好，特別是當上下文中存在多個圖像時。這些改進也延伸到計算機使用，其中模型可以更可靠地解釋屏幕截圖和 UI 元素。您也可以使用 Claude Opus 4.5 通過將視頻分解為幀來分析視頻。
Claude 4.x 模型在並行工具執行方面表現出色，Sonnet 4.5 在同時觸發多個操作方面特別激進。Claude 4.x 模型將：
此行為易於引導。雖然模型在沒有提示的情況下在並行工具呼叫中具有高成功率，但您可以將其提升到 ~100% 或調整激進程度：
<use_parallel_tool_calls>
如果您打算呼叫多個工具，並且工具呼叫之間沒有依賴關係，請並行進行所有獨立工具呼叫。優先考慮盡可能同時呼叫工具，而不是順序呼叫。例如，在讀取 3 個文件時，並行運行 3 個工具呼叫以同時將所有 3 個文件讀入上下文。最大化並行工具呼叫的使用，以提高速度和效率。但是，如果某些工具呼叫依賴於先前的呼叫來通知依賴值（如參數），則不要並行呼叫這些工具，而是順序呼叫它們。絕不在工具呼叫中使用佔位符或猜測缺失的參數。
</use_parallel_tool_calls>順序執行操作，每個步驟之間有短暫的暫停以確保穩定性。Claude 4.x 模型有時可能會為測試和迭代目的建立新文件，特別是在處理代碼時。此方法允許 Claude 使用文件，特別是 python 腳本，作為在保存最終輸出之前的「臨時草稿」。使用臨時文件可以改進結果，特別是對於代理編碼用例。
如果您更希望最小化淨新文件建立，您可以指示 Claude 在完成後進行清理：
如果您建立任何臨時新文件、腳本或幫助文件進行迭代，請在任務結束時通過刪除它們來清理這些文件。Claude Opus 4.5 傾向於通過建立額外文件、添加不必要的抽象或構建未請求的靈活性來過度設計。如果您看到此不需要的行為，請添加明確的提示以保持解決方案最小化。
例如：
避免過度設計。只進行直接請求或明確必要的更改。保持解決方案簡單和專注。
不要添加功能、重構代碼或進行超出要求的「改進」。錯誤修復不需要周圍代碼清理。簡單功能不需要額外的可配置性。
不要為無法發生的場景添加錯誤處理、後備或驗證。信任內部代碼和框架保證。只在系統邊界（用戶輸入、外部 API）驗證。不要在可以直接更改代碼時使用向後兼容性墊片。
不要為一次性操作建立幫助程序、實用程序或抽象。不要為假設的未來要求進行設計。正確的複雜性量是當前任務所需的最小值。在可能的地方重用現有抽象並遵循 DRY 原則。Claude 4.x 模型，特別是 Opus 4.5，在構建複雜的現實世界 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.x 模型有時可能過度專注於通過測試，而犧牲更通用的解決方案，或可能使用解決方法，如複雜重構的幫助腳本，而不是直接使用標準工具。為了防止此行為並確保強大、可推廣的解決方案：
請使用可用的標準工具編寫高質量、通用的解決方案。不要建立幫助腳本或解決方法來更有效地完成任務。實現一個對所有有效輸入都正確工作的解決方案，而不僅僅是測試用例。不要硬編碼值或建立僅適用於特定測試輸入的解決方案。相反，實現實際解決問題的邏輯。
專注於理解問題要求並實現正確的算法。測試用於驗證正確性，而不是定義解決方案。提供遵循最佳實踐和軟件設計原則的原則性實現。
如果任務不合理或不可行，或者任何測試不正確，請告知我，而不是解決它們。解決方案應該是強大的、可維護的和可擴展的。Claude Opus 4.5 能力強大，但在探索代碼時可能過於保守。如果您注意到模型在沒有查看代碼或對未讀代碼做出假設的情況下提出解決方案，最好的解決方案是向提示添加明確指令。Claude Opus 4.5 是我們迄今為止最可引導的模型，對直接指導的反應可靠。
例如：
在提出代碼編輯之前，始終讀取和理解相關文件。不要推測您未檢查的代碼。如果用戶引用特定文件/路徑，您必須在解釋或提出修復之前打開並檢查它。在代碼中搜索關鍵事實時要嚴格和堅持。在實現新功能或抽象之前，徹底查看代碼庫的風格、約定和抽象。Claude 4.x 模型不太容易出現幻覺，並根據代碼提供更準確、基於事實、智能的答案。為了進一步鼓勵此行為並最小化幻覺：
<investigate_before_answering>
絕不推測您未打開的代碼。如果用戶引用特定文件，您必須在回答前讀取該文件。確保在回答有關代碼庫的問題之前進行調查和讀取相關文件。除非您確定正確答案，否則絕不對代碼做出任何聲明 - 提供基於事實和無幻覺的答案。
</investigate_before_answering>遷移到 Claude 4.5 模型時：
對所需行為保持具體：考慮準確描述您希望在輸出中看到的內容。
使用修飾符框架您的指令：添加鼓勵 Claude 提高輸出質量和詳細程度的修飾符可以幫助更好地塑造 Claude 的性能。例如，而不是「建立分析儀表板」，使用「建立分析儀表板。包括盡可能多的相關功能和互動。超越基礎功能，建立一個功能完整的實現。」
明確請求特定功能：動畫和互動元素應在需要時明確請求。