Context Engineering：超越 Prompt Engineering 的下一個前線¶
整理自外部來源（見文末），2026-06-19。Context engineering 被視為 prompt engineering 在生產環境的演化後繼者：從「調字句」升級為「設計模型看到的整個資訊環境」。
一句話定義¶
Context engineering = 刻意設計與管理「模型在生成回應時所看到 / 知道的一切」。 它把整個 context window 當成一個要被工程化的設計面,而不只是把 prompt 的字句調好。
與 Prompt Engineering 的四個差異¶
| 面向 | Prompt Engineering | Context Engineering |
|---|---|---|
| 範圍 Scope | 聚焦「措辭」 | 涵蓋所有輸入:prompt、system、範例、檢索資料、工具輸出、護欄、對話史 |
| 動態 Dynamics | 相對靜態的模板 | 執行期依當前 query 動態組裝 |
| 焦點 Focus | 怎麼問 | 要提供什麼資訊 給模型 |
| 整合 Integration | 把模型當孤立的文字處理器 | 把工具、API、記憶納入迴圈,模型是大系統的一環 |
一個比喻:prompt engineering 像導一場戲的某一幕,context engineering 是把整個舞台與道具都搭起來。
Context 由什麼組成¶
模型生成時，context window 裡通常包含:
- System 指令 / 角色定義
- 使用者 query
- 檢索進來的外部知識（RAG）
- 對話歷史
- 工具 / function schema
- 記憶系統（短期 + 長期）
- 安全約束 / 護欄
五個核心管理技巧¶
- 選擇 / 相關性（Selection）：只放進相關資訊（相關性評分、向量相似度），避免分心。
- 壓縮（Compression）：把長歷史 / 長文件摘要成更短的表示,塞進有限視窗。
- 排序（Ordering）：階層化擺放,例如把持久的 system prompt 放在 context 最上方。
- 隔離（Isolation）：依角色切分（system / user / assistant）並用不同格式標記（JSON、bullet、tagged text）。
- 檢索整合（Retrieval）：用 RAG 注入即時事實 / 領域知識,讓輸出有所依據。
三個常見失敗模式¶
- Context Rot（脈絡腐化）：context 變得很大時,模型對特定事實的回憶反而變差——資訊越多不一定越好。
- Distraction（分心）：放進不相關內容,會讓模型給出離題答案。
- Overflow（溢出）：資訊超過視窗,重要片段被丟棄或忽略。
相關框架¶
- Model Context Protocol（MCP）：一個正在成形的標準,用一致方式向模型描述工具與能力。
- Context engine：一個自動化層,在執行期即時編排所有 context 組裝（檢索、記憶、prompt 建構）。
核心啟示¶
「效能的提升,越來越不是來自更好的模型,而是來自更聰明的 context。」
把模型當「資訊環境的工程」來做,而不是當黑箱來戳。
與本庫其他筆記的關係¶
- 這是 Prompt Engineering 核心技術 的自然續集（從「怎麼問」擴到「給什麼」）。
- 其中「檢索整合」這塊由 RAG 完整指南 與 Agentic RAG（2026） 展開。