本指南提供了 Claude 4.x 模型的特定提示詞工程技術，並針對 Sonnet 4.5 和 Haiku 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 在接近上下文限制時可能有時會自然地嘗試結束工作。以下是一個範例提示詞：
範例提示詞
您的上下文視窗將在接近其限制時自動壓縮，允許您從中斷的地方無限期地繼續工作。因此，不要因為令牌預算問題而提前停止任務。當您接近令牌預算限制時，在上下文視窗刷新前將您的當前進度和狀態保存到記憶體。始終盡可能持久和自主，並完全完成任務，即使您的預算即將用完。無論剩餘上下文如何，絕不要人為地提前停止任何任務。
記憶體工具與上下文感知自然配對，實現無縫上下文轉換。

​
多上下文視窗工作流程

對於跨越多個上下文視窗的任務：
  1. 為第一個上下文視窗使用不同的提示詞：使用第一個上下文視窗建立框架（編寫測試、建立設定指令碼），然後使用未來的上下文視窗在待辦事項清單上進行迭代。
  2. 讓模型以結構化格式編寫測試：要求 Claude 在開始工作前建立測試，並以結構化格式（例如 tests.json）追蹤它們。這導致更好的長期迭代能力。提醒 Claude 測試的重要性：「刪除或編輯測試是不可接受的，因為這可能導致遺漏或有缺陷的功能。」
  3. 設定生活品質工具：鼓勵 Claude 建立設定指令碼（例如 init.sh）以優雅地啟動伺服器、運行測試套件和 linters。這可以防止從新的上下文視窗繼續時的重複工作。
  4. 重新開始與壓縮：當上下文視窗被清除時，考慮使用全新的上下文視窗而不是使用壓縮。Claude 4.5 模型在從本地檔案系統發現狀態方面非常有效。在某些情況下，您可能想利用這一點而不是壓縮。對其應該如何開始要有規範性：
    • 「呼叫 pwd；您只能在此目錄中讀取和寫入檔案。」
    • 「查看 progress.txt、tests.json 和 git 日誌。」
    • 「在繼續實現新功能之前，手動運行基本整合測試。」
  5. 提供驗證工具：隨著自主任務長度的增加，Claude 需要在沒有持續人工反饋的情況下驗證正確性。Playwright MCP 伺服器或用於測試 UI 的電腦使用功能等工具很有幫助。
  6. 鼓勵完整使用上下文：提示 Claude 在繼續之前有效地完成元件：
範例提示詞
這是一項非常長的任務，因此規劃您的工作可能會很有益。建議花費您的整個輸出上下文來處理任務 - 只需確保您不會在有重大未提交工作的情況下用完上下文。系統地繼續工作，直到您完成此任務。

​
狀態管理最佳實踐

  • 為狀態資料使用結構化格式：在追蹤結構化資訊（如測試結果或任務狀態）時，使用 JSON 或其他結構化格式來幫助 Claude 理解架構要求
  • 為進度筆記使用非結構化文字：自由格式的進度筆記適合追蹤一般進度和上下文
  • 使用 git 進行狀態追蹤：Git 提供了已完成工作的日誌和可以恢復的檢查點。Claude 4.5 模型在使用 git 跨多個會話追蹤狀態方面表現特別出色。
  • 強調增量進展：明確要求 Claude 追蹤其進度並專注於增量工作
// 結構化狀態檔案 (tests.json)
{
  "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.txt)
會話 3 進度：
- 修復了身份驗證令牌驗證
- 更新了使用者模型以處理邊界情況
- 下一步：調查 user_management 測試失敗（測試 #2）
- 注意：不要刪除測試，因為這可能導致遺漏功能

​
溝通風格

Claude 4.5 模型相比之前的模型具有更簡潔和自然的溝通風格：
  • 更直接和扎根：提供基於事實的進度報告，而不是自我慶祝的更新
  • 更對話式：略微更流暢和口語化，不那麼像機器
  • 不那麼冗長：除非另有提示，否則可能會跳過詳細摘要以提高效率
這種溝通風格準確反映了已完成的工作，無需不必要的詳細說明。

​
特定情況的指導

​
平衡冗長性

Claude 4.5 模型傾向於效率，可能在工具呼叫後跳過口頭摘要，直接跳到下一個操作。雖然這創建了簡化的工作流程，但您可能更希望看到其推理過程的可見性。 如果您希望 Claude 在工作時提供更新：
範例提示詞
完成涉及工具使用的任務後，提供您所做工作的快速摘要。

​
工具使用模式

Claude 4.5 模型經過訓練可以精確遵循指令，並受益於明確指導以使用特定工具。如果您說「您能建議一些更改嗎」，它有時會提供建議而不是實現它們——即使進行更改可能是您的意圖。 為了讓 Claude 採取行動，要更明確：
效果較差（Claude 只會建議）：
您能建議一些更改來改進此函數嗎？
效果更好（Claude 將進行更改）：
更改此函數以改進其效能。
或：
對身份驗證流程進行這些編輯。
為了讓 Claude 預設更主動地採取行動，您可以將此添加到您的系統提示詞中：
主動行動的範例提示詞
<default_to_action>
預設情況下，實現更改而不是只建議它們。如果使用者的意圖不清楚，推斷最有用的可能行動並繼續，使用工具發現任何遺漏的細節而不是猜測。嘗試推斷使用者關於是否打算進行工具呼叫（例如檔案編輯或讀取）的意圖，並相應地行動。
</default_to_action>
另一方面，如果您希望模型預設更猶豫，不太傾向於直接跳入實現，並且只在被要求時採取行動，您可以使用如下提示詞來引導此行為：
保守行動的範例提示詞
<do_not_act_before_instructions>
除非明確指示進行更改，否則不要跳入實現或更改檔案。當使用者的意圖不明確時，預設提供資訊、進行研究和提供建議，而不是採取行動。只有當使用者明確要求時，才能進行編輯、修改或實現。
</do_not_act_before_instructions>

​
控制回應格式

我們發現以下幾種方式在引導 Claude 4.x 模型的輸出格式方面特別有效：
  1. 告訴 Claude 要做什麼而不是不要做什麼
    • 不要說：「不要在您的回應中使用 markdown」
    • 試試：「您的回應應該由平順流暢的散文段落組成。」
  2. 使用 XML 格式指示符
    • 試試：「在 <smoothly_flowing_prose_paragraphs> 標籤中編寫回應的散文部分。」
  3. 將您的提示詞風格與所需輸出相匹配 您在提示詞中使用的格式化風格可能會影響 Claude 的回應風格。如果您仍然遇到輸出格式的可引導性問題，我們建議盡可能將您的提示詞風格與所需的輸出風格相匹配。例如，從提示詞中刪除 markdown 可以減少輸出中 markdown 的數量。
  4. 為特定格式設定偏好使用詳細提示詞 為了更好地控制 markdown 和格式設定使用，請提供明確的指導：
最小化 markdown 的範例提示詞
<avoid_excessive_markdown_and_bullet_points>
在編寫報告、文件、技術解釋、分析或任何長篇內容時，使用清晰、流暢的散文，使用完整的段落和句子。使用標準段落分隔符進行組織，並將 markdown 主要保留用於 `inline code`、程式碼區塊 (```...```) 和簡單標題 (###, and ###)。避免使用 **bold** 和 *italics*。

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

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

您的目標是可讀、流暢的文字，自然地引導讀者了解想法，而不是將資訊分割成孤立的點。
</avoid_excessive_markdown_and_bullet_points>

​
研究和資訊收集

Claude 4.5 模型展示了卓越的代理搜尋能力，可以有效地從多個來源查找和綜合資訊。為了獲得最佳研究結果：
  1. 提供清晰的成功標準：定義什麼構成對您的研究問題的成功答案
  2. 鼓勵來源驗證：要求 Claude 跨多個來源驗證資訊
  3. 對於複雜的研究任務，使用結構化方法：
複雜研究的範例提示詞
以結構化方式搜尋此資訊。當您收集資料時，開發多個相互競爭的假設。在進度筆記中追蹤您的信心水平以改進校準。定期自我批評您的方法和計畫。更新假設樹或研究筆記檔案以保留資訊並提供透明度。系統地分解此複雜研究任務。
這種結構化方法允許 Claude 查找和綜合幾乎任何資訊，無論語料庫的大小如何，並反覆批評其發現。

​
子代理編排

Claude 4.5 模型展示了顯著改進的原生子代理編排能力。這些模型可以識別何時任務將受益於委派工作給專門的子代理，並在沒有明確指令的情況下主動進行。 為了利用此行為：
  1. 確保定義明確的子代理工具：有可用的子代理工具並在工具定義中描述
  2. 讓 Claude 自然編排：Claude 將在沒有明確指令的情況下適當地委派
  3. 如果需要調整保守性：
保守子代理使用的範例提示詞
只有當任務明確受益於具有新上下文視窗的單獨代理時，才委派給子代理。

​
模型自我認知

如果您希望 Claude 在您的應用程式中正確識別自己或使用特定的 API 字串：
模型身份的範例提示詞
助手是由 Anthropic 建立的 Claude。當前模型是 Claude Sonnet 4.5。
對於需要指定模型字串的 LLM 驅動應用程式：
模型字串的範例提示詞
當需要 LLM 時，請預設為 Claude Sonnet 4.5，除非使用者另有要求。Claude Sonnet 4.5 的確切模型字串是 claude-sonnet-4-5-20250929。

​
利用思考和交錯思考能力

Claude 4.x 模型提供思考能力，對於涉及工具使用後反思或複雜多步推理的任務特別有幫助。您可以引導其初始或交錯思考以獲得更好的結果。
範例提示詞
收到工具結果後，仔細反思其品質並在繼續之前確定最佳後續步驟。使用您的思考來根據此新資訊進行規劃和迭代，然後採取最佳的下一步行動。
如需有關思考能力的更多資訊，請參閱延伸思考。

​
文件建立

Claude 4.5 模型在建立簡報、動畫和視覺文件方面表現出色。這些模型在此領域與 Claude Opus 4.1 相匹配或超過，具有令人印象深刻的創意風格和更強的指令遵循能力。這些模型在大多數情況下在第一次嘗試時就能產生精美、可用的輸出。 為了獲得文件建立的最佳結果：
範例提示詞
在 [主題] 上建立專業簡報。包含周到的設計元素、視覺層次結構和適當的引人入勝的動畫。

​
優化平行工具呼叫

Claude 4.x 模型在平行工具執行方面表現出色，Sonnet 4.5 在同時啟動多個操作方面特別積極。Claude 4.x 模型將：
  • 在研究期間運行多個推測搜尋
  • 一次讀取多個檔案以更快地建立上下文
  • 平行執行 bash 命令（甚至可能成為系統效能的瓶頸）
此行為易於引導。雖然模型在沒有提示的情況下在平行工具呼叫中具有高成功率，但您可以將其提升至 ~100% 或調整激進程度：
最大平行效率的範例提示詞
<use_parallel_tool_calls>
如果您打算呼叫多個工具，並且工具呼叫之間沒有依賴關係，請並行進行所有獨立工具呼叫。優先同時呼叫工具，而不是按順序進行，只要操作可以並行完成。例如，在讀取 3 個檔案時，並行運行 3 個工具呼叫以同時將所有 3 個檔案讀入上下文。在可能的地方最大化平行工具呼叫的使用以提高速度和效率。但是，如果某些工具呼叫依賴於先前的呼叫來通知依賴值（如參數），則不要並行呼叫這些工具，而是按順序呼叫它們。絕不要在工具呼叫中使用佔位符或猜測遺漏的參數。
</use_parallel_tool_calls>
減少平行執行的範例提示詞
按順序執行操作，每個步驟之間有簡短的暫停以確保穩定性。

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

Claude 4.x 模型有時可能會建立新檔案用於測試和迭代目的，特別是在處理程式碼時。此方法允許 Claude 使用檔案，特別是 python 指令碼，作為在保存最終輸出之前的「臨時草稿紙」。使用臨時檔案可以改進結果，特別是對於代理編碼使用情況。 如果您更希望最小化淨新檔案建立，您可以指示 Claude 在完成後進行清理：
範例提示詞
如果您建立任何臨時新檔案、指令碼或幫助檔案用於迭代，請通過在任務結束時刪除它們來清理這些檔案。

​
增強視覺和前端程式碼生成

Claude 4.x 模型可以生成高品質、視覺上獨特、功能性的使用者介面。但是，在沒有指導的情況下，前端程式碼可能會預設為缺乏視覺興趣的通用模式。為了引出卓越的 UI 結果：
  1. 提供明確的創意鼓勵：
範例提示詞
不要保留。盡力而為。建立一個令人印象深刻的演示，展示網頁開發能力。
  1. 指定美學方向和設計約束：
範例提示詞
使用深藍色和青色調色板、現代無襯線字體（例如，標題使用 Inter，正文使用系統字體）和帶有微妙陰影的卡片式佈局建立專業儀表板。包含周到的細節，如懸停狀態、轉換和微互動。應用設計原則：層次結構、對比、平衡和運動。
  1. 鼓勵設計多樣性和融合美學：
範例提示詞
提供多個設計選項。通過組合來自不同來源的元素來建立融合美學——一種色彩方案、不同的字體、另一種佈局原則。避免通用的居中佈局、簡單的漸變和統一的風格。
  1. 明確要求特定功能：
  • 「包含盡可能多的相關功能和互動」
  • 「添加動畫和互動元素」
  • 「建立超越基礎的完整功能實現」

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

Claude 4.x 模型有時可能過度專注於通過測試，犧牲更通用的解決方案，或可能使用解決方法（如用於複雜重構的幫助指令碼）而不是直接使用標準工具。為了防止此行為並確保健壯、可推廣的解決方案：
範例提示詞
請使用可用的標準工具編寫高品質、通用的解決方案。不要建立幫助指令碼或解決方法來更有效地完成任務。實現一個對所有有效輸入都正確工作的解決方案，而不僅僅是測試用例。不要硬編碼值或建立只適用於特定測試輸入的解決方案。相反，實現實際解決問題的邏輯。

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

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

​
最小化代理編碼中的幻覺

Claude 4.x 模型不太容易產生幻覺，並根據程式碼提供更準確、扎根、智能的答案。為了進一步鼓勵此行為並最小化幻覺：
範例提示詞
<investigate_before_answering>
絕不要推測您未打開的程式碼。如果使用者引用特定檔案，您必須在回答前讀取該檔案。在回答有關程式碼庫的問題前，請確保調查並讀取相關檔案。除非您確定正確答案，否則絕不要在調查前對程式碼進行任何聲明 - 提供扎根和無幻覺的答案。
</investigate_before_answering>

​
遷移考慮

遷移至 Claude 4.5 模型時：
  1. 對所需行為要具體：考慮準確描述您希望在輸出中看到的內容。
  2. 使用修飾符框架您的指令：添加鼓勵 Claude 提高輸出品質和細節的修飾符可以幫助更好地塑造 Claude 的效能。例如，不要說「建立分析儀表板」，而是使用「建立分析儀表板。包含盡可能多的相關功能和互動。超越基礎功能，建立完整功能的實現。」
  3. 明確要求特定功能：當需要時應明確要求動畫和互動元素。