提示詞最佳實踐

本指南提供了 Claude 4.x 模型的特定提示詞工程技術，並針對 Sonnet 4.5 和 Haiku 4.5 提供了具體指導。這些模型經過訓練，相比之前的 Claude 模型世代，能夠更精確地遵循指令。

一般原則

明確說明您的指令

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 追蹤其進度並專注於增量工作

溝通風格

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 4.x 模型的輸出格式方面特別有效：

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

   • 不要說：「不要在您的回應中使用 markdown」
   • 試試：「您的回應應該由平順流暢的散文段落組成。」

2. 使用 XML 格式指示符

   • 試試：「在 <smoothly_flowing_prose_paragraphs> 標籤中編寫回應的散文部分。」

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

   您在提示詞中使用的格式化風格可能會影響 Claude 的回應風格。如果您仍然遇到輸出格式的可引導性問題，我們建議盡可能將您的提示詞風格與所需的輸出風格相匹配。例如，從提示詞中刪除 markdown 可以減少輸出中 markdown 的數量。

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

   為了更好地控制 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. 明確要求特定功能：當需要時應明確要求動畫和互動元素。