如何把 Context Engineering 用進 AI Coding Workflow：一套可執行的落地路徑

為什麼你理解了概念卻寫不出上下文

在 AI 編碼助手中，Context Engineering（上下文工程）通常被描述為「如何給模型最相關的資訊」。但當你打開編輯器時，問題立刻變成了：該放哪些檔案？應該包含多少 token 的歷史？錯誤日誌要不要一起餵？

第一個最常見卡點是：你把 Context Engineering 當成了模型微調。實際上，它和訓練無關，只和當前對話或 Agent 循環中如何組織已有資訊有關。這意味著你不需要 GPU，也不需要重新訓練，只需要一套結構化的選擇、注入和更新規則。

第二個卡點是：你試著一次把整個程式碼庫塞進去。許多初嘗試者會拼接專案所有目錄結構、README、數十個文件，結果要不是超過 token 窗口，就是模型根本抓不住重點。

有效的 Context Engineering 需要三層：採集層、篩選層、注入層。其中第一層直接決定了後續質量，但多數人更關注最後一層。

採集層的核心是「主動獲取而非被動拼接」。在編碼場景中，你需要明確定義什麼資料是必須的：

一個比較具體的做法是設定檔案變更監聽器（如 chokidar），當檔案儲存時觸發一次上下文快照，而不是每次鍵盤敲擊都刷新。這樣既減少 API 消耗，也不會讓模型在回答中途因為上下文突變而「失憶」。

終端機中列印的上下文狀態日誌，包含各條上下文的優先順序和過期事件，用於診斷上下文問題

這是最容易失敗的部分。很多人會設計一個完美的上下文結構，但忘記考慮「過時上下文」的清理。結果模型每次回答都引用已經刪除的函數或過時的註釋。

失敗場景一：你儲存了一條錯誤訊息的上下文，使用者隨後修改了程式碼並重新編譯，但先前的錯誤上下文仍佔據 token 位置，導致新模型回應誤以為錯誤還存在。

解決方法：為每個上下文新增「有效直到」標記。例如編譯錯誤上下文只在下一個成功編譯的操作後自動移除；git diff 上下文在目前分支切換或提交後清空。你可以用簡單的優先權佇列來維護：高優先權（如使用者目前指令）始終保留，低優先權依時間或事件過期。

另一個常見問題是上下文個數過多。即使每個都非常精準，如果一次性注入 10 條以上，模型會開始產生注意力稀釋。一般建議保持主幹上下文 3-5 條，其餘的則透過使用者主動查詢來載入。

筆記型電腦上的遷移檢查清單，列出從無上下文到存取最小路徑的步驟，如檔案監聽、事件清除等

這裡給一個經典型的設計，不需要特殊框架，只基於 Node.js 或 Python：

建立一個 contextEngine.js，包含一個 ContextStore 類，內部用 Map 儲存每個上下文，key 是自動產生的 ID。
實作三種方法：addContext({ id, content, priority, expireOnEvent })、removeContext(id)、getActiveContexts()。
在你的 AI 編碼助手（如 Continue、Aider、Cursor Agent）的「tool call」或「hook」中呼叫：當檔案儲存時，呼叫 addContext 記錄 diff；當編譯執行結束時，檢查錯誤並呼叫 addContext 記錄 diff；當編譯運行結束時，檢查錯誤並調用 addContext 記錄 diff；當編譯運行結束時，檢查錯誤並調用對應上下文。
在傳送給模型的 prompt 組裝函數中，呼叫 getActiveContexts()，依優先權降序拼接。

這裡有一個真實的取捨：你是要「盡可能多的上下文」還是「只給模型最需要的」？前者容易把模型搞糊塗，後者需要你自己定義一套規則。以我們的實踐，推薦後者，而且規則宜少不宜多，先從一個簡單的「最近修改文件 + 最新錯誤」開始，再逐步增加。

若模型回答品質下降，首先檢查上下文佇列是否超載或過時。建議在終端機輸出上下文狀態日誌（用簡短的 JSON 行），方便複盤。還有一個檢查點：觀察模型是否在重複之前已經解決過的問題，這通常是上下文沒有及時清除的跡象。

如果頻繁出現上述問題，可以回退到一個更窄的上下文策略：只包含目前文件和一條使用者指令，完全放棄增量累積。雖然模型會缺少全域視野，但至少回答穩定性較高。這是一個可接受的工程權衡，尤其當你需要高可用性時。

跑通上述最小路徑後，你可能會發現還有很多優化點，例如如何跨會話保存上下文模板、如何為不同任務（重構、調試、程式碼審查）切換不同的上下文策略。這些已經是進階主題，單篇文章難以窮盡。

如果你的目標是脫離「調 API」式的使用，真正掌握如何設計 Agent 級的上下文閉環，建議進入更有系統的學習路徑：從環境建立開始，到微調上下文注入策略，再到多 Agent 協作下的上下文共享機制。