# 當 AI 開始「健忘」：從一個調試噩夢談起 Context Engineering

凌晨三點，我盯著螢幕上的錯誤日誌，咖啡已經涼了。

我們的客服 AI 系統又出問題了。明明前面聊得好好的，客戶提到了訂單編號，但到了對話後半段，AI 竟然問「請問您的訂單編號是？」我翻看對話記錄，訂單編號清清楚楚地在第 15 條訊息裡。

這不是 AI 模型的問題，我們用的是最新的 GPT-4。問題出在別的地方。

## 那天改變一切的推文

就在我準備重寫整個對話管理系統時，我刷到了 Shopify CEO Tobi Lutke 的一條推文。那是 2025 年 6 月 19 日，他寫道：「別再糾結 Prompt Engineering 了，Context Engineering 才是關鍵。」

說實話，第一眼看到這個詞，我還以為又是什麼行銷噱頭。但仔細想想我遇到的問題，突然有種恍然大悟的感覺。

我一直在優化怎麼「問」AI，卻忽略了更重要的事：我到底「給」了 AI 什麼資訊？


## 從 4K 到 100 萬：一場上下文的軍備競賽

還記得早期用 ChatGPT 的時候嗎？聊幾輪就會忘記之前說了什麼。那時候的上下文視窗只有 4K tokens，大概就是幾頁 A4 紙的內容。

現在呢？Claude 3.5 已經支援 200K tokens，而最新的 Claude 4 更是將這個數字推向了 100 萬 tokens。Gemini 2.5 Pro 也達到了類似的水平。聽起來很厲害對吧？


但這裡有個陷阱。就像你不會把整個資料庫倒給一個新員工，然後期待他立刻找到需要的資訊。更大的上下文視窗不等於更好的理解。

## 中間地帶的詛咒

後來我發現了一個學術研究，解釋了為什麼我們的 AI 會「健忘」。研究人員稱之為「Lost in the Middle」現象。

想像一下你在讀一本很厚的技術手冊。你可能記得開頭的摘要和結尾的總結，但中間那些密密麻麻的細節？大概率會被忽略。AI 也有同樣的問題。


研究顯示，當你給 AI 提供大量資訊時，它會呈現一個 U 型的注意力曲線。開頭和結尾的資訊容易被記住，中間的？就像石沉大海。

這解釋了為什麼我們的客服 AI 會忘記訂單編號。它被淹沒在對話的中段了。

## 重新思考：不是怎麼問，而是給什麼

Context Engineering 的核心理念其實很簡單：與其糾結怎麼寫出完美的提示詞，不如想想怎麼組織和管理你要給 AI 的資訊。

我開始重構我們的系統。不再是把所有對話歷史一股腦兒塞給 AI，而是：

**智能摘要**：每隔幾輪對話，就生成一個關鍵資訊摘要。訂單編號、客戶問題、已經採取的行動，都記錄在一個結構化的「上下文物件」裡。

**動態優先級**：根據當前對話的主題，動態調整哪些歷史資訊應該被優先考慮。討論退款？那就把訂單相關的資訊往前放。

**分層處理**：長對話被分成多個邏輯段落，每個段落有自己的摘要。AI 可以先看摘要，需要時再深入細節。

效果立竿見影。客服 AI 不再「健忘」了，客戶滿意度從 72% 提升到 89%。

## Claude 的 Context 革命：Projects 功能

就在我苦惱如何更好地管理上下文時，Claude 推出了 Projects 功能。這簡直是為 Context Engineering 量身定制的。

Projects 讓你可以創建一個持久的知識庫。我把所有的 API 文檔、程式碼範例、業務規則都放進一個 Project 裡。每次對話，Claude 都能記住這些背景知識。這相當於給 AI 配了一個專屬的「大腦外掛」。

更棒的是，Claude 的 200K context window 意味著你可以放入一整本技術手冊的內容。我甚至把整個微服務架構的設計文檔都丟了進去。

## 從 Prompt 到 Context：實戰心得

我最近發現了一個 GitHub 專案 [context-engineering-intro](https://github.com/coleam00/context-engineering-intro)，完美詮釋了 Context Engineering 與傳統 Prompt Engineering 的差異。

這個專案的作者提出了一個很有意思的觀點：Prompt Engineering 就像是「投機取巧地措辭」，而 Context Engineering 是「建立一個完整的系統來提供全面的上下文」。

他們的工作流程讓我大開眼界：

1. **詳細的功能請求文檔**（INITIAL.md）- 不是簡單的需求描述，而是包含所有細節的完整規格
2. **產品需求提示生成器**（PRP）- 系統化地生成包含所有必要上下文的提示
3. **程式碼範例庫** - 讓 AI 理解你的程式碼風格和模式
4. **驗證機制** - 確保生成的程式碼符合專案標準

這種方法把「與 AI 合作寫程式」從隨機的「碰運氣」變成了可預測、可重複的工程流程。

## MCP：當標準化來敲門

Anthropic 不僅在產品功能上創新，還在 2024 年 11 月開源了 Model Context Protocol (MCP)。

這就像是 USB 標準之於電腦周邊。以前每個 AI 應用都要自己實現資料連接，現在有了統一的協議。你的 AI 可以標準化地連接到資料庫、API、文件系統，而不需要為每個資料源寫特殊的程式碼。

我花了一個週末把我們的系統遷移到 MCP。原本幾千行的整合程式碼，現在變成了幾個簡潔的配置文件。更重要的是，這個協議已經被 Claude、Gemini 和 OpenAI 支援，真正實現了「一次開發，處處可用」。

## Claude 的最佳實踐：讓 AI 「思考」

使用 Claude 進行 Context Engineering 時，我發現了一些獨特的技巧。Claude 團隊分享的最佳實踐中，有一個特別有用：讓 Claude 先「思考」再行動。

具體來說：
1. **先讀取相關文件** - 告訴 Claude 讀取特定文件，但明確指示「先不要寫程式碼」
2. **制定計劃** - 使用「think」這個關鍵詞觸發 Claude 的延伸思考模式（think < think hard < think harder < ultrathink）
3. **驗證和迭代** - 利用子代理來驗證細節，特別是在對話初期

這種方法大幅提升了程式碼品質。我們的 bug 率從 15% 降到了 3%。

## 踩過的坑和學到的教訓

這一路走來，我踩了不少坑。分享幾個最痛的：

**上下文膨脹**：一開始我以為上下文越多越好。結果不僅回應變慢，準確率反而下降了。後來我學會了「斷捨離」，只保留真正相關的資訊。就像 Claude Projects 建議的，200K tokens 相當於 500 頁的書，但你真的需要那麼多嗎？

**時效性陷阱**：有次 AI 引用了三個月前的產品價格。我這才意識到，上下文不僅要有，還要新鮮。現在每條資訊都有時間戳，過期的會被自動過濾。

**格式混亂**：不同來源的資料格式不一，直接餵給 AI 就像讓它讀天書。統一資料格式這件事，看起來簡單，做起來要命。這也是為什麼 MCP 協議如此重要 - 它提供了標準化的資料交換格式。

**Context Clash**：這是個新發現的問題。當你在對話中分散提供資訊時，AI 的表現會大幅下降。研究顯示，這種「資訊分片」會導致平均 39% 的性能損失。解決方案？一次性提供完整、結構化的上下文。

## 實用建議：開始你的 Context Engineering 之旅

如果你也想開始實踐 Context Engineering，這裡有幾個建議：

1. **從 Claude Projects 開始** - 如果你是 Claude Pro 用戶，立即創建一個 Project，把你最常用的文檔和程式碼範例放進去
2. **建立你的上下文庫** - 參考 context-engineering-intro 專案，為你的專案建立結構化的上下文文檔
3. **採用 MCP 標準** - 如果你在開發 AI 應用，考慮使用 MCP 來標準化你的資料連接
4. **測量和優化** - 記錄 AI 的錯誤率和回應時間，持續優化你的上下文策略

## 寫在最後

Context Engineering 不是什麼高深的黑科技，它更像是一種思維方式的轉變。

以前我們問：「怎麼讓 AI 更聰明？」

現在我們問：「怎麼讓 AI 看到它需要看到的？」

這個轉變，可能比任何模型升級都要重要。特別是在 2025 年，當 Claude 4、GPT-5 這些模型的能力差距越來越小時，真正的競爭優勢來自於你如何使用它們。

下次當你的 AI 又開始「裝傻」的時候，別急著改 prompt。先看看你給了它什麼上下文，又是怎麼組織的。答案可能就在那裡。

順帶一提，我那個凌晨三點的調試？最後只改了 20 行程式碼，調整了上下文的組織方式。問題就解決了。

有時候，最簡單的解決方案，往往最有效。

而 Context Engineering，正是這樣一個簡單卻強大的解決方案。

---

*關於作者：一個在 AI 時代努力不被淘汰的工程師，專注於讓 AI 更好地理解人類，而不是讓人類遷就 AI。*