Claude 5 模型的 context engineering 新規則

Claude 5 模型的 context engineering 新規則 我先前寫過關於如何以最佳方式為新一代的 Claude 5 模型寫 Prompt，並透過與它們反覆互動來摸索出你想建構的東西。 但當你發送訊息給 Claude 時，Prompt 只是它取得的 context 的一小部分。你的大部分 context 是由系統 Prompt、skill、CLAUDE.md 檔案、記憶和其他來源組合而成。我們稱這為 context engineering，它會對你使用 Claude Code 或建構自己的 Agent 時所產生的結果產生巨大影響。 與 Prompt 不同的是，context 通常會在許多請求中通用，因此無法那麼具體。特別是當你不知道使用者的 Prompt 會是什麼時，你要如何為 Claude 建構這些通用的 Prompt 與指引呢？ 隨著 Claude 自身的能力不斷演進，這可能會變得出奇地困難。最近我們注意到，我們為新一代 Claude 模型寫 Prompt 的方式有了巨大的跳躍。我們移除了 Claude Code 中針對像是 Claude Opus 5 和 Claude Fable 5 等模型超過 80% 的系統 Prompt，且在我們的程式碼評估中沒有發現任何可測量的效能損失。 以下是我們針對這類新模型在寫 Prompt 上所學到的經驗，以及你該如何利用它來更新你的 context engineering。我們已經將這些最佳實踐放入 claude doctor 中，請在 Claude Code 中使用 /doctor 指令來調整你的 skill 和 CLAUDE.md 檔案的大小。 解除 Claude 的束縛 總體而言，我們發現自己過去對 Claude Code 的限制太多了，無論是透過我們的系統 Prompt，還是在我們的 CLAUDE.md 檔案和 skill 中。 舉例來說，當我們閱讀內部使用 Claude Code 的對話紀錄時，我們會在單一請求中看到幾個互相衝突的訊息，像是系統 Prompt、skill 和使用者請求互相打架，例如「適當留下文件」或是「不要新增註解」。 展開畫面重點圖片展示了一個標題為「the assembled context」的區塊，內含三個主要部分： 「system prompt」：包含灰色橫條文字，並在橘色突顯框中標示「"leave documentation as appropriate" *」。 「skills」：包含灰色橫條文字，並在橘色突顯框中標示「"do not add comments" *」。 「your request」：包含灰色橫條文字，並在橘色突顯框中標示「"just make it work like the old one" *」。 下方文字說明：「one context; Claude reads all of it, and has to reconcile it」 最下方附註：「* Illustrative examples, not verbatim quotes from any real prompt, skill, or user request.」 通常，Claude 可以解讀使用者的意圖來得到正確答案，但在決定要做什麼之前，Claude 必須更仔細地思考這些重疊且衝突的訊息。 雖然這些限制曾經是為了避免最糟情況發生而需要的，但我們後來發現，我們可以刪除其中許多限制，讓模型改用周遭的 context 和判斷力來處理。 此外，現在的 Claude Code 擁有了更多工具。過去 Claude 依賴 CLAUDE.md 作為記憶、資訊和指引的來源。現在我們有了記憶、artifact 和 skill，Claude 可以利用這些來建立在不同工作階段之間載入和分享 context 的新方式。 過去與現在 有許多先前的 context engineering 最佳實踐已經變成了迷思。其中包括： 展開畫面重點這是一張列表對照圖，左側為刪除線樣式的舊概念，右側為對應的新概念，各項目由箭頭（→）連接： Give Claude Rules → Give Claude Judgement Give Claude Examples → Design Interfaces Put it all upfront → Use Progressive Disclosure Repeat Yourself → Simple Tool Descriptions Memory in Claude.MDs → Auto-memory Simple Specs → Rich References 過去：給 Claude 規則 現在：讓 Claude 發揮判斷力 當我們剛推出 Claude Code 時，我們需要確保 Claude 能夠避開最糟的情況，例如刪除檔案。這意味著我們會給予特別強烈的指引，而這些指引可能不見得永遠正確。例如，我們過去在系統 Prompt 中會這樣說： 在程式碼中：預設不寫任何註解。絕不要寫多段式 docstring 或多行註解區塊 — 最多一行短註解。除非使用者要求，否則不要建立規劃、決策或分析文件 — 請從對話 context 著手，而不是中介檔案。 但對於特定的 Prompt 子集而言，這種指引可能是錯的。以文件為例，使用者可能會有自己的偏好，或者極度複雜程式碼的特定部分可能會需要多行註解區塊。 儘管如此，如果對舊模型不加上這些安全防護網，Claude 寫出的註解在許多情況下會是錯的，而我們必須接受這個權衡。但較新的模型具備更好的判斷力，能夠在沒有明確規則的情況下妥善處理這些決定。 在新的系統 Prompt 中我們說：編寫讀起來像周遭程式碼的程式碼：符合其註解密度、命名慣例和慣用語法。 過去：給 Claude 範例 現在：設計介面 工具使用的第一條法則，就是給 Claude 如何使用它們的範例。但在我們最新的模型中，我們發現給予範例實際上反而會將它們侷限在特定的探索空間中。 展開畫面重點圖片包含左右兩個區塊，用於對比「Before」與「TodoWrite」兩種做法的差異。 左側區塊（Before）： 標題：「Before」 字數標示：「≈9,100 characters」 描述文字：「when-to-use lists, worked examples」 內容：包含大量連續的長段落文字線條（呈現冗長、未結構化的 prompt 內容）。 右側區塊（TodoWrite）： 標題：「TodoWrite」 描述文字："Create and update a task list for the current session..." 內容： - 含有項目符號的簡短任務列表線條。 - 狀態標籤：status:，包含三個選項按鈕 pending、in_progress、completed。 - 底部提示說明：only one task in_progress at a time。 與其使用範例，不如多思考你的工具、腳本和檔案的設計——Claude 擁有什麼參數？它們要如何才能更具表達力？ 舉例來說，在 Todo 工具的範例中，只要將狀態列為 pending、inprogress 和 completed 之間的列舉值，就是在暗示 Claude 該如何使用它。關於保持一個項目處於 inprogress 的指令，則有助於定義我們要求的行為。 過去：把所有東西都放在最前面 現在：使用漸進式揭露 (progressive disclosure) 因為 Claude Code 專注於程式撰寫，我們的系統 Prompt 包含了如何進行程式碼審查與驗證的詳細資訊。這些並不總是必要的，但當需要它們時，這就是至關重要的資訊。 自那之後，Claude Code 在使用漸進式揭露方面變得非常熟練——在正確的時間點載入正確的 context。舉例來說，我們將驗證和程式碼審查移到了它們自己的 skill 中，讓 Claude Code 可以選擇性地呼叫。 但漸進式揭露不只適用於 skill，我們也將其用於工具。我們有些工具屬於「延遲載入 (deferred loading)」，這意味著 Agent 在使用它們之前，必須先透過 ToolSearch 搜尋它們的完整定義。這讓我們能夠擁有更多工具（例如我們的 Task 工具），在需要之前不會佔用 context。 這同樣可以應用在你自己的 CLAUDE.md 和 Skill.md 檔案中。一個常見的迷思是，你會想把這些檔案變成你可能遇到的每一個已知實踐的中央儲存庫，因為 Claude 否則就找不到它們。相反地，請考慮建立一個可以在正確時間點被載入的檔案樹。 過去：重複你自己 現在：簡單的…