# 2026 年的上下文工程：它是什麼、與提示工程有何不同，以及如何在 Claude Code 中應用 > 什麼是上下文工程，以及它與提示工程有何不同。Anthropic 的核心資料、7 個常見錯誤，以及 Claude Code 的最小化設定。 Source: https://ailoot.ai/blog/zh-hant-tw/context-engineering/ Canonical: https://ailoot.ai/blog/zh-hant-tw/context-engineering/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-037 Revision: sha256-4b78c74602ae862e4e6cadd2dd9f5a994aa6e5161c242af0fd5c446b0d069571
重點 上下文工程是一門設定 Claude 上下文視窗中、訊息送出前所有內容的技術：系統提示、工具、歷史紀錄、記憶檔案，以及工具提供的資料。到了 2026 年，它已取代提示工程，成為關鍵技能——Anthropic 這麼說。本指南整理一手來源中的核心內容、7 個會浪費 token 的常見錯誤，以及 Claude Code 的實用 7 步驟設定方法。
如需了解如何使用 Ailoot，請參閱[文件](https://ailoot.ai/docs/)。 ## 一句話說明：什麼是上下文工程？
重點 上下文工程是一門整理 AI 代理每個步驟中上下文視窗所含資訊的技術：系統提示、工具、歷史紀錄、記憶檔案，以及外部來源的資料。提示工程回答的是「如何撰寫提示？」上下文工程回答的是「你撰寫提示時，AI 知道些什麼？」
Anthropic 在 2025 年 9 月 29 日的一篇工程部落格文章中確立了這個詞：
上下文工程是指在 LLM 推論期間，選擇並維持最佳 token（資訊）集合的一系列策略，其中包含提示本身以外所有輸入的內容。
— Anthropic Applied AI team, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
同一篇文章也提出了最能改變思考角度的一句話：
使用語言模型，正逐漸從在提示中尋找合適的詞句，轉向回答一個更廣泛的問題：「哪種上下文配置最可能產生預期的模型行為？」
— Anthropic Applied AI team, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
核心概念是：上下文不是你撰寫的訊息。上下文是 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 在工程部落格中明確指出：
你應該將上下文視為效益遞減的有限資源。
— Anthropic Applied AI team, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
換句話說，上下文是效益遞減的有限資源。每增加一個 token，效益不會等比例增加。視窗越長，模型處理其中資訊的表現就越差。 2026 年的主要技能不是讓所有內容都保持開啟，而是在狹窄的上下文之間快速切換，每項任務各用一個上下文。 ## 最大的錯誤：上下文越多，結果越差嗎？
重點 上下文越長，模型處理其中資訊的表現就越差。這種現象稱為上下文劣化。「迷失在中間」效應也會發生：模型記得上下文的開頭和結尾，卻略過中間部分。實際結論是，長篇記憶檔案會對你不利。
第二種效應「迷失在中間」也會同時發生。 實際上，如果重要規則位於 CLAUDE.md 檔案的中間，模型就可能略過它。 Anthropic 在 CLAUDE.md 文件中建議設定長度上限：
盡量將 CLAUDE.md 控制在 200 行以內——較長的檔案會消耗更多上下文，並降低指令遵循度。
— Anthropic, https://code.claude.com/docs/en/memory
引文中的少於 200 行是長度目標，不是超過便停止遵循規則的硬門檻。80–120 行來自作者所述專案的偏好，並非 Anthropic 的另一項要求。請維持相關內容，實測重要規則是否遵循；增加的每行都會競爭注意力與上下文。如需了解如何設定 CLAUDE.md 以符合此限制，請參閱指南[「如何在 2026 年設定 CLAUDE.md」](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)。 ## Anthropic 提出的上下文工程 5 項原則
重點 Anthropic 在 2025 年 9 月 29 日的工程部落格中，記錄了 5 項基本上下文策略：有限資源、即時擷取、結構化筆記、壓縮，以及子代理架構。如今，其他討論這個主題的作者都會引用這些核心內容。
### 原則 1. 上下文是有限資源 這是基本前提，缺少它，其他四項原則便無法運作。Anthropic 寫道：
對上下文的所有組成要素（系統提示、工具、範例、訊息歷史等），一般建議都是審慎處理，並讓上下文資訊充足且精簡密實。
— Anthropic Applied AI team, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
「精簡」代表「內容密實、沒有填充文字」。視窗中的每個 token 都應實質影響模型的判斷。如果 CLAUDE.md 中有一行寫著「我們盡量撰寫乾淨的程式碼」，可以刪掉，因為它沒有傳達有效訊號。 ### 原則 2. 即時擷取 AI 代理會透過工具即時擷取資料，而不是預先將所有內容載入視窗。這就是 Claude Code 的架構：代理不是使用向量資料庫或索引，而是使用 `glob` 和 `grep`，就像工程師在 IDE 當掉時手動搜尋程式碼。 使用時機：你**無法事先得知**任務會需要哪些段落。 ### 原則 3. 結構化筆記 代理會將筆記寫入外部儲存空間，並在需要時載入。在 Claude Code 中，這是透過記憶工具實現的。Anthropic 在 Cookbook 中如此描述：
記憶是結構化的筆記：代理會寫入持續保存的外部儲存空間，追蹤不同任務與工作階段的進度，而不必將所有內容留在目前的上下文中。
— Anthropic Cookbook, https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
使用時機：長時間工作階段、工作階段之間的轉換，以及累積專案知識。 ### 原則 4. 壓縮 接近限制時，將訊息歷史壓縮成摘要。在 Claude Code 中，這包括 `/compact` 命令，以及視窗用量達到約 80% 時觸發的自動壓縮。Anthropic 寫道：
當整個視窗變得太大時，壓縮會將它縮小。
— Anthropic Cookbook, https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
使用時機：長時間的分析對話中，聊天歷史已成為多餘負擔，佔滿視窗卻無助於工作。 ### 原則 5. 子代理架構 專業化的子代理會在各自的上下文視窗中並行工作，再將精簡摘要交給主代理。Anthropic 寫道：
子代理有助於壓縮：它們在各自的上下文視窗中並行工作，同時調查問題的不同面向。
— Anthropic Engineering, https://www.anthropic.com/engineering/multi-agent-research-system
Anthropic 自家內部測試的數據顯示：由 Claude Opus 4 主代理搭配 Claude Sonnet 4 子代理，在研究任務上的品質比單一 Claude Opus 4 **高出 +90.2%**。代價是 token 約增加 15 倍。結論是：成果價值高時，這種做法才值得採用。 如需了解如何在 Claude Code 中設定子代理，請參閱指南[「Claude Code 的子代理」](https://ailoot.ai/blog/zh-hant-tw/claude-code-subagents/)。 ## 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 個步驟： 1. **80-120 行的 CLAUDE.md。** 放在專案根目錄。使用祈使句，而不是描述句。Anthropic 在[官方文件](https://code.claude.com/docs/en/memory)中建議遵循 `Specificity` 原則：規則應具體且明確，不應只是一般原則。實務上，「測試中絕不使用 inline mocks」比「我們盡量撰寫乾淨的程式碼」更有效。詳細範本請參閱指南[「如何設定 CLAUDE.md」](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)。 2. **建立含有 3-7 個已驗證模式的 `examples/` 資料夾。** 每個常見模式各放一個範例：API 呼叫、撰寫測試、遷移、錯誤處理。Claude 在 `examples/` 中看到模式時，就會精確重現。沒有範例時，它就會邊做邊猜。 3. **為主要功能撰寫 PRP 文件。** PRP = Product Requirements Prompt。每項功能一個檔案：上下文 + 計畫 + 驗證 + 範例。 4. **用記憶工具保存跨工作階段的長期資訊。** 在 Anthropic 的 Cookbook 中，Claude 的記憶工具以結構化筆記儲存區的方式實作。代理在新工作階段回到任務時，會先讀取筆記，而不是重新閱讀整個語料。 5. **使用 `/compact`，並在達到上限 80% 時啟用自動壓縮。** 不要等到視窗抵達上限。你可以在設定中啟用自動壓縮，或在覺得工作階段開始原地打轉時自行執行 `/compact`。 6. **將子代理用於研究／審查／規劃。** 每個子代理都有自己的上下文和範圍明確的提示。主代理 Claude 只會收到摘要，不會收到原始資料。詳情請參閱[「Claude Code 的子代理」](https://ailoot.ai/blog/zh-hant-tw/claude-code-subagents/)和[「Claude Code 的 Skills」](https://ailoot.ai/blog/zh-hant-tw/claude-code-skills-library/)（Skills 是一種封裝特定專業知識，讓 Claude 自動套用的方法）。 7. **使用即時擷取，而不是預先載入。** 不要把整個儲存庫塞進視窗。讓 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 行（[指南在此](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)）、建立一個整理商業知識的資料夾、學會使用 `/compact`，以及[停止浪費使用額度](https://ailoot.ai/blog/zh-hant-tw/claude-code-token-limits-saving/)。 接著，加入子代理（[指南](https://ailoot.ai/blog/zh-hant-tw/claude-code-subagents/)）和 [Skills](https://ailoot.ai/blog/zh-hant-tw/claude-code-skills-library/)，把專業知識從共用上下文移到專用技能中。
### 來源 - [有效的 AI 代理上下文工程](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - Anthropic Applied AI team，29.09.2025。包含 4 項上下文工程原則的核心文章。 - [我們如何打造多代理研究系統](https://www.anthropic.com/engineering/multi-agent-research-system) - Anthropic Engineering，13.06.2025。品質 +90.2% 與 token 15 倍這兩項數據的來源。 - [Anthropic Cookbook - 使用工具進行上下文工程](https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools) - 實用基本功能：壓縮、清除工具結果，以及記憶工具。 - [Claude Code 記憶文件](https://code.claude.com/docs/en/memory) - 說明精簡、具體的專案指示；引文目標是少於 200 行，80–120 行則為作者偏好。
來認識 [Ailoot](https://ailoot.ai/)。 ## 常見問題：2026 年的上下文工程：它是什麼、與提示工程有何不同，以及如何在 Claude Code 中應用 ### CLAUDE.md 的 200 行是硬性上限嗎？ 不是。引文建議少於 200 行以節省上下文並改善遵循，作者的 80–120 行是實務偏好。請在真實任務驗證重要規則，不要把行數當成保證。 ### 哪些內容應移出初始上下文？ 詳細範例、長工具結果與特定任務參考資料，應放在獨立檔案。CLAUDE.md 保留精簡規則與指引，需要時再擷取相關段落。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。