上下文工程：讓你從 AI 用戶晉升為 AI 高手的核心技能

大多數 AI 用戶都在缺少這個關鍵層次

你用 AI 工具已經一段時間了。提示愈寫愈精細，有時輸出結果令你非常滿意，但也有一些時候，同一組提示在上週運作良好，這週卻輸出一堆廢話——你找不到任何理由。

問題幾乎不在你的提示措辭。問題在你的上下文。

上下文工程（Context Engineering）是一種刻意管理 AI 模型在生成回應前所「看見」的一切的實踐——不只是你的訊息，還包括系統指令、注入的知識、對話歷史、範例，以及工具輸出。提示工程（Prompt Engineering）關注你對模型說什麼；上下文工程關注模型在你說話時知道什麼。

OpenAI 創始成員、前特斯拉 AI 總監 Andrej Karpathy 給出了最精確的定義：「在上下文視窗中填入恰到好處資訊的精妙藝術與科學。」「恰到好處」這四個字非常關鍵——不是全部可用的資訊，不是愈多愈好，而是下一步所需的最精確內容。

大多數從業者從未學過這個區別。學過的人，輸出品質明顯處於另一個層次。

什麼是上下文工程？

上下文工程是一種設計並管理語言模型完整資訊環境的方法，涵蓋系統指令、注入知識、對話歷史、示例，以及結構化狀態——目的是在重複使用中產生持續高品質的輸出。

在 Notion、Linear、Perplexity 等公司的生產 AI 系統中，流入模型上下文視窗的內容，約有 80% 是精心設計的背景資訊——檢索到的文件、角色定義、結構化數據、工具輸出。用戶的實際訊息只佔約 20%。這個比例正是上下文工程的核心洞見：提示只是冰山一角。

提示工程專注於那 20% 的指令本身；上下文工程關注的是其餘的 80%——模型推理所在的環境。兩者都重要，但對於每天持續使用 AI 的從業者而言，上下文工程才是真正的槓桿所在。

為何精心設計的提示有時仍然失效？

精心設計的提示產生差劣輸出，最常見的原因不是措辭問題，而是周圍的上下文讓模型難以聚焦於真正重要的事情。

原理如下：每個 AI 模型都有一個上下文視窗——它在生成回應時能「看見」的全部文字量。2026 年，主要前沿模型提供 128K 至 100 萬 Token 的視窗。直覺告訴你，視窗愈大愈好。事實並非如此。

史丹福大學基礎模型研究中心的研究記錄了所謂的「中間迷失」效應：即使模型擁有超大上下文視窗，埋藏在長對話中間的資訊所獲得的模型注意力，仍系統性地低於位於開頭或結尾的資訊。一個被埋在 60,000 Token 對話中間位置的關鍵限制條件，實際效果幾乎等同於不存在。

這正是為何同一組提示在全新對話開頭能產生優秀結果，但在長對話進行到一半後往往表現失色——提示沒有變，但上下文變了，而且對你不利。

上下文工程就是刻意管理這個上下文：什麼內容放進去、放在哪裡、如何結構化，以及視窗開始擁擠時哪些內容需要修剪。

每位從業者都需要管理的四個上下文層次

無論你使用 ChatGPT、Claude 還是 Gemini，每一個高效的 AI 工作流都在四個上下文層次上運作。大多數從業者只有意識地管理其中一到兩個層次。掌握全部四個，才能獲得可重現的穩定輸出品質。

第一層 — 系統指令

這是你上下文的基礎。它定義了模型扮演的角色、應該做什麼與不做什麼、輸出格式，以及適用的品質標準。強而有力的系統指令是具體的，而非泛泛而談。「你是一個有幫助的助理」是系統指令。「你是一位香港 B2B 市場策略師，正在為客戶撰寫中英文內容。避免行話。始終使用具體數據舉例。每個段落不超過 200 字。」才是真正能塑造輸出的系統指令。

第二層 — 注入知識

模型需要準確回答所需的參考資料——產品規格、公司指南、數據摘要、風格範例、過往決策。這裡的關鍵技能不是注入所有可用的資料，而是選取最低限度的相關子集。一份包含 3 條精選客戶引言的內容簡報，比注入 20 頁市場研究的效果更好。

第三層 — 對話歷史（主動管理）

原始對話歷史是上下文品質最大的殺手之一。隨著對話延長，之前的訊息不斷積累——其中許多對當前任務已經不再相關。優秀的上下文工程師會主動總結並精簡對話歷史，只保留對下一步有實質意義的決策、限制條件和輸出結果。當一個對話已經「漂移」，正確的應對不是提示得更長，而是重置並重新建構上下文。

第四層 — 工具輸出與結構化狀態

在代理工作流中——模型調用工具、檢索數據或執行程式碼的情境下——這些操作的輸出會成為下一步的輸入。如何結構化並呈現這些輸出，對後續生成品質有顯著影響。JSON 格式的工具輸出、命名欄位、要點摘要，始終優於原始文字傾倒。

如何在實際工作中應用上下文工程

你不需要任何技術設置就能開始實踐上下文工程。以下三個習慣，在任何 AI 介面中持續應用，一週內就能看到輸出品質的明顯提升。

習慣一：為每種重複性任務類型撰寫持久性系統上下文。對你定期執行的每種任務——撰寫客戶電子郵件、起草簡報、總結報告、審查提案——撰寫一個可重複使用的系統上下文區塊。內容包括：你的角色、目標受眾、輸出格式、品質標準和關鍵限制。儲存好它，在每次相關對話開始時貼上。每當你發現輸出存在系統性不足時，更新它。

習慣二：只注入相關內容，而非所有可用內容。在要求模型執行任何知識密集型任務之前，識別它所需的最低限度摘錄——而不是整份文件。如果你在一次客戶通話後起草跟進電子郵件，貼上會議記錄，而不是整個客戶歷史。模型用 400 個精準的字，比用 4,000 個漫無邊際的字表現更好。過度注入與注入不足同樣有害。

習慣三：在上下文品質下降之前重置並總結。當一個長對話開始產生更弱的輸出——更泛化、更不精確、偏離你的指令——不要用更長的提示去對抗。要求模型總結目前對話中已確立的內容。複製這份總結。開啟新對話，將總結作為起始上下文貼上，然後從那裡繼續。這樣做能重置上下文視窗，同時不失去連貫性。

上下文工程常見錯誤與避坑指南

了解不該做什麼，與了解技術本身同樣重要。以下是最常見的失敗模式。

把所有東西都塞入上下文。更多輸入不等於更好輸出。一個塞滿邊際相關文件的上下文視窗，其輸出品質劣於只包含三段高度相關段落的上下文。模型會將注意力分散到它看見的所有內容上。你的工作是確保它看見的每樣東西都值得佔據那個位置。

忽視內容的放置位置。上下文視窗的開頭和結尾獲得的模型注意力不成比例地多——這是模型層面的近因效應和首因效應。將不可妥協的限制條件和品質標準放在系統提示中（頂部）。將具體任務和任何關鍵參考資料放在你的請求正前方（底部）。絕不要把關鍵資訊埋在長篇貼文的中間。

把一個對話當作無限工作空間。許多從業者在一個對話中貼文件、提問題、生成輸出，然後跨天跨週持續積累訊息。等到他們執行最重要的查詢時，上下文已被無關的早期工作污染。有目的地使用對話。一個新任務值得一個全新的上下文視窗。

注入內容時不做結構化處理。原始散文比結構化內容更難被模型解析。注入參考資料時，使用清晰的標題、標記的章節或要點。「品牌聲音：直接、實用、無行話。目標讀者：30-45 歲、香港本地、B2B 行銷主管。」的效果，始終優於等量的連續散文。

立即嘗試：一個可直接複製的上下文系統

以下是一個適用於內容創作者、市場人員和運營專業人士的即用上下文模板。複製它，填入括號中的內容，並在下次 AI 對話開始時、提出任何請求之前貼上。

---

系統上下文

你是一位資深 [角色：如內容策略師 / 文案撰寫人 / 分析師]，正在協助 [你的姓名] 在 [公司名稱] 完成工作。

主要任務類型：[如「為客戶起草中英文對外內容」]

目標受眾：[具體描述——如「香港本地熟悉科技的 B2B 決策者，對行話持懷疑態度」]

語氣與風格：[如「直接、有權威感、平輩對話式。無企業官話。短段落。主動語態。」]

格式：[如「每次輸出最多 350 字。前兩句必須是鉤子。列表用要點格式。結尾一個清晰的行動呼籲。」]

硬性限制：[如「不得捏造統計數據。不得使用『賦能』或『協同效應』等詞語。」]

參考資料：
[只貼本次對話所需的具體摘錄——如會議記錄、產品規格、數據摘要——而非整份文件]

當前任務：
[說明你現在需要模型生成什麼]

---

執行一次。將初稿品質與你平時只用提示的方式比較。針對系統上下文進行迭代——在模型偏離的地方收緊限制，在語氣偏差的地方添加示例。經過 3-4 輪改進後，你將擁有一個能持續產出可靠成果而無需大量編輯的上下文系統。

從 AI 用戶到 AI 高手的真正分水嶺

提示工程是大多數從業者停下來的地方。上下文工程是穩定、可生產品質 AI 輸出的起點。一個偶爾獲得優秀 AI 成果的用戶，與一個持續獲得卓越成果的高手之間的差異，幾乎總是體現在他們如何設計提示周圍的環境——而非提示本身。

2026 年，模型的能力已經足夠。限制因素是你給它們的簡報品質。正如 Karpathy 所言，在嚴肅的 AI 工作流中，提示只佔工作的 20%，另外 80% 是上下文。

懂AI，更懂你 — UD 同行28年，讓科技成為有溫度的陪伴。真正的技術賦能，不只是知道上下文工程的存在，而是把它建構進你每天的工作方式中。

準備好建構真正可擴展的 AI 工作流？

理解上下文工程是第一步。下一步是將它建構成整個團隊都能持續使用的工作流。UD 團隊手把手帶你完成每一步——從上下文設計、系統提示架構，到在組織內部署可靠的 AI 工作流。我們幫助香港各行業的團隊，從不穩定的一次性提示，升級到可重現的 AI 系統。