為 Claude Sonnet 5 撰寫提示

本指南涵蓋 Claude Sonnet 5 特有的提示模式。關於模型的功能與 API 變更，請參閱 Claude Sonnet 5 的新功能。關於適用於所有現行 Claude 模型的技巧，請參閱提示最佳實踐。

Claude Sonnet 5 在程式編寫和代理任務方面具有特別的優勢。它在現有的 Claude Sonnet 4.6 提示上開箱即用就有良好表現。本指南中的模式涵蓋最常需要調整的行為。



回應長度與冗長程度

Claude Sonnet 5 會根據任務的複雜度校準回應長度，而不是預設為固定的冗長程度。這通常意味著對簡單查詢給出較短的答案，對開放式分析給出較長的答案。

如果您的產品依賴特定風格或冗長程度的輸出，您可能需要調整您的提示。舉例來說，若要降低冗長程度，您可以加入：

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

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



校準 effort 與思考深度

effort 參數讓您可以在 Claude 的智慧與 token 花費之間進行調整，以能力換取更快的速度和更低的成本。在 Claude Sonnet 5 上，effort 預設為 high，與 Claude Sonnet 4.6 相同。對於最困難的程式編寫和代理任務，請將 effort 提高到 xhigh。嘗試其他 effort 等級以進一步調整 token 使用量和智慧：

• max： 絕對最大能力，對 token 花費沒有任何限制。
• xhigh： 超高 effort 是最困難的程式編寫和代理使用案例的建議設定。
• high： 預設值。此設定在大多數使用案例中平衡 token 使用量和智慧。
• medium： 適合需要減少 token 使用量並以智慧作為交換的成本敏感使用案例。
• low： 保留給簡短、範圍明確的任務，以及對延遲敏感但對智慧不敏感的工作負載。

作為遷移時的粗略跨模型對應：Claude Sonnet 5 的 medium 在智慧上與 Claude Sonnet 4.6 的 high 相當，而 Claude Sonnet 5 的 high 與 Claude Sonnet 4.6 的 max 相當。進行基準測試時，請依觀察到的思考長度而非 effort 名稱來匹配。

Claude Sonnet 5 嚴格遵守 effort 等級，尤其是在低端。在 low 和 medium 時，模型會將其工作範圍限定在被要求的內容，而不是超出預期。這對延遲和成本有利，但在以 low effort 執行中等複雜度的任務時，存在思考不足的風險。

如果您在複雜問題上觀察到淺層推理，請將 effort 提高到 high 或 xhigh，而不是透過提示來繞過它。如果您因延遲需要將 effort 保持在 low，請加入有針對性的指引：

This task involves multi-step reasoning. Think carefully through the problem before responding.

在 Claude Sonnet 5 上，自適應思考預設為開啟。沒有 thinking 欄位的請求會以自適應思考執行。這與 Claude Sonnet 4.6 不同，在 Claude Sonnet 4.6 上相同的請求會在沒有思考的情況下執行。若要完全關閉思考，請傳入 thinking: {type: "disabled"}。由於 max_tokens 是總輸出（思考加上回應文字）的硬性限制，請針對在 Claude Sonnet 4.6 上沒有思考就執行的工作負載重新檢視此值。如果您先前在 Claude Sonnet 4.6 上使用關閉思考的設定，請嘗試在 Claude Sonnet 5 上開啟思考並搭配較低的 effort 等級。

自適應思考的觸發行為是可引導的。如果您發現模型發出思考區塊的頻率比您希望的更高（這可能發生在大型或複雜的系統提示中），請加入指引來引導它。一如既往，請衡量任何提示變更對效能的影響。範例：

Thinking adds latency and should only be used when it will meaningfully improve answer quality, typically for problems that require multi-step reasoning. When in doubt, respond directly.

相反地，如果您以 medium 執行困難的工作負載並看到思考不足，第一個調整手段是提高 effort。如果您需要更精細的控制，請直接在提示中說明。

手動擴展思考（thinking: {type: "enabled", budget_tokens: N}）在 Claude Sonnet 5 上不受支援，並會回傳 400 錯誤。它在 Claude Sonnet 4.6 上已被棄用，現在已被移除。請改用自適應思考搭配 effort 參數。



工具使用觸發

Claude Sonnet 5 預設比 Claude Sonnet 4.6 更具代理性，會更主動地使用工具並執行自我驗證迴圈。在停用思考的情況下，模型較不可能使用工具或考慮搜尋；如果您在關閉思考的情況下依賴工具呼叫，請在系統提示中加入明確的提醒。effort 也是工具使用的調整手段：high 或 xhigh effort 設定在代理搜尋和程式編寫中顯示出明顯更多的工具使用。對於您希望有更多工具使用的情境，您也可以調整提示，明確指示模型何時以及如何正確使用其工具。例如，如果您發現模型沒有使用您的網路搜尋工具，請清楚描述它為什麼以及應該如何使用。



面向使用者的進度更新

Claude Sonnet 5 在長時間的代理執行過程中會向使用者提供定期、更高品質的更新。如果您已加入強制產生中間狀態訊息的鷹架（「每 3 次工具呼叫後，總結進度」），請嘗試移除它。如果您發現 Claude Sonnet 5 面向使用者的更新長度或內容與您的使用案例不夠契合，請在提示中明確描述這些更新應該是什麼樣子並提供範例。



更字面的指令遵循

Claude Sonnet 5 會字面且明確地解讀提示，尤其是在較低的 effort 等級。它不會默默地將一個項目的指令推廣到另一個項目，也不會推斷您沒有提出的請求。這種字面性的好處是精確性，對於具有精心調整的提示、結構化擷取，以及需要可預測行為的管線等 API 使用案例，它通常表現更好。如果您需要 Claude 廣泛套用某個指令，請明確說明範圍（例如，「將此格式套用到每個章節，而不只是第一個」）。



語氣與寫作風格

與任何新模型一樣，長篇寫作的文體風格可能會有所改變。如果您的產品依賴特定的語調，請針對新的基準重新評估風格提示。

例如，如果您的產品語調更溫暖或更口語化，請加入：

Use a warm, collaborative tone. Acknowledge the user's framing before answering.

如果您先前依賴 temperature 來獲得風格多樣性，請注意在 Claude Sonnet 5 上將 temperature、top_p 或 top_k 設定為非預設值會回傳 400 錯誤。此限制對 Sonnet 級別的模型來說是新的。遷移時請移除這些參數，並改用系統提示指令來引導語氣和多樣性。



設計與前端預設值

Claude Sonnet 5 在開放式的前端和設計需求上可能會固定在一致的預設視覺風格。預設的固有風格對某些需求來說可能看起來不錯，但對儀表板、開發工具、金融科技、醫療保健或企業應用程式來說可能感覺不對。

通用的指示（「不要使用那個顏色」、「讓它乾淨簡約」）往往會讓模型轉向另一個固定的調色盤，而不是產生多樣性。有兩種方法可以可靠地發揮作用：

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

Design a desktop landing page for a supplement brand called AEFRM.

The visual direction should come from a cold monochrome atmosphere using pale silver-gray tones that gradually deepen into blue-gray and near-black, similar to a misted metallic surface.

The page should feel sharp and controlled, with a strong sense of structure and restraint.

Use this tonal system across the full page instead of introducing bright accent colors.

Use the uploaded image on the hero design in black and white.

The layout should be built with clear horizontal sections and a centered max-width container. Use 4px corner radius consistently across cards, buttons, inputs, and media frames. Margins should feel generous, with enough empty space around each section so the page breathes.

Typography should use a square, angular sans-serif with wider letter spacing than usual, especially in headings and navigation, so the text feels more engineered and less compressed. Headline text can be large and uppercase, while supporting copy remains short and sparse. The sub texts should be written with Alumni Sans SC in 4-6px like tiny little texts on corners bottom centre like that.

For the structure, start with a hero section containing a strong product statement, one short supporting paragraph, and a clean product placeholder or packshot frame. Below that, add a benefit grid with three or four blocks, then a formulation or ingredients section, and finally a cta.

Buttons should be flat and precise, with subtle hover changes using transition: all 160ms ease out where brightness and border contrast shift slightly rather than using dramatic motion.

Color palette should stay within this range:
#E9ECEC, #C9D2D4, #8C9A9E, #44545B, #11171B.

2. 讓模型在建構之前提出選項。 這會打破預設值並讓使用者掌控。由於 Claude Sonnet 5 不接受 temperature，此方法是在多次執行中產生有意義差異的設計方向的建議方式。範例提示：

Before building, propose 4 distinct visual directions tailored to this brief (each as: bg hex / accent hex / typeface, plus a one-line rationale). Ask the user to pick one, then implement only that direction.

若要避開使用者稱為「AI slop」美學的通用模式，您可以在系統提示中加入簡短的指令。frontend-design skill 提供了更完整的處理方式，但這個片段與前述的多樣性方法搭配使用效果很好：

<frontend_aesthetics>
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white or dark backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character. Use unique fonts, cohesive colors and themes, and animations for effects and micro-interactions.
</frontend_aesthetics>



互動式程式編寫產品

在具有單一使用者回合的自主、非同步程式編寫代理，與具有多個使用者回合的互動式、同步程式編寫代理之間，token 使用量和行為可能有所不同。為了在程式編寫產品中最大化效能和 token 效率，請使用 xhigh 或 high effort，加入自動模式等自主功能，並減少使用者所需的人工互動次數。

在限制所需的使用者互動次數時，重要的是在第一個人類回合中預先指定任務、意圖和相關限制。預先提供明確、清晰且準確的任務描述，有助於最大化自主性和智慧，同時最小化使用者回合後的額外 token 使用量。相反地，透過多個使用者回合逐步傳達的模糊或規格不足的提示，往往會相對降低 token 效率，有時也會降低效能。



程式碼審查框架

如果您的程式碼審查框架是為較早的模型調整的，您最初可能會在 Claude Sonnet 5 上看到較低的召回率。這很可能是框架效應，而不是能力退化。當審查提示說「只回報高嚴重性問題」、「保持保守」或「不要吹毛求疵」之類的話時，Claude Sonnet 5 可能會比較早的模型更忠實地遵循該指令：它可能會同樣徹底地調查程式碼、識別錯誤，然後不回報它判斷低於您所述標準的發現。這可能表現為模型進行相同深度的調查，但將較少的調查轉化為回報的發現，尤其是在較低嚴重性的錯誤上。精確度通常會上升，但即使模型的底層錯誤發現能力已經提升，測得的召回率仍可能下降。

一些建議的提示用語：

Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

此提示可以在沒有實際第二步驟的情況下使用，但將信心過濾從發現步驟中移出通常會有幫助。如果您的框架有獨立的驗證、去重或排名階段，請明確告訴模型它在發現階段的工作是覆蓋率而不是過濾。

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

針對您的評估或測試案例的子集迭代提示，以驗證召回率或 F1 分數的提升。



電腦使用

Claude Sonnet 5 支援 computer_20251124 工具版本。電腦使用功能可在各種解析度下運作，最高解析度為 2576px / 3.75MP。內部電腦使用測試顯示，以 1080p 傳送影像可在效能和成本之間取得良好平衡。

對於特別注重成本的工作負載，720p 或 1366×768 是成本較低且效能強勁的選項。請進行您自己的測試，以找到適合您使用案例的理想設定；嘗試不同的 effort 設定也有助於調整模型的行為。