當 AI 工具剛起步時，最常被提及的關鍵字是 Prompt Engineering（提示工程）。那的感覺就像學會「魔法咒語」，只要會用對的詞，模型就會吐出漂亮的答案。各種社群上流傳的很多prompt 模板，讓人可以很快的直接應用。

但很快地，當任務變得複雜，例如需要查詢多份文件、呼叫不同工具，甚至在不同角色之間協作時，單靠prompt 已經撐不住了，就會遇到瓶頸卡住了。於是，就開始很多人開始討論——Context Engineering（上下文工程）這樣的概念。

#1為什麼要談「上下文」？

先看一個比喻。Andrej Karpathy ，前 Tesla AI 負責人，也曾是 OpenAI 的核心人物，他在一次演講中說：

「LLM 就像作業系統，模型是 CPU，而 Context Window 就是 RAM。Context Engineering，就是要把對的資訊在對的時機，精巧地放進 RAM。」

（YTLink: https://www.youtube.com/watch?v=LCEmiRjPEtQ&t=620s)

這句話的意思是：模型的能力再強，如果記憶體塞不進有用的資訊，那就是浪費。換句話說，模型本身不是問題，問題在於我們怎麼餵它「上下文」。

另一位把這件事講得更直白的人，是 Shopify 的創辦人Tobi Lutke 。他在 X 上寫道：

「It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.（Context Engineering 是為 LLM 提供所有能解決任務所需上下文的藝術。）」

Context Engineering不只是技術問題，它更像一種調和——什麼該放進去，什麼該拿掉，什麼時候該壓縮，什麼時候該拆分，這需要經驗與判斷。

在這一集的YC影片，就在討論要讓提示詞更加立體和完整的脈絡。

（YT Link: https://www.youtube.com/watch?v=DL82mGde6wo)

影片中的範例，採用「經理式」超詳細提示詞架構，轉而採用長達 6 頁以上的詳盡提示詞文件。精準角色定位: 明確告訴 LLM 它的身份和專業領域，錨定 LLM 語氣風格、專業水準、思維模式；任務分解，將複雜任務拆解為可管理的小步驟。面對複雜工作流程，預先定義好任務並規劃執行路徑至關重要；結構化標籤: 使用 Markdown、XML 或 JSON 格式規範輸出。結構化格式對 LLM 的重要性不可低估，還有 API 整合優勢便於後續處理和驗證，因此這種結構化方法能產生更好的結果。

#1從 Prompt 到 Context 的轉變

回頭看，提示工程的時期，像是大家都在練習寫「漂亮的提問或指示」。但隨著 AI 被放進真實場景，就覺得不能只有單一提示詞的內容是不夠。

這就像你請實習生準備簡報，如果只說「幫我弄一份會議簡報」，結果一定會偏離你的預設期待。因為缺少上下文Context，沒有跟實習生說給誰看？要講什麼內容？之前的版本是什麼？需要搭配哪些資料？

LLM 也是一樣。它可以寫，但它需要背景，需要資料，需要任務的上下文Context；這就是從 Prompt Engineering 到 Context Engineering 的轉變。

Context Engineering 的原則

• Context 不是字串，而是系統：它不是一個靜態 prompt，而是多個環節共同生成的輸出。

• Context 是動態的：不同任務需要不同上下文，不能一套打天下。

• 資訊要正確，工具要即時：避免 Garbage In, Garbage Out。

• 格式很重要：簡潔的摘要比雜亂的原始數據更有用。

#1GPT 的記憶層次：更立體的 Context

建立Context就是可以運用LLM本身會有的記憶能力，以ChatGPT來說

再來看看記憶系統。GPT 的上下文管理可以拆成四層：

• 長期記憶（Long-term Memory）：放置固定資訊，例如使用者個人偏好或公司規則。比如說要每次回答時，都使用繁體中文回覆。

• 指令式記憶（Short-Term Memory）：透過即時指令，讓它暫時記住購物清單或會議重點。特定指令要求 GPT 記住特定事項（如採買淸單、會議重點、記帳）。

• 對話歷史（Conversation History）：保存近期的互動紀錄，避免斷線式的回應，可在後台資料控管中檢視與管理。

• 專案記憶（Projects Memory）：專門存放某個專案的文件與資料，避免不同專案混淆，例如專案文件規格、會議記錄，在該專案時，直接引用該專案的上下文，不會混淆到其他情境。

除了記憶層次，加上檢索（RAG）、工具結果、結構化輸出，共同組成一個完整的上下文Context， 不僅僅是你傳送給 LLM 的那段 prompt，而是模型在回應之前，將會看到的所有內容，這包括：

• Instructions / System Prompt: 定義模型行為的初始指令和風格

• User Prompt / User Input: 使用者的請求、問題或輸入

• Retrieved Information (RAG): 外部的最新知識，從文件、資料庫或 API 檢索的相關資訊

• Available Tools: 所有可呼叫的函數或工具定義

• Responses from tools: 工具執行的結果

• Structured Output: 定義模型回應格式，例如 JSON 或 XML

• Global State / Workflow Context: 在多步驟驟 Agent 或 Workflow 中，暫存全域變數、任務進度、先前結果等等。

LangChain 開發者的拆解

Lance Martin (LangChain 核心開發者) 寫了一篇 Context Engineering for Agents 文章，將上下文工程會用到的方法歸納為四類

1. 寫入 Context：把資訊存在長期記憶之外，例如保存使用者偏好，讓模型隨時能調用。動態將資訊保存在 context window 之外，例如跨對話記憶用戶偏好，形成長期記憶(Memory)的效果

2. 選擇 Context：從記憶、檢索系統或工具結果中，動態挑選最相關的資訊。將相關內容拉進 context window，這包括從 Memory 拉出需要的回憶、根據當下任務動態挑選工具、透過 RAG 檢索拿到的相關資料 。

3. 壓縮 Context：當資訊量超過限制，就做摘要或濃縮，把必要訊息留住。 在context window 限制下，在超過某個閥值時，我們只保留執行任務所需的 tokens。例如 Claude Code 在超過 95% context window 時執行會 auto-compact，將目前狀態總結存下來，再重新開始。或是其他修剪方式。

4. 隔離 Context：把任務拆分成子代理處理，主代理只要接收結果，節省大量資源。將 context 拆分以協助任務執行，通常出現在 Multi-Agents 的實作，把任務拆分到另一個 Sub Agent 去執行，執行完成回來就只會有結果，如此可以大幅節省 Lead Agent 的 context 用量。

這些技術內容，自己理解後其實蠻生活化。就像整理出國行李，不能什麼都塞進行李箱。你要決定：哪些必帶？哪些可以壓縮？哪些乾脆分成小包？Context Engineering感覺就像是替模型整理分類要出國的行李。

但總結來說，Prompt Engineering 並不會消失，它只是成為 Context Engineering 的一部分。從單一的「提示詞」，進化成一個需要設計、選擇、壓縮、隔離的完整流程系統。所以Prompt是一部分，很多個Prompt串在一次，形成一個可以解決複雜問題的流程系統。