2026 年的上下文工程：它是什麼、與提示工程有何不同，以及如何在 Claude Code 中應用
Markdown什麼是上下文工程，以及它與提示工程有何不同。Anthropic 的核心資料、7 個常見錯誤，以及 Claude Code 的最小化設定。
閱讀全文
重點
上下文工程是一門設定 Claude 上下文視窗中、訊息送出前所有內容的技術：系統提示、工具、歷史紀錄、記憶檔案，以及工具提供的資料。到了 2026 年，它已取代提示工程，成為關鍵技能——Anthropic 這麼說。本指南整理一手來源中的核心內容、7 個會浪費 token 的常見錯誤，以及 Claude Code 的實用 7 步驟設定方法。
如需了解如何使用 Ailoot，請參閱文件。
一句話說明：什麼是上下文工程？
重點
上下文工程是一門整理 AI 代理每個步驟中上下文視窗所含資訊的技術：系統提示、工具、歷史紀錄、記憶檔案，以及外部來源的資料。提示工程回答的是「如何撰寫提示？」上下文工程回答的是「你撰寫提示時，AI 知道些什麼？」
Anthropic 在 2025 年 9 月 29 日的一篇工程部落格文章中確立了這個詞：
上下文工程是指在 LLM 推論期間，選擇並維持最佳 token（資訊）集合的一系列策略，其中包含提示本身以外所有輸入的內容。
同一篇文章也提出了最能改變思考角度的一句話：
使用語言模型，正逐漸從在提示中尋找合適的詞句，轉向回答一個更廣泛的問題：「哪種上下文配置最可能產生預期的模型行為？」
核心概念是：上下文不是你撰寫的訊息。上下文是 AI 在你的訊息之前看到的整套資訊——系統提示、工具說明、對話歷史、記憶檔案，以及透過 MCP 載入的資料。提示是最後一步。上下文工程則是送入視窗中所有內容的架構。
為什麼提示工程在 2026 年變得過時？
重點
提示工程誕生於模型只處理單一提示的時代——一個回合、一項任務。2026 年的 AI 代理會在長時間工作階段中使用工具、記憶、子代理，以及透過工具即時擷取的資料。在這種架構下，措辭單一提示不再是主要技能；整理代理看見的所有資訊才是。
這個轉變發生在 2025 年夏天。
2025 年 9 月 29 日： Anthropic 在工程部落格文章中確立這門學科，並提出 4 項原則。
提示工程並沒有「死亡」。它已成為一種基本素養，就像懂得如何使用鍵盤打字一樣。在此之上，一門新學科應運而生，讓 AI 代理能在長任務中保持運作：上下文工程。
上下文工程與提示工程有何不同？5 項差異
重點
提示工程會最佳化單一提示：選擇措辭、範本和語氣。上下文工程則在提示送出前，設計整個資訊環境：系統提示、工具、工作階段歷史、記憶檔案和資訊擷取。這項差異體現在五個面向：最佳化目標、時間範圍、主要風險、核心技能，以及專案中的資訊來源。
| 面向 | 提示工程 | 上下文工程 |
|---|---|---|
| 最佳化目標 | 單一提示的措辭 | 整套 token：系統提示 + 工具 + 歷史紀錄 + 擷取的資料 |
| 時間範圍 | 一個回合 | 多個回合，以及工作階段之間的轉換 |
| 主要風險 | 模型不理解提示 | 模型淹沒在雜訊中（上下文劣化） |
| 核心技能 | 文案撰寫與理解模型 | 資訊架構與目標式擷取 |
| 專案中的資訊來源 | 你的提示範本 | CLAUDE.md、記憶檔案、資訊擷取、子代理、壓縮 |
| 比喻 | 「如何撰寫提示」 | 「提示 AI 時，它知道些什麼」 |
上下文工程不是「一股腦地塞更多資訊」。它講究的是精準配量。太少，AI 就缺少上下文並產生幻覺；太多，AI 就會淹沒在雜訊中、在中途失去方向，成本也更高。
提示工程處理的是最後一步。上下文工程處理的是之前的一切。
為什麼 100 萬個 token 不代表「全部塞進去」？
重點
2026 年的模型上下文視窗擴大了：Claude Opus 4.7 和 Sonnet 4.6 支援 1 million tokens。這讓人誤以為可以把整個儲存庫塞進視窗。實際上，視窗大不代表有用的記憶量也大——模型在達到上限前很久，效能就開始下降。
Claude 模型目前的上下文限制如下：
| 模型 | 上下文視窗 | 適用方案 |
|---|---|---|
| Claude Haiku 4.5 | 200,000 tokens | 所有方案 |
| Claude Sonnet 4.6 | 1,000,000 tokens | 含使用額度的 Pro+ |
| Claude Opus 4.7 | 1,000,000 tokens | Pro、Max、Team、Enterprise |
1M tokens 約等於 2,500 頁文字。看起來似乎可以載入所有專案文件、所有往來信件和所有規格，然後讓 AI 自己判斷。但 Anthropic 在工程部落格中明確指出：
你應該將上下文視為效益遞減的有限資源。
換句話說，上下文是效益遞減的有限資源。每增加一個 token，效益不會等比例增加。視窗越長，模型處理其中資訊的表現就越差。
2026 年的主要技能不是讓所有內容都保持開啟，而是在狹窄的上下文之間快速切換，每項任務各用一個上下文。
最大的錯誤：上下文越多，結果越差嗎？
重點
上下文越長，模型處理其中資訊的表現就越差。這種現象稱為上下文劣化。「迷失在中間」效應也會發生：模型記得上下文的開頭和結尾，卻略過中間部分。實際結論是，長篇記憶檔案會對你不利。
第二種效應「迷失在中間」也會同時發生。
實際上，如果重要規則位於 CLAUDE.md 檔案的中間，模型就可能略過它。
Anthropic 在 CLAUDE.md 文件中建議設定長度上限：
盡量將 CLAUDE.md 控制在 200 行以內——較長的檔案會消耗更多上下文，並降低指令遵循度。
引文中的少於 200 行是長度目標，不是超過便停止遵循規則的硬門檻。80–120 行來自作者所述專案的偏好，並非 Anthropic 的另一項要求。請維持相關內容，實測重要規則是否遵循；增加的每行都會競爭注意力與上下文。如需了解如何設定 CLAUDE.md 以符合此限制，請參閱指南「如何在 2026 年設定 CLAUDE.md」。
Anthropic 提出的上下文工程 5 項原則
重點
Anthropic 在 2025 年 9 月 29 日的工程部落格中，記錄了 5 項基本上下文策略：有限資源、即時擷取、結構化筆記、壓縮，以及子代理架構。如今，其他討論這個主題的作者都會引用這些核心內容。
原則 1. 上下文是有限資源
這是基本前提，缺少它，其他四項原則便無法運作。Anthropic 寫道：
對上下文的所有組成要素（系統提示、工具、範例、訊息歷史等），一般建議都是審慎處理，並讓上下文資訊充足且精簡密實。
「精簡」代表「內容密實、沒有填充文字」。視窗中的每個 token 都應實質影響模型的判斷。如果 CLAUDE.md 中有一行寫著「我們盡量撰寫乾淨的程式碼」，可以刪掉，因為它沒有傳達有效訊號。
原則 2. 即時擷取
AI 代理會透過工具即時擷取資料，而不是預先將所有內容載入視窗。這就是 Claude Code 的架構：代理不是使用向量資料庫或索引，而是使用 glob 和 grep，就像工程師在 IDE 當掉時手動搜尋程式碼。
使用時機：你無法事先得知任務會需要哪些段落。
原則 3. 結構化筆記
代理會將筆記寫入外部儲存空間，並在需要時載入。在 Claude Code 中，這是透過記憶工具實現的。Anthropic 在 Cookbook 中如此描述：
記憶是結構化的筆記：代理會寫入持續保存的外部儲存空間，追蹤不同任務與工作階段的進度，而不必將所有內容留在目前的上下文中。
使用時機：長時間工作階段、工作階段之間的轉換，以及累積專案知識。
原則 4. 壓縮
接近限制時，將訊息歷史壓縮成摘要。在 Claude Code 中，這包括 /compact 命令，以及視窗用量達到約 80% 時觸發的自動壓縮。Anthropic 寫道：
當整個視窗變得太大時，壓縮會將它縮小。
使用時機：長時間的分析對話中，聊天歷史已成為多餘負擔，佔滿視窗卻無助於工作。
原則 5. 子代理架構
專業化的子代理會在各自的上下文視窗中並行工作，再將精簡摘要交給主代理。Anthropic 寫道：
子代理有助於壓縮：它們在各自的上下文視窗中並行工作，同時調查問題的不同面向。
Anthropic 自家內部測試的數據顯示：由 Claude Opus 4 主代理搭配 Claude Sonnet 4 子代理，在研究任務上的品質比單一 Claude Opus 4 高出 +90.2%。代價是 token 約增加 15 倍。結論是：成果價值高時，這種做法才值得採用。
如需了解如何在 Claude Code 中設定子代理，請參閱指南「Claude Code 的子代理」。
7 個浪費 token 並破壞 Claude Code 的錯誤
重點
以下以專案案例介紹 7 個常見反模式。每一種都會毫無效益地浪費 token，或因上下文劣化而導致幻覺。每項錯誤下方都說明上下文工程如何處理。
| # | 反模式 | 會發生什麼事 | 解決方法 |
|---|---|---|---|
| 1 | 把整份 README 和 5 個程式碼檔案貼進同一個提示 | 一個回合就填滿 50% 的視窗，之後很快達到上限 | 長期事實交給記憶工具，並採用即時擷取——讓 Claude 透過 read_file/glob 自行讀取檔案 |
| 2 | 500 行的 CLAUDE.md | 長指示可能降低遵循情況，尤其重要規則埋在中段時 | 控制在 80-120 行，使用祈使句，並為命令和風格分段。最重要的內容放在開頭和結尾 |
| 3 | 長時間工作階段中不執行 /compact | 工作階段達到 180k tokens，Claude 忘記最初的訊息，你得手動重述上下文 | 手動執行 /compact，或使用觸發式自動壓縮。Claude 桌面版的上下文用量指示器可作為負荷過高的徵兆 |
| 4 | 所有事情都交給一個 Claude | 一個代理負責規劃、搜尋、撰寫程式碼、審查和測試，視窗會以指數速度膨脹 | 使用子代理：每個子代理都有自己的上下文，由主代理彙整摘要。Anthropic 報告研究任務的品質提高 +90.2% |
| 5 | 記憶檔案被工具結果塞得愈來愈大 | 代理重讀同一個檔案 5 次，工具呼叫結果填滿 96% 的上下文 | 清除工具結果：保留最近 4-6 個結果，其餘清除。呼叫曾經發生過這件事會保留下來 |
| 6 | 把整個儲存庫都貼進 examples/ 資料夾 | AI 在 200 個範例中搜尋模式，結果迷失方向 | 在 examples/ 中放 3-7 個代表性模式，每個模式對應特定任務類型 |
| 7 | 用 200 行的 Markdown 清單當作「功能計畫」 | 長而無結構的清單可能讓任務追蹤更難，但沒有第 50 行就失效的普遍分界 | 改用 HTML 成品，或另存一份編號計畫 |
Anthropic 的 Cookbook 描述了錯誤 #5 的一項具體測量結果：在基準工作階段中，上下文裡的第一份文件（關於秀麗隱桿線蟲 C. elegans）在技術上仍位於視窗內，卻被 335k tokens 淹沒。理論上可以存取，實際上模型卻想不起來。使用記憶工具後，問題便以這種方式解決：aging_model_organisms_comparison.md 筆記檔約 3000 tokens，不必重新載入原始語料。
用日常生活來比喻：上下文視窗就像一張桌子。上面放著 200 份文件，即使你要找的那份就在桌上，也找不到。上下文工程就是「桌面上只留現在需要的東西，把其他內容存檔，並在需要時載入」的技術。
如何在一個晚上組出可用的設定？
重點
Claude Code 最基本且可用的上下文工程設定包含 7 個要素：CLAUDE.md、examples、PRP 文件、記憶工具、/compact、子代理，以及透過工具即時擷取資訊。基本架構需要 30-40 分鐘設定；包含範例和經驗證提示的完整設定則需要一個晚上。你可以邊用邊改善。
依序進行以下 7 個步驟：
80-120 行的 CLAUDE.md。 放在專案根目錄。使用祈使句，而不是描述句。Anthropic 在官方文件中建議遵循
Specificity原則：規則應具體且明確，不應只是一般原則。實務上，「測試中絕不使用 inline mocks」比「我們盡量撰寫乾淨的程式碼」更有效。詳細範本請參閱指南「如何設定 CLAUDE.md」。建立含有 3-7 個已驗證模式的
examples/資料夾。 每個常見模式各放一個範例：API 呼叫、撰寫測試、遷移、錯誤處理。Claude 在examples/中看到模式時，就會精確重現。沒有範例時，它就會邊做邊猜。為主要功能撰寫 PRP 文件。 PRP = Product Requirements Prompt。每項功能一個檔案：上下文 + 計畫 + 驗證 + 範例。
用記憶工具保存跨工作階段的長期資訊。 在 Anthropic 的 Cookbook 中，Claude 的記憶工具以結構化筆記儲存區的方式實作。代理在新工作階段回到任務時，會先讀取筆記，而不是重新閱讀整個語料。
使用
/compact，並在達到上限 80% 時啟用自動壓縮。 不要等到視窗抵達上限。你可以在設定中啟用自動壓縮，或在覺得工作階段開始原地打轉時自行執行/compact。將子代理用於研究／審查／規劃。 每個子代理都有自己的上下文和範圍明確的提示。主代理 Claude 只會收到摘要，不會收到原始資料。詳情請參閱「Claude Code 的子代理」和「Claude Code 的 Skills」（Skills 是一種封裝特定專業知識，讓 Claude 自動套用的方法）。
使用即時擷取，而不是預先載入。 不要把整個儲存庫塞進視窗。讓 Claude 自行透過
glob和grep搜尋。這正是 Claude Code 本身的架構。
文中提到的專案經驗也提供了以下實用規則：
- 一項任務，一個視窗。 完成後關閉視窗並開啟新的。不要在好幾項連續任務之間累積歷史紀錄。
- 新視窗第一個命令的範本。 每次都使用相同文字：「依序讀取
CLAUDE.md和任務區域。用一行確認。不要開始任務；等待下一則訊息。」在文中描述的工作流程裡，這個範本儲存在文字片段編輯器中，並透過單一快速鍵呼叫。 - 上下文視窗超過 60% 時，切換到新視窗。 一種過渡做法是請 Claude「寫一個提示，讓旁邊的聊天能接續你的任務而不失去原意」，複製後開啟新視窗。
- 每一次 AI 錯誤都是新增規則的理由。 不要手動把規則寫進記憶檔案。出錯當下告訴 Claude「這樣不對，因為……」，它就會依照「規則 → 原因 → 方法」慣例整理成檔案。
接下來：上下文工程這門學科將如何發展？
重點
2026 年，上下文工程正從以文字為主的 Markdown 檔案轉向更有結構的格式。Dreaming 功能也已出現，代理會在夜間重新檢視過往工作階段。接下來是 HTML 成品、持續記憶，以及跨整個產品團隊的多代理協作。
這門學科目前的一個發展方向：
Dreaming——夜間重新檢視工作階段。 在 2026 年 5 月 6 日舉行的 Code w/ Claude SF 活動中，Anthropic 展示了一項功能：代理會在夜間重新檢視過往工作階段並更新自己的筆記。現在，結構化記憶檔案不只會在你寫入時增加內容，也會在代理從累積經驗中歸納結論時增長。
有一個趨勢很明確：上下文工程正成為一門完整學科，專門為 AI 代理設計資訊，而不只是「如何撰寫 CLAUDE.md」。提示工程是這門學科最初的層次之一。下一個階段就是上下文工程。
第一個晚上值得完成的最低限度設定：將 CLAUDE.md 控制在 80-120 行（指南在此）、建立一個整理商業知識的資料夾、學會使用 /compact，以及停止浪費使用額度。
接著，加入子代理（指南）和 Skills，把專業知識從共用上下文移到專用技能中。
來源
- 有效的 AI 代理上下文工程 - Anthropic Applied AI team，29.09.2025。包含 4 項上下文工程原則的核心文章。
- 我們如何打造多代理研究系統 - Anthropic Engineering，13.06.2025。品質 +90.2% 與 token 15 倍這兩項數據的來源。
- Anthropic Cookbook - 使用工具進行上下文工程 - 實用基本功能：壓縮、清除工具結果，以及記憶工具。
- Claude Code 記憶文件 - 說明精簡、具體的專案指示；引文目標是少於 200 行，80–120 行則為作者偏好。
來認識 Ailoot。
更多詳情
常見問題：2026 年的上下文工程：它是什麼、與提示工程有何不同，以及如何在 Claude Code 中應用
CLAUDE.md 的 200 行是硬性上限嗎？
不是。引文建議少於 200 行以節省上下文並改善遵循，作者的 80–120 行是實務偏好。請在真實任務驗證重要規則，不要把行數當成保證。
哪些內容應移出初始上下文？
詳細範例、長工具結果與特定任務參考資料，應放在獨立檔案。CLAUDE.md 保留精簡規則與指引，需要時再擷取相關段落。