# Claude 5 模型的 context engineering 新規則

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 原作者：Thariq (@trq212) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥🔥🔥🔥🔥 · 日期：2026-07-24

> 原始來源：https://x.com/trq212/status/2080710971228918066

## 中文摘要

# 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 和使用者請求互相打架，例如「適當留下文件」或是「不要新增註解」。

![彙整系統 Prompt、skill 與使用者需求的內容組合結構示意圖](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/f1a0ec5d00cc6b6a.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片展示了一個標題為「the assembled context」的區塊，內含三個主要部分：
1. 「system prompt」：包含灰色橫條文字，並在橘色突顯框中標示「"leave documentation as appropriate" *」。
2. 「skills」：包含灰色橫條文字，並在橘色突顯框中標示「"do not add comments" *」。
3. 「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.」</div></details>

通常，Claude 可以解讀使用者的意圖來得到正確答案，但在決定要做什麼之前，Claude 必須更仔細地思考這些重疊且衝突的訊息。

雖然這些限制曾經是為了避免最糟情況發生而需要的，但我們後來發現，我們可以刪除其中許多限制，讓模型改用周遭的 context 和判斷力來處理。

此外，現在的 Claude Code 擁有了更多工具。過去 Claude 依賴 CLAUDE.md 作為記憶、資訊和指引的來源。現在我們有了記憶、artifact 和 skill，Claude 可以利用這些來建立在不同工作階段之間載入和分享 context 的新方式。

## 過去與現在

有許多先前的 context engineering 最佳實踐已經變成了迷思。其中包括：

![顯示 Claude 相關規則與介面設計概念對照清單的圖表](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/176396226e4c9b59.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">這是一張列表對照圖，左側為刪除線樣式的舊概念，右側為對應的新概念，各項目由箭頭（→）連接：
1. Give Claude Rules → Give Claude Judgement
2. Give Claude Examples → Design Interfaces
3. Put it all upfront → Use Progressive Disclosure
4. Repeat Yourself → Simple Tool Descriptions
5. Memory in Claude.MDs → Auto-memory
6. Simple Specs → Rich References</div></details>


過去：給 Claude 規則
現在：讓 Claude 發揮判斷力
當我們剛推出 Claude Code 時，我們需要確保 Claude 能夠避開最糟的情況，例如刪除檔案。這意味著我們會給予特別強烈的指引，而這些指引可能不見得永遠正確。例如，我們過去在系統 Prompt 中會這樣說：

在程式碼中：預設不寫任何註解。絕不要寫多段式 docstring 或多行註解區塊 — 最多一行短註解。除非使用者要求，否則不要建立規劃、決策或分析文件 — 請從對話 context 著手，而不是中介檔案。

但對於特定的 Prompt 子集而言，這種指引可能是錯的。以文件為例，使用者可能會有自己的偏好，或者極度複雜程式碼的特定部分可能會需要多行註解區塊。

儘管如此，如果對舊模型不加上這些安全防護網，Claude 寫出的註解在許多情況下會是錯的，而我們必須接受這個權衡。但較新的模型具備更好的判斷力，能夠在沒有明確規則的情況下妥善處理這些決定。

在新的系統 Prompt 中我們說：編寫讀起來像周遭程式碼的程式碼：符合其註解密度、命名慣例和慣用語法。

過去：給 Claude 範例
現在：設計介面
工具使用的第一條法則，就是給 Claude 如何使用它們的範例。但在我們最新的模型中，我們發現給予範例實際上反而會將它們侷限在特定的探索空間中。

![TodoWrite 工具與傳統系統 Prompt 的字數與結構對比示意圖](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/73b7d2ffc7f0f837.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片包含左右兩個區塊，用於對比「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`。</div></details>

與其使用範例，不如多思考你的工具、腳本和檔案的設計——Claude 擁有什麼參數？它們要如何才能更具表達力？

舉例來說，在 Todo 工具的範例中，只要將狀態列為 pending、in_progress 和 completed 之間的列舉值，就是在暗示 Claude 該如何使用它。關於保持一個項目處於 in_progress 的指令，則有助於定義我們要求的行為。

過去：把所有東西都放在最前面
現在：使用漸進式揭露 (progressive disclosure)

因為 Claude Code 專注於程式撰寫，我們的系統 Prompt 包含了如何進行程式碼審查與驗證的詳細資訊。這些並不總是必要的，但當需要它們時，這就是至關重要的資訊。

自那之後，Claude Code 在使用漸進式揭露方面變得非常熟練——在正確的時間點載入正確的 context。舉例來說，我們將驗證和程式碼審查移到了它們自己的 skill 中，讓 Claude Code 可以選擇性地呼叫。

但漸進式揭露不只適用於 skill，我們也將其用於工具。我們有些工具屬於「延遲載入 (deferred loading)」，這意味著 Agent 在使用它們之前，必須先透過 ToolSearch 搜尋它們的完整定義。這讓我們能夠擁有更多工具（例如我們的 Task 工具），在需要之前不會佔用 context。

這同樣可以應用在你自己的 CLAUDE.md 和 Skill.md 檔案中。一個常見的迷思是，你會想把這些檔案變成你可能遇到的每一個已知實踐的中央儲存庫，因為 Claude 否則就找不到它們。相反地，請考慮建立一個可以在正確時間點被載入的檔案樹。

過去：重複你自己
現在：簡單的工具描述

早期的 Claude 模型有時需要重複的指令，或者比起放在 context 視窗開頭，更容易聽進放在結尾的指令。這意味著我們的系統 Prompt 有時會在主要系統 Prompt 中提及工具，同時也在工具描述中包含指令。

我們發現我們可以刪除這些重複的範例，並將如何使用工具的指令放在工具描述中，而不是系統 Prompt 裡。

過去：將記憶放在 CLAUDE.md 檔案中
現在：自動記憶

我們過去鼓勵使用者透過使用 `#` 熱鍵自動寫入他們的 CLAUDE.md，來將事情儲存到 Claude 的記憶中。相反地，現在 Claude 會自動儲存與該工作以及與你相關的記憶。

過去：簡單的規格書
現在：豐富的參考資料

在計畫模式 (plan mode) 下，Claude Code 極度依賴帶有計畫的 markdown 檔案。將這些檔案儲存為計畫，有助於 Claude 在需要時參考它們。另一個類似的最佳實踐是將規格書儲存在程式庫中，供 Claude 在執行較長專案時參考。

但我們發現 Claude 可以處理越來越複雜的參考資料。Claude 不再只能依賴簡單的 markdown 檔案，還能參考由我們的新 artifacts 功能所建立的 HTML artifacts。

你也可以用程式碼的形式提供參考資料給 Claude。規格書也可以是詳細的測試套件，或是 Claude 可能會移植的不同程式庫中的函式。

評分標準 (rubrics) 是另一種形式的參考資料。評分標準允許 Claude 透過使用動態工作流程並啟動帶有這些評分標準的驗證 Agent，來試著驗證你在特定領域的品味（例如：好的 API 設計長什麼樣子）。

## 將此應用到你的 context 中

把這些全部整合在一起，當你組合你的 context 時，它會是什麼樣子？

![包含 Your prompt、References、System prompt、Claude.MDs、Skills 與 Memory 的 Prompt 階層架構圖](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/d904e9525ae04b8e.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面為一個方框內的階層架構列表，從上到下包含以下區塊：
1. Your prompt（最上方以淺橘色框選）
2. References（包含說明文字：@-mentioned files, specs, mockups, codebases, artifacts）
3. System prompt
4. Claude.MDs
5. Skills
6. Memory</div></details>

系統 Prompt
系統 Prompt 與產品 context 緊密相連。它告訴 Claude 它正在哪個產品中運作以及它正在做什麼。用 Claude Code 時，你可能永遠不需要改這個，但如果你正在建構自己的 Agent harness，這會是你需要花費大量時間的地方。

CLAUDE.md
保持你的 CLAUDE.md 輕量化，並簡短描述你的 repo 的用途，但要把大部分的 token 花在程式庫內部的潛在陷阱 (gotchas) 上。舉例來說，你可能會將程式碼組織成將型別放在一個單體檔案 (monolithic file) 中，而不是其他地方。避免陳述 Claude 只要查看你的檔案系統或 repo 就應該知道的「顯而易見」的事情。

使用漸進式揭露來取得更多詳細資訊，例如，如果你有多個關於如何驗證工作的獨特指令，請建立一個驗證 skill 並從你的 CLAUDE.md 中參考它。

Skills
將 skill 視為輕量級的指引，讓 Claude 在需要時找到資訊。除了高度重要的領域之外，避免將它們過度限制。

對於較長的 skill，請盡可能嘗試使用漸進式揭露——將其分為多個檔案並拆分開來。

當 skill 包含了對你、你的團隊或產品而言特有的特定觀點、知識或最佳實踐時，效果是最好的。

References
你可以使用 `@` 提及檔案來將它們包含為參考資料。參考資料允許 Claude 參考關於目前計畫的深入資訊。

這可以是規格書檔案、mockup，甚至是整個程式庫。一般來說，你應該優先選擇位於程式碼中的檔案，因為它能以 Claude 非常熟悉的語言，為其提供清晰、高傳真度的指引。舉例來說，設計的 HTML mockup 通常會比設計描述或截圖產生更好的結果。

## 嘗試簡化

在你的系統 Prompt、skill 和 CLAUDE.md 檔案中，你可能需要像我們一樣進行簡化。我們推出了一個名為 `claude doctor` 的新指令，它也能夠協助你自動完成這件事。若要取得關於專門為更先進模型寫 Prompt 的更多詳細資訊，請查看我們的 Fable 實戰指南。

## 標籤

Skills, Claude Code, Agent, 教學資源, Anthropic, Claude