iT邦幫忙

2025 iThome 鐵人賽

DAY 15
0
生成式 AI

可愛又迷人的提示詞工程 Prompt Engineering系列 第 15

Day15. 認識 Context Engineering 上下文工程

  • 分享至 

  • xImage
  •  

隨著 AI 的應用範圍愈來愈廣、功能愈來愈強大,此時你可能會發現 Prompt Engineering 雖然依舊好用,但單純靠提示詞已經不再足夠了。因為真正影響結果品質的變成是模型可以接收到多少正確的上下文資訊,這也是為什麼 Context Engineering 開始變得關鍵與重要

Context Engineering 的定義與背景

Context Engineering 作用是設計與優化提供給 AI 模型上下文內容的工程。它給單純寫提示詞不太一樣,Context Engineering 作用是打造一個完整的資訊環境,他可以決定如下事項:

  • 哪些外部文件需要被引入?
  • 歷史對話的記憶該如何傳遞?
  • 外部工具 (API) 應該如何串接?
  • 所有資訊該以何種格式呈現給模型?

正如 LangChain 官方所強調的:Context Engineering 的目標是為了提供正確的資訊與工具,並以最適合的格式賦予大型語言模型完成複雜任務的能力。

與 Prompt Engineering 的關聯與區別

Context Engineering (以下簡稱上下文工程) 與Prompt Engineering (以下簡稱提示詞工程)的關係密切,所以了解他們之間的不同,有助於我們設計出更好、更健壯的系統

範圍大小不同

提示詞工程著重在「如何在一次呼叫裡寫好指令」,也就是寫好要 AI 做什麼的那句話。 上下文工程涵蓋的範圍更廣,包含在這句指令之前、之中與之後,所有與任務相關的資料、記憶、檢索結果和工具配置。

靜態與動態

提示詞工程偏重靜態輸入,意味我們在呼叫模型前就要決定好 Prompt。上下文工程偏向動態調整,可以根據使用者當下的任務或外部資料,來動態拼接上下文,例如先索引文件、摘要、記憶,再整合進 Prompt 中。

資料策略 vs 表達策略

提示詞工程的重點是如何説得好,比如我們要規劃語句、結構、提供範例、給他約束 ... 等,這些在前面的文章都有一一介紹,有興趣的朋友可以翻閱之前的文章內容。

上下文工程的重點是什麼該被說,也就是整個資訊的規劃過濾、組織、邏輯 ....等,相對於提示詞更加全面與宏觀

錯誤造成的影響不同

如果提示詞工程沒有做好,模型可能會忽略我們的指令,或是偏離風格,輸出模糊的語意。但隨著 AI 模型愈來愈聰明,現在 AI 對提示詞的判斷能力好上許多,有時候提示詞沒有寫好,AI 也可以自己判斷輸出優質的內容。

那上下文工程沒有做好的話,可能導致模型忘記重要背景、甚至會搜尋到錯誤的資料,內文也會被大量雜訊蓋過。這些錯誤不容易被即時察覺,但影響更深遠。

簡單來說,上下文工程決定了舞台 (資訊環境) 上有哪些道具與佈景,而提示詞工程則是指導演員 (AI 模型) 如何在這個舞台上進行表演,一個好的系統,兩者缺一不可。

提示詞與上下文的角色分工

在設計 AI 系統時,我們可以將資訊劃分為兩類,以釐清它們各自應扮演的角色,決定哪些資訊放在提示詞裡,哪些要放在上下文中。

類別 放在上下文 (Context) 放在提示詞 (Prompt)
背景資訊 / 已知事實 歷史對話紀錄、知識庫摘要、先前使用者的偏好、記憶片段 像「假如你已經知道 X」、「假設背景是 Y」
搜尋結果 / 引用資料 把搜尋到的段落、引用文章摘要等放進上下文中 在提示詞裡指定:請根據以下文本回答
任務指令 / 要求 一般不放任務細節在上下文,避免過度冗雜 任務目標、格式、限制、輸出要求等必須明確寫在提示詞裡
工具能力 / 操作規則 可放工具調用介面函數、API 規格等上下文 在提示詞中告訴模型:在什麼情況下可呼叫工具、工具如何回應
範例與格式模板 可以把範例放入上下文作為參考 提示詞要指定:請模仿這些範例的語氣、格式

上下文工程的核心價值

建立標準化的開發流程

以往 AI 開發比較依賴開發者的個人經驗,而上下文工程強調導入可重複的標準化流程。這個流程的核心是將模糊的產品需求,轉化為 AI 能理解並執行的結構化指令。

為此就有了產品需求提示詞 (Product Requirements Prompt, PRP) 的最佳實踐。它將傳統開發的需求定義、計畫生成與執行實施,整合進一個標準化框架中:

  • 需求定義 (Define):透過結構化的 PRP 文件,明確定義 AI Agent 的最終目標、能力邊界、使用者故事與成功標準。
  • 計畫生成 (Plan):基於 PRP,讓 AI 輔助生成詳細的技術實施計劃,包含要使用的工具、資料結構與互動邏輯。
  • 執行實施 (Execute):根據該計劃,生成高品質、符合現有架構的程式碼,並完成最終實現。

透過 PRP 這樣的實踐,我們就將開發的可預測性與團隊協作效率提升到新的高度。

確保生產級的品質與可靠性

上下文工程強調從一開始就導入生產級 (production) 的品質思維,而不單純只要做出功能就好。

我們要確保框架中應包含從單元測試(無需 API 成本的快速驗證)到功能測試(驗證完整行為與錯誤場景)的多層驗證機制,確保程式碼的穩定性。此外也要注意安全性、測試覆蓋率、系統監控與類型安全等生產環境的硬性要求,確保 AI Agent 能在真實世界中可靠運行。

這使得 AI 系統的穩定性與可解釋性不再是空談,而是有具體的工程手段來保障。

提升開發效率與務實迭代

上下文工程不提倡過度設計,他的重點是高效與務實。

所以我們會避免過度工程話化,勁量從最小可行性 (MVP) 產品開始,透過快速迭代完善功能,好處是可以讓提示詞更乾淨聚焦,也可以讓整個開發過程更敏捷。

此外我們也能在上下文工程埋入範例,像這樣範例驅動的開發,大幅減少模糊的自然語言描述,也能確保 AI 輸出的程式碼風格與團隊現有的架構相符合,減少我們重構的成本

更複雜的 Agent 應用

當 AI 系統具備了標準化流程與生產級品質後,我們才能真正放心地建構更複雜的應用,並透過上下文管理的策略,實現多輪對話與個人化體驗,讓 AI 能夠記得關鍵資訊。

只有在一個可靠、可驗證的上下文中,我們才能讓模型安全、可靠地與外部世界互動,打造出真正能解決問題的 AI Agent。

小結

上下文工程並非只是給提示詞加上一層包裝,它是一種架構 AI 對話或 Agent 系統的底層設計思維。

當我們開始掌握如何區分提示詞與上下文、如何動態整合外部工具與記憶時,我們的 AI 應用就能在穩定性、可靠性與擴展性上實現質的飛躍。如果你已經很熟悉提示詞工程,也許下一步就是開始學著工程化上下文,讓 AI 應用可以愈發成熟


上一篇
Day14. 使用約束式提示詞控制 AI 輸出的格式與結構
下一篇
Day16. 上下文的三個層次:即時、持久與外部
系列文
可愛又迷人的提示詞工程 Prompt Engineering16
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言