我先前曾撰文探討如何善用提示新一代 Claude 5 模型，並透過迭代方式與它們協作，逐步發掘你想建構的內容。
但當你傳送訊息給 Claude 時，提示詞只是它所取得上下文的一小部分。你的上下文大多由系統提示、技能、CLAUDE.md 檔案、記憶體及其他來源組合而成。我們稱之為上下文工程，它對你在使用 Claude Code 或建立自己的 Agent 時所產生的結果有重大影響。
與提示詞不同，上下文通常用於許多請求，因此無法如此具體。你要如何為 Claude 建立這些通用提示和指引，尤其是當你不知道使用者的提示詞是什麼時？
隨著 Claude 自身能力的演進，這可能變得異常困難。最近，我們注意到在提示新一代 Claude 模型的方式上有了大幅躍進。我們移除了 Claude Code 中超過 80% 的系統提示（針對 Claude Opus 5 和 Claude Fable 5 等模型），但在編碼評估上並未觀察到任何可量化的損失。
以下是我們在提示這類新型模型時學到的心得，以及如何運用它們來更新你的上下文工程。我們將這些最佳實踐收錄在 claude doctor 中，你可以在 Claude Code 中使用 /doctor 指令來調整你的技能和 CLAUDE.md 檔案。
解放 Claude
整體而言，我們發現我們對 Claude Code 過度約束，無論是在系統提示、CLAUDE.md 檔案還是技能中都是如此。
例如，當我們閱讀 Claude Code 的內部使用記錄時，我們看到單一請求中出現多條互相衝突的訊息，例如「酌情留下文件」或「不要加入註解」，因為我們的系統提示、技能和使用者請求彼此衝突。
一般來說，Claude 可以解讀使用者的意圖以得出正確答案，但 Claude 必須更仔細思考這些重疊且互相衝突的訊息，才能決定該怎麼做。
雖然這些限制曾經是為了避免最糟情況而必要，但我們後來發現可以刪除其中許多限制，讓模型改用周圍的上下文和判斷力來處理。
此外，Claude Code 現在擁有更多工具。Claude 過去依賴 CLAUDE.md 作為記憶、資訊和指引的來源。現在我們有了記憶、成品和技能，Claude 可以用它們來建立新的方式，跨工作階段載入和分享上下文。
過去與現在
過去有許多上下文工程的最佳實踐，如今已成為迷思。包括：
**
過去：給 Claude 規則
現在：讓 Claude 使用判斷力
**當我們首次推出 Claude Code 時，需要確保 Claude 避免最糟情況，例如刪除檔案。這表示我們會給予特別強烈的指引，但這些指引不一定總是正確的。例如，在系統提示中，我們過去會說：
在程式碼中：預設不寫任何註解。絕不寫多段落的 docstring 或多行註解區塊——最多一行。除非使用者要求，否則不要建立規劃、決策或分析文件——從對話上下文而非中間檔案來工作。
但對於某些提示詞，這項指引反而是錯的。以文件為例，使用者可能有自己的偏好，或者非常複雜的程式碼的特定部分可能需要多行註解區塊。
儘管如此，對於舊模型來說，少了這些防護措施，Claude 寫的註解在許多情況下會不正確，我們必須接受這種取捨。但較新的模型擁有更好的判斷力，可以在沒有明確規則的情況下妥善處理這些決策。
在新的系統提示中，我們說：寫出與周圍程式碼風格一致的程式碼：比照其註解密度、命名方式和慣用語。
**過去：給 Claude 範例
現在：設計介面
**工具使用的首要規則是給 Claude 使用範例。但對於我們最新的模型，我們發現給範例反而會限制它們的探索空間。
與其使用範例，不如思考你的工具、腳本和檔案的設計——Claude 有哪些參數可用？這些參數如何能更具表達力？
例如，在 Todo 工具範例中，僅僅將狀態列舉為待處理、進行中和已完成，就暗示了 Claude 該如何使用它。而「保持一個項目在進行中」的指示，則有助於定義我們期望的行為。
**過去：把所有內容放在前面
現在：使用漸進式揭露
**由於 Claude Code 專注於編碼，我們的系統提示包含了如何進行程式碼審查和驗證的詳細資訊。這些資訊並非每次都需要，但當需要時，卻是至關重要的資訊。
從那時起，Claude Code 已變得非常擅長使用漸進式揭露——在正確的時間載入正確的上下文。例如，我們將驗證和程式碼審查轉移到各自的技能中，讓 Claude Code 可以選擇性地呼叫。
但漸進式揭露不僅適用於技能，我們也將其用於工具。我們有些工具是「延遲載入」的，這表示 Agent 必須先使用 ToolSearch 搜尋它們的完整定義，才能使用它們。這讓我們能夠擁有更多工具（例如我們的 Task 工具），這些工具在需要之前不會佔用上下文。
同樣的原則也可以應用在你的 CLAUDE.md 和 Skill.md 檔案中。一個常見的迷思是，你應該將這些檔案打造成所有可能遇到的已知實踐的中央儲存庫，因為 Claude 否則找不到它們。相反地，考慮建立一個可以在適當時間載入的檔案樹。
**過去：重複說明
現在：簡單的工具描述
**早期的 Claude 模型有時需要重複的指示，或者更傾向於聽從上下文視窗結尾處的指示，而非開頭的。這表示我們的系統提示有時會在主要系統提示中提及工具，同時也在工具描述中提供指示。
我們發現可以刪除這些重複的範例，並將工具的使用說明放在工具描述中，而不是系統提示裡。
**過去：記憶體放在 CLAUDE.md 檔案中
現在：自動記憶體
**過去我們鼓勵使用者將內容儲存到 Claude 的記憶體中，方法是使用 # 快速鍵自動寫入他們的 CLAUDE.md。現在，Claude 會自動儲存與工作及使用者相關的記憶。
**過去：簡單的規格
現在：豐富的參考資料
**在規劃模式下，Claude Code 高度依賴包含規劃的 Markdown 檔案。將這些檔案儲存為規劃，有助於 Claude 在需要時參考它們。另一個類似的最佳實踐是將規格儲存在程式碼庫中，讓 Claude 在處理較長專案時可以參考。
但我們發現 Claude 能夠處理越來越複雜的參考資料。除了簡單的 Markdown 檔案，Claude 還可以參考我們的新成品功能所建立的 HTML 成品。
你也可以用程式碼的形式提供參考資料給 Claude。一份規格可能是一套詳細的測試套件，或是一個不同程式碼庫中的函式，Claude 可能會將其移植。
評分標準是另一種參考資料形式。評分標準讓 Claude 能夠嘗試並驗證你在特定領域的品味（例如，好的 API 設計是什麼樣子），方法是使用動態工作流程並啟動帶有這些評分標準的驗證器 Agent。
將這些應用於你的上下文
綜合以上所述，當你組合自己的上下文時，具體會是什麼樣子？
**系統提示
**系統提示與產品上下文密切相關。它告訴 Claude 它在哪個產品中運作，以及它正在做什麼。對於 Claude Code，你很可能永遠不需要修改它，但如果你正在建立自己的 Agent 框架，這就是你應該投入大量時間的地方。
**CLAUDE.md
**保持你的 CLAUDE.md 輕量化，簡短描述你的儲存庫的用途，但將大部分 token 用在程式碼庫中的「陷阱」上。例如，你可能將程式碼組織成將型別統一放在一個大型檔案中，其他地方都沒有。避免說明 Claude 透過檢視你的檔案系統或儲存庫就能知道的「顯而易見」的事情。
對於更詳細的內容，使用漸進式揭露。例如，如果你有幾個獨特的驗證工作指示，請建立一個驗證技能，並在 CLAUDE.md 中引用它。
**技能
**將技能視為輕量化的指南，讓 Claude 在需要時找到資訊。避免讓它們過度受限，除非是在高度重要的領域。
對於較長的技能，盡可能使用漸進式揭露——將其分成多個檔案並拆分開來。
技能最好能用來編碼特定的觀點、知識或最佳實踐，這些是專屬於你、你的團隊或產品的。
**參考資料
**你可以使用 @ 提及檔案來將它們包含為參考資料。參考資料讓 Claude 可以查閱關於當前規劃的深入資訊。
這可以是規格檔案、模型，甚至是整個程式碼庫。一般來說，你應該優先選擇程式碼中的檔案，因為它們能以 Claude 非常熟悉的語言提供清晰、高保真度的指示。例如，一個設計的 HTML 模型通常會比設計的描述或截圖產生更好的結果。
嘗試簡化
在你的系統提示、技能和 CLAUDE.md 檔案中，你可能需要像我們一樣進行簡化。我們推出了一個名為 claude doctor 的新指令，它將自動協助你完成這項工作。如需更多關於提示更進階模型的詳細資訊，請參閱我們的 Fable 現場指南。
