Anthropic 團隊在官方網站和社群媒體上分享了一系列針對 Claude Opus 4.5 模型的 prompting 最佳實踐。這部影片將這些技巧整理成易懂的圖解形式，涵蓋語氣控制、行動導向提示、避免過度工程化、鼓勵程式碼探索、規則撰寫原則、並行工具控制等核心主題，幫助開發者更有效地使用 Claude Code 進行程式開發。

---

原影片連結：https://www.youtube.com/watch?v=pb0lVGDiigI

影片重點

• 避免使用攻擊性語氣（如 “you must”），改用指令式的柔和語氣來提示模型
• Opus 4.5 更精確地遵循指令，不再自動將「建議」理解為「實作」
• Opus 4.5 有過度工程化的傾向，需要在提示中明確約束範圍
• 鼓勵模型探索程式碼庫，而非讓它依賴訓練資料猜測
• 豐富的輸入提示能產出豐富的輸出結果（分布收斂效應）
• 撰寫規則時應附帶動機說明，讓模型理解「為什麼」而非只知道「做什麼」
• 可以調整模型的詳細程度，要求每步驟提供摘要以增加透明度
• 格式化指令應使用正面表述，而非負面限制
• 並行工具執行可以透過提示來控制速度
• 在關閉思考模式時避免使用 “think” 這個詞

詳細內容

[00:00] 使用柔和的指令式語氣

在提示 Claude Opus 4.5 時，應避免使用攻擊性的語氣。例如，使用「you must always use a web search tool」這類強制語句，會讓模型因為害怕犯錯而過度觸發工具，導致混亂的輸出和整體效能下降。

更好的做法是使用指令式提示，例如「use tool X when condition Y is met, answer directly otherwise」。這讓模型能夠遵循你給定的流程，而不會因為恐懼而不必要地使用工具。影片用了一個有趣的比喻：把模型當成叛逆青少年一樣大吼大叫只會讓它更焦慮，效能更差；把它當成有能力的員工來對待，反而能獲得更好的結果。

過去的研究曾顯示負面提示能帶來更好的效能，但這個時代正在結束，因為過度使用工具會導致整體輸出品質下降。Anthropic 團隊也製作了一個 Claude Code migration plugin，可以自動將程式碼庫中過度攻擊性的系統提示轉換為較柔和的語言。

[02:45] 行動導向的明確提示

Opus 4.5 現在會更精確地遵循指令。過去如果你說「can you suggest improvements as code?」，較早版本的 Claude 會直接幫你實作改進。但現在模型會嚴格按照字面意思，只給你建議而不進行實作。

如果你希望模型實際執行修改，就需要明確地說「can you refactor this code and implement the changes directly?」。這意味著 Opus 4.5 對指令的理解更加精確，開發者需要更直接地表達自己的意圖。

[03:40] 避免過度工程化

Opus 4.5 有一個傾向：在收到開放式請求時會過度工程化。例如你只說「refactor the authentication logic」，模型可能會非常積極地幫你創建新的介面、輔助類別、設定檔和更多抽象層，做出遠超預期的修改。

解決方法是在提示中加入明確的約束，例如「Refactor the authentication logic, modify in place, no new files, keep it minimal」。這樣模型就知道只需修改現有檔案。你也可以把類似的約束規則加入 CLAUDE.md 檔案中，這樣就不需要每次都手動寫。

[05:00] 鼓勵程式碼探索

Opus 4.5 在探索程式碼時可能會過於保守。如果你只說「fix a bug in the user module」，模型可能不會去查看周圍的上下文和相關檔案，而是根據訓練資料猜測其他程式碼的運作方式，這可能導致修復方案有誤。

更好的提示方式是「read the entire user module and its dependencies, understand the dataflow, then propose a fix」。這會讓模型先建立整個程式碼庫的心理模型，再提出更準確的修復方案。

如果你使用 Claude Code 的 Plan Mode，它會自動觸發子代理來探索程式碼庫。你也可以手動使用 @explore 指令來觸發探索子代理。

[06:50] 豐富的輸入產出豐富的輸出

如果你只給模型一個簡單的提示，如「build me a login page in React」，你會得到一個非常基礎的輸出。但如果你的提示更加豐富，例如「build a login page in React, include full animations, form validation, error messages, accessibility features, a polished visual design, go beyond the basics」，你就會得到明顯更好的結果。

這背後的原因是「分布收斂」（distributional convergence）現象。當給出簡單的提示時，模型會從訓練資料中最常見、最安全的模式取樣——例如 Inter 字體、紫色漸層、極簡設計——這些設計普遍可接受但非常通用。提供明確的指引（如避免 Inter 字體、使用獨特字體、複雜動畫、大膽配色），可以引導模型從訓練資料的創意邊緣取樣，產出更具特色的設計。

值得注意的是，在安全性相關的程式碼（如認證系統）中，通用的實作方式反而是好的。但在 UI 設計方面，你需要更多的引導才能跳脫常規。簡單來說：模型在輸出上投入的努力，取決於你在輸入上投入的努力。

[09:30] 為規則提供動機說明

當你為模型制定規則時，光寫規則本身是不夠的。例如只說「never use abbreviations」，模型會盲目地遵循，把所有縮寫都展開，可能導致尷尬的輸出。但如果你加上上下文，如「never use abbreviations — for formal legal documents to avoid ambiguity」，模型就能理解規則背後的目標是清晰性和正式性，並更好地將這個原則廣泛應用。

在程式碼中的實際應用：不要只寫「always use try-catch blocks around API calls」，而是寫「always use try-catch blocks around API calls — our monitoring system relies on caught exceptions to trigger alerts, and unhandled rejections cause silent failures in production that are difficult to debug」。同樣，不要只寫「add comments explaining complex logic」，而是寫「add comments explaining complex logic, especially business rules — our domain in insurance claims processing has non-obvious requirements that aren’t apparent from the code itself」。

附帶動機的規則有三個好處：規則能智慧泛化（模型理解原則而非只是字面規則）、當兩條規則衝突時模型能做出更好的取捨判斷、以及模型能夠標記可能的邊界案例。隨著 CLAUDE.md 檔案的規則越來越多，規則之間可能會產生衝突，因此附帶動機說明格外重要。

[12:50] 調整輸出的詳細程度

Claude 4.5 模型預設傾向高效率，可能在工具呼叫後跳過語言摘要直接進入下一步。這雖然能加快工作流程，但你可能會不清楚模型做了什麼、為什麼得出這個結果。

你可以在提示中加入「after each major step, provide a brief summary of what you found and what you did」，或是「after completing a task that involves tool use, provide a quick summary of the work done」。這樣模型的每一步都會透明化，你能更有信心地理解和驗證它的輸出。

[14:30] 使用正面表述的格式化指令

在控制模型的回應格式時，避免使用負面提示如「do not use bullet points or markdown formatting」。這會讓模型過度關注哪些事不能做，導致輸出不自然。

更好的方式是使用正面表述：「write your response as flowing prose paragraphs, use complete sentences that connect ideas naturally」。告訴模型你想要什麼格式，而不是不要什麼格式，能讓輸出更加流暢自然。

[15:10] 控制並行工具執行

Claude 4.5 模型擅長並行工具執行，特別是 Sonnet 4.5 會非常積極地同時發起多個操作。在研究任務中，它可能同時發起三到四個網頁搜尋，而這些搜尋可能是推測性的。如果改為逐一執行，下一個搜尋查詢可以根據上一個結果來優化。

在程式碼場景中，如果模型同時執行多個安裝命令，可能會導致套件衝突而陷入迴圈。這個行為可以透過提示來控制：在 CLAUDE.md 中加入鼓勵並行的提示會讓它做更多並行操作；加入要求每步之間暫停和思考的提示則會減少並行。

[16:50] 關閉思考模式時避免使用 “think”

當 Claude Code 的思考模式（thinking mode）關閉時，應避免在提示中使用 “think” 這個詞，Opus 4.5 對此特別敏感。使用「think step by step before answering」會導致模型產生大量冗長且充滿噪音的回答，因為它實際上無法在非思考模式下進行思考。

替代方案是使用類似含義但不同的詞彙，如「carefully consider and evaluate constraints, then give a final answer, no intermediate reasoning」。使用 “consider”、”believe”、”evaluate” 這些詞可以在思考模式關閉的情況下獲得更好的輸出品質。

我的想法

這部影片很好地整理了 Anthropic 官方散佈在各處的 Opus 4.5 prompting 指南，尤其是「為規則附帶動機」這個觀點特別有價值。在實務中，很多團隊的 CLAUDE.md 或系統提示只堆積了大量的「必須做」和「禁止做」的規則，卻沒有解釋為什麼。模型不是只會背規則的機器，它需要理解上下文才能做出好的判斷。

「分布收斂」的觀點也很有啟發性。這解釋了為什麼很多人抱怨 AI 生成的 UI 都長得差不多——不是模型不會做，而是你的提示把它推向了統計上最安全的中間地帶。這個概念不只適用於設計，在程式架構選擇、命名慣例等方面也同樣適用。

另一個值得注意的趨勢是：隨著模型能力增強，「負面提示」的效果正在衰退。過去那套「你必須做什麼、你絕對不能做什麼」的恐嚇式 prompting 已經不再是最佳實踐。這反映了 AI 模型正在從「需要嚴格約束的工具」演進為「需要清晰指引的協作者」。

進階測驗