---
title: 提示 Claude Opus 4.8
url: https://platform.claude.com/docs/zh-TW/build-with-claude/prompt-engineering/prompting-claude-opus-4-8
description: Claude Opus 4.8 的行為差異與提示模式，涵蓋冗長度、努力程度校準、工具使用、子代理以及前端預設值。
---

本指南涵蓋 Claude Opus 4.8 特有的提示模式。關於從 Claude Opus 4.8 遷移至 Claude Opus 5.5 所涉及的 API 變更，請參閱[從 Claude Opus 4.8 遷移至 Claude Opus 5.5](https://platform.claude.com/docs/zh-TW/models/opus-5-5/migration-guide#migrating-from-claude-opus-4-8)。關於適用於所有現行 Claude 模型的技巧，請參閱[提示最佳實踐](https://platform.claude.com/docs/zh-TW/build-with-claude/prompt-engineering/claude-prompting-best-practices)。

Claude Opus 4.8 在長時程代理工作、知識工作、視覺以及記憶任務方面具有特別的優勢。它在現有的 Claude Opus 4.7 提示上開箱即可表現良好。以下模式涵蓋最常需要調整的行為。

<Note>
  關於自 Claude Opus 4.7 以來的 API 參數變更（預設 1M「context window」（上下文視窗）以及對話中途的系統訊息），請參閱[從 Claude Opus 4.7 遷移至 Claude Opus 5.5](https://platform.claude.com/docs/zh-TW/models/opus-5-5/migration-guide#migrating-from-claude-opus-47)，該文件涵蓋了遷移至 Claude Opus 5.5 過程中的相同變更；Claude Opus 4.8 也具有這些行為。
</Note>

## 回應長度與冗長度

Claude Opus 4.8 會根據其對任務複雜度的估計來校準回應長度，而不是預設採用固定的冗長程度。這通常意味著簡單查詢的回答較短，而開放式分析的回答則長得多。

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

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

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

## 校準努力程度與思考深度

[effort 參數](https://platform.claude.com/docs/zh-TW/build-with-claude/effort)讓您能夠在 Claude 的智慧與 token 花費之間進行調整，以能力換取更快的速度與更低的成本。對於程式編寫與代理使用情境，請從 `xhigh` 努力程度開始；對於大多數對智慧敏感的使用情境，請至少使用 `high` 努力程度。請嘗試其他努力程度，以進一步調整 token 用量與智慧：

* **`max`：** Max effort 在某些使用情境中可以帶來效能提升，但增加的 token 用量可能呈現報酬遞減。此設定有時也容易過度思考。請針對需要高度智慧的任務測試 max effort。
* **`xhigh`：** 超高努力程度是大多數程式編寫與代理使用情境的最佳設定。
* **`high`：** 此設定在 token 用量與智慧之間取得平衡。對於大多數對智慧敏感的使用情境，請至少使用 `high` 努力程度。
* **`medium`：** 適合需要減少 token 用量、同時願意犧牲部分智慧的成本敏感使用情境。
* **`low`：** 保留給簡短、範圍明確的任務，以及對智慧不敏感但對「latency」（延遲）敏感的工作負載。

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

如果您在複雜問題上觀察到淺層推理，請將努力程度提高至 `high` 或 `xhigh`，而非透過提示來繞過它。如果您為了延遲需要將努力程度維持在 `low`，請加入針對性的指引：

```text wrap
This task involves multistep reasoning. Think carefully through the problem before responding.
```

對於此模型而言，努力程度可能比以往任何 Opus 都更為重要，因此在升級時請積極地進行實驗。

在 Claude Opus 4.8 上，除非您明確設定 `thinking: {type: "adaptive"}`，否則思考功能為關閉狀態。[自適應思考](https://platform.claude.com/docs/zh-TW/build-with-claude/thinking)的觸發行為是可引導的。如果您發現模型思考的頻率超出您的期望（這可能發生在大型或複雜的系統提示中），請加入指引來引導它。一如既往，請衡量任何提示變更對效能的影響。範例：

```text wrap
Thinking adds latency and should only be used when it will meaningfully improve answer quality — typically for problems that require multistep reasoning. When in doubt, respond directly.
```

反之，如果您以 `medium` 執行困難的工作負載並看到思考不足的情況，第一個調整手段是提高努力程度。如果您需要更精細的控制，請直接透過提示要求。

<Note>
  如果您以 `max` 或 `xhigh` 努力程度執行 Claude Opus 4.8，請設定較大的最大輸出 token 預算，讓模型有空間在其子代理與工具呼叫之間進行思考與行動。請從 64k token 開始，並由此進行調整。
</Note>

## 工具使用觸發

Claude Opus 4.8 傾向於偏好推理而非工具呼叫。這在大多數情況下會產生更好的結果。然而，提高努力程度設定是增加「tool use」（工具使用）程度的有用手段，尤其是在知識工作中。`high` 或 `xhigh` 努力程度設定在代理搜尋與程式編寫中顯示出明顯更多的工具使用。對於您希望有更多工具使用的情境，您也可以調整提示，明確指示模型何時以及如何正確使用其工具。例如，如果您發現模型沒有使用您的網頁搜尋工具，請清楚描述它為何以及應如何使用。

## 面向使用者的進度更新

Claude Opus 4.8 在長時間的代理追蹤過程中，會向使用者提供更規律、更高品質的更新。如果您曾加入鷹架來強制產生中間狀態訊息（「每 3 次工具呼叫後，總結進度」），請嘗試將其移除。如果您發現 Claude Opus 4.8 面向使用者的更新在長度或內容上未能很好地校準至您的使用情境，請在提示中明確描述這些更新應該是什麼樣子，並提供範例。

## 更字面化的指令遵循

Claude Opus 4.8 會以字面且明確的方式解讀提示，尤其是在較低的努力程度下。它不會默默地將一項指令從一個項目推廣到另一個項目，也不會推斷您未提出的請求。這種字面化的好處是精確且較少反覆折騰，而且對於具有精心調整提示的 API 使用情境、結構化擷取，以及您希望行為可預測的管線，它通常表現更好。如果您需要 Claude 廣泛地套用某項指令，請明確說明範圍（例如，「將此格式套用至每個章節，而不僅是第一個」）。

## 語氣與寫作風格

與任何新模型一樣，長篇寫作的文字風格可能會有所改變。Claude Opus 4.8 傾向於直接、有主見的風格，極少使用以肯定為先的措辭，也很少使用表情符號。如果您的產品依賴特定的語調，請針對新的基準重新評估風格提示。

例如，如果您的產品語調較為溫暖或更具對話性，請加入：

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

## 控制子代理的產生

Claude Opus 4.8 預設傾向於產生較少的「subagents」（子代理）。然而，此行為可透過提示加以引導；請就何時需要子代理給予 Claude Opus 4.8 明確的指引。以下是一個程式編寫使用情境的簡單範例：

```text wrap
Do not spawn a subagent for work you can complete directly in a single response (e.g. refactoring a function you can already see).

Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.
```

## 設計與前端預設值

Claude Opus 4.8 具有強烈的設計直覺，並有一致的預設風格：溫暖的奶油色／米白色背景（\~`#F4F1EA`）、襯線展示字體（Georgia、Fraunces、Playfair）、斜體文字點綴，以及赤陶色／琥珀色強調色。這對於編輯、餐旅與作品集類的需求效果很好，但不適合儀表板、開發者工具、金融科技、醫療保健或企業應用程式。此預設會出現在簡報與網頁 UI 中。

此預設風格相當頑固。通用的指示（「不要使用奶油色」、「讓它乾淨且極簡」）往往會讓模型轉向另一個固定的調色盤，而非產生多樣性。有兩種方法能可靠地奏效：

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

```text wrap
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. 讓模型在建構之前先提出選項。** 這能打破預設風格並讓使用者掌握控制權。如果您先前依賴 `temperature` 來獲得設計多樣性，請使用此方法；它能在多次執行之間產生有意義的不同方向。範例提示：

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

此外，相較於先前的模型，Claude Opus 4.8 需要較少的前端設計提示，即可避免使用者稱為「AI slop」美學的通用模式。對於較早的模型，Anthropic 建議使用 [frontend-design skill](https://github.com/anthropics/claude-code/blob/main/plugins/frontend-design/skills/frontend-design/SKILL.md) 中較冗長的提示片段。然而，Claude Opus 4.8 只需較少的提示指引即可產生獨特且富有創意的前端。此提示片段與前述關於多樣性的提示建議搭配使用效果很好：

```text wrap
<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>
```

## 互動式程式編寫產品

Claude Opus 4.8 的 token 用量與行為，在只有單一使用者回合的自主、非同步程式設計代理，以及具有多個使用者回合的互動、同步程式設計代理之間可能有所不同。具體而言，它在互動式環境中往往會使用更多 token，主要是因為它在使用者回合之後會進行更多推理。這可以在長時間的互動式程式設計工作階段中改善長期連貫性、指示遵循與程式設計能力，但也會伴隨更多的 token 用量。若要在程式設計產品中同時最大化效能與 token 效率，請使用 `xhigh` 或 `high` effort，加入自動模式等自主功能，並減少需要使用者進行的人工互動次數。

當然，在限制所需的使用者互動次數時，重要的是在第一個人類回合中預先指定任務、意圖與相關限制。預先提供規格完善、清晰且準確的任務描述，有助於最大化自主性與智慧，同時將使用者回合之後的額外 token 用量降至最低。由於 Claude Opus 4.8 比先前的模型更具自主性，這種使用模式有助於最大化效能。相較之下，透過多個使用者回合逐步傳達的模糊或規格不足的提示，往往會相對降低 token 效率，有時也會降低效能。

## 程式碼審查框架

Claude Opus 4.8 在發現錯誤方面明顯優於先前的模型，在內部評估中同時具有更高的召回率與精確率。然而，如果您的程式碼審查框架是針對較早的模型調整的，您一開始可能會看到較低的召回率。這很可能是框架造成的效果，而非能力退步。當審查提示中出現諸如「只回報高嚴重性問題」、「保守一點」或「不要吹毛求疵」之類的說法時，Claude Opus 4.8 可能會比較早的模型更忠實地遵循該指示：它可能會同樣徹底地調查程式碼、找出錯誤，然後不回報它判定低於您所述標準的發現。這可能表現為模型進行相同深度的調查，但將較少的調查轉化為回報的發現，尤其是針對較低嚴重性的錯誤。精確率通常會提升，但即使模型底層的錯誤發現能力已經改善，測得的召回率仍可能下降。

一些建議的提示用語：

```text wrap
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 Opus 4.8 支援較早的 `computer_20251124` 工具版本，並且在 Claude API 和 Claude Models on Google Cloud (Google managed) 上支援 `computer_toolset_20260801` 工具集。在這兩個平台上，Claude Opus 4.8 也支援用於網頁內任務的[瀏覽器使用工具](https://platform.claude.com/docs/zh-TW/agents-and-tools/tool-use/browser-use-tool)（`browser_toolset_20260801`）。「[Computer use](https://platform.claude.com/docs/zh-TW/agents-and-tools/tool-use/computer-use-tool)」（電腦使用）功能可在各種解析度下運作，最高解析度為 2576px / 3.75MP。內部電腦使用測試顯示，以 1080p 傳送圖片能在效能與成本之間取得良好平衡。

對於特別成本敏感的工作負載，720p 或 1366×768 是具有強勁效能的較低成本選項。請自行進行測試，以找出適合您使用情境的理想設定；嘗試不同的努力程度設定也有助於調整模型的行為。