什麼是 Context Engineering？取代 Prompt Engineering 的企業框架

你正在決定用什麼取代企業 AI 堆疊中的 Prompt Engineering。這裡才是真正的答案。

你正在決定是否繼續投資於 Prompt Engineering（提示工程）培訓，或是否應該圍繞供應商最近稱之為「Context Engineering」（情境工程）的新學科重新組織你的 AI 能力。這個決定非常關鍵——預算、招聘、組織架構、供應商選擇，全部圍繞它而轉。以下，是這個詞真正的含義、為什麼 Anthropic、OpenAI 及頂尖企業 AI 團隊現在將它視為策略級工作單位，以及如何圍繞它建立你 2026 年的 AI 能力。

本文不會要求你放棄 Prompt Engineering。它會向你展示：Prompt Engineering 只是一個更大學科下的子集——而只在提示層進行優化的企業，是在優化錯誤的變數。

什麼是 Context Engineering（情境工程）？

Context Engineering 是一門學科，專門設計 AI 模型在推理時所見的完整資訊環境——提示、檢索到的文件、工具輸出、對話歷史、系統指令及元資料——使模型能為特定業務任務產出可靠、高品質的結果。Anthropic 將其定義為 Prompt Engineering 的自然進化：不再著眼於「找到正確的字眼」，而是「什麼樣的情境配置，最有可能產生我們想要的行為」。

這個轉變並非語言學上的，而是結構上的。Prompt Engineering 將輸入視為使用者精心撰寫的單一文字串。Context Engineering 將輸入視為一個經過工程化的系統——被篩選、版本控制、檢索、壓縮、評估——並在模型每次運行時流入模型之中。

對企業領袖而言，實際意義在於：你不再是聘請那些文字功夫了得的人。你是在建設一套基建，在規模化、可審計、每一次都如此的情況下，於正確時刻、為正確任務，組裝出正確的情境。

為什麼 Context Engineering 取代了 Prompt Engineering 成為策略性概念？

2025–2026 年間，三股力量交匯，使 Context Engineering 成為主導學科。第一，情境窗口由 8,000 個 token 擴大到 100 萬個——問題已不再是「如何把我的請求塞進提示」，而是「我要用什麼填滿這 100 萬個 token」。第二，AI 代理（AI Agent）成為正式生產系統，而代理會進行多次模型呼叫、情境持續演化——靜態提示會失效。第三，檢索增強生成（RAG）與工具使用成為預設——提示本身，如今只佔到達模型內容的極小部分。

根據 Anthropic 工程團隊，Context Engineering 引入了五個情境必須滿足的品質標準：相關性（只放任務需要的資訊）、充分性（足以在無需猜測下作答）、隔離性（任務之間無滲漏）、經濟性（以最少 token 傳遞最大訊號），以及可追溯性（每一項事實都可追回來源）。

任何未明確處理這五個標準的 2026 年首席資訊官 AI 策略，基礎都是不穩的。只對提示品質評分的供應商評估，評估的是已過時的層級。

Context Engineering 在企業 AI 系統內部實際如何運作？

正式投產的 Context Engineering 系統，具備四個在每次 AI 請求運行時協同運作的層級。理解這四層，是領袖判斷供應商究竟是真正在做 Context Engineering、還是只是為舊版提示劇本換新包裝的方法。

--- 第一層：檢索。系統從內部知識來源——政策文件、CRM 紀錄、產品目錄、過往對話——透過向量嵌入上的語義搜尋抽取相關情境。這一層決定了模型是否擁有作答所需的事實。

--- 第二層：工具整合。模型被賦予以結構化方式存取業務系統的能力——查詢資料庫、呼叫 API、建立紀錄。工具輸出會再回饋到下一次模型呼叫的情境中。

--- 第三層：指令設計與記憶。系統提示、角色定義、行為約束，以及對過往互動的長期記憶。這一層定義了這個 AI 是誰、在這項特定任務上應如何表現。

--- 第四層：評估與可觀測性。每一次情境組裝都被記錄。輸出會按品質標準評分。產生失敗的情境模式被標記並修訂。缺少這一層，其他三層會在不知不覺中隨時間退化。

若供應商聲稱在做 Context Engineering，卻無法在正式環境中展示這四層，其實只是包裝得較好的提示範本。

Context Engineering 與 Prompt Engineering、RAG 有什麼分別？

Prompt Engineering、RAG、Context Engineering 經常被混淆。清晰的劃分是：Prompt Engineering 優化文字串。RAG 將文件檢索進提示中。Context Engineering 則是把整個資訊環境——包括提示、檢索、記憶、工具、約束、評估——作為一個工程化系統來編排。

換句話說：Prompt Engineering 是一種技能。RAG 是一種技術。Context Engineering 是容納兩者的整體架構。當數碼轉型總監評估一個企業 AI 平台時，問題不是「它是否支援 RAG」（每個平台都支援）。問題是這個平台是否提供一個連貫的框架，能在每日數千次 AI 互動中設計、版本控制、評估、治理情境。

這正是為什麼 Deloitte 2026 年研究顯示 75% 企業計劃在兩年內部署代理式 AI，但 KPMG 觀察到這些部署「推進後又退縮」——將情境視為基建的機構成功；只將它視為提示文字的機構則不然。

Context Engineering 對你香港機構的 AI 預算意味著什麼？

在實際預算層面，2026 年的企業 AI 堆疊，會把 60 至 70% 的實施支出，由模型授權轉移到 Context Engineering——檢索系統、評估框架、工具整合、可觀測性。模型本身正變得商品化；包覆它的情境，正成為策略性資產。

對於中型香港企業（200 至 500 名員工），合理的第一年 Context Engineering 投資範圍介乎 80 萬至 300 萬港元，包含向量資料庫基建、檢索管道開發、評估工具，以及設計及維護系統的人才或夥伴。這不包含模型本身——模型逐漸成為按 token 計費的營運支出，而非資本開支。

常見的誘惑是跳過 Context Engineering，期望用更大的模型解決問題。2026 年的證據毫不含糊：即使是最強的前沿模型，在情境工程不佳時，也會產出不可靠的企業輸出。每月花 5 萬港元用最強模型卻沒有情境基建，正是機構對 AI 徹底失去信心的方法。

一個真正達到企業級水準的 Context Engineering 能力，是什麼樣子？

一個達到企業級水準的 Context Engineering 能力，會展現四個採購團隊在供應商評估階段就可驗證的特徵。第一，具名的檢索來源：供應商能精確列出哪些內部文件、資料庫、API 正在為情境供料。「我們的 LLM 會讀取你的資料」是營銷；有文件紀錄的來源清單才是工程。

第二，具可量度標準的評估準則：對來源的忠實度、完整性、安全性、任務特定準確度——每一項都有通過／失敗門檻。第三，情境範本的版本控制：能像軟體團隊回退一次錯誤部署那樣，回退一次情境更改。第四，可觀測性：每一次 AI 互動都記錄完整組裝的情境，讓失敗可以被診斷，成功模式可以被複製。

若供應商無法在試點期間展示這四項，他們就尚未準備好進行企業級部署——不論他們掛的是哪款模型。

企業領袖採納 Context Engineering 時最常犯的錯誤是什麼？

第一個錯誤，是把 Context Engineering 當作可委派的技術細節。它不是。Context Engineering 是業務知識——定價規則、審批流程、政策詮釋、客戶情境——與 AI 層相遇的地方。若這一層沒有業務端主人，AI 會在規模化運行下自信地犯錯。

第二個錯誤，是過度塞滿情境。更多情境，不等於更好情境。「以防萬一」地把每一份文件都加進去，會降低模型效能，並大幅推高每次查詢成本。Anthropic 的五個標準——相關性、充分性、隔離性、經濟性、可追溯性——正是為了對抗這種本能。

第三個錯誤，是略過評估。團隊部署了 Context Engineering 系統、看到漂亮示範、便宣告勝利。六個月後，漂移出現——文件過時、檢索拖出陳舊紀錄、工具輸出格式改變——AI 便悄然退化。持續評估是唯一防線。懂AI，更懂你 UD相伴，AI不冷——Context Engineering 殘酷的現實，是工作永遠不會「完成」，只會愈來愈受治理。

準備好建立你的 Context Engineering 能力？

Context Engineering 這一層，決定你 2026 年的企業 AI 投資會複利增長還是崩潰。UD 已陪伴香港企業走過 28 年，手把手帶你完成每一步——由檢索架構、評估框架設計，到 AI 勞動力部署、持續情境治理。沒有提示範本式的表演，只有能讓企業 AI 規模化下仍然可靠的基建。