Context Engineering

情境工程是什麼，跟提示工程有什麼不同？

提示工程（prompt engineering）關注的是「這一句話該怎麼寫」，而情境工程關注的是「這次對話的上下文窗口裡，應該放什麼、放多少、用什麼順序放」。範圍更大：包括系統提示、少樣本範例、RAG 檢索回來的文件片段、工具呼叫的回傳結果、對話歷史的取捨與摘要。

簡單說，提示工程是寫一句好台詞，情境工程是設計整個舞台——誰站在哪裡、觀眾看得到什麼、上一幕的記憶要保留多少。當任務變複雜（多輪對話、外部工具、大量參考資料），單靠寫好一句提示已經不夠，情境本身的組裝方式才是決定輸出品質的關鍵。

情境工程為什麼會出現，解決了什麼問題？

早期使用大型語言模型時，上下文窗口小、任務單純，寫好一句提示詞往往就足夠。但隨著上下文窗口擴大到數十萬 token、應用場景變成多輪對話 + 工具呼叫 + 外部知識庫檢索，問題從「怎麼問」變成「該給模型看什麼」。塞入太多不相關資訊會稀釋模型的注意力、拖慢回應、增加成本；塞入太少又會讓模型缺乏必要背景，導致幻覺或答非所問。

情境工程的出現，是因應這個新的瓶頸：當「有沒有足夠資訊」不再是問題，「資訊該怎麼篩選、排序、壓縮」才是決定答案品質的核心變數。

情境工程具體怎麼做，實務上有哪些常見手法？

幾種常見做法：

1. 分層放置：把最重要、最不會變動的指令（系統提示、角色設定）放在上下文最前面，把易變的、每輪不同的資訊（使用者最新訊息、即時檢索結果）放在最後面，讓模型的注意力集中在正確位置
2. 動態檢索取捨：RAG 系統不會把整個知識庫塞進去，而是先用相似度搜尋篩出最相關的幾段文件，控制在合理的 token 預算內
3. 對話歷史摘要：長對話進行到一定輪數後，把較早的內容壓縮成摘要，取代逐字保留，避免上下文塞爆
4. 工具結果精簡：工具呼叫回傳的原始資料（例如整份 API 回應）通常會先做欄位篩選或摘要，只留下模型真正需要的部分再放入上下文

這些手法的共同目標，是讓上下文窗口裡的每一個 token 都在為當前任務服務，而不是被無關資訊佔用。

情境工程對我有什麼影響，實務上該注意什麼？

如果你在設計需要長時間運作的 Claude 應用（客服機器人、研究助理、多步驟 agent），情境工程的品質會直接決定系統的穩定性與成本。常見的實務注意事項：不要迷信「上下文窗口越大就丟越多資訊進去」，過量的不相關資訊反而會拉低回答準確度（這個現象有時被稱為「lost in the middle」，模型對放在上下文中段的資訊容易漏看）；優先做好資訊的篩選與排序，而不是單純擴大窗口。

對一般使用者而言，理解情境工程也有實際用處：與 Claude 對話時，把最重要的指令放在訊息開頭或結尾（而不是埋在一大段文字中間），並適時開新對話清空無關的歷史脈絡，都是應用情境工程原理的簡單做法。