Context Engineering 取代 Prompt Engineering — 1M 窗口時代的 AI 協作方法論
學 AI 的第一步通常是學怎麼寫 prompt。但當你真的用 Agent 工具跑專案之後會發現，問對問題只是起點——AI 在後續每一步做的決策，取決於它當下 context 裡有什麼，而不是你一開始的指令寫得多好。這就是上下文工程（Context Engineering）正在取代提示工程（Prompt Engineering）的原因。
- Prompt Engineering 解決單次互動的品質，但 Agent 工具是多步驟自主執行——prompt 只是起點，後續決策品質取決於 context 裡有什麼。
- Context Engineering 是「設計一個系統，讓 AI 在每次做決策時都有正確的上下文」，核心操作是常駐精簡、按需載入、跨 session 延續、上下文隔離。
- 1M context window 提高了能力上限，但沒有降低管理複雜度——注意力機制（Attention）的有限性沒有消失，frontier model 能穩定遵循的指令數仍是約 150-200 條。
Prompt 寫得再好，放在混亂的 Context 裡也會失效
Prompt Engineering 解決的是「單次互動」的品質：你問一個好問題，AI 給一個好答案。這在 ChatGPT 的一問一答場景中確實有效。
但 Agent 工具不是一問一答。Claude Code、Cursor、Copilot 這類工具是「多步驟自主執行」——收到任務後自己決定讀哪些檔案、跑什麼指令、怎麼驗證結果。Anthropic 在《Building Effective Agents》中定義 Agent 為「LLM 動態決定自身流程與工具使用的系統」。你的 prompt 只是起點，之後每一步的決策品質取決於它當下 context 裡裝了什麼。
真實案例：我的 blog-writer 專案有一套 8 步驟轉寫流程，prompt 寫得很清楚。但因為 CLAUDE.md 塞了 300 行（角色設定、14 家公司來源清單、三種平台格式規範全混在一起），Claude 在第 6 步產出格式時已經「注意力漂移」，直接跳過第 7 步的 fact-check。問題不在指令寫得不好，在於 context 被污染了。後來我把 CLAUDE.md 從 300 行壓縮到 40 行，把格式規範和查核規則拆成按需載入的 Skills，同樣的 prompt，執行穩定性馬上提升。
Prompt 再好，放在一個混亂的 context 裡也會失效。這不是 prompt 的問題，是系統設計的問題。
Context Engineering 的四個操作面向
Bojie Li 對 Claude 架構的分析中有一句話很精準：「Claude is already smart enough — intelligence is not the bottleneck, context is.」Claude 夠聰明了，瓶頸不在智力，在上下文。
Context Engineering 的定義：不是「怎麼問好問題」，而是「怎麼設計一個系統，讓 AI 在每次做決策時都有正確的上下文」。前者是一次性的技巧，後者是持續性的系統設計。
從我的實作經驗，Context Engineering 有四個具體的操作面向：
常駐資訊只放每次都需要的東西
根據 HumanLayer 的分析，frontier model 能穩定遵循的指令數約 150-200 條，而 Claude Code 的系統指令本身就吃掉約 50 條。你的 CLAUDE.md 只有 100-150 條的 budget。每多放一條「以防萬一」的規則，就是在稀釋每一條真正重要的規則。我的做法是壓縮到 40 行核心骨架。
按需載入：需要時才給，用漸進式揭露控制 token 成本
Anthropic 的 Skills 機制採用漸進式揭露（Progressive Disclosure）——啟動時只載入 metadata（約 100 token），被觸發時才讀取完整內容。寫作風格指南 3000 字，不用每次 session 都佔用 context。這跟 Bojie Li 提出的 Context Engineering 四大支柱之一「Just-in-time data retrieval」是同一個原則：用輕量索引取代全量預載。
跨 Session 延續：用 200 token 交接文件換零重複溝通
HANDOFF.md 記專案進度、article-log.md 記寫過什麼。不是讓 AI 記住所有事，而是用最精簡的結構把跨 session 需要延續的資訊存下來，放在 Claude 每次都能讀到的地方。200-400 token 的交接文件，換來零重複溝通的 session 銜接。
上下文隔離：別讓研究任務污染主對話
子代理（Subagent）在獨立的 context window 中運作，只回傳摘要結果。當你讓 Claude 研究一個問題時，它讀取的每個檔案都會吃掉主對話的 context。派一個子代理去調查，帶結論回來就好。
核心洞察：好的 Context Engineering 不是給 AI 更多資訊，是讓它在正確的時間點拿到正確的資訊。「以防萬一多放一點」是最常見的反模式（Anti-pattern）。
1M Context Window 提高了上限，但注意力瓶頸沒變
Anthropic 在 2026 年 3 月正式宣布 Claude 1M token context window 全面開放（GA）。Opus 4.6 和 Sonnet 4.6 都支援，標準費率不加收溢價（Opus 4.6 維持 $5/$25 per million tokens）。Claude Code 的 Max、Team、Enterprise 用戶自動使用 1M 空間。Opus 4.6 在 MRCR v2 基準測試拿到 78.3%，是 frontier model 在該 context 長度的最高分。
直覺反應可能是：空間變 5 倍，什麼都塞進去不就好了？
不是這樣的。Attention 有限性沒有因為窗口變大而消失。根據 HumanLayer 的分析，frontier model 能穩定遵循的指令數還是約 150-200 條。Claude Code 系統指令吃掉約 50 條。1M 窗口塞 300 行 CLAUDE.md，注意力分配問題跟 200K 時一模一樣——LLM 優先關注的是 prompt 的頭尾兩端，中間的內容接收到的注意力最少。
1M 的真正價值在別的地方：
- 單次 session 能做更大的任務——整個 codebase 一次讀入、幾百頁文件直接分析，不需要切片
- 壓縮觸發頻率降低——92% 的 1M 比 92% 的 200K 多出大量空間，有用戶回報 compaction 事件減少了 15%，早期決策保留更久
- 媒體處理能力提升——從 100 張提升到 600 張圖片或 PDF 頁面
但壓縮的本質沒變：它是摘要，摘要就是細節遺失。窗口再大，你的指令 budget 還是那麼多。
用一個類比來說：1M 就像辦公桌從 1 坪變 5 坪。如果你本來就不擅長整理，桌子再大還是會亂。Context Engineering 就是「整理桌面的方法論」。1M 提高了能力上限，但沒有降低管理複雜度。Context Engineering 解決的是後者。
而且，當每個人都有 1M 的窗口，差別就不再是「誰的桌子大」，而是「誰整理得好」。硬體限制越來越少，軟性的設計能力就越來越重要。
我的觀點
這是「AI Agent 協作系統設計」系列的第三篇，也是收束。三篇的底層邏輯一致：你不是在「用工具」，你是在「設計一個讓工具穩定運作的系統」。第一篇講怎麼分層，第二篇講怎麼跨 session 記憶，這篇拉高到方法論層級。
Context Engineering 不是 Claude Code 專屬概念。任何 Agent 工具——Cursor、Windsurf、Copilot、未來還沒出現的工具——都面臨同樣的架構挑戰。上下文管理、任務驗證、代理分工，這套思路可以直接搬過去。對想進入 AI 領域的人來說，比起學某個工具的操作，理解「怎麼設計人和 AI Agent 的協作系統」才是可遷移的核心能力。
門檻不是技術，是思維方式的轉換：從「我要 AI 做什麼」變成「我要設計什麼系統讓 AI 穩定工作」。Anthropic 說得好——最成功的 Agent 實作不是用複雜框架，而是簡單、可組合的模式。把你的 CLAUDE.md 拆乾淨、把交接文件寫好、把驗證流程自動化——這些不需要寫一行程式碼，但效果比任何 prompt 技巧都大。
Context Engineering 和 Prompt Engineering 可以共存嗎？
完全共存，而且相輔相成。Prompt Engineering 優化的是「單次輸入」的品質，Context Engineering 優化的是「AI 做決策時的整體資訊環境」。好的 prompt 放在好的 context 裡效果最佳。但如果只有好 prompt 沒有好 context，Agent 在多步驟執行過程中遲早會偏離。
1M context window 夠用了嗎？還需要管理 context 嗎？
1M 解決的是「裝不裝得下」的問題，Context Engineering 解決的是「注意力分配」的問題。根據 HumanLayer 分析，frontier model 能穩定遵循的指令數仍是約 150-200 條，不會因為窗口從 200K 變成 1M 就翻倍。空間夠大讓壓縮觸發更少，但指令 budget 不變。
不是工程師也需要懂 Context Engineering 嗎？
需要。Context Engineering 的核心是「資訊架構設計」，不是寫程式。PM 決定哪些規則常駐、哪些按需載入、怎麼做跨 session 交接——這些都是資訊管理和流程設計的工作。用 Claude Code 的 CLAUDE.md、Skills、HANDOFF.md 不需要寫任何程式碼。
系列導讀：AI Agent 協作系統設計
本文是「AI Agent 協作系統設計」系列的第三篇。三篇可獨立閱讀，也可依序建立完整的知識體系。
- Claude Code 用久了為什麼會「變笨」？用六層架構的系統設計思維來解決 — 單次 session 內的上下文管理：怎麼把臃腫的 CLAUDE.md 拆分成精簡指令 + 按需載入的 Skills。
- AI 每次都像失憶？用 HANDOFF 模式解決跨 Session 的記憶斷層 — 跨 session 的記憶延續：用交接文件讓新 session 零重複溝通地接手工作。
- 從 Prompt Engineering 到 Context Engineering — 為什麼會問問題已經不夠用了（本篇）— 把前兩篇的做法拉高到方法論層級，解釋為什麼上下文設計比 prompt 技巧重要。
本文為 gwarket 原創內容，作者 Aaron Huang。