Part 1: 一切的起點
提示詞 (Prompt)
當大型語言模型 (LLM) 剛出現時，它主要是一個聊天機器人。而你對它說的任何話，就是「提示詞」。
// 普通提問
你: 你好。
AI: 我很好，你呢？
🎭 角色扮演式提問
// 1. 先給予角色設定
你: 你來扮演一位海盜船長。
// 2. 開始對話
你: 你好。
AI: 嘿，夥伴！有什麼寶藏要尋找嗎？
但「角色設定」和「對話內容」混在一起容易混亂。於是，模型廠商們巧妙地將提示詞一分為二：
系統提示詞 (System Prompt)
定義 AI 的角色、行為準則和背景設定。通常由開發者預設。
例如: "你是一位豪邁的海盜船長"
用戶提示詞 (User Prompt)
我們在聊天框裡輸入的日常對話內容。
例如: "你好"
這種透過組合與設計來引導 AI 的做法，就是 提示詞工程 (Prompt Engineering)。
Part 2: 馴服 AI 的藝術
提示詞工程技巧
提示詞工程的核心目的，是透過一系列技巧來約束 AI 的行為，使其回覆更穩定、精準。
Zero-Shot
只提要求，不給範例。直接命令 AI 遵循某些規則。
"解這道數學題，在給出答案前，請仔細檢查，確保答案正確。"
Few-Shot
給 AI 幾個具體範例作為參考，讓它模仿學習。這在需要特定格式輸出時特別有用。
// 範例 1
"出發去尋寶" -> "小的們，揚帆，目標是寶藏！"
// 範例 2
"我畫好了藏寶圖" -> "藏寶圖完成了，船長！"
// 現在，轉換這個句子：
"我找到了一箱金幣"
思維鏈 (Chain of Thought, CoT)
一種更玄學的技巧。引導 AI 一步步拆解問題，並給出中間結果，從而提升複雜問題的準確率。
問題
1 + 2 * 3 = ?
並要求：一步步拆解
AI 的思考過程：
1. 根據運算優先級，先計算 2 * 3，結果是 6。
2. 然後再計算 1 + 6。
3. 最終結果是 7。
Part 3: 當對話變長...
上下文 (Context)
一個殘酷的事實：模型本身沒有記憶。
每次我們給 AI 發送消息，對它來說都是一次全新的、獨立的請求。那麼，連續對話的「記憶」是怎麼實現的呢？
答案是：透過一個中間層 (AI Agent 或聊天伺服器)。
你
AI Agent
// 1. 收到你的新消息
// 2. 附加到歷史紀錄末尾
// 3. 將包含「所有過往信息」的完整歷史打包
AI 模型
這個被一次性發給 AI 的「完整歷史紀錄」，就叫做 上下文 (Context)。
當 AI Agent 擁有工具（如網頁瀏覽）時，情況變得複雜。為了回答一個問題，AI 可能會多次調用工具，導致上下文極速膨脹，充滿中間訊息。
[User] 海盜的口頭禪是什麼？
[AI] 決定... 使用 Google 搜尋
[Tool_Code] google.search("海盜 口頭禪")
[Tool_Response] (返回了長篇的網頁內容...)
[AI] 決定... 訪問維基百科
[Tool_Code] browser.visit("...")
[Tool_Response] (又返回了超長的網頁內容...)
...
[AI] 總結：海盜的口頭禪通常是 "啊哈！" 或 "嘿咻！"。
問題：在這個漫長的探索過程中，AI 很容易「跑偏」，忘記自己最初要幹什麼。
如何透過程式化規則，自動管理和修改這個上下文，確保 AI 不跑偏？這就是 上下文工程 (Context Engineering) 要解決的核心問題。
Part 4: 讓 AI 保持專注
上下文工程方案
雖然沒有公認的完美方案，但業界有一些常見且有效的做法。
1. 讓 AI 學會記筆記
提供一個「記筆記」的工具，並在系統提示詞中指導 AI：行動前先分解任務，寫下任務清單，並隨時更新狀態。這些「筆記」會被放在上下文最顯眼（開頭或結尾）的位置。
上下文結構示意
由於 Transformer 架構對頭尾信息特別敏感，這能確保 AI 始終記得核心目標。
2. 讓上下文變短（壓縮）
既然太長是問題的根源，那就想辦法縮短它。
暴力丟棄
直接丟掉太老的消息，只保留最近的對話（系統和用戶提示詞除外）。
優雅總結
讓 AI 模型去總結較老的消息，用精煉的總結替換掉原來的長篇內容。
3. 更高級的壓縮與優化
從源頭減少信息冗餘，或用更高效的方式存儲信息。
RAG + 工具化
將上萬字的文章存入向量資料庫，然後給 AI 一個查詢工具。這樣，幾萬字的 `tool_response` 就被壓縮成了一句幾十個字的指令。
優化工具返回值
對於網頁瀏覽工具，Agent 可以先去掉不必要的 HTML 標籤、廣告等，只把最核心的內容返回給 AI 模型。