你一定用過 ChatGPT 或 Claude。但你有沒有發現一件怪事：同一個問題，你給的資訊不一樣，答案會天差地遠？問「幫我總結這場會議」，AI 可能寫出一堆廢話；但如果你把逐字稿貼進去、告訴它這份摘要要給老闆看、再附上上次的格式範本——它突然就變得很聰明。差別不在你「問得多漂亮」，而在你「餵了什麼給它」——這，正是上下文工程（Context Engineering）要解決的問題。
2025 年年中，矽谷工程師圈幾乎在幾週之內，從滿口「Prompt Engineering（提示工程）」改口談一個新詞：Context Engineering（上下文工程）。Shopify 執行長、OpenAI 創始成員 Andrej Karpathy、再到 Anthropic 官方部落格，全都在講同一件事。這篇文章，就是要用最白話的方式，帶完全沒有技術背景的你，從零搞懂什麼是上下文工程——它到底是什麼、和提示工程差在哪、為什麼突然這麼紅，以及你今天打開 ChatGPT 就能用上的幾個技巧。不寫一行你看不懂的程式碼。（先說在前面：本文無業配內容。）
先說結論：一句話搞懂上下文工程
🎯 一句話結論：上下文工程（Context Engineering），就是「幫 AI 管理它那塊有限的『工作記憶』」這門功夫。
把 AI 的「情境視窗（context window）」想成電腦的 記憶體（RAM）：又快、又小、又不持久。提示工程決定「你怎麼問」；上下文工程決定「AI 回答的那一刻，腦袋裡到底裝了什麼」。前者是後者的一小部分——用數學講就是「提示工程 ⊂ 上下文工程」。你的工作不是把所有東西塞進去，而是剛剛好地放入「下一步需要的正確資訊」，不多也不少。
零基礎前置：先搞懂三個詞，後面才看得懂
上下文工程這個題目，網路上幾乎所有文章都「預設你已經懂」。我們不這樣。先花 30 秒，把三個關鍵字講成人話：
- Token（詞元）＝ AI 眼中的「字」。AI 不是一個字一個字讀，而是把文字切成一塊一塊的 token（大致上，1 個英文單字約 1 個 token，1 個中文字約 1～2 個 token）。所有「長度」「費用」「上限」最後都是用 token 在算。
- 情境視窗（Context Window）＝ AI 的「單一輸入框」，能裝多少 token 有上限。你貼的問題、它的回答、之前的對話、你附的文件……全部都要擠進這一格。它就是 AI 的「工作記憶」，這篇文章的主角。
- AI Agent（AI 代理）＝ 一個「會自己跑很多步、還會用工具」的 AI。它不只回你一句話，而是會上網查、讀檔案、執行指令，一步接一步完成任務。（想更完整理解，可看我們的〈Agent Harness 是什麼〉。）
記住這句口訣就好：情境視窗就是 AI 的工作記憶，而且它很小、很貴。上下文工程，整門學問就是在管理這一格。
上下文工程 vs 提示工程：到底差在哪？
很多人第一個反應是：「這不就是提示工程換個名字嗎？」這個質疑很合理，連業界都還在吵（後面〈誠實的一面〉會講）。但最站得住腳的講法是：它不是改名，而是「升級」與「校正」。
- 提示工程（Prompt Engineering）＝ 把「一句話」寫好。重點在你怎麼措辭、怎麼下指令。它處理的是「一段文字字串」。
- 上下文工程（Context Engineering）＝ 設計「一整套系統」，在對的時間、用對的格式，把對的資訊和工具都準備好，讓 AI「回答的當下」擁有完成任務所需的一切。它處理的是系統指令、記憶、你附的文件、工具、對話歷史……整個資訊環境。
Google DeepMind 的工程師 Philipp Schmid 有一個很傳神的比喻：上下文工程是「一套系統，而不是一串字」（a system, not a string）——提示工程處理的是「單一一串文字」，上下文工程則是「一整套在 AI 回答前先跑起來的系統」。提示工程沒有消失，它變成了上下文工程裡的「一個工具」。下面這張對照圖，幫你一眼看懂兩者的分工：
這個詞是誰發明的？其實沒有單一發明人——這個說法在爆紅之前就有人零星在用。我們查得到、且早於這波熱潮的一次使用，來自 Braintrust 創辦人 Ankur Goyal（2025 年 4 月 20 日）；真正讓它一夜爆紅的，是 Shopify 執行長 Tobi Lütke（6 月 19 日）和 Andrej Karpathy（6 月 25 日）。Karpathy 那句定義堪稱經典，值得抄下來：「上下文工程，是一門精細的藝術與科學——在情境視窗裡，剛剛好地填入『下一步』所需要的正確資訊。」之後 Anthropic 在官方工程部落格（2025 年 9 月 29 日）把它正式定義為「提示工程的自然延伸」。注意：Anthropic 是「定義並推廣」，不是「發明」這個詞。
核心原理：為什麼「給越多資訊」反而越糟？
新手最大的直覺誤會是：「那我把所有資料一次全部貼給 AI，它不就最聰明了嗎？」恰恰相反。這裡有兩個你一定要懂的觀念。
① 情境視窗 = 記憶體（RAM），不是硬碟
這個比喻最早來自 2023 年的學術研究 MemGPT，現在幾乎成了業界共識：情境視窗像電腦的 RAM，不像硬碟。硬碟可以無限堆東西、慢慢找；RAM 又快又小，而且關機就沒了。AI 的工作記憶就是這塊 RAM——你的任務是決定「載入什麼、清掉什麼」，而不是拚命塞。塞太滿，它反而會卡。
② 金髮女孩法則：不能太少，也不能太多
Karpathy 點出了核心矛盾，可以叫它「金髮女孩法則（Goldilocks，剛剛好原則）」：
- 太少、或格式不對：AI 沒有足夠線索，當然做不出來。
- 太多、或太雜：費用變貴，而且答案品質反而下降。一句話總結：「你放進去的每一樣東西，AI 都得分心去看它。」
「太多反而變笨」不是猜的，是有實證的。研究公司 Chroma 在 2025 年 7 月發表的〈Context Rot（情境腐爛）〉報告，測了 18 個主流大模型（涵蓋 Claude、GPT、Gemini、Qwen 等），結論很清楚：模型不會均勻地用完它的視窗——輸入越長，表現會「漸漸地、不平均地」變差，連很簡單的任務都一樣。關鍵是：這種衰退是「逐漸惡化」，不是到上限才突然斷崖式崩潰。所以廠商標榜的「100 萬 token 超大視窗」，意思是「裝得下」，不代表「用得好」。
還有一個很實用的老發現叫「Lost in the Middle（迷失在中間）」（Liu 等人，2023）：模型對「開頭和結尾」的資訊記得最牢，夾在中間的東西最容易被忽略（當年的模型，中間區段的準確率大約掉了 20～30 個百分點）。新一代模型有改善但沒消除。給新手的實戰結論：把最重要的指令放在提示的「最開頭」或「最結尾」，別埋在一大段文字的中間。
四個核心動作：WRITE / SELECT / COMPRESS / ISOLATE
知道「要管理 RAM」之後，具體怎麼管？LangChain 的 Lance Martin 把所有做法歸納成四個動作，這也是全世界談上下文工程最常用的骨架。把它們想成「在 RAM 裡換進換出資料的四招」：
- WRITE（寫下來）：把資訊「存到視窗外面」，等需要時再拿回來。就像把筆記寫在記事本（硬碟）上，而不是全背在腦子（RAM）裡。
白話例子：ChatGPT 的「記憶（Memories）」會自動記住你的偏好，跨對話都還在；AI Agent 會把計畫先寫進一個外部記憶檔，免得對話一長就忘了自己原本要幹嘛。 - SELECT（選重點）：每一步只把「這一步真正需要的」資訊撈進視窗。
白話例子：Claude Code 用CLAUDE.md規則檔、Cursor 和 Windsurf 用「rules（規則）」檔，把該遵守的規範拉進來；這也是大家熟知的 RAG（檢索增強生成）——RAG 講白了，就是「先從你的文件堆裡撈出最相關的幾段，再塞進提示裡」。 - COMPRESS（壓縮其餘）：只留下完成任務必要的 token，其他濃縮或丟掉。
白話例子：Claude Code 的「自動壓縮（auto-compact）」會在對話快塞滿時，把前面一大段濃縮成摘要，再繼續。（這是會隨版本變動的功能細節——Lance Martin 2025 年 6 月那篇寫的是「約 95% 時觸發」，社群後來觀察到的數字又不太一樣，官方文件只說「接近上限時自動壓縮」，沒有公布確切百分比。記住「概念」就好，別記死數字。） - ISOLATE（隔離雜訊）：把脈絡拆開，讓每個部分各管各的。
白話例子：派出「子代理（sub-agent）」去做某件事，子代理有自己獨立的視窗，做完只回報一段精煉的摘要，不會把它讀過的一大堆原始資料倒回主對話裡，污染你的 RAM。
口訣記起來：寫下來、選重點、壓縮其餘、隔離雜訊。這四招，幾乎涵蓋了所有上下文工程技巧。
四種「翻車模式」：脈絡一長，AI 會這樣壞掉
另一個經典框架，來自 Drew Breunig 2025 年 6 月的兩篇文章。他把「脈絡塞太多會出的故障」分成四種。這四個名字配上生活化比喻，新手一次就記住：
- ① 中毒（Poisoning）＝ 白板上被釘了一句假話。一旦某個幻覺（AI 編造的錯誤資訊）混進了脈絡，它之後會一直引用這個錯誤，越錯越離譜。（Breunig 舉的例子是 Gemini 玩寶可夢的 AI，目標被「下毒」後，要花很久才扳得回來。）
- ② 分心（Distraction）＝ 陷在自己的日記裡出不來。對話太長時，AI 開始一直重複「它過去做過的事」，而不是想新辦法。（一份 2024 年 Databricks 的 RAG 研究中，Llama 3.1 405b 的準確率大約從 3.2 萬 token 開始下滑，較小的模型更早。這是特定研究、特定模型的數字，不是通則。）
- ③ 混淆（Confusion）＝ 一個塞了 46 種工具的雜物抽屜。給 AI 太多工具，它反而會拿錯。（同一個模型，給它 46 個工具會失敗，只給 19 個反而成功。）一句話：能少給就少給。
- ④ 打架（Clash）＝ 跟「早一版的自己」吵架。新進來的資訊和脈絡裡舊的資訊互相矛盾，AI 卻死抱著它早先猜的答案不放。
看懂這四種，你就懂為什麼「開新對話」這麼重要——很多時候，與其在一個又臭又長、已經中毒分心的對話裡硬凹，不如直接開一個乾淨的新對話。
省錢的祕密：為什麼「穩定的開頭」這麼重要（KV-cache）
上下文工程不只關乎品質，還關乎錢。這裡有個對開發者超重要、但一般人也該懂的觀念，叫 Prompt Caching（提示快取）。
原理很簡單：如果你每次請求的「開頭那一大段」（系統指令、固定的背景資料）都一模一樣，AI 就能把這段的計算結果「快取」起來重複用，不用每次重算。關鍵規則就一句：「穩定的開頭 ＋ 只往後追加 ＝ 便宜。」反過來，只要你在最前面塞一個會變動的東西（最經典的雷就是「精確到秒的時間戳」），整個快取就失效，全部重算。
省多少？以 Anthropic 官方定價為例（截至 2026 年 6 月）：在 Claude Sonnet 上，命中快取（cache read）的輸入 token 約 $0.30／百萬，標準輸入則是 $3.00／百萬——足足差 10 倍。Anthropic 官方也說，提示快取「最高可降低成本約 90%、降低延遲約 85%」（注意這是「最高」的最佳情境，實際依場景而異）。小提醒：那個便宜的 $0.30 指的是「快取命中（讀取）」價；第一次「寫入」快取反而比標準貴一點（1.25～2 倍），所以快取是「重複使用」時才划算。打造 AI 產品的 Manus 團隊甚至說：「快取命中率，是正式產品級 AI 代理最重要的單一指標。」想更深入省 token 的技巧，可參考我們的〈Claude 省 token 教學〉。
實戰：5 個你今天就能用的上下文工程動作
講了這麼多，到底怎麼開始？不用寫程式，下面 5 個動作，你打開 ChatGPT 或 Claude 就能做：
- 把背景一次餵好，別讓 AI 用猜的。問之前先補齊：「這是給誰看的、目的是什麼、有什麼限制、附上相關文件或範例」。這就是「金髮女孩法則」裡『把對的資訊放進去』。
- 善用「自訂指令／記憶」功能。ChatGPT 的 Custom Instructions、Memories，把「我是誰、我偏好什麼風格」一次設好，之後每次對話自動帶入——這正是 WRITE（寫下來）。
- 換個主題，就開新對話。不要在同一個對話串裡又問程式、又問食譜、又問旅遊。雜訊會害 AI「分心、混淆」。換任務＝按一下「開新對話」清空 RAM。（這就是工程師說的
/clear。） - 重要指令放開頭或結尾。長提示裡，把最關鍵的要求放最前面或最後面，別埋中間（記得「Lost in the Middle」）。
- （給用開發工具的人）寫一份精簡的規則檔。用 Claude Code、Cursor、Windsurf 的話，寫一個
CLAUDE.md或rules檔，把專案規範、慣例寫進去（Claude 官方建議CLAUDE.md控制在 200 行內，越精簡越聽話）。需要時用/compact壓縮、用子代理去做大量查找，把主視窗留乾淨。
進階一眼：真實產品是怎麼做上下文工程的？
想看高手怎麼玩，這三個案例最有名（看不懂細節沒關係，抓概念就好）：
- Manus（AI 代理產品）：把檔案系統當作無限記憶（脈絡裡只留「網址、檔名」這種指標，不留一大坨內文）；讓代理不斷重寫一份
todo.md待辦清單，把目標「拉回最新注意力」，對抗分心；甚至刻意把出錯的訊息留在脈絡裡，讓 AI 學會別再犯同樣的錯。 - Cognition（Devin 的母公司）：主張「別亂蓋多代理系統」——多個子代理平行做事，常因為「彼此看不到對方的完整脈絡」而做出互相矛盾的結果，建議用單一線性的代理 ＋ 一個專門壓縮歷史的模型。
- Claude Code / Cursor / Windsurf：都提供同一套基本功——持久的規則檔（保持精簡）、依路徑生效的規則（只在相關時才載入，省脈絡）、會回報摘要的子代理。這正是把 WRITE／SELECT／COMPRESS／ISOLATE 落地的工具。
對「AI 怎麼一步步自己跑完任務」這件事有興趣的話，建議延伸閱讀〈動手做一個 Agent Harness〉和三方比較的〈Claude vs Claude Code vs Cowork〉。
誠實的一面：什麼時候「不需要」上下文工程？
網路上一堆文章把上下文工程吹成「新時代的超能力」。我們要誠實一點：它比較像「損害控制」，不是「超能力」。它存在的理由，是為了補救一個已知的架構限制（注意力有限、情境腐爛）——它是為「已知的車禍」繫的安全帶，不是一台更快的車。請記住幾個誠實的界線：
- 單次、簡短的問題，根本不用搞這套。如果你只是問一個一兩萬 token 內就講得完、不需要記憶或查資料的問題，寫好一句提示就夠了，硬要做全套反而是「過度工程」。
- 每個技巧都用「一種故障換另一種故障」。壓縮（COMPRESS）會失真——Anthropic 自己承認摘要「本質上是有損的」，壓過頭會漏掉關鍵細節；RAG 會「漏抓」對的段落；子代理會多燒約 15 倍的 token、還可能協調失敗。天下沒有白吃的午餐。
- 「多代理一定比較強」是錯的。這題目前業界還沒定論，要看任務性質：Anthropic 報告多代理在「廣度優先的研究查找」上大勝單代理（內部評測高出 90.2%）；Cognition 卻說平行多代理在「需要一致性的寫作／編碼」上很脆弱。簡單講——平行「讀」適合多代理，一致性「寫」適合單線程。誰賣你「唯一正解的架構」，都是誇大。
- 「換個更大的視窗就好了」也是迷思。前面的 Context Rot 和 Lost in the Middle 都證明：視窗變大，不代表可靠度跟著變大。但反過來，這也意味著上下文工程能救的也有上限——它能讓 AI「不浪費」那 100 萬 token，卻沒辦法逼 AI 真的「用好」全部 100 萬 token。
- 「它只是提示工程改名」這個質疑，部分成立。Anthropic 自己都說它是提示工程的「自然延伸／超集」。把它當成全新學科會過譽；把它當成純炒作又太武斷。最持平的講法就是：提示工程 ⊂ 上下文工程。
常見問題 FAQ
Q1：上下文工程和提示工程是同一件事嗎？
不是，但有重疊。提示工程（把一句話寫好）是上下文工程（設計整個資訊環境）的一個子集。提示工程決定「你怎麼問」，上下文工程決定「AI 回答時知道什麼」。
Q2：我不會寫程式，也需要懂上下文工程嗎？
需要，而且很實用。「餵好背景、開新對話、重要的話放開頭結尾、善用記憶功能」這些都是上下文工程，完全不用寫程式，馬上能提升你用 ChatGPT／Claude 的品質。
Q3：把資料一次全部貼給 AI，是不是最聰明？
不一定，常常更糟。「金髮女孩法則」——太多、太雜的資訊會讓 AI 分心、變貴，品質反而下降。給「剛剛好且相關」的資訊才對。
Q4：廠商說的「100 萬 token 超大視窗」是不是越大越好？
「裝得下」不等於「用得好」。Chroma 的研究顯示，輸入越長、表現會逐漸變差。大視窗是上限，不是品質保證。
Q5：RAG 是什麼？跟上下文工程有關嗎？
有關，RAG 是「SELECT（選重點）」的代表做法。RAG（檢索增強生成）＝ 先從你的文件堆裡撈出最相關的幾段，再放進提示裡讓 AI 參考。它就是「把對的資料選進視窗」的一種技術。
Q6：對話變笨了，我該怎麼辦？
開新對話。對話太長容易「中毒、分心」。換任務或感覺它開始鬼打牆時，最簡單有效的解法就是開一個乾淨的新對話，把背景重新講一次。
Q7：多代理（一堆 AI 一起做）是不是比較強？
看任務。需要「廣度優先、各自獨立查找」時，多代理有優勢；需要「一致性的寫作或編碼」時，單一線性代理通常更穩。沒有放諸四海皆準的答案。
Q8：上下文工程是不是一時的炒作，學了會白學？
底層觀念不會白學。名詞或許會再演化（被併進更大的「AI 工程／代理工程」），但「管理 AI 的有限記憶、給剛剛好的資訊」這個核心思維，只要 AI 還有情境視窗的限制，就一直適用。
給新手的 5 個重點
- 情境視窗 = AI 的工作記憶（RAM）：又快又小又不持久，你的工作是管理它，不是塞爆它。
- 提示工程 ⊂ 上下文工程：前者把一句話寫好，後者設計 AI 回答前的整個資訊環境。
- 金髮女孩法則：給的資訊不能太少（做不出來）、也不能太多（變貴變笨），要剛剛好。
- 四招口訣：WRITE 寫下來、SELECT 選重點、COMPRESS 壓縮其餘、ISOLATE 隔離雜訊。
- 最簡單的兩個習慣：餵好背景、換主題就開新對話。光這兩點，就能讓你用 AI 的品質大幅提升。
📚 延伸閱讀
- Agent Harness 是什麼？——上下文工程是「Harness（執行層）」的一部分，先搞懂 Agent ＝ Model ＋ Harness。
- 動手做一個 Agent Harness——用白話偽代碼，看一個 AI 代理迴圈長什麼樣。
- Claude 省 token 教學——把上下文工程的「省錢」落實成 10 個實戰技巧。
- Claude Opus 4.8 完整解析——看看支援 100 萬 token 視窗的最新模型強在哪。
- Claude vs Claude Code vs Cowork——三大產品差在哪，搭配本文一起看。
- AlphaLab AI 教學總覽｜想更系統地學，看我們的線上課程。
- （官方原文）Anthropic：Effective context engineering for AI agents
結語
回到開頭那個問題：為什麼同一個 AI，有人用起來像智障、有人用起來像超能力？答案往往不在「模型多強」，而在「你怎麼管理它的工作記憶」。這就是上下文工程的全部精神——在那塊又小又貴的 RAM 裡，剛剛好地放入下一步需要的正確資訊。你不需要會寫程式，光是「餵好背景、開新對話、把重點放開頭結尾」，就已經贏過大多數人。
這個領域還在快速演化，名詞或許會再變，但這套「管理有限記憶」的思維，會跟著你一直用下去。下次再覺得 AI 很笨的時候，先別怪它——先檢查一下，它的 RAM 裡到底裝了什麼。
免責聲明
本文為教育與知識分享用途，內容整理自截至 2026 年 6 月 的公開資料，主要參考來源包括：Anthropic 官方工程部落格〈Effective context engineering for AI agents〉(2025/9)、Lance Martin／LangChain 的〈Context Engineering for Agents〉(2025/6)、Drew Breunig 的〈How Long Contexts Fail〉(2025/6)、Chroma 的〈Context Rot〉研究 (2025/7)、Manus 與 Cognition 的工程文章，以及 Anthropic 官方定價與文件。文中部分模型行為、價格與功能細節（如自動壓縮觸發比例、各家工具規則檔上限）會隨版本更新，請以各官方文件最新版本為準。AI 具有輸出錯誤資訊的可能，重要決策請由人類複核。本文無業配內容。